服務窗口

1）什麼是「服務窗口」,為什麼需要

服務窗口-對於可能影響可用性/性能的工作,預先商定的時間間隔。目標是具有可預測風險，透明溝通和循證報告的可控變化。

• 計劃（計劃）：版本，遷移，證書/密鑰輪換，DB/經紀人升級。
• 緊急情況（緊急情況）：緊急安全假貨/事件回滾。
• Silent/Zero-impact：無用戶影響（隱藏的金絲雀、副本、並行輸入）。
• 提供者：外部提供商窗口（PSP/KYC/CDN/雲）。

2）原則

SLO-first：關於窗口時間/格式的決定取決於對SLI和錯誤預算的影響。
最小爆炸半徑：金絲雀→逐步→完全打開。
可逆性：每個操作都有背景計劃和驗證的回滾。
單一真相來源：帶有完整數據包的窗口日歷+tiket/RFC。
可證明性：收集事件（標誌，圖形，屏幕截圖，工件散列）。

SLA通信： 預先,在工作過程中,完成後.

3）計劃： 時間和覆蓋範圍的選擇

窗口選擇：流量低,關鍵隊列（區域/VIP/合作夥伴）影響最小。
時區：在UTC+本地時間（例如Europe/Kyiv）中固定。
Blacklaut時期：禁止在旺季/事件（比賽，銷售，發布的「死亡窗口」）中工作。
Blast radius：明確確定將影響誰（服務、地區、提供商）。

4）匹配過程（RFC/CAB lite）

1.啟動器創建帶有風險分析和計劃的tiket/RFC（請參見下面的模板）。
2.風險評估（Low/Med/High）和服務所有者批準+SRE/安全性。
3.日歷：插槽預訂；沖突檢查（其他窗口/提供程序）。
4.通訊計劃：事先商定的通知和狀態頁面。
5.Go/No-Go會議（24-48小時）進行High Risk更改。

5）準備： 安全門

開始前檢查：成功測試賭註，簽名工件，總風險≤允許的。
金絲雀：隊列/地區占1%→5%→25％；自動SLO Gardrails和自動回滾。
降級標誌和限制已經準備就緒。
Rollback/backout計劃在沙箱中驗證；已記錄回滾命令。
備份：僅用於預期噪聲,SLO信號不幹擾。
可用性：JIT/JEA操作憑據，授權審核。

6）溝通（時間和內容）

T-14/7/2天（計劃）：客戶端/內部團隊的頭對頭（何時/影響/聯系人）。
T-60/30/15分鐘：內部和狀態頁面上的提醒。
在工作期間：每15至30分鐘一次升級（SEV依賴）：Impact → Stage →以下更新。
之後：最終的「完整/分配完整/滾動」，更改列表，SLO檢查。

7）進行工作（參考腳本）

1.無關發行版的凍結。
2.→觀察到SLI/p95/p99度量標準進入金絲雀（有限隊列）。
3.綠色花園的份額逐步增加。
4.驗證業務SLI（轉換，付款/註冊成功）。
5.通過支票單驗證功能（快樂路徑+關鍵場景）。
6.Release/No Release解決方案（IC/SRE/服務所有者）。
7.取消支持，返回警報策略。

8）窗口後： 驗證和報告

觀察窗口（例如1-24小時）：跟蹤SLO和錯誤。
窗口報告：做什麼，度量，偏差，事件，總數。
如果存在問題：AAR→RCA→CAPA（規則小說，測試，文檔）。
存檔：字幕，文物，簽名，校驗和。

9）與外部供應商協調

確認的插槽和提供商聯系人；進入其狀態系統的窗口。
在運行期間對備用提供商進行後退/路由。
與提供商（聊天/橋）和SLA升級一個戰爭室。

10）過程成熟度度量

時間間隔：按時啟動/完成的窗口的百分比。
更改故障率：在SLO上具有回滾/影響的窗口百分比。
事件-during-MW：窗口期間發生的事件。
傳播SLA：及時升級的比例。
完整性：包含完整證明包的窗口百分比。

