オペレーションにおけるチームの相互作用

1）なぜ

iGamingプラットフォームは数十のドメイン（支払い、ゲーム/コア、リスク/KYC、データ、Infra/SRE、サポート、コンプライアンス）です。正式な相互運用性なしでは、MTTR、 CFR、および運用上のリスクが上昇します。目標は、異なる機能を単一のオペレーティングシステムに変えることです。予測可能な連絡先、透明なキュー、共通信号、一貫した優先順位。

2）原則

1.SLO-first：ジョイントソリューションはSLO/エラー予算に関連付けられます。
2.真実の単一のソース：一般的なダッシュボード、均一なステータスとアーティファクト。
3.境界とインターフェイスをクリア：各コマンドのペアには、記述されたコントラクト（OLA/Runbook/API）があります。
4.小さいバッチおよび可逆性：phicheflags/canary、速いロールバックによる変更。
5.いいえ責任-はいデータ：事実の解析、改善-サイクルの必須部分。
6.必要最小限の権限とSoD：機密操作のロール分離。
7.ルーチンを自動化し、残りを標準化します。

3）役割とRACI（エンドツーエンド）

Ops/SRE Leadの責任者は、運用フレームワークであるKPI/KRIの所有者です。A （A）

サービスオーナー（支払い/ゲーム/KYC/データ）-ドメインの目標、変更、リスク。A/R

プラットフォーム/インフラ-アクセシビリティ、パフォーマンス、リリース/カナリア。R （R）

リスク/コンプライアンス/セキュリティ-SoD、 RG/KYC/PII、監査。C/A

サポート/CRM-苦情、プレーヤーへのコミュニケーションの前。R/C

通話中のIC/CL-インシデント管理と外部更新。R （R）

Release Manager-カレンダー、CAB、変更状況。R （R）

データ/アナリティクス-製品および運用指標、RCAサポート。R/C

4）インタラクションコントラクト（OLA/SLx）

• 責任領域：その領域（例えば、PSPルーティング-支払い；cache/DB-Infra）。
• 目標/しきい値の指標：インシデントMTTA、エスカレーション応答時間、ポストモニタリングウィンドウ。
• キューと優先順位：P1-P4、ビジネスの重要性、ウィンドウの凍結。
• インターフェイス：チャンネル、ボットコマンド、API/Runbook、オーナーディレクトリ。
• アーティファクト：イベントに同行するために必要なドキュメント/ログ/ダッシュボード。

5）通信チャネルおよび議定書

運用チャット（シフト）：毎日の更新、ミニリチュアル、引き渡し。
インシデントのためのVARルーム：ボットによって作成されました。IC/CLロールはコマンドによって割り当てられます。
CAB/Change channel：変更、リスク、リリースカレンダーの議論。

読み取り専用SLO/インシデント/計画アクティビティの概要

エスカレーション：コマンドテンプレート'/page'、'/escalate'、 SLAレポート。

統一メッセージプロトコル：「fact→impact→ETA/ETR→next update window→owner」。

6）シフトとリージョン間のハンドオーバー

1.SLO/SLI：予算バーンアウトのリスクはどこにありますか。

2.オープンインシデント/エスカレーションとそのETA。

3.次の24-48時間に予定されている作品/リリース。

4.プロバイダ（PSP/KYC/スタジオ）：アクティブなチケット、期待。

5.通話中のコンポジションとコンタクト（IC/CL/ドメイン）。

6.「ウォッチリスト」-注目の領域（キュー/レプリケーション/キャッシュ）。

ハンドオーバーはシフトログ、リンク-var-roomsとダッシュボードに記録されます。

7）インシデントコラボレーション

Start： alert→botはカード'#inc-YYYY-MM-DD-XXX'を作成し、IC/CLとドメインリードを割り当てます。
1つの投票ルール：ICは最終決定です。CL-通信。
事実と仮説：私たちは分離します。「赤」信号-優先度。
ガードレール：phicheflags/PSPルーティングはSoD/デュアルコントロールでrunbook経由でのみ変更されます。
コミュニケーション：CLを介した公開アップデートの草案、パートナー-ターゲット。
閉鎖：所有者/期限とのポストモニタリング、死後の生成と改善タスク。

8）変更に関する共同作業

リリースカレンダー：フリーズピリオドとオンコールスロットを備えたパブリック。
品質ゲート：ユニット/コントラクト/e2e、セキュリティ、SLOゲートのステージング。
カナリア圧延：ステップバイステップ5％→25％→GEO/テナント/銀行のための100％。
自動ロールバック：キーSLI/KRIによるポリシー、WORMマガジン。
Commパッケージ：CL/Legalと事前に合意したアップデート案。
RACIの変更：RM （A/R）、 SO （A/R）、 SRE （R）、 Sec/Compliance （C/A）、 CAB （A）、 IC/CL （R/C）。

9）統一されたテレメトリとアーティファクト

