**IT告警管理的现状
**

IT系统良好稳定的运行，离不开系统监控报警。监控为整个IT系统提供了更好的可用性，如果能配置正确警报策略，可以使得IT团队更快地响应事件，消灭潜在故障。以上理念在IT系统的相互独立的时代是百分百正确的。但是，随着企业规模的增长IT环境也随之扩张，您如果有办法应对即将到来的告警风暴——否则您很快就会被各种告警信息所淹没，以至于无法正常工作。

更加不幸的是，随着时间的推移，未来会有越来越多的系统可以产生告警，而且它们的速度会更快，数量也会更多。目前大多数IT团队的告警都是自动生成的，然而告警处理却是人工的。更要命的是，他们所处理的告警都是孤立的很少进行过关联或归并处理。

目前在收到大量警报的IT机构（告警数量1000次／日以上）中，只有17％能够在24小时内完成故障排查和修复。大量分散的且不相关的告警，让企业别无选择只能增派工程师来解决。即使是增派了人员来处理，但是仍然有告警会被忽视，造成响应不及时，业务停机时间持续增长。因此告警风暴会为企业带来个多方面的损失。

IT告警风暴是如何产生的？

在讨论告警风暴所带来的支出增长之前，让我们先仔细分析下导致告警风暴的原因：

首先，当今的IT系统环境比以前更加复杂

IT部门只需要监控少数几台服务器的日子已经一去不复返了，现在IT团队必须处理更加复杂的虚拟机、多云、容器等等IT环境。因此监控的IT系统的规模以及产生的告警的数量也要比五年前大一个数量级。

与此同时，应用程序的结构也越来越分散

应用程序分解为各种“微服务”组件的做法已经成为主流。当然微服务也有很多优点，它们使代码更加模块化和动态化，也避免了IT系统的单点故障，但是在告警方面，采用微服务架构加剧了告警噪音问题，因为一套IT系统现在有数十甚至数百个组件，它们的健康状态同时也必须得到持续监控。

再次，“立体化”监控成为标配

IT基础架构和软件架构在过去十年中发生了巨大变化，因此20世纪遗留的基础监控工具已无法满足现代IT环境的需求，于是各公司开始采用一种新的监控体系：使用各种不同专业工具针对IT栈中不同层面进行“立体化”监控。在“立体化”监控工具体系中，至少会使用六个以上的监控工具，例如：系统监控、应用监控、跟踪误差 、日志分析、APM、异常检测、业务性能监控、云监控、自动化部署监控、协作工具、工单系统等。然而所有这些不同的工具都会导致更多数量的告警产生；同时它们输出的大量混乱不一的告警，也使得发现相互之间的关联关系变得更加困难，从而无法发现严重的问题，至于查找故障的根本原因更是妄想。

此外，随着组织转向持续集成/持续交付，开发周期比以往任何时候都更加敏捷。

虽然基础设施和代码的变化还是在预定的窗口系统中进行，但是已经由过去的月度，季度甚至每半年度变化一次，演变为现在每天都在不断的进行版本迭代。当版本更新顺利时，可以进行更快的新功能上线、提高更好的客户满意度。但是，基础架构和代码中变化的速度越快，变更就越多，告警的数量也越多。

以上因素加起来就不可避免的产生了告警风暴，为企业造成了大量隐 形 的 生 产 成 本

1.停机成本

因为维护人员的扩充永远赶不IT系统所产生的数据和报警的指数级增长速度，所以如果不改变人工运维的方式，将使得IT部门陷入瘫痪。

事实上，维护人员无法跟随数据和告警的指数级增长而随时扩充，当他们用传统的手工方式去解决告警风暴的时候，关键的告警可能会掩盖在海量数据之下。因此，当找到这些关键问题之前，IT故障造成的业务中断将会一直存在。所以，告警风暴带来的第一个隐形成本就是业务中断时间。

