建维以法 众智远行——建行云生态化运维方法助力AIOps实践

1

建行AIOps实践现状与挑战

建设银行作为大型国有商业银行，客户体量大，业务范围广泛。随着国内外环境的变化，根据“十四五规划”要求，建设银行在不断积极践行新发展理念，探索“新金融”落地实践，目标是建设“以数据为关键生产要素、以科技为核心生产工具、以平台生态为主要生产方式”的现代金融供给服务体系。

为此，建设银行一直在推动“住房租赁、普惠金融、金融科技”三大战略，开启第二发展曲线，实现数字化经营、生态化业务。建行云生态是建设银行落地三大战略和第二曲线的基础支撑，是数字化经营的操作系统，是生态化业务的载体和渠道。如果业务战略是一支探照灯，“云”就是业务的影子；业务到哪里，“云”就在哪里。随着三大战略推进，建行云业务蓬勃发展——云规模3年增长了15—20倍，覆盖集团一体化、实体经济、政务服务、住房服务、普惠金融等9大领域。同时，建行云的目标客户发生重大变化，不仅服务本行及集团业务，也助力国家经济发展，赋能合作伙伴，服务百姓社会民生，涵盖了政府、企业、军队、机构等战略合作伙伴。

业务的快速发展的同时，建设银行的IT技术架构也在不断演进：分布式、容器化、国产化技术带来了越来越多的新产品和新技术，这些都对运维提出了更高的要求。为贯彻“规模化管控”和“双态运维”的要求，建设银行自2015年开始探索智能运维，运维管理体系从最初的流程驱动向开发驱动、数据驱动演进，运维技术也从人工操作向自动编排、自主管理演进，先后在指标异常检测、告警聚合、日志分析等方向做了智能化的尝试。

建行云运维能力的演进

2020年，Gartner发布中国ICT技术成熟度曲线（下图），可以看出AIOps目前正在从过高期望的峰值（Peak of inflated Expectations）向泡沫化的低谷期（Trough of Disillusionment）滑落。这表明，经过近几年的摸索与试错，AIOps已发现可行性的领域并进行落地实践。这与建行最近几年对AIOps的探索路线是基本吻合的。

此外，Gartner在2020年10月发布的《银行业20大AI应用场景》报告（下图）， AIOps经典场景“故障根因分析”上榜，排在第18位，说明AIOps在业务价值和可用性方面还有待提高。

通过上面的分析我们看到，AIOps方向是正确的，时机也已经成熟，正在从碎片式、散点式发展向AIOps落地应用和推广逐步演进。然而AIOps在建行的落地实践并非一帆风顺，我们还是遇到不少问题和挑战——AIOps不是缺少算法，而是缺少培育算法的土壤和机制——可以总结为“四缺”，即缺人才、缺问题、缺数据、缺平台。

• 缺人才。AIOps人才门槛比较高，既要有丰富运维经验，又要掌握一定的AI算法知识。如果没在运维领域工作四~五年，就不会懂运维。

• 缺问题。我们不缺乏运维问题本身，而是缺乏边界清晰、描述准确且有评价标准的运维问题。

• 缺数据。机器学习领域知名学者吴恩达提出“80%数据+20%的模型=更好的AI”。从实际应用来看，如果找一个场景做AI，80%的数据非常客观。不过由于安全性的问题，我们很难从公开市场获得运维数据。

• 缺平台。AI要持续发挥作用，必须有敏捷、开放、共享且支持数据产生、模型训练、模型部署和优化一体的ModelOps平台做支撑。

我们认为，AIOps是对Ops的赋能，但不是运维问题的银弹。AI解决的是算法问题，而“四缺”本质是运维业务问题，最终要通过运维体系来解决。技术（AI）+业务（Ops）双轮驱动才能发挥1+1>2的效果。我们必须既重视AI，又重视Ops，甚至在一定程度上更重视Ops，才能完成运维的目标。建行云生态化方案，正是针对以上问题的一种全新模式的运维体系方案。

2

