#故障案例分析

2015 年 5 月 27 日晚上 22:52，携程官网和 App 同时崩溃，所有订单页面显示空白。一个小时后，官方微博声明「服务器遭到不明攻击，正在紧急恢复」。

但真相远比「不明攻击」复杂。携程某位工程师在调试生产数据库时，执行了一条 DELETE 语句，本意是删除测试数据，WHERE 条件却写错了——把正式环境的用户航班信息表清空了。更要命的是，这台数据库没有开启 binlog，备份是 5 小时前的，意味着过去 5 小时的所有用户操作数据永久丢失。

这不是「不明攻击」，这是一个工程师的失误，加上极其脆弱的数据安全机制，共同酿成的事故。

故障是互联网公司最昂贵的学费。每一次重大故障背后，都有系统设计的盲点、团队协作的缝隙、技术债务的积累。学会从别人的故障中学习，比自己踩坑要划算得多。

#四类典型故障场景

这四类故障覆盖了 80% 以上的线上重大事故。不是因为技术有多复杂，而是因为团队在这些地方最容易被「理所当然」所蒙蔽——没有人觉得自己的备份会失效，没有人觉得一次普通发布能搞垮整个系统。

#阅读路径

故障学习的顺序不是随意的，正确的路径对应故障的生命周期：

发生（大型故障复盘）
  ↓
分析（故障根因分析）
  ↓
预防（故障预防措施）
  ↓
响应（应急响应流程）

先看大故障，知道故障长什么样；再看根因分析方法，学会怎么找病根；然后看防护体系，知道怎么事前堵漏洞；最后看应急响应，知道事发时怎么止血。

#一个核心认知

故障复盘不是为了追责，而是为了回答一个问题：下次怎么不让同样的事情发生？

好的复盘会追问到系统层面、制度层面的问题。比如携程的事故，追问「为什么一个工程师能在没有审核的情况下直接操作生产数据库」，比追问「哪个工程师犯了错」要有价值得多。

本分类的四篇文章，就围绕这个逻辑展开。