故障演练

组织人：周敏

环境：预发

日期：0000-00-00

场景：停掉一台应用

结论：另一台 40 秒内接过流量

一、演练结论

9月14日 16:00 在预发停掉两台应用中的第 1 台，用来确认预订和请假还能提交。第 2 台在 40 秒内接过全部探测。停机期间探测 30 次，失败 1 次，发生在摘除后的第 8 秒。恢复第 1 台用了 3 分钟。张伟认为达到「单台故障不中断主路径」的预期。生产未做同样停机，步骤已写进值班手册的发布说明。

二、演练步骤

王芳先以 1 笔每 10 秒的节奏提交预订探测，确认两台都健康。
周敏把第 1 台移出负载均衡，进程仍在，只是不再接流量。
观察 5 分钟后，再把第 1 台加回，确认两台版本仍是预发的 v1.2.4。
刘洋同时看错误日志和通知是否仍在发送。

三、过程记录

那 1 次失败返回的是连接被拒绝，页面提示稍后重试。王芳按提示再提交成功，没有产生两张相同预订。通知 4 条是演练期间的探测预订结果。

四、改进

摘除后第 8 秒的失败来自负载均衡还没摘干净。周敏把等待时间从 5 秒改为 15 秒再开始对外说「已摘除」。这条已写进 9月16日的发布步骤。下次演练定在 10 月，场景改为停主库前的只读副本，不与本次重复。生产若真的要摘一台，仍按发布步骤里 8 分钟的间隔，而不是演练用的 5 分钟观察。9月14日探测共用了 30 个独立工号，成功写入 29 笔预订，失败那一次没有落库。刘洋核对通知 4 条的 eventId 互不重复，屏上和企微各收到应有的条数。失败的那 1 次发生在 16:05:08，请求没有单号。其后第一笔成功是 16:05:18 的 BK-0000-199。周敏把 15 秒等待写进 9月16日发布步骤的第 2 步。陈静在演练记录上签字，认为单台故障的结论可以保留到 10 月下一次演练。