Unified Theory of SRE in SRECon22 Europe/Middle Asia/Africa の意訳

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

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

前回は、Notes from Production Engineering in SRECon15の意訳でした。FacebookでのProduction Engineeringチームまでの流れ、特にSRE的な取り組みを時系列でエモーショナルに紹介してくれているセッションでした。

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

私のコメントはこの記法

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

今回は比較的最近のSREcon22から、SREの統一理論(Unified Theory of SRE)という、かなり刺激の強いタイトルのセッションです。少し歴史的な背景を最初に補足しておくと、SREconが始まった2014年、SRE本が出版された2016年(日本では2017年)から5年ほど経過して、SREをメタ的に振り返る内容が増えています。今回はその中で、特にGoogleやFacebookのSREではなく、私たちのSREを作ろう！という内容です。

https://www.youtube.com/watch?v=9uF9VhcTZiE

セッション詳細: Unified Theory of SRE | USENIX

今回の内容で触れられているGoogleとFacebookのSREの内容要約は、今回のアドベントカレンダーでまとめていますので、そちらも良ければご一緒にどうぞ。

• Keys to SRE in SRECon14の意訳
• Notes from Production Engineering in SRECon15の意訳

要約

SREにまだ共通解はない

昔、あるドイツのエンジニアディレクターと電話で話したのです。

• その会社にはインフラエンジニアが2人だけ
• ドイツには労働者保護の法律があり
  • オンコール待機時間も労働時間に含める必要がある
  • シフトの間には11時間の休憩が必要
• その条件だと「呼び出しを受けたあと、次の人に交代できない。どうすればいいか?」と相談された

私の答えは、「No idea」だった。
この会話から私は気づいた。「実は、SREとしての共通解みたいなものは、まだ何も定まっていないのではないか」と。

SREの歴史と「SRE本」が作ったギャップ

ここで一度、SREの歴史を振り返る。

• 2003年:SRE at Google誕生
• 2009年:SRE at Facebook
• 2010年:SRO&AppOps at Facebook
• 2012年:ProductionEngineering at Facebook
• 2014年:SRO廃止(Facebook)
• 2014年:第1回SREcon
• 2016年:SRE本("Site Reliability Engineering")出版

SRE本を少し深掘りする

• 寄稿者は70名以上
• 数十のチームから寄稿された
• オンコールの章は「オンコールが最もうまくいっているチーム」
• データベースの章は「DB運用が最もうまくいっているチーム」

つまり、各領域の「最強チーム」が、自分たちのやり方を書いている。非常に示唆に富んだ内容を多く含んでいるが、これは全体としてみた時に正常な視点だろうか？

さらに2016年当時のGoogleには、1200人以上のSREがいたと言われるが、実際はそれ以上いた。
しかも構造は、多くの人が想像する「SRE部門の下に各SREチーム」ではない。

多くの読者はこういう組織図を想像したはずだ。

• SRE
  • NetworkSRE
  • StorageSRE
  • ...

しかし現実はこうだった。

• Infrastructureという大きな組織があり
  • その下にSWE組織
  • その下にSRE組織
• Infrastructure全体でSWEとSREがそれぞれ1200人以上
• 合計2400人以上のエンジニアがインフラだけに関わっている

そして、元Googleのエンジニアがその世界から外に出てくると、「地球に降り立った宇宙人」のようになってしまう。
他社の現実とはあまりにもスケールが違うからだ。

ここに「SREの基盤の亀裂」があるかもしれない。

• SRE本は価値ある本だが
• 書いている人たちの世界は、多くの企業の現実からかなりかけ離れている

今となっては「SRE本はSREの定義ではなく、すべてを実践する必要はない、道標の1つに過ぎない」と言うのが一般的な立場かもしれない。
しかし出版当時は「これがSREの権威あるテキストです」という雰囲気が強かった、という指摘をしている。

スタートアップのためにSREを再構築する

「スタートアップ～中堅企業」の文脈で、SREをどう再構築すべきか。

チーム名は正直どうでもいい。

• SRE
• Platform
• Infrastructure
• DevOps

好きな名前を付けて構わない。
重要なのは、その組織がどんな前提条件のもとで、何にフォーカスすべきかだ。

Default AliveとDefault Dead

彼は企業を2パターンに分ける。

• RealBusiness(Default Alive)
  • すでに顧客がいる
  • 安定稼働していれば、顧客が会社を生かしてくれる
  • SREは信頼性にフォーカスすることで存在意義を正当化できる
• Start-up(Default Dead)
  • 顧客はまだ少ない、あるいは存在しない
  • プロダクトマーケットフィットもまだ
  • プロダクトの速度がすべて

Default Aliveな会社では、「顧客の信頼性」を中心にSREを組み立てられる。ここでは信頼性の定義を広げていくことに意味がある。

一方、Default Deadなスタートアップでは、話が変わる。

• 顧客がほとんどいないのに、何をSREするのか?
• 何よりも大事なのは「プロダクトの速度」
• つまり、Default Deadな状態では、Production環境より開発者体験に重点を置くべきだ

