假期要保证服务不掉，先算清值守点与响应时限
一、假期真正失效的不是人手，是五个平时成立的假设
据公开报道，有车企在假期开启出行服务保障，把补给点设到高速公路服务区和景区一带，并让数百家服务中心照常值守。这类做法值得抄的部分，和汽车没什么关系：它承认了一件事——假期不是“人少一点”，而是五个平时成立的假设同时失效。
第一，变更冻结之后没人兜底。平时代码出问题有原作者在岗，冻结期里原作者不在，剩下的人只读过文档。第二，值班人数下降但事件种类不变，一个人同时接三类电话是常态。第三，供应商同步停摆。上游接口出了问题，对方值班表上只有一个人的手机号，而且不一定接。第四，外部支持的响应时限变长，包括云厂商、专线运营商、第三方安全服务。第五，负载形状和平时不一样：峰值更尖、时段更集中、用户容错更低——堵在路上和坐在办公室里的用户，对同一个故障的忍耐度完全不同。
把这五条写出来，是因为多数假期方案只解决了第二条（排更多人值班），而剩下四条一个都没动。方案该做的，是针对每个失效假设有一条对应的处置安排。
二、四类对象各填三格，三格填不满就不算方案
保障清单按四类对象展开，每类都必须填到“谁负责、多久响应、什么条件升级”三格。空格就是假期里的未知数。
| 对象 | 具体条目 | 谁负责 | 多久响应 | 什么条件升级 |
|---|---|---|---|---|
| 服务点位与人员 | 值班表、联系方式、可替换人员、跨点位支援路径 | 点位负责人姓名加备份姓名 | 接单后若干分钟内到人 | 同一现象在两个点位同时出现 |
| 系统容量与限流 | 水位线、限流开关、排队策略、低优任务停发开关 | 平台侧值班 owner，开关需可单人操作 | 触发告警到完成动作的时限 | 水位连续越线且原因不明 |
| 外部依赖与供应商 | 上游接口清单、对方值班渠道、我方联系人、降级替代 | 依赖责任人逐条到人 | 按依赖重要性分两档时限 | 影响面达到核心链路 |
| 沟通渠道 | 对客户公告、对内部通报、对监管或大客户的定向通知 | 唯一对外出口，禁止多头发布 | 事件确认后固定时限内首份口径 | 涉及数据、资金或舆情 |
四类里最常被漏的是第三类的“对方值班渠道”。很多人只记录了供应商的工单入口，没有记录假期里能打通的那条路径；而假期里工单往往是最慢的通道。每条关键依赖要有两样：一个能打电话的入口，一个已经确认可用的替代方案或降级方式。
三、值守三层，权限差别的核心是“谁能独自决定”
一线接单、二线定位、三线决策，这三层的区别不是能力而是权限。假期里最常见的事故扩大方式，是一线有决策权但没信息，三线有信息但联系不上。
- 一线（接单与止血）：只做预先定义好的动作。重启指定服务、切流量到备用节点、按模板发第一份客户通知。每个动作必须能在操作手册里找到对应页。
- 二线（定位与判断）：有扩容量、开限流、降级非核心功能的权限，可以改动运行参数，但不能对外发布结论；不能自主决定停掉某项带用户权益的功能。
- 三线（决策与对外）：批准变更冻结期例外、决定功能下线、批准对外口径与补偿方案、判定是否升级到重大事件。
| 动作 | 一线 | 二线 | 三线 |
|---|---|---|---|
| 重启单个实例 | 可以 | 可以 | 不需要 |
| 扩容与开限流 | 不可以 | 可以 | 超预算规模需批准 |
| 关闭带用户权益的功能 | 不可以 | 不可以，需上报 | 可以 |
| 对外发布状态公告 | 只按模板首发 | 提供技术事实 | 定稿并承担责任 |
| 冻结期例外变更 | 不可以 | 不可以 | 批准并留痕 |
权限表要写在值班表旁边，而不是藏在流程文档里。假期里没人有耐心翻文档找“这件事该谁点头”。
四、容量预案看的是负载形状，SLA 不承诺做不到的时限
容量预案四件事，顺序不能颠倒：
- 预测依据与波动区间。不要只给一个峰值数字，给区间和最坏情形（假设某条依赖同时不可用）。依据要写清楚是按历史同期还是按活动排期推算，两者误差方向不同。
- 限流与排队策略。超限之后用户看到什么——排队、延迟提示还是直接拒绝，三种要分别定；拒绝要在能重试的语义下做，不能让人以为提交成功了。
- 优先级队列与低优任务停发开关。批量同步、报表生成、离线打分这类任务要有一个人能拉下的开关，并且开关动作要留记录。
- 压测复现真实假期负载形状。按假期时段分布压，不按平时的均匀分布压。尖峰宽度、并发到达速率和超时重试风暴，比平均吞吐更容易把系统打穿。
SLA 在假期的处理原则只有一条：不承诺不可能达成的时限。做法是按事件分级重设时限并在方案里写明哪一档对应多久，同时把对外沟通口径提前定稿——首发口径、进展节奏、恢复确认三段各一份模板，事件发生时只填空不改结构。临时写出来的公告，通常会承诺一个连自己都不确定的时间点。
五、变更冻结期的规则，和“补给点”式的前置
冻结期最容易犯的两个错，一是把冻结写成“什么都不能改”，于是紧急修复无处可走；二是留一个口头例外，谁都能改。规则要三样都定：冻结范围（哪些环境、哪些类型的变更）、例外审批人（到人，且假期里可达）、审批留痕格式（谁提的、为什么必须现在改、验证到什么程度、多久回滚）。紧急修复还要给一条最短验证路径：不跑全量回归，但要跑指定的核心用例集，并明确失败即回滚，不允许“先撑到假期结束”。
降级清单要提前定稿并演练。每一项写四个字段：能不能关、关掉之后用户看到什么、恢复顺序、恢复后的验证项。没演练过的降级开关，假期里不敢按——因为没人确认过它能生效，也没人确认过恢复之后系统是不是真的回来了。
补给点这个思路值得直接搬过来：把备件、备机和预配置镜像前置到离现场更近的位置，而不是集中在一个仓库。对在线服务，“离现场更近”意味着按区域或按业务线各留一份可即刻替换的东西——预装好环境的备用实例、离线可用的配置与镜像、关键外设的备用件。这里要算清一件事：前置库存缩短的是恢复时间，不是响应时间。人到位的速度靠排班，东西到位的速度靠库存，两个指标混在一起谈，方案里就会出现“我们已经有人值班了”这种答非所问。
六、假前一次桌面推演，假后只看四个时长
桌面推演的做法很省：把最坏场景写在白板上，逐条走时限、权限和沟通。场景不要选“最可能”，选“最贵”——核心链路不可用且主责联系不上、外部依赖中断且对方无人响应、水位越线但降级开关不生效。走完把发现的空缺直接补进清单，这就是推演唯一的产出；没有空缺记录的推演，多半是坐了一下午。
假后复盘只看四个时长，别的一概不进指标：
- 首报时长：从系统或用户第一次报出异常，到事件被登记并有人接手。
- 定位时长：从接手到判断出属于哪一类问题、该走哪条处置路径。
- 止损时长：从定位到完成限流、切换或降级，影响不再扩大。
- 恢复时长：从止损到功能回到可用水位并通过验证项。
这四个数各自暴露不同的问题：首报慢说明监控或值班接单有断点，定位慢说明手册里没有分诊路径，止损慢说明权限或开关不在一线手里，恢复慢说明降级项缺少演练或依赖方响应不及时。假期结束当天就把四个数算出来，比任何“总结经验”的文字都有用。洹拓内部做这类方案时有一条纪律：凡是在清单里写不出责任人姓名的条目，视为该条不存在——因为假期里它一定没人处理。