根据IDC估算，一般的基础环境故障每小时的成本约为10万美元，而关键的应用程序的故障每小时损失高达50万到100万美元。 实际上停电造成的故障中有1/3的都持续1至12个小时，17%的基础设施故障以及13%的应用程序故障会持续了一整天。每年IT中断的成本是1000万到25亿美元之间。

以星巴克为例。由于“例行系统更新的故障”，这家咖啡巨头在美国和加拿大的销售网点都遭遇了大规模的业务中断，无法进行收银结算。这家零售商被迫免费赠送了数千杯咖啡，从而造成了300万美元的损失。300万美元不是因为安全漏洞，而是因为一个错误，一个常规的程序更新带来的故障。

2.事故解决成本

当组织发现自己被淹没在告警中时，通常的反应是投入更多的人来解决问题，也就是更多的工程师和更多的工作时间。这种方法虽然简单，但成本高昂而且效率低下。近年来，机器数据和告警的数量以指数级速度增长，对于告警的检测、处理、分析和纠正的需求已经远远超过了IT团队的能力了。尽管许多企业已经将其NOC和IT团队的规模扩大了一倍，但他们仍然无法跟上不断增长的设备所生成事件和警报。虽然钱花了，但问题仍然存在——这意味着把钱打了水漂。

3.客户满意度

DevOps和CI/CD(持续集成/持续交付)的目标是减少IT中的摩擦。这样做可以使产品更快地进入市场，并在不断创新改进的过程中提高客户满意度。但是告警风暴的问题已经成为IT工作流中新的瓶颈。一方面CI/CD允许开发周期更快迭代，同时云自动化使得基础设施扩展的速度更快，但是告警管理仍然是手动的。这样造成的结果就是：服务的质量下降也变的更频繁(系统迭代更加频繁，同时停机更加频繁)，而且问题也经常很长时间才被发现，甚至是被客户投诉后才发现。这种故障会带来切实的财务后果，也会损害客户满意度和品牌声誉。当客户如果不信任您服务的可用性和可靠性时，他们必将转向竞争者。

告警治理行动

显然，处理机器生成的数据的问题不应该用人工的方案来解决，人类根本无法处理持续增长的海量告警。公司应该将精力集中在利用机器处理上，以提高他们将信号与噪音分离的能力。好的方法是通过应用一个自动化的解决方案来识别不同的监控系统之间的相关告警。告警关联是一种将高度相关的警报分组到高级别事件的方法，这些事件被按照各种各样的参数合并，包括：

拓扑

主机、主机组、服务、应用程序、云或其他发出警报的基础设施元素，当来自基础设施的相同区域时，告警更有可能是存在关联关系的。

时间

关联警报发生的时间窗口，在同一时间段内发生的警报更有相关性，而不是时间间隔很远的告警。

上下文

告警指标的类型。一些告警指标类型会暗示了它们和其他告警之间存在关系，当然也有部分告警类型是独立的，与其他告警无关。

优锘智能事件管理平台（Tarsier-EIM）的告警关联的技术可以帮助客户避免受到海量告警的影响，可以科学的自动完成警报关联。这有助于IT团队更快地发现和解决关键事件，并减少人力资源的占用。

优秀实践案例

在国内某股份制银行，通过优锘智能事件管理平台（Tarsier-EIM）的告警的关联能力对告警进行压缩，压缩率超过97%。

因此，运维工程师们不再盯着7套监控工具的57000个日常提醒，而是集中处理240个高度关联的事件。告警关联功能已经将最初孤立混乱的警报，变成了运维工程师可以轻松处理的故障队列。在使用优锘智能事件管理平台（Tarsier-EIM）的前三个月，客户的故障处理的平均时间(MTTR)减少53%。与此同时，运维团队发现，在不到一半的时间内，他们能够解决两倍多的突发事件，同时员工数量和资源并没有变化。随着IT规模不断扩大，虽然产生了更多的告警，但他们的故障处理能力反而提高了。