6.0 第6部への導入:信頼性、運用、セキュリティの指標

第2部は、変更がコミットから本番環境にどう至るかをカバーしました。この部は、それが本番環境で稼働し始めた後、無期限に、チームが完全には制御できない実際の条件の下で何が起きるかをカバーします。信頼性、運用、セキュリティの指標は、ソフトウェアエンジニアリングの約束が持続する現実と出会う場所です。「このデプロイは成功したか」ではなく、「このシステムは、次のインシデントのためだけでなく何年も持続可能でなければならないオンコールのローテーションの負担の下で、夜な夜な、負荷の下で、攻撃の下で、動き続けるか」です。

この部の4つのトピックは意図的な弧を描いています。サービスレベルの指標と目標(トピック6.1)は、この部の他のすべてが依存する語彙と目標設定の規律を確立します。インシデントの指標(トピック6.2)は、その目標が外れたときに何が起きるかを測定します。オンコールと容量の指標(トピック6.3)は、その目標を維持し続けることの人的およびインフラ的なコストを測定します。セキュリティと脆弱性の指標(トピック6.4)は、同じ信頼性の規律を、異なるが密接に関連するリスク、「これは自然に失敗するか」ではなく「誰かが意図的にそれを失敗させるか」に拡張します。これら4つのトピックすべては、本書の中心的な規律を共有しています。指標に名前をつけ、それがどのようにゲーミングされるかに名前をつけ、そのゲーミングを捕捉するガードレールと組み合わせることです。

大規模なチームにとって、この部の指標は、エンジニアリングの約束が契約的になり、政府の文脈では時に法的になる場所です。企業組織は、トピック6.1が導入する指標に対してサービスレベル契約を書き、それを外した場合には本物の金銭的な罰則を伴います。政府組織は、信頼性やセキュリティの失敗が単一の企業の貸借対照表をはるかに超える結果をもたらす重要な公共インフラを運用しています。この部はその重さを一貫して真剣に扱います。

この部のトピック

• 6.1 サービスレベルの指標、目標、エラーバジェット: サイト信頼性エンジニアリングの基盤となる語彙と目標設定の規律、そしてエラーバジェットが信頼性を、到達不可能な絶対値ではなく、使うことができ管理可能なリソースに変える方法。
• 6.2 インシデントの指標:検知、対応、復旧: 組織が失敗にどれだけ速く気づき、対応し、解決するかを測定すること、そしてその測定を正直に保つ非難のない規律。
• 6.3 オンコール、容量、運用負荷の指標: 信頼性を維持することの人的およびインフラ的なコスト、そしてなぜ持続不可能なオンコールの負担が最終的にそれ自体が信頼性の問題として現れるか。
• 6.4 セキュリティと脆弱性管理の指標: 同じ規律のあるガードレールと組み合わせたアプローチをセキュリティのリスクに拡張すること、脆弱性の発見から是正まで。

これらのトピックがどう相互に関連するか

トピック6.1は、この部の後のすべてのトピックが築く基盤を設定します。明確なサービスレベル目標なしには、「このインシデントはどれだけ悪かったか」(トピック6.2)と「私たちのオンコールの負荷は持続可能か」(トピック6.3)は、それに対して測定するための共有された基準点を持ちません。トピック6.2のインシデントの指標は、ある本物の意味で、トピック6.1が導入するエラーバジェットの支出の記録です。トピック6.3は、その支出を予算内に収め続ける責任を持つ人的システムの持続可能性を測定します。そしてトピック6.4は、同じ目標と予算の考え方を、測定されないまま放置されると積極的にではなく反応的に、インシデントの後にのみ注目を受ける傾向があるセキュリティ態勢に適用します。

この部は第2部に直接つながっています。DORAの変更失敗率と失敗したデプロイの復旧時間(どちらもトピック2.10でカバーされています)は、それぞれ、この部のインシデントの指標に対する先行指標とその一例です。それはまた第8部にも先に向かってつながっています。ダッシュボードとプログラムの成熟度の指針は、抽象的な目標(信頼性、セキュリティ)を、チームが実際に日々管理できる具体的で追跡可能な非絶対的な目標に変える実例として、この部のエラーバジェットモデルに大きく依拠しています。