中证协下发了《证券公司网络和信息安全三年提升计划》（详见 https://www.doc88.com/p-40959715591002.html ） ， 征求意见稿，提出33项重点工作 ，与运维直接相关的有7项工作。这7 项工作要求与我对行业运维重点工作十分吻合，应该是身处一线运维工作专家编写而成，值得细细品读。本篇是第3项重要点提升工作：“ 持续提升信息系统故障发现能力”。

一. 故障发现概述

故障发现是故障应急的第一个步骤，其手段通常包括： 监控、风险识别、例行巡检、协同反馈 。其中前三项是运维主动发现故障，第四项属于被动发现，从故障发现的比率看，我们期望“监控>风险识别/例行巡检>协同反馈”。通常来说，监控发现“点”的问题，并需要立即处置；风险识别与巡检通常涉及多个“点”问题的集合，需要人干预评估，处理的紧急程度不如监控。我们需要通过建立了一系列运维复盘机制去持续推动监控、风险识别、巡检工作，增强主动故障发现的能力。

1. 监控

监控发现是当前最重要、发现率最高的故障发现手段。可以认为监控就是一系列机器人驻扎在硬件、软件对象中，不间断的采集运行指标数据，分析指标的异常状态，并将异常信息触达相关人员。

1）被动监控
“被动”监控是为了区别主动监控，指代传统在基础设施、硬件资源、平台软件、应用可用性、客户体验多个层级的监控管理，以及统一的监控告警管理。通常基于生产故障或IT风险的事件驱动，针对已知事件打补式的监控完善，采集指标数据，配置监控策略，以及触发策略后将监控告警统一推送到统一告警系统。

从工程角度看，源端监控端强调“不漏报、少误报”，需关注平台能力建设与平台运营两点：监控平台方面采用乐高式组合提升能力提升监控覆盖面，比如缺性能监控则补充APM、NPM，缺终端监控则补充终端拨测工具，引了新的技术组件则配套加入相关组件的监控能力；工具运营方面采用数据与机制运营协同推动，监控策略需要运维人员在工作过程中，结合信息系统的实际特点，在平台通用监控策略上持续的丰富针对性策略，运维组织需要建立事件或任务触发机制，比如事件复盘对监控发现能力的分析，并通过主动的监控评审、监控告警数据分析等运营工作发现哪些系统监控的覆盖面与误报情况。

2）观察者视角
传统被动性的监控管理是针对已知异常，进行补丁式的增强监控的方式持续完善的过程。但面临几个困难，一是很多已知故障监控策略加入后就再也没有真正发挥作用，但随着架构复杂性越来越高，未知故障并未减少；二是数据量与风险触发因素增强后，单维指标监控能力不足，而多维指标让人配置又面临无法穷举的问题；三是运维对于故障发现已经在可用性故障基础上，增加了功能逻辑、数据类故障的发现要求，对于日志、链路的监控发现能力要求越来越高。

观察者视角是运维组织需要借助算法、海量数据、平台能力，构建一个全数字化监控感知的能力。这种感知能力需要尽量减少运维打补丁式的增加细化的指标策略，利用算法能力加深感知监控深度，利用海量数据加大感知监控广度，利用平台加快感知监控的速度与穷举的能力。观察者视角的感知能力有几个特点：

• 全景：举一反三，面的思维，主动思考同类的感知，主动消费已有的数据库、日志的数据。
• 业务：关注观测业务运行状况的指标，比如：是否影响业务服务可用性、性能、功能、体验。
• 数字化：消费、落地关系数据库、内存数据库、日志数据，与关系链路的配置数据多维关联，形成评价系统是否“健康”的多维度指标。
• 感知闭环：感知系统“健康状态”，利用同比、环比的基线比对、多维度组合达到“感知”能力、即时的信息推送、数据驱动的自动化操作让运维能够更快、更全面的感知异常，并融入到工作机制中。

