9.1 サイト信頼性エンジニアリング

概要と動機

サイトリライアビリティエンジニアリング(SRE)は、ソフトウェアエンジニアリングの実践を、本番システムの運用に適用します。運用を、開発から切り離された、手作業でチケット駆動の仕事として扱う代わりに、SREは信頼性を、コード、測定、明確なサービス目標で解くエンジニアリングの問題として扱います。Googleによって広められたが今では広く普及している中核の考えは単純です。システムを動かし続ける人々は、同じ障害に何度も手作業で火消しするのではなく、時間のほとんどを、自動化を築きシステムを改善することに費やすべきだ、ということです。

大きなチームにとって、これが重要なのは、規模が信頼性の価値とそれを誤るコストの両方を引き上げるからです。一つのサービスが数百万のユーザーや数千の内部の利用者を支えるとき、1時間の停止は、失われた収益、逃した取引、侵食された信頼を意味します。少数のサーバーならうまく行く手作業の運用は、数百のサービスと継続的デプロイのもとでは崩れます。SREは、信頼性の共有の言語、機能を出荷することと安定を保つことのトレードオフを明示する方法、そして多くのチームにわたってその線を一貫して保つ方法を与えます。

企業と政府の文脈は、さらに重みを加えます。銀行、医療、公共サービスのような規制対象の産業は、しばしば法的あるいは契約上の可用性の約束、監査の要件、市民や安全に影響する停止へのほとんどない許容度を負います。政府のデジタルサービスは、信頼性の目標とパフォーマンスのデータをますます公開しています。SREは、「十分に信頼できる」とは何かを定義し、誠実に測定し、リーダーシップと監督機関に対してエンジニアリングの優先事項を、意見ではなくデータで擁護する、厳密で証拠に基づく方法を与えます。

関連項目: 9.2章(オブザーバビリティと監視)、9.3章(インシデント管理)、3.5章(スケーラビリティ、パフォーマンス、レジリエンス)。

主要原則

信頼性は最も重要な機能である。 動かないシステムは、どれだけ機能があっても価値がありませんが、完全な信頼性は達成できず、そのコストに見合いもしません。
測定可能な目標で信頼性を定義する。 サービスレベル指標(SLI)、目標(SLO)、契約(SLA)が、曖昧な期待を、誰もが合意できる数字に変えます。
100パーセントは間違った目標である。 ユーザーは非常に信頼できるシステムと完全に信頼できるシステムの違いを見分けられないので、「十分に信頼できる」を目指し、残りのバジェットを速度に使います。
エラーバジェットはインセンティブを揃える。 SLOと100パーセントの間の隙間は、開発者と運用者が共有するリスクのバジェットで、議論を算術に置き換えます。
苦役は敵である。 反復的で、手作業で、自動化可能な運用の仕事は、測定し、上限を設け、体系的に排除すべきです。
意図して自動化する。 自動化は、小さなチームが大きなシステムを運用する方法で、それへの投資は第一級のエンジニアリング活動です。
責めない学び。 失敗は、個人を罰するためではなく、システムとプロセスを改善する機会として扱われます。

推奨事項

SLI、SLO、SLAを意図して定義する

ユーザーの視点から始めます。サービスレベル指標は、300ミリ秒未満で処理されたリクエストの割合や、成功した応答の割合のような、サービスの挙動の定量的な尺度です。ユーザーの満足を本当に反映する少数のSLIを選びます。可用性、レイテンシ、正しさ、鮮度が一般的です。サービスレベル目標は、SLIの目標値あるいは範囲で、たとえば「28日間のローリング窓でリクエストの99.9パーセントが成功する」。サービスレベル契約は、約束された水準に結果(返金、ペナルティ)が付いた契約です。約束を破る前に警告が得られるよう、SLOをSLAより厳しく保ちます。SLOを公開し、四半期ごとにレビューし、学ぶにつれて締めたり緩めたりする生きた文書として扱います。

エラーバジェットを採用して徹底する

