民生银行的科技发展趋势

应用运维的定位

• 应用系统的全生命周期管理
• 应急处置第一责任人
• 承上启下
  • 对外作为运维部门面向业务和开发的窗口
  • 对内协调运维各条线完成业务服务

面向业务部门

• 沟通协调业务需求
• 同步业务运行情况
• 系统架构 续性管
• 优化提升业务流程

面向开发测试部门

服务请求 上线交付 三线支持 工具建设 架构评审 设计评审

面向运维内部

• 系统管理网络管理运行监控
• 运维内部组织协调主要力量(流程+项目+系统)
• 应急处理第一责任

民生应用运维的原则：基于SRE理念

• 对应用系统的可靠性负责
• 员工多面手，80%的员工具有开发经验

对服务质量负责

• 服务分级
• 驱动运维其他部门
• 服务依赖

以发现问题为荣

• 鼓励推动业务流程优化
• 鼓励发现系统隐患
• 鼓励建立问题工单

琐事与工具观

• 工具和琐事的跷跷板效应
• 好工具不是规划出来的

优先恢复

• 详细事件报告
• 根因分析
• 规避总结

问题跟踪

• 角色定位明确
• 应急预案规范

应急管理

• 以恢复生产服务为第一要务
• 十分钟定位问题，十分钟解决问题

应用运维面临的挑战

• 故障处理困难加大
• 运维数据亟待挖掘
• 运维价值难以体现

业务创新

• 产品推陈出新
• 流程优化改进
• 注重客户体验
• 要求快速响应

场景

• 直销银行
• 新零售信贷
• 小微3.0
• 远程银行

技术演进

• 新架构
• 新技术

场景

• 分布式核心
• 微服务与服务治理
• 容器云平台
• 大数据人工智能区块链|生物识别

运维支撑

• 虚拟化
• 云平台
• 服务治理

场景

软硬件数量激增：7000+操作系统 应用和架构复杂化 频繁的变更操作： 调用链显著加长：最长17次调用 运维数据井喷：日志每日20T，监控指标百万/分钟，交易明细数亿/天

故障定位难题

基础资源异构性

• 新老结构并行
  • 新系统一套架构 老系统一套 标准化做的不好
  • 合作的方式开发、买过来的、自己开发的 很难去标准化
• 双栈运行

应用架构不统一

• 标准化程度低
• 无法共享和复用

频繁的变更发布

• 应用集成关系频繁变更
• 新业务新流程不断新增
• 影响分析难以准确
• 各条线协作困难

调用关系错综复杂

• 网状调用关系
• 难以厘清故障系统

严重依赖专家经验

• 运维专家具有处理经验
• 专家经验难以复用

运维数据井喷

• 数据分散在各专业工具中，数据孤岛
• 专业条线之间难以协作，数据难以共享
• 海量数据人工无法快速分析

智能运维的架构设计

底层是运维对象层

• 真实物理机
• 云
• 机房
• 网络设备
• 数据库
• 宿主机

数据源层

• 机房的监控
• 网络监控
• 交易监控
• 存储监控
• 日志采集
• 流程管理
• 运维工具

将数据接入到智能运维平台

智能运维平台

• 数据统一采集 进行数据治理
• 数据加工
• 数据存储
• 引入一些智能的算法和模型
• 实时计算和离线计算

然后推给上层的展示

展示层

• 统一展示

应用场景

• 质量保障
• 运维效率提升
• 成本优化

运维数据治理

• 不断的摸索和迭代数据摸底
• 编译出数据标准 格式 字段
• 经过配置采集自动化 保证数据的准确
• 采集的数据 进行人工分类 28个数据模型
• 优化和反馈 不断的提高数据的质量

一横一纵故障定位

最上层是系统间的调用关系 服务的调用关系即交易路径 先从交易路径层面 确认是哪个系统

常见故障类型的总结

组件性能问题

• 现象：数据库、中间件性能不足
• 原因：交易量大，应用使用不合理、组件参数不合理等

基础设施故资障

• 现象：网络、存储、宿主机等底层资源故障
• 原因：硬件故障，变更操作 评估不到位等

调用链路问题

• 由一套系统/服务引发了多套系统/服务故障

应用逻辑错误

• 设计缺陷、代码缺陷、配置错误等

部分主机故障

• 现象：集群中的个别主机出现故障
• 原因：硬件故障，假死，内存泄漏，操作

部分服务故障

• 现象：部分服务异常，其他服务正常
• 原因：逻辑错误、性能问题、

第三方问题

• 依赖的外部系统故障幕共享

故障类型站占比情况

人工排障流程-应用运维视角

告警

• 触发检查的操作

影响分析

• 影响范围 全局or局部
• 影响程度 严重程度

故障传播分析

• 依赖其他的服务 由其他服务导致 或者是自己引起的
• 定界

特征分析

• 问题的数据 总结到一个具体的特征上
  • 单服务故障
  • 返回码
  • 报错来自哪里

监控指标

• 检查各监控指标是否正常

日志检查

• 检查日志有没有报错

模拟人工排障

故障发现

可用性故障发现

