DevOps の基本: DevOps の原則を定義する

記事の見出しから求人票の職務内容欄まで、「DevOps」はここ 10 年いたるところで見聞きするホットなバズワードです。それには相応の理由があります。多くの場合、組織が DevOps の導入に成功すると、その組織ではソフトウェア開発速度の大幅な向上、信頼性の向上、製品のイテレーションの高速化、サービスの拡張を簡単に行えるようになります。

しかし、ルーツはソフトウェア開発であるにもかかわらず、DevOps は総合的なビジネス慣習であり、人、プロセス、文化的慣習、テクノロジーを組み合わせて、それまではサイロ化していたチームを一つにまとめ、スピード、価値、品質をソフトウェア開発のライフサイクル全体にもたらします。

これはつまり、多くの場合、汎用的なアプローチは存在しないという意味です。ただし、成功する DevOps の導入には共通のプラクティスと原則があります。

以下のガイドでは、これらのプラクティスと原則を紹介し、次の質問に答えます。

DevOps の主な目的は何ですか。
DevOps にはどのような基本原則がありますか。
DevOps のワークフローにはどのような主要なステージがありますか。
DevOps においてチームのメンバーはどのような役割を負いますか。
DevOps においてセキュリティとは何ですか。
DevOps にはどのようなベストプラクティスがありますか。
DevOps とアジャイルはどのように違いますか。

DevOps の主な目的

DevOps の主な目的は、価値を提供して、問題なくすぐ使用できる質の高いソフトウェアを迅速に生産することです。その際には、基になるインフラストラクチャ、ソフトウェアアーキテクチャ、エンジニアリングコードのリリースを、摩擦を最小限に抑えながら連携させます。

ソフトウェア業界では、組織はリリースの速度を取るか、製品の信頼性を取るかのどちらかだと考えられてきました。DevOps はその両方の実現を可能にし、そのために 2 つの革新的なアプローチを使用します。つまり、これまでサイロ化されていた開発チームと運用チームを連携させ、ソフトウェア開発ライフサイクル (SDLC) の全てのステージに自動化を組み込むのです。

DevOps の基本原則

2009 年に Patrick Debois が作り出した「DevOps」という言葉は、「development (開発)」と「operations (運用)」の組み合わせであり、そこには開発チームと運用チームの連携をより緊密にするという当初の観念が表れています。歴史的に、この 2 つのチームはそれぞれサイロの中で仕事をしてきました。開発者はコードを記述してソフトウェアを構築し、運用チームは品質保証テストを行い、基になるインフラストラクチャを担当してコードが適切にデプロイされるようにしていました。そのため、開発チームと運用チームが対立し、コードのデプロイが困難になることがよくありました。

Debois をはじめ Gene Kim や John Willis といった初期の DevOps リーダーはしばしば、DevOps の大まかな特徴として開発と運用のインテグレーションによってソフトウェアの開発プロセスとリリースプロセスを合理化する点を挙げましたが、今日 DevOps は、個々のチームを超えた総合的なビジネス慣習へと進化しています。

GitHub では DevOps を、開発、IT 運用およびセキュリティチームが連携し、SDLC を通じて構築、テスト、イテレーション、定期的なフィードバックを行うための、哲学と一連のプラクティスとして捉えています。

DevOps の導入方法は組織によってさまざまです。しかし、高い成果を上げている DevOps 環境はどれも次の基本原則に従っています。

コラボレーション

DevOps を成功させるためには、これまでサイロで互いに隔てられてきた 2 つのチーム、つまり運用と開発が緊密に連携しなければなりません。DevOps モデルのもと 3 つのチームを緊密に連携させることで、チーム間のコミュニケーションと協力を促し、アプリケーションやソフトウェアのスタックの開発、テスト、運用、デプロイ、モニタリング、イテレーションの能力を高めることを目指します。

バージョン管理

バージョン管理は DevOps にとっても、今日の多くのソフトウェア開発にとっても不可欠な要素です。バージョン管理システムは、ファイルの変更を自動的に記録し、以前のファイルバージョンの記録を保持するためのものです。

