Google SRE:起源

Benjamin Sloss Treynor

Googlegoogle总裁。他的一个主要工作就是确保的网站永不掉线

• sre:站点可靠性工程师(Google负责7*24小时运维的VP命名)
  

      1.SRE是工程师:使用计算机和软件工程手段设计和研发大型、分布式计算机软件系统;

      2.SRE关注:焦点是可靠性,包括架构设计、运维流程优化足够可靠

     3.sre主要工作:运维分布式集群系统上的具体业务服务(Service)

• SRE是一种职业:专注于整个软件系统的生命周期管理
  

Google SRE:基本概念

站点可靠性工程(SRE)和系统管理员(sysadmin)的区别

1.运维对象不同:分布式集群管理系统VS小型机、X86管理系统

2.存在时间不同于 Google,前十年VS近十年于中国15年之后VS15年之前

1.技能要求不同:计算机科学+软件工程V计算机科学

2.关注焦点不同:产品可靠性VS只负责将现成的软件组件部署到生产系统

3.成员来源不同:研发工程师VS从第三方工具厂商或系统集成商招聘

GoogleSRE实践总结

• 传统运维模式（Dev/Ops分离的团队模式）冲突的焦点
  

• 直接成本相对清晰；
  

• 间接成本差异较大（背景、技术能力、工具习惯、工作目标）；
  

• 初步演变为目标与方向上的分歧以及内部沟通严重问题，上升到部门之间的信任与尊重
  

传统运维模式（Dev/Ops分离的团队模式）冲突的焦点

1、直接成本相对清晰；

2、间接成本差异较大（背景、技术能力、工具习惯、工作目标）；

初步演变为目标与方向上的分歧以及内部沟通严重问题，上升到部门之间的信任与尊重；

传统运维模式（Dev/Ops分离的团队模式）冲突的焦点

1、传统研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更的发布速度上。

2、开发团队宣称不再进行大规模的程序更新，改为功能开关调整、增量更新和补丁化（大变更→小变更），为了绕开运维团队设立的各种流程，从而更快地上线新功能。

●Google的解决之道:sre

• SRE团队的组成:1)50%60%软件工程师)其他具备85%99%软件技能,且具备一定
  

       程度其他技能(UNX和网络)的工程师。

• SRE模型的优势:1)运维人数相对少
  

                               2)开发团队和运维团队的冲突焦点消除;

                               3)SRE团队和研发团队之间的成员可以自由流动。

• SRE模型的问题:就是如何招聘合适的SRE,一直存在。
  

●SRE方法论由来

• SRE背景:
  

1.SRE共有1000人+,分为多个SRE团队,每个团队有自己的工作流程、优先级定义以及日常工作规范;

2.SRE团队的工作职责:可用性改进、延迟优化、性能产品研发试优化、效率优化、变更管理、监控、紧急事务处理以及容量规划与管理。

• SRE方法论是什么:所有SRE团队共同的一套完整的沟通准则和行事规范。
  

• SRE方法论的作用
  

      1.规定了SRE是如何 google操作生产环境的;RE部门

      2.规定了SRE如何和产品研发部门、测试部门、最终用户进行有效沟通;

      3.帮助每个SRE团队保持良好的研发和运维工作平衡。

●SRE方法论内容:

1.确保长期关注研发工作

2.在保障SLO的前提下最大化选代速度

3.监控系统

4.应急事件处理

5.变更管理

6.需求预测和容量规划

7.资源部

8.效率与性能

GoogleSRE的企业价值

GoogleSRE代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破

SRE模型包含：

一套指导思想

一套方法论

一套激励方法

一个拥有广阔空间的独立职业

适用性：由于Google的独特地位，SRE模式不宜照搬，但可以深度模仿或借鉴，所以需要咨询。

GoogleSRE：知识体系：

Google SRE:起源

Benjamin Sloss Treynor

Googlegoogle总裁。他的一个主要工作就是确保的网站永不掉线

• sre:站点可靠性工程师(Google负责7*24小时运维的VP命名)
  

      1.SRE是工程师:使用计算机和软件工程手段设计和研发大型、分布式计算机软件系统;

      2.SRE关注:焦点是可靠性,包括架构设计、运维流程优化足够可靠

     3.sre主要工作:运维分布式集群系统上的具体业务服务(Service)

• SRE是一种职业:专注于整个软件系统的生命周期管理
  

Google SRE:基本概念

站点可靠性工程(SRE)和系统管理员(sysadmin)的区别

1.运维对象不同:分布式集群管理系统VS小型机、X86管理系统

2.存在时间不同于 Google,前十年VS近十年于中国15年之后VS15年之前

1.技能要求不同:计算机科学+软件工程V计算机科学

2.关注焦点不同:产品可靠性VS只负责将现成的软件组件部署到生产系统

3.成员来源不同:研发工程师VS从第三方工具厂商或系统集成商招聘

GoogleSRE实践总结

• 传统运维模式（Dev/Ops分离的团队模式）冲突的焦点
  

• 直接成本相对清晰；
  

• 间接成本差异较大（背景、技术能力、工具习惯、工作目标）；
  

• 初步演变为目标与方向上的分歧以及内部沟通严重问题，上升到部门之间的信任与尊重
  

传统运维模式（Dev/Ops分离的团队模式）冲突的焦点

1、直接成本相对清晰；

2、间接成本差异较大（背景、技术能力、工具习惯、工作目标）；

初步演变为目标与方向上的分歧以及内部沟通严重问题，上升到部门之间的信任与尊重；

传统运维模式（Dev/Ops分离的团队模式）冲突的焦点

1、传统研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更的发布速度上。

2、开发团队宣称不再进行大规模的程序更新，改为功能开关调整、增量更新和补丁化（大变更→小变更），为了绕开运维团队设立的各种流程，从而更快地上线新功能。

●Google的解决之道:sre

• SRE团队的组成:1)50%60%软件工程师)其他具备85%99%软件技能,且具备一定
  

       程度其他技能(UNX和网络)的工程师。

• SRE模型的优势:1)运维人数相对少
  

                               2)开发团队和运维团队的冲突焦点消除;

                               3)SRE团队和研发团队之间的成员可以自由流动。

• SRE模型的问题:就是如何招聘合适的SRE,一直存在。
  

●SRE方法论由来

• SRE背景:
  

1.SRE共有1000人+,分为多个SRE团队,每个团队有自己的工作流程、优先级定义以及日常工作规范;

2.SRE团队的工作职责:可用性改进、延迟优化、性能产品研发试优化、效率优化、变更管理、监控、紧急事务处理以及容量规划与管理。

• SRE方法论是什么:所有SRE团队共同的一套完整的沟通准则和行事规范。
  

• SRE方法论的作用
  

      1.规定了SRE是如何 google操作生产环境的;RE部门

      2.规定了SRE如何和产品研发部门、测试部门、最终用户进行有效沟通;

      3.帮助每个SRE团队保持良好的研发和运维工作平衡。

●SRE方法论内容:

1.确保长期关注研发工作

2.在保障SLO的前提下最大化选代速度

3.监控系统

4.应急事件处理

5.变更管理

6.需求预测和容量规划

7.资源部

8.效率与性能

GoogleSRE的企业价值

GoogleSRE代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破

SRE模型包含：

一套指导思想

一套方法论

一套激励方法

一个拥有广阔空间的独立职业

适用性：由于Google的独特地位，SRE模式不宜照搬，但可以深度模仿或借鉴，所以需要咨询。

GoogleSRE：知识体系：