从被吐槽的Amazon看,如何建设好的on call机制?

对于每个程序员来说,进入市值万亿的Amazon工作,似乎都是一件值得骄傲的事,但只要在网络上一提起Amazon,关于它的on call 机制的吐槽就会此起彼伏!要知道在互联网公司,on call应该是非常普遍的现象。但大家为什么对Amazon的on call文化如此反感呢?
Amazon的on call真的不一般
首先是范围广,基本上90%的组都要on call,甚至可以说只要在Amazon做技术基本都有过on call的经历。
其次是时间长,基本是每隔x周就要接受一周的on call,x等于团队人数。而且每天需要24小时处于待命状态!也就是说724小时的on call!看到这里相信很多技术小哥哥的双腿已经开始颤抖了,别急,后面还有更厉害的!
故障会分几个等级,当遇到 sev-2 级别的问题,就要在收到告警短信15分钟内处理问题了,否则就会收到经理的电话。
而Amazon是一个全球公司,业务分布在各个时区,夜里出现问题的几率就太大了!所以当夜里收到告警短信,你就要有马上醒来处理问题的能力,而且业务方会不断询问进度,如果解决的不是很好,也会安排你的经理了!
高强度on call的情况下,大家会有很大压力,而要是几次没处理好on call就要做好跑路的准备了,这种情况下被吐槽是难免的!
如何建设好的on call机制?
Amazon的on call机制是其“客户之上“文化的有力实践,但其对内部员工来说强度过高!事实上,太多公司的on call机制让团队成员感到焦虑痛苦了。那么从运维的角度来看,该如何建立一个好的on call 机制呢?我们总结了以下四点:
1、建立on call机制的时间要越早越好
一般来说on call是在监控之后的环节,但其实在做监控之前我们就应该做好on call机制,因为故障问题的反馈渠道不只有监控系统,还有用户反馈、团队成员告知等。
在企业初创期,网站出现故障,第一个知道的往往是用户。监控只是给我们一种从数据发现问题的视角,并不能保障准确,而用户则是故障的直接体验者。
而且,监控可以不断优化,故障则随时会发生,优先恢复业务是最高优先级。好的on call机制既能保障业务,还能把数据反馈给监控,进一步优化监控体系。
2、建设故障处理sop
谷歌SRE应急时间处理策略的一条是:由万能工程师解决生产问题,向手持《运维手册》的经过演练的on-call工程师演进,其核心思路是建设故障处理SOP,保证SRE可以处理大多数故障。
运维手册就是故障处理sop,由经验丰富的运维工程师总结撰写各种故障的处理方式,可以让on call成员通过看sop,快速了解问题,保障能有效处理大部分故障。
3、建立职责清晰、多层次的支撑团队
发生故障时如果是一个混乱无序的团队去处理,沟通成本就非常高了,效率肯定也会大打折扣。对于互联网公司来说,故障处理的时间是至关重要的,而要想迅速有效的处理故障,就要搭建一个职责清晰、多层次的支撑团队。
根据团队和项目的情况,可以建立一线、二线、三线支撑团队:
一线通常是7
24小时的值班运维同学,可以根据团队成员进行排班,降低成员压力。
二线通常是资深工程师,或者是对应的应用开发/测试同学。在故障处理的时候经常被忽视的一点是,通常第一时间响应的是运维,业务开发关键人无法响应,但业务开发其实是对相关业务最了解的人。
三线一般是主管或者是外部的厂家,如涉及硬件、IDC机房等相关服务方。故障问题很多时候都和硬件或者服务器、系统有关,而外部厂商是最了解产品的人,与他们合作可以解决不少的问题。
有了多层次的支撑团队,我们还要有相应的升级策略。出现故障时,不是这三线团队都一起处理,也不是所有问题都是一线团队处理,这两种极端思路都不可取。合理的思路是让资源利用最大化,核心是给运维授权,当一线运维发现无法解决问题时,可以升级问题给二线、三线团队,甚至公司cto。
4、合理使用运维工具
on call离不开监控和告警,再好的流程机制无法有效执行也是空谈,而好的工具可以有效的把机制落地,让on call有迹可循。国外pagerduty做的比较好,国内的话推荐睿象云智能告警平台,相比pagerduty来说,用户体验更好,服务更好,价格也更便宜!
on call机制的一个问题监控告警的分散,不管是大公司还是小公司,都可能会使用多个监控工具,比如zabbix、nagios和promethues等。故障出现时可能会发出大量的告警短信,而这些告警没有去重就会产生告警风暴,告警风暴除了数量巨多,还难以进行精准的分派到匹配的人员手中,无法在大量的告警中快速的定位问题,又会加大告警处理的难度,形成一个恶性循环。
一个比较好的方法就是告警汇集,把多个告警源接入汇集到一个平台,然后可以对这些告警分析去重,分析告警相关性,帮助故障处理,还可以集中处理监控。比如睿象云智能告警系统,可以方便地监控告警集中,可以实现包括Zabbix、Nagios、Promethues等100+ 种工具告警接入汇集。
除了监控汇集,支撑团队的团队排班和升级策略环节也可以用工具很好实现。比如睿象云有灵活的排班管理功能,可以快速落地告警响应机制,精准分派相关人员。还可以制定灵活的通知规则,保障告警必达,比如先邮件通知,若5分钟没响应就短信通知,若10分钟还是没响应就电话通知,让重要告警不再遗漏!
告警方式除了电话、短信和邮件,国内使用微信、钉钉更多一点,而监控工具自带的告警对国产im软件的支持有限。国内的平台支持渠道更丰富,像睿象云支持微信、钉钉、平台原生 App 端等。
然后是告警的去重降噪,一成不变的人工设定的告警规则无法适应一直在变的业务,有统计显示只有不到40%的告警能够通过规则进行压缩。而要想做好好告警的去重降噪,比较好的就是结合运维大数据和人工智能,实现人工智能分析把相同事件自动去重,还可以自定义压缩规则,按规则合并或压缩相似告警信息。
而故障处理后,一般都会写一下告警分析,对于某些运维来说,做图分析是一个麻烦的事情。我们可以一键生成告警分析报告,自动生成基于时间、级别、内容、主机、对象的多维度分析告警,下钻历史告警详单,定位故障细节。
总之流程机制是软的,要靠人去推动执行有诸多不便,而把机制落地到软件,执行推动效果更好,机器还省去了很多重复工作,更简单高效,可以说是一个很好的解决方案!
最后,如果我们做好了以上几点,相信运维团队会有一个不错的进步,能更好地做好故障处理。
我是睿象云智能运维平台,专注人工智能提升运维效率!如果你在on call 方面有自己的见解,欢迎在评论区留言,也欢迎把这篇文章分享给身边的朋友!

上一篇:Microsoft Client Development MVP 2013 - 2014


下一篇:​​​​​​​​CloudMounter:挂载云存储作为在 Mac 的本地磁盘