Keys to SRE in SRECon14の意訳

Qiita Advent Calendar 2025の海外SRE関連セッション意訳の初回です。ひとりアドベントカレンダーですが、完走できるように頑張ります。

このアドベントカレンダーでは、海外のSRE関連のセッションを翻訳しながら、私の意見や疑問や補足を追加したものです。私の誤解から誤った説明になっている箇所は、コメントでご指摘お願いします。

このアドベントカレンダーでは、私の意見やコメントは可能な限り、下記の記法で要約と区別します。ただ、そこまで厳密にできないため、要約文中に私の思想が混じってしまうことはご容赦ください。(気がついたらご指摘ください)

私のコメントはこの記法

紹介するセッションについて

初回は、SREの始まりともいうべき、SRECon14 The Keys to SREです。

https://www.youtube.com/watch?v=n4Wf14e2jxQ

セッション詳細: Keys to SRE | USENIX

Ben Treynor氏は、Google SREの創設者であり、Googleの運用チームを7名から1200名以上の組織へ成長させたリーダーでありマネージャーです。SREの定義や原則について語るとき、このセッションを引用しているものが少なくないです。
例えば、SREをはじめよう - O'Reilly Japanでも、冒頭で引用されていますね。

要約

SREの出発点：「いちばん大事なのはプロダクトがちゃんと動いていること」

• ビジネスにとって最重要なのは「プロダクトが動き続けていること（product works）」。
• 経営層は、大きな障害が起きて「炎上」してからようやく信頼性の優先度を上げがち。
• しかしその時にはもう、構造的な問題が積もりすぎていて、直すのに数か月〜1年単位かかる。
• だからこそ、信頼性に責任を持つ“独立したチーム”＝SREが必要、という位置づけになっている。

伝統的な Dev vs Ops の構造的対立

従来のOpsチーム：

• 目的：壊さないこと（安定運用）
• 経験則：一番壊れるのは「変更したとき」
  • →「じゃあ変更を止めれば壊れない」という方向に行きがち

動画内ではユーモアを交えて、「障害を減らしたければ半年間すべてのエンジニアに休暇を与え、変更はキャパシティのスケールだけに止めれば良いけど、誰もそれは言わない。その代わり、膨大なリリースチェックリストを作っているんだ」と説明してあって、わかるとなった。

一方Devチーム：

• 目的：新機能を速く出したい
• 変更を止められるとビジネスが前に進まない

このギャップから、典型的な「ゲート文化」：

• ローンチレビュー&ディープダイブ
  • 過去の事故をもとに「この3つをやってなかったから事故った、だからチェック項目にしよう」とゲートが増える。
  • プロダクトを細かく分析して、「壊れうるポイント」の膨大なチェックリストができる。
  • それを管理するTPMが必要になり、チェック項目は増える一方。
• 慎重すぎるカナリーリリース
  • 1% カナリーを1ヶ月、さらに地域ごとに数週間…というように、とにかくリスクを減らそうとする。

しかしこれをやると：

• Devはゲートを回避するために
  • 「これはリリースじゃなくて、ただフラグON/OFFするだけ」
  • 「既存機能じゃなくて新機能追加だから関係ない」などと言い始め、“ゲートをすり抜けるパス”を作り始める。
• そしてそもそもDevよりもコードを理解していないOpsが、リリースの安全性を判定するというねじれが生じる。

これは人の問題ではなく、「構造のインセンティブ設計の問題」。

リリースチェックリストにおけるリリースの定義の議論はよく見かけるので自戒。
サーバーの追加は？動的な設定変更は？など、「リリースチェック」を回避するための定義の議論は本当に嫌い

SLO / エラーバジェットによる自己制御

Google SREは、「リリースをチェックリストレビューで止めて守る」やり方をしなくなった。代わりに使っているのがSLOとエラーバジェット。
まずサービスに対してSLO（例：可用性99.9%）を決める。

• エラーバジェットは1 - SLO。
• 例：SLO 99.9%なら、残り0.1%が「壊れていても許される枠」。月に10億リクエストがあるなら、約100万回のエラーは「予算内」とみなせる。

リリースのポリシーはとてもシンプル。

• エラーバジェットの範囲内なら、リリースしてよい。
• SLOを満たしている限り、開発者は「良い仕事をしている」とみなし、 SREはそれを信頼する。
• 大障害などでSLOを割り込み、エラーバジェットを使い切ったら：
  • 新機能リリースを止めて、信頼性改善（バグ修正・テスト強化・設計改善）に集中する。