自動化

DevOps における自動化とは、一般的に、テクノロジーやスクリプトを活用し、基になるインフラストラクチャのメンテナンスやスケーリングを担当する者と中核的なソフトウェアの構築を担当する者との間にフィードバックループを作成することです。環境のスケーリングの支援からソフトウェアビルドの作成やテストのオーケストレーションまで、DevOps における自動化はさまざまな形態を取ることができます。

私たちのチームは、自分たち自身を自動化してより良い仕事ができるように常に模索しています。

Buzzfeed エンジニアリングディレクター、Andrew Mulholland

インクリメンタルリリース

インクリメンタルリリースは DevOps　プラクティスが成功するための柱であり、それまでの機能に基づき小さな変更や更新を迅速にリリースすることが特徴です。インクリメンタルリリースでは、アプリケーション全体を更新するのではなく、開発チームが小さな変更をメインのブランチにすばやく統合し、品質とセキュリティをテストして、エンドユーザーにリリースします。

オーケストレーション

オーケストレーションとは自動化されたタスクのセットを単一のワークフローに組み込んだものを指し、コンテナの管理、新しいウェブサーバーの立ち上げ、データベース項目の変更、ウェブアプリケーションのインテグレーションなど一連の機能を処理します。簡単に言えば、オーケストレーションは、アプリケーションを効率的に実行するために必要となるインフラストラクチャ要件の構成、管理、調整を支援します。

パイプライン

DevOps に関する会話では、「パイプライン」という言葉をかなり頻繁に耳にします。分かりやすく言えば、DevOps パイプラインとは、自動化やさまざまなツールを活用し、開発者がコードをテスト環境に迅速にデプロイできるようにするプロセスです。運用チームと開発チームはその後、セキュリティ問題、バグ、問題などがないかコードをテストしてから、本番環境にデプロイします。

継続的インテグレーション

継続的インテグレーション、略して CI は、開発者チームが自動ビルドおよびテストプロセスを通じて、コードを共有の中央リポジトリに頻繁にコミットするプラクティスです。小さなコード変更を継続的にメインのコードベースにコミットすることで、開発者はバグやエラーをより迅速に検出できます。またこのプラクティスは、ソフトウェア開発チームの異なるメンバーが加えた変更をより容易にマージできます。

継続的デリバリー

継続的デリバリーは、自動化を用いてソフトウェアのアップデートをエンドユーザーにリリースするプラクティスです。継続的デリバリーは、ソフトウェアを自動的に構築し、テストしてから一般使用向けにリリースできるように、常に継続的インテグレーションの後に行われます。継続的インテグレーションと継続的デリバリーとを合わせると、一般的な DevOps パイプラインの 3 分の 2 を占めます。重要なのは、継続的デリバリーモデルが自動化するのはデプロイまでのステージだということです。この時点で、人間が介入してソフトウェアをエンドユーザーにリリースする必要があります。

継続的デプロイ

継続的デプロイつまり CD は、完全な DevOps パイプラインの最後の部分であり、コードリリースのデプロイを自動化します。これは、本番運用パイプラインの全ての自動テストにコードが合格した場合、そのコードは直ちにエンドユーザーにリリースされるということです。継続的デプロイは、ソフトウェアリリースのオーケストレーションに人間が介入する必要性を決定的に排除することで、より迅速なリリースタイムラインを実現します。その結果、開発者はより即時的に実世界からフィードバックを受けることもできます。

継続的監視

継続的監視は、イシューのトラブルシューティングに用いたり、開発チームが将来の開発サイクルの参考にしたりバグの修正や問題のパッチに使用したりできる、自動プロセスやツールのセットです。

確立した継続的監視システムには通常、次の 4 つのコンポーネントが含まれます。

