On-call机制——一种有效运维的方法

对于On-cal这一词，国内并没有特别明确的说法，因为这是个欧美流传过来的叫法。国内与之相接近的意思大致就是值班，再详细一些的说法便是指企业为了快速相应生产故障或者重大事件，在某段时间内指定某个人或者某组人随时待命（类似值班）。在故障发生的一瞬间，会以邮件、短信、电话等形式通知到负责人，以保障第一时间的处理。

正所谓，没有零bug的程序，没有零问题的系统，因此互联网技术的发展也是时刻离不开运维的支撑，与此同时，On-call机制的理念也逐渐流行开来，但依旧会存在没能有序的处理：

• 海量的事件淹没了重要事件，没有及时的跟进处理，对后续业务产生了严重的影响；
• 突发事件过多，团队成员疲于应对，整体士气低下，处理效率低。
  如何快速精准的定位到主告警，做好紧急处理工作，维持业务的稳定运营，成为了运维人员（尤其是运维主管）的关键。我们接触过各行各业的公司的运维工作，从初创、中小再到大型公司，总结了一套大多公司通用的On-call机制，这边分享出来，帮助大家有序的处理紧急事件：
• 监控告警时间集中化；
• 建立多层次的，分工明确的支撑团队；
• 多渠道通知，及时响应；
• 告警风暴的规避处理；
• 根因定位和团队记录。
  以上五点基本围绕着人、流程、工具三方面进行，参考了ITIL的管理思路，大家感兴趣的也可以参考一下，特别是其中的ITIL V3的运营管理。

监控告警集中化

zabbix、prometheus等是大多公司都会使用的监控工具。但是同一家公司在硬件、网络等不同的应用层面上应用的监控工具不一定会是同一种，这就存在监控分散的问题。这些监控工具之间的信息并没有关联性，这就导致一旦发生了故障，运维人员就需要多平台的跳转，不仅延长了告警处理的时长，影响业务的正常开展，更是为找到告警根因增加了难度。这个时候，我们就需要一个告警