[size=100%]这句话的意思是，SRE 成员的工作，从软件系统设计的最初，即用户提出最开始的需求、想法，就已经开始了。什么意思呢？就是说，SRE 的工作贯穿软件系统的整个生命周期，从需求分析到维护，直至停止软件的使用。

[size=100%]其实，SRE 的本质就是IT服务管理（IT service management）。SRE 是服务和用户体验的管理员和守护神。

[size=100%]IT 终究来说只是手段，是方式，而我们的目的则是为用户提供满足用户需求的 IT 服务。而 IT 服务管理，则可以认为涵盖为用户提供 IT 服务这一目的的所有相关活动，从软件设计、开发、测试到运维和维护。从时间跨度来说，一套软件系统，用于维护和运维的时间，要比开发和测试的时间长得多，而我们软件技术的重点，多数都集中于前期阶段，而以运维和维护为中心的技术并没有那么多。

[size=100%]IT 服务管理，可不止软件开发和测试那么简单，也不是单纯的基础设施运维，还包括用户体验、系统安全性、等等众多方面，可以说，是一个即涉及技术又涉及到管理的一个理念。

[size=100%]这里再简单聊聊 SRE 的起源。

[size=100%]Benjamin Treynor Sloss 目前是 Google 的工程副总裁，也负责Google cloud platform，他于2003年就创建了 SRE 团队，其实那时的名字叫做“Production Team”，团队只有7人，不过7人都是软件工程师，也就是说，从开始那一天，软件工程师的灵魂就植入到了 SRE 之中。

[size=100%]截止到2016年，Ben 下面的 SRE 团队在全球已经达到了2000人的规模，和创立当初一样，到现在团队也没有改变以软件开发为中心的初衷。

[size=100%]不过，Google 开始对外部宣传 SRE 相关理念也只是从3-4年前开始而已，在 SREcon14 上，Ben 介绍了 Google 这11年间学习总结的 SRE 原则和经验，这一思想才逐渐被世人所熟知。

[size=100%]SRE 的职（bēi）责（guō）是什么？

[size=100%]SRE 既然涉及到软件系统设计、开发、实施和维护的各个阶段，那么他的职责也分布在这些领域中。虽然根据各个公司的业务领域和研发体制不同，其职责有所不同，不过基本上SRE的职责主要集中在以下两个方面：

  
• [size=100%]IT 运营
  
    
• [size=100%]提高系统的可用性
  
  

[size=100%]这里的运营，其实就是运维的意思，因为英语本身就是 operation，我们习惯上更习惯翻译为运维。IT 运营主要包括设计基础设施、部署、持续集成以及监控和故障监测、修复。

[size=100%]提高系统的可用性，相对于传统的运维观点来说，更强调 SRE 的主动性，更体现作为软件工程师这一角色的特点，即通过编码来改善系统的稳定性，提高性能，增强可扩展性等等。相对于传统的运维，提供高于预期的价值。

[size=100%]这两方面的内容，也可以理解为及格和优秀这两个层次，及格是基本要求，做到优秀是我们追求的目标。

[size=100%]更详细来说，其具体工作可能包括以下这些内容，会很细分，范围也很广：

  
• [size=100%]确保 API 的平均延迟低于 xx ms；
  
    
• [size=100%]SLA 达到99.9%；
  
    
• [size=100%]数据库系统备份；
  
    
• [size=100%]构建统一的开发环境；
  
    
• [size=100%]设计 Log 采集系统；
  
    
• [size=100%]... ...
  
  

[size=100%]也就是说，上面这些领域出了问题， SRE 要背锅、补锅，兼带甩锅。

[size=100%]对 SRE 的技能要求

[size=100%]从技能要求来说，SRE = Operations + Software Engineering，可以说，SRE 团队的成员，首先是软件开发者，其次，还需要具备基 Linux 和网络等基础设施方面的知识，通过编码，让自己的运维工作更有效、迅速和可靠。

[size=100%]在 Google，SRE 的工作也有很多是在本职产品开发上，如果 Google 服务发生了故障，不管是 Gmail 还是 Calendar 或是其他产品，SRE 都可能回去阅读其相应源代码，甚至修改代码、修复缺陷。

