DevOps: 迅速で確実なアプリデリバリのための協業的な考え方

共有

DevOpsとは

DevOpsとは、高品質なソフトウェアをすばやく納品することを最終的な目標としていたリーン思考とアジャイル開発から始まった運動を、より広く適用し、発展させたものです。アジャイル開発は一般的に、ソフトウェアエンジニアの役割を中心に据え、ソフトウェアの迅速かつ漸進的な開発に焦点を当てています。クラウド時代になって、ソフトウェアが(設備内にインストールされるよりも)ますますサービスとして消費されるようになると、本稼働が開始されるまで、納品されたとは見なされません。アジャイルの哲学に沿って、ソフトウェア機能の継続的で、漸進的で、迅速なデリバリを重視する動きがますます高まっています。その結果、アジャイルは必然的に運用上のスピードや品質にまで、つまり、コードの完成から本稼働でのサポートまでの一連の活動(構築、テスト、プロビジョニング、構成、デプロイ、継続的な管理など)にまで拡大されました。このようにソフトウェアをすばやく納品するには、開発者(Dev)とIT運用担当者(Ops)が互いに協力しあう必要があります。

DevOpsの動きは、こうしたニーズを認識し、それに対応した結果です。よって、DevOpsは柔軟性が高く、より緊密なコラボレーション、コミュニケーション、そしてソフトウェアデリバリの成功に向けた責任の共有を通じて、従来のハンドオフでありがちだった製品開発(開発者およびQA)側とIT運用側との間の摩擦や遅延の多くを回避できます。


過去のコンテキスト

DevOpsは、従来のエンタープライズソフトウェアデリバリの考え方と大きく異なるものです。一般的に、多くの企業ではソフトウェア開発組織とIT運用組織は別々に分かれて業務を行うため、両組織間の連携がうまくいかず、迅速なソフトウェアデリバリにとって不利な状態です。たとえば、ほとんどの企業の開発者は、概して構成済みインフラストラクチャの自己プロビジョニングをすることが難しく(IT運用担当者によって管理されているため)、反復可能で標準化された環境をスピンアップすることができません。結果として、開発やテストが効率的にできるよう独自に構成されたプライベート環境で、自分が担当するコードを開発することになります。その後、IT運用担当者に引き渡すことにより、さまざまなソフトウェア(複数の開発者によって異機種環境で開発され、テストされた製品)が、高可用性、拡張性、セキュリティといった企業が理想とする特性を持つ、実行中のアプリケーションシステムに投入されます。
View more

これは概して、IT運用担当者にとって複雑で、手動の操作を要し、時間がかかり、エラーが発生しがちなプロセスで、開発チームのサポートがなければ完遂できません。ソフトウェアのデプロイ中に発生した問題が、チーム間の摩擦や不信感につながることも多くあります。このような摩擦は、今日の継続的デリバリ事情の中で悪化しています。なぜなら開発者にとっての誘因はすばやくデリバリすることであり、一方でIT運用担当者の誘因は安定性を確保することだからです。よって、最新の自動化機能を使用しない場合、変更を制限することが実質上取り得る唯一の道になります。


重要な要素

DevOpsは、こう実施すべきといった処方箋がありません。ですが、成功していて十分に機能しているDevOpsプラクティスはいくつかの特性が共通していて、組織の文化、プロセス、およびツールに影響をもたらす傾向があります。

文化

うまく行っているDevOpsプラクティスには、全体の成功、コラボレーション、および説明責任の共有を重んじる文化が浸透しています。開発者やITプロフェッショナルは、アプリケーションデリバリの成功に対して共同で責任を負います。これを促すには、人材が複数の指令系統のもとで別々のプロジェクトに携わるような職能的サイロを廃し、サービスを構築する側と実行する側が同じ場所で開発や運用を行うようにするなど、組織的な変化が必要です。
View more

またDevOpsは共感に重点を置いており、互いの役割をより良く理解し、相手方を受け入れやすくするべく自らの作業を調整し、より効果的にコラボレーションできるようにすることを開発者やIT運用担当者に奨励しています。たとえば、実稼働環境を理解することで、開発者は運用上どのような不具合が起こり得るかをより良く理解し、それに合わせて設計できます。一方、IT運用担当者は、アプリケーション設計をより良く理解することで、デプロイ構成を最適化できます。

DevOpsプラクティスの成功は、成功に対する尺度の違い(開発者は機能を短期間でリリースすることが誘因となり、IT運用担当者は実稼働環境への変更を最小化することが誘因となる)によって生じる摩擦の原因を大いに解消します。

プロセス

DevOpsの文化をプラクティスに反映させるには、開発者とIT運用担当者の両方がコミュニケーションしながら知識を共有し合うフォーラムを設けるといった共通のプロセスの確立や、迅速かつ構造化されたソフトウェアデリバリと障害復旧のための明確に定義された協働フレームワークが必要です。そのようなフレームワークでは、たとえば、APIを通じた容量のセルフプロビジョニングに関して責任を負うこと、IT運用担当者はそれらを実装し、サポートすることなどが定められる場合があるでしょう。または、開発、テスト、実稼働環境間のAPIの区別をなくすことで、遅延や問題の主な原因である環境パリティの問題を解消する合意や契約を提供することもあるかもしれません。

共通プロセスのその他の例としては、相互依存性のあるソフトウェアに対して集中化されたストレージを定め、共同で開発されたスクリプトを通じて最新の状態を維持しながら使用することなども挙げられます。時の経過とともに、こうしたコラボレーションは学びや反復的な改善をもたらすほか、繰り返しやダウンタイムリスクの削減を実現しながら、ソフトウェアの変更を漸進的かつ頻繁に実稼働環境に投入することを可能にします。

自動化と共通ツール

ソフトウェアのデリバリを迅速かつ確実に行うには、プロセスが一貫性と反復可能性を有し、不要な手動介入をなくすべく合理化されている必要があります。たとえば企業は、容量プロビジョニング、開発環境と実稼働環境の差異、および手動で複雑なコンパイル/テストフェーズに関連するスローダウンに頻繁に悩まされています。

一方、良好に機能しているDevOps環境では、協働プロセスの具体化と合理化を可能にする共通のツールを使用して、ソフトウェアデリバリプロセス全体に関する共通の理解が得られます。結果としてDevOpsの実行者は、より迅速なデリバリに役立つ一貫性や自動化を推進できるほか、展開中における予期せぬ火消しや実稼働中における障害復旧に時間を浪費することを回避できます。今や、多くのエンタープライズベンダーが、継続的なインテグレーション、またはインフラストラクチャの自動化や構成のためのツールを提供しています。しかしながら、これらの異なる個別ソリューションの統合は複雑な作業で、余分な経費が掛かる割には、企業の収支にはあまり効果がありません。




「DevOpsは確かに今日の主流であり、もはや、あると助かるとか差別化要素といった存在というより、市場で効果的に競争する上で不可欠な存在です。」

Ovum Research; Changes Within and Driven by DevOps; June 2016




Next Section
Why DevOps?