DevOpsのテキスト研修
DevOpsでITの課題をどう解決するか
継続的にデプロイする
創業直後のスタートアップからFortune 100の企業まで、さまざまな規模で多種多様なソフトウェア製品やサービスを扱う企業が実証しています。DevOpsでは、小規模で独立し、自己完結できるチームが、毎日何十回も本番環境にデプロイします。設計、ビルド、デリバリー、テストは、本番に近い環境で行います。ほかの人が寝静まった深夜に3か月に一度だけ本番システムにコードをリリースする必要はありません。顧客や市場がソフトウェアを利用し、その価値を受け取っている間も、通常の勤務時間中に、1日に何度もコードをリリースできます。
DevOpsでは、ごく小さな機能を頻繁に提供できます。さらに、ダークローンチの手法を使い、非常に大規模な機能を小さな部分に分けて頻繁に本番環境に届けることもできます。設定で大きな機能を有効にするまで、各部分は本番環境で休止状態（無効）になります。この小さな工夫だけでも、コードを一斉に展開して既存の本番システムに予測できない悪影響が出たり、組織で混乱や責任のなすり合いが起きたりする事態を避け、チームの生活の質を大きく改善できます。
組織のミッションを軸にチームを編成する
競合より大きな使命を掲げて市場に応えるため、IT部門では、社内外の顧客に提供する製品、サービス、ケイパビリティ、マイクロサービスを軸に、長期的に活動するチームを編成します。プロジェクトが終わるとすぐに、あるいは終わる前に解散する一時的なチームから、継続して責任を担える形に移行します。
一時的なプロジェクトチームでは、個々のメンバーは自分のプロジェクトが組織の大きな使命の中でどこに位置するかを知る機会が少なく、自分の貢献に責任を持ちにくいうえ、仕事への十分なフィードバックも得られません。データベース開発、フロントエンド設計、翻訳などの専門分野ごとに、複数のプロジェクトから絶えず仕事が割り振られ、作業は何度も中断されます。
長期的なチームは、自分たちの仕事と、その処理能力によって支えられるITと事業の成果に進んで責任を持ちます。組織の大きな使命における自分たちの貢献の位置づけと、その重要性をよく理解しています。
事業目標を達成するシステムを作る
顧客にサービスを提供し、組織の使命を果たすことに対して報酬を受け取っていると、あなたもチームも理解しています。だからこそ、組織と顧客のすべての関係者の時間やリソースを大切にします。長期プロジェクトに着手する前に、ITソリューションに期待する事業価値を試し、検証します。構築しようとしているものを、模型、試作品、A/Bテストの複数案、簡易版などで顧客に示します。反応とフィードバックを測定、記録し、製品やサービスをどう調整すればよいか、そもそも顧客に気に入ってもらえるかを確かめます。
感触が良いというだけで製品に機能を追加しません。アイデアを試し、組織のリソースを投じて構築するものが、利益の向上と競合との差別化に貢献する可能性が高いことを、具体的で提示でき、再現可能な証拠で確かめます。
品質と監視を最初から組み込む
ソフトウェアのデリバリーと運用のライフサイクル全体に、迅速で信頼性が高く、広く伝わるフィードバックループを設けます。品質は特定のチームだけが担うものではないため、誰もが品質を作り込みます。仕事が適切にできたかを確かめるために他チームのフィードバックを待ったり、本番環境へのデプロイを他の人に許可してもらったりする必要はありません。チームを信頼し、設計、コード、テスト、インフラをピアレビューで確かめます。
測定やテストが可能なすべての機能に、自動テストと監視（テレメトリ）を組み込みます。時間をかけてコードを書き、届ける価値のある機能には、継続的で信頼性が高く、速く一貫した自動テストを行う価値があります。また、機能によって得られる効果が当初の目的に合っているか確かめるため、継続的な監視とソフトウェアに組み込んだ分析機能も必要です。本番と本番以外のすべての環境で行います。
コードリポジトリにチェックインするたびに、運用環境を自動で調整、再構成し、必要なら再構築します。影響を受けるアプリケーションを自動で再ビルドし、最後にすべての自動テストを実行して、既存機能と今回のチェックインの目的を検証します。検証に成功すると、同じ変更が本番環境にも自動で適用されます。
アプリケーションに組み込んだ分析機能とテレメトリが、ソフトウェアと運用環境の重要なイベントを継続的に監視、記録します。注文数、ログイン数、CPU使用率、RAM使用量、CPU負荷、エラー件数、データベースクエリの長さなどの主要指標は、常に記録され、リアルタイムで表示されます。チームはデプロイによる悪影響を数分、場合によっては数秒で発見できます。仕事をすばやく進めるうえで、短いフィードバックループが欠かせない理由です。
エラーから学び、周りに伝える
エラーが起きたら、落ち着いて自信を持って解決します。自動テストとテレメトリで観測した科学的な証拠を頼りに、インシデントの根本原因を特定します。問題を解決した後で、足りなかったテストケースやテレメトリに気づいたら、修正と一緒にコードリポジトリに追加します。
複雑なシステムについて、たった一人ですべてを知り、予測することはできません。そのため組織では、エラーを厄介な不意打ちと捉えず、製品やサービスが成熟していく過程の一部と見なします。エラーは学び、成長する機会であり、個人と組織の両方に新たな学びをもたらします。
誰も責めない事後検証を行うと、インシデントの根本原因をより的確に把握し、同じエラーや類似のエラーを防ぐ方法を見つけられます。インシデントをきっかけに、チームとソフトウェアから得た局所的な学びを、組織の誰もが利用できる知識として蓄積できます。
あなたとチームはこのエラーで処罰されることはなく、インシデント後に学んだことを共有したことが評価されます。その貢献のおかげで、組織内の多くのチームが将来同じようなインシデントを避ける方法を知ることができます。
事業が拡大してもチームはさらに力を発揮する
開発者が1人から1,000人に増える一般的な組織を考えてみましょう。小規模なとき、開発者は継続的にコードをビルドして本番環境にデプロイしていました。しかし、規模が大きくなると組織階層や事務手続きが増え、ミスを恐れるようになります。本番環境にコードをデプロイするための調整やコミュニケーションの負担も増します。このため、開発者一人あたりの1日の平均コードデプロイ回数は、組織が大きくなるにつれて、通常は減少し、良くても横ばいになります。
DevOpsで高い成果を上げる企業は違います。開発者が増えると、開発者一人あたりの1日の平均コードデプロイ回数も増やすことに成功しています。Google、Amazon、Facebook、Netflix、Appleなどは、適切なソフトウェアアーキテクチャ、チーム、ミッション、リーダーシップ、文化があれば可能だと実証しています。次に高い成果を上げるDevOps組織になるのは、あなたの組織かもしれません。
出典の図では、チームの規模が拡大するにつれ、開発者一人あたりの1日のデプロイ回数がどれだけ増えるかを比較しています。
出典の図を見る ↗まとめ
DevOpsで高い成果を上げる組織は、次の点で競合を上回っています。
- コードのデプロイ頻度が46倍。
- コミットからデプロイまでのリードタイムが440分の1。
- ダウンタイムからの平均復旧時間が96分の1。
- 変更失敗率が5分の1（変更が失敗する確率が5分の1）。
- 生産性とスループットが向上。
- コードと運用の信頼性が向上。
- 組織の業績と顧客満足度が向上。
- 市場浸透率、市場シェア、組織の収益性が向上（達成する可能性が2倍）。
- 時価総額の伸びが向上。
デプロイ頻度、リードタイム、復旧時間、変更失敗率を比較します。
出典の図を見る ↗