什么是专家？专家不是说只知道系统如何工作的，而是通过调查系统为什么不工作，积累经验成长成专家的。——Brian Redman
事情正常运作是事情出错的一个特例。——John Allspaw
我们认为问题解决是可以学习和可以指导的。问题解决依靠两点∶问题解决的逻辑和系统知识。
理论：
在理想模型中（如下图所示），我们通过问题报告来了解系统出了什么问题。然后我们去看系统现象和日志来了解目前系统的状态。这信息和我们知道的系统设计，工作原理，失效模型结合起来，使我们定位出一些可能导致系统失效的原因。
通常有两个方法来验证我们的假设。我们可以对比系统的状态和我们的理论来找到确认或不确认的证据。或者，在某些情况下，我们可以在受控的条件下去改变系统，观察结果。选用其中一个方法，重复测试直至找到根因，然后再采取正确的措施来规避问题再现，同时写个事后报告。当然，解决可能的问题不一定非要等找到根因之后再处理。
常见陷阱：
1.查看不相关的问题或对系统矩阵的错误理解。
2.为了安全和有效的验证假设，错误理解如何改变系统参数、环境。
3.有关错误想到的是不大真实的理论，或关注于过去问题的原因上，认为既然它发生过，它肯定会再次发生。
4.找到假的相关性，这些相关性实际是起因的巧合或相关内容。
不要想复杂了，考虑事情更有可能发生的情形。医生常常被教导：当你听到蹄声，想想有可能不是斑马。
我们知道什么，不知道什么，应该知道什么的方法论。
实践：
事实上，问题解决永远不会和我们理想模型一样简明。我们可以采取一些步骤使得我们的过程更加简洁和高效。
一、问题报告
所有的问题都源自于问题报告，有效的报告应该包括期望的动作，实际的动作，最好包括这个实际的动作是如何产生的。理想的情况下，这些报告应该有一个固定的格式和方便查询到的存储的地方。我们的团队经常用定制化的格式和小的web应用来查询相关的问题信息。这也为故障自查和自愈系统提供了工具。
在谷歌针对每一个问题开一个bug是很常见的做法。我们的队伍不鼓励报告直接发给某个人，理由如下：这个做法导致了多加一个将报告转化为bug的过程，产出的低质量报告对团队其他成因不可见。发给团队的话可将问题解决的压力集中到多人的身上。
二、问题分类
当你收到一个问题报告，下一步是明确将怎么做。比如根据事情的严重性来确定处理优先级。你的第一直觉不应该是找到根因，而是尽快恢复系统。就像飞行员一样，问题查找是第二要素，第一是确保乘客安全着陆。
三、问题检查
我们应该要做到知道系统中的任何一个部件是做什么的，这样才能明白它是否正常工作。
理想情况下，监控系统会为你的系统记录矩阵，可以通过矩阵来定位问题。图表－时间和操作－时间是个有效理解系统行为的方法。
日志记录也是一个很有价值的工具。系统状态的日志记录会告诉你系统某个时间点在干什么？你需要分析一个或几个系统的日志。可以通过使用Dapper工具来跟踪需求是个理解一个分布式系统如何工作的方法。
展示目前状态是第三个工具。Google的服务器通过终点来展示系统是否正常。这些终点可以让你不需要架构图就可以了解任何系统和其它系统的交互情况，也可以展示错误率和延迟的直方图。
最后，你需要指导一个客户来做实验，来发现这些需求返回的是什么状态。
第四、问题诊断
全面理解系统设计有助于提出系统可能出现问题的假设，一些遗传的实践也可以在没有主要知识的情况下帮助问题诊断。
1. 简化和减少
理想情况下，系统会有明确定义的界面以及输入输出的转化过程。然后可以通过部件间的联系（如数据流）来确定给定的部件是否正常。通过给定的测试数据输入，来检查输出结果。有一个固定的可再生的测试案例可以使debug更快一些，这些测试案例也可以在有攻击性的或风险高的技术要求的非生产环境使用。
划分和解决问题是非常有用的问题解决方案思路。和数据流的处理方式类似，也是看系统端到端是否出现问题。在一个非常大的系统中，线性处理问题可能会比较慢，所以将系统划分成两部分进行诊断很有必要。找到哪部分出了问题之后，再通过二分法进行处理直到找出错误的部件。
2. 多问"what" "where""why"
一个故障的系统通常仍然会尝试做一些事情，一些你不想让它做的事情。找到它在做什么，然后问为什么它这样做？它的输入和输出是什么？有助于你了解为什会出现问题。
3. 最终触发的条件
系统是有规则的，最近系统的变更最有可能导致问题出现。
4. 特殊的诊断
在很多领域，之前介绍的工具对问题诊断是非常有帮助的。Google SRE花很多时间在工具建设上。很多工具仅对给定的系统有帮助。确保找到服务和团队之间的公用之处，避免重复浪费时间和精力。
第五、测试和对症下药
一旦你找到了可能问题原因的清单，就可以开始去查找问题的根因了。在设计测试方案时，要考虑如下几点：
1. 理想的测试有多个选择项，这样可以管理一组假设，但实际上这个很难达到。
2. 先考虑显而易见的问题。比如先减少需要来测试，考虑测试带来的风险，在处理网络连接性问题前找两台机器测试下。
3. 测试可能导致误解性的结果。
4.考虑测试本身带来的影响，如CPU，性能问题等。
5. 测试结果是建议性的，而非直接结果。
要清晰记录你的思路，以便于测试你的想法是否正确。
第六、问题解决
你已经将多个可能的问题原因减少到一个了。下一步就是要证明这就是实际的根因。常见的方法是让问题再现，但这个在生产环境很难实现。原因主要有两个：一是系统比较复杂，可能单个问题都不是问题，但所有的问题集中起来就会导致问题发生；二是若在生产环境再现这个问题会导致影响SLA，这个是不能被接受的。
一旦问题发生，要写故障报告。
如何让问题处理更简单：利用白盒矩阵和结构化日志建设可观察性；设计系统结构间易于理解的和可观察的交互界面。
注：
否定的结果也很神奇。否定是指实验结果没有和计划的保持一致。否定的结果对其他人也是有帮助的，发表使你惊讶的结果吧，这样其他人包括你自己才不会惊讶。
