本文介绍了稳定性建设实践相关的内容。介绍了稳定性保障组织建设，交付流程的稳定性保障，线上稳定性保障的措施，研发效能的提升，团队建设等方面的内容。介绍了简化复杂的事情，标准化简单的事情，流程化标准的事情，自动化流程的事情的重要性。同时也提到了推动落地的方法和向上管理、横向协作的重要性。

1、职责

所在组织结构：团队成员40人左右，业务特点：有大量老服务、流量波动大（峰值集中在中午和傍晚）、流量不可预测。

背景：以业务发展为主，对稳定性关注较少，各项目使用的规范和工具不一致，近两年平台出了几次事故，开始重视稳定性建设，成立稳定性保障小组，推动稳定性工作。

稳定性小组的组成：

image.png

• 稳定性保障小组：各团队抽调人力成立的一个虚拟小组，负责团队内部的任务推动
• QA：负责上线前各流程的规范及检查，负责流水线建设、事故定责
• SRE：负责线上问题的跟进
• Leader：本部门内的稳定性工作负责人
• 安全生产委员会：负责事业部内安全生产相关规范、配合公司级事项推动、协调外部资源

职责：

稳定性保障小组这个名称其实不是特别准确，后续又承接了很多其他的横向推动的任务，主要包括三大块：

• 稳定性保证：分为上线前保障和线上保障
• 研发效能：规范制定、流水线建设、环境建设等
• 降本增效：提升资源利用率

时间分配：

• 组长：50%左右
• 稳定性保障小组成员：10%左右

2、交付流程稳定性保障

整体流程图：

image.png

（1）方案设计规范

超过3PD的需求需要写方案文档同步到小组群，超过10pd的需求需要小组内评审。

（2）代码规范

禁止提交master分支【强制】

分支规范【强制】

参考：Commit Log规范

（3）流水线建设

1. 静态代码检查

   团队之前没有静态代码检查，存量代码中存在大量的待解决问题，卡控应先卡控增量代码，然后逐步提升全量卡控比例；

2. 单元测试

   大部分代码没有单测，且很多跑不通过的单测。治理过程：(a).修复跑不过的单测；(b).流水线检查单测必须跑通过；(c).引入单测规范；(d).卡控增量代码覆盖率、单测必须有assert；(e). 卡控全量覆盖率

3. Git治理

• master分支权限治理：只有组长有master权限
• merge卡控：流水线跑通过才能merge
• merge卡控：不能merge自己提的pr，必须有至少有2个人review通过才能merge
• merge后自动打tag，并用此tag发布线上

（4）上线规范

1. 工具： 上线变更平台

   每次发布、配置变更、数据变更都需要使用上线变更平台发起申请单，并通过二层审批

2. 上线记录到checklist文档

• 需求：PRD、任务地址、需求发起人
• 代码PR地址
• 配置项
• 上线顺序、依赖
• 上线检查截图
• 回滚方案

（5）交付流程观测指标

1. 代码量
2. 静态代码达标率：有问题的代码量/所有代码量
3. 静态代码Blocker, Critical数量
4. 单测通过率：治理过程中的临时指标
5. 单元测试新增覆盖率：merge到master时统计新增代码
6. 单元测试全量覆盖率：定时统计
7. 千行代码bug率：QA测出的bug数/代码行数
8. 回滚次数

3、线上稳定性保障

image.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）

image.png

2. 工具

    a. Metric：跨服务调用链路追踪

        基础组件：上层中间件支持如RPC框架、HTTP客户端服务端、MQ、定时任务框架等。如果没有链路标识，则自动添加链路标识

    b. 日志

        通过监听slf4j日志，上报到日志中心并通过**ES+Kibana**提供查询能力

    c. 指标

        后端指标统计、大盘建设、报警（阈值报警+智能报警）、前端指标统计等。

        常见的指标类型有：

• Count：用来记录一件事发生的次数，只有数量
• Micros：记录一段代码的执行时间和次数，有平均耗时、TP90、TP99、TP999、最大、最小耗时、次数等详细信息

3. 多维度监控、报警

a. 监控

监控建设金字塔：

image.png

基础平台监控、中间件监控：公司基础组件自动上报

应用监控：公司基础组件自动上报，比如接口粒度QPS、响应时间、JVM信息等

业务监控：需要后端业务RD手动打点上报

用户体验：需要前端手动打点上报

b. 报警

基础平台、中间件、应用指标会自动配置报警，但是很多时候不合理，需要RD手动配置报警。

c. 大盘

聚合多个指标，可以做一些简单的数值运算，形成1个大盘。

d. 稳定性小组做的事：规范化（可报警、可看、可查）、自动化（减少人工成本）

指标可追溯：指标和日志Tag绑定：重要业务指标，都要有相应日志；且ES中Tag需是索引字段；

