PR

DevOpsのチーム体制

 DevOpsの推進において重要なのはDevOpsチームという新たな役割の設置です。DevOpsチームは以下のような観点から開発部門と運用部門、さらに品質部門の混成チームである必要があります。

  • 運用作業の自動化に当たり、アプリケーションの構成や構造、テストの実施内容、インフラ構成といった幅広い理解が必要になる
  • 運用作業を自動化するためにはツールの導入、カスタマイズ、設定といった作業が必要になり、開発スキルが要求される

 さらに、この混成チームは、それぞれの部門が持っている既存の手法ではなく、新たな手法で自動化を検討する必要があります。DevOpsチームが推進する自動化の究極のゴールは、開発チームが運用部門や品質部門と会話することなく、用意されたツールを利用して、システムリリースや運用を実現することです。そのためには開発チームに対して運用作業をセルフサービス化する必要があります。例えば以下のような仕組みが考えられます。

  • 開発、ステージング、本番環境の構築は、開発チームが必要なサービスやサーバーの台数を定義するだけで自動的に完了する
  • 開発チームがソースコードをリポジトリーに登録するだけで、適切な環境にリリースが完了する
  • ログは自動的に収集され、開発チームはシステム間をまたがるトランザクションログも自由に閲覧することができる
  • 開発チームが定めたエスカレーションルールに従い、障害時には適切な人に適切な連絡が行く

 こうした仕組みの整備によって、マイクロサービス環境において新たなサービスを作成するハードルが下がります。ここで「用意されたツール」というのは、従来の標準化と発想は同じです。マイクロサービスは個々のサービスで完結せず、それらのサービスが連携することで機能します。相互に連携可能であることを保証するには、お互いに守るべきルールが必要です。そのため、マイクロサービス群全体を一元的に管理する視点が必要です。

 マイクロサービスでは「Decentralized Governance(ガバナンスの分散化)」という特性があります。これは各サービスを単一の技術で作ろうとするのではなく、サービスの特性に合わせて適切な技術セットを使うべきだという意味です。この指摘は妥当ですが、全体最適を考える場合、個別の事情を考慮し過ぎるのは非効率につながります。特にセキュリティーや品質には統制(ガバナンス)が必要であり、そこに強制力が無いことはリスクとなります。

 ただし、従来の標準化に比べると制約は少なくすべきです。特にパブリッククラウドサービスを前提にする場合、クラウド側で用意されているサービスの範囲であれば選択肢は自由にしてもよいでしょう。例えば仮想サーバーであればインスタンスタイプなどは選択肢が多くても全体最適化にはあまり影響がないはずです。サーバーレスのようにミドルウエアやハードウエアが高度に抽象化されたサービスの活用も、インフラ構成の観点からは全体最適に影響を与えないでしょう。また、後述するようにDockerのようなコンテナ技術であれば、アプリケーションの開発言語やフレームワークの選択がインフラ構成や運用作業に与える影響を小さくできます。

 導入したツールは改善を繰り返します。新しい技術は次々と登場します。ツールが対応していなくても、マイクロサービス環境であれば、特定サービスだけでの試行錯誤も実現しやすくなります。DevOpsの活動そのものもマイクロサービスと同じように改善を繰り返していく必要があります。