看似不守规矩的问题排查可以说是世界上压力最大、难度最大、最紧张的工作之一，尤其是面对收入极高的业务、海量服务的运营带来极大的恐慌感并引发肾上腺素飙升。压力的存在可能会诱发我们犯低级错误。为了克服这种白痴本能，我们需要克制自己的怒火，并强迫自己有条不紊地进行每一次尝试。其实就是在运维中修炼出来的一种心态。淡定不乱，淡定应对，这才是真。我个人认为排查问题并找到根源来解决是一件很有成就感的事情。曾经有人问我：“你是怎么认为问题出现在xxx的？你是怎么确认根本原因是xxx的？”，我只能淡淡的回答：“靠经验”，后来觉得这个装逼是好的。其实，这里所说的“靠经验”是很模糊的。你可能一直认为排错问题要靠经验，但你分不清是用什么样的经验来排错问题的。***让排查问题逐渐成为一门玄学。其实故障排除工作往往遵循一些普遍的、不成文的实用规则，并不是所谓的玄学理论，结合自己的经验和总结，希望能给大家的实际工作带来收益。从入行到现在，我们遇到过各种各样奇怪的问题。但是，每个业务形式和系统都是不同的。对于某一类问题，我们往往可以搜索到很多解决方案，但个人觉得认知方法，经验很难复制，所以我就通过抽象（集）like（道路）来谈谈“排错”的方法论，希望能引起大家更多的共鸣。解决问题就像解决一个案例。运维排查线上问题就像警察破案。这是一个不断分析线索、推理的过程。但在准备排查问题之前，我们应该了解三个认知：认知几乎就是人与人之间的关系。它们之间唯一的本质区别。——傅盛《认知升级三部曲》系统不正常是正常的。今天，计算机系统已经变得极其复杂。一个用户请求可能会经过发送请求、DNS解析、运营商网络、负载均衡、服务器、虚拟机（容器），根据业务逻辑的复杂程度，还可能调用组件、缓存、存储、数据库。每个环节都可能出现问题，而且有些组件是分布式的，大大增加了排查的难度，所以出现问题后不要惊慌，要保持良好的心态。首要任务是恢复系统“在紧急情况下，飞行员的首要任务是保持飞机飞行。与确保乘客和飞机安全着陆相比，故障定位和排除是次要目标”，因此恢复在线系统是重中之重。而不是立即找出它发生的原因。道理永远只有一台计算机是一门科学，而计算机世界是由0或1组成的，这个世界只有是或否，没有中间地带，所以计算机世界的一切都有一个根本原因，有没有机会，一切都是必然。了解案例和评估大小，首先评估问题的范围，是全网，某些区域，还是某条链路不通，或者多条业务线出现问题，评估案例的大小.正常吗？不管是民事案件还是刑事案件。整理线索，整理分析手头的资料或线索。比如监控上有网络告警，有的用户反映无法访问，有的开发者反映服务器有问题，同时有改动等，尽量不要错过这些看似无关紧要的线索，先把这些线索梳理清楚，以后再分析。推理的过程就是根据已知的线索，通过合理的想象和推理，得到一个唯一的结果。线索是整个推理过程的起点。线索好不好，有没有错误，会直接影响推理的好坏，所以是最基本也是最重要的环节。在整理线索时，最容易犯的错误是信息不足和主观臆断。扩大自己的信息量，积极扩大信息的接收面，比如问问你的开发或者算法同学今天线上有没有改动，网络群有没有大的调整。从中获取有价值的信息点对于故障排除非常重要。查看监控，看某个监控项的变化，跟踪日志，调试信息，都是扩大信息量的手段。业余时间扩展知识，多了解相关系统，如架构、部署、逻辑等，一旦出现故障，讨论也能为你提供解决思路，举一反三，促进排查和解决问题。分析推荐书以确定对与错。如果是外部问题，比如业务投诉、用户反馈等信息，有时可信，有时人不可信。比如之前开发反馈有问题，有的广告位置偏向异常，有的正常，让我们帮忙排查系统问题，但是***是代码调用动态配置导致的。有时反馈信息会被描述者过滤和处理。他的调查和分析可能会让你误入歧途。在收集信息的时候，你需要带着审视和怀疑的态度去分析每个人的证词。每个人的学习能力其实都很强。随着经验的积累，鉴定人证的能力也会逐渐提高。看清问题本质“听到马蹄声，猜是马，不是斑马”。看现象、看事物，要看本质，不要看表面。当你听到马蹄声时，猜猜这是什么马，这是什么人马，有什么办法而不是猜是斑马还是白马或黑马。排除故障时不要先入为主。有时候看似不可能、极其简单的事情，可能就是最终的原因。不要轻易排除某种原因，比如“宇宙射线导致SSD数据错误”。很久以前遇到过某个svr耗时高的问题。检查了半天，做了一些调优，还是不行。最后发现是网卡满了。确定方向，进行定位确定排查方向，比如从大到小，从上到下排查步骤，从大到小，先排查IDC网络等比较宏观的地方是否有问题，机房状况等，一一排除，逐步缩小问题范围。从上到下，先逐一查看现象的最上层调用链，逐步深入。并不是所有的问题都是从大到小，从上到下。宏观问题只有发展到一定程度，才会引起“质变”，才会引起关注。在导致质变的过程中，你的业务可能受到了某种程度的影响，但表现非常明显。这时候就需要进行微观分析，然后逐渐走向宏观诊断。综上所述，破案记性好，不如烂笔头。但是，在混乱的问题分析中，运维冷静地记录问题和判断，确实有点不切实际。但即便如此，我们还是可以在事情结束后保留??一份分析资料，总结记录处理过程中的执行步骤和解决方案，可以帮助自己和团队积累宝贵的处理经验。上面的方法流程翻译成运维术语：出问题不可怕，但怕从问题中学不到东西，又怕类似的问题再次出现，提高效率问题定位。值得做的，例如：建立一个长效的错误代码机制，用具有统计意义和视觉意义的数字来简要描述错误的含义和范围，俗话说，专注是本质，这是经过实践检验的在错误代码中。编写有效的错误日志并建立日志记录标准。正常流程打印错误日志的主要目的是为了更好的排查和解决问题，提供重要的线索和指导。但在实际应用中，错误日志的内容和格式千差万别，错误提示可能不完整、没有相关背景、不清楚，使得排查和解决问题成为一项非常不便或耗时的操作。其实开发只要用心一点，也会减少很多排查问题的无用功。如何编写有效的错误日志，建立日志标准，对问题分析也有很大的帮助。定位问题避免二次损坏。当出现看似难以捉摸的问题时，本能可能是尽快重启并使系统恢复正常。虽然这种方法通常可以解决问题并迅速奏效，但它也可能使情况变得更糟。故障排除方法，包括重新启动不稳定的系统、尝试自动记录数据库、修复文件系统等，通常确实可以解决问题并使系统恢复生产轨道，但它们也可能导致数据恢复工作付诸东流和毁于一旦。失去确定问题根本原因的机会，甚至会大大延长关键系统的停机时间。保留现场也很重要，就像案发现场一样，需要实地勘查、采集样本、侦查、锁定。对于难以复现的问题，尽量创造条件保留可用于故障复现的数据或场地。网络环境复杂多变。虽然这对于立即解决问题没有起到直接的作用，但最终对于业务的长期稳定是有帮助的。建立一个集中的数据可视化平台，让你遇到问题不去分析。如果对业务了解不够，不依赖数据，很可能在解决问题的时候把事情弄糟。建立沙盒影子系统，模拟复杂多变的现网环境，避免上线冲击、重现或压测问题，如tcpcopy、dubbocopy等构建开源日志可视化方案，帮助我们解决***“一公里”问题，如ELK、Log.io等，要想做好，必须先利其器，常见的系统排查工具perf、iptraf、netperf、tcpdump、gdb、pstack、jstack、strace、top、iotop、tsar,etc...结语总结这几年处理问题的一些思路和经验，可以归纳提炼出以下几句话：随时收集信息，记录和协调资源，控制影响，冷静判断，冷静分析大胆假设，认真尝试并积极总结，供日后使用的运维专家或许是每个运维人所追求的梦想。他们敏锐的嗅觉似乎总能找出系统故障的根源。这种快速反应和准确定位的能力源自多年处理复杂系统问题的经验和个人的知识储备，其成功是难以复制的。虽然没有任何组织愿意为其颁发认证资格，但它依然是一项人人乐于追求的“神通”技能。
