稳定性建设实践分享
![稳定性建设实践分享](https://static001.geekbang.org/infoq/b9/b99db166e16cc0ec08f6af5594205d23.jpeg)
本文介绍了稳定性建设实践相关的内容。介绍了稳定性保障组织建设,交付流程的稳定性保障,线上稳定性保障的措施,研发效能的提升,团队建设等方面的内容。介绍了简化复杂的事情,标准化简单的事情,流程化标准的事情,自动化流程的事情的重要性。同时也提到了推动落地的方法和向上管理、横向协作的重要性。
1、职责
所在组织结构:团队成员 40 人左右,业务特点:有大量老服务、流量波动大(峰值集中在中午和傍晚)、流量不可预测。
背景:以业务发展为主,对稳定性关注较少,各项目使用的规范和工具不一致,近两年平台出了几次事故,开始重视稳定性建设,成立稳定性保障小组,推动稳定性工作。
稳定性小组的组成:
![](https://static001.geekbang.org/infoq/4c/4c08de5a8ae8d6ee367c37637758aa02.png)
稳定性保障小组:各团队抽调人力成立的一个虚拟小组,负责团队内部的任务推动
QA:负责上线前各流程的规范及检查,负责流水线建设、事故定责
SRE:负责线上问题的跟进
Leader:本部门内的稳定性工作负责人
安全生产委员会:负责事业部内安全生产相关规范、配合公司级事项推动、协调外部资源
职责:
稳定性保障小组这个名称其实不是特别准确,后续又承接了很多其他的横向推动的任务,主要包括三大块:
稳定性保证:分为上线前保障和线上保障
研发效能:规范制定、流水线建设、环境建设等
降本增效:提升资源利用率
时间分配:
组长:50%左右
稳定性保障小组成员:10%左右
2、交付流程稳定性保障
整体流程图:
![](https://static001.geekbang.org/infoq/a4/a42b91a25119892b13564c0c89ce5e5c.png)
(1)方案设计规范
超过 3PD 的需求需要写方案文档同步到小组群,超过 10pd 的需求需要小组内评审。
(2)代码规范
禁止提交 master 分支【强制】
分支规范【强制】
参考:Commit Log规范
(3)流水线建设
静态代码检查
团队之前没有静态代码检查,存量代码中存在大量的待解决问题,卡控应先卡控增量代码,然后逐步提升全量卡控比例;
单元测试
大部分代码没有单测,且很多跑不通过的单测。治理过程:(a).修复跑不过的单测;(b).流水线检查单测必须跑通过;(c).引入单测规范;(d).卡控增量代码覆盖率、单测必须有 assert;(e). 卡控全量覆盖率
Git 治理
master 分支权限治理:只有组长有 master 权限
merge 卡控:流水线跑通过才能 merge
merge 卡控:不能 merge 自己提的 pr,必须有至少有 2 个人 review 通过才能 merge
merge 后自动打 tag,并用此 tag 发布线上
(4)上线规范
工具: 上线变更平台
每次发布、配置变更、数据变更都需要使用上线变更平台发起申请单,并通过二层审批
上线记录到 checklist 文档
需求:PRD、任务地址、需求发起人
代码 PR 地址
配置项
上线顺序、依赖
上线检查截图
回滚方案
(5)交付流程观测指标
代码量
静态代码达标率:有问题的代码量/所有代码量
静态代码 Blocker, Critical 数量
单测通过率:治理过程中的临时指标
单元测试新增覆盖率:merge 到 master 时统计新增代码
单元测试全量覆盖率:定时统计
千行代码 bug 率:QA 测出的 bug 数/代码行数
回滚次数
3、线上稳定性保障
![](https://static001.geekbang.org/infoq/a4/a42b91a25119892b13564c0c89ce5e5c.png)
(1)事故预防
1. 运维基础能力建设
a.上下游机器配置平衡
b. 负载均衡
RPC 服务流量均衡:RPC 流量路由策略设置成同城市优先分组,对性能要求高的可以设置成同机房优先
DB 流量均衡:Mysql、Redis、MQ 跨城市严格隔离,大流量同机房优先
c. 机器利用率:治理资源利用率太多的应用,及时扩容
d. 弹性伸缩容接入(基于 K8S)【核心服务强制】
检查机制:基础数据通过大盘报表查看,各平台零散数据通过爬虫爬数据,再输出报表
2. 服务治理
a. 服务提供者治理:C 端必须有接口限流
b. 依赖资源治理:C 端核心依赖必须有熔断、降级 【强制】
治理 MQ、Redis 等资源 QPS、容量情况
DB 治理:禁止跨业务引用 【强制】
慢查询治理
c. 风险治理:公司基建,风控推动等
d. 报警治理:P0+P1 报警,每个问题都必须跟进,如无必要报警,调整报警策略 【强制】
检查机制:规范+周会同步
3. 系统能力预估
a.压测 【强制】
公司工具:Trace 链路追踪、Mock 工具、影子表工具等
稳定性小组做的事:
以上几种能力的接入:划分核心服务、核心接口、读写分类,上下游通过确认等;
组织压测,压测后有压测报告
b. 故障演练【强制】 工具:故障演练平台
上下游限流、降级演练
fullgc、cpu100%、宕机等演练
报警 SOP 演练
业务开关演练
4. 业务梳理及风险排查
梳理稳定性问题,包含以下几部分:
a. 核心服务稳定性梳理:代码走查、风控接入等
b. 线上线下行为不一致治理:代码里有大量 ifelse 不同环境走不同逻辑
c. 资损专项治理:接口幂等、对账等
(2)事故发现 &排查
1.原则:可观测性(Observability)
![](https://static001.geekbang.org/infoq/8f/8f08b2dcfe511bb479aacfd269a8c62b.png)
2. 工具
a. Metric:跨服务调用链路追踪
基础组件:上层中间件支持如 RPC 框架、HTTP 客户端服务端、MQ、定时任务框架等。如果没有链路标识,则自动添加链路标识
b. 日志
通过监听 slf4j 日志,上报到日志中心并通过 ES+Kibana 提供查询能力
c. 指标
后端指标统计、大盘建设、报警(阈值报警+智能报警)、前端指标统计等。
常见的指标类型有:
Count:用来记录一件事发生的次数,只有数量
Micros:记录一段代码的执行时间和次数,有平均耗时、TP90、TP99、TP999、最大、最小耗时、次数等详细信息
3. 多维度监控、报警
a. 监控
监控建设金字塔:
![](https://static001.geekbang.org/infoq/01/01a650d3169e83b297b4a73a4ef697c5.png)
基础平台监控、中间件监控:公司基础组件自动上报
应用监控:公司基础组件自动上报,比如接口粒度 QPS、响应时间、JVM 信息等
业务监控:需要后端业务 RD 手动打点上报
用户体验:需要前端手动打点上报
b. 报警
基础平台、中间件、应用指标会自动配置报警,但是很多时候不合理,需要 RD 手动配置报警。
c. 大盘
聚合多个指标,可以做一些简单的数值运算,形成 1 个大盘。
d. 稳定性小组做的事:规范化(可报警、可看、可查)、自动化(减少人工成本)
指标可追溯:指标和日志 Tag 绑定:重要业务指标,都要有相应日志;且 ES 中 Tag 需是索引字段;
指标的治理:(解决的问题:单个指标是 1 个点,指标多了离散化严重)
平级指标:比如串联调用中的多个步骤,使用枚举表示
错误码:一种特殊的指标,用于给前端的返回值,用枚举表示
4. 线上问题发现
节假日巡检
机器容量评估
业务运行情况
应用能力评估:QPS、响应时间、当前压力达到峰值能力百分比
下游依赖情况
(3)事故处理
1. 处理原则
问题处理原则:先止损、再修复
问题通报:根因分析平台自动拉群,及时通报问题,评估并周知影响范围、持续时间、处理进度等
2. 处理方案 SOP
自动部分
降级
限流
重试
人工介入流程 【强制】
判断是否正在上线导致故障:回滚、禁用已发布机器
判断是否是有流量大导致的报警:扩容
及时通报业务方及上游
(4)事故复盘
1. 事故复盘 COE
复盘包含以下几点:问题原因、处理时间线、经验教训、改进计划等,拉 QA、SRE、相关业务方一起复盘 【强制】
2. TODO 及跟进
明确问题处理时间,尽快处理,及时更新状态
(5)线上观测指标
S4 及以上事故数
S9 事故数
漏洞数量:先知风险平台自动扫描
报警量
报警响应率
接口性能达标率:SLA
服务可靠性指标:SLO(Service Level Objective)
SLA 口径:统计团队所有服务所有接口的 200 返回判断是否正常,
问题:a. 大部分服务使用错误码代替 HTTP 状态码、b. 流量小但重要接口出现异常影响不了整体指标、c. 长耗时接口被统计成正常
方案:SLO 指标建设,建设多个 SLI 指标并划分权重,对应重要接口的相应状态(根据状态码+HTTP 状态判断)、接口承诺 TP99 响应时间
4、研发效能
(1)项目管理:
推动需求生命周期都走研发流程管理平台,比如 ONES。
(2)研发提效
1. 基础库建设
建设各种基础 utils,如 JSON 序列化、时间转换工具等;
2. 规范建设
框架规范、模块划分规范、分层规范、编码规范等;
3. 本地开发
a. 服务改造,不支持本地开发的原因:
容器配置依赖:各类 agent、配置文件,方案:在本地也安装一遍
下游依赖:要求本地网络可以连接测试环境资源
编译方式:dev 环境和测试环境保持一致
环境不一致:线上是 Linux,本地是 Mac
b. 工具
热部署:JRebel 等
c. 面临的挑战:
本地电脑太卡:解决方案:云 IDE、IDEA 远程开发;或控制微服务的粒度
4. 环境建设
测试环境泳道治理:主要是主干泳道治理,如 RD 不能手动操作的主干泳道,主干泳道根据 master 分支更新自动发布等
线上仿真环境:
无真实流量环境:使用线上数据库和下游,无线上真实流量,用于上线前的线上环境验证;
有真实流量环境:nginx 配置小流量,验证线上真实流量场景;
5、降本增效
推动策略包含:
a. 手段 1-下机器
数据报表建设:按组织结构选择所有服务资源利用率报表,未达标报表
立目标:deadline,每周目标
数据播报:大群每天定时播报各组资源利用率
b. 手段 2-弹性伸缩
弹性伸缩规则:
定时
根据指标:QPS、CPU 利用率等
服务弹性伸缩注意事项,不适合弹性伸缩的场景:
瞬时流量波动较大的服务
有状态服务:比如 TCP 长连接服务、有本地存储服务
c. 手段 3-服务改造
性能优化:业务层面、JVM 层面等
服务合并部署:多个微服务代码合并成一个
有状态服务改造成无状态服务:比如有的服务依赖了基于本地磁盘的队列,改成了 MQ 队列
日志改造:有服务排查日志依赖本地磁盘日志,把业务重要日志改为日志中心存储(基于 ES)
新工具尝试:serverless 等
6、团队建设
(1)会议
稳定性保障小组周会:查看报警、错误日志、风险等,回顾上周的工作,确定本周 TODO
周会:回顾稳定性周指标,同步
(2)宣讲
推动的每件事情都会进行宣讲
(3)考试
规范考试
SOP 考试
线上操作规范考试等
(4)权限卡控
新人入职 N 个月内不允许上线
考试的通过后才自动开通线上发布权限
总结
稳定性事情涉及的事项、团队、服务非常多,Case By Case 的治理,很容易没有重点且效果不好,要有方法论来全局规划、推动落地。
1、原则
复杂的事情简单化,简单的事情标准化,标准的事情流程化,流程的事情自动化。
![](https://static001.geekbang.org/infoq/56/5658624e0357bffdd3d2a3842612960d.png)
(1)复杂的事情简单化
简化常用的方法:任务拆分,复用(比如:框架的复用、设计模式的复用等)
(2)简单的事情标准化
分两部分:操作流程(SOP)、团队规范、术语标准化、数据口径标准等;
(3)标准的事情流程化
落地有相应辅助工具,比如有了 ORM 框架规范,需要基本的代码生成工具;
(4)流程的事情自动化
完全避免人工操作,比如各种数据统计、任务进度报表等
(5)实践分享:单元测试建设
治理之前:单测全凭 RD 自驱,单测不完善、单测跑不过、单测框架多、流水线没配置单测
a. 简单化:任务拆分
历史债务治理:单测跑通过是基础。又可以拆分为:流水线配置单测、Git Merge 卡控、流水线通过比例大盘
引入新规范:Junit5、powermock、testablemock
推动增量代码单测覆盖率:逐步提升卡控标准:20% 40% 60%,最终达到 80%
推动全量代码单测覆盖率
b. 标准化:规范+模版+数据口径
流水线标准化:通过配置流水线模版,逐步统一各服务流水线
单测规范:工具规范化
数据指标口径标准:比如如何定义增量代码覆盖率? 我们最终采用的是 merge 前最后一次提交时对应的单测数据
c. 流程化:
单测示例代码:建立单测示例代码库,常用的场景都能找到对应 case,降低学习成本
原因分析,保障单测流程顺利执行:对于单测覆盖率不达标的场景,可根据分支名、push 记录找到具体哪一行没跑通过、没覆盖到
意外流程:对于紧急修复漏洞场景,可以不通过单测卡控直接 merge(需审批)
d. 自动化
流水线自动化: 代码 push、创建 pr 都会自动触发流水线,流水线打通 Git Merge 功能
流水线配置自动化:团队卡控要配置到流水线,没有工具,自建脚本完成配置,比如:单测必须开启、单测覆盖率、单测必须有 asset 语句等
数据采集自动化:自动采集各团队、仓库的单测数据,形成多维度报表
2、推动落地
![](https://static001.geekbang.org/infoq/e6/e6142f38eeb111d8be4031f368e5af43.png)
(1)自身:主观能动性
稳定性保证工作没有终点,是项系统的工程,从模糊的目标到方法再到落地有很大的差距。 不仅仅是学习业界相关经验或者采用公司的工具,需要发挥主观能动性全面深入思考,找到符合团队的最佳实践,深入一线才能更顺利的推动落地。
需要承担大量非本职能的工作,不要自我设限:比如数据指标建设、大盘建设、自动脚本开发等。
(2)向下推动
为治理效果负责,不能只当传声筒,可以通过以下几方面保障事情推动:
任务拆解:收到的任务都是模糊的,比如规范、提升某指标等,一线 RD 缺少的具体操作步骤,需要对任务进行拆解并宣导,做到可理解、可落地、可观测的程度;
任务分配:明确负责人及时间点
任务执行:建立 SOP、工具等,有衡量标准,观测手段,及奖惩制度;对下分配任务一定要有相关的进度观测工具;
(3)向上管理
向上管理很重要:
任务范围广:稳定性工作不只是 Leader 分配下来的任务,还有很多自驱的事情;
工作难以量化:不是所有事情都能用数据量化,也不能简单用没有事故就认为稳定性做得好,尽量做到汇报可量化;
需要 Leader 支持的:
给予帮助:稳定性治理人员权限不够,有时需要借助 Leader 的帮助,如通宵紧急修复漏洞、对稳定性提高重视的宣导等;
给予信任:稳定性工作成果不好量化,且不会带来业务价值。需要 Leader 给予足够的信任;
(4)横向协作
稳定性的事情 QA、SRE、其他横向稳定性小组等保持了良好的沟通协作,保障事情顺利推动:
辅助:比如经验参考、规范工具借鉴等;还可以一起推动改变老板的一些决策等;
协助:比如 SRE 服务器资源协调、QA 流水线治理、自动化建设等;
贡献:将做的好的推广给更多团队,比如单测经验分享、指标大盘、自动化工具等;
本文链接:稳定性建设实践
作者简介:木小丰,快手架构师,专注分享软件研发实践、架构思考。欢迎关注公共号:Java 研发
公共号:Java 研发
更多精彩文章:
版权声明: 本文为 InfoQ 作者【木小风】的原创文章。
原文链接:【http://xie.infoq.cn/article/7e001afee14998acd1c0eea67】。
本文遵守【CC BY-NC】协议,转载请保留原文出处及本版权声明。
评论