什么是SRE及其目标？

SRE（Site Reliability Engineering，网站可靠性工程）是一种通过创建软件系统来维护系统运行，以替代传统模型中的人工操作的工程实践。简而言之，SRE的目标是通过提高运维系统的自动化程度来增加服务的可靠性。

SRE的目标

1. 提高服务可靠性：通过自动化手段提升服务的稳定性，从而提高用户体验。
2. 减少运维琐事：通过自动化减少运维人员在日常工作中的重复性任务，使他们能够投入到更具创造性的工作中，进而提高服务质量和效率。

衡量指标

• SLA（Service Level Agreement，服务级别协议）：服务提供商与客户之间的正式承诺，定义了服务的可用性、质量和责任。
• SLO（Service Level Objective，服务级别目标）：以百分比形式表达的服务目标，例如99.99%的成功率或90%的请求延迟小于400毫秒。
• SLI（Service Level Indicator，服务级别指标）：通过监控工具持续采集的数据，用于衡量服务的健康状况。多个SLI可以对应一个SLO。

SRE稳定性保障规划图

系统稳定性

通用衡量指标及计算公式

指标	释义	系统运行状态
MTBF（Mean Time Between Failure）	平均故障时间	系统正常运行时
MTTR（Mean Time To Repair）	故障平均修复时间	系统故障时

提升稳定性的两个措施：提升故障时间间隔，降低故障修复时间。SRE以这两个指标为宗旨。

细分目标

MTBF可以细分为两个阶段：

阶段	释义
Pre-MTBF	故障预防
Post-MTBF	故障改进

具体阶段划分

Pre-MTBF（故障预防）	MTTI（故障发现）	MTTK（故障定位）	MTTF&MTTV（故障恢复）	Post-MTBF（故障改进）
故障演练	AIOps	日志分析	容灾切换	故障复盘
容量评估	舆情感知	链路跟踪	服务降级	改进验收
持续交付	监控告警	根因定位	服务限流	故障模拟
自动化			异常熔断	混沌工程
架构设计				容量压测

体系建设

Pre-MTBF（故障预防）	MTTI（故障发现）	MTTK（故障定位）	MTTF&MTTV（故障恢复）	Post-MTBF（故障改进）
建设演练/On-Call	应急响应	应急响应	应急响应	复盘改进/On-Call

Pre-MTBF阶段（无故障阶段）：做好架构设计，提供限流、降级、熔断等服务治理手段，具备故障快速隔离的条件。还可以引入混沌工程，模拟故障，提前发现问题。

Post-MTBF阶段（故障复盘阶段）：故障结束后，进行故障复盘，总结经验，找到不足，落地改进措施。

MTTI阶段（故障发现响应阶段）：依赖监控系统及时发现问题，对于复杂系统，依赖AIOps提升告警准确率，做出精准响应。

系统可用性：故障≠稳定

目前，业界衡量系统可用性的方式主要有两种：

1. 时间维度的系统可用性：Availability = Uptime / (Uptime + Downtime)
2. 请求维度的系统可用性：Availability = Successful request / Total request

时间维度

时间维度的可用性测量方法包含三要素：

• 衡量指标
• 衡量目标
• 影响时长

常见的按时长维度统计的可用性对照表：

请求维度

请求维度的可用性测量方法包含三要素：

• 衡量指标
• 衡量目标
• 统计周期

例如，基于1000个请求：

• 系统可用性90%：允许100个请求出错。
• 系统可用性99%：允许10个请求出错。
• 系统可用性99.9%：允许1个请求出错。

这种方式对系统运行状况的监管更为严格，不会漏掉任何一次问题的影响。

设立系统稳定性目标的三个因素

1. 成本因素：可用性越高，成本越高。
2. 业务容忍度：核心业务对稳定性要求更高，非核心业务可以适当放宽。
3. 系统当前的稳定性状况：结合系统实际情况，设定合理的标准。

设定稳定性的衡量标准

“确定成功请求条件，设定达成占比目标”的过程，在SRE中就是设定稳定性衡量标准的SLI和SLO的过程。

• SLI（Service Level Indicator）：服务等级指标，选择哪些指标来衡量稳定性。
• SLO（Service Level Objective）：服务等级目标，设定的稳定性目标。