指标的治理：（解决的问题：单个指标是1个点，指标多了离散化严重）

• 平级指标：比如串联调用中的多个步骤，使用枚举表示
• 错误码：一种特殊的指标，用于给前端的返回值，用枚举表示

4. 线上问题发现

节假日巡检

1. 机器容量评估
2. 业务运行情况
3. 应用能力评估：QPS、响应时间、当前压力达到峰值能力百分比
4. 下游依赖情况

（3）事故处理

1. 处理原则

问题处理原则：先止损、再修复

问题通报：根因分析平台自动拉群，及时通报问题，评估并周知影响范围、持续时间、处理进度等

2. 处理方案SOP

1. 自动部分
   1. 降级
   2. 限流
   3. 重试
2. 人工介入流程 【强制】
   1. 判断是否正在上线导致故障：回滚、禁用已发布机器
   2. 判断是否是有流量大导致的报警：扩容
   3. 及时通报业务方及上游

（4）事故复盘

1. 事故复盘COE

复盘包含以下几点：问题原因、处理时间线、经验教训、改进计划等，拉QA、SRE、相关业务方一起复盘 【强制】

2. TODO及跟进

明确问题处理时间，尽快处理，及时更新状态

（5）线上观测指标

1. S4及以上事故数

2. S9事故数

3. 漏洞数量：先知风险平台自动扫描

4. 报警量

5. 报警响应率

6. 接口性能达标率：SLA

7. 服务可靠性指标：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-服务改造

1. 性能优化：业务层面、JVM层面等
2. 服务合并部署：多个微服务代码合并成一个
3. 有状态服务改造成无状态服务：比如有的服务依赖了基于本地磁盘的队列，改成了MQ队列
4. 日志改造：有服务排查日志依赖本地磁盘日志，把业务重要日志改为日志中心存储（基于ES）
5. 新工具尝试：serverless等

6、团队建设

（1）会议

1. 稳定性保障小组周会：查看报警、错误日志、风险等，回顾上周的工作，确定本周TODO
2. 周会：回顾稳定性周指标，同步

（2）宣讲

推动的每件事情都会进行宣讲

（3）考试

规范考试

SOP考试

线上操作规范考试等

（4）权限卡控

新人入职N个月内不允许上线

考试的通过后才自动开通线上发布权限

总结

稳定性事情涉及的事项、团队、服务非常多，Case By Case的治理，很容易没有重点且效果不好，要有方法论来全局规划、推动落地。

1、原则

复杂的事情简单化，简单的事情标准化，标准的事情流程化，流程的事情自动化。

image.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、推动落地

image.png

（1）自身：主观能动性

稳定性保证工作没有终点，是项系统的工程，从模糊的目标到方法再到落地有很大的差距。 不仅仅是学习业界相关经验或者采用公司的工具，需要发挥主观能动性全面深入思考，找到符合团队的最佳实践，深入一线才能更顺利的推动落地。

需要承担大量非本职能的工作，不要自我设限：比如数据指标建设、大盘建设、自动脚本开发等。

（2）向下推动

为治理效果负责，不能只当传声筒，可以通过以下几方面保障事情推动：

1. 任务拆解：收到的任务都是模糊的，比如规范、提升某指标等，一线RD缺少的具体操作步骤，需要对任务进行拆解并宣导，做到可理解、可落地、可观测的程度；

2. 任务分配：明确负责人及时间点

3. 任务执行：建立SOP、工具等，有衡量标准，观测手段，及奖惩制度；对下分配任务一定要有相关的进度观测工具；

（3）向上管理

向上管理很重要：

1. 任务范围广：稳定性工作不只是Leader分配下来的任务，还有很多自驱的事情；
2. 工作难以量化：不是所有事情都能用数据量化，也不能简单用没有事故就认为稳定性做得好，尽量做到汇报可量化；

需要Leader支持的：

1. 给予帮助：稳定性治理人员权限不够，有时需要借助Leader的帮助，如通宵紧急修复漏洞、对稳定性提高重视的宣导等；
2. 给予信任：稳定性工作成果不好量化，且不会带来业务价值。需要Leader给予足够的信任；

（4）横向协作

稳定性的事情QA、SRE、其他横向稳定性小组等保持了良好的沟通协作，保障事情顺利推动：

1. 辅助：比如经验参考、规范工具借鉴等；还可以一起推动改变老板的一些决策等；
2. 协助：比如SRE服务器资源协调、QA流水线治理、自动化建设等；
3. 贡献：将做的好的推广给更多团队，比如单测经验分享、指标大盘、自动化工具等；

本文链接：稳定性建设实践

作者简介：木小丰，快手架构师，专注分享软件研发实践、架构思考。

更多精彩文章：

高效能团队的Java研发规范(进阶版)

错误码设计思考
从MVC到DDD的架构演进