运维老司机:问题排查经验总结

导语:运维可以说是世界上最紧张且强度最大的工作之一,每个杂乱无章的问题背后都需要我们的深入的抽丝剥茧。尤其是当你面对的问题直接与收入业务、海量服务运营挂钩时,可谓是肾上腺素瞬间飙升。压力的存在可能诱发我们犯下低级错误。要克服这种白痴般的本能,就需要强迫自己以有条不紊的方式逐一开展尝试。其实做运维练就的是一种心态,足够淡定遇事不乱,从容应对才是真。

从入行到现在,遇到过各式各样千奇百怪的问题,每个业务形态和系统均不一样,排查出问题并找到根本原因加以解决,其实是一件很成就感的事情。曾经有人问过我:“你是怎么想到问题出现在xxx的?又是怎么确认根本原因是xxx的?”,我只能轻描淡写的回答:“靠经验”,然后感觉这个逼装得还可以。其实这里说的“靠经验”是很模糊的,一直以来大家可能都觉得排查问题要靠经验,但是又说不出具体通过什么样的经验排查出了问题,最后让排查问题逐渐变成了一门玄学。其实问题排查工作往往遵循一些通用且不成文的实践规则,并不是一门所谓的玄说。在此,我将结合自身经历、总结,说关于“问题排查”的方法论,希望能与您产生更多的共鸣。

排查问题犹如破案

运维排查线上问题犹如警察破案一样,是一个不停分析线索,推理的过程,但在准备排查问题之前,我们应该明白三个认知:认知,几乎是人和人之间唯一的本质差别。 —— 傅盛《认知升级三部曲》

系统出现异常是正常

时至今日计算机系统已经变得异常复杂,一次用户请求可能要经过发送请求,DNS解析,运营商网络,负载均衡,服务器,虚拟机(容器),视业务逻辑的复杂程度可能还要调用组件,缓存,存储和数据库等。每个环节都可能出现问题,有的组件又是分布式的,大大增加的排查问题的难度,所以出现问题后不要慌,保持好的心态。

首要任务是恢复系统

飞机在发生紧急情况下,飞行员的首要任务是保持飞机飞行,相比保证乘客与飞机安全着陆,故障定位和排除是次要目标”,所以恢复线上系统是首要任务,而不是立马找到它发生的原因。

真相永远只有一个

计算机是一门科学,而且计算机的世界里都是由0或1组成,在这个世界里只有是或否,没有中间地带,所以在计算机世界凡事都有根本原因,没有偶然发生,一切都是必然。

了解案情,评估大小

先评估出这个问题的影响范围,是全网,某些地区,还是某条链路不可用的问题,还是很多业务线都出现问题,评估出案情的大小,到底是普通的民事案件,还是刑事案件。

理清线索,整理分析

理清手头已得到的信息或线索,比如监控上有网络报警,有用户反馈无法访问,有开发人员反馈服务器有问题,同时间段有做变更等等,尽量不要漏掉这些看似无关紧要的线索,把这些线索先整理下来,后面一并分析。 推理的过程,就是根据已知线索,通过合理的想象、推断得出一个唯一的结果。线索是整个推理过程的起点,线索给出的好有不好、是否有错误,直接会影响推理的质量,因此是最基础、也是最重要的一环。线索的梳理,最常犯错误就是信息不足,主观臆断。

扩大你的信息量

主动扩大信息的接收面,比如问询一下开发或算法同学,今天有没有做线上改动,网络组有无重大调整。从中获取到有价值的信息点,对于排查问题至关重要。查看监控,细看某个监控项的变化,追踪日志和调试信息都是扩大信息量的手段。 拓展知识面,闲暇时间多些了解相关联系统,比如架构,部署,逻辑等。一旦故障发生,讨论中也可提供你解决办法的思路,举一反三,推进问题的排查与解决。

分析证词,甄别对错

