slo-designer

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: クリティカルジャーニーを特定する

1. 対象サービスとユーザーにとって重要な経路（ログイン・検索・購入・決済 等）を洗い出す
2. それぞれで「何が起きたらユーザーは不幸か」を言語化する（遅い・失敗する・古いデータ）

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 違反＝即契約違反ではない点を明示する