一般的なメトリックディレクトリ：SLI/SLO、ビジネスメトリクス、KRI（キュー、PSP、レプリケーション）。
ダッシュボード「オペレーションマップ」：ドメイン、地域、インシデント/作品の状況による要約。
タイムライン：均一なフォーマット（時間、著者、アクション、結果、リンク）。
死後：料金なしのテンプレート、予防措置、改訂日。
ランブック/チェックリスト：バージョン管理済み；アラートとインシデントカードからのリンク。

10）優先順位付けと計画

ウィークリーオプスプラン（30-45分）：トップリスクの調整、リリース、制限、死後の改善。
操作のかんばん：列'Backlog→Ready→In Progress→Validate→Done'、 WIP limits。
優先基準：SLO/収益/コンプライアンス、サイズ/リバーシビリティ、プロバイダへの依存への影響。

11）エスカレーションマトリックス（squeeze）

12）ポリシーとSoD

SoD/4-eyes： 結論/ボーナス/PSP ルーティング/PIIエクスポート-二重承認のみ。
JITの権利：runbookアクションの特権の一時的なエスカレーション。
データポリシー：オープンチャンネル/ダッシュボードでのPII禁止；地理的境界。
監査-不変アクティビティログ（WORM）、ポリシーの改訂。

13）インタラクションツール

インシデントボット：'/incident new'、ロール、更新タイマー、comm drafts、 '/runbook'、 '/flag'、'/config'。
メトリクスAPI：一般的なSLOビューとKRI、 RCAの例（trace_id）。
Release-portal：マニフェスト、ゲート、ローリング/ロールバック状態。
所有者ディレクトリ/CMDB：ドメイン、連絡先、バックアップチャネル。

14）コラボレーションメトリクス（KPI/KRI）

ドメインとスロット（昼/夜）によるMTTA/MTTR、苦情の前にキャッチ事件の割合。
ハンドオーバー品質：伝送欠陥（チェックリスト項目は時間通りに閉じられません）。
コラボレーションの変更：既製のcommパッケージとロールバックなしのリリースの％。
ガードレール規律：SoD/ポリシー違反の頻度（ターゲット0）。
Comms Cadence： P1/P2時に公開更新間隔を遵守します。
死後のSLA：死後の割合≤ D+5、アクションの完了。
公正共有の負荷：人々/チームによる夜/ピークの分布。
顧客シグナルリード：客観的な劣化と最初の苦情の間の遅れ。

15）実装ロードマップ（6-10週間）

ネッド。1-2：ドメイン/所有者のインベントリ；OLAテンプレート；交換チャネルとハンドオーバーチェックリストの起動。ベースエスカレーションマトリックス。
ネッド。3-4：インシデントボット（MVP）、共有ステータスチャネル、シングルSLO/SLI/KRIカード。runbooksディレクトリ。
ネッド。5-6： CAB/リリースカレンダー、 commパッケージおよび凍結窓；敏感な操作のためのSoD/4-eyes。
ネッド。7-8：標準としてカナリア圧延および自動ロールバック；事後テンプレート、Exec/Ops-dashboardsコラボレーション。
ネッド。9-10： P1演習、地域横断ハンドオーバー、WORM監査、KPI/KRIレポート、OLA調整。

16）テンプレート（フラグメント）

16.1 OLA （Infra/SRE ↔支払い）

yaml ola:
scope: "Payments-Auth & Routing"
contacts:
payments_so: "@pay-so"
infra_oncall: "@sre-oncall"
objectives:
mtta_p1: "≤5m"
rollback_ttr: "≤10m canary"
interfaces:
runbooks: ["psp-failover", "reroute", "auth-throttle"]
dashboards: ["auth_success", "psp_latency", "queue_lag"]
escalation:
p1: ["IC","Payments Lead","SRE L2"]
p2: ["Payments OnCall","SRE OnCall"]
artifacts:
status_templates: ["public","partners"]
postmortem_due: "D+5"

16.2ハンドオーバーチェックリスト（10項目）

1.SLOドメインステータス

2.オープンインシデント（ETA/オーナー）

3.計画された活動/リリース+観察ウィンドウ

4.プロバイダー（PSP/KYC/スタジオ）-リスク/期待

5.キュー/レプリケーション/キャッシュ-遅延/異常

6.制限/Phicheflagの変更

7.苦情/チケットおよび負荷しきい値

8.コンマ計画とステータスドラフト

9.通話中の構成と予約

10.スロットごとの「ウォッチリスト」

17） Antipatterns

「誰か取り引くのか？」RACIと所有者なし。
IC/CLおよび更新タイマーのないインシデント。
非表示の変更（手動クリック）、Git/Auditなし。
非共通テレメトリー：異なるチームの異なる数字。
commのパックおよびカナリアなしで解放して下さい。
SoD違反「速度のために」。
記録とチェックリストなしで口頭でハンドオーバーします。
行動と期限のない死後。

合計

OLA/SLx、明確なチャネルと役割、ハンドオーバー規律、一般的なテレメトリー、調整されたリリースとインシデントプロセス。このようなフレームワークは、MTTRとCFRを削減し、優先順位を調整し、SLO、収益およびコンプライアンスを保護し、日常業務を予測可能かつ持続可能にします。