运维故障的排查与解决:正确的流程是什么?

发表时间: 2023-12-14 14:11

稳定是偶然,异常才是常态,用来标注IT运维工作再适合不过。

因为对于IT运维来说,工作最常遇到的就是不稳定性带来的各种故障,经常围绕发现故障、响应故障、定位故障、恢复故障这四大步。

故障处理是最心跳的事情,没有之一。

首先它的发生是随机的,完全未知,尤其是大型互联网系统,海量的用户,故障发生后精神高度紧张,要顶着巨大的压力,用最短的时间协同各方制定方案、恢复业务,尤其考验一个人的综合素质。

其次,处理期间要面临各种老板、质量部门和未知部门未知人员的盘问,各种客服报过来的用户投诉和催促(PS 平时真不知道有这么多人关心着我们),对外信息的同步升级、对内故障的处理都要兼顾,毫不夸张,就是一场必须用最快速度打赢的突击战,需要团队在平时就训练有素,居安思危,同时,它也是一个SRE向高段位修炼的最好道场,被故障搞的神经衰弱,真的很刺激,人们常说台上一分钟台下十年功,运维又何尝不是。

那么,如何处理好一个大型互联网系统的突发故障呢,有没有方法论?

一、丰富的业务储备

1、百发百中生死告警

告警是发现故障的最有效途径,其建设要围绕3个点准、少、快,准是告警的信息准,少是告警的数量少都是有效告警,快指的是告警的实效性高速度快。

作为大型互联网系统,服务和指标都是海量的,告警再怎么分级、收敛还是多,所以必须建立一个用户使用角度的生死告警,并且不断修正确保其准确,生死告警代表系统的生死,任何人在任何时候任何地点看到都需要立刻响应。

告警收到崩溃,时常手机烫到死机,告警的短信铃音连成直线,但很多时候其实是正常的,沉重的历史包袱要把存量告警梳理一遍成本太大,绞尽脑汁后,果断拉齐所有部门,建立唯一生死告警,后面新系统也做了同样的操作,搞好后大家面对告警都松了一口气,可以看下我们生死告警的群公告。

所以,业务一定要有P0级生死告警,判断到底是真故障还是假故障。

2、深度理解系统架构

SRE和系统运维的最大区别,我认为SRE得在系统运维的基础上研究业务,研究系统架构、产品架构,SRE面向的是用户稳定性。

大型互联网系统,模块多、依赖关系复杂,运行的资源环境复杂,如果不了解系统架构,在出现问题时基本就是抓瞎的,不知道服务的功能,不知道到故障后对用户的影响,不知道出了问题后查哪些指标,不知道服务依赖了哪些第三方资源,不知道服务间是怎么调度的,等等都会让SRE局限在系统外的狭窄空间,只能被动的接受安排,很难对产品稳定性提出建设性的意见。

所以要高效处理好故障,一定要和研发的架构师一起深入理解系统架构,而不仅仅停留在基础资源iass层。

3、各种预案了然于心

一定要在日常勤加练习,对各种原子预案可以“闭着眼”快速操作

4、完备的运维工具

从故障发现、故障诊断、故障恢复全过程都离不开工具的支持,一定要选对工具提效,能自动化全部自动化,人肉已经不能很好的处理大型互联网场景下的故障处理,效率太低。

LinkSLA智能运维管家,从故障发现到恢复做了全流程的设计,虽然目前还有很多要做的地方,但已经大大提升了我们在故障发现、分析、诊断、恢复、复盘的效率,上张图。

二、强劲的综合素质

1、临时应变能力

故障的突发性、不可预见性、每次处理的人都不一样,需要用智能运维工具快速定位、根因排查,快速应对故障,降低故障影响,提高运维工程师的综合素质,不仅仅在技术层面,也在心理和应变决策方面。

2、组织协调能力

大多数故障需要跨部门多人协同处理,SRE需要起到组织、协调引导故障快速解决的作用,所以组织协调能力不可或缺。

3、快速的决断力

不善决断对处理故障是个大伤,因为故障期间每分每秒都很珍贵,而且基本上充斥着各种决策,每个决策都需要权衡利弊不能犹豫,所以要独挡一面的处理复杂的故障,一定要锻炼快速的决断力。

4、迅速的执行力

快速决断后,就要快速的执行,执行过程一定不能拖延,快速操作做到闭环。

5、优秀的心理素质

