对于每个程序员来说，进入市值万亿的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、建立职责清晰、多层次的支撑团队
发生故障时如果是一个混乱无序的团队去处理，沟通成本就非常高了，效率肯定也会大打折扣。对于互联网公司来说，故障处理的时间是至关重要的，而要想迅速有效的处理故障，就要搭建一个职责清晰、多层次的支撑团队。
根据团队和项目的情况，可以建立一线、二线、三线支撑团队：
一线通常是724小时的值班运维同学，可以根据团队成员进行排班，降低成员压力。
二线通常是资深工程师，或者是对应的应用开发／测试同学。在故障处理的时候经常被忽视的一点是，通常第一时间响应的是运维，业务开发关键人无法响应，但业务开发其实是对相关业务最了解的人。
三线一般是主管或者是外部的厂家，如涉及硬件、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 方面有自己的见解，欢迎在评论区留言，也欢迎把这篇文章分享给身边的朋友！