建行云生态化运维体系

什么是好的运维？好的运维是将最合适的技术快速应用于生产实践中，满足业务敏捷发展、技术快速迭代的需求，让运维成为业务拓展的助力，而不是阻碍业务快速发展的绊脚石。

建设银行生态化运维（Eco-Ops）是以生态圈运维能力提升作为目标，利用技术平台支持成员场景开发，分享公共能力，鼓励成果共享的运维体系。生态化运维理念是“开放共享、众创共建”，将运维由单打独斗模式转变成共同奋斗，从运维平台建设升级走向生态演进。通过自身与生态圈的连接，形成运维共识，可以获取圈内提供的最佳实践、公共服务、协同的运维运营组织，快速构建自身的运维服务体系，并可以通过平台进行二次开发、成果共享，形成生态圈的良性循环。

生态化运维的“五个特征”和“八大能力”

 “五个特征”分别是整体性、开放性、可持续性、多元化和服务化。

• 整体性，生态化运维是从方法论、制度流程、组织架构、技术能力、运营管理、内外部环境等全方位、多角度整体考虑的运维模式，面向生态圈成员整体而不仅仅是组织内部。

• 开放性，开放是生态的基础，包括技术、服务、理念以及价值的开放，具备以客户价值为核心的跨行业开放式的架构设计。

• 可持续性，生态圈需要经营管理、价值引导和文化润泽等生态运营举措，如采用仲裁管理、激励机制、评价反馈、开源管理、生态大学、生态链管理，切实保障和推动生态圈的互利互赢和良性可持续发展。

• 多元化，生态圈中涵盖不同行业、不同地域、不同性质的多元化组织。

• 服务化，是指将服务接口标准化，所有运维能力都以服务的方式向生态圈开放。

为满足生态化运维这五个特征，生态化运维需具备以八大能力：

• 运维技术中台能力，运维能力通过碎片化中台沉淀，是生态化运维的基础支撑能力；

• 多租户支持能力，以混合云租户的形式提供开放能力，是生态共存的方式；

• 服务管理集成能力，生态圈中每个组织共享出来的运维服务需通过公共平台集成发布，是共享、众创的关键；

• 端到端安全能力，保障从服务发布到使用的企业级流程安全，是生态圈的生存基础；

• 生态管理能力，生态圈需要通过合理的运营才能发展壮大，是良性演进的融合催化剂；

• 运维实践能力，保障共享的运维能力能够快速在其他组织中参与实践，是生态化运维落地的必要条件；

• 组织保障能力，以全新的组织架构和绩效考核推动运维生态化转型，是生态运维动力源；

• 工具产品化能力，在运维中台的基础上提供将运维工具快速产品的能力，是生态化的共享基础。

Eco-Ops实践的关键在于构建创新型组织架构、赋能式技术工具和模型化体系方法，这也是Eco-Ops实践的三大支柱。开发和运维存在鄙视链，为什么很多人不愿意做运维？原因是运维做起来没有成就感，很难找到专业化的方向。对此，我们通过模型化体系方法、赋能式技术工具来解决运维成就感不足问题，创新型组织架构来设定人员定位，解决成长问题。创新型组织架构是一个学习型、成长型的组织，采用激励的方式引导大家来创新；模型化体系方法将运维的大问题拆解成边界清晰、标准描述、有评价标准的小问题，组织里的任何一个人都可以拿到创新的方向；同时，赋能式技术工具保证成员的研究成果得快速被应用，并且获得良好的反馈。

生态化运维实践要点

其中，模型化体系方法是三大支柱的核心，我们称之为“绿洲”，指运维中以对象、活动、场景三维度构建的集成描述框架，寓意困境中的期望。我们希望以此来解决运维知识文档化难以落地的问题，将运维实践经验知识化。

建立绿洲（OASIS）模型需要三步：

• 活动标准化。将运维领域各项工作进行分解识别运维活动，并对活动的要求基本步骤、规则接口进行抽象和标准化表述，即将运维已知方法论进行精简、统一描述，基于此构建原子化的对象无关的运维活动服务。