[size=100%]如果是这样，其实 SRE 对人的要求还是蛮高的，至少在下面这些方面：

  
• [size=100%]操作系统内核，比如 Linux kernel
  
    
• [size=100%]网络
  
    
• [size=100%]数据库、存储等知识
  
    
• [size=100%]编码能力
  
    
• [size=100%]解决问题的能力
  
    
• [size=100%]沟通能力
  
    
• [size=100%]大规模、分布式系统设计能力
  
    
• [size=100%]... ...
  
  

[size=100%]这么说可能有点夸张，SRE 怎么也得能通过裁剪内核来优化系统性能，修改内核参数来提高 TCP 传输；规划得了大二层，配置得了 VxLan ；搞得定 Open Stack，玩得转 Docker；调得了 JVM ，优化得了 Rails ; 左手 Mesos，右手 K8s ... ... 这样的人才，怎么也值得了川普的 $130k 标准吧。

[size=100%]SRE 和 DevOps有啥区别 ？

[size=100%]那你要问了，DevOps 我还没搞清呢，咋又出来个 SRE ？这两货有啥区别？

[size=100%]之所有有此一问，肯定是它们有很多共同点。确实，DevOps 和 SRE 都重视自动化和文档，崇尚信息共享，讲究持续改善，一切以数据说话，对事而非对人等等。

[size=100%]DevOps 概念最初是由 Flick 在2009年的 Velocity 2009 上名为「10 deploys per day : Dev&Ops cooperation at Flickr」演讲中提出的。从时间上来说，比 SRE 晚了6年（这个数字其实是有疑问的，2003年只是 Ben 的 Production team 创立的时间，至于 SRE 这个职位是什么时候出现的，大叔也还没找到）

[size=100%]那它们之间到底有没有点区别？

[size=100%]就大叔目前的水平，也回答不好，这里试着回答，也只是权当为自己解惑。

[size=100%]DevOps 和 SRE 一个比较明显的区别就是，在于 E 这个字母上，即 SRE 要求成员有很强的编码能力，更偏向于一个开者的角色。就像 Google SRE 官网上写道的一样：

[size=100%]Like traditional operations groups, we keep important, revenue-critical systems up and running despite hurricanes, bandwidth outages, and configuration errors. Unlike traditional operations groups, we view software as the primary tool through which our systems are managed, maintained, and minded

[size=100%]还有一点，SRE 更注重提高系统的可靠性和可用性，更强调主动出击。

[size=100%]另一点，DevOps 一般多指一个工作方式或者流程，DevOps 的定义中就包括 Dev 和 Ops 互相协作，识别并规避风险；而 SRE 有时多指一个具体的职位，也就是个人。

[size=100%]具体到 Google 这本书的例子，我们可以理解为 DevOps 更抽象，SRE 更具体，比如 SRE 定义了 Error Budget，PRR（Production Readiness Review），Postmortem，ICS（Incident Command System）等具体化方法和工具。

[size=100%]如果你觉得这个回答不够满意，或者有问题，欢迎留言或者私信，谢谢。

[size=100%]最后总结一下，按照本书的观点， SRE 是 DevOps 模型在 Google 的一个具体实践，带有自己独特的扩展；DevOps 是 SRE 核心理念的普适版，可以用于更大范围的组织结构之内。

[size=100%]那我们公司也能采用 SRE 机制么 ？

[size=100%]说了半天 SRE 这么好那么好，Google 的这一套我们能拿来直接用么？

[size=100%]大叔觉得，SRE 虽然比较新，但是核心内容很多公司都是具备的，在满足下面两个条件的前提下，还是不难的：

  
• [size=100%]有人
  
    
• [size=100%]有钱
  
  

[size=100%]有人不是人多，是要人厉害。前面我们已经看到了，SRE 对人的要求还是比较高的，既要通才，还要专才；既要熟悉本职工作，还要对其他非主要职责的模块比较熟悉；装的了系统，调得了网络；写得了 Python，改得了 Golang ... ... 这是对人才方面的要求，这是最基本的。

[size=100%]其次有钱。雇得起人才，还得培养得起人，消耗得起成本。

