DevOps再入門〜DevOpsが生きる領域、ITILが生きる領域〜：特集：国内DevOpsを再定義する（2）（3/4 ページ）

[編集部,＠IT]

DevOpsに必要な「仕組み」とは

編集部　ただ、DevOpsの適用領域を見つけられたとしても、具体的に何をすれば良いのか、取り組むべきとされる要素が複数あり、今一つ鮮明にならない部分があったと思います。例えば、開発・運用の技術面では具体的に何ができれば「DevOps」と言えるのでしょうか。

長嶋氏　前述のように、DevOpsは「アプローチ」であり範囲が広いため、「何ができれば」とまとめることは難しいのですが、複数の要素を組み合わせて、「スピーディに顧客満足度を上げるための取り組みがなされていること」がDevOpsだと考えます。これをテクノロジの側面で言えば、「開発、ビルド、テスト、デプロイ、リリース、モニタリング、開発へのフィードバック」という一連のステップを連携させ、一つのプロセスとしてスピーディに、高頻度で実行できる「仕組み」があることです。

　例えば、ビルドのためのボタンをクリックすると、そこからテストフェーズに自動的にデータが受け渡され、自動的にテストされる。その結果についてもポリシーやしきい値をあらかじめ決めておき、一定の条件をクリアした開発成果物は人の承認なくして自動的に本番環境にデプロイされる。それと同時に安定運用のための監視項目も自動的に登録、監視されていく。米国では実際にここまで自動化している企業もあります。

図3　開発、ビルド、テスト、デプロイ、リリース、モニタリング、フィードバック」という一連のステップを一つのプロセスとしてスピーディかつ高頻度で実行できる「仕組み」が不可欠（提供：ガートナー）

　また、リリースした後、例えば期待するパフォーマンスが出ていないなど、必ずしも想定通りの動きをしないことがあります。そうした場合、例えば「このアラートが上がってきたら、○日前にリリースされたものは元の状態に戻す」といった一定のポリシーに基づいて、人の承認を介さずに自動的に切り戻す、といったこともなされ始めています。

　ただ、切り戻すといっても「必ず元の状態に戻せる」とは限らないので、「リリース後、一定の時間は古いものと新しいものを両方立ち上げておき、ネットワークのスイッチを使って新しいものに切り替え、異常があれば古いものに戻す、なければ古いものを壊す」といった、いわゆるブルーグリーンデプロイメントを人の手を介さず実現できるようにもなっています。

参考リンク：継続的デリバリ／デプロイを実現する手法・ツールまとめ（＠IT）

　これは当然、一つのツールでできるわけではなく、複数のツールを駆使して、それらが一つのプロセスとして連携するようにしなければなりません。そのためにはデータの流れや承認プロセスの在り方、各ツールのAPI連携なども重要なポイントになります。「リリース自動化だけ」「テスト自動化だけ」といった取り組みはDevOpsではないといえます。

「一連のプロセスや自動化の仕組み、テストやモニタリングした後の開発との連携、コラボレーションといった要素がなければ、一日に何回もデプロイすることは不可能」

編集部　最初にDevOpsという言葉を使ったFlickrのエンジニアは「一日10回デプロイできるようになる」ことをDevOpsとして紹介しました。やはりこれがDevOpsの要件といえるわけですね。

長嶋氏　求めるアプリの品質、ニーズの変化の状況など、開発を取り巻く複数の要素があるため、デプロイの回数に変動はあるにせよ、必要なときに、必要な回数、デプロイできなければ、「スピーディにサービスを開発・改善する」というDevOpsの目的は実現できません。前述した一連のプロセスや自動化の仕組み、テストやモニタリングした後の開発との連携、コラボレーションといった要素がなければ、一日に何回もデプロイすることは不可能です。

　これまでDevOpsというと「開発と運用が打ち合わせをしている」「チェックリストを作っている」といった例もありましたが、それは品質担保の取り組みであり、ビジネスゴールにはつながっていません。「OpsDev」という言葉も出てきましたが、それが「運用担当者にとって良い取り組み」という意味なら、ビジネスゴールにつながっていない点で、やはりDevOpsではありません。

　「ニーズに迅速に対応するためのコラボレーションができること」「そのためのプロセスが作り上げられていること」「テクノロジを駆使してスピードと頻度を実現できること」「目的に応じた品質を担保できること」――こうした複数の要素でスピーディに顧客満足度を上げるための取り組みがなされていることがDevOpsと呼べる要件だと思います。