用户量越大的系统、责任心越强的人,处理故障所需要的心理素质就越强大,否则根本就无法在那种高压的环境下从容的处理,期间还要面临故障延长带来的定级压力,所以要做大型互联网系统的SRE,真的要有一颗强大的心。

三、有章法的处理过程

具备了这些储备和素质后,算是有了和故障战斗的能力,但还不够,处理过程还需要遵循一些战术和章法,才能做到有条不紊,快速结束战斗、取得胜利。

收到告警后,首先快速判断影响范围,第一时间通知到对应管理员,如果影响严重立刻开启专家会议,以最快速度恢复,将故障影响降到最低。

大型互联网系统模块众多、依赖关系和运行环境复杂,研发和SRE要快速通过各种监控、指标的变化分析定位大概故障点,并将可疑的问题罗列出来,然后将其分发下去分别快速落实,此过程的价值观一定是先恢复业务再排查问题,但往往得排查到能足够支撑预案决策的原因,再由总指挥牵头制定恢复方案,再由SRE和研发去分工执行,验证结果是否符合预期,循环往复直至故障恢复,下面我们从两个角度看一下。

1、故障临时组织——分工协作篇

在这里就引出了一个最重要的点——因故障临时聚在一起的这些人如何快速建立组织、高效协作?谁该干什么该如何分工?一些大的故障会有几十个人、N多部门参与处理,如何保证处理过程有序而不乱?在经过无数次故障后,我认为一般要有5类角色:

总组织(流程专家, 发动机角色,组织大家快速分工到位,形成作战室,负责过程纠偏,一般是SRE)

总指挥(对恢复方案负责,带领技术专家们, 拿主意做决策,一般默认在场经验最丰富的架构师)

执行官(对各种执行负责,一般是由经验丰富的SRE和研发)

信息官(对故障恢复情况周期性通告, 内、外信息的上通下达,一般是SRE)

外部团队(按需参与,一般由执行官负责调度)

生产力决定生产关系,有了好的生产关系,生产力才能上去,所以上面的分工尤其重要,根据故障的大小这5类角色可以复用,但不可裁剪,总组织在里面尤其重要,

另外关于角色,也不一定很刻板的言明指定,协作多了后会有默契在里面,每一次分工其实都是对人的授权,不管言明与否,如果要高效快速,不妨按照这种分工试一下。

在一些复杂故障的处理过程中,会有源源不断的信息从执行官、信息官反馈到总指挥,总指挥协同他的专家组进行分析决策,再把新的执行指令分发下去,如果大家目标偏了,比如陷入到了问题中,总组织负责识别并纠偏,整个临时组织的执行力、反馈力都是极强的。

当你经历一次重大故障,全天8个小时一直在电话会中,不停的决策执行反馈、决策执行反馈,那个强度和压力是巨大的,但收获也是巨大的,毫不夸张的讲,一次重大故障,基本能把系统的架构摸得门儿清。

2、故障排查过程——循序渐进篇

故障排查也是要遵循章法的,整个过程会从轻到重进行分析操作,比如机房的某个实例告警,不会一开始就把所有流量全部切到另一个机房,也不会一开始就找大老板申请机动资源劳民伤财的紧急扩容,而是会尝试重启预案,如果恢复了做下复盘就好。

所以为了杀鸡不用牛刀,故障的排查和操作是循序渐进的从低成本到高成本的方向走的,期间最重要的是要提高每个操作的可预见性,并用最优雅、简洁、快速的方式恢复业务,怎么从根本上解决问题等到故障复盘时再定,总结一下常用的故障判断优先级,从低到高。

P0:是否大面积告警, 排查基础资源比如网络、公有云是否有问题,决策是否要执行流量切换预案;

P1:如果是单服务、单实例,常规情况尝试 重启预案;

P2:排查是否有时间吻合的变更,尝试 回滚预案,常规情况下回滚会在重启预案无效后再执行;

P3:排查是否有流量突增,或服务器压力增大,启动 扩容和限流预案;

P4:排查是否有功能无法恢复,并拖垮其他优质服务,启动 降级预案;

P5:综合预案、临时预案,具体情况具体制定,但基本是6把刀的组合拳。

制定恢复方案通常要遵循白名单原则,即优先保证不伤害优质服务,比如说C3机房的服务正常,C4已经大面积不可用,考虑要将流量切到C3,一定要保证C3机房的服务不受影响的前提下,再用C3去救C4机房,别本来75%的可用性,切后雪崩变成了0%。