[size=100%]人才培养很重要，雇佣一帮自学成才的大牛不现实，招聘有潜力的人，通过组织环境和大牛培养起来才是最靠谱的途径，这也需要成本。最后，SRE 成员的工作时间可能会只有50%来用于实际产品开发，势必会影响开发进度，这也是可以用成本来衡量的。

[size=100%]至于其余其他因素，比如组织架构、工作习惯或者企业文化什么的则并不是什么阻碍，当然前提是需要先解决前面两个问题。

[size=100%]“

[size=100%]福利来了

[size=100%]前面我们一直在说这本名为《Site Reliability Engineering: How Google Runs Production Systems》的书，这本简直可以称得上是国内 SRE 理念的启蒙书。就是中文版稍微有点贵。

[size=100%]不过前几天，Google 在他们的网站上放上了这本书，供人们免费阅读。如果你英语好，或者不想买中文版，可以看看 Google 为 SRE 专门设立的网站 sre/ ，这里有这本书的电子版（在线），点击 阅读原文也可以查看在线电子版。

[size=100%]那我们就来看看这本书，全书共分5部分。

[size=100%]第一部分主要介绍了 SRE 的解决之道以及 Google 生产环境和背景。

[size=100%]第二部分是原则篇，主要介绍了一些体制和机制方面的原则，比如监控、自动化和发布等。尤其是发布，是关系到系统稳定性的最关键因素，我们可以想想自己的系统有多少是和上线新功能或者升级相关的吧。

[size=100%]第三部分是实践篇，理论结合实践，在科研上还是工程上，都是不二法宝，缺一不可，没有理论的实践，只能算是无用功，只能不停地重复劳动，不能升华和传播，不能普及世人；而没有实践的支撑，理论也不过是空想，于现实没有任何促进作用。这部分介绍了 Google 的 On-Call 制度、事故报告和总结等实践性强、比较容易借鉴的经验，相信很多部分都可以为我们效仿和定制。

[size=100%]第四部分是管理篇，这部分跳出个人的单独工作细节，介绍了如何在组织内部和其他团队、部门的协作。好方法、好实践不被组织级别重视，都属于暴殄天物，浪费。

[size=100%]这句话的意思是，SRE 成员的工作，从软件系统设计的最初，即用户提出最开始的需求、想法，就已经开始了。什么意思呢？就是说，SRE 的工作贯穿软件系统的整个生命周期，从需求分析到维护，直至停止软件的使用。

[size=100%]其实，SRE 的本质就是IT服务管理（IT service management）。SRE 是服务和用户体验的管理员和守护神。

[size=100%]IT 终究来说只是手段，是方式，而我们的目的则是为用户提供满足用户需求的 IT 服务。而 IT 服务管理，则可以认为涵盖为用户提供 IT 服务这一目的的所有相关活动，从软件设计、开发、测试到运维和维护。从时间跨度来说，一套软件系统，用于维护和运维的时间，要比开发和测试的时间长得多，而我们软件技术的重点，多数都集中于前期阶段，而以运维和维护为中心的技术并没有那么多。

[size=100%]IT 服务管理，可不止软件开发和测试那么简单，也不是单纯的基础设施运维，还包括用户体验、系统安全性、等等众多方面，可以说，是一个即涉及技术又涉及到管理的一个理念。

[size=100%]这里再简单聊聊 SRE 的起源。

[size=100%]Benjamin Treynor Sloss 目前是 Google 的工程副总裁，也负责Google cloud platform，他于2003年就创建了 SRE 团队，其实那时的名字叫做“Production Team”，团队只有7人，不过7人都是软件工程师，也就是说，从开始那一天，软件工程师的灵魂就植入到了 SRE 之中。

[size=100%]截止到2016年，Ben 下面的 SRE 团队在全球已经达到了2000人的规模，和创立当初一样，到现在团队也没有改变以软件开发为中心的初衷。

[size=100%]不过，Google 开始对外部宣传 SRE 相关理念也只是从3-4年前开始而已，在 SREcon14 上，Ben 介绍了 Google 这11年间学习总结的 SRE 原则和经验，这一思想才逐渐被世人所熟知。

[size=100%]SRE 的职（bēi）责（guō）是什么？

