1、SRE体系工作流
（1）故障预防阶段：主动构建系统韧性
从技术规范和架构设计层面，推动系统具备抗风险能力。
- 向开发团队传递“面向失败编程“理念，明确RPC异常处理、分布式事务一致性等编码要求。
- 主导或参与框架治理能力建设，包括设计熔断限流策略、配置失败重试机制、定义数据中间态规则等，从架构层降低故障概率。
（2）故障发现阶段
- 监控策略设计：规划全链路监控方案，明确需埋点的关键链路（如RPC调用、核心业务事件）及日志格式。
- 告警规则制定：基于业务SLA（服务等级协议），在监控系统中配置告警阈值与规则，确保异常（如错误率突增、延迟超标）能触发精准告警。
（3）故障处理阶段
- 告警响应：接收告警后，第一时间通过监控看板（如Grafana）定位故障根源（如服务节点异常、依赖组件故障）。
- 应急操作：通过治理平台执行紧急操作（如流量切换、服务重启），或协调开发团队进行代码热修复，快速恢复服务。
- 经验固化：将高频问题的排查步骤（如“数据库连接池耗尽排查流程”）整理为标准化文档或看板模板，提升团队协作效率。
（4）故障复盘
- 复盘组织与输出：主导故障复盘会议，梳理故障根因（如“配置错误”“容量不足”），输出包含改进方案的复盘报告。
- 流程与工具迭代：将复盘结论转化为可落地的行动，如优化监控指标、更新治理平台功能（如新增“一键扩容”按钮），避免同类故障重复发生。
2、SRE面临的挑战
（1）如何衡量服务可用性
第一种是考虑时长。
- MTTF（平均无故障时间）：指系统无故障运行的平均时间
- MTTR（平均修复时间）：系统从发生故障到维修结束之间的时间段的平均值
- MTBF（平均失效间隔）：两次故障发生时间之间的时间段平均值
MTBF = MTTF + MTTR。衡量稳定性：AO = MTBF / (MTBF + MTTF)
第二种是从服务质量来看：请求维度：成功率 = 成功请求数/总请求数
这里不能统计单个请求，而是看一段时间的概率分布，如5xx占比。计算一段时间的5xx占比达到5%，持续10min。这一块一般用几个9来衡量。
在定目标前要想清楚3件事：1）花多少钱；2）业务能接受多少“小意外”（比如视频网站和支付系统的容忍度就不同）；3）系统现在的“底子”如何（若系统本身遗留的技术债务过多，强行定太高目标可能不现实，得先修复基础问题）。
3个9：指系统全年可用时间达到99.9%，这个目标比较容易实现，成本也低。
4个9：指全年可用时间达到99.99%，全年最多只能“崩8.76小时”，这个目标对技术、人力、硬件的要求极高，投入成本会成倍增加）。
选择稳定性目标涉及了测量方法和判断方法，包含三个要素：
- 衡量指标：如5xx比例
- 衡量目标：总访问量（QOM）code=200占比小于95%
- 影响时长：QPM是一个聚合指标，也是应该在一个时间跨度上去计算次数。
这里的衡量指标就是SLI，目标是SLO，如果针对服务质量还有SLA。
（2）如何选择合适的SLI，设置合理的SLO
Google提出的五大“黄金指标”：容量、可用性、时延、错误率、人工介入。
（3）如何及时发现问题
若选择好了指标，接下来要采集数据提炼出想要的指标。
SRE工具及主要从数据源采集，分析生成监控指标，判定这些指标阈值触发告警后，及时响应。包括以下几个部分：
- 数据采集：将收集的数据发布到Kafka。
- 数据分析：流式分析和离线分析。比如有链路分析，分析链路的依赖拓扑关系，找出循环调用、慢接口、慢SQL、双向依赖等常见的风险点。
- 数据存储：监控常用Prometheus，但它原生不支持分布式存储，我们可以采用其他工具进行远程存储。针对存储时间长的会采用稀疏存储模式，大量采用物化视图聚合数据。
- 监控画像：日志查看主要基于EKL体系，Grafana用于分析后的指标聚合展示。
- 告警通知：可以接入企业群聊等，让整个处理流程移动化。
- 告警响应
3、SRE切入点：推进技术债务改造
技术债务分为三类：不良代码积累；业务建模；业务架构设计。
- 不良代码积累：随着服务迭代，需求变更、烂代码的引入、建模的不合理，就会带来一些技术债务。这样就会使得服务稳定性越差，积累更多技术债务，从而形成恶性循环。
- 原因：1）工程师以完成当前项目功能为导向，但大部分情况下，项目结束后就没有下文了。2）没有保持最小依赖的原则，有些组件可能只需要其中的某个功能，但直接引入了整个组件，这个组件又依赖其他的组件，后续可能没人负责迭代，从而变成不定时炸弹。
- 业务建模 & 业务架构设计
- 未理解SOLID设计原则：单一职责、开闭原则、里氏替换、接口隔离、依赖反转
- 过早的引入不需要的设计：虽然微服务是当前主流，新项目一开始就拆分成不同的服务，为了适应这个复杂的服务调用流程不得不付出很多人力成本。好的架构是支持渐进式的，沉淀出特定领域逻辑，等到合适的时候再拆分，或者随业务的发展变化还能支持聚合。
- 边界划分不合理：
- 依赖不合理：高层策略依赖底层组件。
4、基于链路分析找出潜在风险
（1）慢接口：这会严重影响服务的吞吐量，最终反馈到用户体验上，造成客户流失。这里不采用平均耗时，因为接口延迟满足长尾效应，延迟越大危害越大，所以优先优化延迟高的接口。一般蔡康永接口的延迟百分位第99位来衡量（如后端服务P99<100ms，即99%的服务响应时间都是小于100ms的）
（2）异常接口：接口错误率，实时反映服务可用性。根据业务哦让人都可用性可以设置成3个9或4个9.
（3）慢sql：随业务迭代，未经优化的SLQ可能会产生雪崩。
（4）稳定依赖：能不依赖就不依赖，能少依赖就少依赖，尽量依赖稳定的方向。
参考：
https://www.infoq.cn/article/vbufppurg9lfelrogx3t
设置稳定性目标一般需要考虑：成本，业务容忍度，当前业务的现状。大部分时候 4 个 9 目标比 3 个 9 目标投入成本要高很多。有些底层的服务，稳定性要求就比一般配套服务的高。比如 doctor 医生服务的稳定性就需要 99.99，它一旦有问题很可能就是波及全站的范围。由于很多历史原因，“大泥球”的服务积累的技术债务会很多。这时候针对这个服务定一个合理的指标，比定一个标准的指标要好很多。
