标签：运维 处理 故障 Amazon 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、建立职责清晰、多层次的支撑团队
发生故障时如果是一个混乱无序的团队去处理，沟通成本就非常高了，效率肯定也会大打折扣。对于互联网公司来说，故障处理的时间是至关重要的，而要想迅速有效的处理故障，就要搭建一个职责清晰、多层次的支撑团队。
根据团队和项目的情况，可以建立一线、二线、三线支撑团队：
一线通常是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 方面有自己的见解，欢迎在评论区留言，也欢迎把这篇文章分享给身边的朋友！
标签：运维,处理,故障,Amazon,call,告警,团队,机制 来源： https://blog.csdn.net/weixin_45385576/article/details/120137341
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。