ynitto slo-designer
「どれだけ信頼性が必要か」を数値で合意する。SLI（測る指標）→ SLO（目標値）→ エラーバジェット（許容する不信頼）→ アラート（消費が速いとき鳴らす）の順に設計する。
計測そのものの設計は
observability-designer。本スキルは「何を目標とし、破ったらどうするか」を定義する。
用語
| 用語 | 意味 |
|---|---|
| SLI | サービスレベル指標。ユーザー体験を表す測定値（成功率・レイテンシ等） |
| SLO | サービスレベル目標。SLI の目標値（例: 99.9% の成功率） |
| エラーバジェット | 1 − SLO。許容される不信頼の量（例: 99.9% なら月 ≈43分） |
| SLA | 顧客との契約上の保証。通常 SLO より緩く設定する |
詳細・早見表は references/sli-slo-guide.md。
ワークフロー
Step 1: クリティカルジャーニーを特定する
- 対象サービスとユーザーにとって重要な経路（ログイン・検索・購入・決済 等）を洗い出す
- それぞれで「何が起きたらユーザーは不幸か」を言語化する（遅い・失敗する・古いデータ）
Step 2: SLI を選ぶ
ユーザー視点の good events / total events で定義できるものを選ぶ:
| カテゴリ | SLI 例 |
|---|---|
| 可用性 | 成功レスポンス率（5xx を除く） |
| レイテンシ | しきい値内に応答した割合（例: 95% が 300ms 以内） |
| 品質/正確性 | 正しい結果を返した割合 |
| 鮮度 | データが N 分以内に更新されている割合 |
CPU 使用率のような内部指標を SLI にしない。ユーザーが感じる事象を選ぶ。
Step 3: SLO を設定する
- まず現状値を計測してから、現実的で少し挑戦的な目標を置く（いきなり 99.999% にしない）
- 計測ウィンドウ（28日ローリング等）を決める
- 「ナインの数」のコスト感を共有する（references/sli-slo-guide.md の早見表）
Step 4: エラーバジェットとポリシーを決める
- エラーバジェット = 1 − SLO。期間内に使い切ったらどうするか（バジェットポリシー）を合意する
- 例: 使い切ったら新機能リリースを止め信頼性改善を優先 / 残量豊富ならリスクを取ってよい
- これにより「速度 vs 信頼性」の意思決定がデータ駆動になる
Step 5: バーンレートアラートを設計する
- バジェットの消費速度でアラートする（残量ではなく速度）。速い消費＝重大
- 多段（速い消費=即ページ / 遅い消費=チケット）にしてノイズと見逃しを両立回避する
- 具体的な閾値例は references/sli-slo-guide.md
Step 6: 文書化
SLI 定義・SLO 値・計測方法・エラーバジェットポリシー・アラート設定を表にまとめ、observability-designer の計装と incident-responder の重大度基準に接続する。
ガードレール
| 制限 | 内容 |
|---|---|
| 100% を目標にしない | 100% は非現実的でコスト過大。ユーザーが満足する最小の信頼性を狙う |
| ユーザー視点 | SLI はユーザー体験ベース。内部リソース指標を目標にしない |
| 計測可能性 | 測れない SLO を約束しない。計装(observability-designer)を前提に定義する |
| SLA と区別 | 契約上の SLA は SLO より緩く。SLO 違反＝即契約違反ではない点を明示する |