在作者看来《阿波罗13号》，是有史以来最好的一部关于工程的电影，尤其是在可靠性工作方面，别人看到的可能是三个英勇的宇航员被困在太空试图重返地球，而作者看到的则是一个工程师团队的帮助受困宇航员重获新生的故事，本文将从《阿波罗13号》为引，简单了解SRE。

了解可靠性

▼

电气工程师所能接受的可靠性服务水平目标是（SLOs）5-Nines即99.999%的可用性，但在如今的WEB应用领域中是不合理的，99.999%的可用性会有多少宕机时间？

• 每日：0.9秒

• 每周：6.0秒
  

• 每月：26.3秒

• 每年：5分15.6秒

  
  

再来看下更常见的的可靠目标，如4-nines（99.99%）有多少宕机时间：

• 每天：8.6秒
  

• 每周：1分0.5秒

• 每月：4分23秒

• 每年：52分35.7秒

  
  

两者相较差了整整一个数量级，但仍只有8.6秒/天或者1分钟/周的宕机时间。

系统

▼

如果系统想达到一定的可靠性，首先需要对所有系统拥有可见性和可控性，但对于互联网领域，这是一种奢侈品。在云托管系统中，无法做到完全控制，必须依赖于云服务提供商提供的可靠性，这时就要思考，如果它停止了存储服务或有人在数据中心关闭了UPS电源备份该怎么办？

所以重点要从防止宕机转向确保快速和无数据损失的修复，要把思考从平均故障时间（MTBF）转换为平均修复时间（MTTR），因此需要建立Nassim Taleb所说的“反脆弱系统”。

网站可靠性工程（Site Reliability Engineering）

▼

而今对云托管系统如持续交付等新功能和BUG修复的期望，导致了一个全新的关于可靠性工程领域的诞生，Google一直是该领域的先驱，将其称之为SRE，这种开创性工作的方法和实践已经被归纳总结到书中，成为企业采用SRE的标准，Google定义了下面8项核心原则：

• 持久关注：通过不断地推演和演练，让错误 出来且通过工具去修复，而不是强调避免或将其最小化。

  
  

• 追求最大化SLO：解决了创新步伐与产品稳定性之间的结构性冲突，通过引入Google的错误预算来解决这个问题：在有限的时间内（如1个月/年）允许服务的不可用性（宕机时间）。

  
  

• 监控：SRE将监控自动化——不需要任何人来解释告警域的任何部分，让应用去解释，只有用户需要采取行动才会得到通知。

  
  

• 应急响应：评估应急响应有效性的关键指标是：处理团队如何迅速地将系统恢复到健康状态即MTTR。

  
  

• 变更管理：由于大多数宕机都在一个实时系统中，因此SRE规定三种方式确保自由变更管理——渐进的变更、快速而准确的问题检测、当出现问题时回滚。

  
  

• 容量规划：容量对可靠性至关重要，SRE提供了基于需求预测的容量规划指导，以及负载测试以验证基础设施的原始容量（计算、存储和网络容量）及服务容量（服务运行和规模的能力）之间的相关性。

  
  

• 配置：变更管理和容量管理都需要配置，由于容量是昂贵的，所以需要配置快速、准确和高效。

  
  

• 效率和性能：SRE提供了如何配置正确的容量去满足需求处理的响应速度指导，保持服务性能和利用率的最佳状态，因为服务的负载随时间而变化，这与容量规划和配置都是密切相关的。

  
  

Google的实践经验

▼

当公司运行了多个应用或服务时会遇到SRE（或Ops）的支持极限问题，该如何做出有原则且合理的决定？该给予SREs多大的支持？以及何时改变子集？

Google有SRE团队去支持基础设施（存储、网络、负载均衡等）以及主要的应用（搜索、地图、照片等）尽管如此，对开发和运维技能的双重要求仍使得招聘SREs变得困难。

随着时间推移，SRE团队能够支持的应用数量是有限制的，如果公司运行了很多个应用，可能无法全部支持。

该如何了解公司的SRE团队是否达到极限，下面将进行深入地讨论：

SRE支持的上限