3）主动拨测
在企业推动以客户体验为中心的数字化转型中，主动拨测是监控发现的一种有力补充。主动拨测监控是采用模拟用户访问终端、域名、页面URL、功能、API等，从客户视角监测功能可用性、感知用户端体验、检测网络链路质量，系统事务可用性，在业务投诉前发现问题，提升客户体验。借助机器不间断、自动化执行，提前设计好拨测执行的脚本步骤，可帮助运维执行更细粒度的功能操作，主动获取应用运行的性能体验指标，更准确地了解客户访问业务功能级的体验，以及应用层及网络层性能。同时，站在故障处置角度看拨测，当发生异常时将执行过程进行截图留痕，还可以辅助快速定位问题。

在拨测的解决方案中，通常包括公有云或私有化拨测方案，前者是通过拨测运营商提供部署在世界或全国各地的拨测源进行测试，用户不需要管理拨测终端，只要根据SLA明确的时效性、次数等付费，就可以获得拨测结果。私有化部署的拨测方案则运维组织管理拨测涉及的服务器、终端设备等环境。运维组织可以根据政策、风险、成本等维度考虑选择不同的解决方案。

2.数据运营

数据运营强调主动的运行分析。主动是当前运维组织转型的一个重点方向，区别于当前被动响应服务请求、需求工单、监控告警、生产故障的工作模式。由于证券行业关乎民生，行业对业务连续性风险的容忍度极低，且极易产生客户权益风险，在故障未产生业务影响前消灭故障显得极其重要。所以，我认为主动的数据运营将成为运维或SRE重要的工作，并将建立新的工作机制确保相关工作的落地。以下从故障发现环节的常规巡检、深度巡检、运行感知、风险识别4个主题进行介绍。

1）常规巡检
巡检可以理解为对生产对象的健康检查，常规巡检指常态化的巡检机制。在监控、可观测能力持续完善的今天，经常会引发“是否还需要巡检”或“巡检是否可以被监控替代”的话题。监控能代替巡检的观点，主要理由是：监控覆盖面越来越广，很多巡检指标数据来源于监控系统，且监控执行力更好、实时性更强。也有观点认为巡检仍是一个必要手段，主要理由是：仍有一些重要节点监控无法发现，引入专家经验进行巡检可以发现一些疑难杂症。我认为监控是由众多指标与策略组成，这些指标并没有建立一些特定的主题来归类，而巡检任务通常带有一定主题，比如证券公司的早盘开业、盘中健康检查、夜间清算、周末健康检查、节假日开业检查等。另一方面，应用层的稳定性因素越来越复杂，监控对于业务层的问题发现覆盖面是一个持续提升的过程，管理上会要求运维人员持续深入地学习系统，巡检是运维人员保持必要的学习力、关注度一个手段。

简单的自动化巡检工作将逐步被自动化监控或工具替代，对生产对象健康质检的巡检则仍会长期并存。健康质检的内容需要运维专家不断深入，并建立巡检的管理机制，不断的固化巡检规则、任务、报告、数据感知等解决方案。从技术角度看巡检，在巡场上可以分为定时巡检、实时巡检、基于事件驱动的临时巡检，实现上通常需要数据采集与执行的代理（或复用现在的自动化能力）、巡检策略规则、巡检任务、巡检报告、值班管理几块内容。

2）深度巡检
深度巡检强调主题分析，是主动运营的一个转变表现方式。一个问题通常触发三种策略：诊断误报并取消，潜在风险挂起，发起故障响应流程，其中常规巡检针对线上问题即时反馈并发起故障响应流程，深度巡检则针对潜在风险的发现或预测。可以将常规巡检类比为杀毒软件中的一键健康检查，深度巡检是针对某个部件的深度养护。深度巡检从分析牵头方看，通常包括两类，一类是由运维组织内专家发起的主动性运行分析；另一类是按商务合同要求供应商定时执行的深度巡检。

深度巡检分析的主题应该关注影响业务连续性的风险点，比如应用及数据库等平台软件性能容量、容灾/应用架构高可用、应用逻辑缺陷、数据质量、高可用有效性、应急方案、技术保障方案、数据备份、数据丢失、监控发现及时性等。在实施上，要区别于常规巡检，选择风险点的主题，更加深入分析。同时，深度巡检最好是一项联合运维组织硬件及系统软件运维人员、第三方软硬件厂商、应用系统维护人员等人员协同进行的深度分析工作，要建立线上化的协同机制，确保各环节的衔接紧密与落实。

