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，它一旦有问题很可能就是波及全站的范围。由于很多历史原因，“大泥球”的服务积累的技术债务会很多。这时候针对这个服务定一个合理的指标，比定一个标准的指标要好很多。