一条很重要的经验和观点，甚至是颠覆你对故障根因认知的观点：故障根因不止一个，与其争论根因是什么，不如一起看看引起故障的原因都有哪些，是不是都有改进的空间。
所有导致故障和衍生故障发生、业务恢复过程中耗时较长、以及做出错误决策的原因和环节都提炼出来，把这些都算是故障原因，然后针对这些问题和环节制定改进措施。
那这些原因和环节该怎么找呢？在做故障复盘的时候，首先会结合 Timeline 来做，也就是按照 MTTI、MTTK、MTTF 和 MTTV 先做一个分类；然后针对耗时长的环节，反复讨论改进措施是什么；最后定好责任人和时间点，后续持续跟进执行状况。
如果把这些经验再提炼一下，那就是总结出来的故障复盘黄金三问：
第一问：故障原因有哪些？
第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？
第三问：当时如果我们做了什么，可以用更短的时间恢复业务？
具体开复盘会的时候，就是紧扣着这三问来进行的。除此之外不允许出现相互指责和埋怨的情况，如果出现，会议主持者要及时控制并打断。
通过黄金三问，我们找到了故障发生的原因，也明确了做什么可以优化，那接下来就是落地了。要落地，就要明确到底应该由谁来承担主要的改进职责。注意，这里我没有用谁应该承担主要责任，而是承担主要的改进职责，也就是由谁来执行改进措施。
制定了一些故障判定原则，最重要的就是下面这三条。
1. 健壮性原则
这个原则是说每个部件自身要具备一定的自愈能力，比如主备、集群、限流、降级和重试等等。例如，在 B 依赖 A 的状态下，被依赖方 A 出现问题，但是能够快速恢复，而依赖方 B 无法快速恢复，导致故障蔓延。这时，承担主要责任的是依赖方 B，而不是被依赖方 A。
如交换机故障发生主备切换导致的网络瞬时或短暂抖动，从网络设备这个组件来说，自身是有自愈能力的，而且在极短的时间内就可以恢复。如果应用因为抖动而失败、无法自愈，这种情况，业务应用就不能以服务器或网络故障为理由，不承担改进职责。
原则上，核心应用对非核心应用的依赖必须要有降级和限流手段。如果因为非核心应用的故障或者瞬时高并发访问，导致核心应用故障，这种情况下，主要的改进责任在核心应用，非核心应用只需要配合改造。
2. 第三方默认无责
如果使用到了第三方的服务，如公有云的各类服务，包括 IaaS、PaaS、CDN 以及视频等等，我们的原则就是默认第三方无责。
这种涉及第三方服务的情况，在判定改进责任时会分为两部分，对内谁的服务受影响谁改进，并对外推进第三方改进，但是稳定性一定要做到相对自我可控，而不是完全依赖外部。
比如，一个应用使用了 CDN 服务，如果一家 CDN 厂商服务出现问题，要做到随时可以切换到另外一到两家，这时就不能以某家 CDN 服务故障为由不做改进。如果用到了云存储，如 S3、OSS 或 COS 这样的服务，一定要保证存储有主备，当一个区域有问题时，也要做到可切换，甚至容忍一定的业务有损，但是必须保障全量没有大问题。
如果再提升下高可用视角，就要考虑做到双活或多活，单个 Zone 甚至单个 Region 出现问题时，也能做到切换。
3. 分段判定原则
这个原则主要应用在情况比较复杂的场景。当发生衍生故障，或者故障蔓延的原因与触发原因不同时，我们会将一次故障分段判断。这样分段判定会让故障问题更聚焦，改进措施也会更有针对性。
做个小结，这些原则的根本出发点就是希望你摒弃 “根因只有一个” 这个的观点，以更开放的心态去寻找不足，而且要从自身找不足，目的就是找到更多可以改进的地方，不断从“故障中学习和改进”。
“故障是系统运行的常态，正常才是特殊状态”。所以，你无论作为什么角色，一定要以一颗平常心来对待故障，能做到这个程度不容易，这就需要我们更加辩证地看待故障，我们一定要做到鼓励改进，而不是处罚错误。文章来源：https://www.toymoban.com/news/detail-426754.html
此文章为4月Day26 学习笔记，内容来源于极客时间《SRE 实战手册》，推荐该课程。文章来源地址https://www.toymoban.com/news/detail-426754.html
到了这里，关于故障复盘的黄金三问与判定三原则的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