• 对象模型化。在满足运维活动要求的基础上，按照奥卡姆剃刀原则，设计包含规则、属性、关系、指标、轨迹和标签的六要素对象模型，对象模型是特定对象运维管理的实例化，包含了对象整套的管理实践。模型是对传统CMDB的极大拓展，通过引入动态和高阶语义信息，实现运维对象的完整描述。

• 场景行业化。运维场景是运维人员的实际工作界面，每个场景都是为了实现特定运维业务的流程、对象、活动的组合。不同行业、不同IT组织的特定管理流程和行业参数设置等都需要在场景中落地。

通过绿洲提供的模型化表述，运维标准规范、实践经验都变成了数字化的共识，不仅为生态化运维的建立提供了方向，也降低了进入运维世界、认识运维问题的门槛。

3

生态化运维助力AIOps实践

建行云生态化运维理念与AI的碰撞恰逢其时。如果说业务是翱翔天际的战机群，生态化运维是提供平台支撑的大型航母，由运维方法论来引领前进的方向，技术工具做动力引擎，数据是基础燃料，而 AI是能让动力更澎湃的核催化剂。AI、SRE、DevOps、低代码解决的是效能问题，Eco-Ops解决的是模式问题。有可共享的方法论做引导、赋能型的工具做支撑、创新型组织架构做保障，运维从高成本、低效率的定制化模式进入开放共享的协同量产阶段。在此基础上AI才能发挥出核催化剂般的巨大能量。

生态化运维与AI的关系

AIOps的“四缺”的问题，可以由Eco-Ops的三个关键实践解决。方法论解决问题和数据缺乏，组织解决人才缺乏，工具解决平台缺乏，三者协同就形成了众智共创的良性循环。

我们前期做AIOps大部分是AI去找场景，成本比较高，所以会导致散点式、碎片化的情况；现在通过Ops方法论让业务主动去寻找合适的技术。在体系引导下的AI才能回归理性，具有更广泛的推广价值——这也是我们的目标。

基于Eco-Ops的AIOps实践

实现智能事件处置首先要进行场景分解，看事前、事中、事后要做什么。事前建模，进行对象模板维护、事件完备检查等；事中分为事件识别、根因定位、止损处置三个场景，每个场景又有细分，如止损处置包括止损推荐、止损实施的动作；事后有复盘验证。基于这些活动的标准和规则要求，我们抽象出它所对应的运维对象模型所需要的内容。比如，事件识别阶段有启动规则，处置阶段有处置规则。每个对象有哪些处置动作，每个处置动作花多长时间，处置时有没有业务影响，这些都属于Ops。

规则分析方面，每个运维对象有多少指标、每个指标之间的根因依赖关系都是重要的因素。将建行物理子系统看作一个应用，它在事件中涉及到属性、关系、指标、轨迹和标签。场景拆分好了，活动定义有了，对象模型也建好了，在这个基础上我们去寻找哪些活动适合用AI算法来解决。这里会涉及到大量的算法，如时间序列分析、异常检测、关联分析、因果推理、推荐决策和自然语言处理类等。

写在最后

AIOps本质还是运维问题，单纯的智能化产品、智能化场景不能解决根本问题，最终依然需要传统运维方式加以补充。做场景最重要的是，“人”不能从场景中走开。我们的实践经验是，即便做到80%的智能化场景，另外20%的场景依旧要传统的处置方式做优化补充，最后形成一个真正能发挥作用的完整场景。

国际AIOps挑战赛的模式非常好，把工业界和学术界的同仁聚集在一起。“建维以法，其思益深”，工业界提供Ops方法论支撑，专业化程度更高，能更好地找到问题，对问题的思考也真实有效。同时，我们通过问题分解，将大问题变成小问题，进而降低AIOps门槛，吸引更多的人才参与AIOps实践，我们称之为“众智共享，其行久远”。希望通过共同努力推动智能运维在实践中更好地落地。

END