• 可用性指标
• 单指标异常检查

日志异常检测

• 日志模版
• 单指标异常检查

故障影响分析

影响分析

• 基于交易明细
• 使用多纬的算法 分析在什么范围 从而评估影响

根因分析

调用链分析

• 交易明细
• 基于异常算法实践

多维特征分析

• 交易明细
• 多维度异常定位

监控指标定位

• 监控指标
• 多指标异常定位
• 人工分析慢

日志模版定位

• 人工查询慢
• 日志模版+多指标异常定位

解决方案

典型事件匹配

关联分析

故障解决

处理过程示例

智能运维场景设计1-可用性故障发现

背景

• 与SRE 的核心目标一致
• 固定阈值 误报漏报多 人工维护成本高
• 故障发现要及时 无漏报 少误报

数据: 关注黄金指标

• 交易量
• 成功率
• 响应率
• 响应时间

挑战

• 简单的算法 (例如3sigma LOF 孤立森林) 只能在特定数据下 奏效
• 指标情况各异 难以设计适应所有场景的算法
• 节假日 尖峰 聚变等场景

什么样的成功率都有

算法: 单指标异常检测 基于GBRT的回归基带算法

• 智能基带 根据历史数据 预测基带数据
• 超出基带就是异常

效果

• 开箱即用 无需事先标注 节省人工
• 故障发现时更及时
• 漏报少 大小故障不放过

响应案例

智能运维场景设计2-调用连分析

找到问题到底和哪个模块相关

背景

• 调用链路不断延长
• 告警风暴
• 传统手段 解决办法类似烽火台狼烟信息共享问题 一步一步的去执行 效率低
• 统计历史事件原因，25%的事件中存在多个系统的关联影响

数据需求

• 系统级调用关系
• 服务级调用关系
• 全局统一流水号

调用连分析

构建全局调用链

• 系统为节点， 每一个点代表一套系统, 每一个箭头代表调用关系
• 调用关系
• 调用性能

异常调用剪枝

• 检测每条调用链路 正常的调用干系
• 保留异常调用链

综合排序

• 计算每个节点异常贡献度
• 给出TOP3故障系统

智能运维场景设计3-多维特征分析

背景

• 每笔交易都有很多维度组成，影响故障的维度很多
  • 地理维度 区域 机房 机柜 模块
  • 交互维度 哪个系统 服务 返回码 响应时间
  • 业务维度
• 当整体指标出现告警时(如交易量上升)，快速定位到具体的交叉维度(如渠道=手机银行&服务名=黄金购买)的异常，辅助故障定位或确定影响范围

数据

• 交易明细

场景

• 故障原因定位
  • 单主机异常
  • 个别服务异常
  • 其他维度聚合

故障影响分析

- 其他维度特征总结(错误码相同、机构号相同、源系统相同等)

特征分析:问题数据是否有特征?

智能运维场景设计3 多维特征分析

算法

• 从交易明细数据中，通过关联分析找出每个系统的关键维度(数十个)
• 整体指标出现告警时触发多维定位
• 依据蒙特卡洛树搜索算法，对各种维度的交叉情况评估，快速剪枝，找出交叉维度

优势

• 告警影响分析，缓解告警焦虑
• 根因分析，智能下钻
• 7*24在线

案例 某系统成功率低 准确定位异常来源

智能运维场景设计4 监控指标排查

背景

• 机器数量增多，监控项细分
• 报警仅针对核心指标的严重问题
• 系统特点不同，排障依赖经验
• 传统的报警 不会看cpu突降的问题
  • 关注指标的异常变化

数据

• 按照CMDB 将机器分组
  • 用户数据库
  • 业务数据库
  • 图像数据库
  • 接入层应用
  • 集成层应用
  • Redis缓存等
• 监控指标
  • 系统-模块-服务器-指标类别-实例-指标
  • xBank-业务库DB2-NAPSAP1-Disk-hdisk power 99-磁盘繁忙率

场景

• 故障定界：关注专业模块-指标类别
• 典型问题：常见的典型问题定义和识别，解决方案
• 关联分析：告警关联，SQL关联， 基础资源故障关联

要快速定位 是哪一类的指标有问题 是disk还是数据库? 然后进行更准确的定位

人工排查的特点

1.排查指标是否异常

• 多个监控工具来回切换
• 海量监控指标排查慢
• 异常指标认定无标准
• 告警风暴干扰排查方向

2.同类机器指标比较

• 人工比较主观性强
• 手工操作时间长

3.故障原因分析

• 依赖先验知识
• 依赖专家
• 依赖经验

机器排查的特点

优势

• 与人工排查的结果一致
• 不忽略长尾指标
• 大幅减少故障定位耗时

1.指标异常程度评判

• 同时评判海量指标
• 异常程度定量评价
  • 异常的波动进行量化

2.相似异常机器聚类

• 根据CMDB定义模块(数据库模块，应用服务器模块等)
• 模块内聚类，具有类似指标异常的机器聚类
  • 对每一个层次 打分、然后排名
  • 变化最大的 与故障相关的放到最前面

3.定位结果排名

• 算法排序
• 得到可能性最大的异常原因