エラーバジェットは100%からSLOを引いたものです。SLOが99.9パーセントなら、バジェットは窓ごとに0.1パーセントの不信頼性で、月におよそ43分です。計画されたリスク、つまり攻撃的なリリース、実験、管理された失敗のテストに使います。バジェットが健全なとき、チームは速く出荷できます。尽きたとき、方針は自動的に優先事項を信頼性の仕事へ移し、システムが回復するまで危険な変更を一時停止すべきです。エラーバジェットの力は、事前に合意するので、停止の瞬間から感情と政治を取り除くことです。

苦役を測定して減らす

苦役とは、手作業で、反復的で、自動化可能で、戦術的で、システムとともに増える運用の仕事です。SREの時間のうち苦役に費やす割合を追跡し、通常およそ50パーセントという上限を設けて、エンジニアリングの時間の少なくとも半分が持続的な改善に向かうようにします。苦役削減のプロジェクトの積み残しを保ち、頻度かけるコストで優先順位づけし、繰り返されるタスクを葬ることを、新しい機能を出荷することと同じくらい祝います。自動化の義務はこれを明示的にします。決まった回数より多く行う手作業の手順は、自動化あるいはセルフサービスのツールの候補になります。

容量を計画して需要を予測する

過去の傾向、計画されたローンチ、事業の予測から、期待される負荷をモデル化します。自然な成長の予測を、マーケティングキャンペーン、納税の期限、政府で大いに重要な給付の登録期間のような一回限りの出来事と組み合わせます。ピークの上に余裕を保ち、想定を確認するために負荷テストを行い、可能な所ではスケーリングを自動化しつつ、大きな約束には人間がレビューする容量計画を保ちます。不足が不意を突かないよう、プロビジョニングのリードタイムを追跡します。

信頼性を本物のコストを伴う機能として扱う

可用性の追加の「ナイン」はそれぞれ、通常、直前のものより、冗長性、テスト、運用の洗練にはるかに多くのコストがかかります。プロダクトオーナーが目を開いて目標を選べるよう、ナインのコストを明示的にします。部分的な失敗が全面的な停止ではなく縮退したサービスを与えるよう、グレースフルデグラデーションを設計します。冗長性とフェイルオーバーへの投資を、すべてのコンポーネントに均等にではなく、SLOに比例させます。

SREの組織モデルを選ぶ

唯一の正しい構造はありません。集中型のSREチームは、一貫性、深い専門性、共有のツールを与えますが、ボトルネックや他人の問題の捨て場になりえます。組み込み型のモデルは、SREをプロダクトチームの中に置いて密接に協働させますが、不整合と孤立のリスクがあります。多くの大きな組織はハイブリッドを使います。中央のプラットフォームと標準のチームに加えて組み込みの信頼性エンジニア、そしてサービスがSREのサポートに適格となる時と、最初に越えなければならない本番稼働準備の基準を定義する、明確な関与のモデル。

トレードオフ: 長所と短所

決定	長所	短所
厳しいSLO(より多くのナイン)	より高いユーザーの信頼、契約を満たす	上昇するコスト、遅い機能のデリバリー
緩いSLO(より少ないナイン)	速い出荷、低いコスト	ユーザー離れとSLAのペナルティのリスク
集中型SRE	一貫性、共有の専門性	ボトルネック、プロダクトからの距離
組み込み型SRE	密接な協働、文脈	不整合、人員配置が難しい
重い自動化への投資	スケールする、苦役を減らす	前もってのコスト、自動化自体が失敗しうる

信頼性エンジニアリングは、実のところ有限の資源を賢く使うことです。ユーザーが知覚すらできない追加のナインを追うことは、機能に資金を出したり価格を下げたりできたお金を無駄にします。逆に行き、失敗が本物の害を引き起こすシステムへの投資を怠ることは、怠慢です。エラーバジェットの枠組みは、このトレードオフを暗黙で論争的なものではなく、可視で交渉可能にするためにまさに存在します。組織モデルのトレードオフも同じく本物です。正しい答えは、会社の規模、エンジニアリングの成熟度、サービスがどれだけ均一かによります。

