操作中的团队交互
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，收入和合规性，并使日常工作可预测且可持续。