3）运行感知
运行感知与监控、巡检有一些区别，监控与巡检都是根据已经制定的策略或任务发现问题并触发故障流程，是针对一个个细分点的分析，运行感知是一个面的实时分析。运行感知是从运维专家视角，感知运维对象的运行状况，需要从感知面与感知策略制定感知方案。在感知面上，要广泛使用运行数据，将影响运维对象运行的数据指标化，比如基础设施层的网络链路时延、丢包率等，平台软件层的响应时间、资源负载等，应用系统层的端口监听、JVM内存利率等，业务及体验层的交易成功率、页面加载错误率等，也就是说只要与运行对象相关的关键运行状况的数据都要指标化。在感知策略上，要善用基线的策略，比如偏离度，制定同比、环比、首笔出现等，或引入一些AIOps的算法获得更加有效的基线。

在实现上，运行感知不仅仅以实时运行看板独立存在，还应该与当前主干运维流程结合在一起，以多消费促进感知能力的持续优化，才能不断的加深感知面与感知策略的深度。比如，将运行感知与巡检的定时任务结合在一起，要求每天或每个周末都分析感知数据；将运行感知的异常数据推送到监控告警系统，融入到监控处理的流程中；将运行感知融入到故障诊断的环节，作为问题诊断、影响分析的一个工具。感知能力建设与云原生可观测提出的围绕某个生产对象，拉通相关联的运行数据，建立实时的可观测能力思路相匹配，适用于复杂的系统架构。随着运行数据分析能力的提升，运行感知在故障发现环节中将起到越来越重要的角色。

指导意见中，围绕系统变更风险从变更风险评估、自动化操作、操作风险控制、自动化发布、变更管理机制、质量度量体系等进行了要求，下面我将这些要求归纳为“加强监控覆盖面、打造统一告警平台、探索智能化异常检测”3点做个简要梳理。

4）风险识别
公司之前有关于风险识别的文章，可参见： 《 基于“变化”的运行风险感知能力建设 》

3.协同反馈

虽然理想情况下，故障应始于机器自动化发现，但是随着基础架构、应用逻辑、业务逻辑越来越复杂，系统一个小模块异常都可能导致系统自身甚至关联系统的业务连续性故障，且部分问题可能只影响个别用户。此时，建立一个在线的协同网络，提升协同节点中业务、客户、同业、开发、测试等团队的反馈的效率，仍然是故障发现的有力手段。

1）业务、客户、同业反馈
理想情况下，应尽量减少由业务与客户侧反馈的故障发现占比。但是现实中仍有部分故障，监控或运营分析比较难实时发现，比如局部功能逻辑性、数据准确性等，这些故障虽然不会带来全局性的可用性故障，但是站在以客户为中心角度，此类故障对个别或部分客户属于可用性故障，尤其是对重要客户或权益类交易故障。

针对这类故障，需要提前建立一个高效的信息反馈的渠道，基于用户旅程梳理建立全线上化的问题反馈渠道，比如：将问题反馈功能整合在业务系统中，用户在功能使用时可以方便的反馈问题，运维在后端快速获知用户反馈问题的热点信息并处理；建立全线上化的服务台、一线、二线的问题处理流程，问题反馈的业务人员可以在线获知问题处理进度，机器可以根据问题反馈时长进行线上督办。另外，在企业内部建立必要的信息系统即时通信沟通群，方便公司内业务人员的即时反馈，安排相应的问题服务岗位正在被很多运维组织接受。

同业反馈是针对同类业务事故的一个比较好的方法。比如，银行里涉及人行结算中心、银联、第三方支付、通信运营商等；券商里涉及的交易所、银行、通信运营商、重点厂商等，通常事故会有一定的共性，如能建立实时的故障信息互通互联的渠道，将有助于故障发现、定位、恢复决策与执行。提前建立行业间的即时通信沟通群也很有必要，在预案中提前确定关注、咨询的沟通预案步骤与责任人是一个有效的方法。

