運營和管理→運營責任文化

運營責任文化

1）為什麼需要它

技術提供工具，但可靠性是由人及其行為創造的。運營責任文化使平臺可預測，加快災難恢復，減少「噪音」，並將事件轉化為改進的燃料。

• 對「什麼是可靠性」以及誰負責它的統一理解。
• 透明的業務角色、職責和權力。
• 一個安全的環境來討論錯誤和快速調整。
• SLO，反應時間和操作成本的節奏性改善。

2）原則（文化的核心）

1.You build it — you run it.該團隊擁有從代碼到計算機的域質量。
2.SLO-first.通過對SLO和錯誤預算的影響來評估解決方案。
3.Blameless & factual.沒有指控的驗屍官，只有事實，數據和行動。
4.Small & reversible.小變化，ficheflagi，金絲雀，快速回滾。
5.Safety to speak up.每個人都可以在沒有恐懼的情況下舉起「紅旗」。
6.Evidence over opinions.數據和人工制品比意見和地位更重要。
7.Continuously learn.事件→假設→實驗→標準。

3）角色和所有權

域所有者（Payments/Bets/Games/KYC）：SLO，電通話，改進路線圖，錯誤預算。
事件經理（輪換）：響應協調，時間線，通信質量。
SRE/平臺：可靠性工具（可觀察性，Alerta，Ficheflagi，金絲雀）。
團隊領導/EM：期望，能力發展，遵守儀式。
業務攤販：商定SLO/優先級,接受風險/權衡。

4）SLO作為責任合同

真理的唯一來源：確定指標，窗口，異常。
錯誤預算：明確的風險界限→發布/實驗的門。

SLO語言討論： "這個版本會吞噬預算的20%？».

每季度一次審核：與產品和業務協作。

5）呼叫和事件準備

明確的期望：反應時間，通道，權力（「停止起重機」權利）。
培訓：事件模擬，影子值班，DR演習。
工件：實時運行手冊"，升級矩陣，升級模式。
照顧人：輪班負荷，補償，輪換，「無英雄」政策。

• 訪問和VPN已驗證。
• 通知渠道和備用聯系人是可行的。
• Runbook ≤ 30天前更新。
• DR參與過去90天。

6）運營中的通信

單一模式：事件的簡短更新，輪班之間的「handover」包。
決策宣傳：關鍵權衡是書面記錄的。
圖表上的註釋：版本，ficheflagi，提供程序窗口。
所有SLO面板：狀態和錯誤預算的透明度。

[HH: MM] P2 Games latency ↑ p99 to 420 ms (base + 28%). Canary rolled back.
ETA of the next update: 20 min. Owner: squad-games. Next steps: tuning the breaker, checking provider Y.

7）Postmortham無指控

事實和時間線：誰，何時，做什麼，基於什麼數據。
系統原因：過程，工具，接口而不是「罪魁禍首」。
截止日期行動：糾正和預防。
吸取教訓：標準，支票單，運行手冊更新。

Impact: <metrics/revenue/users>
Timeline: <UTC+TZ>
Root cause: <system cause, not personalities>
Fix now: <3 actions + owners + ETA>
Prevent: <3 process/tool improvements>
Signals to watch: <SLO/metrics>

8）儀式和節奏

每周行動回顧（30分鐘）：SLO，事件，異同，行動進展。
每月可靠性回顧：課程、趨勢、標準更新。
季度可靠性評論：修訂SLO/預算，整合到路線圖中。
Game-days/Chaos：計劃中的故障和操縱器練習場景。

9）動機，增長和軌跡

能力：電話、事件管理、可觀察性、SLO工程、FinOps。
職業水平：對可靠性貢獻的期望（主動性，驗屍後，指導）。
非物質動機：認可，改進的作者，季度的「可靠性冠軍」。
物質：電匯補償，SLO-KPI成就獎金。

10）政策和行為規範（片段）

