SRE是什么？

[color=rgba(0, 0, 0, 0.75)]

SRE(Site Reliability Engineering),站点可靠性工程,起源于2003年。在系统管理员模式下，通常是通过人工操作完成任务，而SRE倾向通过设计、构建自动化工具来取代人工操作。SRE的本质是用软件工程的思维和方法解决复杂的运维问题。

[color=rgba(0, 0, 0, 0.75)]

DevOps是在2008年年末流行起来，强调自动化替代人工操作，以及利用软件工程手段执行运维任务。DevOps的核心是"全栈交付"， SRE的出发点是“保障和提升系统稳定性”，两者要做的事情其实本质上差别不大，但是角度不同。可以认为DevOps是SRE核心理念的普适版本，SRE是DevOps模型在Google的具体实践。

[color=rgba(0, 0, 0, 0.75)]

Google SRE方法论

[color=rgba(0, 0, 0, 0.75)]

• 确保长期关注研发工作
  

[color=rgba(0, 0, 0, 0.75)]

Google将SRE团队的运维工作限制在50%以内，剩余时间花在研发项目上。实践中，SRE管理人员要经常度量团队成员的时间分配，有必要的话，可采取措施将过多的运维压力转移给研发团队。

[color=rgba(0, 0, 0, 0.75)]

• 在保障服务SLO的前提下最大化迭代速度
  

[color=rgba(0, 0, 0, 0.75)]

对于迭代创新速度与产品稳定程度之间的矛盾，可以使用“错误预算”工具处理。”错误预算”起源于这样的理念：任何产品不能，也不应该做到100%可靠。对用户来说，99.999%和100%的可用性是没有实质区别。其中，错误预算 = 1 - 可靠性目标。可以将错误预算用于新功能上线或者产品创新，如：最大化新功能的上线速度，同时保证服务质量。

[color=rgba(0, 0, 0, 0.75)]

• 监控系统
  

[color=rgba(0, 0, 0, 0.75)]

监控系统不应该依赖人来分析警报信息，而是由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。

[color=rgba(0, 0, 0, 0.75)]

• 应急事件处理
  

[color=rgba(0, 0, 0, 0.75)]

可靠性是MTTF（平均失败时间）和MTTR（平均恢复时间）的函数，通过事先预案并将最佳方法记录在“运维手册”上通常可以使MTTR降低3倍以上。

[color=rgba(0, 0, 0, 0.75)]

• 资源部署
  

[color=rgba(0, 0, 0, 0.75)]

新资源的部署与配置是相对比较危险的操作，必须要小心谨慎地执行。

[color=rgba(0, 0, 0, 0.75)]

• 效率与性能
  

[color=rgba(0, 0, 0, 0.75)]

任何盈利性服务都关心高效利用各种资源，SRE最终负责容量的部署和配置，因此SRE必须承担起任何有关利用率的讨论和改进。

[color=rgba(0, 0, 0, 0.75)]

SLA、SLO、SLI

[color=rgba(0, 0, 0, 0.75)]

• SLI, Service level Indicate, 服务质量指标
  

[color=rgba(0, 0, 0, 0.75)]

该服务的某项服务质量的一个具体化指标，请求延迟为大部分服务的一个关键SLI，除此之外有错误率，吞吐率，可用性等。这些指标的计算过程：在某一个度量时间范围内将原始数据收集起来，计算速率，平均值、百分比等汇总数据。通常用9的数量来描述可用程度，99%可用性被称为9个9，99.999%被称为5个9.

[color=rgba(0, 0, 0, 0.75)]

• SLO, Service Level Object, 服务质量目标
  

[color=rgba(0, 0, 0, 0.75)]

服务的某个SLI的目标值，SLO的定义是 SLI<=目标值。

[color=rgba(0, 0, 0, 0.75)]

SLA计算器

[color=rgba(0, 0, 0, 0.75)]

[color=rgba(0, 0, 0, 0.75)]

SLO百分位

一天

一周

一月

一年

99%

14m12s

1h40m48s

7h18m17s

3d15h39m29s

99.9%

1m26

10m5s

43m50s

8h45m57s

99.99%

9s

1m

4m23

52m36s

99.999%

<1s

6s

26s

5m16s

99.9999%

<1s

<1s

3s

32s

[color=rgba(0, 0, 0, 0.75)]

• SLA，Service Level Agreement, 服务质量协议
  

[color=rgba(0, 0, 0, 0.75)]

服务与用户之间的一个明确的，或者不明确的协议，描述了没有达到SLO之后的后果。SLO和SLA的区别是，“如果SLO没有达到时，有什么后果?”如果没有明确定义的后果，那么我们在讨论的是SLO,而不是SLA。

[color=rgba(0, 0, 0, 0.75)]

SRE的目的

[color=rgba(0, 0, 0, 0.75)]

SRE的最终目的是提高稳定性，从业界稳定性通用的衡量标准看，有两个非常关键的指标：

[color=rgba(0, 0, 0, 0.75)]

• MTBF，Mean Time Between Failure，平均故障时间间隔。
• MTTR，Mean Time To Repair， 故障平均修复时间。
  

[color=rgba(0, 0, 0, 0.75)]

想提升稳定性，就会有两个方向：

[color=rgba(0, 0, 0, 0.75)]

• 提升 MTBF，也就是减少故障发生次数，提升故障发生间隔时长；
• 降低 MTTR，故障不可避免，那就提升故障处理效率，减少故障影响时长。
  