如果是外部提出的问题,比如业务投诉,用户反馈等信息,有时候是可信的,有时候人却是不可信的,举个例子之前有开发反馈效果有问题,有些广告位bias异常,有些正常,让我们帮查查系统的问题,但是最后是代码调用一处动态配置造成的。有些时候反馈的信息,是经过描述者过滤加工过的信息,他的排查和分析有可能把你带偏了,在收集信息同时需要以审视、怀疑的态度,分析每个人的证词。 每个人的学习能力其实都很强的,随着经验的积累,甄别证词能力也会逐渐提升。

看清问题本质

“听到马蹄声时,猜马,不要猜斑马”看到一件现象或一件事情,要看实质而不只是表面的东西,听到马蹄声时候猜是什么马,是什么人的马,是来干什么的而不是猜它是斑马还是白马还是黑马。 排查问题也一样切忌先入为主,有时候看似不可能发生、极其简单的事情可能就是最终原因,不要轻易的排除掉某项原因,比如“宇宙射线引发SSD数据错误”。 很早之前碰到过一个某svr耗时高问题,查了很久也做了一些调优依然不见效,最后发现其实是网卡跑满了。

确定方向,开展定位

确定侦查方向,如从大到小,从上到下排查步骤,从大到小先看比如IDC网络,机房状态等比较宏观的地方是否有问题,逐一排除,逐步缩小问题范围。从上到下先从现象发生的顶端调用链逐一排查,逐步向下深入。 并不是所有问题都从大到小从上到下,宏观问题只有达到一定量级才会引发”质变”,从而引起的注意,在通往质变过程中,你的业务可能已经收到某中影响而表现的很明确,此时需要微观分析,然后再逐渐到宏观来诊断。

卷宗记录,破案归档

好记性不如烂笔头,然而在一片混乱问题分析当中,让运维心平气和地记录下问题与判断确实有点不切实际。但即使如此,我们仍然可以在事情结束后为保留一份分析资料,总结并记录处理过程中的执行步骤以及解决途径,则能帮助自己和团队积累宝贵的处理经验。 以上方法流程翻译成运维术语:

吃一堑长一智出了问题并不可怕,怕的是我们从问题中学不到什么,怕的是类似的问题重现,提高问题定位的效率,有哪些值得去做,比如: 1、建立长效错误码机制,使用具统计、可视意义的数字来简短描述错误含义和范畴,正所谓浓缩就是精华,这一点在错误码屡试不爽。 2、正常程序中打错误日志主要是为了更好地排查问题和解决问题,提供重要线索和指导。但是在实际中打的错误日志内容和格式变化多样,错误提示上可能残缺不全、没有相关背景、不明其义,使得排查解决问题成为非常不方便或者耗时的操作。而实际上只要开发稍加用心,也需就会减少排查问题的很多无用功。如何编写有效的错误日志,建立日志标准,也是非常有利于问题分析的。 3、定位问题避免二次损害,当某个看似难以捉摸的难题出现时,本能可能是重启,尽快让系统恢复正常。虽然这样的方式经常能够解决问题而且起效神速,但同时也很可能把情况推向令人难以置信的恶化深渊。问题排查手段包括重新启动不稳定系统、尝试自动记录数据库、文件系统修复等等,这些方式往往确实能搞定难题并让系统重回生产轨道,但同时也没准导致数据恢复努力付之东流,毁掉确定问题根本原因的机会甚至大大延长关键性系统的停机时间。保留现场也非常重要,跟破案现场要要求现场勘察、样本采集、排查、锁定如出一辙,对于难以重现问题,尽量创造条件保留了可以用于故障重现的数据或现场。 线上环境复杂多变,虽然这一点并不能马上解决问题起到直接作用,但坚持这种处理思路,为开发和测试创造条件,降低因难以重现的疑难故障的挂起率,最终有助于业务的长期稳定。 4、建立集中的数据可视平台,不至于遇到问题才开始着手分析,若是对业务没有足够的了解又没有数据依赖,就很可能在解决问题时雪上加霜。 5、建立沙箱影子系统,模拟复杂多变的现网环境,规避线上影响,重现或压测问题,如tcpcopy、dubbocopy等。 6、搭建开源的日志可视方案,协助我们去解决最后”一公里”的问题,常见如ELK、Log.io等。 7、善其事必先利其器,常见系统排查工具perf、iptraf、netperf、tcpdump、gdb、pstack、jstack、strace,top、iotop、tsar等。