No Kubernetes

ここでわりとKubernetesに対して、強めの批判をしていました。

スタートアップにおけるSREの最も価値ある仕事は「開発速度を上げること」である。

• 開発環境
• テスト/ステージング/CI
• デプロイ

といった開発基盤だ。
本番運用については「動くための最低限」でよい。

将来を見据えた対策と過剰エンジニアリングの線引き

とはいえ、「今は不要に見えるが、後で変えるのがとても辛いもの」もある。
ここが難しいポイントだ。

彼が例に挙げたのは:

• Network/VPC設計
• IAM/認証・認可

こういった基盤はDay0に作るのはそこまで難しくないが、後から変えるのは非常に苦しい。
問題は、それが「将来を見据えた合理的な投資」なのか、「ただの過剰エンジニアリング」なのかをどう見極めるか、という点だ。

技術選定:退屈な技術とイノベーショントークン

技術選定についても考えてみよう。私たちはしばしば技術の最先端で活動しようとしている。
常に最新で最高のものが必要だと考えるが、ほとんどの人はそうではない。
Metaは17のリージョンに、それぞれ100万台ずつサーバーを展開している話をしていた。
でも、それは私たちの問題ではない。だから、そうであるかのように装うのはやめよう。

• 私たちの多くが運用しているサービスは、実はほとんど同じで、しかもそこまで複雑ではない
• コミュニティとして、アーキテクチャや設計をもっと標準化できるはず
• イノベーショントークンを消費しない「退屈な技術」を使うべきだ

イノベーショントークンの説明は登壇内にありませんでしたが、大体こんな内容です。

• チームが同時に抱えられる「新しいこと」の上限のようなもの
• ビジネス優位性につながらないところにトークンを使うのは無駄

ここでの「退屈」は枯れていて、みんなが使い方を知っていて、ドキュメントや事例が豊富くらい意義。
ニュアンスはこれと同じかな？ Choose Boring Technology

No Kubernetes & No SLO

ここでもKubernetesと、さらにSLOについても過剰だという話をしています。SLOについては詳細は後述してます。

SLO:数値の前に価値観を定義する

スタートアップでSLOを説得力を持って導入するのは難しい。

• プロダクトもユーザーも頻繁に変わる
• 重要なものの優先度もどんどん入れ替わる
• そのたびにSLOを再定義し続けるのは時間の無駄になりうる

だからといってSLOの考え方が不要になるわけではない。

SLOの本質は「顧客にとって何が重要かを考え抜くこと」だ。
具体的な例として、彼はこんな問いを挙げる。

• エラーを返すべきか、古いデータを返すべきか
• 多くの小さな顧客がダウンするのと、1つの大きな顧客だけがダウンするのと、どちらを許容するか

これらは数値としてのSLOというより、「プロダクトとして何を大事にするか」という価値観の問題だ。スタートアップの段階では「SLOの根底にある価値観の議論」を重視すべきだと言う。

これはSLI/SLOではなく、CUJの議論だけでも十分価値があり、そして会社のフェーズではそれが最適なケースもあるということかな。

インシデントレビュー:全部をやる必要はあるか

次はインシデントレビュー。

• 多くのインシデントレビュー儀式は、大企業向けに設計されている
• バグや小さなエラーまで、すべてレビューしている会社はほぼ存在しないはず

すべてのインシデントが、長いポストモーテムをする価値があるのか？

• インシデントレビューから80%の価値を取る「スリム版」が必要ではないか
• どこまでを無視し、どこからを真剣にレビューすべきか、その境界線を探る必要がある

この問い自体が「SREの統一理論」についての重要な議論になるはずだ。

オンコール:十分なエンジニアがいないときの健康的な形

最後はオンコール。

• エンジニアが5人や10人しかいないスタートアップで、24x7オンコールを健康的に回すのはほぼ不可能

つまり、私たちは考えなければならない。

• 本当に24x7が必要なのか?
• 9-17時オンコールではダメなのか?
• 「そもそもページャーを持つべきかどうか」は、どの時点で判断すべきか?

「健康的なオンコール」とは何か、「どの規模から必要なのか」もまた、SREとして統一された答えがない領域で、議論のトピックになりうる。

全体を通してコメント

さすがに10年以上続いているだけであって、オリジナルを振り返る・批判的に見直す流れも出てきました。「技術・プラクティスは課題の形をしている」という表現をどこかで見た記憶がありますが、いつの時代も盲信的にはならずに、柔軟に解釈して取り入れる必要がありますね。ただ、このセッションは問題提起で終わっています。この流れの先にあるセッションなどをご存知でしたら、教えてください。アドベントカレンダー内で触れられそうであれば、意訳してみたいと思います。

フェーズ(必要なSLO)ごとの目安は、https://map.r9y.dev/beck/map.html でまとめられているものもあります。もしかすると、この方向が必要ということなんでしょうかね。

次回は、今回スタートアップでは数値を追うことは過剰ともいわれたSLOの基礎に立ち返ってみたいと思います。
SLO Basics - a conversation about reliabilityの意訳