「開発者を信頼する」という表現は本当にいいですね。

ここまでの重要なポイント:

1. 情報の非対称性を認める
   • コードを一番よく知っているのは開発チーム。
   • だからSLA/SLOの範囲内では、開発側の裁量を最大限尊重する。
2. 自己調整メカニズム
   • エラーバジェットを使い切るような雑な変更をすれば、自分たちの開発ペースが止まってしまう。
   • その結果、開発者自身が「自分で自分のリリースを規制する」ようになる。
3. SLOはビジネス側のレバー
   • もしユーザーから苦情が殺到したり、経営陣が「髪の毛が燃えている」状態になったら、SLOを上げることもできる。
   • それは技術ではなくプロダクトの意思決定の問題。

→ こうしてDevとOpsの対立軸そのものを消し、共通の指標（SLO/エラーバジェット）で会話できるようにするのが “Key” の1つ。

リリースチェックリストにおける要件は満たしているのに、ビジネス的な要求の変化でリリースが中止されることも心当たりがあるので
そこがSLO, エラーバジェットのレバー操作になると、色々シンプルになりそう。
何より、「エラーバジェット枯渇したらリリース中止」は強すぎるポリシーだと思ってたけど、重厚なリリースチェックリストを廃止するという目的を理解すると、このポリシーは当然に思えてくる。

オペレーションオーバーロードと「6つの指針」

エラーバジェットで対立は減るが、別の問題が出る。

運用作業（手作業・Toil）が多すぎて、SRE が“単なる運用チーム”になってしまう

これを避けるために、Treynorが挙げている指針がだいたい次の6つ。

1. SREとDevは共通の人員プール（One more SRE = One less Dev）

新しくエンジニアを50人採用するとしたら、何人をSREに回し、何人をDevにするかを1つの枠として考える。
つまり、1人SREを増やすということは、その人がDevとして作ったはずの機能がこの世から消えるという意味になる。

逆に言うと、運用作業が減れば減るほど、開発に回せる枠（機能）が増える、ということを経営に理解させる。

2. SREは「ソフトウェアエンジニアだけ」を採用する

ただのスクリプト職人ではなく、システムを設計し、自動化できるエンジニア。
「同じ手作業を30回やる」のが苦にならない人ではなく、2回目でもう飽きて、「これ自動化しないと無理」と思ってコードを書き始めるタイプを求める。要するに “Toilを自動化するのが楽しい人” を集める。

3. Opsに使う時間は50%まで（理想は30%程度）

チームとしての時間のうち、運用（オンコール・チケット対応・手作業）に使ってよい上限を決める。実際は30%くらいに収められていると「かなり良い」状態。
これを超えたら「オペレーション過負荷」のアラートとみなす。

4. 開発チームもオンコール／運用に参加させる（最低5%）

運用、とくにオンコール負荷の5%はDevにも持ってもらう。そうすることで、運用の実態がDev側に常に伝わる（“暖気された”状態）になる。また後続のDevに運用タスクをオーバーフローさせるときのオペレーショントランスファーがスムーズにいく。

SOXなどのコンプライアンスがあるなら、経営陣と交渉してルール設計する必要がある。

SOX法やトップダウンの開発と運用分離の要件について、明確に経営陣と調整するべきと発言されてたことが素晴らしかった。
やはり、そこは避けて通れないのだな、となっている。

5. 運用タスクが50%を超えたら、Devにオーバーフローさせる

SREのOps比率が50%を超えたら、その運用タスクをDevチームに再アサイン。
SREが運用で潰れているなら開発速度を落としてでも、信頼性改善に手を入れないといずれSLO達成が危うくなる。
結果として、

• Devが運用作業に時間を割く → 変更が減る → 新しい障害の発生頻度が下がる
• さらにコード修正で運用作業が減る → 安定性が上がる → エラーバジェットが増え、またリリースできるようになる

「運用が50%を超えたらDevチームに運用タスクを返却する」というプラクティスについて、この動画を見るまでは「開発者に対する罰」「自分のけつは自分でふけ」みたいなニュアンスのものだと誤解していて、あまり好きではなかった。
でも、この動画を見て認識は大きく変わった。運用比率は、エラーバジェット枯渇の先行指標として扱っているという内容だった。
つまり、この運用過負荷状態が継続すれば、いずれ障害が起こりエラーバジェットは枯渇し、開発は止まってしまう。しかもこれはポリシーによるものなので、非常に高い強制力によって発生する。
それが発生する前に、運用改善に工数を割くことで、開発チームの裁量のあるうちに問題に能動的に対処するということだった。
また、これは「1. SREとDevは共通の人員プール」と同じ構造になっていて、SREとDev全体でゼロサムゲームを行う。それを人のアサインの側面から話すか、タスクのアサインの側面から話すかの違いでしかなさそう。