• 當SLO威脅時，任何電子呼叫都可以暫停發布/指關節。
• 一旦消除了風險，將對決定進行記錄和審查。

• Ficheflags和金絲雀的重大變化。
• 根據SLO指標進行的自動駕駛；→暫停/回滾偏差。

• 所有關鍵信息都在共享渠道中,沒有私人解決方案。
• 對於P1/P2事件，ETS（待定時間到狀態）是必需的。

11）文化度量（KPI成熟）

SLO Coverage：具有正式描述的SLO/Alert的關鍵路徑的比例。
事件前檢測率：在退化階段截獲的事件比例。
MTTR/MTTD：每個街區的動態。
更改失敗率：發行後回滾/回歸。
Postmortem Action SLA：按時關閉的動作比例。
警報致命性索引：每通話/班次的變量。
Handoff Quality Score：輪班之間的傳輸質量。
心理安全脈沖：簡短的定期調查（匿名）。

12）實施支票

• 已定義域、所有者、呼叫和SLO。
• 采用了停止起重機、驗屍和通訊政策。
• 提升了SLO面板和版本註釋。
• 儀式已經啟動：每周Ops評論和模式趨勢。
• 開發了驗屍模式和動作跟蹤器。
• 舉行了第一場比賽日/DR演習。
• 定制KPI文化和每月審查。

13）反模式

英雄崇拜：我們在最後一刻保存而不是系統修復。
人的錯：尋找「罪魁禍首」而不是原因。
隱藏解決方案：私人聊天，「口頭安排」。
大型夜間發行：沒有旗幟和金絲雀。
沒有行動的指標：有報告，沒有解決辦法。
混亂的趨勢：沒有模板和接收確認。

14）工具和文物（最低限度）

所有者的SLO/Alert目錄。
Runbook存儲庫（按域、更新≥每月）。
Template： mortem, hendover,事件升級,退化計劃。

Панели: SLO Overview, Incidents, Change Safety, Providers.

行動追蹤器：與SLA和業主統一反擊。

15）嵌入到HR路徑

Onbording： SLO、on-col、Postmortems培訓。
績效評估：對可靠性和文化的貢獻是績效評論的一部分。
指導：影子值班，配對事件管理。
脈搏調查：季度安全/倦怠評估。

16）30/60/90-啟動計劃

• 分配域所有者和呼叫,根據SLO （p95,成功率）提交最小值。
• 采用「停止起重機」和驗屍策略,批準模式。
• 每周推出行動評論和手儀式。

• 進行2 場比賽/DR練習，舉起SLO和Change Safety面板。
• 在1-2項關鍵服務上嵌入金絲雀和SLO自動登機口。
• 運行文化指標（MTTR、Action SLA、Pulse Poll等）。

• 趨勢分析，SLO/預算更新，將改進整合到路線圖中。
• 引入「可靠性冠軍」和指導計劃。
• 根據結果調整儀式和政策。

17）模板（片段）

scope: P1/P2 and repeated P3 timeline: ≤72 hours format: impact, timeline, root cause, actions (now/prevent), owners/due dates review: monthly on Reliability Review blameless: specifying personalities only as a fact of time stamp

SLO summary     Incidents and ETAs    Providers and quotas    Releases/Canaries    Risks/observations     Action items

- Ficheflags/canary set up
- SLO alerts and annotations included
- Rollback plan and "safe mode" defined
- Provider windows considered
- Responsible on-call confirmed

18) FAQ

問：如何衡量「文化」，而不僅僅是技術？
答：輸入脈沖調查（心理安全），後驗屍行動SLA，公共決策份額，HQS分手。

問：如何處理「英雄主義」？
答：感謝但記錄系統性的變化，所以不需要英雄主義。在表演中考慮預防和改進，而不僅僅是「壯舉」。

問：如何說服企業文化價值觀？
答：顯示鏈接：MTTR/Change Failure Rate下降→轉換/收入增加，罰款和隔夜分頁減少，可預測發布。