SLO、 SLA、信頼性監視

（セクション： 技術とインフラ）

概要

SLOは内部品質目標であり、SLAは顧客への外部コミットメントであり、SLIは品質の測定方法です。iGamingでは、主要なSLI： APIと支払い可用性、重要なルートのp95/p99レイテンシ、Time-to-Wallet （TTW）、支払い変換、ゲームの起動、キューのメトリック。信頼性管理は、エラー、マルチバーンアラート、クリアリリースゲート、アノテーション付きのビジュアルダッシュボードの予算に基づいて構築されています。

1）利用規約と相違点

SLI（サービスレベルの表示器）-測定された表示器（例えば。タイムウィンドウごとの成功リクエストの割合）。
SLO （Service Level Objective）-ターゲットSLI値（例："可用性99。30日で9％"）。
SLA（サービスレベル契約）-補償を伴う契約/責任；実際のSLOに基づいていますが、法的条項と計画されたメンテナンスウィンドウが含まれています。

ルール：最初に内部のSLI/SLOを安定化し、次に外部のSLAを修正します。

2） iGaming用SLIフレームワーク

TexSLO

可用性：成功した2xx/3xx/すべての要求。
レイテンシー：キールートによるp95/p99 （'/deposit'、'/bet'、 '/game/init'）。
エラー：5xx共有/タイムアウト。
飽和/キュー：遅延ペイアウト/トランザクションキュー。

ビジネスSLI

支払いの変換：'成功/試み'。
TTW p95：退会申請から入学までの時間。
ゲーム開始の成功：ゲームセッション、プロバイダの初期化。
KYC/AMLフローの成功。

3）エラー予算： カウントする方法

エラー予算=1 − SLO。
例：可用性99 SLO。9 ％/30d>エラー・バジェット=0。時間の1％ ≈、 30日間のウィンドウで42分12秒です。

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLOはスライディングウィンドウ（30/7/1日）にカウントされ、ダッシュボードに表示されます。

• 予算→フリーズリリースの速い「燃焼」、カナリアを止め、安定に取り組んでいます。
• 予算在庫→より頻繁な変更を許可（制御）。

4）キーフローのSLO例

• 空室状況≥ 99。9 ％/30d
• レイテンシp95 '/deposit '≤ 250ms/30秒
• ベースライン≥支払い変換− 0。3 ％/24h
• TTW p95（出力）≤ 3 分/24h

• ゲームの成功≥ 99。5％/7位P95ゲーム・イニット≤ 600 ms/7位

• 仕事の成功≥ 99 ％/7e、遅延<5分（ピークウィンドウ別）。

5）測定： 数式とPromQL（アイデア）

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6）バーンレートアラート（マルチウィンドウ）

アイデア：私たちは、現在の予算消費率と許容されるものを比較します。

SLO 99の例。9%:

ファストバーン：1時間で14の予算×→5〜15分でページ。
スローバーン：24時間で6予算×→チケット、理由分析。

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7）ダッシュボード「SLOカード」とオペレーティングシステム

• サービスカード：可用性、P95、エラー率、バーンレート、エラー予算残高。
• フィルタ：'env'、 'region'、 'tenant'、 'version'。
• リリースアノテーション：Git SHA、タイプ（カナリア/ブルーグリーン）、スイッチ時間。

• 安定vsカナリア比較。
• PSP/ゲームプロバイダによるセクション。
• exemplars （trace_id）と関連するログに移動します。
• キューラグと飽和（USEメトリック）。

8） SLOプロセス： ゲート、凍結、エスカレーション

CDのゲート：カナリアプロモーションは、SLOプロキシ（availability、 p95、 conv）を実行するときにのみ許可されます。
フリーズ：ファストバーンまたはゼロの予算バランスで-回復までリリースを停止します。
エスカレーション：SEVマトリックス（SEV1支払/預金、SEV2ゲーム、SEV3バックホー）。
RCA：料金なしの分析、テスト/リミット/phicheflagsを更新します。

9） データ/ML-SLO（推薦者/LLMのために）

レイテンシ：p95レスポンスモデル≤ 300ミリ秒（またはトークン/s ≥ N）。
質のプロキシ：有効な応答/低い毒性の割合、有用の共有。
鮮度：特徴/データの年齢≤ X時間。
1kイベントあたりのコスト：予算の支出。
SLOゲートはモデルリリース（A/B/カナリアロールアウト）に統合されています。

10） SLOに基づくSLAの設計

SLAの基礎として保守的なSLOを選択します。
例外（計画アクティビティ、外部依存プロバイダ、インシデント・プロシージャ）を定義します。
違反レベル（クレジット/割引）、報告および検証メカニズムによってオフセットを入力します。

11）頻繁な間違いおよび反パターン

SLOはありません。「稼働時間100％」だけが非現実的で、リスクを取り除き、隠します。
burn-rateの代わりに"every metric'のアラート-alert-fatigとignore。
SLOのためのメトリック/ログのPIIミキシング-コンプライアンスリスク。
Cardinalityは、'user_id/session_id'をラベルとして展開します。
リリース注釈の欠如-劣化と変化を関連付けることは困難です。
不透明なエラー予算-チームはいつリスクを取ることができるか理解していません。
SLOはビジネスに関連付けられていません-技術的な指標は「緑」、収益は「赤」です。

12）実装チェックリスト

1.基本的なSLI （Availability、 p95/p99、 Error-rate、 TTW、 Conversion）を承認します。
2.30/7/1日ウィンドウでSLOを設定し、エラー予算をカウントします。
3.記録ルールとバーンレートアラート（高速/遅い）を追加します。
4.リリース注釈とカナリア/安定比較を備えたSLOマップを構築します。
5.CDにゲートを含める：SLO-OKなし-プロモーションなし。
6.凍結手順とエスカレーションSEVマトリックスを入力します。
7.SLOをビジネスメトリクス（conv、 TTW）および支払いルートにリンクします。
8.データ/MLの場合、レイテンシ/品質/鮮度-SLOを定義します。
9.定期的なRCAとSLO/しきい値の改訂（四半期ごと）。
10.文書SLAは、SLOが安定した後にのみ作成されます。

13）「準備ができている」目標の例（開始時）

API一般： 可用性99。9 ％/30d；p95 ≤ 250 ms/30d；エラーレート≤ 0。3 ％/30d

支払い： ベースライン≥変換− 0。3 ％/24h；TTW p95 ≤ 3 分/24h

ゲームinit： 成功≥ 99。5 ％/7d；p95 ≤ 600ミリ秒/7e

バックオフィスジョブ： 成功≥ 99％/7％；遅延≤ 5 分/7d

LLM/Reco： トークン/s ≥ N、毒性viol。 ≤ 0。5 ％/7d、鮮度≤ 6h。

概要

SLO/SLAアプローチは、信頼性を「昨日より優れた」から測定可能な規律に変えます。透明なSLI、わかりやすいエラー予算、燃焼速度のアラート、わかりやすいダッシュボード、リリースに組み込まれた品質ゲートです。この輪郭は、iGamingプラットフォームに予測可能なp95/p99、安定した支払いとTTWを提供します。これは、最も暑い時間に収益が向上し、インシデントが少なくなることを意味します。