[size=100%]SRE 既然涉及到软件系统设计、开发、实施和维护的各个阶段，那么他的职责也分布在这些领域中。虽然根据各个公司的业务领域和研发体制不同，其职责有所不同，不过基本上SRE的职责主要集中在以下两个方面：

  
• [size=100%]IT 运营
  
    
• [size=100%]提高系统的可用性
  
  

[size=100%]这里的运营，其实就是运维的意思，因为英语本身就是 operation，我们习惯上更习惯翻译为运维。IT 运营主要包括设计基础设施、部署、持续集成以及监控和故障监测、修复。

[size=100%]提高系统的可用性，相对于传统的运维观点来说，更强调 SRE 的主动性，更体现作为软件工程师这一角色的特点，即通过编码来改善系统的稳定性，提高性能，增强可扩展性等等。相对于传统的运维，提供高于预期的价值。

[size=100%]这两方面的内容，也可以理解为及格和优秀这两个层次，及格是基本要求，做到优秀是我们追求的目标。

[size=100%]更详细来说，其具体工作可能包括以下这些内容，会很细分，范围也很广：

  
• [size=100%]确保 API 的平均延迟低于 xx ms；
  
    
• [size=100%]SLA 达到99.9%；
  
    
• [size=100%]数据库系统备份；
  
    
• [size=100%]构建统一的开发环境；
  
    
• [size=100%]设计 Log 采集系统；
  
    
• [size=100%]... ...
  
  

[size=100%]也就是说，上面这些领域出了问题， SRE 要背锅、补锅，兼带甩锅。

[size=100%]对 SRE 的技能要求

[size=100%]从技能要求来说，SRE = Operations + Software Engineering，可以说，SRE 团队的成员，首先是软件开发者，其次，还需要具备基 Linux 和网络等基础设施方面的知识，通过编码，让自己的运维工作更有效、迅速和可靠。

[size=100%]在 Google，SRE 的工作也有很多是在本职产品开发上，如果 Google 服务发生了故障，不管是 Gmail 还是 Calendar 或是其他产品，SRE 都可能回去阅读其相应源代码，甚至修改代码、修复缺陷。

[size=100%]如果是这样，其实 SRE 对人的要求还是蛮高的，至少在下面这些方面：

  
• [size=100%]操作系统内核，比如 Linux kernel
  
    
• [size=100%]网络
  
    
• [size=100%]数据库、存储等知识
  
    
• [size=100%]编码能力
  
    
• [size=100%]解决问题的能力
  
    
• [size=100%]沟通能力
  
    
• [size=100%]大规模、分布式系统设计能力
  
    
• [size=100%]... ...
  
  

[size=100%]这么说可能有点夸张，SRE 怎么也得能通过裁剪内核来优化系统性能，修改内核参数来提高 TCP 传输；规划得了大二层，配置得了 VxLan ；搞得定 Open Stack，玩得转 Docker；调得了 JVM ，优化得了 Rails ; 左手 Mesos，右手 K8s ... ... 这样的人才，怎么也值得了川普的 $130k 标准吧。

[size=100%]SRE 和 DevOps有啥区别 ？

[size=100%]那你要问了，DevOps 我还没搞清呢，咋又出来个 SRE ？这两货有啥区别？

[size=100%]之所有有此一问，肯定是它们有很多共同点。确实，DevOps 和 SRE 都重视自动化和文档，崇尚信息共享，讲究持续改善，一切以数据说话，对事而非对人等等。

[size=100%]DevOps 概念最初是由 Flick 在2009年的 Velocity 2009 上名为「10 deploys per day : Dev&Ops cooperation at Flickr」演讲中提出的。从时间上来说，比 SRE 晚了6年（这个数字其实是有疑问的，2003年只是 Ben 的 Production team 创立的时间，至于 SRE 这个职位是什么时候出现的，大叔也还没找到）

[size=100%]那它们之间到底有没有点区别？

[size=100%]就大叔目前的水平，也回答不好，这里试着回答，也只是权当为自己解惑。

[size=100%]DevOps 和 SRE 一个比较明显的区别就是，在于 E 这个字母上，即 SRE 要求成员有很强的编码能力，更偏向于一个开者的角色。就像 Google SRE 官网上写道的一样：