2）开发或测试发现
开发或测试发现的故障很重要，但边界比较难界定。边界难界定，涉及一些客观原因，比如很多系统或变更带缺陷上线，缺陷在生产运行中不定时会触发故障条件；很多线上问题，如果是业务反馈，可能会先到达开发人员，由于故障通常在组织内会被用于质量考核，部分开发人员可能会因为主观或重视程度不够，导致故障处置不够及时。需要在流程中建立线上化的问题反馈闭环，比如在变更环节，制定紧急变更类型，这类变更与一般需求变更区别，紧急变更的需求由运维问题单分配，紧急变更支持更高优先级的上线支持。同时，建立线上存量缺陷管理，包括缺陷触发条件、缺陷影响、缺陷计划修复时间，将部分中高风险的缺陷转为生产问题管理，并定期对线上存量缺陷问题进行复盘管理。

二.加强监控覆盖面

指导意见的描述是“建立全面覆盖业务、应用、底层基础架构和基础设施的信息系统运行监测体系，并持续完善，不断提升运行监控的覆盖度。”指导意见中重点关注监控“不漏报”、“少误报”的技术目标。

1.不漏报

漏报可以从两个层面看，一是监控工具不具备某方面的监控能力；二是监控工具具备监控能力，但因为使用者使用问题导致未覆盖监控。前者需要完善监控能力，比如针对生产故障举一反三式的优化，或由不同专业条线主动增加监控能力。为了支持通用性的监控覆盖能力，组织需要设计一些可定制化的监控策略，比如支持动态配置SQL方式，可以让DBA配置基于数据库层面的监控策略，支持业务运维人员配置业务交易情况的策略。

• 对于监控使用的运维人员漏配置监控的问题，工具建设需要考虑几个问题：
• 尽可能自动化配置，结合通用策略管理、CMDB等手段实现监控的自动化配置。
• 管理上有没有建立监控覆盖的最小要求，有没有要求具体指标的100%覆盖率。
• 覆盖率的要求是否确实可以落地，功能上是否设计极不友好。
• 能否引入观察者视角的智能化感知。
• 监控策略的设计如何平衡覆盖面与误报率。
  前两个问题需要从管理机制上解决，后三个问题需要在监控系统中解决，即尽可能让需要覆盖的监控指标从技术上实现免配置，减少对运维人员主动性上的依靠，同时监控系统要快速从技术上响应新的监控指标的落地。

除了主动的监控覆盖面分析优化，还要从数据运营角度发现监控漏报问题，比如围绕在“生产事件”驱动的主线，对事件复盘阶段的数据分析，发现监控漏报的事件，再举一反而“运动式”的优化。

2.少误报

误报带来的问题也很大，大量反复的误报告警会让运维人员麻木、消极，进而忽视监控告警，错过真正的监控告警的处理。监控告警的误报情况需要借助数据运营的方式，在目标上结合组织人力资源，梳理各团队处理告警能力，评估一天可处理的告警峰值KPI值，再基于告警KPI目标分析告警的级别、来源系统、时段等维度，制定具体数据分析工作。通常可以采用2/8原则的方式，找告警量比较突出的团队、人、系统、报警策略、源端监控系统，结合告警响应能力去针对性地推动优化。

在减少误报过程中也可以从报警策略与报警管理着手进行运营，从告警策略上可以关注：

• 设计监控维护期功能，但要考虑维护期过长的情况。
• 在静态阈值的基础上增加动态的基线。
• 增加监控自恢复的策略与自动化恢复手段，比如端口异常进行自启动。
• 加强告警收敛、抑制功能。
• 同一个策略维护多套与环境相关的策略，比如实时交易、运营管理、后台支撑、应用平台对同一个策略要求可能不一样。
• 监控告警对应操作规程或优化监控告警描述，关联操作手册。
• 持续的删除无效监控策略，调整监控策略，降低告警级别。

针对性的对告警来源的主要策略进行优化，比如像磁盘告警、SSH无效、CPU毛刺等通常占比高的告警，建立对这类告警的阈值合理性评估、数据清理规范的落实则可能事半功倍。同时，实际情况看，组织里可能出现某个小组或某个人所负责的告警会明显多于其他，这与个别运维人员对监控策略的持续优化是否落实有关。针对性地对告警、人等维度进行运营分析与工作推进可以得到事半功倍的效果。