结语

运维专家或许是每个运维人追寻的梦想,他们敏锐的嗅觉似乎总能揪出系统故障的根本原因。这种快速反应、准确定位的能力源自多年来处理复杂系统难题的经验积累与个人知识储备,而且其成功很难被复制。虽然没有哪家机构愿意为其颁发认证资质,尽管如此,这仍然是大家所乐于追寻的一种“超自然”的本领。 最后,总结了下这几年处理问题的一些思路和经验,如下几行“打油诗”,送给大家,欢迎感兴趣的同事交流指正!

收集信息,随时记录 协调资源,把控影响 冷静判断,沉着分析 大胆假设,谨慎尝试 积极总结,以备后用

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏阮一峰的网络日志

Jacobsen v. Katzer:开源运动的一个重大胜利

今天早上起床,看到Lawrence Lessig(斯坦福大学法学院教授,CC许可证创始人)在Blog上宣布一个"huge and important news"...

903
来自专栏CSDN技术头条

Docker、CoreOS、Google等公司联合建立通用容器标准

基于Linux基金会的帮助,Docker、CoreOS、谷歌、微软、亚马逊目前正在致力于建立一种针对软件容器的新标准。这个联盟的其他成员包括Apcera、思科(...

1835
来自专栏祝威廉

这些年,我工作上走过的路

我走过了毕业季,创业征途,踏进开源之路,转型进入大数据,到最后有缘接触机器学习。每个章节,我都会提及对应那个阶段对技术的感悟,自己做的一些具体事情。

672
来自专栏SAP最佳业务实践

从SAP最佳业务实践看企业管理(16)-CRM-服务请求

CRM管理市场、销售、服务,市场和销售已经剥完了,下面来看看服务。 服务部门现在越来越重要,很多行业卖产品的利润越来越低,而售后服务却能创造更好的利润,服务收入...

3248
来自专栏云市场 精选汇

医院智能电话客服系统应用场景解决方案

那天的场景现在想想还心有余悸,午觉醒来,发现三岁的宝宝小脸通红,手背滚烫灼热,立刻取来体温计测量,高烧40度!心里瞬间悬挂千金巨石,虽然离医院很远,慌乱中还是迅...

1173
来自专栏灯塔大数据

干货|Bilibili (B站)200万用户数据爬取与分析

该爬虫仅供学习使用 B站用户爬虫 B站视频爬虫 B站弹幕下载器 文件介绍 bilibili_user.py:爬虫文件 bilibili_user_info.sq...

2665
来自专栏腾讯数据中心

腾讯数据中心基础设备质量检测之温湿度传感器篇

背景: 2015年伊始,腾讯数据中心出炉了企业内部适用的MDC南北向接口标准,并于同年3月以深圳某机房为试点整改北向接口完毕。然而类似“湿度0%”等匪夷所思的监...

2444
来自专栏CSDN技术头条

如何设计一款优秀的软件架构

“风语者客服+”是针对中小型企业推出的客服SaaS,节约了企业自建客服系统所需的巨大成本。为了给企业提供稳定可靠且优质的服务,我们在整体架构上费尽心思。虽然不尽...

1739
来自专栏腾讯数据中心

数据中心——大数据时代的基石

Hello,大家好,自从前几天小WI发了那篇介绍基于神经网络的数据中心控制的文章,好多朋友就小窗问小WI说你们到底是做什么的呀,怎么天天和神经打...

29012
来自专栏哲学驱动设计

框架模块设计经验总结

    三个月没写日志了,比较懒散……下半年准备做OEA 的 B/S 版本,比较复杂,需要从架构设计开始认真入手。正好今天到了部门反思的时间,今天先把原来的一些...

18110

扫码关注云+社区