在《故障复盘的简洁框架-黄金三问》这篇文章里，我把故障原因分为了两类：触发原因和深层原因。
这里我并没有提到根因或根本原因，理由就是我们原本所认为的根因可能往往不止一个，可能会有多个。
这个怎么理解呢？我举个比较容易理解的例子：
比如我们有一台服务器宕机了，上面跑的的MySQL服务也挂了，影响了上层业务访问，花了30分钟才解决，被定性为故障。
那这个故障的根因是什么呢？
有的人可能会说是服务器宕机引起的，服务器问题是根因。
有人会说上层数据库没做高可用，数据库问题是根因。
也有人会说业务层面没做功能降级，到时业务不可用，业务架构问题是根因。
你看，就一个简单的服务访问问题，不同角色就会有不同理解。如果我们再分几个复杂场景看下：
第一，MySQL做了Master-Slave，但是M-S切换时没切换成功，当时DBA还联系不上，花了20分钟联系上，然后上线解决了。
第二，当时Oncall的DBA第一时间就收到告警准备处理了，但是VPN故障了，或者当时所在环境不好，连VPN总是断线，所以延误了问题处理。
第三，MySQL切换2分钟就完成了，但是业务层面因为访问超时等因素，导致雪崩，业务花了20分钟重启，才恢复了业务。
第四，MySQL切换没成功，没有任何异常日志和信息，定位了到了MySQL引擎层面，发现了在某些OS版本下，切换动作会失效。
第五，MySQL切换没成功，结果花了一星期，MySQL内核代码，OS代码，硬件厂商都看了，还是不知道问题在哪儿。
第六，其实业务影响有限，但是当时有几个大客户因为我们一直没反馈处理进展，导致客户十分不满意，认为我们保障不到位，响应不及时，同时认为我们输出的故障报告太简单，没有讲清楚问题所在，所以投诉严重，造成影响二次升级。
那上述几种情况下，根因又该怎么算？算数据库的？算VPN的？算业务的？算开源软件的？还是算对接客户的销售和BD的？又讲不清楚了。
所以，如果我们还是以根因为导向来盯着做复盘，就很容易陷入到无限的纠结中去。
如果我们还把根因跟定责定性挂钩，不用我说，大家也能想象到，无尽的撕逼扯皮和甩锅推诿就该开始了，好好的氛围就会变得阳奉阴违，多做多错最后就是不做不错。（这个点后面单独写篇文章分享）
但是如果我们换个角度，不把根因唯一化，而是系统化的看根因，我把它们叫做深层原因，同时把找原因的目标放到改进上去，就完全不一样了。
比如：
深层原因1：VPN连接效率问题，定位下来与所处位置的网络有关系，所以Oncall人员需要配备两个运营商的上网卡或手机。
深层原因2：值班机制问题，当时Oncall同事外出办事，没法及时上线处理，后续增加备角，主备Oncall必须确保有一人在家，能确保5分钟内上线。
深层原因3：MySQL的主从切换不生效，是因为不同品牌的服务器有特殊配置导致，这个要定期做切换演练，同时每新增一个品牌服务器，要做适配性验证。
深层原因4：业务没做限流和降级保护，核心接口要增加保护逻辑，同时上线前要做专项评审和测试。
深层原因5：针对严重问题，技术支持值班同事要定时向客户反馈进展，安抚客户情绪，同时故障报告要经过评审，确保信息完备后再发出，不能着急发出就草草了事。
深层原因6：xxxx
然后上面的每个原因和Action后增加责任人和完成时间点，故障的改进点就完善了。
其实我们仔细分析下，上面只要有其中一个环节能够做到位，都会大大降低故障的影响度，哪个是根因其实已经没那么重要了。
如果我们能跳出根因这个框框，我们会发现我们可以找到更多的改进点，每个参与者可能都会找到自己应该改进的地方。
当我们每个参与的角色都能主动思考怎么改进的时候，我们的系统稳定性和软件质量的提升不就变成水到渠成的结果了吗？
如果不需要跟定责挂钩的话，其实整个氛围也会改善很多，我们期待的Blameless也就有可能达成了。
前面聊了两期Observability，其中的Tracing部分一直没有详细分析过，正好博文视点刚出了一本的关于分布式链路跟踪的专业书籍，讲的还不错。
跟侠少要了几本送给大家，大家可以关注我的公众号之后，回复“分布式跟踪”，获取送书方式。
