为解决数据中心建设升级和运维创新带来的新课题。“2021金融业新一代数据中心发展论坛”得到了贵州省农村信用社联合社的大力支持，吸引了银行、保险、证券等金融行业数据中心负责人以及科技公司参与。此次论坛以“数据驱动转型  云智引领未来”为主题，将围绕数字经济时代，金融数据中心创新发展策略和实践，探讨金融数据中心智能化发展新趋势。

 

必示科技解决方案专家应邀参加会议，并发表《AIOps项目落地经验——基于40+头部金融企业实践》主题演讲。他指出，智能运维能力建设已然成为数据中心保证系统可用性和业务连续性的关键一环，但其建设不能一蹴而就，而是有方法论可循。必示科技基于多年在40+头部金融企业的AIOps项目实践经验，探索出一条行之有效的AIOps方法论，能够帮助金融行业数据中心建设智能运维体系，推进运维数字化转型。

 

 

 

以下为演讲全文：

 

 

近几年，从监管机构、国有大行、股份制银行到头部城商行、证券机构，必示科技服务了很多客户。回过头来看，其实大家面临的问题很相似：伴随业务发展越来越迅速，技术环境和系统因果关系变得更为复杂，系统变更也越来越频繁，最后导致运维最根本的目标——保障业务连续性面临巨大挑战。

 

对于数据中心来说，保障业务连续性是最重要的事情。但是正如罗马不能一天建成，AIOps需要一步一步建设。那么从哪里入手？必示的选择是先从应用性能监控入手。

 

大家对海恩法则比较了解，在现有挑战的情况下，要做好业务连续性，仅仅做应用性能监控是不够的。因为传统的业务性能往往基于SLA进行监控，当告警发生的时候，往往故障已经产生了。

 

那么，建设智能运维或者下一代运维方案应该怎么做？必示的经验是不能面向故障，要面向隐患。首先，要扩大有效监控范围，提前发现隐患，而不是单纯扩大监控范围。现在我们做了很多监控工具，采集了很多数据，有时候会带来大量告警的负面影响，这不是有效的监控。

 

其次，当隐患和故障发生时，通过智能化分析手段，加快排障时自动分析和处理海量数据的速度，帮助运维管理员快速找到排障的方向。

 

 

必示应用性能AIOps解决方案，实现了三个落地效果非常好的场景：业务性能异常检测；业务报表多维分析；横向的跨应用调用链路分析。当大量故障发生时，通过对多个系统的多个交易码和服务器故障进行调用链路分析，给出根因结果。

 

 

必示应用性能AIOps解决方案能够帮助数据中心从粗放式运维迈向精细化运营，从事中、事前、事后三个角度来具体看一下。

 

事前，从补全数据逐渐到补全监控，提升系统可观测性。虽然我们有了很多监控工具和海量数据，但其实无法接太多告警。举个例子，应用性能只能监控系统级别或者个别智能筛选的交易。必示现在能做到对交易码、主机、渠道、应用流进行监控，没有漏报且误报率低。

 

事中，进行智能化分析，将人工、手动分析转变为智能化、自动分析。排障时有大量分析工作，包括看日志、前后对比报文、对比数量、查看技术环境异常等，这里有一部分是简单重复、工作量大的工作，非常适合算法来做，能够提高排障效果。

 

事后，优化IT治理运维流程，从面向故障到面向隐患。为什么这么做？先看个例子。以前，当告警提示“手机银行响应率低于95%”时，所有人要放下手上的其他事情，去优先处理的事情。但是现在告警不一样，比如手机银行余额查询从300ms上升至500ms，这个异常持续10分钟后恢复正常。但它不是故障，因为它没有影响生产。假设这种情况每周出现三次，下周又出现三次，要不要处理？这就对IT运维流程提出了挑战。依据海恩法则和墨菲定律，隐患一定不能忽视，所以运维流程要从面向故障逐渐走向面向隐患，这是我们与金融行业客户共同探索出来的经验。 

 

 

 

 

 

 

数据中心AIOps之路如何走？关于这个问题有很多声音，比如统一告警、数据中台、智能算法以及其他。哪个是正确的？我们复盘以往项目经验，发现答案早已有之。

 

 

AIOps是AI+Ops。AI是一门科学，AIOps是基于人工智能的科学。中国人工智能领域顶级专家张钹院士提到，人工智能要做好，需要满足5个条件（如下图所示），任意一项或多项不满足，做起来就很困难。

 

 

为了易于理解，以围棋和德州扑克为例。围棋方面，2016年AlphaGo碾压李世石，2017年AlphaGo秒杀了所有人类棋手，以至于很多围棋选手都在向AI学习。相对来说，德州扑克不一样。德州扑克到现在只有一些自动化辅助分析的工具，与人类对抗互有胜负，或许输率会一直下降，最终让对手输光筹码。这与围棋相比有很大差异，背后的原因是什么？ 

 

从上面提到的5个条件来说，围棋是完全满足的，它是单领域、信息完全的。AI下围棋的时候，只需要看棋盘上的黑子、白子以及规则，至于下棋的人是谁不重要。德州扑克不同，要不要牌、加不加筹码完全取决于自己与对方手中牌的好坏，这是AI做不到的，也就是说“信息不完全”。然后，德州扑克的不可预测性很强，比如我的牌面虽然不好，可以不下筹码或者干脆all in 来迷惑对方，这也是人工智能很难做到的。

 

 

