第01章 故障排除的最佳实践

        故障排除是一项技能，和所有的技能一样，不论是变魔术、弹吉他、烹饪或者编程，有的人生来就有天分，有的人则不然。如果你很自然地就掌握了某种技能，可能会认为别人也能很轻松的掌握。毕竟你第一次尝试就学会了骑自行车，可能就会想当然地以为别人学会骑自行车也不需要多付出多少努力。

        有人天生善于排除故障，当出现故障的时候，他们会不假思索地采取行动，本能地选择方法进一步隔离故障，知道查清故障的根本原因。当你把汽车交给一个善于排除故障的汽车修理工，在你刚描述完车子的“症状”后，他就已经开始摆弄你的汽车了，因为在你描述是他已经把问题锁定在了少数几个成因上，并且同样判了问题的原因。做过一些测试后，她确认了预判的正确性，开始动手修理了。另外一种情况是，当你把汽车送给一个不善于排除故障的汽车修理工，你将会收到高昂的维修账单，不断地去维修店换掉汽车的一个又一个部件。

        故障排除技能任何人都可以学，和很多技能一样，故障排除需要用到一些技术，不论天赋与否，都可以通过训练是这些技术成为本能。你不仅想成为排除故障的高手，还希望能构成为排除故障的快手。再用金钱衡量故障时间的环境下工作更是这样。毕竟，不论是优秀的汽车修理工还是差的汽车修理工最终都会修好你的车，但是你更希望哪个汽车修理工来修理你的汽车呢？

        在devops组织里，团队中的每位成员都负责一部分故障排除。开发者排除软件中的漏洞，系统管理员排除硬件的问题，质量团队首先花费大量时间寻找问题，然后尝试定位问题的根本成因。当devops团队中的每个人使用相同的经过验证的顾长排除技术时，整个团队都会从中受益。

        本章介绍的一些故障排除最佳实践可以应用到任何问题上。当你读过本章之后，会发现其中大部分实践都是常识、但是你会惊讶的发现，当遇到问题时，竟然有那么多人都忽略了这些常识。

 

1.1    划分问题空间

        如果你去猜我正在想的一个1~100内的数、你会猜哪个？

比如这个数字是73，每次猜完之后我会告诉你你猜测的数字比这个数大还是小。一些人可能会随机才某个数字，或者从1开始逐步递加。善于排除故障的人可能会这样猜：50（小了），75（大了），63（小了），69（小了），72（小了），73。每次猜测都会排除一般的可能性。这个例子里，为找到正确答案只猜了6次。而如果从1开始递加，需要猜73次。如果是随机猜，有可能要遍历所有数字才能猜中答案。

        这个方法适用于所有的故障排除。面对问题，一些人从可能产生问题的原因列表的底层开始，一步一步解决问题，另外一些人选择随机测试直到幸运的找到原因。以为优秀的故障排除人员选择的每一项测试的结果都会排除一类原因，而不是一个原因，将故障分而治之。划分问题空间之后，即使一项测试不能找到故障的原因根本，测试结果最少也能排除掉几个可能的原因。

        例如，如果我尝试用浏览器访问一个网站，但是请求超时，此时我想测试是网站的原因还是我的网络连接有问题，但我不会立即去查看网线是否没有插好，而是访问一两个通常都很稳定的其他网站。如果别的网站能正常加载，就可以确定我的网络链接正常，从而省去一系列本地网络测试。

        当你和团队中的其他人协作排除故障时，也会在团队成员之间划分问题空间，没有比跟踪一个问题的时候发现有人也在做相同的测试更坏的事情了。当你在团队环境下着手解决一个问题时，要给每个人分配不同的测试并保证一旦某个人排除了一个原因，能及时把结果传递给其他人。

 

1.2    协同工作时的良好沟通

        建立良好的沟通方法是团队排除故障的最大挑战之一。如果没有良好的沟通，两个人不会意识到正在解决相同的问题，一个人会重复排查别人已经检查过的问题。更糟糕的是，人们误解了说明，会让问题变得愈加严重。下面几节将会介绍协作时用到的不同沟通方法，并且描述在不同场景下那些沟通方式有效、哪些无效。

