下载掌阅APP，畅读海量书库
立即打开
DevOps文化在全球持续推广和得到认可的同时，也有一些开发运维相关的知名管理框架和最佳实践在世界范围得到推广，比较突出的是谷歌公司的站点可靠性工程（Site Reliability Engineering，SRE）。
SRE是一种结合软件工程各方面并将其应用于基础架构和运维问题的技术，于2003年左右由谷歌公司创建，并通过SRE books进行宣传。SRE的主要目标是创建超大规模和高度可靠的分布式软件系统，因为在很多方面均给出了有效的实践创新，所以成为运维研发领域被广泛认同的IT管理框架。SRE被称为运维领域的DevOps最佳实践框架。
①SRE将50％的时间花在Ops（运维）相关工作上，如问题解决、电话值班和手工干预。
②SRE将50％的时间花在Dev（开发）任务上，如新功能、扩展或自动化。
③监控、警报和自动化是SRE的主要部分。
SRE与DevOps的关系如图2-2所示。
图2-2 SRE与DevOps的关系
谷歌公司定义了DevOps成功的5个关键支柱：减少组织的竖井，接受失败即常态，实现渐进的变更，利用工具和自动化，测量一切。
从上述支柱来看，SRE与DevOps的核心理念是完全契合的。谷歌公司认为，SRE是“带有一些扩展的DevOps的特定实现”，如图2-3所示。
图2-3 SRE对DevOps的拓展
SRE是谷歌公司在开发运维的落地过程实现的优化和拓展，包含如下。
1.运维侧的拓展
SRE在DevOps（开发、测试、运维）的基础上将整个流程进行了拓展：创建生产环境（原有）→生产部署（原有）→运行环境测试（新增）→运行环境非功能性测试（新增）→检查监控（新增）→错误测试（混沌工程，新增）。
2.安全生产
在上线前，SRE增加了“安灯绳”（Andon，起源于日本丰田汽车公司，用来实现“立即暂停制度”，即时解决质量问题，达到持续高品质地生产）环节，也就是说，SRE可以针对任何影响安全生产的流水线直接喊停（Say No），可以避免高度自动化条件下的研发错误、无序发布、生产。
总体来说，SRE更关注生产环境（PROD）——使DevOps获得了“运维的智慧”，SRE可以说“不”。
第一条：运维是软件问题
SRE的基本原则是，做好运维最重要的是软件问题，应该使用软件工程方法来解决运维问题。SRE是将运维从传统的操作和维护转成关注，使用软件工程对整个运维流程进行设计和构建的技术。
据估计，软件总成本40％～90％是在产品发布后产生的，因此必须从源头做好软件。
第二条：一切围绕服务水平
服务水平目标（Service Level Objective，SLO）即产品或服务的可用性目标（不必是100％）。SRE强调使用SLO来管理SRE服务，一切围绕SLO。
第三条：减少琐事（Toil）
谷歌公司认为，任何琐事（手动的、强制的运维任务）都是很糟糕的（长期执行成本、增加人为错误），如果一个任务可以自动化，它就应该自动化，以持续减少琐事。
第四条：自动化
SRE强调，将当前手工完成的工作都实现自动化，并建议采用一种基于工程的方法来解决问题，而不是一遍一遍地苦干。
自动化是SRE的主要工作。
第五条：减少失败的成本
后期问题（缺陷）的发现是昂贵的，所以SRE寻找方法来避免，通过提升软件系统健壮性来改善平均修复时间（Mean Time To Recovery，MTTR）。
第六条：共享所有权
SRE与产品开发团队共享技能集，以避免竖井。“应用程序开发”与“生产”（开发和运维）之间的界限应该被消除。SRE的“左移”为开发团队提供“生产智慧”。