ログは、ビジネスの重要なコンポーネントに関する生データの継続的なストリームを提供します。
監視は、ログやメトリクスの生データについての情報を提供します。
アラートは、異常が発生すると積極的に通知したり、重要なデバッグ情報を提供したりします。
トレースはログを掘り下げ、本番環境においてアプリケーションの安定性やスケーラビリティに大きな影響を及ぼす可能性のあるアプリケーションのパフォーマンスや動作について、さらに深いレベルのインサイトを提供します。

フィードバック共有 (フィードバックループ)

フィードバック共有、またはフィードバックループは Gene Kim の画期的な著書「The Phoenix Project (The DevOps 逆転だ!)」で最初に定義された、一般的な DevOps 用語です。Kim は次のように述べています。「ほぼ全てのプロセス改善の取り組みの目標は、フィードバックループを短縮、増幅して必要な修正を継続的に行えるようにすることである」。簡単に言えば、フィードバックループとは、問題やバグが潜在していないかアプリケーションやインフラストラクチャのパフォーマンスを監視し、アプリケーション内でのエンドユーザーの活動を追跡するためのプロセスです。

DevOps ワークフローの主要なステージ

DevOps のライフサイクルの原点は、計画を事前に立て、アプリケーションとインフラストラクチャの要件を定義し、自動化できる SDLC の領域を特定し、共通の認識を確立するための協力的な方法を見つけることにあります。これは結果的に DevOps の目標、つまり価値を提供し、質の高いソフトウェアを開発してできる限り迅速にエンドユーザーに届けることにつながります。

成功する DevOps ワークフローの 8 つのステージ

1. 計画

一般的に、プロダクトマネージャーとエンジニアリングリードが協力してロードマップとスプリントを計画します。チームはカンバンボードなどのプロジェクト管理ツールを活用し、開発スケジュールを策定します。

GitHub Issues を使用してプロジェクトを計画する方法を見る >>

2. コーディング

計画の策定が完了すると、開発者はコードの構築を開始し、コードレビュー、コードのマージ、共有リポジトリでのコード管理など後続のタスクに取り組みます。

GitHub でコーディングする方法を見る >>

3. 構築

コードが開発されレビューされるのと並行して、エンジニアがこのコードを共有の集中型コードリポジトリでソースコードにマージします (継続的インテグレーション)。これは通常、コード変更をテストする継続的インテグレーションと、新しいコードコミットを追跡するバージョン管理ツールを使用して行われます。

GitHub でコードインテグレーションとアプリケーション構築の継続的インテグレーション/継続的デプロイを実現する方法を見る >>

4. テスト

構築プロセスでは、継続的テストを活用し、新しいコードの追加によってバグ、パフォーマンスの低下、セキュリティ上の欠陥などがソースコードで発生しないようにします。これは、新たなコードコミットのたびに一連の自動テストを実施することによって実現します。

GitHub を使用して継続的テストのパイプラインを構築する方法を見る >>

5. パッケージ化

アプリケーションの新しいイテレーションを開始する前に、チームはコードをデプロイ可能な構造にパッケージ化します。これには、npm、Maven、Nuget などのパッケージエコシステム経由で共有するために、再使用可能なコンポーネントを共有することも含まれる場合があります。さらに、ソフトウェア開発ライフサイクルを通じて作成される成果物にコードをパッケージ化し、最終チェックや成果物の保管のためにステージング環境にデプロイすることも含まれる場合があります。

GitHub の統合パッケージ化ソリューションについて知る >>

6. リリース

チームがアプリケーションの新しいイテレーションバージョンをエンドユーザーにリリースします。これには通常、リリースを自動化するツールやスクリプトと、変更が適切にデプロイされずロールバックが必要な場合に使用する変更管理ツールが含まれます。

GitHub でソフトウェアをリリースする方法を見る >>

7. 運用

SDLC の全てのステージで、DevOps 実行者は、アプリケーションを実行するのに必要なコアインフラストラクチャが正常に機能するよう徹底します。この作業には、テスト環境、ステージングまたはデプロイ前環境、デプロイ環境のセットアップも含まれます。
アプリケーションがエンドユーザーに使用されるようになると、コンテナやクラウドベースのサーバーなど、基になるインフラストラクチャが需要に応じてスケーリングできるようにする必要もあります。
実行者は通常、Infrastructure as code (IaC) ツールを活用し、基になるシステムがスケールアップやスケールダウンによってリアルタイムの需要を満たすようにします。また、継続的なセキュリティチェック、データのバックアップ、データベース管理など他の作業にも従事します。

