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


DevOpsでは、ソフトウェアリリースのサイクルの短縮と確実性の改善を目指し、テスト、パッケージング、およびデプロイにおけるコラボレーションを重視します。

DevOpsが重要である理由

開発期間の短縮

ソフトウェア駆動の世の中では、ソフトウェアの構築とリリースを迅速に行うことで、顧客のニーズを知り、競争に打ち勝つことが成功の鍵となります。現在のエンタープライズアプリケーションは、分散されたコンポーネントが複雑に相互依存していますが、成熟したDevOps環境では、コミュニケーションの不足や遅延を回避しながら、開発者とIT運用担当者両方の知識を合わせることで、合理的なソフトウェアデリバリを実現することができます。『2016 State of DevOps Report(DevOpsの状況に関する報告書)』によると、DevOpsを実践している企業は、デプロイの頻度が(平均で)200倍多く、リードタイム(コードのデプロイを意図した時からコードが実稼働環境で使用されるまでの時間)は2555分の1だそうです。他の産業研究でも似たような知見が示されており、下に示すガートナー社のチャートでは、DevOpsアプローチへの移行に伴うさらに多くのメリットが列挙されています。


問題:次の結果のうち、DevOpsがあなたの組織にもたらしたものはどれですか。

回答者:n=95、DevOpsを実践しているガートナーリサーチサークルのメンバー

[ソース: Gartner; Five Questions I&O Leaders Should Ask Before Funding a DevOps Initiative; October 2016]

DevOps導入の結果




リスクの低減とデプロイの円滑化

最新アプリケーションの開発の調整と管理、デプロイ、規模の決定、セキュリティ保護、パッチ適用、高可用性といった事柄は複雑なもので、不具合の原因となり得る要素ばかりです。DevOpsプラクティスは、協働的な文化と、パッケージング、デプロイ、監視、および管理の自動化から成り、新規コードのプッシュと実稼働環境のアップデートに一貫性とスピードをもたらします。継続的学習と相まって、DevOpsチームは問題の原因のほとんどを特定、排除し、より堅牢で、合理的で、反復可能で、成熟したリリースプロセスを確立することで、ソフトウェアのデプロイを問題なく確実に行うことができます。


より迅速な回復

実稼働環境でコードが破損した場合、またはダウンタイムの原因となった場合でも、DevOpsプラクティスはすばやく診断し、回復させることができます。大幅な自動化や監視がリリースプロセスや管理プロセスの大部分を加速させることにより、DevOpsチームはすばやく協働して不具合の元を追跡、特定し、変更のロールバックや問題の修正を行うことができます。事実、『2016 State of DevOps Report(DevOpsの状況に関する報告書)』によると、前述のような迅速で構造化された対応により、DevOpsを実践している組織では実稼働での予期せぬ問題から回復までの平均速度が24倍で、変更の失敗率は3分の1だと報告しています。


顧客満足度とプロダクト/マーケットフィットの向上

機能やバグフィックスを迅速かつ確実にリリースすることは、反応性が向上して顧客満足度が向上するだけでなく、フィードバックが迅速に得られ、顧客が最も求めている機能により早く集中できることにもつながります。DevOpsプラクティスは、このような継続的なデリバリと短いサイクルタイムの中核を成すものです。開発者とIT運用担当者との間に継続的で緊密なコラボレーションがなければ、最新で、分散された本番用ソフトウェア機能の複雑さ、開発、テスト、およびデリバリの管理を、すばやいペースで着実に実行することは不可能です。


DevOpsと従来のアプローチの比較

DevOpsは、ソフトウェア組織に従来と異なる考え方と新しいプロセスをもたらします。次の表は、DevOpsを実践している組織と、従来型のアプローチを用いている組織の違いを示します。


大きな違い:DevOpsと従来のアプローチの比較
DevOpsプラクティス:
従来のアプローチ:
コラボレーション主義。 DevOpsの成功は、ソフトウェアを迅速かつ確実に開発し、デリバリすることを目指して、ソフトウェア開発者とIT運用チームが良好かつ継続的な形で緊密に協働できるかどうかによって左右される。 サイロ駆動。 従来のアプローチは、「壁越しに投げる」形のコラボレーションに依存しており、実稼働環境でソフトウェアのデプロイと管理を行うIT運用担当者は、それを開発したチームから最小限の支援や知見しか得ることができない。
構造化され、大部分が(またはすべてが)自動化されている。DevOpsプラクティスでは、開発環境で機能していたことが、実稼働環境でも確実に機能するよう、環境のプロビジョニングと構成を自動化し、スピード、一貫性、および反復性をもたらしている。構造化されたアプローチでは、反復可能な自動化がロールバックとリカバリを容易にするため、障害復旧が加速される。 雪の結晶型でほとんどが手動。 従来のアプローチは、インフラストラクチャのプロビジョニングと構成を実行するにあたり、「雪の結晶」のようにそれぞれが異なる構成のサーバーを用いて、スクリプトプロセスと手動プロセスを臨機応変に組み合わせるやり方に依存している。このことが、正確性、確実な反復性、迅速性を得ることを難しくしている。このようなアプローチでは、構成パリティによって開発および実稼働インフラストラクチャを迅速かつ一貫してプロビジョニングすることができないことに起因して、数多くの問題に直面する可能性がある。
セルフサービス主義。 DevOps駆動の組織は、協働と自動化のための枠組みを確立することで、開発者やIT運用担当者が互いの行く手を阻害することなく、独立的に行動することを可能にする(開発者が自動化を通じて開発/テスト環境を迅速にプロビジョニングできるということは、IT運用担当者による手動でのプロビジョニングが不要であることを意味する)。 「ITチケット」主義。従来のエンタープライズアプローチの場合、IT運用担当者はITチケットの管理コストをやりくりし、簡単に自動化できる反復的で複雑なプロビジョニングや構成を手動で実行する必要がある。このことは、プロビジョニング、デプロイ、規模の拡大縮小、他のソフトウェアデリバリ、管理作業に大幅な複雑化と遅延をもたらす。
ビジネス中心。 DevOps組織は、協働してビジネスを成功させることに集中している。従って、ソフトウェアデリバリの成功に向けて責任を共有することを重視する。 職務重視。 従来のアプローチの場合、開発チームやIT運用チームは自分の職務の遂行に集中し、全体の成功に向けたつながりや責任感が希薄である。結果として、問題や障害が生じると、責任のなすり合いや組織的な摩擦が多くなる。
変更を想定した設計。 DevOpsプラクティスは、自動化、反復、迅速性を実現できるよう設計されており、頻繁な変更に対処でき、不具合からもすばやく復旧できるなど、速い進行に適したつくりになっている。 変化を嫌う。 従来のアプローチの場合、中断やすばやく復旧できなくなることを恐れて、実稼働環境での変更を避けようとする。変更やアップデートを最小限に抑えようとし、組織に対して暗に慎重さを求める。認証を頻繁に変更するため、短期間しか使用できない。