侧边栏壁纸
博主头像
木小风的博客博主等级

行动起来,活在当下

  • 累计撰写 19 篇文章
  • 累计创建 19 个标签
  • 累计收到 9 条评论

目 录CONTENT

文章目录

稳定性建设实践

木小风
2024-01-15 / 0 评论 / 0 点赞 / 95 阅读 / 20611 字

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

1、职责

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

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

稳定性小组的组成:

img

  • 稳定性保障小组:各团队抽调人力成立的一个虚拟小组,负责团队内部的任务推动

  • QA:负责上线前各流程的规范及检查,负责流水线建设、事故定责

  • SRE:负责线上问题的跟进

  • Leader:本部门内的稳定性工作负责人

  • 安全生产委员会:负责事业部内安全生产相关规范、配合公司级事项推动、协调外部资源

职责

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

  • 稳定性保证:分为上线前保障和线上保障

  • 研发效能:规范制定、流水线建设、环境建设等

  • 降本增效:提升资源利用率

时间分配

  • 组长:50%左右

  • 稳定性保障小组成员:10%左右

2、交付流程稳定性保障

整体流程图:

image-20240115173845914

(1)方案设计规范

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

(2)代码规范

禁止提交master分支【强制】

分支规范【强制】

参考:Commit Log规范

(3)流水线建设

  1. 静态代码检查

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

  1. 单元测试

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

  1. Git治理

  • master分支权限治理:只有组长有master权限

  • merge卡控:流水线跑通过才能merge

  • merge卡控:不能merge自己提的pr,必须有至少有2个人review通过才能merge

  • merge后自动打tag,并用此tag发布线上

(4)上线规范

  1. 工具: 上线变更平台

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

  1. 上线记录到checklist文档

  • 需求:PRD、任务地址、需求发起人

  • 代码PR地址

  • 配置项

  • 上线顺序、依赖

  • 上线检查截图

  • 回滚方案

(5)交付流程观测指标

  1. 代码量

  2. 静态代码达标率:有问题的代码量/所有代码量

  3. 静态代码Blocker, Critical数量

  4. 单测通过率:治理过程中的临时指标

  5. 单元测试新增覆盖率:merge到master时统计新增代码

  6. 单元测试全量覆盖率:定时统计

  7. 千行代码bug率:QA测出的bug数/代码行数

  8. 回滚次数

3、线上稳定性保障

img

(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)

img

2. 工具

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

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

b. 日志

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

c. 指标

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

常见的指标类型有:

  • Count:用来记录一件事发生的次数,只有数量

  • Micros:记录一段代码的执行时间和次数,有平均耗时、TP90、TP99、TP999、最大、最小耗时、次数等详细信息

3. 多维度监控、报警

a. 监控

监控建设金字塔:

img

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

应用监控:公司基础组件自动上报,比如接口粒度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、原则

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

img

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

img

(1)自身:主观能动性

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

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

(2)向下推动

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

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

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

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

(3)向上管理

向上管理很重要:

  1. 任务范围广:稳定性工作不只是Leader分配下来的任务,还有很多自驱的事情;

  2. 工作难以量化:不是所有事情都能用数据量化,也不能简单用没有事故就认为稳定性做得好,尽量做到汇报可量化;

需要Leader支持的:

  1. 给予帮助:稳定性治理人员权限不够,有时需要借助Leader的帮助,如通宵紧急修复漏洞、对稳定性提高重视的宣导等;

  2. 给予信任:稳定性工作成果不好量化,且不会带来业务价值。需要Leader给予足够的信任;

(4)横向协作

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

  1. 辅助:比如经验参考、规范工具借鉴等;还可以一起推动改变老板的一些决策等;

  2. 协助:比如SRE服务器资源协调、QA流水线治理、自动化建设等;

  3. 贡献:将做的好的推广给更多团队,比如单测经验分享、指标大盘、自动化工具等;

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

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

欢迎关注公共号:Java研发

更多精彩文章:

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

错误码设计思考

Java线程池进阶 从MVC到DDD的架构演进


0

评论区