服务窗口

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、金丝雀分区、严格的通信和一套完整的事件,窗口从"可怕的停机时间"转变为常规的改进机制,用户和合作伙伴不会感到意外。