チームで議論すべき問い

ユーザーが実際に感じることを反映するSLIは正確にどれで、それが虚栄の指標でないことを示せますか。 間違った指標を選ぶと、ユーザーが苦しんでいる間、すべてのダッシュボードが緑に見え、それがこの章の警告する虚栄のSLIの罠です。議論に本物のデータを持ち込んでください。サーバーのCPUやバックエンドのヘルスチェックではなく、本物のリクエストの経路から同じユーザーの旅(ログインからダッシュボード、チェックアウトから確認)を測定する。大きなチームでは、一つの悪いSLIが伝播します。数十のサービスがそれを引き継ぎ、アラートが間違ったものに発火し、エラーバジェットが意味を失います。SLAが返金や市民への影響を伴う企業と政府の設定では、SLIは監査人に擁護する証拠なので、ユーザーに見える成功に直接たどれなければなりません。数字からユーザーの体験への線を引けないなら、その数字を置き換えてください。
サービスは、SREチームがオンコールを引き受ける前に何を証明しなければならず、誰が断りますか。 本番稼働準備の基準がなければ、中央のSREチームはあらゆる不安定なサービスの捨て場になり、他人の技術的負債に溺れます。参入の基準を書き出してください。所有されたSLO、動くランブック、対処可能なアラート、容量の余裕、実証されたデプロイとロールバックの経路。大きな組織では、この関与のモデルが、信頼性チームを全員を遅くするボトルネックにしないものです。規制対象の設定では、準備のレビューは監督機関に示せる統制も兼ねます。誰がオンボーディングを断る権限を持つかを決めてください。誰も徹底しない基準は基準ではなく、その答えが、SREがスケールするか、引き継いだ痛みで崩れるかを変えるからです。
最大の予測可能なピークに向けて、どれだけ前もって事前にプロビジョニングし、プロビジョニングのリードタイムを知っていますか。 クラウドの弾力性が即座で無限だと想定すると、まさに最も重要なピークで不足を招きます。そしてそれらのピーク(納税の期限、登録の期間、セールの出来事)は、失敗が最も目につき最もコストがかかる瞬間です。数字を持ち込んでください。過去のピーク負荷、予測される成長、負荷テストする倍率、大きな予約容量や特殊なインスタンスを獲得する本当のリードタイム。政府の季節的なサービスでは、ピークは通常の負荷の数倍になりえて、政治的に見逃せないので、オートスケーリングが追いつくことを願うより、数週間前の事前プロビジョニングが勝ります。答えは具体的なカレンダーを設定すべきです。いつ負荷テストし、いつ容量をロックし、誰が実行の決定を所有するか。
エラーバジェットが尽きたとき、実際に何が起こり、誰がそれを徹底する立場にありますか。 尽きたときに決して行動されないエラーバジェットは、単なる飾りで、停止の瞬間は、方針をゼロから交渉するのに最悪の時です。相反する引力は本物です。約束されたローンチ、収益の期限、公的な発表が、危険な変更の凍結に強く押し返します。バーンレートのデータ、事前に合意された方針の文面、バジェットが超過した最近の数回の記録を持ち込み、凍結が実際に保たれたかを見られるようにしてください。大きなチームでは、バジェットは、すべてのグループが同じ徹底を引き継ぐ場合にだけインセンティブを揃えるので、誰が上書きを承認し、その例外がどう記録されるかを事前に決めてください。SLAがペナルティや市民への影響を伴う企業と政府の設定では、上書きの証跡が監査の成果物になるので、バジェットがすでになくなっているときに即興で行うのではなく、説明責任のある所有者を今名指ししてください。
SREチームの週のどれだけの割合が苦役で、それは測定された数字ですか。それとも感覚ですか。 誰も数えない苦役は、チームが時間のすべてを火消しに費やし、持続的な改善を築く時間がなくなるまで静かに拡大し、それはまさにSREが逃れるために存在する罠です。緊張は、苦役の測定それ自体が仕事であり、期限の圧力のもとのエンジニアが、時間がどこに行くかを記録するのに抵抗することです。誠実なサンプルを持ち込んでください。苦役の共有の定義(手作業、反復的、自動化可能、戦術的、システムとともに拡大)に照らして追跡した1、2週間の時間と、頻度かけるコストで順位づけた自動化プロジェクトの積み残し。大きな組織では、50パーセントの上限は、チームごとに報告され擁護される場合にだけ意味を持つので、誰が数字をレビューし、チームが超えたとき何が起こるかに合意してください。規制対象と政府の文脈では、苦役に上限を設けることは、手作業の運用が押しのける統制と監査の仕事のために、乏しい専門家を解放するので、苦役の数字を、リーダーシップが見るべき容量のシグナルとして扱ってください。
どのSRE組織モデルを運営していて、それが合わなくなったことを示す証拠は何でしょうか。 集中型のチームは一貫性と共有のツールを与えますがボトルネックになりえ、組み込み型のモデルは文脈を与えますが不整合へとずれ、ほとんどの大きな組織が落ち着くハイブリッドは、明確な関与のモデルがなければ両方の弱点を引き継ぎます。緊張を明らかにするシグナルを持ち込んでください。サービスがSREのサポートを待つ時間、信頼性の実践がチーム間でどれだけ異なるか、組み込みのエンジニアが専門家のコミュニティから切り離されていると感じているか。正しい答えは会社の規模、エンジニアリングの成熟度、サービスの均一さによるので、最初の選択を恒久的なものとして扱うのではなく、それらが変わるにつれて見直してください。多くのチームと厳しい均一性の要件を持つ企業あるいは政府機関では、通常、中央の標準とプラットフォームのグループに組み込みの信頼性エンジニアを加えることが、一貫性と地域の文脈のバランスをとりますが、関与のモデルと本番稼働準備の基準が書き出され、誰かが所有している場合に限ります。

