前几天由于沟通上的偏差,Stripe的工程师把一个关键的数据库表的索引给删了,造成大量的API访问超时、用户使用的dashboard也变得不可用。这篇文章可以当成创业公司事故报告的范文。

简单总结发生了什么事情、给出时间轴、分析造成生产事故的根本原因、给出具体改进的措施(更好的流程、更好的工具等)。任何线上服务、网站都不可能100%稳定、不出故障。一旦出现故障,一定要就事论事地分析、总结教训,避免以后再次发生同样的故障。

大部分生产故障都是自己人差枪走火,比如部署新代码、改了配置文件、升级数据库、fat finger不小心输入了错误的命令行等。所以这种事故分析经常是要讨论如何改进做事的流程。这些事故分析也不用都向全世界公开,但内部一定要归档好,对于新人来说,很有学习的价值:可以很好理解为什么我们有这种工具、这种流程。

分享到: