# Reliability Equilibrium: The Hidden Playbook behind SRE Influence [[Daria Barteneva]]（[[Microsoft Azure]]、Principal SRE / Observability Engineering）による SREcon26 Americas（2026-03-26）の発表。スライド 60 ページ。 ## 概要 ゲーム理論のフレームワーク——ナッシュ均衡、囚人のジレンマ、Stag Hunt、公共財ゲーム、シュタッケルベルク戦略——を用いて、SRE が直面する社会技術的なトレードオフを分析する。信頼性と速度がなぜ対立して見えるのかを「悪い均衡への収束」として診断し、メカニズムデザインの視点から SRE ツール（エラーバジェット・カナリアデプロイ・プログレッシブロールアウト）が「良い均衡」へのインセンティブ設計として機能することを論じる。登壇者は 8 年前（SREcon18 EMEA）と同じ問い——オブザーバビリティの始め方、SLI/SLO、レガシーシステム、他チームを信頼性作業にコミットさせる方法——が繰り返されることへの問題意識から出発する。 ## 主要メッセージ - **SRE はシングルプレイヤー問題ではない** (p.10): 自分の成果が他者の選択に依存する構造が根本にある。 - **ナッシュ均衡は安定であって良いとは限らない** (p.12): チームが「フリーズ」に収束するのは合理的な個人行動の帰結であり、意志や能力の問題ではない。 - **SRE はメカニズムデザイン** (p.17): ゲームのルール（ペイオフ・情報・リスク帰属）を変えることで、より良い行動が合理的選択になる。 - **「良い意図で行動した」と「ひどい結果になった」は同時に真である** (p.20): 囚人のジレンマが証明する。 - **信頼性の失敗パターンは予測可能** (p.59): Stag Hunt（調整の失敗）、囚人のジレンマ（インセンティブの歪み）、公共財ゲーム（フリーライダー）、ベイジアンゲーム（不完全情報）の 4 類型で系統的に診断できる。 ## 視覚的に重要な図表 **p.1 タイトルスライド** ![[_attachments/sre26amer_slides_barteneva/page-001.png]] 登壇者（Daria Barteneva / Microsoft Azure）と、ゲームテーブルを囲む 4 体のキャラクターが示す「SRE はマルチプレイヤー問題」というビジュアルメタファー。 **p.12 ゲーム理論「なぜゲーム理論か？」** ![[_attachments/sre26amer_slides_barteneva/page-012.png]] ナッシュ均衡の定義：「各プレイヤーが他者の戦略を所与として自分の最良手を選んでいる状態」。Nash Equilibrium doesn't mean "good". It means stable. **p.15 ミニマルゲーム理論入門** ![[_attachments/sre26amer_slides_barteneva/page-015.png]] SRE 文脈のペイオフ例：Velocity・Reliability・Pager load・Risk・Reputation・Career safety。ペイオフは金銭でなく「各プレイヤーが気にすること」で定義。 **p.17 SRE の方法（メカニズムデザイン）** ![[_attachments/sre26amer_slides_barteneva/page-017.png]] ペイオフ変更（信頼性を合理的選択に）・情報変更（システム状態を共有知識に）・リスク帰属変更（所有権と結果を対応させる）の 3 軸。「SRE work is mechanism design. Redesign the game, so better behavior becomes the rational choice.」 **p.19 囚人のジレンマ利得行列** ![[_attachments/sre26amer_slides_barteneva/page-019.png]] 古典的 2×2 行列：Stay Silent/Stay Silent=(1yr,1yr)、Stay Silent/Confess=(3yr,0yr)、Confess/Stay Silent=(0yr,3yr)、Confess/Confess=(2yr,2yr)。Albert W. Tucker (1950) による。 ## ゲーム別の SRE 適用 ### 囚人のジレンマ — デプロイ凍結問題 (p.21-32) - **均衡の診断**: ロールバックが困難・テレメトリが弱い・変更後の責任追及が強い環境では「フリーズ」が支配戦略になる。Freeze/Freeze → Dev/SRE/Leadership = (2,4,3)。 - **DORA の証拠**: エリートパフォーマーはデプロイ頻度（速度）と変更失敗率（安全性）を同時に改善している。凍結戦略は「Safe but slow, local optimization」の象限に留まる。 - **情報の非対称性** (p.27): 「情報が不均等に分布しているとき、意思決定はローカルで最適化されてもグローバルに失敗する」（Hayek のパラフレーズ）。Principal-Agent 問題として定式化。 - **設計解** (p.30-32): (i) カナリア＋プログレッシブデリバリーでシッピングコストを下げる、(ii) リスクを蓄積させてフリーズのコストを顕在化、(iii) エラーバジェットでポリシーが判断を置換、(iv) シュタッケルベルク先手——SRE が SLO とガードレールを先にコミットし、チームが安全に出荷することが合理的応答になる。Ship/Ship → (5,4,5)。 ### Stag Hunt — 調整失敗問題 (p.35-38) - **構造**: 協調投資（Stag）vs 個人安全（Hare）の 2 均衡ゲーム。Stag/Stag=(3,3)、Hare/Hare=(1,1)。両方が Nash 均衡。 - **診断**: 「チームが Stag を避けるのは信頼性を求めていないからではなく、調整を信頼できないからだ」。Hare 均衡は「安定だが凡庸」。 - **設計解**: 信頼ではなく設計で調整を担保する。「Stag Hunt は、信頼性が設計ではなく信頼を必要とする場合に失敗する」。 ### ベイジアンゲーム — 不完全情報問題 (p.39-40) - 「欠けているコンテキストの多くは隠されているのではなく、前提とされている。人は自分が全員が理解していると思っていることを共有しない」（John Allspaw）。 ### 公共財ゲーム — フリーライダー問題 (p.41-47) - **公共財の例**: オンコール改善・ドキュメント・ランブック・プラットフォーム強化・検知・トイル削減。全員が恩恵を受けるがコストは個人持ち。 - **ポストモーテムも公共財**: 全員が学習から恩恵を受けるが、コスト（時間・脆弱性の開示）は個人が払う。浅いポストモーテムと低いフォロースルーが悪い均衡を形成する。 - **SLI/SLO は公共財メカニズム**: 共有 SLO は信頼性を共有ペイオフに変換し、フリーライダーを不可視でなくする。 ### 進化的ゲーム (p.54-57) - **パターン**: インシデント対処法 → 繰り返しの成功 → 標準慣行 → 自明の規範（この段階でゲームは人間が行うのでなく、文化が行うようになる）。 - **インシデント対応は繰り返しゲーム**: 英雄主義が報酬を受け、自動化が「来四半期」に先送りされる悪い均衡。変更手段：防止を報酬し、自動化をプロダクト作業として資金化し、オペレーション負荷を輪番制にする。 ## 信頼性を可視化する指標提案 (p.58) - 重要ユーザージャーニー中 SLI を持つ割合 - エラーバジェット消費率と変動性（穏やか vs スパイク） - SLO 脅威の検知レイテンシ（time-to-signal） - インパクトの表現を「乗り越えたインシデント数」ではなく「排除したリスク」として変換 ## まとめ：5 ステップのゲームエンジン設計 (p.59) 1. **プレイヤー** — 意思決定者の特定 2. **戦略** — 各プレイヤーが選べる行動 3. **ペイオフ** — 各結果から得るもの（速度・信頼性・ページャー負荷・評判・キャリア安全） 4. **均衡** — システムが収束している状態の診断 5. **ルール変更** — ペイオフ・情報・リスク帰属を設計し直す 「信頼性の問題は構造的であり、個人の問題ではない」。 ## 概念・実体への接続 - [[ゲーム理論とSRE]] — 本発表の中心概念 - [[Daria Barteneva]] — 登壇者 - [[Microsoft Azure]] — 登壇者の所属 - [[エラーバジェット]] — 囚人のジレンマ解として登場 - [[サービスレベル目標|SLO]] — 公共財メカニズムとして登場 - [[DORA]] — デプロイ凍結が "safe but slow" 象限に収束することの証拠として引用 - [[ポストモーテム]] — 公共財ゲームとしての分析 ## 限界・不確実点 - スライド p.21-60 は視覚確認不可（多画像読み込み制限）。PDF 抽出テキストで補完しており、図表の詳細値はスライド画像が権威である。 - DORA チャート（p.26）の 4 象限の具体的数値はテキスト抽出に含まれず未確認。 - transcript なし。口頭説明・Q&A は未取得。 - Daria Barteneva の所属チームは「Observability Engineering in Azure」と公式ページに明記。役職は Principal SRE（公式ページ本文より）。