セクター別の視点

スタートアップ。 少数のエンジニアと専任の信頼性チームに割く余裕がないなら、最も重要なユーザーの旅に単一のSLOを選び、チーム全体でオンコールを共有してください。オブザーバビリティのインフラストラクチャを築くのではなく、クラウドプロバイダーのマネージドなサービスと組み込みの監視に頼り、修正が定着するよう共有のドキュメントに短いポストモーテムを書きます。ここではプロセスより速度が重要です。実際に徹底する緩いSLOは、誰も見ない手の込んだものに勝ります。

小規模事業者。 信頼性を動かす専門家がいないなら、それをプラットフォームを通じて買い込む規律として扱ってください。カスタムのスタックではなく、ホスト型の稼働監視、マネージドなデータベース、ステータスページのツール。請求書を払う取引に結びついた一つか二つのSLOを設定し、どの失敗が顧客を失わせるかを誠実に決めます。築くより安い所ではレジリエンスを買い、既存のエンジニアが機能の仕事と並行して担える程度に、運用の負担を軽く保ちます。

大企業。 課題は多くのチームにわたる一貫性です。共有のSLOの語彙、共通のエラーバジェットの方針、SREがオンコールを引き受ける前にすべてのサービスが越える本番稼働準備の基準。中央のプラットフォームと標準のグループに加えて組み込みの信頼性エンジニアが、ボトルネックにならずに実践を均一に保ち、ガバナンスは、エラーバジェットがどこでも同じように報告され徹底されることを必要とします。オブザーバビリティのインフラストラクチャと自動化への投資に明示的に予算を付け、リーダーシップが見られる指標とともに、信頼性をポートフォリオとして管理します。

政府。 公共サービスは、しばしば公表された可用性の目標、法定の約束、監査の義務を負うので、SLOとエラーバジェットの決定は、監督機関に擁護する記録になります。調達規則が使える監視とホスティングを制約するかもしれず、透明性の期待が、信頼性のデータを公開のステータスダッシュボードに載せるよう促します。納税の期限や給付の登録期間のような極端な季節的ピークを数週間前から計画し、公的な失敗が個人の非難ではなくシステムの改善を駆動するよう、責めないポストモーテムの文化を保ちます。

