所在组织结构：团队成员40人左右，业务特点：有大量老服务、流量波动大（峰值集中在中午和傍晚）、流量不可预测。
稳定性小组的组成：
职责：
稳定性保障小组这个名称其实不是特别准确，后续又承接了很多其他的横向推动的任务，主要包括三大块：
整体流程图：
超过3PD的需求需要写方案文档同步到小组群，超过10pd的需求需要小组内评审。
禁止提交master分支【强制】
分支规范【强制】
团队之前没有静态代码检查，存量代码中存在大量的待解决问题，卡控应先卡控增量代码，然后逐步提升全量卡控比例；
大部分代码没有单测，且很多跑不通过的单测。治理过程：(a).修复跑不过的单测；(b).流水线检查单测必须跑通过；(c).引入单测规范；(d).卡控增量代码覆盖率、单测必须有assert；(e).卡控全量覆盖率
每次发布、配置变更、数据变更都需要使用上线变更平台发起申请单，并通过二层审批
a.上下游机器配置平衡
b.负载均衡
c.机器利用率：治理资源利用率太多的应用，及时扩容
d.弹性伸缩容接入（基于K8S）【核心服务强制】
检查机制：基础数据通过大盘报表查看，各平台零散数据通过爬虫爬数据，再输出报表
a.服务提供者治理：C端必须有接口限流
b.依赖资源治理：C端核心依赖必须有熔断、降级【强制】
c.风险治理：公司基建，风控推动等
d.报警治理：P0+P1报警，每个问题都必须跟进，如无必要报警，调整报警策略【强制】
检查机制：规范+周会同步
a.压测【强制】
公司工具：Trace链路追踪、Mock工具、影子表工具等
稳定性小组做的事：
b.故障演练【强制】工具：故障演练平台
梳理稳定性问题，包含以下几部分：
a.核心服务稳定性梳理：代码走查、风控接入等
b.线上线下行为不一致治理：代码里有大量ifelse不同环境走不同逻辑
c.资损专项治理：接口幂等、对账等
a.Metric：跨服务调用链路追踪
基础组件：上层中间件支持如RPC框架、HTTP客户端服务端、MQ、定时任务框架等。如果没有链路标识，则自动添加链路标识
b.日志
通过监听slf4j日志，上报到日志中心并通过ES+Kibana提供查询能力
c.指标
后端指标统计、大盘建设、报警（阈值报警+智能报警）、前端指标统计等。
常见的指标类型有：
a.监控
监控建设金字塔：
基础平台监控、中间件监控：公司基础组件自动上报
业务监控：需要后端业务RD手动打点上报
用户体验：需要前端手动打点上报
b.报警
基础平台、中间件、应用指标会自动配置报警，但是很多时候不合理，需要RD手动配置报警。
c.大盘
聚合多个指标，可以做一些简单的数值运算，形成1个大盘。
d.稳定性小组做的事：规范化（可报警、可看、可查）、自动化（减少人工成本）
指标可追溯：指标和日志Tag绑定：重要业务指标，都要有相应日志；且ES中Tag需是索引字段；
指标的治理：（解决的问题：单个指标是1个点，指标多了离散化严重）
节假日巡检
问题处理原则：先止损、再修复
自动部分
人工介入流程【强制】
SLA口径：统计团队所有服务所有接口的200返回判断是否正常，
问题：a.大部分服务使用错误码代替HTTP状态码、b.流量小但重要接口出现异常影响不了整体指标、c.长耗时接口被统计成正常
推动需求生命周期都走研发流程管理平台，比如ONES。
框架规范、模块划分规范、分层规范、编码规范等；
a.服务改造，不支持本地开发的原因：
b.工具
c.面临的挑战：
测试环境泳道治理：主要是主干泳道治理，如RD不能手动操作的主干泳道，主干泳道根据master分支更新自动发布等
线上仿真环境：
推动策略包含：
a.手段1-下机器
数据报表建设：按组织结构选择所有服务资源利用率报表，未达标报表
立目标：deadline，每周目标
数据播报：大群每天定时播报各组资源利用率
b.手段2-弹性伸缩
弹性伸缩规则：
服务弹性伸缩注意事项，不适合弹性伸缩的场景：
c.手段3-服务改造
推动的每件事情都会进行宣讲
规范考试
SOP考试
线上操作规范考试等
新人入职N个月内不允许上线
考试的通过后才自动开通线上发布权限
稳定性事情涉及的事项、团队、服务非常多，CaseByCase的治理，很容易没有重点且效果不好，要有方法论来全局规划、推动落地。
复杂的事情简单化，简单的事情标准化，标准的事情流程化，流程的事情自动化。
简化常用的方法：任务拆分，复用（比如：框架的复用、设计模式的复用等）
分两部分：操作流程（SOP）、团队规范、术语标准化、数据口径标准等；
落地有相应辅助工具，比如有了ORM框架规范，需要基本的代码生成工具；
完全避免人工操作，比如各种数据统计、任务进度报表等
治理之前：单测全凭RD自驱，单测不完善、单测跑不过、单测框架多、流水线没配置单测
a.简单化：任务拆分
b.标准化：规范+模版+数据口径
c.流程化：
d.自动化
需要承担大量非本职能的工作，不要自我设限：比如数据指标建设、大盘建设、自动脚本开发等。
为治理效果负责，不能只当传声筒，可以通过以下几方面保障事情推动：
向上管理很重要：
需要Leader支持的：
稳定性的事情QA、SRE、其他横向稳定性小组等保持了良好的沟通协作，保障事情顺利推动：