DevOpsとは
DevOpsとは、高品質なソフトウェアをすばやく納品することを最終的な目標としていたリーン思考とアジャイル開発から始まった運動を、より広く適用し、発展させたものです。アジャイル開発は一般的に、ソフトウェアエンジニアの役割を中心に据え、ソフトウェアの迅速かつ漸進的な開発に焦点を当てています。クラウド時代になって、ソフトウェアが(設備内にインストールされるよりも)ますますサービスとして消費されるようになると、本稼働が開始されるまで、納品されたとは見なされません。アジャイルの哲学に沿って、ソフトウェア機能の継続的で、漸進的で、迅速なデリバリを重視する動きがますます高まっています。その結果、アジャイルは必然的に運用上のスピードや品質にまで、つまり、コードの完成から本稼働でのサポートまでの一連の活動(構築、テスト、プロビジョニング、構成、デプロイ、継続的な管理など)にまで拡大されました。このようにソフトウェアをすばやく納品するには、開発者(Dev)とIT運用担当者(Ops)が互いに協力しあう必要があります。
DevOpsの動きは、こうしたニーズを認識し、それに対応した結果です。よって、DevOpsは柔軟性が高く、より緊密なコラボレーション、コミュニケーション、そしてソフトウェアデリバリの成功に向けた責任の共有を通じて、従来のハンドオフでありがちだった製品開発(開発者およびQA)側とIT運用側との間の摩擦や遅延の多くを回避できます。
過去のコンテキスト
DevOpsは、従来のエンタープライズソフトウェアデリバリの考え方と大きく異なるものです。一般的に、多くの企業ではソフトウェア開発組織とIT運用組織は別々に分かれて業務を行うため、両組織間の連携がうまくいかず、迅速なソフトウェアデリバリにとって不利な状態です。たとえば、ほとんどの企業の開発者は、概して構成済みインフラストラクチャの自己プロビジョニングをすることが難しく(IT運用担当者によって管理されているため)、反復可能で標準化された環境をスピンアップすることができません。結果として、開発やテストが効率的にできるよう独自に構成されたプライベート環境で、自分が担当するコードを開発することになります。その後、IT運用担当者に引き渡すことにより、さまざまなソフトウェア(複数の開発者によって異機種環境で開発され、テストされた製品)が、高可用性、拡張性、セキュリティといった企業が理想とする特性を持つ、実行中のアプリケーションシステムに投入されます。
これは概して、IT運用担当者にとって複雑で、手動の操作を要し、時間がかかり、エラーが発生しがちなプロセスで、開発チームのサポートがなければ完遂できません。ソフトウェアのデプロイ中に発生した問題が、チーム間の摩擦や不信感につながることも多くあります。このような摩擦は、今日の継続的デリバリ事情の中で悪化しています。なぜなら開発者にとっての誘因はすばやくデリバリすることであり、一方でIT運用担当者の誘因は安定性を確保することだからです。よって、最新の自動化機能を使用しない場合、変更を制限することが実質上取り得る唯一の道になります。
重要な要素
DevOpsは、こう実施すべきといった処方箋がありません。ですが、成功していて十分に機能しているDevOpsプラクティスはいくつかの特性が共通していて、組織の文化、プロセス、およびツールに影響をもたらす傾向があります。
文化
うまく行っているDevOpsプラクティスには、全体の成功、コラボレーション、および説明責任の共有を重んじる文化が浸透しています。開発者やITプロフェッショナルは、アプリケーションデリバリの成功に対して共同で責任を負います。これを促すには、人材が複数の指令系統のもとで別々のプロジェクトに携わるような職能的サイロを廃し、サービスを構築する側と実行する側が同じ場所で開発や運用を行うようにするなど、組織的な変化が必要です。
またDevOpsは共感に重点を置いており、互いの役割をより良く理解し、相手方を受け入れやすくするべく自らの作業を調整し、より効果的にコラボレーションできるようにすることを開発者やIT運用担当者に奨励しています。たとえば、実稼働環境を理解することで、開発者は運用上どのような不具合が起こり得るかをより良く理解し、それに合わせて設計できます。一方、IT運用担当者は、アプリケーション設計をより良く理解することで、デプロイ構成を最適化できます。
DevOpsプラクティスの成功は、成功に対する尺度の違い(開発者は機能を短期間でリリースすることが誘因となり、IT運用担当者は実稼働環境への変更を最小化することが誘因となる)によって生じる摩擦の原因を大いに解消します。
プロセス
DevOpsの文化をプラクティスに反映させるには、開発者とIT運用担当者の両方がコミュニケーションしながら知識を共有し合うフォーラムを設けるといった共通のプロセスの確立や、迅速かつ構造化されたソフトウェアデリバリと障害復旧のための明確に定義された協働フレームワークが必要です。そのようなフレームワークでは、たとえば、APIを通じた容量のセルフプロビジョニングに関して責任を負うこと、IT運用担当者はそれらを実装し、サポートすることなどが定められる場合があるでしょう。または、開発、テスト、実稼働環境間のAPIの区別をなくすことで、遅延や問題の主な原因である環境パリティの問題を解消する合意や契約を提供することもあるかもしれません。
共通プロセスのその他の例としては、相互依存性のあるソフトウェアに対して集中化されたストレージを定め、共同で開発されたスクリプトを通じて最新の状態を維持しながら使用することなども挙げられます。時の経過とともに、こうしたコラボレーションは学びや反復的な改善をもたらすほか、繰り返しやダウンタイムリスクの削減を実現しながら、ソフトウェアの変更を漸進的かつ頻繁に実稼働環境に投入することを可能にします。
自動化と共通ツール
ソフトウェアのデリバリを迅速かつ確実に行うには、プロセスが一貫性と反復可能性を有し、不要な手動介入をなくすべく合理化されている必要があります。たとえば企業は、容量プロビジョニング、開発環境と実稼働環境の差異、および手動で複雑なコンパイル/テストフェーズに関連するスローダウンに頻繁に悩まされています。
一方、良好に機能しているDevOps環境では、協働プロセスの具体化と合理化を可能にする共通のツールを使用して、ソフトウェアデリバリプロセス全体に関する共通の理解が得られます。結果としてDevOpsの実行者は、より迅速なデリバリに役立つ一貫性や自動化を推進できるほか、展開中における予期せぬ火消しや実稼働中における障害復旧に時間を浪費することを回避できます。今や、多くのエンタープライズベンダーが、継続的なインテグレーション、またはインフラストラクチャの自動化や構成のためのツールを提供しています。しかしながら、これらの異なる個別ソリューションの統合は複雑な作業で、余分な経費が掛かる割には、企業の収支にはあまり効果がありません。
DevOpsが重要である理由
開発期間の短縮
ソフトウェア駆動の世の中では、ソフトウェアの構築とリリースを迅速に行うことで、顧客のニーズを知り、競争に打ち勝つことが成功の鍵となります。現在のエンタープライズアプリケーションは、分散されたコンポーネントが複雑に相互依存していますが、成熟したDevOps環境では、コミュニケーションの不足や遅延を回避しながら、開発者とIT運用担当者両方の知識を合わせることで、合理的なソフトウェアデリバリを実現することができます。『2016 State of DevOps Report(DevOpsの状況に関する報告書)』によると、DevOpsを実践している企業は、デプロイの頻度が(平均で)200倍多く、リードタイム(コードのデプロイを意図した時からコードが実稼働環境で使用されるまでの時間)は2555分の1だそうです。他の産業研究でも似たような知見が示されており、下に示すガートナー社のチャートでは、DevOpsアプローチへの移行に伴うさらに多くのメリットが列挙されています。
リスクの低減とデプロイの円滑化
最新アプリケーションの開発の調整と管理、デプロイ、規模の決定、セキュリティ保護、パッチ適用、高可用性といった事柄は複雑なもので、不具合の原因となり得る要素ばかりです。DevOpsプラクティスは、協働的な文化と、パッケージング、デプロイ、監視、および管理の自動化から成り、新規コードのプッシュと実稼働環境のアップデートに一貫性とスピードをもたらします。継続的学習と相まって、DevOpsチームは問題の原因のほとんどを特定、排除し、より堅牢で、合理的で、反復可能で、成熟したリリースプロセスを確立することで、ソフトウェアのデプロイを問題なく確実に行うことができます。
より迅速な回復
実稼働環境でコードが破損した場合、またはダウンタイムの原因となった場合でも、DevOpsプラクティスはすばやく診断し、回復させることができます。大幅な自動化や監視がリリースプロセスや管理プロセスの大部分を加速させることにより、DevOpsチームはすばやく協働して不具合の元を追跡、特定し、変更のロールバックや問題の修正を行うことができます。事実、『2016 State of DevOps Report(DevOpsの状況に関する報告書)』によると、前述のような迅速で構造化された対応により、DevOpsを実践している組織では実稼働での予期せぬ問題から回復までの平均速度が24倍で、変更の失敗率は3分の1だと報告しています。
顧客満足度とプロダクト/マーケットフィットの向上
機能やバグフィックスを迅速かつ確実にリリースすることは、反応性が向上して顧客満足度が向上するだけでなく、フィードバックが迅速に得られ、顧客が最も求めている機能により早く集中できることにもつながります。DevOpsプラクティスは、このような継続的なデリバリと短いサイクルタイムの中核を成すものです。開発者とIT運用担当者との間に継続的で緊密なコラボレーションがなければ、最新で、分散された本番用ソフトウェア機能の複雑さ、開発、テスト、およびデリバリの管理を、すばやいペースで着実に実行することは不可能です。
DevOpsと従来のアプローチの比較
DevOpsは、ソフトウェア組織に従来と異なる考え方と新しいプロセスをもたらします。次の表は、DevOpsを実践している組織と、従来型のアプローチを用いている組織の違いを示します。
DevOpsプラクティス:
|
従来のアプローチ:
|
---|---|
コラボレーション主義。 DevOpsの成功は、ソフトウェアを迅速かつ確実に開発し、デリバリすることを目指して、ソフトウェア開発者とIT運用チームが良好かつ継続的な形で緊密に協働できるかどうかによって左右される。 | サイロ駆動。 従来のアプローチは、「壁越しに投げる」形のコラボレーションに依存しており、実稼働環境でソフトウェアのデプロイと管理を行うIT運用担当者は、それを開発したチームから最小限の支援や知見しか得ることができない。 |
構造化され、大部分が(またはすべてが)自動化されている。DevOpsプラクティスでは、開発環境で機能していたことが、実稼働環境でも確実に機能するよう、環境のプロビジョニングと構成を自動化し、スピード、一貫性、および反復性をもたらしている。構造化されたアプローチでは、反復可能な自動化がロールバックとリカバリを容易にするため、障害復旧が加速される。 | 雪の結晶型でほとんどが手動。 従来のアプローチは、インフラストラクチャのプロビジョニングと構成を実行するにあたり、「雪の結晶」のようにそれぞれが異なる構成のサーバーを用いて、スクリプトプロセスと手動プロセスを臨機応変に組み合わせるやり方に依存している。このことが、正確性、確実な反復性、迅速性を得ることを難しくしている。このようなアプローチでは、構成パリティによって開発および実稼働インフラストラクチャを迅速かつ一貫してプロビジョニングすることができないことに起因して、数多くの問題に直面する可能性がある。 |
セルフサービス主義。 DevOps駆動の組織は、協働と自動化のための枠組みを確立することで、開発者やIT運用担当者が互いの行く手を阻害することなく、独立的に行動することを可能にする(開発者が自動化を通じて開発/テスト環境を迅速にプロビジョニングできるということは、IT運用担当者による手動でのプロビジョニングが不要であることを意味する)。 | 「ITチケット」主義。従来のエンタープライズアプローチの場合、IT運用担当者はITチケットの管理コストをやりくりし、簡単に自動化できる反復的で複雑なプロビジョニングや構成を手動で実行する必要がある。このことは、プロビジョニング、デプロイ、規模の拡大縮小、他のソフトウェアデリバリ、管理作業に大幅な複雑化と遅延をもたらす。 |
ビジネス中心。 DevOps組織は、協働してビジネスを成功させることに集中している。従って、ソフトウェアデリバリの成功に向けて責任を共有することを重視する。 | 職務重視。 従来のアプローチの場合、開発チームやIT運用チームは自分の職務の遂行に集中し、全体の成功に向けたつながりや責任感が希薄である。結果として、問題や障害が生じると、責任のなすり合いや組織的な摩擦が多くなる。 |
変更を想定した設計。 DevOpsプラクティスは、自動化、反復、迅速性を実現できるよう設計されており、頻繁な変更に対処でき、不具合からもすばやく復旧できるなど、速い進行に適したつくりになっている。 | 変化を嫌う。 従来のアプローチの場合、中断やすばやく復旧できなくなることを恐れて、実稼働環境での変更を避けようとする。変更やアップデートを最小限に抑えようとし、組織に対して暗に慎重さを求める。認証を頻繁に変更するため、短期間しか使用できない。 |
DevOpsを検討する際の 考慮事項
DevOpsは、文化、プロセス、およびツールを通じて、ソフトウェアデリバリサイクルを加速する新しいアプローチを推進します。初めに何から手をつけてよいか分からないという方に、DevOpsプラクティスの検討や計画に役立つベストプラクティスをいくつかご紹介します。
ニーズに合わせてカスタマイズしてください。DevOpsプラクティスの導入は、組織の構造、チームの誘因、現在のソフトウェアライフサイクル、遅延の原因、自動化の可能性を考慮しながら、組織固有のニーズを満たすよう構成される必要があります。
自動化と新しいプロセスに投資をします。「最新のサービスデリバリには、徹底した自動化が必要である。」[ソース:Forrester Brief: Good DevOps Requires Collaboration, Automation, And Cultural Change; June 2016]。DevOpsは、自動化を可能にするツールを通じて大幅に強化されます。多くの場合、DevOpsでの成功のためには、まったく新しい解釈の自動化が求められます。協働に関してチームをトレーニングすること、新しいプロセスを確立すること、および新しいツールを使用することへの投資は、そうするだけの値打ちが十分にあります。
リサーチ会社のフォレスター社による前述の報告書によると、調査対象となったI&Oプロフェッショナルのうち82パーセントが、リリース管理、構成管理、および変更管理といった分野のうち少なくとも1つ以上で、自動化ソリューションをデプロイしたと回答しました。
チーム作りと文化の重要性を認識してください。信頼やコラボレーション精神を確固たるものにするには、開発者とIT運用担当者との間で動機や目標を同じにすることが重要です。たとえば、開発者、運用担当者、または両方に複数のプロジェクトに関する職能的な責任と動機(安定性を維持することまたは機能を迅速にデリバリすること、など)を与えるよりも、足並みを揃えて積極的にコラボレーションしているチームは、単一のプロジェクトに人材を配置し、プロジェクトの成功のあらゆる側面を総体的に測定しており、協力しながら効果的に作業に取り組む傾向があるようです。また、ツールを購入するのは簡単ですが、それだけではDevOpsプラクティスのメリットを語ることはできません。ツールは、協働と責任の共有に根差した文化哲学の文脈内で使用される必要があります。
障害になりそうな組織ダイナミクスを理解します。新しいプロセスやツールを配備すると、現在のプロセスが乱れ、既存の組織的な義務が、特にコンプライアンス、セキュリティ、および監査機能といった面で脅かされることが避けられません。これらの当事者が大局を受け入れ、意欲ある利害関係者になることが重要です。そうでなければ、善意から合理化されたDevOpsプラクティスが、人的な遅延に悩まされることになるかもしれません。トップダウンでの幹部からのサポートと複数チームでの取り組みが、これらの複雑な組織的ダイナミクスに対処するのに役立つかもしれません。事実、2015年のガートナー社による調査に回答した人の半分は、DevOpsを用いている自らの組織にとっての最大の課題として人的問題を挙げました。
インテグレーションのコストと複雑さの問題を認識してください。ソリューションを提供しているベンダーの数を考慮すると、DevOpsプラクティスの各側面に対処するためのソリューションを個別に購入することは容易です。しかし、こうして得たさまざまなツールをシームレスなエクスペリエンスへと統合しようとすると、多大なコストと複雑化が生じる結果となる可能性があります。統合型アプローチは、ベストプラクティスに根差した説得力のある意見を提供し、アプリケーションランタイムプラットフォームと一体化しながら、一方で組織固有のニーズに合わせた自動化を可能にする顕著な柔軟性を提供します。これにより前述の落とし穴を回避して、確固とした足場からスタートすることができます。
小規模から始めましょう。DevOpsプラクティスを構築するには、実験と改良が必要になる場合があります。だからこそ小規模から始めるべきなのです。有意義な結果を出すには、実際のアプリケーションではあっても、ビジネス成果がリスクにさらされるような規模や重要性を持たないものを使用してスタートします。
これまでの作業負荷を考慮してください。DevOpsは、新たな作業負荷のみに関わるものではありません。クラウドに向けて既存の作業負荷の最新化と移行を考慮しているなら、DevOpsの原則と自動化をどのようにライフサイクルに生かすかを検討してください。DevOpsは、リリースの頻度とデプロイの信頼性または安定性という点で、従来の作業負荷に大きなメリットをもたらすことでしょう。
DevOpsの理解は、旅のようなものです。DevOpsは実践哲学です。いったんチームとプラクティスが定義されても、それがずっと変わらないとは思わないでください。プラクティスの存在意義(ソフトウェアを迅速かつ確実に提供すること)を満たすには、作業負荷、要件、および運用の文脈が変化するごとに、プラクティスも成長し、進化する必要があります。