面对疾风吧，如何搭建高协同的精准告警体系？

简介： 想要实现AiOps，智能告警少不了。Arms 告警运维中心让面向告警的组织协同更加便捷高效！

作者｜九辩

世上没有一个系统是百分之百尽善尽美的。如果想要保证可用性，那么技术团队就得对服务的各种状态了如指掌，能在第一时间发现问题且快速定位问题原因。但要想做到以上这两点，只能依赖完善的监控&告警体系去监控服务运行状态，但技术团队又不可能时时刻刻都盯着看板并关注到所有方面。因此，告警成为团队监控服务质量与可用性的最主要手段。

但在实践过程中，技术团队所获取的告警往往不是太少了，而是太多。我们看看某跨境电商系统 SRE 每天的工作日常，或许每个工程师对此都不陌生：

打开通讯工具 IM，运维群的告警消息提示 99+，甚至 999+；

点开群查看消息，满屏告警标题、等级和分派人，但信息过多无法快速筛选和确定高优先级告警；

挨个打开信息，查看告警内容并评估实际优先级，这其中包括但不限于服务超时、网络重传、数据库响应慢；

发现等级为“P1”的告警，检查内容来自交易系统服务超时，告警分派人是交易系统开发同学，开发同学检查发现交易系统当前没有异常，认为是数据库问题，返回群依次点击检查；

到了公司打开告警中心系统，按告警等级高低排序再点开列表条目，分别与业务开发、网络设备维护和数据库 DBA 开会沟通，综合分析发现“交易系统服务超时告警”是由于“网络重传”引起的“数据库响应慢”。

可以看到，随着企业数字化不断深入，IT 系统划分、异构性都使得企业技术架构变得愈发复杂。为了更好地保障系统稳定性，也为了避免遗漏故障，技术团队通常会在监控系统中，针对基础设施、平台、应用设置大量监控指标和告警规则，从网络到机器、从实例到模块、再到上层业务。虽然极大提高了故障发现能力，但也很容易导致一个异常或故障触发大量告警，造成告警风暴。比如，一个机器发生故障时，监控机器健康度的告警规则产生报警；监控机器上实例运行状态的告警规则也产生告警；这些实例的上游应用模块受到影响也开始告警。比如，应用模块中的实例发出告警，上游应用模块也产生告警。当应用模块中包含的实例比较多时，产生数百条告警消息。再有甚者，网络、机器、域名、应用模块、业务等同时产生多层次、多方面异常告警，产生数万条告警消息。

与此同时，在异常发生时传统告警体系通过邮件、短信、电话等方式向相关人员进行告警，但大量告警消息并不能帮助他们迅速寻找根因和制订止损方案，反而会淹没真正有效的信息。与此同时，问题处理往往需要协同不同团队并及时同步进展，单点发送不利于问题描述与处理跟进。大量重复描述情况与跨团队的责任人沟通，大大拖长了 MTTR。

很多中小型互联网公司都有相对完整的监控与告警系统，告警质量和应急效率相较于大型及超大型企业会高很多。这是由于监控系统都在一个运维团队开发与维护，业务结构、产品能力及使用方式相对简单且统一，监控系统的主要使用人为产品运维工程师，配置的监控及告警质量较高。但随着企业规模的不断增长，中小型企业也将与大型企业面临着相同问题：

监控系统越来越多，各监控系统的操作方式、产品能力无法拉通对齐；

大多数监控系统对于技术团队，功能设计体验差且学习成本高。技术团队不知道该配置哪些监控以及告警规则，导致未做到风险点 100% 覆盖，或者导致了大量无效告警；

不同监控系统对应责任人越来越多，当组织架构发生变化时，各监控系统订阅关系无法及时更新。

最后的状况就变成了报警量越来越大，无效报警越来越多，技术团队放弃监控告警，然后开始恶性循环。具体归因以上现象，我们发现问题主要集中在以下几点：

「标准化告警处理流体系」的缺失

告警源数据缺乏统一标准以及统一维度的标签

