C. 智能运维解决方案 --- 微众银行

C. 智能运维解决方案 — 微众银行

概述

• IT 运维的价值体现在对业务稳定、运行安全和提效降本三个方面的保障与控制
• 发展阶段
  • 手动运维
    • 背景
      • 信息化发展初期缺少运维工具和操作指南
      • 依赖个人知识、技术及经验
  • 流程化、标准化运维
    • 背景
      • 业务量增长超过人力增长
      • 运维流程、标准等文档的建立和管理
      • 工具标准化管理
  • 平台化、自动化运维
    • 背景
      • 架构异构；运维方式差异化
      • 手工执行转化自动化操作
      • 事件与流程关联
      • 运维数据可视化
  • DevOps
    • 背景
      • 需求迭代频繁、快速；业务架构复杂
      • 速度质量提升
      • 工具全链路打通
      • 跨团队线上协作
  • AIOps
    • 背景
      • 业务庞大；海量数据积累；AI技术成熟
      • 现处于实践初期
      • 单一场景智能化
      • 目标为机器决策
• 数据基础
  • 配置数据
  • 日志
  • 告警

基础设施建设

• CMDB
  • 1.0
    • 概述
      • CMDB1.0 吸取了开源项目 oneCmdb 的经验， CI 模型配置结合 key-value 形式存储 CI 数据，灵活的支持了当时的银行基础架构建设的初级阶段。
    • 问题
      • 但随着不断扩大的银行业务规模，配置项越来越多样，科技类的工具系统如雨后春笋般建立起来。在此过程中，CMDB1.0 的架构在系统间对接方面，配置项多样性模型建设方面，以及数据量急速增加方面的可扩展性表现得越来越差， 同时用户体验方面也暴露出很多问题。
        • 模型定义不完整：CMDB 中管理的配置范围、配置数据覆盖不全，配置关系及属性定义不完整，无法有效支撑日常运维的基础诉求。
        • 数据维护成本高：未建立配置信息的生命周期管理流程，无法达到自动更新维护数据的目的。当时，CMDB 中数据的采集和变更严重依赖人员维护，维护成本高，数据滞后于真实运行情况，甚至部分配置信息在系统外维护，CMDB 未能发挥应有的作用。
        • 数据质量无法保证：缺乏数据之间逻辑规则校验机制以及数据同步校验机制，数据准确性和数据质量无法保证，运维人员不信任 CMDB。
  • 2.0
    • 特点
      • 以应用为中心，通过自研提供完整的、准确的，能全网管理运维对象和关系存储的模型，实现了与运维系统的灵活衔接。CMDB2.0 的优势主要体现在如下三个方面：
        • 以应用为中心。建立自动化、智能化运维体系，从应用的角度规划管理各种运维场景。因此，在 CMDB2.0 的模型设计上，我们坚持以应用为中心，全面梳理和分析行内的运维对象及关系，从物理层、逻辑层和应用层几方面分层构建模型。
      • 重视系统的灵活性和可扩展能力性。
        • CMDB2.0 一方面需要提升配置模型的管理能力，即快速灵活的实现模型随着业务变化而调整、修正和扩展，满足各个运维团队对于配置数据的深度和广度的需求；
        • 另一方面，也需要提高配置数据的易用性，帮助用户或其他运维系统便捷、高效地查询和引用 CMDB 数据。在这个思路下， CMDB2.0 管理平台具备如下 6 个方面功能特性：
          • 配置模型动态扩展：在线动态定义配置项，以及配置项的属性、关系、数据类型、唯一性、组合关键字等；
          • 定义多维度查询：支持在线自定义多项配置数据联合查询，以及全站检索；
          • API 接口动态生成：支持在线定义 API 接口，支持在线测试、验证接口准确性；
          • 细粒度权限管控：实现行级列级的数据权限控制；
          • 多维度日志查询：全站数据变迁的历史追溯；
          • 版本基线比对及回退：支持配置模型版和配置数据的版本基线比对及回溯。
    • 问题
      • 随着外围系统对 CMDB2.0 的依赖越来越大，系统间调用关系越来越复杂， CMDB2.0 各模块耦合高：一个服务节点同时支持规则、审计，报表、接口等功能，如果一个功能点异常可能会影响整个平台服务。
  • 3.0
    • 特点
      • CMDB3.0 进行了微服务架构升级，把系统接口调用、web 用户访问，规则处理、数据处理等按功能模块抽离成单个微服务应用，使用 Dubbo 框架进行微服务治理，另外 3.0WEB 前端是基于 VUE 自研的框架，改善了用户体验，提高了团队开发协作能力，降低了开发风险。
  • 总结
    • CMDB 的系统设计思路：多维度确保数据的准确性
      • 建立数据生命周期管理，自动化流程驱动数据更新
        • CMDB2.0 在建设之初，就定义了每个配置项从生产、运营、消亡的整个生命周期，并通过设计与之匹配的 ITSM 流程自动化驱动生命周期状态流转，实现了数据闭环管理。同时，识别每个阶段会影响的属性及关系，保证配置模型的完整性。
      • 与多个运维工具对接，促进数据消费，提高数据流动性
        • 基于灵活 API 服务，微众银行 CMDB2.0 已实现与 ITSM、监控平台、容量平台、应用发布平台、基础科技工具平台以及智能化运维平台等系统对接。用一个子系统从设计态到运形态的整个生命周期为例，展示数据联动的消费及流动过程如下。
      • 通过规则校验以及人工审计确保及时发现和修复异常数据
        • 为了保证数据准确性，通过规则校验、系统之间的信息同步比对以及人工抽样审核的方式的定期审计。持续检视和优化生命周期管理，不断改善数据质量。微众银行关键配置项准确率达到 99%以上。
  • 未来展望
    • 驱动业务流程：CMDB 为各业务流程提供高质量的配置数据，所有业务系统架构设计、资源申请、上线部署和运行维护等流程，均是通过 CMDB 与多个系统的协同运作来驱动落地。当前仅 ITSM 系统中对接 CMDB 更新或查询数据的流程已超过 200 个。
    • 服务数据化运营：支持服务容量规划、成本核算、业务运营分析等场景，例如容量管理系统基于 CMDB 数据可提供业务整体资源利用率数据和各业务使用量数据分析报告。
    • 支持智能化运维：基于 CMDB 数据关系，通过监控系统端到端视图辅助故障诊断定位、根因分析，使故障快速恢复和及时发现，已成功实现了对我行智能化监控系统这种复杂需求场景的有效支持。