三.打造统一告警平台

指导意见的描述是“应建设统一的告警平台，与多种专业化监控工具实现联动，形成一体化运维监控平台，并建立告警的统一汇聚、分派通知和处置流程体系，持续开展告警的分析运营，提升监控告警的全面性、准确性、及时性。”指导意见重点强调了企业建立统一告警平台的重要性。

1.告警运营

1）告警效能指标
在故障处置过程中，通常关注一些指标，比如：MTBF（无故障时长）、MTTI（平均故障发现时长）、MTTK（故障定位时长）、MTTF（平均故障处理时长）、MTTR（平均故障响应时长）、MTTF（平均故障恢复时长）。其中，MTTR重点要关注监控告警时效性管理，即告警出现后多久被运维值班人员受理并介入处理，针对不及时处理的告警如何升级加快处置。通常来说，运维工作者应该相信客观数据，即有报警即要响应，而非怀疑。

数据运营中，可以考虑实时与离线分析两个角度。在事中提升监控的响应效率有不少方法。

实时分析涉及以下：

• 针对响应不及时的数据进行实时升级等操作。
• 结合当前物联网设备的发展，可以考虑结合一个智能的穿戴设备提升响应效率。
• 优化监控告警内容的描述，从描述中即可得知监控的基本处置方法，或将每个告警关联一个告警处置方法。
• 优化监控告警级别，对不同级别有针对性地准确触达与升级等。

• 结合ChatOps，对未及时处理的监控告警进行升级与群公示。

  离线分析是定期的监控响应数据分析，比如采用报表分析的方法，按人、团队、系统、类型等聚类排名，排名是一个有效的推动方式。

2）告警处理与时效性管理
告警的处理是建立于在告警的操作层面，通常需要涉及以下功能。

• 告警操作方面，包括确认、关闭、暂挂、通知、转派、生成工单、触发故障等。
• 告警分析方面，包括告警报告、告警处理及时性、恢复及时性、误报分析、漏报分析等。
• 告警复盘方面，重点针对告警进行分析确认，从漏报、误报、触发及时性、处理及时性等角度进行分析。
• 维护期设置方面，重点是针对需要对监控系统、上游系统、硬件环境、发布软件后的重启等进行维护，为了减少这些对象异常引发的无效告警风暴，设置相关维护期，有抑制告警的效果。

监控告警时效性管理是为了辅助达成“高响应”目标，指告警出现后多久被运维值班人员受理并介入处理，针对不及时处理的告警如何升级加快处置。运维组织在持续推动故障更快恢复，尤其是对事中定位进行大量的资源投入，但在一些故障处置复盘中会发现有一些因监控告警不及时处理导致延误战机，而且这个时间可能远大于事中定位所减少的时间。告警的时效性管理，重点是在事中对告警的响应处理时间进行实时监测，当出现告警延迟处理的状况，自动化进行多次触达、升级、公示，以达到告警得到响应处置。

2.告警管理的实现

1）告警汇总与数据标准化
统一告警首先要将各个源端的监控工具告警信息进行汇总，并对告警数据归一标准化。通常由源端监控工具主动推送告警信息，包括告警内容、告警级别、告警分类、告警指标id、告警推送渠道、主机IP、应用等信息。源端监控工具通常分布在不同专业条线、不同硬件、不同系统中，且监控工具来源诸多，格式、协义、运行环境等各有不同，需要建立统一的监控告警采集和控制能力，对告警数据的行为和控制行为进行统一规范的管理。统一告警需要承担告警数据接收、数据的结构化、数据的指标清洗计算，并存储起来。

2）告警丰富
在建设监控过程中会花较多时间在监控数据采集、数据处理、指标覆盖面方面上，也就是“监”上面的投入，对于“控”方面的投入较少。“控”方面的投入少往往会导致监控告警后，运维人员仍需花很大时间去判断影响、定位根源、应急处理等方面，延误了故障恢复的战机，直接影响应用可用性的提高。要做好“控”，告警丰富是关键，告警丰富的广度与深度则依赖于CMDB的建设。告警丰富可以从数据层面与告警交互层面进行。

