@2020__SREcon20Americas__Avoiding Goodhart's Law

# Avoiding Goodhart's Law: Use SLO's as Tools Not Cudgels (SREcon20 Americas) Navigation: [[index]] | [[グッドハートの法則]] | [[サービスレベル目標]] | [[SLI-SLO段階的導入]] 登壇者: [[Marco Coulter]]（@marcocoulter）所属: [[AppDynamics]]（Cisco 傘下）、Technical Evangelist for AIOps イベント: SREcon20 Americas（バーチャル開催）/ 2020-12-07 12:40–13:20 動画: https://www.youtube.com/watch?v=iKjKFeTSJGs（Whisper 文字起こし取得済み） --- ## 概要 AppDynamics の Marco Coulter が、SLO を「ツール」として使うか「棍棒（cudgel）」として使うかという観点から、グッドハートの法則が SRE 実践に与える悪影響を解説した SREcon20 Americas のトークである。医療ラボ処理システム（HL7 メッセージング）を一貫した事例として用い、Code・Infrastructure・Business & CX という 3 次元の SLI/SLO/SLA 定義フレームワークと、SLO 交渉の反復プロセスを提案する。2020 年 12 月に COVID-19 によりバーチャル開催された SREcon20 Americas での発表。 ## 主要メッセージ - **グッドハートの法則の SRE 版**: SLO が「達成すべき目標」として組織のプレッシャーになると、チームはシステムを改善せず SLO をゲームする。例：「キュー深度 100 以下」という SLO に対してメッセージを削除してゲームする（p.7〜9）。 - **3 次元フレームワーク**: SLI/SLO/SLA は Code（トランザクション成功率）・Infrastructure（パフォーマンスカーブ）・Business & CX（行動ベース SLI）の 3 次元で評価することで、ゲーミング耐性が高まる（p.13〜28）。 - **パフォーマンスカーブ SLO**: 単一閾値ではなく「90%/30s・99%/1min・99.9%/5min」のような多段パーセンタイル定義が「予測可能な変動」を提供する（p.22〜23）。 - **結果で管理する**: 指標ではなくアウトカムを管理すること。罰則ではなく報酬の仕組みを使うこと（p.32）。 - **交渉スキルを加える**: SLO 設定は技術だけでなく交渉のプロセスである。反復的な合意形成が必要（p.30〜31）。 ## 視覚的に重要な図表 **p.13 The SLI, SLO, SLA Model** ![[_attachments/2020__SREcon20Americas__Avoiding-Goodharts-Law/page-013.png]] SLI = *n*（ネスト可能な複合 SLI を含む）、SLO = *n <= xxx* または *xxx <= n <= yyy*（範囲指定可）、SLA = エラーバジェット消化時の結果。「Slowdown is the New Outage」を参照し、CX ドメイン可用性 = (成功リクエスト)/(全リクエスト) を含めることを強調。 **p.18 Code Example（完全版: SLI + SLO + SLA）** ![[_attachments/2020__SREcon20Americas__Avoiding-Goodharts-Law/page-018.png]] SLI: 「well-formed HL7 updates for Labs receive OK responses per APM tool」（トランザクション・反応・ソースを明示）。SLO: 99.9%。SLA: 99.1% over 28 days else `<action>`。 **p.23 Infrastructure Example（完全版: パフォーマンスカーブ SLO）** ![[_attachments/2020__SREcon20Americas__Avoiding-Goodharts-Law/page-023.png]] SLI: 「HL7 Lab update transaction total transaction time per APM tool」。SLO（パフォーマンスカーブ）: 90%/30s・99%/1min・99.9%/5min。SLA: 99.5%/5min over 24h else `<action>`。 **p.25 Dimensions（3 次元全体像）** ![[_attachments/2020__SREcon20Americas__Avoiding-Goodharts-Law/page-025.png]] Business 次元（Browser Real-User・Mobile Real-User・Synthetic・IoT）/ Code 次元（Java・.NET・PHP・C++・Go 等）/ Infrastructure 次元（Server/DB Visibility・Docker・Kubernetes・Mainframe・Azure・AWS・OpenShift 等）の 3 層スタック図。 **p.28 Business & CX Example（完全版）** ![[_attachments/2020__SREcon20Americas__Avoiding-Goodharts-Law/page-028.png]] SLI: 「Patient lookups repeated beyond 10s and within 5m per Patient Record Application」（技術的エラーではなくユーザーの再試行行動を SLI として定義）。SLO: < 0.5%。SLA: < 1% over 8h else `<action>`。 **p.31 Negotiation Flow** ![[_attachments/2020__SREcon20Americas__Avoiding-Goodharts-Law/page-031.png]] Warmup → Test Drive → Assess → Propose → [RECUR] → Agree の反復フロー。SLO は一回の合意ではなく繰り返し交渉するものとして示す。 **p.32 Avoiding Goodhart's Law（まとめ）** ![[_attachments/2020__SREcon20Americas__Avoiding-Goodharts-Law/page-032.png]] まとめ: 指標ではなくアウトカムで管理 / 罰則より報酬 / 3 次元で SLI/SLO/SLA を評価 / 予測可能な変動が勝る / 交渉スキルを加える。 ## 事例: Gaming the System（Labs Processing）医療ラボシステムの HL7 メッセージング処理（患者→メッセージキュー→サーバー→ラボ機器）を題材にした「ゲーミング」の例（p.5〜9）。 1. **通常フロー**: 患者採血 → HL7 データがメッセージキュー（MQ）経由でサーバーへ、さらにラボ機器へ転送（p.6）。 2. **Queue Failure（p.7）**: MQ 障害により HL7 メッセージがサーバー側でスタック。SLO が「キュー深度 100 以下」であればメッセージを削除することで達成できてしまう。 3. **TX Failure（p.9）**: MQ は回復したが下流のラボ機器（送信側）が障害。HL7 メッセージが宛先で積み上がる。単一指標の SLO ではこの障害パターンを捉えられない。この事例から、単一の技術指標 SLO は「その指標を改善する行動」と「実際のシステム健全性向上」を分離できないことを示す。 ## SLI 定義の 3 要素（Code 次元） Code 次元の SLI は以下を明示する（p.16）: | 要素 | 意味 | 例 | |---|---|---| | Specify the transaction | どのトランザクションか | well-formed HL7 updates for Labs | | Specify the reaction | 期待される応答は何か | receive OK responses | | Specify the source | どのツール・ソースで計測するか | per APM tool | ## SLO/SLA の時間窓比較（3 次元） | 次元 | SLA 時間窓 | 備考 | |---|---|---| | Code | 28 日間 | 長期でのコード品質契約 | | Infrastructure | 24 時間 | インフラは短周期で監視 | | Business & CX | 8 時間 | ビジネス影響は即時性が高い | SLA の時間窓は次元によって大きく異なる。CX は 8 時間と最も短く、ビジネスインパクトの即時性を反映する。 ## SLO 交渉の準備（p.30） - **Know thyself**: 現実的にどれだけのリスクを一定期間に吸収できるか / リスクは均等に分散されているか / 12 か月後・24 か月後は状況が変わるか - **Estimate your boundaries**: リスク境界の見積もり - **Draft your strategy model**: 交渉戦略の草案 - **Identify your facilitator**: ファシリテーターの特定 - **Schedule your negotiation**: 交渉の日程確保 ## 口頭説明・補足 ### 登壇者バックグラウンド（Whisper より） Marco Coulter はオーストラリア出身の元 CTO。国際的な大手銀行（トップ 50 入り）・病院とサービスプロバイダ向けデータセンター支援・業界大手ベンダー複数社を経験。3 か国に居住し 13 か国のチームを管理した。5 年間 451 Research（S&P Global Market Intelligence のデータサイエンスチームリーダー）として業界アナリストを務めた後、AppDynamics へ。「オペレーター・デベロッパー・アナリスト・ベンダー・バイヤー・CTO と、技術を全ての角度から見てきた」という独自の視点を持つ（transcript より）。 ### Labs Processing の実話背景スライドの事例は架空ではなく、Marco がオーストラリアで実際に関わったシステムの実話である。 - 対象: オーストラリアのある州内の全病院をカバーするサービスプロバイダが運用する HL7 メッセージングシステム。 - 物理的背景: 病棟は 16 階のような高い階にあり、ラボは別棟の地下にある。かなりの距離があった。 - システムダウン時のバックアッププロシージャ: **看護師が病棟からラボへ物理的に走って結果を取りに行く**ことが要求されていた（患者の健康へのリスクと、看護師が病棟を離れることのリスクが生じていた）。 - SLA の内容: 「メッセージキューが 100 を超えたらサービスプロバイダは返金する」という契約を結んでいた（transcript より）。 ### キューが空でも問題が続いた理由（核心的失敗パターン）「看護師から電話がくる。でも見るとキューが空。問題はトランザクションがメッセージキューに到達する前にタイムアウトしていた」——これが「管理は指標ではなくアウトカムへ」という教訓の起源。キュー深度だけを SLO にした結果、チームはキュー処理への設備投資（キャパシティプランニング）を行い、キューは空になったが、患者記録の更新という本来の目標は達成されていなかった（transcript より）。 ### SLI の測定ツールについて「AppDynamics が馴染み深いが、Datadog や New Relic でも全く同じように使える。コードだけを対象とするなら Honeycomb や Instana のようなオブザーバビリティツールを好む人もいるかもしれない」——`per APM tool` という SLI 定義の「ソース」要素は APM ツール非依存の書き方になっている（transcript より）。 ### Well-Formed HL7 を SLI 対象にした理由コードで制御できない要素が多かったため、エラー比率（故障数/総数）ではなく「well-formed（整形済み）」更新を SLI の対象にした。HL7 メッセージを出力するラボ機器のコードはベンダー依存で修正できず、MQ システムも third-party 製品だった。「そのコードを修正できない。パッチを待つしかない」——このため、自チームが制御できるコードへ到達した well-formed メッセージだけを SLI の起点とする設計が必要だった（transcript より）。 ### SLO 目標値の原則「100% の SLO を設定する人がいるが、それは実験も革新もないということを意味する。SLO は『かろうじて満たせば典型的な顧客が満足できる』レベルに設定すべきだ。高すぎると機会コストが無駄になる」（transcript より）。 ### インフラ SLO の 5 分保証がどのように決まったか（重要な背景）看護師へのヒアリングで判明した。通常、ユーザーは「できるだけ速く」を要求すると予想していたが、看護師たちの認識は異なっていた。 **「サンプルがラボに届くまでに時間がかかる。だから採血から結果が返ってくるまである程度の遅延は想定している」**——看護師たちは処理時間の全体像を把握していた。判断基準は「システムがダウンしたとき、医師に緊急指示された看護師が病棟からラボまで走る時間を超えないこと」。1 つの病院での実測値が**約 10 分**だったため、「5 分を保証する」と提案したところ看護師たちは「とても喜んだ、大喜びだった（very happy, very ecstatic）」。 **「常に最速である必要はない。必要なだけ速ければよい。」** この経験が不必要なインフラコストを回避させた。対比として、銀行の株式取引システムは「処理速度が競争上の差別化要因であり、コストを気にせず最速を求める」文化だったと述べた（transcript より）。 ### CX SLI「再試行パターン」の発見プロセス病棟での行動観察と看護師（**医師より看護師に聞くべき——実際の仕事内容をよく知っている**）へのヒアリングから発見した。看護師には「ラボ結果がいつ来るか」について直感的な期待があり、更新がなければ別の作業をして数分後に再度確認するという行動パターンがあった。**「その繰り返し検索（repeated record lookups）が、私たちが彼らの直感的な期待に応えられていないサインだった。そして間もなく電話で苦情が来る」**——この観察に基づいて患者記録アプリケーションに再試行カウンターを実装した（transcript より）。 ### 「10 秒以上」という条件の追加理由最初は「5 分以内の再試行」だけで SLI を定義したが、「記録処理は正常なのに SLO を達成できない」問題が発生した。「ひたすら連打し続ける看護師」の存在がわかった——待てない人が何度も Enter を押し続けることで再試行カウントが増加していた。**「そういう人を除外するために『10 秒以上経ってから』という条件を追加した」**（transcript より）。この経緯が示す重要な点: SLI/SLO は時間をかけて理解が深まるにつれて再定義・再交渉されるものである。 ### 8 時間という CX SLA 時間窓の由来看護師が「シフト単位で考える」ことから来ている。「28 日間？いや、8 時間でいい。シフトが終わるまでに戻ってくれれば、患者記録と書類を完了できる」——看護師たちのシフト文化に合わせた SLA 設計（transcript より）。 ### SLI の粒度設計原則（口頭）「SLI はシステム境界またはチーム境界で定義せよ。**システム境界の強みは変化しにくいこと**（システム全体を替えないと変わらない）だが、細かくなりすぎることがある。**チーム境界の強みは責任の割り当てが容易**なこと（このSLIはあなたのチームが責任を持つ、と言える）」（transcript より）。 ### 交渉フロー各ステップの詳細（口頭補足） - **Warmup**: 「スコープ・対象アプリケーション・次元・ビジネス価値・参加する利益」を設定。全員に話させる（各自 1〜2 分）。長くなったら礼儀正しく止める。 - **Test Drive**: 「SLI/SLO/SLA のチェーンの具体的な例を 1 つ提示」。本物の例を使う——最終合意に生き残れる可能性があるものを。 - **Assess**: ビジネス価値・ROI・革新とリスクのバランス・アクションの内容（返金か予算移転か開発凍結か）。**「假定の明確化（clarifying assumptions）が重要——SLA の脚注が SLA 本文より長くなることがある」**（transcript より）。 - **Propose**: 「**予測可能性は速さよりもほとんど常に重要**。応答時間の分散が大きいほどユーザー体験は悪化する。3〜6 標準偏差を超えるスプレッドは避けよ。6 標準偏差超は工程能力の低さを示す」（transcript より）。 - **RECUR**: 「これが本当の交渉が起きるステージ。複数回の会議が必要になるかもしれない。毎回ウォームアップし直す——スコープのリステートと前回の要約と各参加者への敬意表明」（transcript より）。 - **Agree**: 「最終 SLI/SLO/SLA の承認。**内部の SLI/SLO エラーバジェットでも、メールで全員にコミットさせること**。理由は 2 つ：記録として残すため、そして渋る人を発見するため（渋る人がいれば Assess フェーズで見落とした点がある）」（transcript より）。 ### 発表の位置づけ「これは私にとってこのプレゼンテーションの初回。フィードバックをもらえると嬉しい」——SREcon20 Americas がこのトークの初演だった（transcript より）。 ## 概念・実体への接続 - [[グッドハートの法則]]: 本スライドの核心テーマ。SRE 文脈での SLO ゲーミングへの応用 - [[サービスレベル目標]]: SLI/SLO/SLA の 3 次元定義・パフォーマンスカーブ SLO - [[SLI-SLO段階的導入]]: SLO 交渉プロセス・3 次元評価フレームワーク - [[Marco Coulter]]: 登壇者（AppDynamics Technical Evangelist for AIOps） - [[AppDynamics]]: 登壇者所属組織（Cisco 傘下、APM ツール提供） ## 限界・不確実点 - Q&A セッションは動画・文字起こしに含まれていない（SREcon20 Americas はバーチャル開催で Q&A が Slack チャンネルで行われた可能性がある。文字起こし末尾に「Slack チャンネルで会いましょう」とある）。 - `<action>` の具体的内容は SLA 条項に委ねられており、スライドでは示されていない。文字起こしでは「返金・予算移転・開発周期の凍結」が候補として言及された。 - 文字起こし末尾（「Give me a second. Unless it's denised way for weeks.」等）は不明瞭。バーチャル会議のアクシデントと推測される。 - 「オーストラリアのある州」の具体名は非開示。「物理的に米国大陸本土の 3 分の 1 に相当する地理的範囲に病院が散在していた」という記述のみ。