操作中的團隊交互
1）為什麼
iGaming平臺是數十個域名（Payments，Games/Core，Risk/KYC，Data，Infra/SRE，支持，合規性）。如果沒有正式的互動，MTTR，CFR和運營風險就會增加。目標是將不同的功能轉變為單個操作系統：可預測的聯系人，透明的隊列，共享的信號和一致的優先級。
2）原則
1.SLO-first：聯合解決方案與SLO/錯誤預算掛鉤。
2.真相的單一來源：普通的行刑板，統一狀態和人工制品。
3.明確的邊界和接口：每對命令都有描述的合同（OLA/Runbook/API）。
4.小蹦床和可逆性：通過菲奇弗拉吉/金絲雀的變化，快速滾回。
5.No blame-yes data：事實分析，改進是周期的必備部分。
6.最低要求權限和SoD：敏感操作的角色劃分。
7.自動化例程，標準化其余部分。
3）角色和RACI（端到端）
行動負責人/SRE Lead是運營框架KPI/KRI的所有者。A
服務所有者（Payments/Games/KYC/Data）-域目標，更改，風險。A/R
Platform/Infra-可用性，表演，發行版/金絲雀。R
Risk/Compliance/Security-SoD，RG/KYC/PII，審核。C/A
支持/CRM-投訴戰線，與玩家溝通。R/C
On call IC/CL-事件管理和外部升級。R
Release Manager-日歷、CAB、更改狀態。R
Data/Analytics-產品和運營指標，RCA支持。R/C
4）互操作性合同（OLA/SLx）
OLA（運營級別協議）是團隊之間的內部安排（不是外部SLA）。包括：- 責任區域：其區域（例如PSP路由-付款；緩存/DB-Infra）。
- 目標/閾值指標：事件的MTTA，對升級的響應時間，後監測窗口。
- 隊列和優先級：P1-P4、業務關鍵性、凍結窗口。
- 接口：通道、機器人命令、API/Runbook、所有者目錄。
- 文物：哪些文檔/logi/dashbords必須伴隨事件。
5）溝通渠道和協議
操作聊天（輪班）：每日升級、迷你儀式、打包。
關於事件的var-rums：由機器人創建；IC/CL角色由團隊分配。
CAB/Change通道：討論更改、風險、發布日歷。
狀態通道（只讀）：SLO摘要/事件/計劃工作。
上報：報告SLA的「/page」，「/escalate」命令模板。
單一消息協議：「ETA/ETR →的事實→影響→以下升級窗口→所有者」。
6）輪班和地區之間的分手
Template 10-15分鐘：1.SLO/SLI：預算倦怠的風險在哪裏。
2.公開事件/升級及其ETA。
3.計劃在接下來的24至48小時內完成/發布。
4.提供商（PSP/KYC/工作室）：主動滴答聲，期望。
5.呼叫組成和聯系人（IC/CL/domains）。
6.「Watchlist」是高度關註的區域（隊列/復制/緩存）。
亨多弗（Hendover）被記錄在可互換的日誌中，指的是酒窖和行車記錄儀。
7）聯合應對事件
開始：alert → bot創建「#inc-YYYY-MM-DD-XXX」卡，分配IC/CL和域線。
一票規則：IC是最終決定；CL-通信。
事實和假設：我們分離；紅色信號-優先。
Guardrails： ficheflagi/PSP路由僅通過具有SoD/雙控制功能的運行簿進行更改。
通訊：通過CL公開展示的草稿，合作夥伴-定向。
關閉：後監測，後驗屍的生成以及與所有者/時間表的改進任務。
8）在變更時協同工作
發行日歷：公開提供，帶有免費期和呼叫插槽。
質量門：單位/合同/e2e，安全，SLO門插頭。
金絲雀分銷：GEO/tenant/銀行分步增長 5%→25%→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、復制）。
Dashboard「操作圖」：域摘要，區域，事件/工作狀態。
時間線：統一格式（時間，作者，動作，結果，鏈接）。
後面模特：無指控模板，預防措施，修訂日期。
Runbooks/Checklists: versioned;來自警報和事件卡的鏈接。
10）優先排序和規劃
每周Ops計劃（30-45分鐘）：協調頂級風險、發布、限制、後驗屍的改進。
Kanban操作：「Backlog → Ready → In Progress → Validate → Done」列，WIP限制。
優先級標準：對SLO/收入/合規性的影響,規模/可逆性,對提供商的依賴性。
11）升級矩陣（擠壓）
12）政策與社會責任
SoD/4-eyes：結論/獎金/PSP 路由/PII導出-僅獲得雙重批準。
JIT權利：運行簿操作的特權暫時升級。
數據政策：禁止PII 進入開放渠道/dashbords；地理邊界。
審計：不變活動日誌（WORM），策略修訂。
13）互動工具
事件機器人：「/事件新」，角色，更新計時器，comm草稿，「/runbook」，「/flag」，「/config」。
Metrics API：常見的SLO和KRI，RCA的exemplars（trace_id）。
發布門戶：清單、門戶、滾動/回滾狀態。
所有者目錄/CMDB：域名，聯系人，備用渠道。
14）合作度量（KPI/KRI）
MTTA/MTTR按域和插槽（晝夜）分列，在投訴之前捕獲的事件比例。
Handover Quality：傳輸缺陷（支票點未按時關閉）。
Change Collaboration：使用現成的Comme Packs且無回滾的版本百分比。
Guardrail Discipline：違反SoD/策略的頻率（目標-0）。
Comms Cadence：在P1/P2時遵守公共升級間隔。
後太平間SLA：後太平間份額≤ D+5，執行動作。
公平分享負載：按人/團隊分配晚上/高峰。
Customer Signal Lead：客觀退化和首次投訴之間的脫節。
15）實施路線圖（6-10周）
奈德。1-2：領域/所有者庫存；OLA模式；開通可互換頻道和交叉支票單；基本升級矩陣。
奈德。3-4：事件機器人（MVP），通用狀態通道，單個SLO/SLI/KRI卡；runbooks目錄。
奈德。5-6：SAV/發布日歷，com包和凍結窗口；敏感操作SoD/4-eyes。
奈德。7-8：金絲雀分期付款和自動回滾作為標準；後太平間模板，Exec/Ops-dashbords合作。
奈德。9-10：P1演習，跨區域嘗試，WORM審計，KPI/KRI報告，OLA調整。
16）模板（片段）
16.1 OLA (Payments ↔ 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 Hendover支票清單（10分）
1.域的SLO狀態
2.公開事件（ETA/所有者）
3.計劃工作/發行版+觀察窗口
4.提供商（PSP/KYC/工作室）-風險/預期
5.隊列/復制/緩存-lag/異常
6.限制/ficheflags變化
7.投訴/滴答聲和負載閾值
8.Comm計劃和狀態-草稿
9.呼叫陣容和儲備
10.每個插槽的「觀看列表」
17）反模式
「有人會處理嗎？」沒有RACI和所有者。
沒有IC/CL和升級計時器的事件。
隱藏更改（手動點擊）,沒有Git/Audit。
無縫遙測：不同團隊的不同數字。
沒有Comm軟件包和Canars的版本。
SoD違規行為「為了速度」。
Hendovers是口頭的，沒有記錄和支票單。
沒有動作和時間表的後面部表。
底線
團隊在運營中的互動是合同合作：OLA/SLx，清晰的渠道和角色，分包商紀律，通用遙測，協調發布和事件過程。這樣的框架降低了MTTR和CFR，平衡了優先事項，保護了SLO，收入和合規性，並使日常工作可預測且可持續。