以此来看必示的算法实践。大概2017年的时候，必示自研的单指标异常检测算法，完全满足5个条件，能够很好地找出违反历史规律的异常点，但是它没有上生产环境。原因在于，单指标异常检测不是生产环境所需，生产环境需要的是业务系统的故障处置。

 

举个例子，有一个年收益率5%-7%的理财产品，在进行促销时交易量骤增，这违反了历史规律，但并不是故障。再比如，这个理财产品10:00开始促销，手机银行成功率在9:55左右疯狂下降。这是异常吗？是。这是故障吗？没有人关心。原因在于信息不充足、定义不明确，算法不能从一个KPI数值知道业务信息。再比如，这个理财产品促销了三期忽然不卖了，因为业绩已经达标了，但这个信息算法不可能知道。

 

必示科技用很复杂的产品逻辑，把业务知识和运维经验固化到产品里面，最终做到了95%准确率的业务性能故障检测。

 

 

对此，我们总结了三点经验：

 

没有算法是万万不行的，因为算法才能解决核心问题。没有算法，很难对成千上万个服务的交易码进行监控。

只有算法也是万万不行的，因为算法只解决了核心问题。

如果把运维比作建设城市的话，场景就是房子，算法是钢筋水泥。没有钢筋水泥，建的房子规模再大也是图左所示的城市；但有了钢筋水泥就可以建设图右所示的现代化城市。

 

 

 

这里，我借用中国传统哲学的概念“道法术器”，来说明数据中心AIOps建设。当然这个方法论只是初步的想法，尚不成熟。

 

 

“道”是在海量复杂数据上做最小场景的智能化。什么是海量复杂数据？我们有一亿条核心的记账记录，数据量庞大但是并不复杂，可能跑得慢一点，但一个SQL就能搞定。但我们却无法同样的方式监控1000个交易码，因为它是海量的复杂的数据，是人工和传统工具无法处理的。最小场景是什么？一定是符合张钹院士所说的5个条件，如果不符合就肯定做不好、做不成。智能化是什么？它一定以无监督为主，因为有监督就违反了海量数据，同时输入有限的人工、业务知识、运维经验或者其他需要的知识，否则就不是一个完整的场景。

 

“法”是指方法论。首先一定要场景落地先行，“道”是说必须建场景，不建场景解决不了核心问题。随着场景积累和场景的有机联动，最终实现数据中台，通过一个个场景建设来推动数据治理。此前有很多用户反馈数据中台建好后，却无法用起来，原因在于没有场景。大家按照业务数据中台的惯性去建设运维数据中台，区别于银行、证券有大量业务等着场景用，运维数据中台在没有场景的时候用不起来，这意味着数据治理是一次性的，建完就闲置了。

 

数据治理的问题是系统不断变更导致的，一定要通过场景来驱动数据中台建设，先把数据底座框架做出来，再随着场景的不断积累，形成“指标体系+数据治理”，最终达到智能运维数据规范。当数据和场景在某一个或多个领域极大丰富时，我们从扁平算法摘要逐渐过渡为立体排障树。

 

“术”是指流程。刚才所说的运维数据规范就是建立面向隐患的运维流程，这里不再赘述。而运维数据规范，是要从根本上解决数据问题，一个新业务系统投产或者版本更迭时，需要很多人力铺上去，时间可能长达一两个月甚至三个月，然后系统才能稳定下来。背后原因在于新系统上线后，无法预估有多少工作，即便做了很多测试，但代码质量、流程都可能出现问题。监控不全归根究底是没有运维数据规范，当有智能运维数据规范的时候，我们在新系统上线之前就能够有一个明确的预期，日志包含哪些内容、有哪些模板、报文格式什么样、监控指标应该有多少，配置了多少，还缺多少，交易码多少个、涉及多少渠道、有多少调用关系，有哪些监控了哪些还没有，在系统上线之后，统筹监控所有的服务、交易码和维度，一旦出现任何微小问题马上给出定界建议。如此一来，从运维侧倒推开发，能够缩短系统上线稳定期，支持更快的变更、更灵敏的业务反应。

 

“器”是指运维工具。按照“道”去打包补全场景，以业务性能为先，及时发现应用故障，并通过算法定位分析问题根因，这里不具体展开。

 

 

3、从方法论到实践：金融行业数据中心的AIOps应该如何逐步建设？
 

 

有了方法论，如何指导做产品？下图主要说明的是AIOps建设不是一蹴而就的，逐步迭代至成熟才是正确的方式。

 

必示科技已经做了一些不错的单场景，正在致力于优化场景的串联。从产品框架、用户价值和业务价值来说，必示现有产品比较全面，包括数据平台、统一监控，统一告警和排障摘要。通过这样的产品框架，我们希望降低误报、降低漏报和快速排障，最终在当前运维人力资源不变的情况下，支持更高的运维效率、更大的系统规模、更快的变更频率，进而实现数据中心的价值——支持更敏捷的业务。