## 概要 2014 年の SREcon14 にて [[Ben Treynor Sloss]] が「SRE とは何か、なぜ機能するか」を初めて体系的に公開した講演である。Google 2003 年入社以来 7 名から 1300 名超へ成長させてきた SRE 組織の運営原則を「13 のキー」としてまとめた。SRE Book（2016 年）より 2 年早い、原著者による最初の公開整理であり、エラーバジェット・運用キャップ・無責非難のポストモーテムなど後の SRE 標準語彙の起点となる講演だ。 ## 主要メッセージ - **SRE の本質的定義**: SRE は役割の名称ではなく「ソフトウェアエンジニアが運用を設計するとどうなるか」という実験の結果である。SRE が動くのは、仕事に飽きやすいエンジニアが繰り返し作業を自動化するインセンティブを持ち続けるためだ(口頭説明)。 - **信頼性の不可視性という罠**: 信頼性は機能していると気づかれず、機能しなくなったときだけ存在が見える。この非対称性から「信頼性は誰でも担える」という誤解が生まれる(口頭説明)。 - **13 のキー(後述)**: SRE が大規模・長期的に機能するための実践原則群。インセンティブ設計・オンコール設計・ポストモーテム・訓練・移植可能性の 5 つの柱で構成される。 - **エラーバジェットが利害対立を解消する**: 開発チームと SRE の「速度 vs. 信頼性」という構造的対立は、エラーバジェットを共有インセンティブとすることで消滅する。開発チームは自チームのローンチ枠を守るために他チームの不品質なリリースを牽制するようになる(口頭説明)。 ## 13 のキー Ben Treynor は「これらを書き下ろしたことはなかった」と述べた上で、以下を提示した(口頭説明より。映像フレーム未確認)。 ### 1. コーダーだけ採用する SRE は非trivialなコードを書けなければならない。コードを書けない人材が採用されると、状況が変わっても同じ手順書を繰り返し実行し続け、自動化が進まない。 ### 2. SLA を定義する SLA(サービスレベル合意)がなければ、信頼性を数値で語れない。100% の SLA は現実的でない——ユーザー端末自体が 2〜3 ナインズ程度の信頼性しかなく、サービスがそれを上回る必要がない。 ### 3. SLA に対して実績を計測・報告する SLA を定義するだけでなく、実績との乖離を継続的に測定する。計測なしでは改善の方向も優先度も決まらない。 ### 4. エラーバジェットを使う エラーバジェット = 1 − SLA。SLA 99.9% なら 0.1% のエラーが許容予算となる。この「予算」は四半期ごとに利用可能で、製品変更・実験・リスクに対して使える。 ### 5. エラーバジェットでローンチをゲートする 「ブラックでローンチ」原則: SLA 遵守中(エラーバジェット残有り)ならローンチを自由に許可し、SLA 違反中ならコンプライアンス回復まで全ローンチを凍結する。SRE と開発の間に主観的判断を介在させない客観的な決定ルールである。 ### 6. 共通人材プールを持つ SRE と開発のヘッドカウントは同一プールから確保する。開発チームが信頼性を損なうと、追加の SRE が必要になりその分の開発ヘッドカウントが削られる。開発チームが SRE 数を最小化したければ運用負荷を減らすしかない、という自浄インセンティブが生まれる。 ### 7. 余剰運用作業を開発チームへ差し戻す 運用負荷が 50% キャップを超えたとき、余剰チケットは開発チームへ戻す。最初は抵抗が激しいが、Treynor によれば「6 ヶ月後には改宗する」。 ### 8. 運用負荷を 50% 以下に抑える 実際の目標は 30〜50%。残り時間はコーディング・設計・自動化に使う。「運用ばかりやっている」状態では SRE は SWE でなくなり、採用した意味がなくなる。 ### 9. 開発チームにオンコールの 5% を担わせる 開発チームが週に 1〜2 件のアラートを受けることで「自分には見えていなかった現実」(Kahneman の "What you see is all there is") に気づく。数回の眠れない夜が信頼性改善の優先度を劇的に変える。 ### 10. 移植可能性を確保する SRE はチームをまたいで異動できる必要がある。開発チームが協力的でない場合の最終手段として、SRE チームを解散してメンバーを他チームへ異動させることができる。これは年に 1〜2 回実際に行使される「核オプション」であり、その信頼性が抑止力として機能する。 ### 11. 最低 8 名のオンコール体制 単一ロケーションなら最低 8 名(ローテーションで週 1 回以下)。複数ロケーションなら各 6 名以上。8 名を割ると運用負荷が持続不可能になる。 ### 12. 1 シフトあたり最大 2 件のイベント 2 件を超えると調査とポストモーテムを適切に書く時間がなくなる。超過は次のシフトに持ち越されスパイラルが起きる。 ### 13. 全イベントにポストモーテム、無責非難で すべての重大インシデントにポストモーテムを書く。全員が善意で正しいと思うことをしたという前提から出発し、人ではなくシステム・環境・プロセスを修正する。アクションアイテムはバグトラッカーに登録して追跡する。 ## 映像で確認できる重要点 ![[_attachments/srecon14-keys-sre/frame-001.jpg]] タイトルスライド「The Keys to SRE」。SREcon14 のロゴとともに表示。 ![[_attachments/srecon14-keys-sre/frame-005.jpg]] 「Reliability is easy to take for granted」スライド。信頼性は「エラーの不在」として定義され、サービスが不安定になるまで気づかれない性質を明示した。"You need to work at reliability all the time. Not just when everything's on fire." のフレーズが確認できる。 ![[_attachments/srecon14-keys-sre/frame-010.jpg]] 「Then what?」スライド。「Error budgets!」と「First you must have an SLA...」という 2 行だけで構成されており、エラーバジェットの前提条件として SLA が必要であることを明示した。 ![[_attachments/srecon14-keys-sre/frame-012.jpg]] 「What do you spend your budget on?」スライド。"Change is #1 cause of outage / Launches are big sources of change / Solution: Spend error budget on launches! / ... or spend it on service instability :(" と明示。変更がダウンタイムの第 1 原因であることがスライドで確認できる。 ![[_attachments/srecon14-keys-sre/frame-015.jpg]] 「Part II: Staffing, Work, Ops Overload」スライド。"At the core, you can throw people at a badly-functioning system and keep it alive via manual labor. / That job sucks. / I won't do it, I won't ask SRE to do it." という宣言が直接確認できる。Treynor が自らの哲学を力強く表明した場面。 ![[_attachments/srecon14-keys-sre/frame-018.jpg]] 「50% Cap on Ops work」スライド。"If you succeed, work scales with traffic / Coding reduces work/traffic ratio / Leave enough time for serious coding / Or drown. / (or fail)" と説明。運用 50% キャップの構造的論拠がスライドで確認できる。 ![[_attachments/srecon14-keys-sre/frame-020.jpg]] 「Speaking of Dev and ops work...」スライド。"Excess operations load (tickets, oncall, etc) always gets assigned to the dev team / Another self-regulating system :)" と明示。余剰運用作業が開発チームへ差し戻される仕組みを「自己調整システム」と命名した。 ![[_attachments/srecon14-keys-sre/frame-022.jpg]] 「SRE Portability」スライド。"No requirement to stick with any project; in fact, No requirement to stick with SRE / Build it and they will come; / Bust it, and they will leave. / The threat is rarely executed, but it is powerful." と明示。「脅しはほとんど実行されないが、強力だ」という表現がスライドで確認できる。 ![[_attachments/srecon14-keys-sre/frame-025.jpg]] 「Wheel of Misfortune」スライド。クジラ・嵐・熊のイメージで構成された車輪と "Roll 1d20 / 1-4: Sharks with lasers / 5-9: Sharknado / 10-15: Sharkvalanch / 16-20: Bear Cavalry" という指示書。障害対応訓練のシナリオがユーモラスに表現されている。 ![[_attachments/srecon14-keys-sre/frame-028.jpg]] 締め括りのスライド「The SRE Benediction: May the Queries Flow, And the Pagers Remain Silent / Thank you.」。講演の締めのフレーズがスライドで確認できる。 ## 口頭説明・補足 **可用性の目標**: Treynor は「変更がダウンタイムの第 1 原因」とした上で、100% の可用性が意味をなさない理由を説明した。ユーザーがより高い信頼性を体験できるのは、端末・ブラウザ・ネットワークの方が制約になるためであり、99.99% と 99.999% の差はユーザー体験上検知できない。 **MTTF と MTTR**: 信頼性は障害ゼロを目指すことではなく、障害期間と影響範囲の積を最小化することだとした。ダメージ = 期間 × スコープ。MTTF と MTTR の両方が重要で、特に MTTR には訓練で大きな改善余地がある。 **Wheel of Misfortune**: 定期的な障害対応訓練の呼称。チームによって「貧困の八角形」(Ads チーム)など別名が使われている。Treynor は「MTTR が 50〜70% 改善した」と述べた。訓練は実際のインシデント対応を模したシナリオで行われ、アラートのトリアージから修正・ポストモーテムまでをロールプレイする。 **NOC を持たない**: Google SRE はネットワーク運用センターを持たない。アラートは問題を修正できるエンジニアに直接届く。NOC を経由させることは「一番修正できる人が起こされない」という構造的遅延を生む。 **組織的な共感の生成**: 5% 開発オンコール(キー 9)の効果は、単に信頼性を「教える」ことではなく、「見えなかったものを見えるようにする」ことだと強調した。開発チームは障害の「外側」にいると自分のサービスがどれだけ壊れているかに気づかない。 ## 概念・実体への接続 - [[SRE]] — この講演は SRE 定義の原典的位置にある - [[エラーバジェット]] — エラーバジェット概念の最初の公開整理 - [[ポストモーテム]] — 無責非難のポストモーテムの原則 - [[トイル]] — 運用 50% キャップとトイル削減の関係 - [[Ben Treynor Sloss]] — 登壇者・SRE 創始者 - [[Wheel of Misfortune]] — 訓練手法 ## 限界・不確実点 - transcript は YouTube 自動生成字幕由来(confidence: medium)。主要な主張はスライドで映像確認済み。 - スライドに「13 のキー」を箇条書きで一覧したスライドは映像フレームに存在しない(2 分毎のサンプリングのため、そのスライドが 2 分未満の表示だった可能性がある)。キーの番号付けは transcript の文脈から推定。 - Q&A セクションは transcript に含まれておらず、内容不明。 - Wheel of Misfortune の「MTTR が 50〜70% 改善した」という数値は口頭説明のみで、スライドでの確認はなし。