## 概要 Indeed の VP of Engineering である [[Ketan Gangatirkar]] が SREcon18 Asia/Pacific（2018 年）で発表。SRE が SLO を設計・定義するという通例が、実はユーザー体験との大きなズレを生む構造的問題であることを指摘し、「共感を数値化する（quantify empathy）」という設計哲学でその問題を解消する手順を示す。具体的にはユーザー幸福の 6 フレーバーと S 字曲線による痛みのしきい値特定の 5 ステップフレームワークを提示する。 ## 主要メッセージ - **SRE は自分たちのユーザーではない**（p.16）：SLO がユーザー体験を決定し、SRE が SLO を決定するなら、SRE がユーザー体験を決定することになる——しかし SRE とユーザーはまったく異なる存在だ。 - **共感なき SLO は悪い SLO**（p.22）：SLO はユーザーが気にしている特徴量を SLI として選び、ユーザーが実際に痛みを感じる閾値に合わせなければ機能しない。 - **ユーザー幸福の 6 フレーバー**（p.91）：可用性・応答性・鮮度・完全性・精度・機能幅で SLI 候補を体系的に発見できる（助記符 #ARFCAapBof）。 - **SLO は痛みのしきい値より下に設定する**（p.148）：S 字曲線でユーザーが「使えない」と感じ始める点を特定し、そこより下を SLO の目標とする。 - **SLO がカバーしている範囲とユーザーが気にしている範囲がずれる 2 方向のリスク**（p.35, p.45）：カバー不足（ユーザーの問題を SLO が見ていない）とカバー過剰（ユーザーが気にしていない項目に SLO を張る）のどちらも失敗である。 ## 視覚的に重要な図表 **p.4 Indeed のアーキテクチャ概略** ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-004.png]] 複数の求人サイト（Job site 1〜∞）からクローリングして Indeed のクラウド DB に集約し、ユーザーへ提供するアグリゲーション型サービスの構造を示す。"One search. All jobs." というプロダクト価値がサービス停止で "No searches. No jobs." に転落することを視覚化する前提図。 **p.35 カバー不足の Venn 図（赤）** ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-035.png]] 外円＝ユーザーが気にする機能、内円＝SLO がカバーする機能。外円の方が大きい場合（SLO が小さい）、"Your users may notice problems your SLO doesn't cover"。 **p.45 カバー過剰の Venn 図（緑）** ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-045.png]] 外円＝SLO がカバーする機能、内円＝ユーザーが気にする機能。外円の方が大きい場合（SLO が過剰）、"Your SLO may cover things your users don't care about"。 **p.91 ユーザー幸福の 6 フレーバー一覧** ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-091.png]] 1) Availability、2) Responsiveness、3) Freshness、4) Completeness、5) Accuracy and precision、6) Breadth of functionality。助記符 `#ARFCAapBof` がスライド上に大きく表示されている。 **p.95 Tenfold の生産性対可用性 S 字曲線** ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-095.png]] 縦軸＝生産性（Productivity）、横軸＝可用性（Availability）の S 字曲線。SLO 99.95% で "I can do my job" ゾーンと "This is tolerable" ゾーンの境界が現れ、99.9% を下回ると "We're paying how much?!?!" 、99% では "Cancel the contract" に達する。痛みのしきい値を S 字曲線から特定する手法の具体例。 **p.120 S 字曲線の多様な形状** ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-120.png]] 縦軸＝ユーザー幸福度、横軸＝壊れ度合い（Brokenness）。4 本の異なる曲線（ピンク・黒・ティール・オレンジ）が示すように、サービス種別・ユーザータイプによって S 字の傾きや屈曲点が大きく異なる。 **p.130 SLO の構成要素** ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-130.png]] "What you can't control（オレンジ）" ＋ "What you have to work with（青）" ＝ Service Level Objective。制御不能なコンポーネントと作業可能なコンポーネントの両方を束ねて SLO を構成することを視覚化する。 **p.145 共感ギャップの 2×2 マトリクス** ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-145.png]] 行＝ユーザー感情（Sad/Happy）、列＝SLO 達成状況（Failing/Meeting）の 2×2 表。SLO 達成・悲しいユーザー＝「Empathy gap」、SLO 未達・嬉しいユーザー＝「Overkill」、その他 2 セルは良い状態。理想の SLO は "an accurate simulation" であるという中心主張を凝縮した図。 **p.148 共感を数値化する 5 ステップ** ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-148.png]] 1) ユーザーを知る、2) プロダクトがユーザーに何をするかを理解する、3) ユーザー幸福の 6 フレーバーを適用する、4) データでユーザーの痛みを探す、5) SLO を痛みのしきい値より下に設定する。 ## 口頭説明・補足 ### SRE の God Object アンチパターン（transcript） 「一人の人間がすべての意思決定をする」という単純な解は、ソフトウェア工学の God Object アンチパターンと同じ構造的欠陥を持つ。God Object はすべてを知り、すべてを制御しようとするコンポーネントだが、保守不能・不透明・スケール不能になる。SRE が組織全体の SLO を単独で定義しようとすると同じ問題が起きる。SLO 設計は「SRE だけの仕事」ではなく、マーケティング・ソフトウェアエンジニアリング・CEO も含めた全員の仕事だ（transcript）。 ### ユーザーペルソナ具体例（transcript） - **フラッグキャプチャーゲームのプレイヤー**：ラグ（の不在）を最優先とし、可用性にはあまり関心がない。ゲームが落ちても「少し残念」程度で、生命線ではない。可用性よりレスポンシブネスが支配的な SLO 設計が必要。 - **Tenfold の企業ユーザー**：カスタマーサポートエージェントが電話を取る前に顧客情報を確認する B2B ツール。可用性が下がると業務生産性が急落し、契約解除に直結する。SLO 99.95%（p.95）が「tolerable」の上限として設定されている。 ### 5 つの Why から SLO へ（transcript） 「なぜ PoP を追加するか？→ネットワークホップが減る→ページロードが速くなる→バウンス率が下がる→エンゲージメントが増える→収益が上がる」のような 5 つの Why チェーンで SRE の技術的判断をビジネス価値まで接続する。一方「なぜオートスケーリングを実装するか？→必要時に容量が増える→スループットが増える→データが新鮮になる→有用性が増す→リテンションが上がる」という別チェーンも存在する。どちらも適切だが、ユーザーへの接続なしに SLO 設計をしてはいけない。 ### 「制御不能なもの」と「作業可能なもの」（p.130, transcript） Indeed の Job Search は複数の外部求人サイトに依存しており、それらのサイトが落ちることは制御不能だ。しかし外部からのデータ品質低下が自分たちの処理パイプライン（Processed jobs）に与える影響は作業可能な範囲である。SLO はこの二つを束ねて設計する必要がある。 ## 概念・実体への接続 - [[サービスレベル目標]]（SLO 設計論の横断的知見を更新） - [[Ketan Gangatirkar]]（登壇者エンティティ） - [[Indeed]]（事例組織） - [[SRE.md]]（SRE の役割論との接続） - [[エラーバジェット]]（pain threshold → budget 設計との関係） ## 限界・不確実点 - 発表年月日は 2018 年として記録（SREcon18 Asia/Pacific の正確な開催日付は不明）。confidence: high は内容の確実性を指し、日付精度ではない。 - 6 フレーバーフレームワークが Indeed 内部での実証評価を経て提案されたものか、一般的フレームワークとして提案されたものかは transcript から判然としない。 - Tenfold の S 字曲線は具体的な Indeed の顧客データに基づくものか、例示であるかは不明。 - transcript は YouTube 自動字幕（機械精度）のため、固有名詞・数値の一部は不正確な可能性がある。スライド画像を優先。