slo-implementation

SLO の実装

サービスレベル指標（SLI）、サービスレベル目標（SLO）、エラーバジェットを定義して実装するためのフレームワークです。

このスキルを使用しない場合

• タスクが SLO の実装に関係しない場合
• この範囲外の別のドメインやツールが必要な場合

手順

• 目標、制約、必要な入力を明確にします。
• 関連するベストプラクティスを適用し、結果を検証します。
• 実行可能な手順と検証方法を提示します。
• 詳細な例が必要な場合は、resources/implementation-playbook.md を開きます。

目的

SLI、SLO、エラーバジェットを使用して測定可能な信頼性目標を実装し、信頼性とイノベーションの速度のバランスを取ります。

このスキルを使用する場合

• サービスの信頼性目標を定義する
• ユーザーが感じる信頼性を測定する
• エラーバジェットを実装する
• SLO ベースのアラートを作成する
• 信頼性目標を追跡する

SLI／SLO／SLA の階層

SLA (Service Level Agreement)
  ↓ Contract with customers
SLO (Service Level Objective)
  ↓ Internal reliability target
SLI (Service Level Indicator)
  ↓ Actual measurement

SLI の定義

一般的な SLI の種類

1. 可用性 SLI

# Successful requests / Total requests
sum(rate(http_requests_total{status!~"5.."}[28d]))
/
sum(rate(http_requests_total[28d]))

2. レイテンシ SLI

# Requests below latency threshold / Total requests
sum(rate(http_request_duration_seconds_bucket{le="0.5"}[28d]))
/
sum(rate(http_request_duration_seconds_count[28d]))

3. 書き込み成功 SLI

# Successful writes / Total writes
sum(increase(storage_writes_successful_total[28d]))
/
sum(increase(storage_writes_total[28d]))

参考： references/slo-definitions.md を参照してください。

SLO 目標の設定

可用性 SLO の例

以下のダウンタイム換算値は、時間ベースの SLI、30 日の月、365 日の年を前提としています。トラフィックモデルなしに、リクエストベースの予算をダウンタイムに換算しないでください。

SLO %	月間ダウンタイム	年間ダウンタイム
99%	7.2 時間	3.65 日
99.9%	43.2 分	8.76 時間
99.95%	21.6 分	4.38 時間
99.99%	4.32 分	52.56 分

適切な SLO の選択

考慮事項：

• ユーザーの期待
• ビジネス要件
• 現在のパフォーマンス
• 信頼性のコスト
• 競合他社のベンチマーク

SLO の例：

slos:
  - name: api_availability
    target: 99.9
    window: 28d
    sli: |
      sum(rate(http_requests_total{status!~"5.."}[28d]))
      /
      sum(rate(http_requests_total[28d]))

  - name: api_latency_under_500ms
    target: 99
    window: 28d
    sli: |
      sum(rate(http_request_duration_seconds_bucket{le="0.5"}[28d]))
      /
      sum(rate(http_request_duration_seconds_count[28d]))

エラーバジェットの計算

エラーバジェットの計算式

Error Budget = 1 - SLO Target

例：

• SLO：可用性 99.9%
• エラーバジェット：0.1% = 月間 43.2 分
• 現在のエラー：0.05% = 月間 21.6 分
• 残りの予算：50%

エラーバジェットポリシー

error_budget_policy:
  - remaining_budget: 100%
    action: Normal development velocity
  - remaining_budget: 50%
    action: Consider postponing risky changes
  - remaining_budget: 10%
    action: Freeze non-critical changes
  - remaining_budget: 0%
    action: Feature freeze, focus on reliability

参考： references/error-budget.md を参照してください。

SLO の実装

Prometheus 記録ルール

# SLI Recording Rules
groups:
  - name: sli_rules
    interval: 30s
    rules:
      # Availability SLI
      - record: sli:http_availability:ratio
        expr: |
          sum(rate(http_requests_total{status!~"5.."}[28d]))
          /
          sum(rate(http_requests_total[28d]))

      # Latency SLI (requests < 500ms)
      - record: sli:http_latency:ratio
        expr: |
          sum(rate(http_request_duration_seconds_bucket{le="0.5"}[28d]))
          /
          sum(rate(http_request_duration_seconds_count[28d]))

  - name: slo_rules
    interval: 5m
    rules:
      # SLO compliance (1 = meeting SLO, 0 = violating)
      - record: slo:http_availability:compliance
        expr: sli:http_availability:ratio >= bool 0.999

      - record: slo:http_latency:compliance
        expr: sli:http_latency:ratio >= bool 0.99

      # Error budget remaining (percentage)
      - record: slo:http_availability:error_budget_remaining
        expr: |
          (sli:http_availability:ratio - 0.999) / (1 - 0.999) * 100

      # Error budget burn rate
      - record: slo:http_availability:burn_rate_5m
        expr: |
          (1 - (
            sum(rate(http_requests_total{status!~"5.."}[5m]))
            /
            sum(rate(http_requests_total[5m]))
          )) / (1 - 0.999)

