エラーの予算とSLO管理

1）なぜSLOとエラー予算

SLO （Service Level Objective）-ユーザーが認識する目標品質レベル;SLI-測定メトリック；Error Budget-ウィンドウごとの偏差の許容差（通常30/90日）。
エラー予算は、信頼性を「抽象化」から管理リソースに変えます。予算がすぐに燃え尽きると、機能とchinimを凍結します。予算が健全な場合-あなたはリリースをスピードアップすることができます。

2） SLIピック： 「良い」とカウントするもの"

基準：「ユーザーの視点から成功」。

2.クラシックSLI×1

可用性は、成功したリクエストの割合です（クライアントによってキャンセルされたものを除く）。
'success=http_status ∈ {2xx、 3xx、 404} and no timeout' （404はセマンティクスが期待される場合、読み取りAPIの成功と見なすことができます）。
レイテンシ：リクエストの割合はスレッショルド（例えばp95 ≤ 300 ms）よりも速い。
'good_latency=duration_ms ≤ 300'を指定します。
Freshness/Staleness：「データがX分以上でない」（キャッシュ、ディレクトリ、係数）。
品質：結果の正確性（ビジネスバリデータ/バックエンド不変量の渡し）。

2.2境界とセグメント

SLIは'route'、 'tenant/brand'、 'region/conference'、 'payment_provider'という重要なスライスでカウントされるべきです。したがって、システム全体で1つの重要なハンドルの障害を「汚す」ことはありません。

3）数式と予算

3.1リクエストベース（APIに適しています）

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3.2タイムベース（バックグラウンドサービス/ストリーミング用）

SLO_uptime = good_minutes / total_minutes

3.3目標の例

API一般： 99。30日間で9％の可用性→予算=0。1%.

重要な支払いペン： 99。95%;カタログ/検索：99。5%.

レイテンシー：'/v1/payments'のp95 ≤ 300ミリ秒、p99 ≤ 800ミリ秒。

4） SLIの計装

4.1原則

ログ/トレイル→明示的なバケットを持つRED （Rate/Errors/Duration）メトリック。
必ず'tenant'、 'region'、 'route_class' （PIIなし）を入れてください。
「成功」と「合計」の2つのメトリクスを数え、レイテンシは「高速」と「合計」です。

4.2プロメテウス例（5mあたりのレート）

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5）燃焼率によるアラート（マルチウィンドウ、マルチバーン）

5.1アイデア

私たちは、予算が目標に対してどのくらいの速さで燃え尽きるかを見ています。短いウィンドウと長いウィンドウで速度が高い場合は、信号を送信します。

5.2しきい値プロファイル（SLO 99用。9%)

ページング：燃焼率≥ 14。4 × （1時間の予算の10％、6時間の5％）。
チケット：燃焼率≥ 6 × （6時間で2％、24時間で1％）。

5.3例則（Prometheus、擬似）

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

同様にチケットのための6h/24hのために。

6）予算のオフィス： プロセス

6.1リリースゲート

予算のバランスが25％未満で、トレンドがマイナスの場合-機能の「コードフリーズ」、優先順位はSRE/安定性です。
カナリアリリースには別個のSLOスライス（'deployment。environment=」canary」'）。

6.2バックログの優先順位付け

燃焼率と収益の影響に比例してコマンド容量を分配します。
「fix Xは燃焼率をY％削減する」という指標で技術的負債を正当化します。

6.3ポストインシデント

各インシデント-RCAと「ロールバックできない修正」（実行可能）、コントロールは「SLOに戻りました」。

7）コードとしてSLO

7.1 SLOマニフェスト例（YAML）

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7.2ルール生成

ジェネレータ（スロージェネレータ、pyrra、 sloth）を使用して、ルール、ダッシュボード、レポートを自動的に作成します。

8） SLOの劣化と保護

Load shedder：ピーク時に「高価な」依存関係なしに素早い回答を提供します。
キャッシュと古い：'stale-while-revalidate'を読む。
レート/並行限度：バックエンドを保護します。重要なルート-優先度。
回路/タイムアウト：高速タイムアウトと「フォールバック」ブランチ。
フィーチャーフラグ：ボタン1つで重いフィーチャーを無効にします。

9） SLOの観察可能性

ダッシュボード：SLO実際とターゲット、予算バランス、燃焼率、ルート/プロバイダによる貢献。
相関：SLO→の「穴」からexemplar→特定のトレース→ログ/プロファイルへ。
レポート：毎週-トレンド、予算の消費、劣化のトップの理由。

10） Antipatterns

全体のための1つの「グローバル」SLO→マスクの問題。セグメント。
«99.すべての99％"コストと現実を除く。ユーザーエクスペリエンスから目標を選択します。
バーンレート/SLOではなくCPU/ヒープアラート。
4xx/longリダイレクトを無視すると、UXが台無しになります。
不透明なウィンドウ（カレンダー対ローリング）-「オレンジとリンゴ」の比較。

11） iGaming/Financeの詳細

マネーパス（預金/出金）：全体的なレベルを超える個々のSLO（例：99.95％の可用性；p95 ≤ 250ms）。
PSP/KYCプロバイダ：各プロバイダのSLO+書き込みへの貢献に対するアラート。自動ルートスイッチング（スマートルーティング）。
管轄/テナント：地域の問題がグローバルメトリックを「洪水」しないように「地域/管轄/ブランド」によるSLOと予算。
責任あるゲーム：制限/自己排除（コンプライアンス式）の適用期間のSLO。
監査/規制：SLOとインシデントレポートを維持する。内部監査の透明性。

12） Prod Readinessチェックリスト

• SLI（可用性/遅延/品質/鮮度）およびセグメント（ルート/テナント/リージョン）が定義されています。
• 目標（SLO）は現実的で、ビジネスと整合しています。転がり窓があります30/90日。
• マルチウィンドウ（ページング/チケット）による書き込み速度によるアラート。
• コードとしてのSLO（ルール/ダッシュボードジェネレータ）；予算報告書です。
• 解放のゲートは予算の残りの部分に結ばれています；カナリアセクション。
• 劣化メカニズム（シェダー、キャッシュの老朽化、回路、限界）が実装され、テストされます。
• メトリクス↔トレイル相関、クリアランブック。
• 財務/管轄経路-個別のSLO/アラート；PSP/KYCは分離されます。
• 定期的なインシデントレトロとバーンベースの信頼性投資。

13） TL；DR（ドクター）

ユーザー値でSLIを定義し、現実的なSLOを設定し、エラー予算とマルチウィンドウでの書き込みレートを介して管理します。SLO-as-code、リリースゲート、劣化を計画通りに有効にします。ルート/テナント/地域別セグメント；お金のパスのためにより堅いターゲットおよび別の警報を保ちます。