1.2.1    电话会议

        电话会议是解决问题时最常见但也绝对是最坏的方法之一。它最大的问题是电话会议上每次只有一个人可以说话。即便你很幸运，只与直接解决问题的人打电话，但其他人就算有新信息、突破性进展、警告或者别的信息、突破性进展、警告或者别的信息，都不得不等轮到自己发言时说。即使轮到他们发言，因为多次发言的中断、糟糕的电话信号或者来自忘记静音的麦克风背景噪音，不能保证每个人一次就能理解他们所说的内容。在沟通命令行命令、IP地址、日志输出或者任何其他远程技术尤为困难。

        如果解决问题的速度很重要，那么电话会议已经给你设置了很多障碍。首先是花费在查找电话会议号码和接入码的时间。接好会议电话设备。然后等待“中间人”加入会议。接通会议电话后可以预料的是前五到十分钟完全没有意义，因为绘画将会是这样的：

        

        事实上，大多数情况下，并不是只有解决问题的团队成员参加电话会议。许多管理人员爱把电话会议作为一个参与排除故障的方式，并作为中央指挥官去“管理”这个问题，即使他们无法对解决问题做出直接贡献。浙江不可避免地导致频繁请求进度报告，也意味着某个人（很可能是派去解决问题的团队负责人）需要放下正在做的事情去解释。因为电话会议上同一时刻只有一个人可以讲话，所以在解释的过程中，团队的其他成员将无法沟通。

        实际上，下面列出的其他沟通方法都比电话会议要好，所以，我不是说要你扔掉电话会议号码，二十说应该把它作为最后选择使用的手段。

1.2.2    直接对话

        团队成员通常都坐在同一区域，然而，即使团队的每个成员都坐的很近，在处理紧急故障时，人们还经常借助会议电话沟通。如果每个人都离得很近，大声讨论问题有很多优势。首先，这样一般更容易理解别人所说的话；其次，很容易同时进行多个会话。

        直接对话解决问题的不足之处是仍然很难共享相关的技术信息，更不要说冗长的日志条目或者网址。除此之外，这样做通常无法记录绘画内容，所以就没有排除故障的步骤可用于事后分析，同时任何后加入的人需要能狗跟上绘画的进度。另外，若是每个人不在同一个地点办公或者问题发生在下班之后，就又要回到电话会议这个方法上。对我来说，直接对话时其他更好的沟通方法的一个很好的补充。

1.2.3    电子邮件

        电子邮件时协作解决问题的一个好方法，尤其是对于不需要立刻解决的问题来说更是如此。在流行开源项目的漏洞追踪系统中可以看到这样的例子。与语音交流相比，电子邮件的优点是：

                多个会话可以同时进行；

                进行双向对话非常容易；

                很容易粘贴IP地址、URL或者命令；

                可以添加截屏图片或者日志信息；

                后加入解决问题的人可以通过阅读邮件主题从而自己跟上问题的进度；

                自动拥有一个带时间戳的协作排除故障的日志，里面包含了粘贴的命令输出和其他方法无法记录的数据。

        即便如此，电子邮件沟通仍存在很多问题。首先，电子邮件不是实施和交互式的，所以使用电子邮件沟通于面对面沟通相比存在一个延迟，这确实会让故障排除的进程慢下来。其次，冗长的邮件列表难以分析和阅读，尤其是人们有各自不同的回复风格，如上回复风格（top-posting）、下回复风格（bottom-posing）和内联回复风格（inline）。这样很容易让人们忽视那些嵌套在注释中或者粘贴输出数据中的重要信息。如果你是系统管理员并且安装了监控软件，你可能用邮件作为一种统治手段。出问题时，收件箱可能会收到很多报警邮件，这样难以在众多邮件中找到需要的会话邮件。最后，万一你要解决的问题时邮件服务器宕机了，你该怎么办？

1.2.4    实时聊天室

        实时聊天室是团队协作排除故障的最好方法之一。实时聊天室包括IRC或者其他即时通信客户端，例如具有群聊天功能的jabber。下面是聊天室相比较其他沟通方法的一些优点：

            沟通是事实和交互式的；

            个人可以同时交流；

            个人之间可以私密的交流；

            方便粘贴技术信息：

            大多数聊天室软件都具有文件共享功能，因此可以共享截图或日志信息；

            聊天室对话可以保存下来用于以后的故障分析；

            一些聊天室能保留聊天记录，这样新加入的成员也能很容易跟上讨论的进度；

            可以将聊天室标题设置为故障当前的进度，一次来让经理满意。

        尽管如此，聊天室也有他自己的问题。首先，只有部分聊天软件能够保存聊天记录。如果没有这个功能，新加入聊天的协作者只能借助他人对当前故障处理状态的介绍才能跟上进度。其次，任何超出一定行数的信息难以在聊天室里面阅读，所以，你可能会求助电子邮件或者其他方法共享大量的数据。最后，一些人喜欢说话而不是打字，尤其是打字速度不是很快的人更是这样，当这些人加入聊天室后，你的沟通体验会很糟糕。

        毫无疑问，因为隐私的缘故，在排除需要共享敏感数据的问题时，最好使用自己管理的聊天室服务器。IRC和jabber都提供开源服务器，你可以将他们安装在一个环境中，从而确保聊天室内的沟通在你的掌控之下。

