[size=100%][size=100%]                    

                          

推出SRE系列译文，为大家带来国外SRE的深刻解读与实践。本文基于作者组建相应SRE组织总结出来的经验，提供了大家开始SRE之旅之前需要思考的各方面问题。

[size=100%]SRE最近已成为许多公司间一个热门讨论的话题。什么是SRE？谁是SRE？我们如何实现？对于这个话题我当然也有自己的一些观点。但是大部分观点都有一个共同点，SRE不仅是工具和技术，它更是在企业内部的一种文化转变。现在，作为一个免责声明我想说以下的内容只是基于我自己组建相应组织的一些经验，以及通过和其他一些已经实施或正在实施SRE的组织交流而总结出来的。建立SRE体系没有一个统一的处方，每个企业都会找到适合自身组织体系和运营模式的方法。仅仅因为这是一种流行趋势而强迫引入这种文化绝非一种正确的态度，这些都要取决于企业自身。

[size=100%]定义

[size=100%]在这篇文章中，会使用到一些不同的术语。将它们统一提出这样大家在阅读的时候就不用再去查询这些术语。定义非常简短，后面会深入阐述。

  
• SRE- 网站可靠性工程师，具有软件工程背景，又对基础设施和运维感兴趣的个人。
    
• SWE - 软件工程师。
    
• 基础设施SRE- SRE的一个分支，主要是处理和基础设施相关的工作如监控、配置、基础云架构等。
    
• 应用/服务SRE- SRE的一个分支，是专用于特定的应用/服务组。这些应用/服务组都是为公司营收开发新的产品。
  

什么/谁是SRE?

  
• SRE定义比较分散，不同的人对它有不同的理解。下面总结一下个人理解的SRE：
    
• SRE聚集了具备一系列广泛技能人员的核心素质。这些技能范围包括运维，网络，开发，硬件，分布式系统，监测，稳定性，能力规划等。
    
• SRE负责就基础架构的所有方面向任何寻求支持的团队提供建议和评估。
    
• SRE不仅仅是技术，更是一种心态，一种思维过程和文化转变。这些特点是由经验丰富的个人带入组织，以推动整个团队前进。
    
• SRE不应该在公司强制推广，需要SRE支持的团队可以选择建立SRE。
  

责任范围

[size=100%]由于SRE的技术具有很多不同的方面，似乎很难缩小SRE实际应该花费时间和精力的地方。这些人不会直接面向公众的产品或功能（当然这完全取决于你的公司），那他们的职责到底应该覆盖什么范围呢？当然SRE的责任绝非仅限于以下所列内容，但这应该是SRE团队需要关注的基本范畴。如果无法对底层基础设施进行合适地搭建、监测、测量，那就很难对组织外部成员宣扬这种新的文化。看到以下项目也许会觉得基础架构部分很重，其实很多项目可以拆分成基础设施SRE和应用SRE，一个是主要的生产者，另一个是主要的消费者。

  
• 监测
    
• 配置管理和自动化
    
• 大数据/数据仓库
    
• 核心基础设施服务，工具和容量规划和系统
    
• 性能文件和运行手册
    
• 事件响应
  

SRE是单一的团队还是多个团队？

[size=100%]这是一个很多人都疑惑的问题。我极力推荐将SRE分成多个小组（基础设施/监控/工具/应用/服务等）。虽然它会按照某种逻辑进行拆分但是汇报链始终都应保持在组织内部。个人看来，打破这种集中的层级结构会导致SRE实行的失败，需要集中汇报的原因在于SRE应该向有相同思维方式的人报告，这些个人（领导）将为建立工具而提供协助，这是团队成功的关键。他们还能提供有关通用工具集、最佳实践和架构指导的信息。有一件事是值得考虑的，那就是最初的应用/服务SRE可以选择应用程序/服务团队中对运维和基础架构有兴趣的成员，可以先用他们因为他们最接近代码，既可以转变为SRE也可以再回到团队继续做软件工程师。

[size=100%]应用软件工程师团队和基础架构需要不同层次的支持。应用程序SRE会花费70%左右的时间来服务应用/服务团队，而其他的30%将用于协助其他领域的SRE（主要是基础架构相关的项目）。基础架构SRE首先要集中精力在基础设施相关的产品/服务等上，较少与开发功能的应用团队有直接的合作。这两者不一定要分开工作，但他们尊重对方的侧重点。

[size=100%]确保SRE团队不是一个垃圾场，只接收应用团队不想做的工作。这种情况之前是见过的，它很快破坏了嵌入式团队和应用程序/服务团队之间的关系。应该将部分业务相关的运维工作分配给应用/服务团队（大约5-10%），这样他们可以更加了解环境也知晓底层在发生什么，使得成员在团队中流动成为可能，如果项目可以自动运行则不再需要专职的SRE支持。