企业内各个域的运维系统独立建设，没有统一标准且大部分告警数据只包含标题、等级和基础内容。运维人员耗费大量时间逐条阅读告警、分析告警来源和最终原因。而这一过程中，又十分依赖 SRE 的过往经验。深究其背后原因，主要是由于来自各个域的告警数据，告警策略配置逻辑不一致，没有标签或者标签定义不统一，SRE 需要在繁杂的告警中识别有效信息，分析告警之间的关联性，找到根源。传统的IT运维系统为了标准化和丰富告警信息，会从企业层面定义统一的告警数据标准，每个域的告警系统需要按此接入。强制标准化的方法在实践中一定会遇到如下问题：1）不同运维域改造成本大，项目推动困难；2）数据扩展性差，一个数据标准改动牵动所有运维域。

缺乏全局视角的告警数据处理和富化

IT 系统运维将来自不同域的告警集成统一处理，初衷是掌握更多信息，从而进行更准确的判断。但如果只是被动接受并分派告警，告警运维系统作为运维信息中枢的价值并未体现，效率与体验也没有改善。对此，运维人员可以主动对这些告警内容进行一次“消化”、“吸收”和“丰富”，将充满噪音的信息变得清晰规整。那么，告警运维体系就需要可以对告警进行分解、提取和内容增强的工具。

组织协同处理告警难以落地

如何通过组织协同灵活处理告警？

在一个组织中，各个服务的稳定性往往落实在一个或多个组织的日常工作中。告警处理需要在团队内、团队之间进行协同。当告警触发时根据当前排班计划对主值班人员进行通知，一段时间未处理则通知备值班人员， 主备值班都未及时处理的情况下升级到管理员。当值班人员发现告警需要上下游其他团队处理时，或需要提高优先级处理时，需要能够修改告警等级，能够把告警快速转派给其他人员，并且被转派的人员能够获得该告警处理权限。

如何避免组织隔离的复杂性灵活处理告警？

正常场景下，技术团队不希望看到其他团队的告警的同时，也不希望该团队的告警被其他团队看到（涉及故障等敏感信息）。但当告警需要跨团队协同处理时，又需要能够快速将这个告警转派给其他人员且同时对其授权。怎么在云上完成这些灵活多变的权限管理需求？当前云上传统的授权方法是为每个成员在云上建立对应的子账号，对其进行授权。这种方式明显不适合告警处理，线上业务已经受损了难道还要找管理员授权才能处理告警吗？面对上述问题，不同规模的企业给出了不同的解决方案：

规模较小企业：把组织内的人配置为云平台上的告警联系人，告警触发后，根据内容通知其中部分人。

优点：当团队规模较小时，通过简单配置即可完成告警的分发处理。缺点：需要不断同步组织架构和告警联系人的关系，比如新人员入职，老员工离职时需要及时同步。

规模较大企业：把告警通过统一webhook 投递到内部告警平台中进行二次分发处理。

优点：自建系统可以和企业内部组织架构和权限系统打通，对于满足组织隔离的复杂性和告警分发的灵活性。缺点：自建告警平台，投入大，成本高。

针对上述两大问题，我们需要更加完整的思路去解决上述问题，经过大量实践，我们提供以下思路供大家参考：

「标准化告警事件处理流」

结合上述运维案例的痛点以及告警标准化面临的困难，我们不再强制推动各运维域在集成前进行适配。开发运维人员使用运维中心提供的“标准化告警事件处理流”功能，凭借以下手段去编排和维护不同场景下的处理流，对不同来源的告警进行标准化和内容增强。

借助告警平台灵活的编排组合能力以及丰富的处理动作，去快速处理多样化告警场景

从告警运维中心视角来看，不同来源或者场景的告警数据处理流程各不相同。通过所提供的数据处理、数据识别和逻辑控制等丰富的处理流动作，面对标准化或者场景化诉求，SRE 用条件过滤出当前关注的告警，选择动作编排处理流。经过测试启用后，告警数据会按照预期的标准存入告警系统进行分派通知；SRE 的告警运维经验，可以沉淀下来供后续自动化处理。

内容 CMDB 富化，打破信息孤岛

企业IT运维过程中，打破不同来源告警的“信息孤岛”是一件重要且富有挑战的任务，而企业的 CMDB 数据正是最好的原料。通过维护静态和 API 接口的方式集成 CMDB 数据，告警事件处理流可以通过 CMDB 对信息进行富化，使得来自不同域的告警产生维度上的关联。这样在告警处理过程中，IT 资源之间的告警可以建立联系，便于快速分析定位根因。

