| name | slo-designer |
| description | サービスの信頼性目標を SLI/SLO/エラーバジェットとして設計するスキル。SLIの選定、現実的なSLO設定、エラーバジェットとバーンレートアラート、SLAとの関係整理を支援する。「SLOを決めたい」「SLI/SLOを設計して」「エラーバジェットを設定して」「信頼性目標を決めたい」「バーンレートアラートを設計して」などで発動する。observability-designer の計装を前提とする。 |
| metadata | {"version":"1.0.0","tier":"experimental","category":"operations","tags":["slo","sli","error-budget","reliability","sre"]} |
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 を設定する
Step 4: エラーバジェットとポリシーを決める
- エラーバジェット = 1 − SLO。期間内に使い切ったらどうするか（バジェットポリシー）を合意する
- 例: 使い切ったら新機能リリースを止め信頼性改善を優先 / 残量豊富ならリスクを取ってよい
- これにより「速度 vs 信頼性」の意思決定がデータ駆動になる
Step 5: バーンレートアラートを設計する
Step 6: 文書化
SLI 定義・SLO 値・計測方法・エラーバジェットポリシー・アラート設定を表にまとめ、observability-designer の計装と incident-responder の重大度基準に接続する。
ガードレール
| 制限 | 内容 |
|---|
| 100% を目標にしない | 100% は非現実的でコスト過大。ユーザーが満足する最小の信頼性を狙う |
| ユーザー視点 | SLI はユーザー体験ベース。内部リソース指標を目標にしない |
| 計測可能性 | 測れない SLO を約束しない。計装(observability-designer)を前提に定義する |
| SLA と区別 | 契約上の SLA は SLO より緩く。SLO 違反＝即契約違反ではない点を明示する |
