系统出问题后我们该做些什么?

我看到很多公司处理线上故障的方式并不科学，而且存在很多问题，所以，今天这篇文章就来分享一些我的经验。这些经验主要来自亚马逊和国美这两家公司，以及我个人的经验总结。

故障复盘过程

对于故障，复盘是一件非常重要的事情，因为我们的成长基本上就是从故障中总结各种经验教训，从而可以获得最大的提升。在亚马逊和阿里，面对故障的复盘有不一样的流程，虽然在内容上差不多，但细节上有很多不同。

亚马逊内部面对 S1 和 S2 的故障复盘，需要那个团队的经理写一个叫 COE（Correction of Errors）的文档。这个 COE 文档，基本上包括以下几方面的内容。

• 故障处理的整个过程。就像一个 log 一样，需要详细地记录几点几分干了什么事，把故障从发生到解决的所有细节过程都记录下来。

• 故障原因分析。需要说明故障的原因和分析报告。

• 故障后续整改计划。需要针对出现的问题如何举一反三地从根本上解决所有的问题。

   然后，这个文档要提交到管理层，向公司的 VP 级的负责人进行汇报，并由他们来审查。其实需要些COE的情况,就证明事故已经非常严重了!

故障整改方法

第一，优化故障获知和故障定位的时间。

• 从故障发生到我们知道的时间是否可以优化得更短？(发邮件,发微信,如何更快让Oncall人员发现问题)
• 定位故障的时间是否可以更短? (你是否对系统的业务熟悉)

第二，优化开发过程中的问题。

• Code Review 和测试中的问题和优化点。
• 软件架构和设计是否可以更好？
• 如何正确处理因为技术债欠下的问题

第三, 优化故障的处理方式

• 有哪些地方可以做到自动化？
• 处理事务的第一优先级是什么
• 是否能把复杂的东西简单化
• 团队之间如何正确的,有效的沟通

其实我是不认同惩罚和划分故障责任人的,因为你做的越多,错的可能越多,如果不出错,那就最好什么都别做,会让大家的开发变得畏手畏脚,team之间的人员可能会相互推诿,十分不利于大家今后的开发,给整个team中营造了一种恐怖的氛围.

我支持“不从物质上惩罚工程师”。 可以让他针对重大事故进行总结,复盘给大家进行一次分享.大家学的呢?

目录

故障复盘过程

故障整改方法

---