“ 居安思危，思则有备，有备无患。”

团队人员慢慢多起来了。很多工作1-2年的新人。很多都没经历过比较大的事故，在内心深处，也不太明白事故的影响有多大。

软件服务行业服务稳定性方面都讲究几个9的概念。比如，5个9，就是说服务一年稳定性保证在99.999%。而要做到5个9级别，简单算算就知道这个要求服务中间发生故障的时间有多长了。如下图等于315.36秒，5分钟多一点。

当然5个9级别的，要求确实非常非常之高的。很多企业都达不到这么高的标准的。

然而，软件事故就如同交通事故一样，一直会持续不断的冒出来。今天不是这里出问题，明天就是那出问题。再加上人员迭代更替，离职人员的有一些内隐知识跟着消失。人不同，项目也不尽相同，就感觉这种事故问题没法根治。

如果没法根治，那么我们可以总结经验教训，正视问题，可以尽力让后续项目做到更好。

如何做好事故总结，让经验可以传承，我认为一个好的事故总结需要包括6个方面：问题，影响，过程，暴露出的细节，短期优化，长期优化。如下图：

根据这6个分类，细分整理汇总，一份翔实的事故总结就水到渠成一般输出出来。

举个例子来说明下：

问题：

某年某月某天，什么服务发生了异常。如：2021-07-15 管理后台新用户注册服务异常。

影响：

服务中断具体时长，多少分钟？

事故造成整体服务稳定性下降程度，和服务稳定KPI对比。

过程：

过程要详细，说明整个事故的发展过程。几时几分知晓服务异常，如何排查的，排查过程中是否还有其他服务异常，最终如何操作，到具体某事某刻服务才回复的。

整个详细的操作过程复盘后，基本能判断问题的根本原因，也能大概知道短期的优化点在哪些方面。

暴露出的细节：

整个服务定位过程，恢复的过程初步能分析出来事故原因的。也同时就暴露出团队的弱项。这些细节一般可以从3方面来分析：第一，主观态度。从态度上团队有没有重视？第二，客观能力。团队目前在具体哪些方面能力比较薄弱？分析定位能力？mysql优化能力？还是说具体代码实现层面有欠缺。第三，项目流程。整个研发流程上有没有漏洞？存不存在多个迭代共用测试环境情况？

短期优化：

有了上述的分析，此刻就能整理出团队短期需要补的短板。比如，是不是要指定一个健全的生产部署操作手册。提前做好服务整理，代码控制。部署环节就无脑操作就行。比如，要不要短时间对团队组员培训mysql 优化知识。

长期优化：

一口气吃不了大胖子。同样，优化也不是一朝一夕的行为。有哪些事情需要团队长期坚持，长期遵守的规则；又或者说，有些优化必须一一排查，而后才能慢慢优化等等。

如下图，大概以一个注册服务异常事故，基于以上6个步骤，梳理汇总出一份事故报告。用脑图展示出来，一目了然。

前事不忘后事之师，事故总结完成后，从实践中来，还要回到软件工程研发实践中去。

知行合一，最终也还是要实践。心中醒，口中说，纸上作，不从身上习过，皆无用也。