[size=100%]应用/服务SRE和基础设施的SRE

[size=100%]应用SRE

  
• 应用/服务团队的嵌入
    
• 对应用程序/服务团队内部的支持
    
• 团队应用程序和服务的自动化
    
• 为应用程序/服务团队进行监控/测量
    
• 对代码的基准和性能辅助
    
• 应用程序和服务的基础设施部署和架构
    
• 为应用/服务栈警报发布写文档和运行手册
  

基础设施SRE

  
• 建立和管理核心基础设施（配置、操作系统、DNS、DHCP、网络等）
    
• 基础设施服务自动化（遥测，日志汇总，Chef等）
    
• 为外部团队建立和文档化的工具/服务
    
• 支持应用SRE团队
    
• 用代码来搭建基础设施
    
• 为应用SRE团队提供的架构指南和协助
    
• 最佳实践和文档记录
  

组织架构

[size=100%]建设SRE就应该及早解决组织架构的问题，组织必须集中化。画一个图来显示应用程序SRE和基础设施SRE的分类逻辑。团队领导可以依据类型和项目来处理复杂的应用程序/基础设施团队，根据组织特点来设定团队领导/经理/总监等级别，目前进行组织分隔的标准就是如此。

[size=100%]SRE内部协作的例子

[size=100%]下面是Ruby应用程序团队和SRE团队之间协作的一个典型案例。可以注意下底部增加了一个额外的支持，这一部分方法并非必须但是能避免大家精疲力竭。一线支持的职责是按照运行手册运行和处理来自监控系统的告警。如果发生紧急事件该员工将获得监控页面的第一手信息。外包这个部分也可以雇佣驻厂人员来处理，对于一个刚刚开始运维工作并希望了解尽可能多的堆栈知识的初级员工来说这是一个伟大的起点。我们习惯于把新的SRE和有经验的团队成员分成一组，然后在第一周左右就去执行值班任务，这能让他们够快速学习，根据过往经验当一个新成员加入后这种做法是非常有效的。

[size=100%]总结

[size=100%]对于SRE其实还有很多内容，在此谈了一些开始SRE之旅时需要最先思考的问题。目前已经有很多公司在组织内部实施了SRE文化可供参考。要记住，没有公式，对别人有用的对你未必有用，必须真正推动组织内部对SRE文化转变的理解并确保每个人都准备好了，只要大家全力协作，可能性是无穷无尽的。感谢阅读！

[size=100%][size=100%]                    

                          

推出SRE系列译文，为大家带来国外SRE的深刻解读与实践。本文基于作者组建相应SRE组织总结出来的经验，提供了大家开始SRE之旅之前需要思考的各方面问题。

[size=100%]SRE最近已成为许多公司间一个热门讨论的话题。什么是SRE？谁是SRE？我们如何实现？对于这个话题我当然也有自己的一些观点。但是大部分观点都有一个共同点，SRE不仅是工具和技术，它更是在企业内部的一种文化转变。现在，作为一个免责声明我想说以下的内容只是基于我自己组建相应组织的一些经验，以及通过和其他一些已经实施或正在实施SRE的组织交流而总结出来的。建立SRE体系没有一个统一的处方，每个企业都会找到适合自身组织体系和运营模式的方法。仅仅因为这是一种流行趋势而强迫引入这种文化绝非一种正确的态度，这些都要取决于企业自身。

[size=100%]定义

[size=100%]在这篇文章中，会使用到一些不同的术语。将它们统一提出这样大家在阅读的时候就不用再去查询这些术语。定义非常简短，后面会深入阐述。

  
• SRE- 网站可靠性工程师，具有软件工程背景，又对基础设施和运维感兴趣的个人。
    
• SWE - 软件工程师。
    
• 基础设施SRE- SRE的一个分支，主要是处理和基础设施相关的工作如监控、配置、基础云架构等。
    
• 应用/服务SRE- SRE的一个分支，是专用于特定的应用/服务组。这些应用/服务组都是为公司营收开发新的产品。
  

什么/谁是SRE?

  
• SRE定义比较分散，不同的人对它有不同的理解。下面总结一下个人理解的SRE：
    
• SRE聚集了具备一系列广泛技能人员的核心素质。这些技能范围包括运维，网络，开发，硬件，分布式系统，监测，稳定性，能力规划等。
    
• SRE负责就基础架构的所有方面向任何寻求支持的团队提供建议和评估。
    
• SRE不仅仅是技术，更是一种心态，一种思维过程和文化转变。这些特点是由经验丰富的个人带入组织，以推动整个团队前进。
    
• SRE不应该在公司强制推广，需要SRE支持的团队可以选择建立SRE。
  

责任范围

