Runbook

编写人：陈静

适用场景：行政协同平台通知排队

适用环境：生产环境

演练日期：9月25日

状态：步骤已演练

一、适用场景

当协同运行大盘上的通知排队超过 50 条，或员工反馈申请已经保存、主管超过 5 分钟仍未收到企业微信待办时，值班人按本文处置。目标是在 30 分钟内恢复文本待办，并抽查单据状态与消息内容一致。生产环境使用本文的阈值。预发排障沿用同一顺序，观察阈值取生产的一半。到达提醒的照片上传和请假、预订的文本待办走同一条发送队列，所以先区分是照片把线程占住，还是文本发送本身变慢。

二、确认现象

1. 查看待发送条数、最老一条的等待时间和到达提醒开关的当前值。
2. 抽 3 张最近提交、主管尚未收到待办的单据，记下单号、类型和提交时间。
3. 对照最近 2 小时的发布和开关变更。变更记在值班群日历里，值班人按分钟核对。
4. 确认预订和请假的写入是否正常。写入正常而待办延迟时，按通知队列处理，业务版本保持在当前发布。

三、处置步骤

1. 到达提醒处于开启，且线程停在照片上传时，关闭到达提醒。文本消息继续发送，照片留在访客单附件里，由行政打开单据查看。
2. 发送线程数为 0 时，按当前版本滚动重启，一次 1 台，两台之间间隔 3 分钟，重启后核对线程数恢复到 4。
3. 线程正常但排队仍在上升时，把发送并发从 4 调到 8，观察 5 分钟。排队降到 50 条以下后，再把并发调回 4。
4. 某一条消息反复失败时，记下单号并跳过该条，先放行其余消息。失败的一条由刘洋在 2 小时内按原单号手工补发。

四、恢复验证

排队低于 20 条且连续 5 分钟下降后开始抽查。抽查 10 张单据，其中必须包含确认现象时记下的那 3 张。主管收到的标题、单号、状态与页面一致，即视为恢复。抽查人在群里写明抽查单号和最老一条的等待时间。

五、升级条件

20 分钟内排队仍高于 200 条，或待办内容与单据状态不一致时，升级张伟，并请周敏准备回滚最近一次与通知有关的变更。需要停掉全部外出消息时，只停止发送，单据写入保持开放，员工已经提交的申请仍然有效。张伟 10 分钟内没有接听时，周敏按上一稳定配置恢复发送开关，次日补记录。

六、演练记录

9月25日 15:10，王芳在预发按本文走了一遍。预先堆积 80 条文本待办，到达提醒保持关闭。并发调到 8 之后队列下降，15:22 抽查 10 张，标题和单号全部一致。15:26 并发调回 4。陈静确认演练覆盖了第 3 步和第 4 步以外的主路径，单条失败的跳过动作留在下次演练补做。