理解一个系统应该如何工作并不能使人成为专家，而是掌握系统为何失败才行。
假设-排除诊断法
假设-排除法：我们不断提出一个造成系统问题的假设，进而针对这些假设进行测试和排除。
假设阶段：
我们从收到系统问题报告开始处理问题，通过观察系统的监测指标和日志信息了解系统目前的状态。再结合我们对系统构建原理、运行机制，以及失败模型的了解，提出一些可能的失败原因。
验证阶段：
1、检查该微服务的指标、日志以及依赖的其他服务状态，明确“问题现象”与“正常行为”之间的差异。把假设与实际观测结果进行对比，以判断假设是否成立。
2、对系统进行可控调整（如果怀疑新版本存在兼容性缺陷，可回滚到上一版本验证错误是否消失），并观察操作结果。
诊断实战
以下是一个故障排查的理想模型：
故障报告
每个系统故障都来源于一份故障报告，由报警产生，或者仅仅是同事反馈的“系统很慢”。故障报告最好可以统一格式，写明预期、实际结果，以及如何重现。最好将这些报告存储在Bug记录系统中，保证每个问题都有调查历史和解决方案，可供未来使用。
定位
当你收到一个错误报告时，首先需要判断问题的严重程度，是一个影响全球范围内某项服务不可用的大型问题还是只会影响特定用户在特定条件下的小问题。
对于大型问题，第一反应是立即开始故障排查过程，试图尽快找到问题根源。这是错误的！
正确做法是，尽最大可能让系统恢复服务（比如将用户从问题集群导向其他还在正常工作的集群）。同时在快速定位问题时应及时保存问题现场，比如服务日志等，以便后续分析问题根源使用。
检查
我们必须能够检查系统中每个组件的工作状态，以便了解整个系统是不是在正常工作。
在理想情况下，监控系统记录了整个系统的监控指标，这些监控指标是找到问题所在的开始。
日志是另外一个无价之宝。在日志中记录每个操作的信息和对应的系统状态可以让你了解在某一时刻整个组件究竟在做什么。
一些跟踪工具，例如Dapper提供了非常有用的了解分布式系统工作情况的一种方式。
使用该系统的真实客户端发送请求，以便了解这个组件在收到请求后具体返回了什么信息。
诊断
对系统设计的详细了解，有利于我们提出合理的猜想。以下一些方法可以在不完全了解系统情况下提供帮助：
1、通过接口文档以及测试用例｜单元测试检查输出是否正常；
2、一个多层系统中，最好的办法通常是从系统的一端开始，逐个检查每个组件，直至系统最底层。在大型系统中，逐个检查可能太慢了，可以采用对分法将系统分为2部分，确认问题所在再进行顺序排查。
3、最后一个更改，检查最近对系统的修改可能对查找问题根源很有帮助。
4、开发有针对性的诊断工具。
测试和修复
根据上述流程，我们已经有了一个相对较短的可能原因列表，然后执行一些具体的试验，逐一排除可能原因。在试验上有一些提倡建议：
- 一个理想的测试应该具有互斥性，通过执行这个测试，可以将一组假设推翻，同时确认另外一组假设。
- 先测试最可能的情况，按照顺序进行测试。
- 将你的想法和已经执行的测试记录下来，避免重复执行。
造成低效排查过程中的常见陷阱：
- 关注了错误的系统现象，或者错误地理解了系统现象的含义，导致在错误的方向上浪费时间。
- 不能正确修改系统配置信息、输入信息或者系统运行环境，造成不能安全有效的测试假设。
- 年年不忘之前曾经发生过的问题，认为仍与之前问题有关。
- 试图解决从属问题，而不关注根源问题（比如发现数据库压力大的情况下，环境温度也有所上升，于是试图解决环境温度问题）。
我们要记住，一些同时出现的现象可能是由同一个原因造成的，但这些现象并没有因果关系。
事后总结
核心价值
在事故发生后，我们要修复根源性问题，同时将服务恢复到正常状态。如果没有一种方法从已发生的事故中学习经验，那么事故就可能循环反复地发生。如果不能解决这个问题，那么随着系统规模和复杂度的增加，事故可能成倍增加，最终导致我们没有足够的资源处理事故，从而影响最终用户。因此，事后总结是SRE的一个必要工具。
事后总结目的是保证该事故被记录下来，理清所有根源性问题，同时实施有效措施使得未来重现的几率和影响降到最低。
事后总结不是一种惩罚措施，而是整个部门的一次学习机会。
触发条件
- 宕机或服务质量降级达到一定标准
- 任何类型的数据丢失
- 需要人工介入的事故（回滚，切换流量等）
- 问题解决耗时超过一定限制
- 监控问题（事故前未触发报警，而由人工发现的）
事后总结原则
- 事故造成的影响
- 未缓解该事故采取的措施
- 造成事件的根本原因
- 防止未来问题重现的后续任务
事后总结文档应该尽可能大的范围内公布，传递给所有能够因此获益的团队和部门。
文化落地策略
建立起事后总结文化需要不对培育和加强，Google通过高级管理层主动参与写作和评审环节来不断加强此文化，在引入事后总结机制的时候，最大阻力来源于对投入产出比的质疑，以下策略可以帮助面对这些挑战：
- 逐渐引入事后总结流程。首先进行几次完整的和成功的事后总结，证明它们的价值，同时帮助确定具体书写事后总结的条件。
- 确保对有效的书面总结提供奖励和庆祝。不光通过前面提到的公开渠道，也应该在团队或个人的绩效考核中体现。
- 鼓励公司高级管理层认可和参与其中。
