運用と→管理監査指標とSLA

監査指標とSLA

1）なぜそれを必要とします

メトリクスが間違っている場合-決定が間違っている場合、SLAは「紙に」違反するか、またはその逆に問題を隠すことになります。監査の指標とSLAは、ユーザーとパートナーへの約束が同等で、信頼性が高く、法的に安全であることを保証します。

• 単一の「真実の源」（SSOT）と再現可能な計算を提供します。
• ダッシュボード/レポート/課金の間の不一致を軽減します。
• 証拠ベースのSLAを作成します。
• サービスのように早くも測定の劣化を検出します。

2）基本的な概念と責任の境界

メートル：測定された量（RPS、 p95、 CR、 GGRの成功率）。
KPI/OKR：メトリクスがリンクされているターゲット。
SLO：サービスのターゲット品質（例："p99 ≤ 400 ms 99。時間の9％"）。
SLA：外部約束；SLOに基づいて法的に重要です。
OLA：チーム/ベンダー間の社内契約、SLAをサポートしています。
SSOT：データがレポートの参照と見なされるシステム/ストレージ。

3）メトリックの分類（レイヤー）

1.インフラストラクチャ：CPU/メモリ/IO/ネット、ポッド/ノード、HPA/VPA。
2.プラットフォーム：キュー/ストリーム（遅延、スループット）、DB/キャッシュ（接続、ヒット）、API （p95/p99、 5xx）。
3.ビジネスフロー：入金/出金、賭け、ゲームの立ち上げ、承認、KYC。
4.製品/マーケティング：コンバージョン、ARPPU/LTV、キャンペーン。
5.プロセスの質：MTTA/MTTR、変更の失敗率、チェックリストの適用範囲。

ルール：各メトリックには、レイヤー、所有者、数式が必要です。

4）データソースと「true」

オンラインテレメトリー：Prometheus/OTel、ログ（ELK/ClickHouse）、トレース。
イベントと会計：Kafka/Outbox、 DWH/データマート （BigQuery/ClickHouse）。
手動アーティファクト：死後、チケット、インシデントレジスタ。
外部レジストリ：プロバイダレポート（PSP/KYC/studios）、請求。

競合の解決：「online vs DWH」の不一致の場合、優先度の規制が適用されます（たとえば、SLAの場合-ソースのトレーサビリティを持つDWHからの集計）。

5）メトリック監査プロセス（制御ループ）

1.在庫：メトリックカタログ/SLO/SLA（名前、所有者、レイヤー、数式、ソース、計算頻度）。
2.式の検証：SQL/プロモーションクエリと定義（計算の単位テスト）との照合。
3.サンプリングと再チェック：イベント/ログラインのサンプリングと手動の調整。
4.輪郭マッピング：オンラインダッシュボードとDWHレポートの比較。
5.変更制御：スキーマ/ロジックリリースの数式レビュー。
6.SLA監査：アセンブリと例外の正確性の検証（計画メンテナンス、不可抗力）。
7.レポートと改善：検出された不一致のリストと期限付きの修正。

6）定義と数式（サンプル）

• 'success=requests-（5xx+timeouts+circuit_open）'
• 'success_rate=success/requests'

• SSOTは、ウィンドウの単一の定義（5m/1hのローリング）と集計（HDR/TDigest）を記録します。

• 'SLO_availability_month=（uptime-allowable_exceptions ）/total_time'

• 'SLA_month=99。UTCウィンドウによる90％の稼働率、計画されたウィンドウ（T-48通知）、トランジットオペレータ（文書）での実証可能な事故を除く'

7）データ品質： チェックとアラート

• （完全性）：'received_events/ expected_events ≥ 0。99`.
• 適時性：負荷遅延≤ N分。
• 一意性：重複キーなし（idempotency-key）。
• consistency-金額/通貨/文字。
• 直線性-カウンタは「ロールバック」されません。

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8） SLA/OLA監査： 方法論

1.例外のカレンダーを収集する：計画されたウィンドウ、合意された劣化、ベンダーの行為。
2.稼働時間の計算：SSOTに基づいて、単一のタイムゾーンに従って。
3.事件との和解：タイムライン、チケット、死後。
4.アトリビューション：独自の障害、プロバイダ、トランジット、DDoS、定期メンテナンス。
5.SLA境界：ユーザーエクスペリエンス（E2E）と特定のAPIを比較します。
6.報告：毎月/四半期レポート：実際、偏差、補償（該当する場合）、是正措置。

9）計算再現性の確認

数式バージョン管理：SQL/PromQL/dock仕様のGitリポジトリ。
メトリクスのユニットテスト：合成データ（エッジケース：ギャップ、重複、日付境界）。
データライン：ダッシュボードからソーステーブルやイベントに戻ります。
スナップショット：再計算に匹敵するようにカットオフ用のデータをフリーズします。