6. SRE Portability（SREはポータブルである）

SREは他プロジェクトや他組織、場合によってはDevへの異動も自由であるべき。
「壊れた運用環境」「Toilだらけで学びも成長もない環境」にSREを縛り付け続けることはしない。
どうしても改善不能な状況なら、そのSREチーム自体を解散し、他の健全なチームに移すこともある。
これは経営に対しても強いメッセージで、「このままだとチケットキューは溜まり続け、経営にとっても損失ですよ」

「必要ならトップ（ラリー）まで話が行き、そこまで行けば必ずサポートしてくれる」というくらいの覚悟でやっている、というニュアンス。

ここはたぶん重要なんだろうけど、Google規模のSRE組織じゃないと意味なさそうな気がする。

障害対応のキー：影響の最小化と再発防止

どれだけ頑張っても障害はゼロにはならない。
大事なのは2つ：

• 見つけて直すまでの時間を短くする（MTTR）
• 影響範囲（影響人数）を減らす

そのためのポイントとして挙げられていたのが：

• No NOC
  • 手順書通りにしか動けない一次対応要員（NOC）を前提にしない。
  • 問題を解決できるスキルを持ったエンジニアに、直接アラートを飛ばす。
  • これによって、エスカレーションの段数と時間を削減する。
• 良いアラート設計
  • 「このクラスタのどこかがおかしいっぽい」レベルのアラートは役に立たない。
  • 「誰が何をすべきか」が見えるアラートを目指す。
• Practice, practice, practice（Wheel of Misfortune）
  • 実際のポストモーテムを見ると、現場の対応時間は「理想の3倍」かかっていることが多い。
  • 「優秀なエンジニアなら一瞬で正解にたどり着くはず」というのは神話。
  • そこで、Wheel of Misfortune（不運の輪）という訓練を行う：
    • GM（ゲームマスター）と担当者に分かれてロールプレイ。
    • 参加者は質問しながら状況を把握し、運用・設計の知識をもとに対応する。
    • 他のメンバーは基本見ているだけ（頼まれたときだけ手助け）。
    • ダンジョン&ドラゴンズのようにGMが「今ダッシュボードにこう見えている」と状況を返し、最後にふりかえりを行う。

良いアラート設計については、オブザーバビリティ文化の発展やエラーバジェットのバーンレートアラート関連で今と若干ニュアンスが違う気がする。
現在は、アラートは複数要因を多く含んだエラーバジェットの枯渇だけにして、それを受け取った人が能動的にダッシュボードなどを見に行ったときに原因がすぐにわかる状態(オブザーバビリティの高い状態)を目指す、としていて
アラート単体で原因まで指し示すのはちょっと違うかも？

ポストモーテム文化

障害が起きたあとの振り返りで重要なのは：

• プロセスと技術にフォーカスする（人の責めではない）
• タイムラインを作り、事実を集める
• フォローアップ作業はすべてバグやチケットとして起票する

ミスを正直に共有し、
「どうシステムを変えれば、同じミスをしても事故になりにくいか」を議論する。

「この点については、いくら強調してもしすぎることはない」
というくらい、ブレームレスで学習する文化 を強く推していた、という位置づけです。

ここはもう当たり前すぎて、特に思うことはなかった。"当たり前"が変わったのかな。

全体を通してコメント

11年も前の動画で、いつでも見ることができたのに、なんで今まで先送りにしていたんだろうと後悔しました。それぐらい、私はいくつかのSREプラクティスについて誤解をしていたし、ある意味でSLOやエラーバジェットを軽視していた。重厚なリリースチェックリストを完全に置き換えるものとして捉えれば、これはとても適切だし、逆に置き換えられないのであれば、効果は限定的かもと思った。

DevとOpsが分離していない現場(DevOpsネイティブというような)では、実はガバナンスの名目で中央組織(Opsではない)がリリースチェックリストなどを整備しがちだと思っていて、その場合はそことの間にインセンティブの設計変更を試みないといけないんだな、となった。

アドベントカレンダー2日目は SLO Math in SLOconf 2021の意訳 です。