事故概述

事故背景

由于项目组某核心研发成员与项目组内其他成员发生不可调解的矛盾，导致事发当天该成员被裁，出于报复心理，该核心研发成员对正处于线上内测的项目进行了一系列损毁行为，包括：

• 删除线上数据库、当日数据库备份文件及相关日志文件
• 删除 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 回收站保底措施，大部分数据得以保存和恢复，针对此次事故做出如下反思与优化：

• 数据库定时备份：每日定时对数据库执行备份，确保数据库的备份存在且数据持续更新
• 文档本地化备份：项目文档及相关接口说明要按照一定开发周期持续收集，以文件形式备份，不能只依赖线上协作

反思总结

针对此次事故，除了上述各个环节的反思之外，还有其他需要注意的点：

• 优化员工离职流程：要确保员工离职前做好项目交接，做好权限回收以及善后工作，避免项目人员离职后再出现问题
• 对员工权限管理做出分级和管控：此次事故中，该离职员工所持权限过大，导致其破坏行为无法加以限制，将项目最高权限分级放权，严格执行权限行为规范
• 加强员工法律意识建设：对项目组成员进行法律知识科普，知晓此类恶意破坏行为所带来的法律风险