稳定性建设实践

2024-01-14  本文已影响0人  木小丰_

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

1、职责

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

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

稳定性小组的组成：


image.png

职责：

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

时间分配：

2、交付流程稳定性保障

整体流程图：


image.png

（1）方案设计规范

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

（2）代码规范

禁止提交master分支【强制】

分支规范【强制】

参考：Commit Log规范

（3）流水线建设

  1. 静态代码检查

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

  2. 单元测试

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

  3. Git治理

（4）上线规范

  1. 工具： 上线变更平台

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

  2. 上线记录到checklist文档

（5）交付流程观测指标

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

3、线上稳定性保障

image.png

（1）事故预防

1. 运维基础能力建设

a.上下游机器配置平衡

b. 负载均衡

c. 机器利用率：治理资源利用率太多的应用，及时扩容

d. 弹性伸缩容接入（基于K8S）【核心服务强制】

检查机制：基础数据通过大盘报表查看，各平台零散数据通过爬虫爬数据，再输出报表

2. 服务治理

a. 服务提供者治理：C端必须有接口限流

b. 依赖资源治理：C端核心依赖必须有熔断、降级 【强制】

c. 风险治理：公司基建，风控推动等

d. 报警治理：P0+P1报警，每个问题都必须跟进，如无必要报警，调整报警策略 【强制】

检查机制：规范+周会同步

3. 系统能力预估

a.压测 【强制】

公司工具：Trace链路追踪、Mock工具、影子表工具等

稳定性小组做的事：

b. 故障演练【强制】 工具：故障演练平台

4. 业务梳理及风险排查

梳理稳定性问题，包含以下几部分：

a. 核心服务稳定性梳理：代码走查、风控接入等

b. 线上线下行为不一致治理：代码里有大量ifelse不同环境走不同逻辑

c. 资损专项治理：接口幂等、对账等

（2）事故发现&排查

1.原则：可观测性（Observability）

image.png

2. 工具

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

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

    b. 日志

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

    c. 指标

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

        常见的指标类型有：

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. 服务改造，不支持本地开发的原因：

b. 工具

c. 面临的挑战：

4. 环境建设

测试环境泳道治理：主要是主干泳道治理，如RD不能手动操作的主干泳道，主干泳道根据master分支更新自动发布等

线上仿真环境：

5、降本增效

推动策略包含：

a. 手段1-下机器

数据报表建设：按组织结构选择所有服务资源利用率报表，未达标报表

立目标：deadline，每周目标

数据播报：大群每天定时播报各组资源利用率

b. 手段2-弹性伸缩

弹性伸缩规则：

服务弹性伸缩注意事项，不适合弹性伸缩的场景：

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. 简单化：任务拆分

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的架构演进

上一篇 下一篇

猜你喜欢

热点阅读