アジャイル開発の発展がDevOpsの進歩を促した
アジャイル開発プロセスの 教義では、小規模な反復を頻繁にリリースして、ソフトウェアを開発するべきとされます。これは、ウォーターフォールモデルで、全ての機能を一度にリリースするビッグバン・ アプローチと反するものです。アジャイルでは一般的に、2週間の各スプリントの終わりに、出荷できる最低限の機能をリリースするのを目指します。
アジャイル開発はビジネスの信頼性を取り戻すために適用されてきたものの、意図的ではないにせよ、運用をおろそかにしていたとの指摘があります。アジャイルの要求でデプロイの頻度が上がったため、IT 運用の作業が増えてしまい、それについて対策が十分になされていませんでした。
コードが開発されても、すぐに本番環境へ適用されなければ、デプロイするべきコードが運用チームで滞ってしまいます。例えば、開発チームがが2週間に1度コードを凍結しているのに対し、デプロイは2ヶ月に一回しか行われないといった状態です。顧客は便益を得られず、久しぶりのデプロイによって混乱と、過去のシステムへの不具合をもたらすリスクが高まってしまいます。
DevOpsでは継続的インテグレーションとリリースプロセスを高度化し、アジャイル・開発プロセスを補完します。コードが常に出荷できる状態にあるため、顧客に価値を提供できる点が保証できるからです。そのため、DevOpsは事業全体として信頼を取り戻すための方法論になるのです。
DevOpsとITILやITSMとの関係について考える
DevOpsはITIL やITサービスマネジメントへの回帰だと捉える人がいます。しかし、これらの方法論は、いまだにIT運用が目指すべきビジネスプロセスの中心的な存在です。実際、DevOpsが提唱する作業フローを実現するためには IT運用に関する多くのスキルが求められます。
アジャイル開発において、継続的インテグレーションやリリースは開発チームのアウトプットであると同時に、運用チームのインプットになり得ます。頻繁なリリースを実施するために、ITILで議論されている分野である、変更管理・構成管理・リリースに関する自動化が必要とされます。
DevoOpsの目的は変更の頻度を高めるだけではなく、混乱や他のサービスの破壊を伴わずに、新しい機能を本番環境へとデプロイする点です。また、問題が発生した場合、素早く検知し、修正する必要があります。これはITILのサービスデザイン、インシデント管理、問題管理といった方法を反映しています。
DevOpsを実装する4つのパターン
DevOps Areasの記事では、開発と運用チームの関わりに関して、DevOpsを四つのパターンに分類しています。
エリア1：開発と本番を統合する
継続的インテグレーションとリリース機能を本番環境に統合します。QA（品質保証）やセキュリティ作業を作業フローの一部に組み込み、コードや実行環境が常に本番へデプロイできる状態である点を確認します。
エリア2：本番環境でのフィードバックを開発チームに反映する
開発と運用チームが協力してインシデントの解決に臨むよう、時間を配分します。また、本番環境に関するポストモータム（作業後の振り返り）に開発チームを参加させ、開発者が自分自身で実行環境に関する問題を解決できるよう、建設的な議論を行います。そして、個人やチーム内で行われた意思決定が、システム全体の目標達成に影響している旨を明らかにし、必要な情報が全員に伝播されるよう確認する方法です。
エリア3：開発チームを運用チームに組み入れる
本番環境の問題解決フローに開発チームを参加させ、場合によって、問題解決作業を開発者に担当してもらいます。この方法により、技術的負債の解消が促進し、開発チームと運用チームが相互に情報共有し、運用から開発へのエスカレーションを減らします。
エリア4：運用チームを開発チームへ組み入れる
上記とは逆に、運用チームの担当者を、開発チームに参加させます。運用スタッフで、デプロイや本番環境でのコード管理というた再利用できる成果物を作ります。また、他のプロジェクトに横展開できる非機能要件を定義します。
セキュリティや品質保証部門がDevOpsの導入によって受ける影響とは
DevOpsではデプロイ頻度の向上を目指します。しかし、頻繁なデプロイは、QA（品質保証）とセキュリティ部門に負担をかけます。例えば、開発チームが日に20回のデプロイ行っているのに対し、セキュリティチームが4ヶ月かけてセキュリティのレビューを行うとします。コードの開発とセキュリティのテストの間に、リードタイムのミスマッチが発生しています。
セキュリティのテストが十分でないままデプロイされてしまった例として、2011年の Dropbox の障害が挙げられます。認証が4時間無効化されてしまい、認証していないユーザーが他のユーザーのデータにアクセス可能になるというものでした。
品質保証とセキュリティは継続的インテグレーションの仕組みを活用し、頻繁なデプロイへ対応できる可能性があります。DevOpsで提案されているテスト自動化の文化と合致しているからです。つまり、コードがリポジトリにチェックインされるたびに、自動化テストが走り、すぐに問題が解決される流れです。機能テスト・統合テストに加え、セキュリティテストが日次のプロセスに組み込まれれば、セキュリティの問題がすぐに検出・解決される期待が高まります。
セキュリティテストが膨大なものになり、数時間・数日かかってしまい、継続的インテグレーションとの統合が困難になるという問題があります。そのような場合、暗号化や認証といったセキュリティに関するモジュールを特定し、その箇所に変更があった場合にのみ、再テストを実施します。セキュリティに関する変更がなければ、デプロイは継続します。
品質保証の問題としては、DevOpsが通常の単体テストよりも、検出・修復を重視している点が挙げられます。これまでのパッケージソフトウェアの開発では、品質保証部門が、リリース前に十分に機能テストを行っていました。DevoOpsでは自動化テストに依存しており、本番環境における問題の発見・解決を目指しています。品質保証が発見と修復を重視するのは、高いデプロイ頻度の中で作業効率を向上させるのに、現実的な判断と言えます。
しかし、企業の信用やシステムが保有する重要なデータを失うリスクが高い場合、品質保証部門は、発見と修復に頼るべきではありません。デプロイされる前にテストされなければ、本番環境でのセキュリティ問題につながるからです。
品質保証とセキュリティにおいては、DevOpsに対応した新しい仕事の進め方が求められています。
まとめ
アジャイル開発が普及し、素早い開発と安定した運用が求められるようになったことを背景に、DevOpsが発展してきました。ITILなどで議論されてきた運用手法が、現代の開発手法のもとで見直されてきたものと位置付けられます。開発チーム、運用チーム、セキュリティ部門、品質保証部門が一つの目標に向かって、自動化・効率化を図っていく新しい考え方が求められています。
