操作和管理→在輪班之間傳遞上下文

在更改之間傳遞上下文

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；只在他們身上偷看。

問：需要記錄簡報嗎？
答：是的，對於有爭議的案例和培訓。但錄音不能取代標準化寫作包。