SLAおよびSLO監視

1）利用規約と役割

SLA（サービスレベル契約）-クライアントに対する外部契約上の義務（ペナルティ条項、クレジット）。
SLO （Service Level Objective）-SLA実行をサポートする内部サービスレベルをターゲットにします。
SLI （Service Level Indicator）-SLO/SLAの評価に基づいて測定されたインジケータ。
Error Budget-期間の「利用不可/エラー」の許容割合：'Budget=1 − SLO'。
スコープ：ユーザーの目（エンドツーエンド）によって測定されます。マイクロサービスでは、コンポーネントレベルでもエンドツーエンドのパスレベルでも。

2） SLIの選択： 正確に測定するもの

この基準は、ユーザーエクスペリエンスとビジネス価値との相関です。

• 可用性：成功したリクエストの割合。'SLI=successful/all'。
• レイテンシー：リクエストの割合は、しきい値T。 'SLI=P （latency ≤ T）'よりも速い。
• 品質：正解の割合（5xx/functsなし。エラー）。
• データの最新情報：レプリケーションのレイテンシー/ETL ≤ X分。
• ビジネスプロセスのパフォーマンス：成功した支払い/登録のシェア。

アンチパターン：200のみを「成功」としてカウントし、ビジネスミスを無視します。ユーザーネットワークの代わりにテストネットワークで測定します。

3）数式と観察窓

• 'Availability=（OK_requests/ All_requests） × 100％'。

• 'P95 ≤ T'→は共有としてより良い定式化されています：'SLI=T ≤の要求の％'。
• 例：「検索クエリの99％ ≤ 28日で300ミリ秒です。」
• スライディングウィンドウ：28または30日（感度と安定性のバランス）。インシデントの場合-追加のウィンドウ：1時間、6時間、24時間。

4）エラー予算と変更レート制御

計算：'SLO=99。9％ 'budget='0。期間ごとに1％のエラー/利用不可。

• 予算>50％：リリースと計画実験。
• 予算10〜50％：低リスクのリリースのみ、カナリアの締め付け。
• 予算<10％：リリースの凍結、根本原因、信頼性向上。
• プログレッシブリリースとの接続：カナリア/フィーチャーフラグは、分解の下で自動ロールバックで、用量で予算を「食べる」。

5）警告政治家： しきい値から燃焼率まで

なぜ「daupal SLO-アラートを上げる」しなかったのですか？プロアクティビティが必要です。

• 'BR=（このウィンドウの短いウィンドウでの観察エラー/許可されたエラー）'。
• 'BR> 1'の場合、予算は通常よりも高速に消費されます。

• 速い警報（騒音は敏感、キャッチ災害）：窓5-10分、しきい値BR 14-20 ×。
• 遅いアラート（忍び寄る劣化をキャッチ）：ウィンドウ1-6時間、しきい値BR 2-4 ×。
• コンバイン条件：高速または遅い作業-ページングオンコール。
• レベル：ユーザーSLOのページャー、内部SLIの灰色の劣化のためのチケット/通知。

6）真実の観察可能性と情報源

ログ-原因の診断。
メトリクス-数値SLI（成功/エラー、遅延パーセンタイル、分数、カウンタ）。
トレイル-パスを通じて、「ホット」セグメントのローカライズ。
合成-周辺の活性サンプル（region-aware）。
実際のイベント-RUM/顧客テレメトリー、ビジネスメトリック（コンバージョン、支払いの成功）。

要件：リリースとインシデントのダッシュボード内の単一の画像、注釈「version/canary/flag」。

7） SLO設計： ステップバイステップのテンプレート

1.クリティカルパス（「カードによる入金」など）を説明します。
2.SLIの定義：成功/エラー、待ち時間のしきい値、完全性。
3.SLOに同意する：28日間のターゲット+例外（スケジュールされたウィンドウ）。
4.SLAへのリンク：実際のSLO ≦法的義務。
5.サービスオーナー、RACI、アラートチャンネルを割り当てます。
6.アラートポリシー（2ウィンドウBR）と自動ロールバックを定義します。
7.レポートの実装：毎週の予算レビュー、事件後のレビュー。