GitHub がソフトウェア運用を実現するしくみを見る >>

8. 監視

DevOps 実行者はツールと自動化を組み合わせて実装し、ソフトウェアがエンドユーザーにリリースされた後に重点を置きながら、ソフトウェア開発ライフサイクル全体の継続的監視を実施します。継続的監視には、サービスのパフォーマンスの監視、セキュリティの監視、エンドユーザーエクスペリエンスの監視、インシデント管理などが含まれます。

GitHub が組織に高度な監視機能を提供するしくみを見る >>

効果的な DevOps ワークフローに欠かせない要素に、ワークフローの「継続性」、つまり常時稼働の確保があります。これは、ワークフローが継続的に繰り返されるようにするプロセスを設定するということです。もっと平たく言えば、DevOps ワークフローを確実に実践するということです。

DevOps チームの構成

DevOps で高い成果を上げている組織は、「DevOps チーム」の構築ではなく、DevOps の実践に重点を置いています。その際こうした組織は、共同作業を可能にする DevOps 環境を構築することを優先しています。サイロ化したインクリメンタルなプロジェクトではなく、エンドツーエンドの製品に焦点を当てた総合的な手法がチームをまたがって適用され、DevOps 環境を構築します。

効果的な DevOps 環境では、運用や IT からエンジニアリング、製品管理、ユーザーエクスペリエンス、デザインにいたるまで、全ての人が役割を担っています。優れた DevOps のプラクティスでは、個人の任務に基づきチームを分割するのではなく、より大きな組織のミッションにおいて個人がどのような役割を果たすかに重点が置かれます。

DevOps における役割は、一般的に次の 4 つの主要領域に分類されます。

計画: 計画の策定は、DevOps チームを十分に機能させるうえで欠かせません。通常、この役割を担うチームメンバーは、プロジェクトマネージャー、SCRUM リーダー、プロダクトマネージャー、運用リード、エンジニアリングリードなどです。これらのメンバーは、リソースの調整を支援し、コミュニケーションを促進し、開発スケジュールを設定し、全てのメンバーが共通の目標に向かって作業をしているか確認します。
開発: DevOps チームには、ジュニア開発者、シニア開発者、スタッフエンジニア、エンジニアリングディレクターや、さらに上のレベルのメンバーを含む、強力なコア開発要員が必ずいます。ここでの目標は、コードの開発、コミット、レビューおよびマージと、コードのリリースの両方です。
デリバリー: 成功する DevOps チームのもう一つの構成要素は、コードのインテグレーション、テスト、ステージング、デプロイを行う適切な CI/CD パイプラインを通じた、アプリケーションイテレーションの実現です。これは通常、中央 CI/CD パイプラインの構築、メンテナンス、監視、改善を担当するエンジニアリングリードやチームが担当します。さらに、このエンジニアリングリードまたはチームは通常、開発チームと運用チームが今後のリリース、既存の問題、デプロイのボトルネックを認識するように徹底します。
運用: 開発を除く DevOps チームの役割の中でおそらく最も重要な役割が、運用です。運用の実行者は、サーバースペースのオーケストレーション、コンテナ管理、アプリケーションパフォーマンスの監視、インシデント対応などを担当します。一般的な肩書きは、システム管理者、運用リード、システムアーキテクト、システムエンジニアなどです。

まとめ

DevOps はサイロの解体を原点とした組織変革であり、この改革には関係者全員の賛同が必要です。優れた DevOps プラクティスには特定の役割が存在するものの、DevOps で高い成果を上げる企業は、新たなサイロに DevOps チームを構築することはしません。

DevOps におけるセキュリティの役割

