操作和管理→在轮班之间传递上下文

在更改之间传递上下文

1）为什么需要它

变化来了-系统已经"运行"了。Hendover的质量直接影响MTTR，Alert噪音和发行稳定性。一个好的分手是一个快速的基准，明确的风险和可理解的下一步行动。

• 排除事件、发行版和提供商的上下文丢失。
• 将新班次的"出现时间"减少到几分钟而不是几小时。
• 稳定关键路径的SLO（存款、出价、游戏启动、退出）。
• 使通信可预测和可验证。

2）良好亨多夫原则

1.标准化表格（一种模板，一种术语）。
2.单一文物（链接到相同的dashbords/tiketa/runbook'和）。
3.Taymbox（书面形式的"简报"+"longrid"）。
4.Actionable：在结尾处是"谁/什么/何时"任务的显式列表。
5.SLO定向：SLO/错误状态而不是"事件日志"。
6.可追踪性：任何事实都被人工制品证实。

3）角色和责任

轮班负责人（离开）：准备一个包裹，举行简报会。
班长（接管）：记录问题/风险，确认接受。
事件经理：更新事件的时间线/频道，监视升级的SLA。
域名所有者（Payments/Bets/Games/KYC）：按其分区给出"状态和风险"。
SRE/Observability：支持工件（dashbords,版本注释,alerts）。

4）时间安排和频道

轮班前T-30分钟：离开轮班冻结状态，更新模板。
T-10分钟：语音/视频频道上的快速简报（最多15-20分钟）。
T+0：在共享通道"#ops-handover"中发布hendover软件包。
T+15分钟：接待班次确认接待并澄清悬而未决的问题。
升级：所有"红色"项目立即进入相应团队的通道。

5） Hendover软件包结构（模板）

Handoff - <date, time, TZ>
Shift: <outgoing> → <receiving>
Overall SLO status (last 4h):
- API p95/p99: <values/trends>
- Error rate: <values/trends>
- Queue lag/DB connections/Cache: <brief>
Critical incidents:
- <INC-123>: status, impact, next update ETA, links (ticket, channel, postmortem draft)
Providers (PSP/KYC/studios):
- PSP-X: quotas/errors/fake <links>
- KYC-A: Webhook delays <links>
Releases/Features:
- In progress: <service>, stage (canary X%), gate/metrics, risk
- Scheduled: windows/locks/dependencies
Risks and observations:
- <briefly, with links and graphs>
Action items (before <time>):
- [Owner] <task>, readiness criterion
Useful links:
- Dashboard Overview, dependency map, escalation matrix, runbook 'and
On-call contacts:
- Domains/Names/Channels

6） Mini-SOP hendover

1.即将离任的更改将更新发行版和行车记录注释（SLO，提供商，队列）。
2.在过去4小时内检查红色Alerta，记录状态/原因。
3.更新"风险和观察"部分（趋势/怀疑，不是事实）。
4.用截止日期和所有者填充Action items。
5.简报：10-15分钟,严格按照模板。
6.接待人员提出问题；如果需要-立即升级给业主。
7.入场证明："收到，提问/不"，第一步清单。

7）Hendover质量度量（KPI）

Handoff Quality Score （HQS）-通过支票单对包进行评分（0-100）。
Handoff Time-简报时间（目标走廊10-20分钟）。
Acknowledgement SLA-接待确认≤ 15分钟。
Missing Context Rate-更改后发生"上下文丢失"事件的比例。
Handoff Incident Spike-在前60分钟内发生了Alert/事件。
Action Items SLA-轮班后按时完成的任务比例。

8）包装质量检查表（HQS评估）

• 在4小时内完成SLO/关键指标与趋势。
• 所有"红色"Alerta都列出了原因/参考。
• 事件：编号，状态，影响，下次更新（时间）。
• 提供商：配额/错误/failover,最近的变化。
• 版本/fici：阶段、风险、门户/金丝雀。
• 行动项目：所有者、期限、准备就绪标准。
• 参考：dashbords，通道，runbook'和，升级矩阵。
• 呼叫联系人和备用通信渠道。

