当前位置:首页 > 新闻中心 >新闻详情

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

发布时间:2021-09-14 13:51:59

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实践,我们称之为“众智共享,其行久远”。希望通过共同努力推动智能运维在实践中更好地落地。






 
 
 

TOP

400-666-1132