Google

Google

讲师介绍：刘峰

互联网IT管理领域资深实战专家，具备超过15年IT服务管理以及开发运维一体化咨询领域工作和讲师经历。作为国内SRE第一批实践者，具备甲方乙方、外企国企的咨询经验。

为招商银行、平安银行、华夏银行、国家开发银行、上海银行、郑州银行、IBM、中国惠普、埃森哲、中国移动、中国电信等提供过专业服务。

Google SRE 起源：

SRE最早的起源是Apollo 7 飞船研发的事故，一场的软件执行失败案例。一位小朋友在参观过程中，意外触发，导致整个模拟过程失败，基于SRE的直觉，Margaret教授提交软件了改进建议，不过当时所有人，包括NASA管理层、工程师团队，都认为这是一个低级错误，不值得修改，从而否决了建议。几天后，飞船运行操作失误，导致故障真的出发了，航天员参考了Margaret之前更新的手册，在有限的时间内解决了问题，才得以避免灾难的发生。世界上第一个SRE诞生了。

真正现代SRE的起源来自Google。Google的一位副总裁，叫Benjamin Sloss Treynor，他的主要工作是确保Google网站不掉线。但是他发现面向全球的互联网高并发量的系统很难运维，很难达到永不掉线。因此，通过他的不断观察和探索，坚持创新，Benjamin Sloss Treynor提出了SRE，Site Reliability Engineer，翻译成中文是站点可靠性工程师。他是一名工程师，可以使用计算机和软件工程手段设计和研发大型、分布式计算机软件系统。也就是说，他具有一定的软件开发能力，又有很强的运维实践经验。

SRE关注的焦点是可靠性，包括架构设计，包括运维流程优化，做到足够可靠。

SRE主要工作是运维分布式集群系统上的具体业务服务，SRE是一种职业，专注于整个软件系统的生命周期管理。

从最初的规划、设计、研发、上线、运维、优化、架构等的维护都在SRE，跟DevOps的理念非常接近。

Google SRE中的S（Service）是指Google搜索引擎服务。Google软件系统的40%-90%的花销是在开发建设完成后的不断维护过程中。在研发阶段用的时间和费用都是相对来说比较少，一旦上线之后，面对互联网海量用户，压力就很大，很难运营和维护。

站点可靠性工程（SRE）和系统管理员（sysadmin）的区别：

* 运维对象不同：分布式集群管理系统VS小型机、X86管理系统。

* 存在时间不同：于Google，前十年 VS 近十年于中国，15年之后 VS 15年之前。

* 圆技能要求不同：计算机科学+软件工程 VS 计算机科学。

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

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

Google SRE的实践总结：

一、传统运维模式的冲突焦点：

传统运维模式，也就是Dev/Ops分离的团队模式，他们的冲突焦点，主要有四个方面。

第一，直接成本相对清晰，研发的费用和运维的费用是分开的；

第二，间接成本差异较大，研发和运维两个团队在背景、技术能力、工具习惯、工作目标都是不太一样的；随着业务和技术的发展，使得两个团队在目标与方向上的分歧以及内部沟通方面产生比较严重的问题，有些甚至上升到部门之间的信任与尊重；

第三，传统研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更的发布速度上；第四， 开发团队宣称不再进行大规模的程序更新，改为功能开关调整、增量更新和补丁化（大变更变成小变更），为了绕开运维团队设立的各种流程，从而更快地上线新功能。不过这种绕过流程的方式，虽然带来了高效率，但这种做法是不正确的。

很多公司也都面临这样的矛盾，究竟是更敏捷，更快响应业务的变化，还是保证业务稳定，更安全呢？

二、Google的解决之道：SRE

Google也面对同样的问题，因为规模庞大的服务器，以及Google的系统以及架构都是非常复杂，导致这个问题更加尖锐。这时，Benjamin Sloss Treynor，Google的这位副总裁，找到了解决方法，他组织了一个新的团队，也就是SRE团队。团队有50%~60%软件工程师，其他人具备85%~99%软件技能，且具备一定程度其他技能（UNIX和网络）的工程师。

这种模型有三种优势，第一，运维人数相对少；第二，开发团队和运维团队的冲突焦点消除，从两个团队变成一个团队，遇到问题，大家一起想办法解决；第三，SRE团队和研发团队之间的成员可以自由流动。

实践证明，这个模型很有效，不过 SRE模型的也面临一个一直存在的问题，那就是如何招聘合适的SRE。

SRE与DevOps的区别是，SRE是运维拥抱研发，DevOps是研发拥抱运维。

三、SRE方法论的由来

SRE共有1000人+，分为多个SRE团队，每个团队有自己的工作流程、优先级定义以及日常工作规范。SRE团队的工作职责包括可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理以及容量规划与管理。

SRE方法论是所有SRE团队共同的一套完整的沟通准则和行事规范。SRE的作用包括，1） 规定了SRE是如何操作Google生产环境的；2.）规定了SRE如何和产品研发部门、测试部门、最终用户进行有效沟通；3） 帮助每个SRE团队保持良好的研发和运维工作平衡。

四、SRE方法论的内容

* 确保长期关注研发工作。

* 在保障SLO（服务级别目标）的前提下最大化迭代速度。

* 做好监控系统，能够实时发现异常，判定如何快速处理。

* 做好应急事件处理。监控系统做的再好，一旦发现了应急事件，也要做好相应的处理。

* 做好变更管理。如果没有变更，就无法进行迭代，如果持续性迭代，就会有风险。

* 需求预测和容量规划。互联网下的需求是弹性的是可变的，不是非常平稳，要主动规划容量。

* 资源部署。

* 效率与性能。在确保高可用情况之下，保证效率与性能。

五、SRE原则

* 拥抱风险

* 简单化：系统架构、流程、作业标准等简单化

* 服务质量目标

* 自动化：Google不遗余力的推动自动化，降低出错率，提升效率

* 发布工程：做到持续集成持续发布，高效率的发布软件

* 消除琐事：提升琐事的效率，省出时间做更有价值的事

* 分布式系统监控：第一时间发现问题，快速解决问题

六、SRE和DevOps的关系

SRE的作者认为：DevOps是SRE核心理念的普适版，可以用于更广范围内的组织结构、管理结构和人员安排。

个人认为：SRE可以是运维向运维研发的拓展，这可以适用于国内广泛的运维部门转型，事实上DevOps或者说“开发运维一体化”在国内刚刚开始落地，很多组织上仅仅通过引入DevOps理念，仍然需要面对“生产环境天天出问题，就是不知道问题出在哪”。

SRE对企业和团队的价值

1、Google SRE 企业价值

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

SRE模型包含一套指导思想、一套方法论、一套激励方法、一个拥有广阔空间的独立职业。由于Google的独特地位，SRE模式不宜照搬，但可以深度模仿或借鉴。

2、Google SRE 团队价值

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

最后，我们讲一讲SRE带来的团队启迪和价值，我们坚信只要不断地解决根源问题，服务质量就一定会得到提升。高可用性背后是一系列的根源问题。在设计评审中，他们会推演各种灾难场景。在每周例会时，他们又会讨论如何消除和防范事故发生、优化各种警报策略以及增强自动化功能。在平时工作中，他们则会精心维护团队的各种文档和项目源代码，一点一点地提高服务质量。回头来看，SRE其实是一群崇尚工匠主义的人。

Google SRE专家讲师：