SLO/SLAとメトリクス

SLO/SLAとメトリクス

1）用語と階層

SLI（サービスレベルインジケータ）-「ユーザーが私たちを見ているように」測定可能なインジケータ：成功したリクエストの共有、P95レイテンシ、データの鮮度、正常に処理されたバッチの共有など。

SLO （Service Level Objective）-観測間隔（28/30/90日）でSLI値をターゲットにします。例： "99。リクエスト/ペイエンドの9％ ≤ 400ミリ秒"

エラー予算-1 − SLO。SLO 99。9％エラー予算=0。時間/リクエストの1％。
SLA（契約）-法的に重要なサービスレベル：SLO、測定、例外、補償/罰金が含まれます。

2）設計原則

症状>内部指標。SLIは実際のユーザーエクスペリエンスを反映する必要があります。
少数の鍵SLI。サービスの場合-2-5メイン：成功、レイテンシ、スループット/鮮度、正確さ。
重要な経路のカバレッジ。各ビジネスシナリオ（チェックアウト、ログイン、Webhook、 ETLダウンロード）には、独自のSLI/SLOがあります。
厳密な「成功」意味論。「code 200」ではなく「、ユーザーが時間通りに応答を受信し、結果は有効」です。
外部SLOと内部SLOの分離。内部-より厳密な；外付けSLA ≤ 1-2 nines下がります。

3） SLIのカタログ（参照）

3.1 API/オンラインサービス

成功： 'SLI_success=1 − （5xx+timeout+business_error）/all_requests'

レイテンシー： route/method/tenantによるp95/p99 'http_server_duration_seconds'

帯域幅： 'RPS '/limits/quotas

正当性： 有効な応答の割合（署名、スキーマ、不変量）

3.2 Webhook/非同期配信

配信： T秒と≤ Nリトレイで確認されたイベントの割合

顧客： 長期間の遅れのない加入者の割合（テナントごと）

3.3 データ/ETL/DWH

新鮮さ： '今 '

完全性： 'ingested_rows/ expected_rows'

Correctness： 品質チェックに合格したレコードの割合

パイプライン： 締め切り前に完了したジョブのシェア

3.モバイル/クライアントSDK×4

クライアントの成功： 致命的なエラーのないセッションの割合

往復レイテンシー： リクエストからレンダリングまでのp95

キャッシュのヒット数： キャッシュから得られる割合（パフォーマンスの症状として）

4）数式と目標例

• 'SLI_req_avail=1 − （failed_requests/ total_requests）'
• 'SLO_req_avail=99。30日間95％'→エラー予算=0。05％のリクエスト。

• 'uptime=（obs_window − downtime）/obs_window'

• 'SLO_latency=p95 （route=「/pay」）≤キャッシュウォームアップ（1％）を除く7日間のスライスで400ミリ秒%)

• 'SLO_freshness （dataset=「orders」） ≤ 24時間で10分'p99。

5）エラーの予算と変更管理

予算（B）： 'B=1 − SLO'。
「書き込み」（Burn）-実際のエラーと許容されるエラーの比率。

• オーバースペンド（燃焼>1）→フィーチャーフリーズ、信頼性に焦点を当てます。
• 燃焼率で>短いウィンドウでX-インシデントとキャップ。対策。
• プランニング：スプリントの信頼性のシェアは、過去の期間にわたって燃焼と相関します。

6）警告： 燃焼率とマルチウィンドウのルール

アイデア：私たちは速いリークと遅いドリフトをキャッチします。

例（SLO 99。9％、予算0。1%):

クリティカル：「1時間で2％の予算」（高速火災）。
警告：「6時間で予算の5％」（忍び寄る劣化）。

• クイックインシデントのための短いウィンドウ（分時間）。
• トレンドのための長いウィンドウ（6-24時間）。
• レイテンシ：alert by p99> threshold ≥ 5 min、フラッピングの抑制とトレースインスタンスとの通信。

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7）マルチテナントとセグメンテーション

SLI/SLOはテナント/プラン/地域に応じてカウントされます。そうでなければ、中央値は失敗を「隠蔽」します。
統計的意義（ガードレール）の最小イベント数。

SLAは関税が異なる場合があります（例： "Pro 99。9％、無料99。5%»).

8）観測可能性および痕跡との関連

