9.0 第9部の導入: 運用、信頼性、オブザーバビリティ

ソフトウェアを築くことは、仕事の半分にすぎません。それを良好に動かし続けることがもう半分で、ほとんどの組織にとって、それは終わることのない半分です。この部は、本番でシステムを運用することについてです。「十分に信頼できる」とは何かを定義し、そこへ向けてエンジニアリングします。予期しないものをデバッグできるほど複雑なシステムの内側を見通し、物事が壊れたときに一貫して対応し、そのすべてを、お金を浪費したり炭素を燃やしたりせずに行うことを学びます。これらは、デモで動くシステムを、人々が何年も頼れるサービスに変える規律です。

大きなチームにとって、これらの関心事は背景の活動でなくなり、それ自体が一つのシステムになります。現代のプラットフォームは、数百のサービス、多くのチーム、複数のリージョン、サードパーティの依存関係にまたがり、誰一人としてその全体を頭に保てません。規模は、信頼性の価値と、それを誤るコストの両方を引き上げます。1時間の停止は、失われた収益と侵食された信頼になります。曖昧なアラート一つが、数千のページングになります。クラウドの無駄の数ポイントが、数百万ドルになります。この規模の運用には、共有の言語、共有のテレメトリ、共有の構造が必要で、誰も完全には所有しないシステムに、多くの人が一貫して行動できるようにします。

企業と政府の文脈は、あらゆる賭け金を引き上げます。規制対象の産業は、法的な可用性の約束、監査の要件、義務づけられた停止の報告を負います。市民向けのサービスは、公表されたパフォーマンスの目標を満たすことを示せなければならず、単に落ちることはできません。公共部門の予算は、強まる持続可能性とネットゼロの義務のもとで、納税者のお金を使います。これらの設定では、運用、信頼性、オブザーバビリティ(外部の出力からシステムの内部状態を理解すること)は、運用上の衛生以上のものです。それらは、説明責任、セキュリティ、制度への信頼の道具です。

この部の章

9.1 サイト信頼性エンジニアリング: SLI(サービスレベル指標)、SLO(サービスレベル目標)、SLA(サービスレベル契約)で信頼性を定義し、エラーバジェット(完全な信頼性からの許容される不足分)で速度と安定のバランスをとり、自動化を通じて苦役(反復的で自動化可能な手作業の運用の仕事)を容赦なく減らし、規模が驚きにならないよう容量を予測することで、運用にソフトウェアエンジニアリングを適用します。
9.2 オブザーバビリティとテレメトリ: 既知の失敗を監視することから、システムが発するテレメトリ(共有の識別子で相関づけられたメトリクス、ログ、トレース、イベント)に築かれた本物のオブザーバビリティへ進み、ベンダー中立のOpenTelemetry(テレメトリを生成し収集するためのオープン標準)に標準化し、対処可能でユーザーから見える問題にだけ人間を呼び出すアラートを設計します。
9.3 インシデント管理: 持続可能なオンコールのローテーション、定義された役割と深刻度を備えた明確なインシデント指揮の構造(対応を調整するための定義された階層)、誠実な利害関係者とのコミュニケーション、是正の行動を完了まで駆動する、責めないポストモーテム(個人の過失ではなく構造的な原因を狙うインシデントのレビュー)を通じて、障害を検知し、調整し、解決し、そこから学びます。
9.4 コスト、持続可能性、グリーンソフトウェア: FinOps(クラウド支出の財務運用)の可視性と最適化、カーボンを意識した(電力がよりクリーンなときと場所に合わせて仕事をスケジュールする)省エネルギーの設計、継続的な適正サイズ化、コスト、パフォーマンス、信頼性の三角形にわたる意図したトレードオフを通じて、本番に財務と環境の説明責任をもたらします。
9.5 災害復旧と事業継続: 事業影響分析から復旧時間と復旧時点の目標を設定し、テストされた不変のバックアップを保ち、コストと速度の幅にわたって復旧の戦略を選び、フェイルオーバーをリハーサルして、復旧が願うものではなく証明されたものになるようにすることで、悪い日を生き延びる備えをします。
9.6 カオスエンジニアリングとレジリエンステスト: 定常状態を定義し、仮説を立て、封じ込められた影響範囲で現実的な障害を注入することで、システムが乱れた条件に耐えるという確信を築き、ゲームデーから継続的で自動化されたレジリエンスの検証へと育てます。
9.7 容量計画と需要予測: 計算、ストレージ、ネットワークの供給を、意図した余裕を持たせて予測された需要に合わせ、飽和の近くでレイテンシが爆発しないよう、負荷テストと待ち行列理論の推論を使い、コストと信頼性のバランスをとります。
9.8 オンコールと運用の備え: サービスを動かす人々が燃え尽きるのではなく成功できるよう、対処可能なアラート、明確なエスカレーション、本番稼働準備のレビューとランブックを備えた、人道的で持続可能なオンコールを設計します。

これらの章の相互関係

これらの章は、緊密な運用のループを形成します。サイトリライアビリティエンジニアリング(9.1章)が目標を設定します。SLIとSLOが信頼できるとは何かを定義し、エラーバジェットがいつ速度を落とすかを決めます。オブザーバビリティ(9.2章)は、それらの目標を測定して守る方法です。SLOのバーンレートのアラートは、よく構造化されたテレメトリがあって初めて機能し、それは対応者が失敗の背後の「なぜ」を見つける方法でもあります。インシデント管理(9.3章)は、エラーバジェットを計画より速く使ったときに起こることです。9.2章のアラートが発火し、指揮の構造が動き、結果として得られる責めないポストモーテムが、持続的な改善を信頼性と計装の仕事にフィードバックします。コストと持続可能性(9.4章)が輪を閉じます。それらは、あらゆる所を金メッキするのではなく、9.1章で定義したSLOに合わせて信頼性とパフォーマンスをプロビジョニングするよう主張するので、コスト、パフォーマンス、信頼性の三角形は、恐れによってではなく意図してバランスがとられます。

つながりは、この部をはるかに超えて広がります。ここでの信頼性の所有は、1.2章のチームトポロジーに形づくられ、8.1章と8.4章のパイプラインとプラットフォームエンジニアリングを通じて届けられます。安全で頻繁なデプロイは、規模で運用するための前提条件だからです。インシデント対応を誠実にする、責めない学び志向の文化は1.1章に始まり、これらの実践の下にある信頼性とレジリエンスのパターンは、3.3章と3.5章のアーキテクチャに根ざしています。最後に、これらの規律が生む証拠、監査に即応できるテレメトリからポストモーテム、コストの帰属まで、は、10.2章と11.3章のリスク、保証、ガバナンスの仕事に直接供給します。うまく運用されれば、この部のシステムは、コードが書かれたずっと後まで、組織が約束を守り続けられるようにするものです。