技术人必备技能:解决问题方法论——troubleshooting
所以从 troubleshooting 的角度,在做故障定位的时候,可以尝试把一个非常复杂,功能和组件非常多的系统,精简到最基本的系统,测试没问题后,再一件一件把其他的系统组件加进来,这样就可以事半功倍的把这个问题找到并解决掉。但是在一些自研系统的运维过程中,这些系统往往文档和说明并不是特别完善,所以先决条件需要根据系统的异常或者问题去做一些排查,另外也需要跟研发人员,或者是设计人员做一些深入的沟
因为很多系统,特别是 IT 系统或者一些电力系统、通讯系统,都是 7×24 小时不间断运行的。如果一旦发生故障,就要求我们运维人员很快的发现故障,然后用快速和经济的办法去把这个故障解决掉。比如医院有些支撑手术的系统,一旦故障如果不能很快解决的话,甚至会威胁到病人的生命安全。所以 troubleshooting 对我们运维人员来说是一项非常重要的技能和技术要求。 |
什么是 troubleshooting?
troubleshooting 是找到问题发生的根源并将其解决更正的过程,troubleshooting 的目标就是使设备 / 系统回到正常的工作状态。
因为很多系统,特别是 IT 系统或者一些电力系统、通讯系统,都是 7×24 小时不间断运行的。如果一旦发生故障,就要求我们运维人员很快的发现故障,然后用快速和经济的办法去把这个故障解决掉。比如医院有些支撑手术的系统,一旦故障如果不能很快解决的话,甚至会威胁到病人的生命安全。所以 troubleshooting 对我们运维人员来说是一项非常重要的技能和技术要求。
不仅在工作中需要做 troubleshooting,生活中也会遇到。前段时间我跟着朋友在玩王者荣耀,就遇到了一个故障。每天晚上玩这个游戏大概 8、9 点钟就遇到打着打着网络质量变差,操作变得很卡。我很苦恼,作为一个运维人员,或者一个技术人员的本能,我就想网络是什么问题?怎么把它解决掉?所以我就做了一次 troubleshooting 的过程。我对家里所有的无线网络,联通的宽带做了一些测试,尝试对无线路由器做了配置优化,最后定位到是我们家和邻居附近 2.4G 信道太拥挤了,干扰太严重,所以晚高峰的时候大家都有上网需求,会互相干扰。后来我把信道切换到 5G,世界就清静了,可以安心打游戏了。
解决问题的通用方法
后来我就思考,有没有非常科学和规范的流程或方法,按照这个方法一步步做下来,就可以解决任何故障或问题?尽管问题多种多样,实际问题解决的方式也是多种多样,对于具体场景和问题,可以制定特定的问题解决流程。在具体的工作中,大家有做 SA 的,也有做网络的,也有做 DBA 的,每一个特定的方向都会有一些跟专业和问题场景相关的 troubleshooting 方法。
对于通用的问题,是否会有通用的解决方法和解决步骤可以遵循呢?
这是 《troubleshooting and maintaining cisco IP network》 这本书的作者总结的一套相对一个通用的方法。他把 troubleshooting 整个过程分成了 7 个步骤,从定义问题,到收集线索和信息,到分析、假设、排除可能性,最终可以把问题解决掉。
在一些复杂的系统或复杂问题的 troubleshooting 中,我们可以按照这个解决方法的流程对问题去做一些抽象和定义,然后一步一步来解决。
具体策略与技巧
在这个标准流程和方法之外,我们可能会遇到一些相对简单或者更直观的问题,可以使用一些具体的策略和小技巧来更快速的 troubleshooting。
排查先决条件
我们经常会遇到电视按了开关怎么没反应?电脑怎么开不了了?这个问题有非常大的可能性是电源没插,或者停电了。从这个事情引申出来,任何系统运行都需要一些必要的前提条件,或者叫先决条件。在系统或服务发生异常的时候,需要回过头来了解一下这个系统有哪些依赖关系,有哪些先决的条件,这些条件是不是之前是存在和正常的,现在条件不满足了,所以发生了一些故障。
比如说摩托车在行驶过程中不走了,是不是没油了?在一些非常成熟或者产品化做得非常好的产品,比如说 iphone 手机,它的用户手册里会列出正常运行的条件,以及要远离哪些条件,比如高温、低温等,会做一个非常明确的定义。
但是在一些自研系统的运维过程中,这些系统往往文档和说明并不是特别完善,所以先决条件需要根据系统的异常或者问题去做一些排查,另外也需要跟研发人员,或者是设计人员做一些深入的沟通,找到系统的一些先决条件,然后作为一个排查的线索去进行排查。这是第一个很基本的 troubleshooting 方法。每一个人都解决过类似的问题,大多数的问题往往是很普通的原因造成的,而我们的经验和直觉可以帮助解决。
最精简系统
我们进入下一个问题解决的策略,大家都有装过电脑的经验吗?一套计算机系统有很多部件,比如 CPU、内存、电源、机箱、显示器、光驱、鼠标、音响、网卡,等等。我们在装机的时候并不是需要一次性全部装好,往往是把电源,主板、CPU、内存装好后,就可以试试这套系统能不能正常工作。如果这个系统能亮,说明这套系统最重要的部件是 OK 的。所以从 troubleshooting 的角度,在做故障定位的时候,可以尝试把一个非常复杂,功能和组件非常多的系统,精简到最基本的系统,测试没问题后,再一件一件把其他的系统组件加进来,这样就可以事半功倍的把这个问题找到并解决掉。
恢复默认状态 / 重启
另外一个跟第一种场景类似,系统经过长时间的运行,工作状态不正常了,一般怎么解决呢?重启一下。在我之前的前东家有一条不成文的规则,重要的系统在节假日前做排查,如果超过多少天没有重启,就会安排一次计划中的重启,来避免系统长时间的运行导致的异常的状态。
所以可以用一些重启的方案来把故障恢复到系统初始的状态,把这个故障解决掉,这是一个非常强有力的一个故障解决方法。当然,重启前需要考虑预期外的后果,比如可能启动失败会导致更差的后果。除了重启,还可以重装 / 重建系统,从默认或正常工作的系统复制一个副本出来。
一次更换且只更换其中一个组件
当我们通过一些分析定位发现,故障可能发生在某个子系统或者某几个模块之内,有什么办法能够很快的定位问题呢?可以尝试去更换其中一个部件,然后测试下。使用这个方法,可以通过排查一步一步精确定位到故障点,然后去解决。这为我们以后遇到类似的问题提供了宝贵的经验。在使用这个方法的过程中,需要注意,每次只更换一个组件,测试完成后如果需要更换其他部件,首先要讲之前更改的恢复原状。否则可能会因为变更导致出现多个问题,影响和干扰问题的解决。
写在最后
troubleshooting 既是一门科学,也是艺术。除此之外,还可以尝试复现问题、更改启动和配置顺序等等方法,在实践中根据时间、资源、场景情况和限制,选择最适合的策略,完成 troubleshooting。Happy troubleshooting!
作者介绍
滕传永,美团云架构师。先后在百度和 eBay 从事系统和服务运维工作,工作涉及基础服务运维,大规模系统部署和优化,虚拟化等。12 年加入美团,负责运维工作,主要集中在基础服务运维,数据中心和网络建设,云计算环境建设和运维等方面。
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)