事例

スタートアップ。 10人のスタートアップは、単一のウェブアプリを動かし、3人のエンジニアでオンコールを共有します。余裕のない信頼性チームを築く代わりに、一つの意味あるSLOを選びます。ログインからダッシュボードへの流れで99.5パーセントの成功、本物のユーザーのリクエストから測定。不安定なサードパーティのAPIがそのバジェットを食い始めると、チームは次の機能を出荷する代わりに金曜日をリトライとキャッシュの追加に使い、それから修正が定着するよう、共有のドキュメントに二段落のポストモーテムを書きます。

大企業。 世界的な決済企業は、取引APIに99.99パーセントの可用性のSLOを設定し、それは月におよそ4分のエラーバジェットを与えます。中央のSREプラットフォームチームが、共有のオブザーバビリティ、インシデントのツール、エラーバジェットの方針を所有し、組み込みの信頼性エンジニアが各プロダクトグループの中で働きます。新しい不正検知の機能が1週間で月のバジェットの半分を燃やすと、事前に合意された方針が、信頼性の仕事が余裕を取り戻すまで、重要でないリリースを凍結します。経営陣は、方針を事前に承認したので、議論なしにこれを受け入れます。

政府。 国の税務当局は、年次の期限前後に極端な季節的ピークを持つオンライン申告サービスを動かします。そのSREチームは、過去の年に人口と方針の変更を加えて需要を予測し、通常のピークの数倍まで負荷テストし、数週間前に容量を事前にプロビジョニングします。可用性とページのレイテンシの公開向けSLOは、ステータスのダッシュボードに載ります。責めないポストモーテムの文化(個人の非難を割り当てるのではなく、システムを改善するために失敗をレビューすること)と自動化の義務が、かつて申告の季節を支配していた手作業の介入を着実に減らし、職員を、期限のたびにシステムを看病するのではなく改善することに解放します。

ビジネスケース: 動機、ROI、TCO

SREの見返りは三つの源から来ます。避けられた停止、減った運用の労力、より速く安全なデリバリー。大きなサービスの停止は、失われた収益、ペナルティ、是正で、1時間あたり数千から数百万のコストがかかりえるので、控えめな信頼性の向上でもチームの元をすぐに取ります。苦役の削減は、繰り返される手作業のコストを一度きりの自動化の投資に変えるので、総所有コストは、規模とともに歩調を合わせて上がるのではなく、規模が育つにつれて下がります。エラーバジェットは、信頼性が健全なときにビジネスがより速く出荷できるようにし、過度に慎重な運用が取り残す機能の価値を捉えます。

採用のコストは本物です。SREは、熟練したエンジニア、オブザーバビリティのインフラストラクチャ、機能の期限と競合する文化的変化を必要とします。しかし採用しないコストは、規模ではより高くなります。際限のない運用の人員、予測できない停止、職員の燃え尽きと離職、定量化は難しいが被るのは容易な評判の毀損。リーダーシップに論拠を示すには、SREを、測定可能な見返りを伴うリスク管理として枠づけてください。インシデントと手作業の運用の現在のコスト、事業の約束に結びついたSLOの目標、両方の予測される削減を示します。論拠を、リーダーシップに信頼性対速度のトレードオフへのてこを与えるガバナンスの道具としての、エラーバジェットに据えてください。

アンチパターンと落とし穴

看板を掛け替えただけの運用としてのSRE。 エンジニアリングの時間、自動化の義務、押し返す権限なしに運用チームの名前を変えても、何も変わらないこと。
100パーセントを狙うこと。 完全な信頼性を追うことは、お金を無駄にし、ユーザーが知覚できない利得のためにデリバリーをブロックすること。
虚栄のSLI。 ユーザーに見える成功ではなくサーバーのCPUを測ると、ユーザーが苦しんでいる間、よく見える数字を出すこと。
歯のないエラーバジェット。 尽きたときに決して徹底されないバジェットは、単なる飾りであること。
測定されない苦役。 苦役を追跡しなければ、改善の仕事が起こらなくなるまで、静かにチームを消費すること。
捨て場としてのSRE。 準備の基準なしにあらゆる不安定なサービスを引き継ぐ集中型のチームは、他人の技術的負債に溺れること。
容量のリードタイムの無視。 クラウドの弾力性が即座で無限だと想定すると、まさに最も重要なピークで不足を招くこと。

