哈啰稳定性建设演进之路
哈啰 - 孟闯
关于我
孟闯
10余年互联网行业研发经验，主要从事后端系统研发，擅长高并发系 统，高可用架构设计
2015年加入哈啰，参与多个核心系统从0到1的建设过程
最近2年主要在做稳定性相关工作，现任哈啰技术风险负责人，负责 全局系统稳定性建设
技术风险整体框架
影响稳定性的因素
- 业务发展: 业务体量从小到大，系统压力变大，逻辑变得复杂
- 人员意识: 风险意识不足，对稳定性重视程度不够，缺少经验
- 外部环境: 运营商网络、第三方外部接口、机房环境
- 系统设计: 架构设计不合理，健壮性不够，缺少容错设计稳定性
- 技术升级: 发展过程中引入了新的技术，带来收益的同时伴随着风险
我们面临的挑战
- 业务 迭代快
- 人员 组织大
- 技术 系统多
- 标准 要求高
应对策略
- 分而治之: 先解决主要矛盾，区分 核心与非核心，成熟型 业务与发展型业务
- 技术升级: 坚持以技术手段来解决问题，包括演练、压测、 巡检等
- 流程规范: 使用流程规范来约束人的行为，对工具进行补 充，制定红线与军规
- 权责明确: 设立稳定性架构师角色， 明确责任，保障稳定性的人力投入稳定性策略
- 持续运营: 避免运动式治理，通过稳定性运营机制持续推进稳定性提升
技术风险发展过程
- ~ 2018 点状治理
- 2018 ~ 2019 重点项目
- 2020 ~ 体系化
技术风险组织形式
- 组织职责
- 稳定性建设目标、标准、规范制定
- 工具/平台建设，通用能力沉淀与输出
- 稳定性基线，牵引业务线稳定性能力提升
- 核心理念
- 保障业务连续性是首要目标
- 让风险可量化可治理
- 坚持以技术手段优先来解决问题
目标拆解 - 稳定性目标
- 降低故障发生概率: 99.99% 提升MTBF
- 故障预防能力
- 故障隔离能力
- 降低故障影响范围: 5-5-10达标 缩短MTTR
- 故障发现能力
- 应急处置能力
能力框架
最佳实践 - 依赖治理
依赖治理 - 复杂的调用关系: 网关 -> 系统 -> 存储
依赖治理 - 应用分级: S1(最核心)-S4
依赖治理 - 治理原则
- 明确强弱依赖
- 熔断降级限流
- 避免核心单点
- 治理共同依赖
依赖治理 - 长效机制 如何保证依赖关系的合理性是长期有效的?
- 研发流程
- 高可用平台
- 混沌工程
- 巡检平台
最佳实践 - 大促保障
大促保障 - 大促特点: 大促保障与日常保障的关键区别是流量差异，大促一般具有时间短、流量大、营销玩法丰富的特点
大促保障 - 保障细节
大促保障 - 关键思路
- 组织保障
- 全链路压测
- 封网管控
- 应急机制
最佳实践 - 故障演练
故障演练 - 整体框架
- 线下 - 依赖关系演练 重在检验各项依赖关系的合理性
- 线上 - 应急演练 常态化预案演练、专项演练、大促演练等
- 线上 - 攻防演练 无预告突袭式演练，以战代练
故障演练 - 故障处理过程
故障演练 - 关键思路: 故障演练的目的，不止是检验系统某个维度的稳定性，更是在验证稳定性建设的综合能力，包括预防能力、发现能力、定位能力、应急处置能力等等
- 人员: oncall值班 稳定性意识
- 系统: 依赖合理 容错降级完善
- 工具: 监控告警有效 排障工具有效
- 流程: 预案完整 应急协同有效
故障演练 - 落地方式
- 考核方式
- 运营机制
- 基础能力
稳定性运营机制
稳定性运营 - 背景: 如何避免「运动式」治理 如何巩固稳定性建设成果
风险大盘 - 稳定性模型
- 安全生产
- 故障演练
- 服务治理
- 研发过程
- 全链路压测
- 监控告警
风险大盘 - 量化机制: 稳定性大盘
稳定性基线: 技术风险统一牵引 -> 稳定性基线
- 研发过程
- 架构治理
- 监控告警
- 容量治理
- 混沌工程
- 应急响应
- 故障管理
持续运营机制
- 风险大盘(存在哪些问题，为什么要做) 稳定性周/月报
- 稳定性基线(有哪些手段，如何去做) 基线评估 差距分析
- 稳定性文化(提升人员意识，自发去做) 稳定性竞赛 稳定性考试
总结规划
内容总结: 稳定性整体框架 -> 依赖治理 大促保障 混沌工程 -> 持续运营
建设路径: 定目标 -> 拆过程 -> 建能力 -> 落机制
