slo-architect

SLO アーキテクト

意味のある SLO を定義します。世の中にある「SLO」のほとんどは、誰も信頼していない恣意的な数値です。すべてのエンドポイントで 99.9% とする一方、SLI の定義も、エラーバジェットも、バジェットが消費されたときの対応方針もありません。このスキルは、Google の SRE Workbook に基づく規律を徹底します。適切な SLI を選び、ユーザーが実際に重視する目標を設定し、エラーバジェットを計算し、複数ウィンドウのバーンレートアラートを設定し、バジェットが尽きたときの方針を書面で用意します。

使用する場面

• サービスや機能の新しい SLO を定義するとき
• 既存の SLO によくある不備がないか確認するとき
• 適切な SLI（イベントベース、時間ウィンドウベース、リクエストベース）を選ぶとき
• エラーバジェットとバーンレートアラートのしきい値を計算するとき
• SLO を既存の制御に結び付けるとき — 機能フラグによる中断、カオスの影響範囲、オペレーターの能力レベル

使用しない場面

• 一般的なオブザーバビリティ戦略（メトリクス＋ログ＋トレース）→ observability-designer を使用
• 法的拘束力のある顧客向け SLA → エンジニアリングではなく契約書の作成です
• パフォーマンス負荷テスト（信頼性ではなく容量）→ performance-profiler を使用
• 進行中のインシデント対応 → incident-response を使用

基本原則：SLO はユーザー体験に関する約束です

SLI  ⟶  measurable signal of user-perceived health (e.g., HTTP 2xx rate)
SLO  ⟶  target for the SLI over a window (e.g., 99.9% over 30 days)
SLA  ⟶  customer-facing commitment with consequences (separate concern)
EB   ⟶  error budget: 100% − SLO target = how much "bad" you can spend
BR   ⟶  burn rate: how fast you're consuming the error budget

よくある重大な間違いは次の 4 つです。

1. 目標が高すぎる（対応できないサービスで 99.99% 以上）— 小さな障害のたびに SLO 違反となり、アラートがノイズになります。
2. SLI が不適切（ユーザー体験の代替指標として CPU 使用率を使う）— ユーザーが困っているのに、システムは「正常」に見えることがあります。
3. エラーバジェットポリシーがない — 合意された対応がなければ、バジェットの消費は何の意味も持ちません。
4. 単一ウィンドウのバーンレートアラート — ノイズが多すぎる（5 分間の急増でページャー通知）か、遅すぎる（バジェットが尽きた後に気付く）かのどちらかです。

以下の 3 つのツールで、これらの問題をそれぞれ検出できます。

クイックスタート

SKILL=engineering/slo-architect/skills/slo-architect

# 1. Design an SLO
python "$SKILL/scripts/slo_designer.py" \
  --service checkout-svc \
  --sli-type request-success-rate \
  --target 99.9 \
  --window-days 30

# 2. Compute error budget + multi-window burn-rate alerts
python "$SKILL/scripts/error_budget_calculator.py" \
  --target 99.9 --window-days 30

# 3. Review existing SLO definitions for common bugs
python "$SKILL/scripts/slo_review.py" --slo-doc docs/slos/

3 つの Python ツール

すべて標準ライブラリのみを使用します。

slo_designer.py

必須フィールドを含む構造化された SLO 定義を生成します。必須フィールドが 1 つでも欠けている場合は、出力を拒否します（exit 1）。

python scripts/slo_designer.py \
  --service checkout-svc \
  --sli-type request-success-rate \
  --target 99.9 \
  --window-days 30 \
  --owner team-checkout

サポートされる SLI の種類：

• request-success-rate — (total_requests - bad_requests) / total_requests
• request-latency — count(requests < threshold) / total_requests
• availability-time — (window - downtime) / window
• data-freshness — count(data_age < threshold) / total_data_points
• correctness — count(correct_outputs) / total_outputs

デフォルトでは、すべての必須フィールドが入力済み、または <must define> と記された Markdown を出力します。JSON 出力（--format json）は slo_review.py で使用されます。

error_budget_calculator.py

目標可用性とウィンドウを指定すると、次の項目を計算します。

• ウィンドウ内で許容されるダウンタイム
• Google SRE Workbook（第 5 章）に基づく複数ウィンドウのバーンレートしきい値：
  • 高速バーン — 月間バジェットの 2% が 1 時間で消費された場合にページャー通知
  • 低速バーン — 6 時間で 10% が消費された場合にページャー通知、3 日間で 10% が消費された場合にチケットを作成
• 推奨アラートルール（PromQL 形式の出力）

python scripts/error_budget_calculator.py --target 99.9 --window-days 30
python scripts/error_budget_calculator.py --target 99.95 --window-days 7 --format json

slo_review.py

SLO 定義のディレクトリ（Markdown または JSON）を監査し、よくある不備を検出します。

python scripts/slo_review.py --slo-doc docs/slos/

チェック項目：

• target_too_high：目標値が 99.99% 以上（持続には大規模なエンジニアリング投資が必要）
• target_too_low：目標値が 99.0% 以下（おそらく SLI が不適切で、ユーザーが気付きます）
• window_too_short：ウィンドウが 7 日未満（統計的なノイズが支配的になります）
• window_too_long：ウィンドウが 90 日を超える（フィードバックが遅くなります）
• no_sli_definition：SLI セクションがない、または曖昧（「すべて正常」）
• no_error_budget_policy：バジェット消費時の対応が文書化されていない
• cpu_as_sli：ユーザー体験の代替指標として CPU／メモリを使用（不適切なシグナル）