成熟度モデル

レベル1: 開始。 運用は手作業で反応的です。正式なSLOはなく、信頼性は意見の問題で、火消しが支配する間、同じインシデントが繰り返されます。自動化があるとしても偶発的で、誰もエンジニアリングの関心事として信頼性を所有していません。

レベル2: 発展。 一部のサービスは基本的なSLIとSLO、初歩的な監視とアラートを持ちますが、実践はチーム間で大きく異なります。苦役は認められているが測定されず、自動化はその場しのぎで、ポストモーテムは一貫せずに行われます。信頼性は、組織が求めるからではなく、個人が押し進めるところで改善します。

レベル3: 標準化。 SLI、SLO、エラーバジェットの方針が文書化され、チーム間で一貫して適用されます。苦役は定義され追跡され、容量計画は日常的で、本番稼働準備のレビューを伴うSREの関与のモデルが存在し、自動化は副業ではなく資金のある作業の流れです。信頼性の実践は書き出され、組織全体で徹底されます。

レベル4: 管理。 信頼性のプログラムが、ベースラインに対するデータで測定され制御されます。エラーバジェットのバーンレート、苦役の割合、SLOの達成、平均復旧時間、プロビジョニングのリードタイムが指標として追跡され、決まった周期でレビューされ、チームを目標に保つのに使われます。バジェットの超過は合意された凍結を引き起こし、容量は需要のモデルに対して予測され、すべての実行か中止かの決定は、意見ではなく証拠に基づきます。

レベル5: オーケストレーション。 信頼性エンジニアリングは、組織全体に統合され、継続的に改善されています。エラーバジェットの方針は自動化され、どこでも尊重され、ほとんどの運用はセルフサービスで、容量は先回りしてプロビジョニングされ、信頼性のデータが、速度と安定の間の適応的なトレードオフを駆動します。組織は、事業とリスクの状況が移るにつれて、SLOの範囲を日常的に見直し、苦役を退役させ、信頼性の投資を再均衡させます。

議論のためのアイデア

組織が、それを支える過去の信頼性データを持たないとき、最初のSLOをどう設定すべきですか。
エラーバジェットが尽きているが大きなローンチが約束されているとき、凍結を上書きする権限は誰にあり、その決定はどう記録されますか。
集中型、組み込み型、ハイブリッドのうち、あなたの組織に正しいSREのモデルはどれで、何が変更の引き金になりますか。
同じ投資が資金を出せる機能に対して、可用性の追加のナインをどう評価しますか。
あなたの文脈では何が苦役に当たり、価値ある手作業の判断と排除できる繰り返しの線はどこですか。
信頼性の目標は、市民向けの政府サービスと社内の企業ツールで、どう違うべきですか。

要点

SREは、ソフトウェアエンジニアリングを運用に適用し、信頼性を測定可能で資金を出せる機能として扱います。
SLI、SLO、SLAは、信頼性を意見から合意された数字に変えます。SLOはSLAより厳しく保ちます。
エラーバジェットは、信頼性対速度のトレードオフを明示的で事前に交渉されたものにすることで、開発者と運用者を揃えます。
苦役を測定して上限を設け、自動化を第一級のエンジニアリングとして扱い、運用が線形より緩やかにスケールするようにします。
特に季節的なピークでは、需要の予測から容量を計画し、プロビジョニングのリードタイムを尊重します。
SREの組織モデルを意図して選び、明確な関与と本番稼働準備の基準を定義します。

参考文献とさらなる読み物

Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne, The Site Reliability Workbook: Practical Ways to Implement SRE
David N. Blank-Edelman (editor), Seeking SRE: Conversations About Running Production Systems at Scale
Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan, The Practice of Cloud System Administration
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps