稳定性建设实践
1、职责
所在组织结构：团队成员40人左右，业务特点：有大量老服务、流量波动大（峰值集中在中午和傍晚）、流量不可预测。
背景：以业务发展为主，对稳定性关注较少，各项目使用的规范和工具不一致，*两年*台出了几次事故，开始重视稳定性建设，成立稳定性保障小组，推动稳定性工作。
稳定性小组的组成：
- 稳定性保障小组：各团队抽调人力成立的一个虚拟小组，负责团队内部的任务推动
- QA：负责上线前各流程的规范及检查，负责流水线建设、事故定责
- SRE：负责线上问题的跟进
- Leader：本部门内的稳定性工作负责人
- 安全生产委员会：负责事业部内安全生产相关规范、配合公司级事项推动、协调外部资源
职责：
稳定性保障小组这个名称其实不是特别准确，后续又承接了很多其他的横向推动的任务，主要包括三大块：
- 稳定性保证：分为上线前保障和线上保障
- 研发效能：规范制定、流水线建设、环境建设等
- 降本增效：提升资源利用率
时间分配：
- 组长：50%左右
- 稳定性保障小组成员：10%左右
2、交付流程稳定性保障
整体流程图：
（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、线上稳定性保障
（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）
2. 工具
a. Metric：跨服务调用链路追踪
基础组件：上层中间件支持如RPC框架、HTTP客户端服务端、MQ、定时任务框架等。如果没有链路标识，则自动添加链路标识
b. 日志
通过监听slf4j日志，上报到日志中心并通过ES+Kibana提供查询能力
c. 指标
后端指标统计、大盘建设、报警（阈值报警+智能报警）、前端指标统计等。
常见的指标类型有：
- Count：用来记录一件事发生的次数，只有数量
- Micros：记录一段代码的执行时间和次数，有*均耗时、TP90、TP99、TP999、最大、最小耗时、次数等详细信息
3. 多维度监控、报警
a. 监控
监控建设金字塔：
基础*台监控、中间件监控：公司基础组件自动上报
应用监控：公司基础组件自动上报，比如接口粒度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、原则
复杂的事情简单化，简单的事情标准化，标准的事情流程化，流程的事情自动化。
（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、推动落地
（1）自身：主观能动性
稳定性保证工作没有终点，是项系统的工程，从模糊的目标到方法再到落地有很大的差距。 不仅仅是学习业界相关经验或者采用公司的工具，需要发挥主观能动性全面深入思考，找到符合团队的最佳实践，深入一线才能更顺利的推动落地。
需要承担大量非本职能的工作，不要自我设限：比如数据指标建设、大盘建设、自动脚本开发等。
（2）向下推动
为治理效果负责，不能只当传声筒，可以通过以下几方面保障事情推动：
-
任务拆解：收到的任务都是模糊的，比如规范、提升某指标等，一线RD缺少的具体操作步骤，需要对任务进行拆解并宣导，做到可理解、可落地、可观测的程度；
-
任务分配：明确负责人及时间点
-
任务执行：建立SOP、工具等，有衡量标准，观测手段，及奖惩制度；对下分配任务一定要有相关的进度观测工具；
（3）向上管理
向上管理很重要：
- 任务范围广：稳定性工作不只是Leader分配下来的任务，还有很多自驱的事情；
- 工作难以量化：不是所有事情都能用数据量化，也不能简单用没有事故就认为稳定性做得好，尽量做到汇报可量化；
需要Leader支持的：
- 给予帮助：稳定性治理人员权限不够，有时需要借助Leader的帮助，如通宵紧急修复漏洞、对稳定性提高重视的宣导等；
- 给予信任：稳定性工作成果不好量化，且不会带来业务价值。需要Leader给予足够的信任；
（4）横向协作
稳定性的事情QA、SRE、其他横向稳定性小组等保持了良好的沟通协作，保障事情顺利推动：
- 辅助：比如经验参考、规范工具借鉴等；还可以一起推动改变老板的一些决策等；
- 协助：比如SRE服务器资源协调、QA流水线治理、自动化建设等；
- 贡献：将做的好的推广给更多团队，比如单测经验分享、指标大盘、自动化工具等；
本文链接：稳定性建设实践
作者简介：木小丰，快手架构师，专注分享软件研发实践、架构思考。欢迎关注公共号：Java研发
公共号：Java研发
更多精彩文章：
