amazon 用云服务器可以吗（每个公司都有on-call）

对于每个程序员来说，进入市值万亿的Amazon工作，似乎都是一件值得骄傲的事，但只要在网络上一提起Amazon，关于它的on call 机制的吐槽就会此起彼伏要知道在国内互联网公司，on call应该是非常普遍的现象，但为什么大家对Amazon的on call文化如此反感呢？，我来为大家科普一下关于amazon 用云服务器可以吗?以下内容希望对你有帮助!

amazon 用云服务器可以吗

对于每个程序员来说，进入市值万亿的Amazon工作，似乎都是一件值得骄傲的事，但只要在网络上一提起Amazon，关于它的on call 机制的吐槽就会此起彼伏！要知道在国内互联网公司，on call应该是非常普遍的现象，但为什么大家对Amazon的on call文化如此反感呢？

Amazon的on call真的不一般

别的公司on call 可能只有少部分部门参与，但是Amazon的范围很广，基本上90%的组都要on call，甚至可以说只要在Amazon做技术基本都有过on call的经历。

其次是时间长，基本是每隔x周就要接受一周的on call，x等于团队人数。而且每天需要24小时处于待命状态！也就是说7*24小时的on call！看到这里相信很多技术小哥哥的双腿已经开始颤抖了，别急，后面还有更厉害的！

亚马逊把故障分成几个等级，当遇到 sev-2 级别的问题，负责人要在收到告警短信15分钟内处理问题，否则就会收到经理的电话。

如果是白天告警，15分钟内处理其实难度不大，但Amazon是一个全球公司，业务分布在各个时区，所以夜里出现问题的几率就很大了！当夜里收到告警短信，负责人就要马上醒来处理问题，最坑的是业务方会不断询问进度，如果解决的不是很好，还是会通知经理！

高强度on call的情况下，大家会有很大压力，要是几次没处理好估计就要做好跑路的准备了，这种情况下被吐槽是难免的！

如何建设好的on call机制？

Amazon的on call机制是其“客户至上“文化的有力实践，但其对内部员工来说强度过高。事实上，太多公司的on call机制让团队成员感到焦虑痛苦了。那么从运维的角度来看，该如何建立一个好的on call 机制呢？我们总结了以下四点：

一、建立on call机制的时间要越早越好

一般来说on call是在监控之后的环节，但其实在做监控之前我们就应该做好on call机制，因为故障问题的反馈渠道不只有监控系统，还有用户反馈、团队成员告知等。

在企业初创期，网站出现故障，第一个知道的往往是用户。监控只是给我们一种从数据发现问题的视角，并不能保障准确，而用户则是故障的直接体验者。

而且，监控可以不断优化，故障则随时会发生，优先恢复业务是最高优先级。好的on call机制既能保障业务，还能把数据反馈给监控，进一步优化监控体系。

二、建设故障处理sop

谷歌SRE应急时间处理策略的一条是：由万能工程师解决生产问题，向手持《运维手册》的经过演练的on-call工程师演进，其核心思路是建设故障处理SOP，保证SRE可以处理大多数故障。

运维手册就是故障处理sop，由经验丰富的运维工程师总结撰写各种故障的处理方式，可以让on call成员通过看sop，快速了解问题，保障能有效处理大部分故障。

三、建立职责清晰、多层次的支撑团队

发生故障时如果是一个混乱无序的团队去处理，沟通成本就非常高了，效率肯定也会大打折扣。对于互联网公司来说，故障处理的时间是至关重要的，而要想迅速有效的处理故障，就要搭建一个职责清晰、多层次的支撑团队。

根据团队和项目的情况，可以建立一线、二线、三线支撑团队：

一线通常是7*24小时的值班运维同学，可以根据团队成员进行排班，降低成员压力。

二线通常是资深工程师，或者是对应的应用开发／测试同学。在故障处理的时候经常被忽视的一点是，通常第一时间响应的是运维，业务开发关键人无法响应，但业务开发其实是对相关业务最了解的人。

三线一般是主管或者是外部的厂家，如涉及硬件、IDC机房等相关服务方。故障问题很多时候都和硬件或者服务器、系统有关，而外部厂商是最了解产品的人，与他们合作可以解决不少的问题。

有了多层次的支撑团队，我们还要有相应的升级策略。出现故障时，不是这三线团队都一起处理，也不是所有问题都是一线团队处理，这两种极端思路都不可取。合理的思路是让资源利用最大化，核心是给运维授权，当一线运维发现无法解决问题时，可以升级问题给二线、三线团队，甚至公司cto。

四、合理使用运维工具

on call离不开监控和告警，再好的流程机制无法有效执行也是空谈，而好的工具可以有效的把机制落地，让on call有迹可循，国外的有pagerduty、国内的睿象云智能告警平台都做的不错。这些工具解决了on call 机制的几个问题：

1、不管是大公司还是小公司，都可能会使用多个监控工具。故障出现时可能会发出大量的告警短信，而这些告警没有去重就会产生告警风暴，还难以进行精准的分派到匹配的人员手中，无法在大量的告警中快速的定位问题，又会加大告警处理的难度，形成一个恶性循环。

一个比较好的方法就是告警汇集，比如把Zabbix、Nagios、Promethues等多种工具告警源接入汇集到一个平台，然后可以对这些告警分析去重，分析告警相关性，帮助故障处理，还可以集中处理监控。

2、支撑团队的团队排班和升级策略环节，如果用excel或者就是群里通知效果很差，用工具可以很好实现。类似日程安排的排班管理功能，可以快速落地告警响应机制，精准分派相关人员。灵活的通知规则，可以保障告警触达，比如先邮件通知，若5分钟没响应就短信通知，若10分钟还是没响应就电话通知，可以保障重要告警不再遗漏！

3、告警方式除了电话、短信和邮件，国内使用微信、钉钉更多一点，而监控工具自带的告警对国产im软件的支持有限。国内的平台支持渠道更丰富，包括微信、钉钉、平台原生 App 端等都支持。

4、然后是告警的去重降噪，一成不变的人工设定的告警规则无法适应一直在变的业务。要想做好好告警的去重降噪，比较好的就是结合运维大数据和人工智能，实现人工智能分析把相同事件自动去重，还可以自定义压缩规则，按规则合并或压缩相似告警信息。

总之流程机制是软的，要靠人去推动执行有诸多不便，而把机制落地到软件，执行推动效果更好，机器还省去了很多重复工作，更简单高效。如果我们做好了以上几点，相信运维团队会有一个不错的进步，能更好地做好故障处理。

我是睿象云智能告警平台，专注人工智能提升运维效率！码字不易，欢迎大家关注点赞收藏转发～

,