在数据层面，告警数据统一标准化后，下一步是丰富告警信息，包括基于CMDB的对象属性与关系数据，告警描述丰富（通过基本信息的丰富、拓扑丰富）、告警现场丰富（基础层、应用可用性、性能、业务运行指标信息丰富）、知识库丰富，提高运维人员分析问题的能力。其中，关系数据可以从纵向和横向关系进行分析，纵向是指从底层的基础设施、网络、服务器硬件、虚拟机、容器、操作系统、中间件、应用域、应用、交易；横向是指从当前的应用节点、上游服务器节点、下游服务器节点的交易关系。

在告警处理层面，告警丰富需要与告警处置相关。监控告警发生到处置环节，仅仅给出“什么时候，什么资源，出现什么问题”远远不够，运维人员需要其他运行数据辅助告警处理，通常包括数据、操作层面的丰富。告警丰富不能为了丰富而丰富，而是要从事件处理过程中需要的信息进行丰富，比如判断故障影响分析涉及的告警所在系统的业务及性能关键KPI指标；辅助问题定位涉及的故障点相关的调用链关系，上下游系统的关键KPI指标，系统变更行为，日志信息等；故障恢复所需要使用的重启、回切、切换、应急预案等工具等。告警的丰富可以考虑与可观测能力相关联，结合可观测的信息与整合逻辑思路辅助告警的处理。

3）告警收敛、派生、抑制
同一个故障会触发多类指标的告警，同一个指标在故障未解除前也会重复产生大量的告警事件，如果将全部事件都展示出来，那对于监控处理人员将是灾难性的，所以需要进行告警收敛。告警收敛除了在最后的告警中处理，还需要进行前置，即针对传统指标固定阈值、基线阈值不准确问题，比如建立指标波动的变化例如周期、趋势、时间模式等因素来综合判断指标的波动变化，或基于AIOps动态基线的异常检测算法，收敛告警，提高告警准确率。

告警抑制与收敛很类似，从名词看是当出现大量告警时压制当前告警的通知，有效的防止告警风暴。比如：物理机异常时，基于物理机上的虚拟主机以上的各类监控指标都会触发，但这些警告并不能反映真实问题在哪，真正需要发出的应该是物理机不可用的告警。要做好告警的抑制服务，需要建立准确的对象关系，根据关系设置相关抑制策略。

告警的派生是多条告警整合后，或某条告警达到某个策略后，派生出别一条新的告警。还是上面同一物理机下多个虚拟主机异常的例子，统一告警在分析后，可以产生一条新的、更加精准的硬件告警信息，并通知用户进行处理，减少警报噪音，降低信息干扰，减轻运维人员处理警报的压力。

4）告警分级及告警分析
对于不同的告警需要有适当层次的告警分级，告警升级的策略。告警分级是将告警当前紧急程度进行标识显示，告警升级是对于低级的告警当达到一定的程度，比如处理时间过长，则需要进行升级。

告警风暴问题一个重要因素是告警分级不清晰，比如将大量通知与知会类的报警设置为高处理级别的告警。为了规范化监控告警分级，解决每个监控工具不同分级方式的现状，考虑到原有监控工具改造的可行性与成功，通常减少对源系统进行改造，选择在告警集中后，由告警集中管理模块承担事件分级的标准化规范。选择多个层级的告警级别需要视组织精细化管理与平台能力，级别越多需要的能力越高，但至少需要制定“通知（或知会）、预警（或不紧急）、告警（或紧急）”三级，分别代表的意义如下。

• 告警（或紧急） ：属于已影响业务或可用性的异常事件，需要马上介入处理（非营业时间的告警可以是预警），由于告警将调度现场资源快速介入处置，运维组织需要尽量提升告警的准确性。
• 预警（或不紧急）： 属于异常事件，这类事件暂时不会有业务影响，需要运维人员关注并处理（预警事件长时间不处理时，会升级为告警）。
• 通知（或知会）：知会性的监控告警，这类监控告警通常不是告警，属于提醒性的消息，比如每天巡检前发布某个业务系统的登录量，业务量等。