案例 某系统响应时间增加 原因是磁盘繁忙

案例 某系统响应率和失败率下降 准确定位到异常进程

智能运维场景设计5 智能日志分析

背景

• 日志数据内涵丰富

  • 记录很多行为
  • 相当比例的逻辑问题可以从日志中找到答案
  • 应用运维工程师熟悉服务的内部逻辑，熟悉日志

• 日志挖掘难度大

  • 非结构化，无法直接分析
  • 数据量过大，人力无法完成

数据

• 已建立日志平台，日志量丰富
  • 平均每日新增15TB
  • 覆盖1715台主机，4大类操作系统，应用系统213套，9大类日志类型(应用日志，数据库日志，中间件日志，以及存储、网络、管理口、审计、容器平台、监控相关日志)

智能日志分析

日志采集

• 借助ELK天眼日志平台的通道 获取日志

日志模版提取

• 基于FP-tree的模版提取技术
• 将相似的日志 归位一类 提取常量和变量 用常量组成一个模版

日志故障发现

• 然后根据模版出现的频率进行统计
  • 转换成一个持续的曲线
  • 可以进行异常检查
  • 异常变化的提示
  • 和异常事件进行匹配
• 查看变量的分布 辅助定位

日志辅助问题定位

• 模版频率变化
• 变量分布变化

案例 某文件系统飙升 定位到具体的日志异常

• 当前的日志 比前一天的日志 多出了6 7倍
• 业务类型数据的变化 占比变化突增
  • 发现日志集中在某个业务上面

某系统成功率降低

• 定位结果：某机器无模版的日志量增加, 抽样查看主要为Too ManyFiles Open
• 原因：代码缺陷，个别服务器的文件句柄数量达到最大

某音视频类系统响应慢

• 定位结果：某类服务器的日志， UDP异常的报错增大
• 原因：音视频流量大， UDP服务繁忙

某系统的调用时间过长

多位特征分析 定位到某商户 操作某产品导致

实践感悟

智能运维不是万能的，尤其是现阶段的智能运维

• 正确的认识它 现在是一个初级阶段 还是有很多的挑战 不能给予过高的期望
• 面对的问题和数据 比较复杂
  • 常见的都是正常的数据 很少出现异常的情况 数据倾斜的问题很多
• 数据挑战：收集数据，数据倾斜
• 算法挑战：非典型机器学习问题，可解释性要求
  • 常见的算法都是面对分类问题
  • 实际运维场景往往很杂 直接利用分类的情况不多 往往要用无监督学习

管控预期，合理定位智能运维

• 替换人工流程中“难、慢、重”的部分，考AI提升效率
• 结合“场景+算法+数据"，简化应用运维的工作

数据的质量决定智能运维能达到的上限，好的算法逐渐逼近上限

• 数据的质量很重要 然后才能提升算法 从而提高AI
• 不要迷信算法，实践是检验算法的唯一真理 不要为了AI 而AI
  • 黑猫白猫，抓住老鼠就是好猫
  • 不一定通过算法 利用一些规则也可以做好

从算法Demo到产品存在巨大鸿沟

• 产品化的过程 很难 跟当前现用的流程融合起来 不要颠覆现状
• 不要尝试改变用户，而要融入日常流程

智能运维，大有可为

• 仍处于单点时代，未来将由点及面，快速发展
• 智能运维场景将逐渐从故障处理领域扩散开来，发展出更多的应用场景

QA

故障分析的数据源?

• 应用监控的数据
• 统一监控的数据 服务器 数据库 中间件 缓存数据库 进行组织编排
• 日志

和日志分析平台的区别？

• 看技术路线
• 应用系统的监控 主要是通过日志实现的
  • 通过日志 去分析服务的一个运行的情况
• AI运维 实现故障的发现和定位
  • 需要在现有数据的基础

对于基础资源的监控 如果集群中的硬件配置不同 怎么取健康值

• 不做横向的比较 只做纵向的比较
  • 这个机器平时60% 突然飙到了80% 那可能就是异常

黄金指标是怎么采集到的？

• 一个途径 基于流量定向分析的工具
  • 生产的流量镜像一份 网络抓包的数据进行解包
• 自主的开发平台 进行APM的操作

  • 输出黄金指标

降低维护的难度和复杂度 提高维护性?

监控的工具多 数据也很多 如果各自玩自己的话 数据无法共享 没有协作

• 数据集中起来 一起利用
• 各个团队去消费数据
  • AI运维面向故障
  • 运营面向可视化

日志异常检测的模版数 会比较多 会进行一些筛选过滤的环节 只把关心的日志模版接入进来

• 容量预测算法
• 告警压缩算法

周期性指标的异常检测

• 异常检测的时候 使用了回归的算法 会把周期性的问题考虑进去

收集规则和建模规则

• 和数据的采集有关
• 多源异构的数据 使用这些数据之前 要有梳理成标准数据的一个过程(数据治理)
• 收集上来的数据 先进行数据清洗

不同指标的相关性

• 后续异常定位的时候 会引入这样的一个考量
• 某几个指标 从关系的角度 做关联