1.2.5    备用的沟通方法

        无论选择哪种沟通方法，都要确保有一个适当的备用方法。如果邮件服务器宕机，很难通过邮件去沟通；如果碰到网络故障，你将无法登录内部聊天服务器。提前想好在首选沟通方法无法使用的情况下，将如何与其他人沟通。并确保每个人都知道如何使用这个方法。

1.3    首选快速、简单的测试，而不是缓慢、复杂的测试

        如果每个问题都有一系列并井然有序的测试集合，那就太棒了。然而，通常你会遇到各种各样的原因，这些原因看起来都像是问题的根源所在。你很难知道应该先尝试哪个，一个好的原则时：当你可以执行两个一样好的测试的时候，首选快速或简单得，而不是缓慢或复杂的。

        如果你们团队的宕机时间是用金钱衡量的，那么尽可能快的定位问题的原因非常重要。例如当一个web服务器宕机的时候，有很多不同的方法可以解决这个问题。但是，如果你从ping服务器的方法开始尝试，那么就是在使用一种相当快的方法断定服务器是否联通了网络。如果无法ping通服务器，你就可以着手处理如何让服务器恢复网络连接。若是能ping通，则可以进行更进一步的故障排除过程，损失的只不过时几秒钟时间而已。在团队合作的情况下有个优势是可以很容易同时进行多个测试。在这种情况下，让一个员工做缓慢、复杂的测试而其他人专注更短、更简单的测试是合理的。只要团队成员之间具备良好的沟通，你们就能迅速定位到问题的根本原因。

        尽管应该首选快速、简单的测试，但如果有缓慢的测试可以在无人监视的情况下执行，那么做一下慢测试也无妨。因为起订慢测试后，测试运行期间你可以去做别的事情。同样的思路也适用于那些需要花费时间的故障排除过程。例如，故障排除中有一步是提交一个工单或者给支持人员发送某种通知，当启动这些流程之后，你就可以将注意力转移到其他更需要关注的任务当中。

        另外一个大问题是，网络是否接通？通常一些大问题的原因都很简单。网络和电源线的连接经常会松动，非常轻微的推动就足以让服务器断开网络连接。如果你离系统设备非常近，可以查看下线缆是否接通，快速查看线缆链接比坐在电脑前一分钟等待端口扫描的结果要好得多。

1.4    多尝试过去的解决方案

        事实上大部分问题都发生了不止一次。某些人拥有快速划分问题根源能力的原因是他们以前多次碰到过同样问题。你接触的问题越多，你就越能成为一个更好、更快的故障排除人员。

        解决问题时经常会遇到以前碰到过的症状。努力回忆上次是什么原因造成的这个问题，采取什么步骤隔离问题。多数情况下，问题症状一样，造成问题的原因也相同，如果你能识别出来这个症状，就能非常快速的解决问题。俗话说的好，如果他走起路来像鸭子且叫声也像鸭子，那它可能就是鸭子。

        然而，有时候他并不是鸭子。我曾经见过某些人在听到任何相似的症状时就采用使用过的解决方案去解决问题，完全不在听取任何其他的描述。实际情况是，完全不同的问题经常也可以产生相同的症状。尤其时那些表面症状。例如，登入服务器的话会有延迟并且看起来非常缓慢，在服务器负载很高或者网络i链接不佳的情况下都会出现这样的情况。Nmap（一个很好用的端口扫描工具）会报告一个端口被过滤，如果防火墙阻塞了这个端口或者某个路由器配置错误的话。如果过早的把注意力放到过去的某个解决方案中，会让自己对问题产生偏见，从而更难找到造成问题的真正原因。

        关键的一点是即使你用之前的解决方案指导故障的排除过程，也务必验证你的假设。如果你记得上一次隔离问题的一些方法，那么这次你应该能用一个测试很快的验证问题，如果测试结果不同，就准备好采取别的解决方法吧。