8.SLOの四半期ごとのレビュー（ロード/アーキテクチャ変更）

8） SLO例（テンプレート）

• 空室状況：'≥ 99。95％ '（28d、発表されたウィンドウを除く≤ 30分/月）。
• レイテンシー：'≥ 99％'応答'≤ 400ミリ秒'。
• 事業の成功：'≥ 98。5％"成功した承認（詐欺フィルターが考慮されます）。

• レイテンシー：'≥ 99％'リクエスト'≤ 300 ms'。
• キャッシュの関連性：'≤ 5分'遅延時間の99％。

• 配達：'≥ 99。'≤ 60'の9％'（エンドツーエンド、レトラ付き）。
• 損失：'≤ 0。01％'メッセージ（idempotency/重複除外が有効）。

9）複数の地域および複数のテナント

SLO「コホート」：国、決済プロバイダー、VIPセグメント、デバイス。
エッジのローカルSLO：ユーザーに最も近いポイント（edge/PoP）のメトリック。
集約：Total SLOは重要なコホート間の障害を隠すべきではありません。
スイッチングプロバイダ：SLOゲートレベルの自動フォールバックルート。

10）ダッシュボードとレポート

リリースダッシュボード：バージョン、カナリア（％トラフィック）、SLI（成功/遅延）、BR、フラグアノテーション。
オペレーティングダッシュボード：日ごとのバーンダウン予算、トップインシデント、MTTR、問題のコホート。
週報：予算収支、BR動向、技術債務（ボトルネック）、改善計画。

11）プロセス： インシデント、RCA、改善

インシデント管理：アラート→BR評価→カナリア/フラグのスケール→ロールバック/修正。
RCA（根本原因）：SLIによる事実/タイムライン/仮説/修正/効果チェック。
学んだ教訓：非罰的な死後、所有者と期限付きの必須のアクション項目。
ループ閉鎖：テスト、フィーチャーフラグ、リミット、キャッシュ、リトレイ、クォータの変更。

12）コンプライアンスと監査

制御アーティファクトとしてのSLO/SLI （policy-as-code、 immutable logs）。
要件へのリンク（例えば、支払い取引の可用性）。
証拠：アラート分、予算レポート、リリース/ロールバックのログ。

13）頻繁な間違いとそれらを回避する方法

“99.99％または死"：達成不可能な目標→一定のアラートノイズ。現実的なSLOを選択します。
グローバル平均はローカルディップを非表示にします→コホートを導入します。
e2eではないメトリクス：クライアントの実際の劣化中の高いSLO→RUM/合成を追加します。
1スレッショルドのアラート→2ウィンドウのバーンレートに切り替えます。
変更へのリンクはありません→リリースは注釈なし、自動ロールバックはありません。

14）ミニインプリメンテーションのチェックリスト

• クリティカルパスとそのSLI/SLOについて説明します。
• 監視と除外ウィンドウが設定されています。
• 2ウィンドウのBRアラート（高速および遅い）が設定されています。
• バージョン/フラグのアノテーションによるリリースと操作のダッシュボード。
• エラー予算ポリシーはリリースに影響します。
• 定期的な予算レビューと事件後のRCA。
• ドキュメントとスコアカードの所有者。

15）計算例（詳細）

APIの可用性SLO： 99。28日で9％→予算=0。1%.

7日間は0を蓄積しました。エラーの06％→毎週の予算の60％を使用しました。

15分の短いウィンドウでは、エラーの2％が観察されます。このウィンドウで有効な値は'0です。1％ × （15分/40320分）≈ 0。000037%`.

燃焼率≫ 1（数十×）→高速ページャがトリガーされ、カナリアが1％に戻り、degrade-payments-UXフィーチャーフラグがオンになり、RCAが開始されます。

16）ボトムライン

SLA/SLO監視は、レポートの数値だけでなく、変更のリスクとサービスの品質を管理するためのメカニズムです。SLI、現実的なSLO、エラー予算管理、2ウィンドウのバーンレートアラート、e2eオブザビリティを修正すると、メトリクスは作業中のソリューションに変わります。