对于On-cal这一词，国内并没有特别明确的说法，因为这是个欧美流传过来的叫法。国内与之相接近的意思大致就是值班，再详细一些的说法便是指企业为了快速相应生产故障或者重大事件，在某段时间内指定某个人或者某组人随时待命（类似值班）。在故障发生的一瞬间，会以邮件、短信、电话等形式通知到负责人，以保障第一时间的处理。
正所谓，没有零bug的程序，没有零问题的系统，因此互联网技术的发展也是时刻离不开运维的支撑，与此同时，On-call机制的理念也逐渐流行开来，但依旧会存在没能有序的处理：
- 海量的事件淹没了重要事件，没有及时的跟进处理，对后续业务产生了严重的影响；
- 突发事件过多，团队成员疲于应对，整体士气低下，处理效率低。
如何快速精准的定位到主告警，做好紧急处理工作，维持业务的稳定运营，成为了运维人员（尤其是运维主管）的关键。我们接触过各行各业的公司的运维工作，从初创、中小再到大型公司，总结了一套大多公司通用的On-call机制，这边分享出来，帮助大家有序的处理紧急事件： - 监控告警时间集中化；
- 建立多层次的，分工明确的支撑团队；
- 多渠道通知，及时响应；
- 告警风暴的规避处理；
- 根因定位和团队记录。
以上五点基本围绕着人、流程、工具三方面进行，参考了ITIL的管理思路，大家感兴趣的也可以参考一下，特别是其中的ITIL V3的运营管理。
监控告警集中化
zabbix、prometheus等是大多公司都会使用的监控工具。但是同一家公司在硬件、网络等不同的应用层面上应用的监控工具不一定会是同一种，这就存在监控分散的问题。这些监控工具之间的信息并没有关联性，这就导致一旦发生了故障，运维人员就需要多平台的跳转，不仅延长了告警处理的时长，影响业务的正常开展，更是为找到告警根因增加了难度。这个时候，我们就需要一个告警集中化：将所有的生产监控发现的告警事件集中到一起，这样我们盯着一个平台就够了，不仅快速省时，更能帮助分析告警根因，从根源上解决问题。
建立支撑流程和机制
上面我们说到告警的集中化，但是如果使用的监控工具单一，那么集中化就不是最必要的，如何有序处理才是核心问题。尤其是运维团队人数多达数百人的，就很有必要梳理下支撑流程和响应机制了。
- 建立一线、二线甚至三线支撑团队，一线一般为7*24小时值班的人员；
- 二线一般是资深工程师，或者是对应的应用开发/测试同学；
- 三线一般是主管或者是外部的厂家，如涉及硬件、IDC机房等相关服务方。
如果管理更加细致一些，还可以对业务进行拆分，形成一个矩阵，例如一线二线的伙伴根据不同的专业，去负责不同层面的业务；或者根据告警的级别不同，去进行差异化处理：
-
严重级别，如大范围影响业务和终端用户的，需要及时处理，一般要求多长时间响应处理，若在一定时间内无人响应，要立刻升级到谁手中处理；
-
警告级别：影响范围和严重程度低一些的故障，可以设置给团队里的初级运维工程师进行处理。
有了一个良好的规划和设计，那么如何将其顺利的实施呢？这又是一个十分重要的问题。目前市面上一众的监控工具提供的支持多数是在处理问题上面，但是在管理这一方面，市面上给予支持的工具是较少的：
1.人肉方式：针对一个监控器进行7*24小时的值班，人为通知与处理。超大规模的公司与金融、运营商会采用这种方式；
2.技术实现：通过智能降噪、分派策略和排班等：
- 通过智能降噪，将监控工具发送过来的所有事件根据设定的压缩条件进行压缩降噪，例如将标题相同的压缩成同一条，减少告警处理量的同时也减少了通知，减轻人员负担；
- 在分派策略里面设置不同的分派条件（根据级别，内容等）去选定告警分派的人员，以及在设定时间内，告警未被认领，就启动分派升级机制。
- 7*24小时的值班制度不论对于人力还是物力都是一笔巨大的支出，因此我们可以通过系统制订排班，实现日、周、月的轮流机制。
多渠道通知和及时响应
当所有的告警都经过了一系列的处理后，我们便需要决定以怎样的方式通知到相应的负责人去进行处理了。这里就涉及到了多渠道通知的方式：
- 电话通知：遇上十分紧急处理的故障，电话通知的方式无疑是最为直接的。尤其是在非工作时间发生的重大故障；
- 短信通知：在短信中可以自行定义通知到的内容包括哪些；
- 邮件通知：在工作时间内不失为一种有效的方式，但是在工作时间之外相对而言就比较容易错过消息；
- 微信端、APP端通知：顺应时代潮流，与主流的沟通交流软件绑定，确保消息接收的及时性和APP端简易处理的便利性；
- 钉钉，企业微信，飞书等协作工具，帮助人员间的良好协作，共同解决故障。
有了这些流程的设置，就能很好的解决这一系列的问题了。但是当告警的规模扩大，产生告警风暴的话，频繁的通知会给处理人员带来极大的困扰，因此接下来就来聊一下告警风暴规避的问题。
告警风暴的规避处理
关于这个问题，有的监控工具是做了一部分的，但是就目前来看，也是一个业界难题，简要来说：
- 静态规则方式，需要知识经验积累，根据业务逻辑梳理出一些父子关系。简单如，出现服务器Down的告警，肯定该机器上的业务应用也会Down，那么就整理为一条规则。需要一套告警的过滤引擎，根据告警字段信息进行匹配。
- 关联关系分析，依赖CMDB，服务关联关系，根据调用依赖关系进行告警的根源追溯。CMDB的建设和维护是非常困难的事情，数据准确性和实时性是决定CMDB效果的根本因素。CMDB国内落地效果理想的很少，只能依赖自动化，微服务、docker、devops大量应用让IT环境更动态、更复杂，没有自动化机制保障是非常困难的。
- 机器学习方式，相比前两种方式，机器学习更取巧一些，或者是说应该是未来的方向，节省大量人力物力。
现在我们做的一些成果分享一下： - 在与应用进行集成的时候，可以通过设置去重化，将获取到的告警信息eventID相同的进行合并压缩到第一条中去，一来避免了大量的通知，二来也减小了告警风暴的可能性；
- 针对监控工具对接过来的原始事件量配置风暴预警，若在设定的时间内接收到的告警数量超过设定的阈值，那么就会触发通知机制；
- 前面说到，在告警传入的时候，在分派到人员手中的时候，会先对告警进行一个智能降噪的操作来减少不必要的通知。同时在这里也会有一个针对已经压缩过的告警量的风暴预警，和之前的动作前后配合，避免告警风暴对业务造成重大的影响。
根因定位和团队记录
如果每天产生的告警量很大，告警后续处理和跟踪往往会依赖于外部团队（部门外或公司外）。但是监控告警粒度太细了，可能很多告警都是一个事情。如上面的告警风暴中，由于应用程序故障，引发了大量的异常，之后又产生连锁反应，其实就是一个事情，只需要处理一个事情就行。这个时候为了能更好的定位到告警根因，就可以通过以往的告警产生逻辑生成的根因拓扑图来快速锁定根本原因。
每解决一个告警，负责人都可以填写上告警解决的具体方案，所有的告警方案聚集到一起，就会形成一个知识库，这就有利于后续发生相类似的告警时，团队中的其他成员能够依据此前的方案去更加快速的解决这一类的告警。
小结
On-call机制建立后，通过告警和事件数据分析，建立起以数据指标驱动的团队文化，有机会和大家分享。