• 交易链路的生成
  • 将原始消息转化为消息对：两个子系统之间的一次调用包含两条消息（一次请求，一次回复）
  • 消息对转化为树节点：
    • 首先需要将消息对中的属性进行预处理，如某些属性缺失可以通过 CMDB 中的信息进行补充。
    • CMDB 中还保存有完整的子系统与其提供的服务响应的对应关系，而在消息对的 req_message 中详细记录了调用哪个子系统的哪个服务，基于此对应关系，我们可以得到所有可能的下游节点。
    • 根据消息对中的 rsp_message 及一定的规则引擎，我们将消息对转化为了树节点。依据调用的响应方，可能会生成多个 tree node
  • 树节点转化为链路
    • 首先要选取一个根节点，然后寻找下游节点依次拼接。
  • 合并链路生成交易树
    • 首先对每条链路进行预处理。如果同一条链路中上游节点的接收方属性和发送方属性相同，则表示自己调用自己，做合并处理即纵向合并（调用自循环）
    • 接着对于不同的链路进行处理，如果不同的链路中存在上下游属性完全一致的情况，意味着具有相同的父链路，做合并处理即横向合并。

异常检测

• 指标异常检测
  • “微众银行智能监控系统识图模块”是针对业务四大黄金指标而设计的智能曲线异常检测系统。
    • 交易量(业务实时产生的交易量)
    • 业务成功率(业务成功量/交易量)
    • 系统成功率(系统成功量/交易量
    • 平均时延(交易的平均耗时)
  • 识图的检测方法主要有三种：
    • 基于 LSTM 与高斯分布的检测，这个算法主要用于交易量和时延的检测。大部分的曲线突变都能准确检测到，但算法的死角在于小幅度长时间的缓慢变化容易被漏掉。
      • 特点
        • 曲线预测：通过LSTM
        • 异常判断：通过 实际值与预测值的差 的高斯分布，来寻找阈值
      • 缺点
        • 对于幅度较小，延续时间较长的异常识别能力较弱，主要的原因在于 LSTM 的预测线跟得太紧，一旦异常持续时间稍长，预测线会被带偏，这个时候基于 LSTM 和高斯分布的检测的方法就失效了
    • 基于 k-means 算法的特征检测，主要用于填补第一种算法的盲区,在交易量缓慢变化的案例效果较好。
      • 提取了四个重要特征：均值、斜率、零值率、一阶差分的均方差
        • 指标为中高频指标时，均值、斜率在缓慢变化的异常中会体现较为明显
        • 当指标为低频指标时，零值率、一阶差分的均方差更为明显
    • 基于概率密度的检测，主要用于业务成功率和系统成功率的曲线，因为成功率曲线的背后隐藏着无数的可能，需要用一个更接近本质的量来衡量异常的程度。
      • 前两种算法对成功率曲线检测效果不好的原因是，单独一个成功率的值并不能体现出它背后的所有可能
        • 该业务日常成功率为 95%。如果当前发生 1 笔交易，失败了，那么当前成功率是 0%，按照过往规律计算，这是可能发生的，说明不了问题。但如果当前发生 30 笔交易，失败了 15 笔，当前成功率是 50%，但按照过往规律计算，这几乎是不可能事件，极大可能是异常。如果不结合交易量来检测，我们会以为这个 0%比 50%更接近异常，但事实并非如此。
• 日志聚类及相似度检测

根因分析

• 技术路径
  • 专家系统 — Drools
    • 原因
      • 首先，“业务异常”的数据是“小数据”。正常的公司运营过程中，真正影响业务的异常事件数据本身就会很少，数据累积的速度会很慢。在“小数据”的基础上，机器学习在根因分析方面的应用相对有限。
      • 其次，“根因分析”是需要有较强的解释性的，每次业务异常后，运维工程师都会有完整的异常事件分析报告，机器学习在可解释性上相对较弱，而专家系统能更好的解释根因是如何分析出来的，更符合人类的思考逻辑。
      • 最后，利用人类专家“举一反三”的能力，可以短期内构建出根因分析系统。
    • 问题
      • 首先是数据不透明。每一次异常发生过后，我们都需要检视根因分析是否正确。
        • 如果根因正确，那么就需要向团队内同步是基于什么样的数据和推理逻辑推导出根因的；
        • 如果根因错误，则需要检视是否存在数据缺失、推导规则错误等问题。
        • 复盘就需要依赖当时获取到的异常数据来开展，原先我们把数据都放在 TDSQL 内，彼此之间相互不关联，所以复盘时这些数据都是碎片化的，数据透明程度差，复盘也相对困难。
        • 后来引入了图数据库，将异常数据以知识图谱的方式来存储，即方便查询，也方便展示。
      • 规则维护困难。
• 知识图谱
  • 方法论
    • 数据采集维度
      • 事件：异常事件的起点，包含了异常事件的相关信息，例如事件的开始时间等。
      • 指标：产品的关键指标，我们选择了四种类型的指标作为黄金指标，用于检测产品业务是否异常，每个场景都有其对应的黄金指标，其中包括：
        • 交易量：单位时间内的交易笔数。
        • 业务成功率：单位时间内的业务成功率，业务失败时该指标会下降。业务失败是指符合业务逻辑的失败，例如验证码未通过。
        • 系统成功率：单位时间内的系统成功率，系统失败时该指标会下降。系统失败时指系统内部的失败，例如连接数据库异常。
        • 时延：单位时间内完成交易的总耗时时间。
      • 业务流水：用户在产品上操作所产生的编号，每一次操作都会产生一个唯一的编号，也称为一笔交易。这个编号可以关联出业务日志和实时树日志（WEMQ 日志）。
      • 业务流水日志：每个系统按照规范打印的业务相关日志，可以从中查到具体的业务参数和相关调用信息。除了业务相关的信息外，日志中还有交易发生的子系统、主机、DCN 等信息。
      • 实时树日志：之前提到的 WEMQ 日志，可以将交易的完整调用路径分析出来，其中还有经过的主机、耗时等明细数据。
    • 根因定位阶段，该阶段根据收集到的日志数据，对交易进行统计分析，并定位到哪个子系统、主机才是本次事件的根因。
    • 根因补充阶段。这个阶段会采用告警、变更等数据来进行分析，并对根因进行补充。如果定位到一个子系统存在异常，该子系统如果还存在告警、变更等数据的话，就会进一步的补充到根因内，使得根因更加具体、明确。
  • 事件指纹库：构建异常案例的“博物馆”
    • 一个完整历史案例对比过程包括以下三个步骤：
      • 异常事件的特征（事件指纹）的选取
      • 异常案例在知识图谱中的存储和更新的方案
      • 基于指纹权重的异常案例匹配算法
    • 历史事件对比流程
      • 事件发生
      • 推送告警群
      • 定位与标记
      • 结构化事件
      • 更新特征指纹库
      • 新事件的相似匹配
      • 推送告警群
    • 根因的定位来源分为了七个方面：日志、告警、接口、应用版本发布、SQL 操作、非应用版本变更和推广活动。每个维度，都会产生唯一的事件指纹，用以代表该异常发生时我们所能观察到的 root。

挑战和应对之道

• 挑战 1. 及时性和准确率，如何平衡？
• 挑战 2. 算法和经验/规则，哪个更有效？
• 挑战 3. 实时数据和历史数据，哪个更可信？
• 挑战 4. 当掌握全面的信息时，如何聚焦到有用的信息上？