[size=100%]由于SRE的技术具有很多不同的方面，似乎很难缩小SRE实际应该花费时间和精力的地方。这些人不会直接面向公众的产品或功能（当然这完全取决于你的公司），那他们的职责到底应该覆盖什么范围呢？当然SRE的责任绝非仅限于以下所列内容，但这应该是SRE团队需要关注的基本范畴。如果无法对底层基础设施进行合适地搭建、监测、测量，那就很难对组织外部成员宣扬这种新的文化。看到以下项目也许会觉得基础架构部分很重，其实很多项目可以拆分成基础设施SRE和应用SRE，一个是主要的生产者，另一个是主要的消费者。

  
• 监测
    
• 配置管理和自动化
    
• 大数据/数据仓库
    
• 核心基础设施服务，工具和容量规划和系统
    
• 性能文件和运行手册
    
• 事件响应
  

SRE是单一的团队还是多个团队？

[size=100%]这是一个很多人都疑惑的问题。我极力推荐将SRE分成多个小组（基础设施/监控/工具/应用/服务等）。虽然它会按照某种逻辑进行拆分但是汇报链始终都应保持在组织内部。个人看来，打破这种集中的层级结构会导致SRE实行的失败，需要集中汇报的原因在于SRE应该向有相同思维方式的人报告，这些个人（领导）将为建立工具而提供协助，这是团队成功的关键。他们还能提供有关通用工具集、最佳实践和架构指导的信息。有一件事是值得考虑的，那就是最初的应用/服务SRE可以选择应用程序/服务团队中对运维和基础架构有兴趣的成员，可以先用他们因为他们最接近代码，既可以转变为SRE也可以再回到团队继续做软件工程师。

[size=100%]应用软件工程师团队和基础架构需要不同层次的支持。应用程序SRE会花费70%左右的时间来服务应用/服务团队，而其他的30%将用于协助其他领域的SRE（主要是基础架构相关的项目）。基础架构SRE首先要集中精力在基础设施相关的产品/服务等上，较少与开发功能的应用团队有直接的合作。这两者不一定要分开工作，但他们尊重对方的侧重点。

[size=100%]确保SRE团队不是一个垃圾场，只接收应用团队不想做的工作。这种情况之前是见过的，它很快破坏了嵌入式团队和应用程序/服务团队之间的关系。应该将部分业务相关的运维工作分配给应用/服务团队（大约5-10%），这样他们可以更加了解环境也知晓底层在发生什么，使得成员在团队中流动成为可能，如果项目可以自动运行则不再需要专职的SRE支持。

[size=100%]应用/服务SRE和基础设施的SRE

[size=100%]应用SRE

  
• 应用/服务团队的嵌入
    
• 对应用程序/服务团队内部的支持
    
• 团队应用程序和服务的自动化
    
• 为应用程序/服务团队进行监控/测量
    
• 对代码的基准和性能辅助
    
• 应用程序和服务的基础设施部署和架构
    
• 为应用/服务栈警报发布写文档和运行手册
  

基础设施SRE

  
• 建立和管理核心基础设施（配置、操作系统、DNS、DHCP、网络等）
    
• 基础设施服务自动化（遥测，日志汇总，Chef等）
    
• 为外部团队建立和文档化的工具/服务
    
• 支持应用SRE团队
    
• 用代码来搭建基础设施
    
• 为应用SRE团队提供的架构指南和协助
    
• 最佳实践和文档记录
  

组织架构

[size=100%]建设SRE就应该及早解决组织架构的问题，组织必须集中化。画一个图来显示应用程序SRE和基础设施SRE的分类逻辑。团队领导可以依据类型和项目来处理复杂的应用程序/基础设施团队，根据组织特点来设定团队领导/经理/总监等级别，目前进行组织分隔的标准就是如此。

[size=100%]SRE内部协作的例子

[size=100%]下面是Ruby应用程序团队和SRE团队之间协作的一个典型案例。可以注意下底部增加了一个额外的支持，这一部分方法并非必须但是能避免大家精疲力竭。一线支持的职责是按照运行手册运行和处理来自监控系统的告警。如果发生紧急事件该员工将获得监控页面的第一手信息。外包这个部分也可以雇佣驻厂人员来处理，对于一个刚刚开始运维工作并希望了解尽可能多的堆栈知识的初级员工来说这是一个伟大的起点。我们习惯于把新的SRE和有经验的团队成员分成一组，然后在第一周左右就去执行值班任务，这能让他们够快速学习，根据过往经验当一个新成员加入后这种做法是非常有效的。

[size=100%]总结

[size=100%]对于SRE其实还有很多内容，在此谈了一些开始SRE之旅时需要最先思考的问题。目前已经有很多公司在组织内部实施了SRE文化可供参考。要记住，没有公式，对别人有用的对你未必有用，必须真正推动组织内部对SRE文化转变的理解并确保每个人都准备好了，只要大家全力协作，可能性是无穷无尽的。感谢阅读！