10）サンプリング

毎日：キーフローによる10-20イベント（デポジット/レート/CCL）-トレース↔ DWHの手動検証。
Weekly： 「online vs DWH」を集計全体で比較するための1％サンプル。
毎月：SLA効果を持つインシデントのセット-詳細な再構築。

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11）ダッシュボードとアラートの監査

メトリックの統一辞書：ダッシュボード上の用語集。
リリース/イベントの注釈：偏差の原因を確認する。
リリース前/リリース後の比較：自動回帰パネル。
重複/不一致：「2つの異なるp99s」を識別する-数式/ウィンドウの編集。
パネルの可用性：権利、予約、リンク/バージョン管理。

12）メートル法変更管理

RFCプロセス-数式/ウィンドウ/ソースの変更-SLA/レポートによるRFCによる影響評価

移行「expand→migrate→contract」：両方のバージョンを一時的に保持し、比較し、古いバージョンをオフにします。
コミュニケーション：「新しい方法に従って」価値の転換の前にプロダクト/ビジネスに通知して下さい。

13）具体的なiGaming/fintech

デマンドピーク：メトリックは爆発的な負荷に耐えなければなりません（集計は「固執」しません）。
プロバイダ：SLAはOLAベンダー→レポート、インシデントのステータス、クォータの保存に依存します。
コスト：'cost_per_1k_calls'と'cost of success'は必須パネルです。
Antifraud/risk：メトリクスの遅延と「誤検出」に対する感度。

14）監査ダッシュボード（最小セット）

Metrics Health：完全性/適時性/重複、ingest-lag、 FTL。
SLO/SLA証拠：計算されたSLO、実際のSLA、例外、インシデント/行為への参照。
オンラインとDWHの比較：p95/p99/Success率、偏差、トレンド。
ベンダーSLA：プロバイダによるアップタイム/クォータ/タイムアウト/コスト。
Release Impact：フィーチャーの計算/インクルード後のメトリックの回帰。

15）監査チェックリスト（運用）

• 所有者と数式を持つメトリック/SLO/SLAディレクトリは最新です。
• SSOTはレポート/パネルごとに定義されます。
• 数式のユニットテストは緑色で、計算パイプラインが文書化されています。
• データ品質アラートがアクティブになります（完全性/タイムライン/重複）。
• 「Online vs DWH」の不一致≤許容しきい値（例：≤ 2％）です。
• 合意されたSLA例外は文書化され、レポートに添付されます。
• 制御サンプルを採取し、証明書を作成しました。
• すべての数式変更はRFCとマイグレーションに合格しました。

16）例（断片）

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17）アンチパターン

異なるパネル上の2つの異なる「同じ」メトリック式。
移行と通知なしでメトリックを変更する-OKR/SLAで「ジャンプ」。
ローカルExcelで「true」（非再現可能）としてレポートします。
SLA計算でのタイムゾーンとカレンダーのミキシング。
SLA例外は文書化されていません。
測定の品質に関する警告はありません。

18）測定成熟度KPI

ドリフトレートOnline↔DWH（目標≤ 2％）。
メトリックヘルス稼働時間。
Time-to-Fixフォーミュラ。
SLA紛争率。
カバレッジSLO/SLA（正式に記述されたSLO/SLAを持つクリティカルパスの割合）。

19）役割と責任

メトリック/サービスの所有者：数式、ソース、ダッシュボード、アラート。
観測/SRE： SSOT/プラットフォーム、数式テスト、データ品質アラート。
データ/BI： DWH、レポートの再現性、血統。
弁護士/パートナーマネージャー：SLA契約および例外。
インシデントマネージャ：SLAインシデントの表示とリンク。

20）クイックスタート（30日）

1週目：インベントリーメトリクス/SLO/SLAおよび所有者；SSOTを割り当てます。
週2：データ品質アラートと「Online vs DWH」パネルを含める。
週3：制御サンプルを行い、p95/p99ウィンドウを揃えます。
週4：数式のRFCプロセスを正式化し、添付ファイル付きの毎月のSLAレポートを準備します。

21） FAQ

Q： SSOT for SLAとは何ですか？
A：再現可能な計算（DWH）および完全な系統の貯蔵；オンラインパネル-法的行為ではなく、運用管理のため。

Q： 「2つのp99s」を取扱う方法か"?

A：メトリックディレクトリのwindow/aggregationメソッドを修正し、パネルを移行し、アラートをドリフトに追加します。

Q：計画された仕事を考慮する方法か？
A：例外のカレンダーを維持し、契約のルールに従ってSLAから自動的に差し引きます。確認アーティファクトを保存します。