[size=100%]Like traditional operations groups, we keep important, revenue-critical systems up and running despite hurricanes, bandwidth outages, and configuration errors. Unlike traditional operations groups, we view software as the primary tool through which our systems are managed, maintained, and minded

[size=100%]还有一点，SRE 更注重提高系统的可靠性和可用性，更强调主动出击。

[size=100%]另一点，DevOps 一般多指一个工作方式或者流程，DevOps 的定义中就包括 Dev 和 Ops 互相协作，识别并规避风险；而 SRE 有时多指一个具体的职位，也就是个人。

[size=100%]具体到 Google 这本书的例子，我们可以理解为 DevOps 更抽象，SRE 更具体，比如 SRE 定义了 Error Budget，PRR（Production Readiness Review），Postmortem，ICS（Incident Command System）等具体化方法和工具。

[size=100%]如果你觉得这个回答不够满意，或者有问题，欢迎留言或者私信，谢谢。

[size=100%]最后总结一下，按照本书的观点， SRE 是 DevOps 模型在 Google 的一个具体实践，带有自己独特的扩展；DevOps 是 SRE 核心理念的普适版，可以用于更大范围的组织结构之内。

[size=100%]那我们公司也能采用 SRE 机制么 ？

[size=100%]说了半天 SRE 这么好那么好，Google 的这一套我们能拿来直接用么？

[size=100%]大叔觉得，SRE 虽然比较新，但是核心内容很多公司都是具备的，在满足下面两个条件的前提下，还是不难的：

  
• [size=100%]有人
  
    
• [size=100%]有钱
  
  

[size=100%]有人不是人多，是要人厉害。前面我们已经看到了，SRE 对人的要求还是比较高的，既要通才，还要专才；既要熟悉本职工作，还要对其他非主要职责的模块比较熟悉；装的了系统，调得了网络；写得了 Python，改得了 Golang ... ... 这是对人才方面的要求，这是最基本的。

[size=100%]其次有钱。雇得起人才，还得培养得起人，消耗得起成本。

[size=100%]人才培养很重要，雇佣一帮自学成才的大牛不现实，招聘有潜力的人，通过组织环境和大牛培养起来才是最靠谱的途径，这也需要成本。最后，SRE 成员的工作时间可能会只有50%来用于实际产品开发，势必会影响开发进度，这也是可以用成本来衡量的。

[size=100%]至于其余其他因素，比如组织架构、工作习惯或者企业文化什么的则并不是什么阻碍，当然前提是需要先解决前面两个问题。

[size=100%]“

[size=100%]福利来了

[size=100%]前面我们一直在说这本名为《Site Reliability Engineering: How Google Runs Production Systems》的书，这本简直可以称得上是国内 SRE 理念的启蒙书。就是中文版稍微有点贵。

[size=100%]不过前几天，Google 在他们的网站上放上了这本书，供人们免费阅读。如果你英语好，或者不想买中文版，可以看看 Google 为 SRE 专门设立的网站 sre/ ，这里有这本书的电子版（在线），点击 阅读原文也可以查看在线电子版。

[size=100%]那我们就来看看这本书，全书共分5部分。

[size=100%]第一部分主要介绍了 SRE 的解决之道以及 Google 生产环境和背景。

[size=100%]第二部分是原则篇，主要介绍了一些体制和机制方面的原则，比如监控、自动化和发布等。尤其是发布，是关系到系统稳定性的最关键因素，我们可以想想自己的系统有多少是和上线新功能或者升级相关的吧。

[size=100%]第三部分是实践篇，理论结合实践，在科研上还是工程上，都是不二法宝，缺一不可，没有理论的实践，只能算是无用功，只能不停地重复劳动，不能升华和传播，不能普及世人；而没有实践的支撑，理论也不过是空想，于现实没有任何促进作用。这部分介绍了 Google 的 On-Call 制度、事故报告和总结等实践性强、比较容易借鉴的经验，相信很多部分都可以为我们效仿和定制。

[size=100%]第四部分是管理篇，这部分跳出个人的单独工作细节，介绍了如何在组织内部和其他团队、部门的协作。好方法、好实践不被组织级别重视，都属于暴殄天物，浪费。