通常对于不紧急的监控告警，会采用工单的形式、报表、看板的方式定时推送，减少对盘中值班资源的影响，组织可以根据企业人力资源现状从系统级别、告警策略等角度调整监控告警级别。有了分级，就要对事件的处理的方式制定策略。

• 微信或短信消息推送： 不同级别的监控 告警 ，推送人员可以不同。
• 电话拨打： 紧急告警或告警事件N分钟未受理 ，工具调用拨打电话接口拨打给负责人， 负责未接电话或N分钟仍未受理拨打群级经理 。
• 可视化： 通知采用单独一标签页，预警为字体红色，告警为橙色，紧急告警为红色。
• 监控告警处理时效性公示 ：对于监控告警处理不及时的告警， 可以按级别推送到团队的IM群中进行公示。

另外，需要注意的是上述3级告警根据受理时间，解决时间将会有升级机制，不同的级别告警有不同的告警处理机制，不同的业务期间或非业务时段的告警级别或升级机制可以不同。对于短期无法恢复但有计划解决的告警，可以设置挂起/维护期，期间如未发现该指标有更快级别事件（或手工设置挂起期间的升级告警阈值，比如80%的空间告警，设置在2天内95%内不告警），不进行升级。

四.探索智能化异常检测

指导意见的描述是“鼓励有条件的证券公司积极开展运维大数据和智能化运维工具平台建设，引入指标异常检测、日志异常检测、告警收敛、全链路调用追踪、根因分析等监控和智能故障发现和定位手段，不断提升信息系统的故障预防和故障发现能力。”

2.异常检测相关算法

运维社区与AIOps标准工作组发布的《企业级AIOps实施建议白皮书》整理了当前运维常见的算法，具体如下。

指标趋势预测：通过分析指标历史数据，判断未来一段时间指标趋势及预测值，常见有 Holt-Winters、时序数据分解、ARIMA 等算法。该算法可用于异常检测、容量预测、容量规划等场景

指标聚类： 根据曲线的相似度把多个 KPI 聚成多个类别。该算法可以应用于大规模的指标异常检测：在同一指标类别里采用同样的异常检测算法及参数，大幅降低训练和检测开销。常见的算法有 DBSCAN、 K-medoids、 CLARANS 等，应用的挑战是数据量大、曲线模式复杂。

多指标联动关联挖掘：多指标联动分析判断多个指标是否经常一起波动或增长。该算法可用于构建故障传播关系，从而应用于故障诊断。常见的算法有 Pearson correlation, Spearman correlation, Kendall correlation 等，应用的挑战为 KPI种类繁多、关联关系复杂。

指标与事件关联挖掘：自动挖掘文本数据中的事件与指标之间的关联关系（比如在程序 A 每次启动的时候 CPU 利用率就上一个台阶）。该算法可用于构建故障传播关系，从而应用于故障诊断。常见的算法有 Pearson correlation、 J-measure、 Two-sample test 等，应用的挑战为事件和 KPI 种类繁多，KPI 测量时间粒度过粗会导致判断相关、先后、单调关系困难。

事件与事件关联挖掘：分析异常事件之间的关联关系，把历史上经常一起发生的事件关联在一起。该算法可用于构建故障传播关系，从而应用于故障诊断。常见的算法有 FP-Growth, Apriori，随机森林等。

故障传播关系挖掘：融合文本数据与指标数据，基于上述多指标联动关联挖掘、指标与事件关联挖掘、事件与事件关联挖掘等技术、由 tracing 推导出的模块调用关系图、辅以服务器与网络拓扑，构建组件之间的故障传播关系。该算法主要应用于故障诊断、定位。

2.智能化的异常检测场景

当前，我认为智能算法应该重点重要赋能已经有的异常检测场景。类似于AI技术帮助手机证券提升客户体验、提高数据决策准确率等场景，原来的业务模式并未发生变化。所以，智能算法的异常检测可以重点融入到已有的工作场景，比如，利用算法，赋能实时可观测场景下黄金指标的异常检测、性能评估场景下的性能指标、容量管理场景下的容量指标、业务运营场景下的业务指标、风险识别场景下的风险指标，让这些指标能够立即具备动态基线的异常检测能力。