宋斌 美团一站式业务稳定性保障平台的 AIOps 实践

QCon大会

2019/06/25 发布于 技术 分类

QCon  QCon2019 

文字内容
1. 美团配送稳定性保障平台的 AIOps实践 宋斌 资深技术专家
3. ⾃自我介绍 宋斌 美团-美团配送资深技术专家 • • • • • 09年硕士毕业,13年加入美团 美团配送后台技术负责人、负责后端系统、履约平台、稳定性建设 全程参与美团外卖、美团配送的建设和演进 Tag:业务团队的技术架构、系统运维、无边界工程师 SET化、分布式系统架构、AIOps、高性能引擎、稳定性保障、清结算、LBS
4. ⽬目录 1、什么是AIOps 2、为什么要AIOps 3、如何搭建智能运维的能力 4、美团配送的实践 5、机器学习能力的探索
5. 什什么是AIOps Gartner 2016 : AI + ops + data,用数据+算法解决IT问题,替代传统运维
6. 为什什么要AIOps ⽤用户⻆角度的美团外卖配送 RD⻆角度的美团外卖配送
7. 为什什么要AIOps
8. 为什什么要AIOps 传统运维 智能运维 保障系统各环节运行流畅,以快速解决问题为目标 聚焦业务,提升业务运行稳定为主 • • 关注用户体验 • 关注业务核心指标 • 强调SLA、MTTR • 深入业务链路拓扑 • 1个人运维几百个服务、几十个DB集群、几千台vm • 善用数据、挖掘数据 网络监控 • 硬件监控 • 系统监控
9. 如何搭建智能运维的能⼒力力 实施准则 • AI只是辅助手段 • 更适合大规模业务、服务、集群的运维 • 关注ROI、实验和实战才能结合好 • 运维数据、经验的积累,会极大的影响AIOps的效果 • 无人值守的运维,是AIOps的最后一公里(L5) • AIOps是趋势,是浪潮
10. 如何搭建智能运维的能⼒力力 组织架构 客户(业务RD、QA、技术leader……) 运维⼯工程师 运维研发⼯工程师 AI⼯工程师
11. 如何搭建智能运维的能⼒力力 Gartner发布AIOps平台市场指南
12. 如何搭建智能运维的能⼒力力 平台能力
13. 美团配送的实践
14. 容量量评估 传统的静态评估 • 存在的问题:评估模型不合理、线性评估不客观、单点评估不准确 基于压测流量的动态评估 • 结合线上真实系统的客观评估(真实的服务器、真实的流量、真实的数据、真实的环境) • 评估结果比静态评估更客观可信 • 自动化程度高,评估成本相对较低 • 集群整体评估,更容易发现容量瓶颈 • 评估过程,更符合业务的特点
15. 容量量评估 流量构造 =》 线上施压 =》指标监控 =》报告分析 • 流量构造:压测请求、影子数据、流量染色、流量隔离 • 线上施压:压力控制、压测风险防控 • 指标监控:入口流量指标、系统性能指标、核心服务指标、AA对 照 • 报告分析:目标压力是否达成、存在的风险及TODO • 置信度、覆盖率、压测成本、压测频率
16. ⻛风险预测 什么是风险? 风险是指在某一特定环境下,在某一特定时间段内,某种损失发生的可能性。换句话说,在某一特定时间段内,人 们期望达到的目标和实际结果产生的距离称之为风险。 ⻛风险 ⻛风险因素 ⻛风险事故发⽣生的潜在原因,是造成事故的内在或间接原因 ⻛风险事故 是造成事故的直接或外在原因,是损失的媒介物, 既损失只有通过⻛风险事故的发⽣生才能造成损失 ⻛风险损失 ⾮非故意、⾮非计划、⾮非预期的经济价值的减少,按形态可以 分为直接损失和间接损失
17. ⻛风险预测 静态风险 动态风险
18. ⻛风险预测 解决什么问题? 线上变更引入的风险、偶尔发生的波动风险、累积的潜在风险; 通过识别风险,然后进行提前干预,避免线上故障 常用的手段:服务周期性巡检、发版巡检 • • • • 选取合适的指标,Google黄金指标 设定抓取数据的时间段、同比、环比、固定阈值 设定触发的时机,比如:服务发版完成后5min 建立高危风险策略库,比如:慢查询、缓存大key大value等,偶尔发生就提早防控
19. ⻛风险预测 巡检结果不准确 • 固定阈值-》动态阈值; • 单一指标判断风险不全面,多指标联合分析判断是否真的风险 • 固定服务巡检时间,不能满足多业务形态(A业务峰值在中午,B业务峰值在凌晨……)
20. 故障识别 故障识别 = 故障检测 + 根因定位 传统报警监控下,RD对故障识别的痛点: • 无需关注的报警多,RD对报警敏感度下降 • 真正故障时,报警风暴(多源、多维报警) • 需要长期维护报警阈值,容易年久失修,还不容易准确 • 传统故障报警,只回答”故障长什么样“,没有回答”故障是什么,根因是啥“ • 需要人工基于经验排查,故障发生时,排查时长不确定,排查能力不可复制
21. 故障识别-WHY 缺少系统化的手段辅助研发人员快速获取关键信息 链路路关系复 杂,故障范围 难以确定 故障相关信息 分散,⼈人⾁肉分 析根因慢且难 研发⼈人员 故障的根因是什么? • 故障的影响范围? • 我们有哪些处理手段? 故障的处理理速 度严重依赖研 发⼈人员的技术 素养 报警⻛风暴暴,难 以获取有效信 息 报警阈值⼿手动 维护,准确性 难以保障 容灾⼿手段和故 障缺少关联, 查找困难导致 ⽌止损慢 • 影响 MTTR缩 短的主要 因素 缺少系统化的手段辅助Leader去review故障信息 ...... 管理理⼈人员 • 故障发生的次数 • 故障的处理时间 • 故障的根因分布和重复发生频率 从不不同的⻆角⾊色来看,⾯面临的问题也是不不⼀一样的
22. 故障识别-WHAT 实现故障⾃自愈 MTTR < 5分钟 ⾃自动分析定位
23. 故障识别-HOW 产品核⼼心功能 运营管理理 链路路监控 根因分析 故障收敛 故障管理理 故障拓拓扑 告警升级 预案推荐 故障标记 辅助研发快速处理理故障 产品运营 基础⽀支撑功能 数据抓取 机器器学习 ⾃自动化测试 ⽬目标⽤用户 研发⼈人员 故障运营 辅助管理理MTTR和MTTF 接⼊入管理理 基础运维平台 CAT OPS DBA平台 故障跟踪 Falcon Squirrel 告警中⼼心 TT反馈 管理理⼈人员
24. 故障识别-HOW TP99监控 接 ⼝口 监 控 • 服务端监控 • 性能(TP99)监控 • 静态阈值 服务 对外接⼝口1 • 静态阈值难以维护 • 误报多,治理理困难 对外接⼝口2 • 报警有效信息少 • LOF+四分位法+兜底阈值多算法 组合 • 错误分布判定规则 对外接⼝口3 • 算法数据排除故障期间数据 • 监控服务调⽤用的失败率,真实反映系 统问题 失败率监控 链 路路 监 控 • 基于LOF算法的异常检测 • 端到端链路路监控 • 失败率监控 • 动态阈值 服务 依赖接⼝口1 依赖接⼝口2 依赖接⼝口3 • 基于历史数据和异常检测算法进⾏行行异 常判定,减少误报 • 针对不不同链路路类型使⽤用不不同规则,减 少⽆无效报警 服务 异常检测除了了算法还依赖⼤大量量的规则 • 失败率和QPS的指数模型 • 消除1分钟失败率抖动问题 • 故障持续的判定算法 • 服务和数据库链路路基于异常类型 的异常检测优化 • ⾼高失败率不不屏蔽原则 • 新上线服务的失败率兜底⽅方案 • ……
25. 故障识别-HOW • 服务:循环调⽤用、异常堆栈 纵向分析的主要指标 • DB :慢查询、慢查询分布 • 告警:流控、鉴权等 • 变更更:发版、配置 纵向 分析 • JVM :GC时⻓长、GC次数、线程blocked • 容器器:错误分布、宕机 根因 服务 • ⽹网络:单机⽹网络、跨机房⽹网络、专线延迟 横向 分析 根据链路路调⽤用关系逐层递归,到中间件为⽌止 服务A 服务B 服务C 中间件
26. 故障识别-HOW 告警链路与已标记的告警链路相同 与已标记告警根因集群相同 链路终节点与已标记告警终节点相同 链路终节点是已标记告警的始节点 链路始节点是已标记告警的终节点 链路始节点与已标记告警始节点相同 告警链路路类型 基于故障链路路,以故障根源服务为根节点,构建故障拓拓扑树,故 障收敛信息主要包含以下三⽅方⾯面内容: 基于链路路监控的告警信息进⾏行行收敛 服务A 服务B 服务D 故障链路路拓拓扑 服务C 服务E 服务F • 故障根因 • 影响范围 • 持续时间 服务H 故障根源节点 中间件G
27. 故障识别-HOW 链路路监控 通知 − − − ⼤大象 短信 电话 产品研发 根因分析 故障处理理主界⾯面 − − − − 链路路监控准确率:通过⽤用户标记,持续优化 故障收敛 故障根因 影响范围 降级⼿手段 产品优化 故障拓拓扑 研发⼈人员 产品运营 − 故障定位成功率:通过⽤用户标记,持续优化 − 故障召回率:故障诊断发现的故障 / 实际发⽣生故 障 容灾推荐 故障恢复 运营报表以组织粒度进⾏行行统计, 每周SRE周会进⾏行行公示和追问, 督促各组负责⼈人进⾏行行持续优化 − 降级MTTF − 降低MTTR 管理理⼈人员 ⽣生成复盘和运 营的case 故障案例例 − 故障发⽣生次数:周、⽉月、半年年、年年 故障运营 − 故障处理理时⻓长:平均故障处理理时⻓长 < x分钟 − 故障发⽣生原因:根因分布、重复发⽣生次数
28. 故障识别 收益 • 定位时间:15min -> 5s • 线上事故覆盖率:80% - > 96% • RD 运维成本:配置阈值、校准阈值、大量报警、人工分析 -> 0成本分析
29. 弹性建设 2012年,Netflix首先通过实践 chaosMonkey来探索弹性能力建设,后来发展为一系 列的猴子军团 弹性能力的建设,需要通过攻防演练,验证弹性能力的有效性、全面性 攻:混沌工程,随机制造故障 防:弹性工程,容灾容错能力的手动、半自动、自愈能力 混沌工程:实施原则,重要的是一定要控制好最小爆炸半径 弹性工程:完备的弹性工具,结合业务做好弹性能力的覆盖,通过混沌工程的实验,不 断补齐和完善弹性能力
30. 弹性建设 弹性建设的目标: 提升系统在应对故障时候的弹性能力,来让系统能快速从错误、灾难中恢复 弹性能力分层 低 代码逻辑 接⼝口 故障影响 服务 ⾼高 IDC 城市 弹性能力分类: 容灾能力、容错能力
31. 弹性建设
32. 美团配送的实践 AIOps的落地误区 • 大数据+机器学习,复杂的预测算法+模型,才是AIOps • 有了学件、组件、服务、能力、平台就落地了 • 只有运维团队需要落地Ops • 只有机房、网络、硬件等问题才需要Ops
33. 技术运营 做好技术运营的重要性 如何做技术运营 • 定义度量指标:MTTR、准确率、召回率…… • 建立运营机制:风险排行榜、每周事故风险复盘、典型案例分析、TODO跟进 • 风险的及时响应和跟进 • 故障告警分级、通知、升级
34. 机器器学习能⼒力力的探索 • 自主的风险预测 • 多维的根因关联分析 • 智能的容灾推荐