毛站,南阳住房和城乡建设厅网站,100种创意活动策划,上海太江建设网站稳定是偶然#xff0c;异常才是常态#xff0c;用来标注IT运维工作再适合不过。
因为对于IT运维来说#xff0c;工作最常遇到的就是不稳定性带来的各种故障#xff0c;经常围绕发现故障、响应故障、定位故障、恢复故障这四大步。
故障处理是最心跳的事情#xff0c;没有…稳定是偶然异常才是常态用来标注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%。 内容转自知乎有删减