開発者が書くコード、運用チームが構築、オーケストレーション、スケーリング、監視を行うコアインフラストラクチャ、自動セキュリティテストなどの観点から、セキュリティは DevOps のライフサイクル全体において重要です。 DevOps の実行者は多くの場合、ツールを活用するか多数のスクリプトやワークフローオートメーションを作成して、アプリケーションやインフラストラクチャを継続的にテストし、セキュリティの脆弱性がないか確認します。このプラクティスは一般に DevSecOps と呼ばれ、開発や運用と同等にセキュリティを優先する DevOps の派生語です。

DevOps のベストプラクティス

要約: 標準的な DevOps のベストプラクティスには、チーム間のサイロを解消するための文化的な改革と、自動化、継続的インテグレーション、継続的デプロイ、継続的監視、継続的フィードバックに対する技術投資が含まれます。

Microsoft の「Enterprise DevOps Report」によれば、DevOps モデルへの移行に成功した組織はコードのリリース速度が向上し、他社の 4 倍から 5 倍のパフォーマンスを達成しています。この基準を満たす組織の数も、急速に増加しています。DORA の 2019 年度版「State of DevOps Report」によれば、2018 年から 2019 年にかけて優れた DevOps 組織の数は 185％増加しました。しかし、優れた DevOps 組織になるには抜本的な文化改革と適切なツールやテクノロジーが必要です。どうすれば、DevOps プラクティスへの適応と DevOps プラクティスの導入を成功させられるのでしょうか。

GitHub は、次の 8 つの共通のベストプラクティスを特定しました。

文化的な変革を覚悟する: DevOps にはツール、プロセス、人が必要ですが、文化的な転換を行い、これまでサイロ化されていたエンジニアリング、IT、運用の各チームが一体となって協力し合うよう促すことも必要です。これは、開発者、システム管理者、信頼性エンジニアといった専門家がそれぞれ独立したサイロの中で働いていた従来の技術プラクティスからの抜本的な改革です。サイロ化されたチームを一つにすることで、DevOps は、組織がアイディアをより迅速に市場に投入しながら、本番環境システムの信頼性とセキュリティを向上できるように支援します。
共同作業環境を奨励する: この文化的な変革では、DevOps プラクティスの異なる役割の間で起こる「私たち」対「彼ら」の対立を排除する、共同作業環境の構築を目指す必要があります。計画から開発、構築、デプロイまで、DevOps ライフサイクルの全てのステップが、コミュニケーションと実行の両方の観点において、協力的かつ部門横断的でなければなりません。また組織は、プロジェクトではなく製品を中心に据え、ミッションを最優先しながらエンドツーエンドのビジネスソリューションを構築するよう努めなければなりません。
セキュリティのシフトレトを組み込んで継続的インテグレーションと継続的デプロイ (CI/CD) を導入する: CI/CD は DevOps の根底をなすプラクティスであり、最も優れた CI/CD パイプラインには、コード品質の改善、バグの特定、コードのデプロイ、基になるアプリケーションインフラストラクチャの最適化や管理を目的として、ソフトウェア開発ライフサイクル全体にさまざまな自動テストが組み込まれています。さらに、SDLC の全てのステップにセキュリティが直接組み込まれています。業界ではこれを「シフトレフト」と呼びます。シフトレフトを実現するには、コードとその基になるインフラストラクチャをチェックするテストを、コードの最初のコミットから構築、リリースにいたるまでの全てのステージで自動化する必要があります。
DevOps パイプラインとアプリケーションを適切なメトリクスを使用して監視する: 優れた DevOps 実行者は、パイプラインとアプリケーションを継続的に監視して、追跡すべき主要なパフォーマンスとセキュリティのメトリクスを特定します。こうしたメトリクスには、ランタイム、速度、故障率、ユーザーエクスペリエンス、基になるコードやインフラストラクチャのセキュリティ上の欠陥 (例: データベースの保護) などが含まれます。実行者は多くの場合、ツール、自動テスト、常時ログ、アラートシステムを組み合わせて活用し、デプロイの頻度、アプリケーションの安定性、システムセキュリティ、検出時間などを監視します。
作業に適したツールを使用する: バージョン管理や継続的インテグレーション/継続的デプロイから infrastructure as code (IaC) やコンテナ管理にいたるまで、DevOps にはツール導入が不可欠です。作業に適したツールは組織の固有のニーズや好みによって異なります。また、中核的なソフトウェアホスティングプラットフォームに備わった、ツールのエコシステムとの統合機能によっても異なります。
モノリシックアーキテクチャからマイクロサービスアーキテクチャに切り替える: ここ 15 年で、複雑化する Web ベースやクラウドベースのアプリケーションに対応すべくマイクロサービスへの移行が進んでいます。