Google最小的SRE团队有6名工程师，需要在30分钟内进行响应，因为不想任何工程师超过12个小时的持续待命，这意味着需要两组由6名工程师组成的SRE团队。

通常会有一个指定的主服务器响应页面，另一个则会捕获页面，如果主服务器宕机或正在处理其它业务，那么初级和次要服务器就会进行操作，如提高可靠性、建立更好的监控或提高操作任务的自动化程度，因此每个工程师都有两周的时间，从6个方面进行工作。

12到16个SRE是否可以为开发团队编写的所有应用提供支持？答案是不能，SRE团队能够有效地管理多少个不同的应用或服务，存在一个明确的认知限制，所有工程师都需要充分熟悉每个应用故障时的生产问题，如果想尽可能多的支持多应用，那么就需要推出自动化工具：如监控和报警，即便如此也无法保证全部支持。

SRE团队所支持的服务最大数量将受到如下因素的影响：

• 常规任务：如发布、BUG修复、非紧急告警/BUG，这些可以通过自动化减少（但不能消除）

  
  

• 计划外的非关键人需求：最有效的策略是自助服务工具，可以处理50—70的需求。

  
  

• 告警、事故管理和后续：让服务更加可靠是减少修复时间的最好办法。

  
  

SRE的企业级落地

▼

企业为什么要采用SRE？就像其他的转换一样——从采用敏捷开发到采用DevOps再到云技术，在组织结构和文化上的变革很难让企业接受，需要通过购买、赞助以及企业范围内的意愿去进行转变，企业需要打破传统的团队结构，职能部门以及权力分封，而这些人从执行者到管理者都不愿放手。

当新的功能和方法被引入时，危机感就会出现很多人的脑海当中：如果所有的一切都可以自动化，我的工作会发生怎样的变化？如果我所做的这些工作都可以用应用来管理，那么我还能留住这份工作吗？我不懂编程，在这个应用驱动的IT世界中如何生存？

所以企业要落地实践SRE，需要从多方向多维度去思考，贴合自身的实际情况考虑是否适合，但正如万事开头难一样，有太多成功的例子这里不再赘述。

原创： Sanjeev Sharma

在作者看来《阿波罗13号》，是有史以来最好的一部关于工程的电影，尤其是在可靠性工作方面，别人看到的可能是三个英勇的宇航员被困在太空试图重返地球，而作者看到的则是一个工程师团队的帮助受困宇航员重获新生的故事，本文将从《阿波罗13号》为引，简单了解SRE。

了解可靠性

▼

电气工程师所能接受的可靠性服务水平目标是（SLOs）5-Nines即99.999%的可用性，但在如今的WEB应用领域中是不合理的，99.999%的可用性会有多少宕机时间？

• 每日：0.9秒

• 每周：6.0秒
  

• 每月：26.3秒

• 每年：5分15.6秒

  
  

再来看下更常见的的可靠目标，如4-nines（99.99%）有多少宕机时间：

• 每天：8.6秒
  

• 每周：1分0.5秒

• 每月：4分23秒

• 每年：52分35.7秒

  
  

两者相较差了整整一个数量级，但仍只有8.6秒/天或者1分钟/周的宕机时间。

系统

▼

如果系统想达到一定的可靠性，首先需要对所有系统拥有可见性和可控性，但对于互联网领域，这是一种奢侈品。在云托管系统中，无法做到完全控制，必须依赖于云服务提供商提供的可靠性，这时就要思考，如果它停止了存储服务或有人在数据中心关闭了UPS电源备份该怎么办？

所以重点要从防止宕机转向确保快速和无数据损失的修复，要把思考从平均故障时间（MTBF）转换为平均修复时间（MTTR），因此需要建立Nassim Taleb所说的“反脆弱系统”。

网站可靠性工程（Site Reliability Engineering）

▼

而今对云托管系统如持续交付等新功能和BUG修复的期望，导致了一个全新的关于可靠性工程领域的诞生，Google一直是该领域的先驱，将其称之为SRE，这种开创性工作的方法和实践已经被归纳总结到书中，成为企业采用SRE的标准，Google定义了下面8项核心原则：

• 持久关注：通过不断地推演和演练，让错误 出来且通过工具去修复，而不是强调避免或将其最小化。

  
  

• 追求最大化SLO：解决了创新步伐与产品稳定性之间的结构性冲突，通过引入Google的错误预算来解决这个问题：在有限的时间内（如1个月/年）允许服务的不可用性（宕机时间）。

  
  

• 监控：SRE将监控自动化——不需要任何人来解释告警域的任何部分，让应用去解释，只有用户需要采取行动才会得到通知。

  
  

• 应急响应：评估应急响应有效性的关键指标是：处理团队如何迅速地将系统恢复到健康状态即MTTR。

  
  

• 变更管理：由于大多数宕机都在一个实时系统中，因此SRE规定三种方式确保自由变更管理——渐进的变更、快速而准确的问题检测、当出现问题时回滚。

  
  

• 容量规划：容量对可靠性至关重要，SRE提供了基于需求预测的容量规划指导，以及负载测试以验证基础设施的原始容量（计算、存储和网络容量）及服务容量（服务运行和规模的能力）之间的相关性。

  
  

• 配置：变更管理和容量管理都需要配置，由于容量是昂贵的，所以需要配置快速、准确和高效。

  
  

• 效率和性能：SRE提供了如何配置正确的容量去满足需求处理的响应速度指导，保持服务性能和利用率的最佳状态，因为服务的负载随时间而变化，这与容量规划和配置都是密切相关的。

  
  

Google的实践经验

▼

当公司运行了多个应用或服务时会遇到SRE（或Ops）的支持极限问题，该如何做出有原则且合理的决定？该给予SREs多大的支持？以及何时改变子集？

Google有SRE团队去支持基础设施（存储、网络、负载均衡等）以及主要的应用（搜索、地图、照片等）尽管如此，对开发和运维技能的双重要求仍使得招聘SREs变得困难。

随着时间推移，SRE团队能够支持的应用数量是有限制的，如果公司运行了很多个应用，可能无法全部支持。

该如何了解公司的SRE团队是否达到极限，下面将进行深入地讨论：

SRE支持的上限

Google最小的SRE团队有6名工程师，需要在30分钟内进行响应，因为不想任何工程师超过12个小时的持续待命，这意味着需要两组由6名工程师组成的SRE团队。

通常会有一个指定的主服务器响应页面，另一个则会捕获页面，如果主服务器宕机或正在处理其它业务，那么初级和次要服务器就会进行操作，如提高可靠性、建立更好的监控或提高操作任务的自动化程度，因此每个工程师都有两周的时间，从6个方面进行工作。

12到16个SRE是否可以为开发团队编写的所有应用提供支持？答案是不能，SRE团队能够有效地管理多少个不同的应用或服务，存在一个明确的认知限制，所有工程师都需要充分熟悉每个应用故障时的生产问题，如果想尽可能多的支持多应用，那么就需要推出自动化工具：如监控和报警，即便如此也无法保证全部支持。

SRE团队所支持的服务最大数量将受到如下因素的影响：

• 常规任务：如发布、BUG修复、非紧急告警/BUG，这些可以通过自动化减少（但不能消除）

  
  

• 计划外的非关键人需求：最有效的策略是自助服务工具，可以处理50—70的需求。

  
  

• 告警、事故管理和后续：让服务更加可靠是减少修复时间的最好办法。

  
  

SRE的企业级落地

▼

企业为什么要采用SRE？就像其他的转换一样——从采用敏捷开发到采用DevOps再到云技术，在组织结构和文化上的变革很难让企业接受，需要通过购买、赞助以及企业范围内的意愿去进行转变，企业需要打破传统的团队结构，职能部门以及权力分封，而这些人从执行者到管理者都不愿放手。

当新的功能和方法被引入时，危机感就会出现很多人的脑海当中：如果所有的一切都可以自动化，我的工作会发生怎样的变化？如果我所做的这些工作都可以用应用来管理，那么我还能留住这份工作吗？我不懂编程，在这个应用驱动的IT世界中如何生存？

所以企业要落地实践SRE，需要从多方向多维度去思考，贴合自身的实际情况考虑是否适合，但正如万事开头难一样，有太多成功的例子这里不再赘述。

原创： Sanjeev Sharma