以下の枯渇予測は、直近のバーンレートが一定であることを前提としています。バーンレートがゼロの場合、枯渇までの時間は有限になりません。予算を使い切った場合は、すでに枯渇している状態として表示する必要があります。テレメトリが欠落している状態を、正常なトラフィックとして扱わないでください。

エラーがゼロの場合のカウンターを初期化するか、同じ正常イベント数／合計イベント数の母集団から不良イベントを算出してください。5xx 系列が存在しないことで、バーン／コンプライアンスルールが暗黙のうちに無効化されてはなりません。エラーゼロ、トラフィックなし、テレメトリ欠落のケースは、それぞれ個別にテストしてください。

追加のバーンレート記録ルール

アラートの例を使用する前に、これらのルールを同じ記録ルールグループに含めてください。

- record: slo:http_availability:burn_rate_1h
  expr: (sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h]))) / (1 - 0.999)
- record: slo:http_availability:burn_rate_6h
  expr: (sum(rate(http_requests_total{status=~"5.."}[6h])) / sum(rate(http_requests_total[6h]))) / (1 - 0.999)
- record: slo:http_availability:burn_rate_30m
  expr: (sum(rate(http_requests_total{status=~"5.."}[30m])) / sum(rate(http_requests_total[30m]))) / (1 - 0.999)

SLO アラートルール

groups:
  - name: slo_alerts
    interval: 1m
    rules:
      # Fast burn: 14.4x rate, 1 hour window
      # Approximately 2.14% of a 28-day budget in 1 hour at constant traffic
      - alert: SLOErrorBudgetBurnFast
        expr: |
          slo:http_availability:burn_rate_1h > 14.4
          and
          slo:http_availability:burn_rate_5m > 14.4
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Fast error budget burn detected"
          description: "Error budget burning at {{ $value }}x rate"

      # Slow burn: 6x rate, 6 hour window
      # Approximately 5.36% of a 28-day budget in 6 hours at constant traffic
      - alert: SLOErrorBudgetBurnSlow
        expr: |
          slo:http_availability:burn_rate_6h > 6
          and
          slo:http_availability:burn_rate_30m > 6
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Slow error budget burn detected"
          description: "Error budget burning at {{ $value }}x rate"

      # Error budget exhausted
      - alert: SLOErrorBudgetExhausted
        expr: slo:http_availability:error_budget_remaining < 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "SLO error budget exhausted"
          description: "Error budget remaining: {{ $value }}%"

SLO ダッシュボード

Grafana ダッシュボードの構成：

┌────────────────────────────────────┐
│ SLO Compliance (Current)           │
│ ✓ 99.95% (Target: 99.9%)          │
├────────────────────────────────────┤
│ Error Budget Remaining: 65%        │
│ ████████░░ 65%                     │
├────────────────────────────────────┤
│ SLI Trend (28 days)                │
│ [Time series graph]                │
├────────────────────────────────────┤
│ Burn Rate Analysis                 │
│ [Burn rate by time window]         │
└────────────────────────────────────┘

クエリの例：

# Current SLO compliance
sli:http_availability:ratio * 100

# Error budget remaining
slo:http_availability:error_budget_remaining

# Days until error budget exhausted (at current burn rate)
(slo:http_availability:error_budget_remaining / 100) * 28
/
slo:http_availability:burn_rate_5m

複数ウィンドウのバーンレートアラート

# Combination of short and long windows reduces false positives
rules:
  - alert: SLOBurnRateHigh
    expr: |
      (
        slo:http_availability:burn_rate_1h > 14.4
        and
        slo:http_availability:burn_rate_5m > 14.4
      )
      or
      (
        slo:http_availability:burn_rate_6h > 6
        and
        slo:http_availability:burn_rate_30m > 6
      )
    labels:
      severity: critical

SLO レビュープロセス

週次レビュー

• 現在の SLO コンプライアンス
• エラーバジェットの状況
• 傾向分析
• インシデントの影響

月次レビュー

• SLO の達成状況
• エラーバジェットの使用状況
• インシデントの事後分析
• SLO の調整

四半期レビュー

• SLO の妥当性
• 目標の調整
• プロセスの改善
• ツールの強化

ベストプラクティス

1. ユーザー向けサービスから始める
2. 複数の SLI を使用する（可用性、レイテンシなど）
3. 達成可能な SLO を設定する（100% を目指さない）
4. 複数ウィンドウのアラートを実装してノイズを減らす
5. エラーバジェットを一貫して追跡する
6. SLO を定期的に見直す
7. SLO の決定事項を文書化する
8. ビジネス目標に合わせる
9. SLO レポートを自動化する
10. 優先順位付けに SLO を活用する

参考ファイル

• インラインの例 - SLO 定義テンプレート
• references/slo-definitions.md - SLO 定義のパターン
• references/error-budget.md - エラーバジェットの計算

関連スキル

• prometheus-configuration - メトリクス収集用
• grafana-dashboards - SLO の可視化用

制限事項

• このスキルは、タスクが上記のスコープに明確に一致する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、専門家によるレビューの代替として扱わないでください。
• 必要な入力、権限、安全境界、成功基準が欠けている場合は、作業を中断して確認を求めてください。