通过 AI 内容识别，快速了解告警分布

借助于 AI 内容识别能力，对告警内容进行分析归类。运维人员可以从全局统计中了解系统告警分布，具体开发运维人员能够一目了然识别出具体告警的对象类型和错误分类，缩短了从现象到根因之间到路径。并且在事后复盘过程中，智能归类信息可以作为 IT 系统优化和改进行动的决策参考数据。

「面向告警的组织协同」

在标准化之外，我们可以看到对于告警处理，组织协同需要足够非常灵活。不能再以“组织”为中心来处理告警，应以“告警”为中心构建组织。当告警发生时需要协调所需的上下游处理人来构建一个处理告警的临时组织，在临时组织中的成员具备告警处理权限，当告警解决后可以快速解散临时组织，避免被告警频繁打扰和非必要故障信息传播。

联系人自助注册到告警系统

对于敏捷化的运维团队而言，应避免手动维护需要处理告警的组织成员在告警系统中的联系方式。手动维护联系人的方式不适合于频繁变动的组织。优秀的告警系统应该由每个组织成员完成自己的联系方式维护和通知设置，这样既避免频繁的组织架构变动对管理员更新联系人信息的及时性要求，也能满足不同人对于通知方式选择的不同偏好。

复用已有账号体系，避免在工作中使用多个账号系统

通常的企业都会使用一个例如钉钉、飞书或者企业微信的办公类协同IM工具。应当避免在告警处理平台中使用独立的账号体系。如果一个企业平时使用钉钉等软件进行办公，然后告警系统有支持通过钉钉来处理告警，那么这个告警系统就很容易能够加入到企业的生产工具链中。反之，如果企业平时都是使用钉钉，但是告警系统需要使用单独的账号来登录，不仅需要维护两套账号，还容易造成沟通不畅，信息处理不及时等问题。

灵活的权限分配方式

告警权限分配方式应是以最快速解决这个告警为目的的，当一个告警产生后值班人员如果不能自己解决，应该第一时间协调所需团队与资源来解决该告警。同时当告警处理完成后又能够将临时协调的成员权限进行回收，确保业务安全，避免信息泄露。结合工作中常用的告警协调方式，拉群沟通无疑是最符合告警处理的一种方式。当告警发生时值班人员临时拉人进群查看并处理告警。此时群就成为了天然的授权载体，进群获得告警查看处理权限，退群后不再被告警打扰。

丰富的可扩展能力

团队协同过程中可能存在诸多协同工具同时运用，比如告警处理过程中，对于重要告警处理需要进行复盘，复盘后可能会指定一些工作内容来从根本上解决告警。这个过程中可能涉及到其他工具的运用，比如协作文档类工具，项目管理类工具。告警系统需要能够更方便的对接这些系统，更加全面融入到企业办公工具链条中。

结合上述思路，阿里云将之进行产品化，并与 ARMS 监控深度集成，为客户提供更为完善的告警与监控体系。

ARMS 告警运维中心核心优势

对接 10+ 的监控数据源

ARMS 本身已经提供应用监控、用户体验监控、Prometheus 等数据源，同时对云上常用的日志服务、云监控等一系列数据源无缝对接对接，用户一键即可完成大部分报警的接入。

强大的报警关联能力

基于 ARMS APM 能力，对常见告警问题进行快速关联，并自动输出响应的故障分析报告。

基于钉钉建设的 ChatOps 能力

不需要导入组织结构，无需云账号。在钉钉群即可完成告警事件的分派，认领等操作，大幅度提升运维效率。

基础与阿里故障管理经验，对告警数据提供深入分析，持续提高告警可用性。

核心场景

核心场景一：多监控系统集成

ARMS已集成云上大部分监控系统，开箱即用。同时支持用户自定义数据源。

核心场景二：告警压缩

ARMS 根据常见告警现象自带 20+ 规则，帮组用户快速压缩告警事件，同时支持客户自定义事件压缩。

核心场景三：多种通知渠道配置

支持在钉钉群中处理和分配告警。

核心场景四：告警数据分析大盘

核心场景五：开箱即用的智能降噪能力

自动识别低信息熵的告警。

原文链接
本文为阿里云原创内容，未经允许不得转载。