例如，HTTP状态码返回为非5xx的比例大于等于99.95%时，认为应用是稳定的。

SLI

什么是SLI？

SLI是能够标识目标对象是否稳定，并与用户体验强相关的指标。

选择监控指标的考量点

1. 要衡量谁的稳定性？：找到稳定性主体。
2. 这个指标能够标识这个实例是否稳定吗？

确定SLI指标的两大原则

1. 选择能够标识主体是否稳定的指标。
2. 针对电商等有用户界面的业务系统，优先选择与用户体验强相关的指标。

VALET选择法

VALET选择法依据指标的特质进行分类甄别，帮助快速区分出SLI。

SLO

什么是SLO？

SLO是SLI的目标，例如“1个小时内90%时延<=80ms”。

如何衡量SLO的有效性？

衡量SLO及错误预算策略是否有效，主要看以下三个关键维度：

1. SLO达成情况：用达成（Met）或未达成（Missed）表示。
2. 人肉投入程度：用投入程度高（High）或低（Low）表示。
3. 用户满意度：通过真实和虚拟渠道获取，用投入程度高（High）或低（Low）表示。

故障发现及处理

故障发现

MTTI（Mean Time To Identify，平均故障发现时间）：从故障实际发生到开始响应的时间。

减少MTTI时间的方法：

1. 判断问题是否是故障：根据SLO和错误预算判断。
2. 确定由谁来响应和召集：建设On-Call机制。

On-Call机制

1. 确保关键角色在线。
2. 组织WarRoom应急组织。
3. 建立合理的呼叫方式。
4. 确保资源投入的升级机制。
5. 与云厂商联合的On-Call。

故障处理

基本原则：一切以恢复业务为最高优先级。

建立有效的故障应急响应机制

关键角色分工

1. Incident Commander（IC）：故障指挥官，负责组织和协调。
2. Communication Lead（CL）：沟通引导，负责信息收集及通报。
3. Operations Lead（OL）：运维指挥，负责故障预案的执行和业务恢复。

流程机制

1. 故障发现后，On-Call的SRE或运维组织War Room。
2. 如果问题明确，IC仍然是SRE。
3. 如果问题疑难，SRE可以要求更高级别的主管介入。

反馈机制

每隔10～15分钟做一次反馈，反馈当前处理进展及下一步Action。

故障复盘

故障复盘的黄金三问

1. 故障原因有哪些？
2. 我们做什么，怎么做才能确保下次不会再出现类似故障？
3. 当时如果我们做了什么，可以用更短的时间恢复业务？

故障判定的三原则

1. 健壮性原则：每个部件自身要具备一定的自愈能力。
2. 第三方默认无责：使用第三方服务时，默认第三方无责。
3. 分段判定原则：当发生衍生故障时，将一次故障分段判断。

SRE组织结构

技术架构图

技术保障体系

1. 工具平台团队：负责效能工具的研发。
2. 稳定性平台团队：负责稳定性保障相关的标准和平台。

组织架构

SRE是由多个不同角色组合而成的团队，包括PE、工具平台开发和稳定性平台开发。

SRE的各个角色如何协作？

通过“以赛代练”的策略，SRE的各个角色在大促等高压场景下协作，充分暴露系统的稳定性问题，并进行针对性改进。

大促项目协作流程

1. 大促项目开工会：明确业务指标，指定技术保障负责人。
2. 业务指标分解及用户模型分析评审会：业务开发和PE团队共同分析核心链路。
3. 应急预案评审会：PE与业务开发配合，制定限流、降级和熔断策略。
4. 容量压测及复盘会：PE、业务开发和稳定性平台团队配合，进行容量压测。

每个角色负责的内容

1. PE：关注线上整体运行状态，负责平台级公共部件。
2. 业务开发：关注具体应用及代码层面的分析。
3. 工具开发和稳定性开发：平时开发各类平台和工具，支持大促期间的压测和应急响应。

SRE组织中的各个角色平时的工作

1. 核心应用变更及新上线业务的稳定性评审：PE与业务开发共同评估变动的影响。
2. 周期性技术运营工作：例行关注错误预算的消耗情况，输出系统整体运行报表。

end