回滚预案

项目：行政协同平台

指挥：张伟

部门：产品研发中心

适用：10月21日上线窗口

目标：60 分钟内恢复原办理方式

一、预案目的

本预案用于行政协同平台在 10 月 21 日上线窗口内无法稳定办理业务时，恢复总部 A 座原有办法。原办法是会议室用行政台账、请假走主管邮件、访客在门岗纸质登记、用品在行政柜台发放。恢复后 186 名员工仍能办完这四件事，平台停止作为主办渠道。

1. 决策人是张伟，技术执行是刘洋，业务通知是周敏，账号通知是王芳。
2. 从宣布回滚到原办法恢复，目标时限 60 分钟。
3. 回滚完成后次日 9:30 开 30 分钟排查会，由张伟主持。
4. 本预案在 10 月 18 日彩排一次计时，刘洋记录实际分钟数。

二、触发条件

出现下列任一情况，张伟在 20 分钟内宣布回滚。未达到这些情况时，继续按上线步骤修复，修复超过 20 分钟仍无结果的，同样宣布回滚。

1. 冒烟的四项事务中，有两项无法办结。
2. 首页连续 15 分钟无法打开，抽查的 10 个账号同样失败。
3. 备份无法抽查恢复，刘洋不能证明可以回到冻结时点。
4. 用品库存扣减与初值对不上，且当场算不清差异笔数。

三、回滚步骤

下表按顺序执行。9 月 27 日只彩排了停写和恢复备份两步，通知和柜台恢复尚未计时。正式日一旦触发，六步全部执行。

四、人员与时限

窗口当晚六人在「A座上线」群待命。张伟不在时由陈静宣布，但恢复备份仍只由刘洋执行。周敏不在时王芳代发柜台通知，口径使用 10 月 18 日前写好的稿件。

1. 刘洋的恢复脚本在 10 月 18 日彩排中记录实际耗时，超过 20 分钟须当天优化。
2. 王芳的员工说明控制在 200 字以内，写明次日四项事务的原办理地点。
3. 周敏提前通知门岗值班长，纸质访客单放在值班台第一层。
4. 李婷负责看市场部是否收到说明，并回复张伟收到时间。

五、验证与收尾

步骤 6 通过后，张伟宣布回滚结束。平台数据停留在冻结时点，供次日排查，当晚不再写入。次日业务全部走原办法，直到张伟另行宣布重新开放的日期。

1. 周敏用台账登记一间会议室，用邮件走一笔请假，确认渠道可用。
2. 刘洋把备份编号、恢复开始和结束时间写入运行记录。
3. 王芳统计说明送达人数，次日 10:00 前报告未送达名单。
4. 张伟在排查会上决定重新开放的最早日期和要先关闭的缺陷。