マイクロサービスアーキテクチャは、基になるインフラストラクチャが単一のサービスで構成されている、つまりアプリケーションの一部に対する需要が急増した場合、それに対応するためにインフラストラクチャ全体をスケーリングしなければならないモノリシックアプリケーションアーキテクチャとは対照的です。モノリシックアーキテクチャは、アプリケーションの一部が更新されるとコードベース全体を再度デプロイしなければならないため、イテレーションの実行もより困難です。

マイクロサービスアーキテクチャはこうした問題を、個別のインフラストラクチャコンポーネントを使用して個々のアプリケーションプロセスを実行することで解決します。その結果、コードベース全体を再デプロイせずに、アプリケーションの個々のコンポーネントでイテレーションを行うことのほか、アプリケーションの一部を個別にスケーリングしてリアルタイムの需要に応えることも容易になります。
継続的にフィードバックを収集する: 継続的フィードバックは、信頼性の高いソフトウェアの構築、マージ、テスト、イテレーション、リリースに必要となる重要な情報を DevOps 実行者に提供します。特定の DevOps プラクティスにおける各役割にとって、恩恵のある情報はそれぞれ異なります。開発者は、コードテストのレポート、運用環境でのエラー、セキュリティの脆弱性についてのアラートをリアルタイムで受け取る必要がありますが、運用担当者はシステムの安定性、サービス需要、障害点などについての情報を必要としています。最終目標は、組織やチームにとって重要なメトリクスを特定して追跡し、SDLC を改善することです。

DevOps とアジャイルの違い

面白いことに、2010 年代の初め、DevOps はアジャイル開発の第 2 の 10 年と呼ばれ、多くの人からアジャイル手法の当然の後継と見なされていました。

それにもかかわらず、DevOps とアジャイル開発は同じではありません。しかし、DevOps がアジャイル手法を基盤に構築され、アジャイル手法を活用していることは事実であるため、この 2 つのプラクティスはしばしば混同されてしまうのです。

基本的にアジャイル開発手法では、大規模なソフトウェア開発プロジェクトを、チームが迅速に構築し、テストし、フィードバックを収集し、次のイテレーションを作成できるような小規模な作業に分割することを目指します。

一方 DevOps 手法では、基本的に、これまでサイロ化されていた大規模なチーム (開発と運用) を統合し、より迅速なソフトウェア開発とリリースサイクルを実現することを目指します。

しかし、最も大きな違いは、DevOps がエンドツーエンドのソフトウェアソリューションの迅速な構築に焦点を当てた、全社的な戦略だという点です。それに対しアジャイル手法では、多くの場合、機能的なソフトウェアリリースにのみ重点が置かれます。

GitHub で DevOps プラクティスを構築する

GitHub は統合型のプラットフォームで、アイディアから計画、運用まで、焦点を絞ったデベロッパーエクスペリエンスと、強力なフルマネージド型の開発、自動化、テストインフラストラクチャを組み合わせて企業を支援します。

料金プランを比較する >

DevOps ソリューションを比較する >

GitHub は、開発を加速させるという当社の長年の取り組みを、コミュニケーションの壁を取り除き、フィードバックループを短縮し、できる限りタスクを自動化することで支援してくれています。

ViacomCBS、システムエンジニアリング担当ディレクター、Mike Artis 氏