1.5    记录问题和解决方案

        如我所说过的，大部分问题都发生了不止一次。利用这个事实的最好方法之一是记录问题及其解决方案。许多人将这个过程称为事后析误。一个问题解决以后，参与解决问题的人聚集在一起记录哪里出错了，每个人分别采取了什么措施来隔离问题，相应的结果是什么。时候剖析的最后确定问题的根本所在，更理想的情况是，实施进一步的方案去防止此类问题再发生。

        尽管时候析误会占用每个人的时间，但是有很多理由值得这么去做。主要原因是，如果同样的症状下次再出现，会很难想起上次解决这个问题是做的每一件事情。情急之下，你能记起的只有你曾找到一个排除故障的步骤列表去隔离问题。

        记录问题的过程也会让团队中的每一位成员成为更好的问题解决者。团队中的初级成员从资深成员的经历中受益，每个人一起学习新的工具和技术。更重要的是，如果问题的解决方法记录下来，团队中的初级成员很容易自己就能解决问题。这意味着你在度假或者睡觉时就会少被打扰了。

        若运用得当，时候析误将成为一笔有价值的财富。倘若运用不当，则它们引发的问题会比能解决的还要多。讨论和记录故障排除方法与过程非常棒，但你必须追溯到问题的根本原因。一旦问题小时，确实要花费很多时间和努力去查阅日志来追查问题的根源。很多时候一个团队只能做到描述问题的症状是什么，采取了什么措施消除了这个问题。团队经常通过重启系统或者服务就解决了问题。如果不能隔离问题的根源，很可能会一次又一次的遇到相同的问题。

        当然找到问题的根源尽在你想采取措施防止文通重现时有用。一旦你掌握了问题的根源，就可以相处解决问题的方法和能解决问题的人员。这说起来容易，但若不了解问题的根源，可能会再次碰到这个问题。最坏的情形是，你认为从根本上解决问题从而一劳永逸的努力是白费的。

        一些团队会有相反的问题。他们喜欢用时候析误去分析问题根源，但只是为了知道应该则被谁，事后析误在这种环境下就会变得有防御性，且常带有侵略性，这最终会起到相反的效果。当事后析误变得只有指责，人们不大可能去参与它，而很可能隐瞒事实，尤其是问题可能齐达内镰刀自己时。最后，即使你发现应该责备某人，但是可能并没有找到问题的根本原因。当你不得不排除一个新问题的原因在于你，而不是我。

        最后，有些人非常喜欢时候析误以至于他们在问题解决之前就开始这么做了。当你身处于一个危机当中的时候，你的关注点你应该在手上的问题和你要隔离问题而采用的故障排除手段。这时候了解问题的根源还为时尚早，追问”我们怎么做才能让这样的事不再发生“也没意义。如果你解决过复杂的问题，你就知道，在解决问题的过程中，你认为可能的问题根源会不断地发生改变。通常排除故障压力很大，需要极度的专注，尤其是当故障花费公司金钱的时候，任何注意力分散都以为着解决问题的时间会更久。

        即使你已经鉴定出问题的根本原因，最好给每个人足够的时间冷静下来，镇定一下，在你计划长期的解决问题方案之前认真思考刚才发生了什么。缺少那些额外的时间，你很可能会碰到反对意见，这将要么推迟问题的解决，要么造成比他们解决的问题还多的问题。

1.6    了解改动

        系统问题的一个最大来源是改动。如果系统已经流畅地运行了很久突然出现一个问题，你首先应该问地问题是：哪里发生了改动？如果系统一直都不稳定，就不必把新的改动作为问题地来源之一。但是对于运行一项稳定地系统来说，在所有其他因素相同地情况下，海东地内容应该作为你进行故障排除地第一目标。鉴定和排除对系统地改动将会显著加快排除故障的过程。

        尽管对系统地更改可能是问题地来源，但你如果没有办法追踪到更改，很可能发无法更快的解决问题。如果你缺乏追踪所作更改的方法，就应该认真的考虑寻找一个方法，尤其是当你地系统曾经很稳定时。没有比收到报警更好的了，”jim在问题发生地那段时间提交了代码“，这可以迅速追踪到问题。没有比在稳定的系统上发现一个问题，当想要知道对系统做了什么改动时却无从得知更糟糕地事情了。

        即使通过某些方法能了解到改动的内容，你最好还是要求自己每次制作一个改动。如果能在问题发生时指出之前地一个改动，会很容易隔离问题。弱听是更改了10段代码和3个配置文件就很难隔离问题。我曾经遇到一些团队用维护窗口作为追踪变更地方法，结果很多不相关的信息都涌了出来。问题在于在这样的维护窗口下发生问题地时候，很难隔离问题地根本原因。

        如果有一个系统专门用来记录改动那就太棒了，这个系统最好还允许回滚那些引发问题的更改。如果没有别的问题，若你能把所有地改动回滚到问题发生之前，而问题依旧存在，就排除了一个主要的假设，然后可以继续做其他测试。即使你能回滚所有的改动，最好仍然每次只做一个改动。回滚多个改动可能会解决问题，但你仍然不得不遍历每个改动去找到问题地源头。

        上面说了这么多，但改动不总是造成问题地原因。事实上，我曾经见过”更改了什么“这个问题在故障排除过程中转移了很多注意力。想所有其他故障排除哲学一样，验证你认为是改动造成地问题假设，而不要在刚碰到问题是就回滚全部改动。