SLI 選定の早見表

ユーザー体験	SLI の種類	測定内容
「リクエストは成功しましたか？」	request-success-rate	2xx / total
「レスポンスは速かったですか？」	request-latency	count(p99 < threshold) / total
「サービスは稼働していましたか？」	availability-time	(window - downtime) / window
「データは最新ですか？」	data-freshness	count(data_age < threshold) / total
「回答は正確でしたか？」	correctness	count(correct) / total

例とアンチパターンについては、references/sli_design.md を参照してください。

エラーバジェットの計算（基本）

30 日間の SLO が 99.9% の場合：

• 許容される停止時間：0.1% × 30 × 24 × 60 = 43.2 minutes
• 1 時間の高速バーンしきい値（月間予算の 2% を消費）：2% × 43.2 / 60 ≈ 1.44 ratio multiplier
• 6 時間の低速バーンしきい値（6 時間で 10% を消費）：10% × 43.2 / 360 ≈ 0.6 ratio multiplier

error_budget_calculator.py がこの計算を行い、そのまま貼り付けられるアラートルールを出力します。

ポートフォリオ内の他のスキルとの連携

このスキルは、次の 3 つのスキルと明示的に連携します。

スキル	連携内容
feature-flags-architect	ロールアウトの中止基準で、SLO のバーンレートしきい値を参照します
chaos-engineering	ブラスト半径計算ツールは月間エラーバジェットを入力として受け取るため、ここで定義します
kubernetes-operator	オペレーター機能の L4（Deep Insights）では、SLO と Prometheus ルールが必要です

error_budget_calculator.py の出力は、engineering/skills/chaos-engineering/scripts/blast_radius_calculator.py が標準入力で想定する形式と同じです。

ワークフロー

ワークフロー 1：新しい SLO の定義

1. Pick the user journey to protect (e.g., "checkout completion").
2. Choose SLI type (request-success-rate, latency, availability, freshness, correctness).
3. Define the SLI precisely: numerator/denominator with concrete labels.
4. Pick a target by measuring 30 days of historical SLI value:
     target = floor(p50 of last 30 days × 100) / 100
   This avoids targets the system has never sustained.
5. Pick a window (28 days = 4 calendar weeks, recommended).
6. Run slo_designer.py to render the SLO definition.
7. Run error_budget_calculator.py to get burn-rate alerts.
8. Write the error budget policy (what happens when budget burns).
9. Run slo_review.py — must pass before the SLO is "live".

ワークフロー 2：四半期ごとの SLO レビュー

1. For every active SLO, run slo_review.py — fix any FAIL findings.
2. Look at last quarter's data:
   - Was the SLO too easy (never burned budget)? Tighten target.
   - Was it too hard (frequently burned)? Loosen target OR fix the system.
   - Did burn-rate alerts fire usefully (not too noisy, not too late)? Adjust thresholds.
3. Audit error budget policies — were they actually followed when budget burned?
4. Commit revised SLOs; archive old versions with date stamps.

ワークフロー 3：SLO に基づくロールバック

1. New deploy starts burning error budget faster than baseline.
2. Burn-rate alert fires (from error_budget_calculator.py thresholds).
3. Auto-rollback via feature flag (kill switch from feature-flags-architect).
4. Postmortem feeds into next SLO revision.

参考資料

• references/slo_principles.md — SLI と SLO と SLA の違い、Google SRE Workbook の基本原則
• references/sli_design.md — 適切な SLI の選び方：例を含む 5 つの種類
• references/error_budget.md — エラーバジェットの計算、バーンレートアラート、予算ポリシー
• references/composition.md — SLO がフィーチャーフラグ、カオス、オペレーターにどう反映されるか

スラッシュコマンド

/slo-design — 3 つのツールをすべて実行する対話型 SLO 設計ウィザードです。

アセットテンプレート

• assets/slo_template.yaml — 入力可能な SLO YAML
• assets/error_budget_policy.md — 入力可能なポリシーテンプレート

アンチパターン

• すべてのエンドポイントに 99.99% を設定する — システムが実際に維持できるか誰も検証していない、コピー＆ペーストの SLO
• CPU 使用率を SLI にする — システムメトリクスはユーザー体験ではありません
• 単一ウィンドウのバーンレートアラート — 5 分ではノイズが多すぎ、30 日では遅すぎます
• エラーバジェットポリシーがない — 対応策がなければ、予算を消費しても意味がありません
• オーナーのいない SLO — 誰も責任を負わず、徐々に陳腐化します
• SLO を年に 1 回だけレビューする — システムの特性はそれより速く変化します
• SLO ドキュメントに SLA を記載する — 対象読者も重要度も異なるため、分けて管理します
• SLO の目標値を SLA の目標値と同じにする — SLO はより厳しくする必要があります（顧客に気づかれる前に、契約上の水準を上回る必要があります）

検証可能な成功基準

このスキルを使うチームは、次の基準を達成する必要があります。

• すべての SLO が slo_review.py に合格し、FAIL の指摘が 0 件である
• すべての SLO に、文書化されたオーナー、エラーバジェット、バーンレートアラート、ポリシーがある
• 対象となる SLO ごとに、バーンレートアラートの発火回数が月 2 回以下である（ノイズではなくシグナル）
• SLO 違反の平均検知時間が 30 分未満である（複数ウィンドウのバーンレートアラートが機能している）
• 四半期ごとの SLO レビューを毎四半期実施する（年 1 回ではない）