SRE是什么？

[color=rgba(0, 0, 0, 0.75)]

SRE(Site Reliability Engineering),站点可靠性工程,起源于2003年。在系统管理员模式下，通常是通过人工操作完成任务，而SRE倾向通过设计、构建自动化工具来取代人工操作。SRE的本质是用软件工程的思维和方法解决复杂的运维问题。

[color=rgba(0, 0, 0, 0.75)]

DevOps是在2008年年末流行起来，强调自动化替代人工操作，以及利用软件工程手段执行运维任务。DevOps的核心是"全栈交付"， SRE的出发点是“保障和提升系统稳定性”，两者要做的事情其实本质上差别不大，但是角度不同。可以认为DevOps是SRE核心理念的普适版本，SRE是DevOps模型在Google的具体实践。

[color=rgba(0, 0, 0, 0.75)]

Google SRE方法论

[color=rgba(0, 0, 0, 0.75)]

• 确保长期关注研发工作
  

[color=rgba(0, 0, 0, 0.75)]

Google将SRE团队的运维工作限制在50%以内，剩余时间花在研发项目上。实践中，SRE管理人员要经常度量团队成员的时间分配，有必要的话，可采取措施将过多的运维压力转移给研发团队。

[color=rgba(0, 0, 0, 0.75)]

• 在保障服务SLO的前提下最大化迭代速度
  

[color=rgba(0, 0, 0, 0.75)]

对于迭代创新速度与产品稳定程度之间的矛盾，可以使用“错误预算”工具处理。”错误预算”起源于这样的理念：任何产品不能，也不应该做到100%可靠。对用户来说，99.999%和100%的可用性是没有实质区别。其中，错误预算 = 1 - 可靠性目标。可以将错误预算用于新功能上线或者产品创新，如：最大化新功能的上线速度，同时保证服务质量。

[color=rgba(0, 0, 0, 0.75)]

• 监控系统
  

[color=rgba(0, 0, 0, 0.75)]

监控系统不应该依赖人来分析警报信息，而是由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。

[color=rgba(0, 0, 0, 0.75)]

• 应急事件处理
  

[color=rgba(0, 0, 0, 0.75)]

可靠性是MTTF（平均失败时间）和MTTR（平均恢复时间）的函数，通过事先预案并将最佳方法记录在“运维手册”上通常可以使MTTR降低3倍以上。

[color=rgba(0, 0, 0, 0.75)]

• 资源部署
  

[color=rgba(0, 0, 0, 0.75)]

新资源的部署与配置是相对比较危险的操作，必须要小心谨慎地执行。

[color=rgba(0, 0, 0, 0.75)]

• 效率与性能
  

[color=rgba(0, 0, 0, 0.75)]

任何盈利性服务都关心高效利用各种资源，SRE最终负责容量的部署和配置，因此SRE必须承担起任何有关利用率的讨论和改进。

[color=rgba(0, 0, 0, 0.75)]

SLA、SLO、SLI

[color=rgba(0, 0, 0, 0.75)]

• SLI, Service level Indicate, 服务质量指标
  

[color=rgba(0, 0, 0, 0.75)]

该服务的某项服务质量的一个具体化指标，请求延迟为大部分服务的一个关键SLI，除此之外有错误率，吞吐率，可用性等。这些指标的计算过程：在某一个度量时间范围内将原始数据收集起来，计算速率，平均值、百分比等汇总数据。通常用9的数量来描述可用程度，99%可用性被称为9个9，99.999%被称为5个9.

[color=rgba(0, 0, 0, 0.75)]

• SLO, Service Level Object, 服务质量目标
  

[color=rgba(0, 0, 0, 0.75)]

服务的某个SLI的目标值，SLO的定义是 SLI<=目标值。

[color=rgba(0, 0, 0, 0.75)]

SLA计算器

[color=rgba(0, 0, 0, 0.75)]

[color=rgba(0, 0, 0, 0.75)]

SLO百分位

一天

一周

一月

一年

99%

14m12s

1h40m48s

7h18m17s

3d15h39m29s

99.9%

1m26

10m5s

43m50s

8h45m57s

99.99%

9s

1m

4m23

52m36s

99.999%

<1s

6s

26s

5m16s

99.9999%

<1s

<1s

3s

32s

[color=rgba(0, 0, 0, 0.75)]

• SLA，Service Level Agreement, 服务质量协议
  

[color=rgba(0, 0, 0, 0.75)]

服务与用户之间的一个明确的，或者不明确的协议，描述了没有达到SLO之后的后果。SLO和SLA的区别是，“如果SLO没有达到时，有什么后果?”如果没有明确定义的后果，那么我们在讨论的是SLO,而不是SLA。

[color=rgba(0, 0, 0, 0.75)]

SRE的目的

[color=rgba(0, 0, 0, 0.75)]

SRE的最终目的是提高稳定性，从业界稳定性通用的衡量标准看，有两个非常关键的指标：

[color=rgba(0, 0, 0, 0.75)]

• MTBF，Mean Time Between Failure，平均故障时间间隔。
• MTTR，Mean Time To Repair， 故障平均修复时间。
  

[color=rgba(0, 0, 0, 0.75)]

想提升稳定性，就会有两个方向：

[color=rgba(0, 0, 0, 0.75)]

• 提升 MTBF，也就是减少故障发生次数，提升故障发生间隔时长；
• 降低 MTTR，故障不可避免，那就提升故障处理效率，减少故障影响时长。