SLIメトリクス-ヒストグラム/カウンタからexemplars→transition to 「bad」 trails。
ログはタイムアウト、ビジネスエラーコード、制限などの理由の元になります。
データの場合-血統とのリンク：「どのジョブが鮮度指標を遅らせたか」。

9）契約およびSLA

• SLI/測定方法/ウィンドウ定義。
• 例外（予定作業、不可抗力）。
• インシデントと通信手順（ステータスページ、RFO/RCA）。
• サービスクレジットおよび要求順序。
• 管轄、有効期間、改定条件。

• アーキテクチャと運用慣行が許容するよりも厳格なSLOを公に約束することはありません。
• 内部SLOと外部SLAを分離します。

10）コストと優先順位付け

ナインの価格は直線的には伸びていない。«99.9% → 99.99％"=異なるアーキテクチャクラス（N+1、マルチゾーン、アセットツーアセット）。
最も貴重なユーザーアクションにSLOを配置します。
テレメトリーのコストを管理-ダウンサンプリング、クォータ、レプリカ、ストレージをクラス別に管理します。

11）手続きと報告

ウィークリーレポート：サービス/テナントによるSLOの実行、予算支出、トップの理由、改善計画。
事件後のRCA：私たちは予算の部分と関連付けます。根本原因を解消するためのタスクを設定します。
Fichfriz：包含/撤退基準。

12）テンプレート（クイックスタート用）

12.1 SLOカード（例）

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12.2 SLO成熟度テーブル

13）ルールの例（断片）

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14）データおよびML（特徴）のためのSLO)

エンドツーエンドのデータSLO： p99の鮮度、p99の完全性、クラッシュ後の「再処理」時間。
データ契約：予想されるスキーム、ボリューム、期限；データ違反→インシデント。
ML：推論レイテンシーのためのSLO、機能storの可用性のためのSLA、ドリフトモニタリング（モデル品質は別のトピック、SLA外）。

15）セキュリティとプライバシーの統合

PII/秘密なしのSLIログ；トークン化/マスキング。
SLO/SLAの変更を監査し、不変ログで出版物を報告します。
規制経路（payment/PII）の場合-別の、より厳格なSLO。

16）チェックリスト

サービス/機能を開始する前に

• 成功/遅延/スループット/鮮度SLIが定義されています。
• 定義されたSLOおよびウィンドウ；エラー予算が計算されます。
• バーンレートアラート（short+long）を設定します。
• ダッシュボードRED+exemplars→routes；インシデントrunibooks。
• マルチリースセクションと意義しきい値。
• Fichfreezeと報告手順。

操作

• SLO/バーンウィークリーレポート、硬化計画。
• アーキテクチャ/ロードの変更時にSLOを再評価します。
• 定期的な「ドリルインシデント」とrunibookの更新。
• テレメトリーコストとSLIカウントを監視します。

17） Runbook'

Runbook： 急速な成長p99/pay

1.Alert p99> threshold→ダッシュボードを開く→exemplarを使用してトレースします。
2.狭いCLIENT/SERVERスパンを探し、リージョン/バージョンを比較します。
3.劣化（キャッシュ/リミット/フォールバック）を有効にし、依存コマンドを通知します。
4.安定化後-RCA、最適化タスク、SLO測定の更新。

ランブック： 予算支出>週の50％

1.特徴を凍らせて下さい、信頼性の優先順位を上げて下さい。
2.エラーのクラスタリング：ルート/テナント/依存関係による。
3.修正をロールアウト→トレンド回復を確認します。
4.レトロスペクティブとアラート/しきい値の調整。

18） FAQ

Q： SLOはいくつ必要ですか？
A：重要なユーザーシナリオの最小値：成功+遅延。それ以外のものはすべて必然ではありません。

Q：どちらが良いですか-時間または要求による可用性？
A：オンデマンド-より多くのユーザーメトリック。時間はネットワークコンポーネント/インフラに便利です。

Q：なぜp95、平均ではないか？
A：中間1は尾を隠します；ユーザーはp95/p99を感じます。

Q："ネジを締めすぎないようにするには？
A：現実的な目標（履歴データ）から始め、成熟するにつれて引き締めます。

• 「Observability：ログ、メトリクス、トレース」
• 「分散トレース」
• 「監査ログと不変ログ」
• 「Webhook配信保証」
• 「In Transit/At Rest Encryption」
• 「データ起源（系統）」