p0-级重大资损事故复盘
事故概述
事故背景
由于项目组某核心研发成员与项目组内其他成员发生不可调和的矛盾，导致事发当天该成员被裁。出于报复心理，该核心研发成员对正处于线上内测的项目进行了一系列破坏行为，包括：
- 删除线上数据库、当日数据库备份文件及相关日志文件。
- 删除 Apifox 的项目接口及相关文档，导致接口文档不可用。
上述一系列行为导致项目内测阶段遭受到不可逆的损失，包括但不限于：
- 数据库主节点损毁，丢失 3 小时内约 2000 条内测重要数据。
- 项目进度延误 20 人/天，严重影响产品上线。
事故整体时间线（Timeline）
- 7月3日 14:00，该成员办理离职手续。
- 14:30，该员工回到工位。
- 15:00，私自备份数据库数据到自己的个人服务器。
- 15:30，删除 Apifox 接口文档。
- 16:10，删除数据库，更改 Nacos 密码。
- 17:40，后端研发成员发现 Apifox 接口文档被全部删除。
- 17:41，后端研发成员开始阻止该离职成员离开工位，开始全面排查项目损毁情况。
- 17:47，发现数据库不可用。
- 17:50，发现 Nacos 密码被篡改，配置文件全部无法拉取。
- 17:52，组内成员被告知离职人员已将数据库数据同步到自己的私有服务器上，组内成员对其数据进行备份后删除。
- 18:00，发现服务器所有后端环境均被恶意删除，系统全面崩溃。
- 18:24，向运维组紧急申请新的服务器资源。
- 21:00，离职成员在组内监督下执行服务资源迁移。
- 21:20，发现离职成员并没有将服务资源正常恢复。
- 21:25，组内研发成员介入，着手恢复数据。
- 23:00，数据库备份恢复，服务器 Nacos 恢复，其他组件均恢复。
事故发现
事故定性定级
从事故特性上看，本次事故为 P0级 别重大 资损性事故：
- 事故发生导致全部服务不可用，属于 P0 级可用性事故。
- 由于内部软件服务被恶意损毁，导致重大测试数据丢失，耽误项目工时 10 人/天，属于资损性事故。
未能及时发现的原因
事故发生距离事故发现时间较远，项目组内其他成员未能在事故发生最初及时发现该员工的破坏行为，导致损失逐步扩大，直至系统崩溃：
- 本项目组存在人员缺失，缺少专业的 DevOps 成员，项目缺乏运维支持。
- 当时项目存在排期问题，研发成员专注于前端 UI 界面开发，后端人员排期空闲。
- 本项目处于前中期的开发阶段，未部署相关服务监控工具进行健康检测与自动化报警。
上述原因综合，导致人工的被动反馈实时性不足，最终出现了 “小故障 × 长时间 = 大事故” 的情况。
反思与优化
经过此次事故，针对事故发现与响应环节，做出如下优化策略：
- 针对人员缺失和排期问题，优化人员任务分配，解决岗位和排期空档。
- 部署应用健康检测工具，实现实时监控与自动化预警。
事故排查
事故排查过程
由于此次事故过于重大，且为人为原因，因此已初步确定事故问题为人为恶意删除破坏：
- 数据库排查： 后端项目无法连接数据库，数据库连接客户端也无法连接。远程连接服务器后发现
mysqld服务不存在，数据库已被删除。 - Apifox 排查： Apifox 客户端中项目下所有接口文档被删除。
- Nacos 排查： 后端服务无法拉取注册中心配置信息。Nacos 后台可以访问，但密码被篡改。强制接管后发现配置信息已被删除。
反思与优化
数据库被删除后，后端项目因无法连接而已报错，但研发人员误以为是网络问题，没有及时上报。综合其他因素，进行如下反思与优化：
- 提高人员事故防范意识： 出现连接问题时，应以更可靠的方式观测数据库状态，而不是主观臆断为网络原因。
- 加强针对服务日志的分析能力： 当服务出现问题时，及时通过日志进行排查，并定位到问题根源，而不是仅从现象推断问题。
事故决策
负责人决策
本次事故被发现后，项目组负责人立即进行了如下决策：
- 定位涉事人员，并阻止其继续破坏。
- 遵循止损原则，联系项目各组件负责成员，快速对事故进行应急处理。
- 发布通知，将问题同步给组内全员以及相关领导。
反思与优化
本次事故决策由另一位核心研发成员制定并执行，从应急策略上看足以应对此次事件冲击，但仍存在不足：
- 决策方案缺少数据化支撑： 由于损害过大且人手不足，故障排查阶段未将损害范围等事故信息数据化，导致决策方案缺乏数据支持。
- 缺少紧急预案等应急策略方案： 本项目处于发展初期，没有历史事故方案可借鉴，也未针对可能发生的事故制定预案。今后应将决策方案进行沉淀，形成一套完整的事故处理方案体系。
事故恢复
执行决策
由于组内成员结构紧凑，且事发突然，因此很快将涉事目标锁定为当天离职的项目组成员。随后，遵循止损原则进行应急处理，防止灾害进一步扩大：
- 禁止该成员继续操作电脑。
- 回收该成员的代码仓库权限。
- 回收该成员的相关账号权限。
- 联系后端研发人员确认各个服务的损毁状况。
事故发生后第一时间将问题上报直属领导及相关部门负责人，并持续跟踪事故进度，保持信息同步。
事故止损后，对受到破坏的服务和组件进行恢复：
- 将离职成员私自拷贝的数据库文件进行备份后删除，再用备份文件恢复数据库。
- 要求离职人员恢复 Nacos 密码及相关服务。
- 通过 Apifox 回收站恢复文档。
反思与优化
此次为人为破坏，且离职人员持有数据库文件备份，加之 Apifox 有回收站保底措施，大部分数据得以保存和恢复。针对此次事故，做出如下反思与优化：
- 数据库定时备份： 每日定时对数据库执行备份，确保备份存在且数据持续更新。
- 文档本地化备份： 项目文档及相关接口说明应按一定开发周期持续收集，以文件形式备份，不能只依赖线上协作。
反思总结
针对此次事故，除上述各环节的反思外，还有以下需要注意的事项：
- 优化员工离职流程： 确保员工离职前做好项目交接、权限回收以及善后工作，避免离职后出现问题。
- 对员工权限管理做出分级和管控： 此次事故中，离职员工所持权限过大，导致其破坏行为难以限制。应将项目最高权限分级放权，严格执行权限行为规范。
- 加强员工法律意识建设： 对项目组成员进行法律知识科普，使其知晓此类恶意破坏行为可能带来的法律风险。