9）Dashbords "hendover"（最低）

Operations Overview: p95/p99, error rate, capacity headroom, queue lag.

事件委员会：公开事件，升级的ETA，影响。
发行与功能：金丝雀，"前/之后"比较，自动登机。
Providers Panel：配额,taymouts, cost/1k calls, change。
Dependency Map：问题边缘（latency/errors/retries）。

10）Alerta关于猎头质量（想法）

ALERT HandoffNotPublished
IF handoff_published == 0 AND within(10m, shift_change) == true
LABELS {severity="warning", team="ops"}

ALERT HandoffAckSLA
IF handoff_ack_minutes > 15
LABELS {severity="warning", team="ops"}

ALERT MissingActionOwners
IF count_over_time(handoff_action_items{owner=""}[1h]) > 0
LABELS {severity="warning", team="ops"}

ALERT PostHandoffIncidentSpike
IF incidents_rate_60m_after_shift > baseline_14d 1. 5
LABELS {severity="info", team="ops"}

11）通信和更新格式

[HH: MM] Handoff published. SLO OK/Degraded. Incidents: INC-123 (ETA 18:30), releases: bets-api canary 10%. Risks: PSP-X 85% quota. Action items: @ squad-payments until 7pm to check out the feilover.

• 没有私人聊天关键点-只有共享渠道。
• 任何"红色"区域都是与所有者的直接联系。
• 所有决定/折衷都是书面的，并参考数据。

12）域名功能（iGaming）

Payments：优先级：存款转换和授权时间，PSP收款人路线，提供商限制。
Bets：系数/缓存更新、流/队列负载、计算延迟。
Games/Live：广播（头奖/流），网站窗口限制，UI降级。
KYC/AML：检查队列，提供商的SLA，高峰敏感性。

13）反模式

自由的"任意形式"hendover（每个人都随心所欲地写）。
接受确认没有截止日期。
没有Action items和所有者的软件包。
Hendover转变为取代SLO/风险的"阅读日志"。
私人聊天室中的秘密解决方案是缺乏跟踪性。
该模板不包含对工件的引用-没有什么可检查的。

14）集成和人工制品

图表上的版本注释，自动链接到分页。
Link unfurling：插入指向dashbords/tiket的链接,并预览关键指标。
Runbook绑定：每个"红色"区域都直接引用特定的绑定。
升级矩阵：在模板中为单个当前文档。

15）保留政策和审计

Hendovers-集中存储（geos，日期/时间，作者）。
每周对HQS进行审计，并选择性地分析"不良"趋势。
模式修订-季度或验尸结果。

16）快速启动（30天）

第一周：批准模板，角色和计时；在一条线上启动飞行员（例如Payments）。
第2周：包括HandoffNotPublished/AckSLA的Alerta的"hendover"行列板。
第3周：引入HQS-scorard，并审计10%的hendovers。
第4周：扩展到Bets/Games/KYC，进行回顾展，更新SOP。

17）软件包的"风险卡"示例

Risk: PSP-X hits 90% quota in prime time
Impact: rise in deposit refusals, SLO payments at risk
Signals: outbound_error_rate, quota_usage_ratio
Mitigation: raise PSP-Y up to 20% of traffic in advance, enable token cache
Owner/ETA: integrations@oncall / до 18:00

18) FAQ

问：如果简报会推迟，该怎么办？
答：严格的Taymbox和"简报后插话"规则。软件包中必须包含用于异步熟悉的所有内容。

问：如何处理"不同版本的真相"？
答：统一文物：单个行车记录板，发行注释，SSOT for SLA；只在他们身上偷看。

问：需要记录简报吗？
答：是的，对于有争议的桉例和培训。但录音不能取代标准化写作包。