1.7    了解系统如何工作

        这么多年来，作为一个系统管理员我了解道德一点是遇到问题时，每个人都会职责他们知之甚少地技术。在我职业生涯地一段时期内，DNS成了所有网络问题地替罪羊。我不知道为什么会出现这样的局面，不过自打我在那里起，我们地DNS服务器一直都很稳定，但出现网络问题地时候，人们总会问：”是不是DNS宕机了？“我注意到职责DNS有问题地人就是那些对DNS了解最少的人。我的解决方案时在公司内部开设一个资源参加地课程，主要讲DNS如何工作。在那之后，我注意到参加过课程地人在遇到网络问题时不在指责DNS（但少数为参加课程地人仍然是老样子）。

        要点是，本能的去指责自己不熟悉地技术这个毛病排除故障地人员和其他人也有。如果你知道所排查故障的系统如何工作，你将回事一个高效的问题解决者。从解决Linux问题地角度讲，这意味着对TCP/IP、DNS、Linux进程、变成和内存管理都要有较深地理解。本书将以故障排除为上下文来解释这些主题，不过这些都是非常不错地主题，即使不为了排除故障也应该了解。

        你会发现，对系统如何工作了解的越多，解决系统问题地速度就越快，同时也会发现你对问题地预感更加准确。这也能帮助你避免做无用功。你将不用执行很多测试就可以排除引起某个问题地一系列原因。

1.8    谨慎使用Internet

        排除故障时，internet时一个非常宝贵地资源。你可能不是世界上第一个看到某条错误消息地人。很有可能有人已经碰到过和你一样的问题，而且你有可能搜索到可行的解决方法。

        使用internet排除故障地挑战实在开始网络搜索之前，需要对问题有正确、清晰地理解。加入你的服务器没有连入网络，而你只是在搜索引擎中输入”server not on network“（服务器脱机），很可能不会得到有用的结果。一旦你才去某些故障排除措施缩小了问题的范围，并且对问题有了清晰的认识，就能使用具体、有针对性地搜索词条帮助你解决问题。

        当问题故障派出的过程中包含了详细地错误码或短语时，internet是最有帮助的。描述特定问题地错误码特别方便，因为很容易搜索到为你解释错误码含义以及应该如何处理这些错误地人或知识库。如果程序输出的错误信息足够详尽，那么他们也可以作为帮助你解决问题地一个很好的来源。

        使用网络搜索的另一个危险是：如果对问题了解的不狗深入或者没有没有使用特定的关键词搜索，你就会得到大量无价值地信息，并且错误地问题诊断步骤将会让你距离产生问题地根源更远。你还可能会从一群一无所知地人那里得到很多建议。总使从问题本身出发，尤其是要确保在复制、粘贴任何命令或代码之前对他们了如指掌。

1.9    抵制重启

        在windows95时代，重启系统通常是修复问题地最好办法。虽然windows95时代已经救援，甚至现在我们都不再使用Windows作为服务器，但是重启操作在一些人地脑海中已经根深蒂固，当发生故障地时候，他们第一反应就是重启服务或者重启硬件设备。

        使用重启操作修复问题最危险指出不在于它能不能工作，而在于有时候重启系统确实修复了故障。危险之处在于如果通过重启操作修复了问题，你仍然不能识别出问题地根本原因。因为问题消失了无法继续测试，所以可能再也不能找出产生问题地原因。在问题不存在地情况下，寻找问题的原因确实非常困难。如果你不能找出问题地根本原因，几乎可以保证你在晚些时候还会遇到相同地问题。

        不要误解我的意思，我不是说排除故障时，永远不能重启硬件设备或者重启服务。我的意思是你应该把重启作为最后地手段。在开始问题诊断之前，尝试获得所有与排除故障相关地数据，以防问题消失。这可能是一个取巧地策略，尤其是在问题需要花费金钱并且你的老板或者客户尖叫着让你重启机器看看问题是否解决时。但是请坚持立场，如果你觉得老板或者客户不高兴，那就等同样的问题再次出现时再说吧。