客戶影響： 抱怨/滴答作響1窗口,趨勢.

7/30天後：SLO穩定性和無復發。

11）支票單

在窗口前

• RFC/tiket已滿；風險評估已經完成；業主被指定。
• 金絲雀和反向計劃已得到驗證；回滾命令經過測試。
• JIT可用性；Alerta定制（SLO不會幹擾）。
• 日歷/狀態頁面和通知已準備就緒。
• 版本/競爭窗口-凍結/移位。
• 提供商已確認；記錄了聯系人和SLA。

在此期間

• 日程安排；戰爭室處於活動狀態。
• 遵守SLO/錯誤峰值的 Gardreils；違規時-自動回滾。
• Evidence收集（截圖、前/後圖形、操作日誌）。

之後

• 在觀察窗口的綠色區域中的SLO。
• 最終報告；狀態頁面已更新。
• CAPA是正式的（如果存在偏差）；更新了文檔。

12）模板

服務窗口上的RFC模板

RFC: MW-2025-11-05-DB-Upgrade
Window: 2025-11-05 00: 00-02: 00 UTC (Europe/Kyiv 02: 00-04: 00)
Service/component: payments-db (PostgreSQL cluster A)
Type: Planned (High)
Target: Upgrade to 15. x for security/bugs
Blast radius: EU region, tenant EU, all write operations
Impact: up to 2 × p99 growth to 400 ms; short-term read-only (≤5 min)
Gardrails: error-rate <0. 5%, p99 <400 ms, SLO not impaired
План: expand→migrate→contract; canary 1 %/5 %/25%; 1..N steps (with commands)
Backout: rolling back replica/slots; TTL DNS does not change; rollback time ≤ 10 min
Suppression: noise of database/replica alerts; SLO alerts are active
Communications: T-7/T-2 days and T-60/15 minutes; war-room #mw-db-a
Owners: @ db-tl, @ sre-ic, @ payments-pm
Evidence: before/after p95/p99 graphs, migration logs, checksums
Risk: High (data) - confirmed by CAB

客戶端通知模板（摘要）

Topic: Planned work 05. 11. 2025 02:00–04:00 (Europe/Kyiv)
We will update the payment database. Short delays and read-only mode (up to 5 minutes) are possible.
On-call contacts: status. example. com      support@example. com

Suppression規則（想法）

yaml suppress:
- name: db-maintenance when: window("2025-11-05T00:00Z","2025-11-05T02:00Z")
match: [ "db. replica. lag", "db. connection. reset", "migration. progress" ]
keep: [ "slo. payment. success", "api. availability" ]

13）受監管域的功能

審核日誌不變： 誰批準,誰執行,哪些命令,工件哈希.

PII/財務：掩蓋事實，限制訪問報告。
通知客戶和合作夥伴的時間表-根據合同。
提供程序窗口-與外部SLA和聯系人一起記錄。

14）反模式

窗口沒有反向計劃和已驗證的回滾。
「以防萬一」幹擾SLO信號。
一個域/區域中的競爭窗口。
Comm沈默：「之前/期間/之後」沒有更新。
無需審核或腳本即可進行手動編輯。
由於不確定的成功標準，「無限」窗口。
缺乏證據無助於確認質量。

15）實施路線圖（4-6周）

1.奈德。1：輸入單一日歷和RFC模板；定義黑時。
2.奈德。2：標準化門戶（金絲雀，SLO gardrails，backout）。
3.奈德。3：自動化版本/註釋和狀態頁面。
4.奈德。4：報告和成熟度指標；每周MW審查。
5.奈德。5-6：與提供商的集成和審計歸檔；高風險窗口模擬。

16）結果

正確組織的服務窗口是可管理，可逆且可證明安全的更改。借助SLO Gardrails、金絲雀分區、嚴格的通信和一套完整的事件,窗口從「可怕的停機時間」轉變為常規的改進機制,用戶和合作夥伴不會感到意外。