贝特西·拜尔等
SRE就是运行和管理这百万台服务器和众多分布式系统的关键。
SRE部门在Google真正落实了DevOps。SRE工程师在Google不只是维护各种线上服务的稳定性，还要负责保证各项服务的性能，同时负责管理维护数据中心。
对应用程序的设计实现方式、依赖库、运行时的资源消耗都有严格的规约；其次，SRE工程师本身也要做不少编程工作，来实现各种工具用以自动解决问题和故障，换句话说，SRE强调的是对问题和故障的自动处理，而非人工干预；再者，按照SRE的约定，开发人员自行负责程序上线部署更新，毕竟开发人员对自己开发的程序更熟悉，易于处理程序上线过程中遇到的问题。总之，作为Google的DevOps实践，SRE非常注重开发和运维职能的结合，极大地加快了业务应用迭代周期，提升了IT对业务的支撑能力。
Google建立了独树一帜的运维体系并称之为SRE（Site ReliabilityEngineering）。绝大部分传统IT公司会雇佣系统管理员（sysadmin）来运维复杂的计算机系统，但由于大部分工作依靠手工操作，所以随着用户增长，Sysadmin的团队也必须相应地增长。Google SRE团队的精华在于研发软件系统，将运维自动化以替代传统模型中的人工操作。
书中提及许多实用的道理，比如，100%!的(MISSING)可用性是不现实的，需要达到这个目标的成本通常远超于所能获得的价值，所以Google会针对每种产品设定一个错误预算（容错率），既能保证用户体验又不影响创新和部署的速度。
Google 是SRE理念的发明者。本书不光介绍了这个职位的技术细节，还包括了其中的思考过程、团队目标、设计理念以及学到的宝贵课程。如果你想从起源上了解SRE一词的意义，应该从本书开始。
SRE是一群天生的怀疑论者，我们怀疑一切宣传起来“高大上”的技术，以及任何“神奇”的产品——我们只想看具体的设计架构、实现细节，以及真实的监控图表。
SRE，站点可靠性工程师。
Google 将这个职位称为站点可靠性工程师（SRE,Site Reliability Engineering）。
SRE并不是无止境地追求完美：当一个系统已经 “足够可靠”的时候，SRE 通常将精力转而投入到研发新的功能和创造新的产品中。[3]
SRE 的主要工作是运维在分布式集群管理系统上运行的具体业务服务（service）
SRE 中的“S”最开始指代的就是google.com的运维服务，因为SRE的第一个工作就是维持网站的正常运转。随着时间的推移，SRE 逐渐接管了 Google 内部绝大部分产品系统，包括 Google Cloud Platform 这类开发者平台，也包括内部的一些非网站类的基础设施系统，例如 Bigtable。
系统管理员的日常工作与研发工程师相差甚远，通常分属两个不同的部门：开发部（Dev）和运维部（Ops）。
由于研发团队和运维团队背景各异，技术能力与工具使用习惯上差距巨大，工作目标也截然不同。两个团队对产品的可靠程度要求理解不同，具体执行中对某项操作的危险程度评估与可能的技术防范措施也有截然不同的理解。这
传统的研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更的发布速度上。研发部门最关注的是如何能够更快速地构建和发布新功能。运维部门更关注的是如何能在他们值班期间避免发生故障。由于绝大部分生产故障都是由于部署某项变更导致的—不管是部署新版本，还是修改配置，甚至有时只是因为改变了用户的某些行为造成了负载流量的配比变化而导致故障。这两个部门的目标从本质上来说是互相矛盾的。
SRE团队通过雇佣软件工程师，创造软件系统来维护系统运行以替代传统模型中的人工操作。
每个SRE团队里基本上有两类工程师。 第一类，团队中 50%!～(MISSING)60%!是(MISSING)标准的软件工程师，具体来讲，就是那些能够正常通过Google软件工程师招聘流程的人。第二类，其他40%!～(MISSING)50%!则(MISSING)是一些基本满足Google软件工程师标准（具备85%!～(MISSING)99%!所(MISSING)要求的技能），但是同时具有一定程度的其他技术能力的工程师。目前来看，UNIX 系统内部细节和1～3层网络知识是Google最看重的两类额外的技术能力。
SRE团队成员都必须非常愿意、也非常相信用软件工程方法可以解决复杂的运维问题。
（a）对重复性、手工性的操作有天然的排斥感。 （b）有足够的技术能力快速开发出软件系统以替代手工操作。
从本质上来说，SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。这些SRE倾向于通过设计、构建自动化工具来取代人工操作。
SRE模型成功的关键在于对工程的关注。如果没有持续的、工程化的解决方案，运维的压力就会不断增加，团队也就需要更多的人来完成工作。传统的Ops团队的大小基本与所服务的产品负载呈线性同步增长。如果一个产品非常成功，用户流量越来越大，就需要更多的团队成员来重复进行同样的事情。
Google为整个SRE团队所做的所有传统运维工作设立了一个50%!的(MISSING)上限值。传统运维工作包括：工单处理、手工操作等。设立这样一个上限值确保了SRE团队有足够的时间改进所维护的服务，将其变得更稳定和更易于维护。这个上限值并不是目标值。随着时间推移，SRE团队应该倾向于将基本的运维工作全部消除，全力投入在研发任务上。因为整个系统应该可以自主运行，可以自动修复问题。我们的终极目标是推动整个系统趋向于无人化运行，而不仅仅是自动化某些人工流程。当然，在实际运行中，服务规模的不断扩张和新功能的上线已经让SRE够忙了！
Google的经验法则是，SRE团队必须将50%!的(MISSING)精力花在真实的开发工作上
我们可以认为DevOps是SRE核心理念的普适版，可以用于更广范围内的组织结构、管理结构和人员安排。同时，SRE是DevOps模型在Google的具体实践，带有一些特别的扩展。
SRE团队要承担以下几类职责：可用性改进，延迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划与管理。S
SRE 处理运维工作的一项准则是：在每8～12小时的on-call 轮值期间最多只处理两个紧急事件。这个准则保证了on-call工程师有足够的时间跟进紧急事件，这样SRE可以正确地处理故障、恢复服务，并且要撰写一份事后报告。如果一次轮值过程中处理的问题过多，那么每个问题就不可能被详细调查清楚，运维工程师甚至没有时间从中学习。
所有的产品事故都应该有对应的事后总结，无论有没有触发警报。这里要注意的是，如果一个产品事故没有触发警报，那么事后总结的意义可能更大：因为它将揭示监控系统中的漏洞。事后总结应该包括以下内容：事故发生、发现、解决的全过程，事故的根本原因，预防或者优化的解决方案。
“错误预算”起源于这样一个理念：任何产品都不是，也不应该做到100%!可(MISSING)靠（显然这并不适用于心脏起搏器和防抱死刹车系统等）。
紧急警报（alert） 意味着收到警报的用户需要立即执行某种操作，目标是解决某种已经发生的问题，或者是避免即将发生的问题。
平时没有人需要关注日志信息，但是日志信息依然被收集起来以备调试和事后分析时使用。正确的做法是平时没人会去主动阅读日志，除非有特殊需要。
但是在巨大的时间压力和产品压力下，运维手册中记录的清晰调试步骤和分析方法对处理问题的人是不可或缺的
SRE的经验告诉我们，大概 70%!的(MISSING)生产事故由某种部署的变更而触发。变更管理的最佳实践是使用自动化来完成以下几个项目：
● 采用渐进式发布机制。 ● 迅速而准确地检测到问题的发生。 ● 当出现问题时，安全迅速地回退改动。
需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。
资源的部署（provisinging）是变更管理与容量规划的结合物。在我们的经验里，资源的部署和配置必须能够非常迅速地完成，而且仅仅是在必要的时候才执行，因为资源通常是非常昂贵的。
一个业务总体资源的使用情况是由以下几个因素驱动的：用户需求（流量）、可用容量和软件的资源使用效率。
软件系统一般来说在负载上升的时候，会导致延迟升高。延迟升高其实和容量损失是一样的。当负载到达临界线的时候，一个逐渐变慢的系统最终会停止一切服务。换句话说，系统此时的延迟已经是无穷大了。SRE的目标是根据一个预设的延迟目标部署和维护足够的容量。SRE和产品研发团队应该共同监控和优化整个系统的性能，这就相当于给服务增加容量和提升效率了。[3]
Google SRE代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破。由一个简单的想法“我是一名软件工程师，这是我如何来应付重复劳动的办法”而生，SRE模型已经发展成一套指导思想、一套方法论、一套激励方法和一个拥有广阔空间的独立职业。想要了解更多关于SRE相关的信息，请阅读本书的其余部分。
对Google来说，并不存在一个具体的物理服务器运行我们的邮件系统，而是采用一套集群管理系统进行资源分配，它的名称为Borg。
通常对一个软件业务来说，软件服务器和物理服务器是紧密相连，密不可分的。但是对Google来说，并不是这样。具体区分的原因和细节相信读者读过下面的章节之后就会有所了解。
Google的数据中心是由一套全球覆盖的骨干网B4（参见文献[Jai13]）连接起来的。B4 是基于SDN网络技术（使用OpenFlow标准协议）构建的，可以给中型规模的骨干网络提供海量带宽，同时可以利用动态带宽管理优化网络连接，最大化平均带宽（参见文献[Kum15]）。
我们使用一个基于OpenFlow协议的软件定义网络（SDN）
这些集群通常是遍布全球的。为了降低分布式集群的服务延迟，我们希望能够将用户指派给距离最近的、有空余容量的数据中心处理。我们的全球负载均衡系统（GSLB）在三个层面上负责负载均衡工作： ● 利用地理位置信息进行负载均衡DNS请求（例如www.google.com的解析，具体描述参见第19章）。 ● 在用户服务层面进行负载均衡，例如YouTube 和 Google Maps。 ● 在远程调用（RPC）层面进行负载均衡（具体描述参见第20章）。
从监控对象抓取监控指标（Metric）。这些监控指标可以被用来触发警报，也可以存储起来供以后观
● 对真实问题进行报警。 ● 对比服务更新前后的状态变化：新的版本是否让软件服务器运行得更快了？ ● 检查资源使用量随时间的变化情况，这个信息对合理制定资源计划很有用。
通常来说，一个软件服务器从该服务的前端（frontend）接收RPC请求，同时将另外一些RPC发往该服务器的后端（backend）。一般来说，前端被称为客户端（client），后端被称为服务端（server）。 Protocol Buffer[7]是Google RPC的传输格式，通常简写为Protobuf，与Apache Thrift类似。Protobuf 相比XML有很多优势，更为简单易用，数据大小比XML格式要小3～10倍，序列化和反序列化速度快100倍，并且协议更加明确。
● 任何对自己项目代码的改动也需要代码评审。
有些项目组甚至在实践自动部署机制：提交一个新版本，测试通过后，将直接部署于生产环境。
极端的可靠性会带来成本的大幅提升：过分追求稳定性限制了新功能的开发速度和将产品交付给用户的速度，并且很大程度地增加了成本，这反过来又减少了一个团队可以提供的新功能的数量。
用户通常不会注意到一项服务在高可靠性和极端可靠性之间的差异，因为用户体验主要是受较不可靠的组件主导，例如手机移动网络或者他们正在使用的设备。简单地说，用户在一个有着99%!可(MISSING)靠性的智能手机上是不能分辨出99.99%!和(MISSING)99.999%!的(MISSING)服务可靠性的区别的！
SRE旨在寻求快速创新和高效的服务运营业务之间的风险的平衡，而不是简单地将服务在线时间最大化。这样一来，我们可以优化用户的整体幸福感，平衡系统的功能、服务和性能。
不可靠的系统会很快侵蚀用户的信心，所以我们想要减少系统出故障的几率。
协议 最后，SLA是服务质量协议（Agreement）：指服务与用户之间的一个明确的，或者不明确的协议，描述了在达到或者没有达到SLO之后的后果。这些后果可以是财务方面的—退款或者罚款—也可能是其他类型的。
● 99%!（(MISSING)在1分钟的时间范围内汇总）的Get RPC调用会在小于100ms的时间内完成（包括全部后端服务器）。
如果系统正常运转中需要人工干预，应该将此视为一种Bug。
SRE要把更多的时间花费在长期项目研发上而非日常运维中。因为术语日常运维可能会被误解，我们在这里使用一个专门的词语——琐事（toil）。
到底什么是琐事？琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。
从SRE的视角中可以更清晰地描述这种情况的消极方面：添加到项目中的每行代码都可能引入新的缺陷和错误。较小的项目容易理解，也更容易测试，而且通常缺陷也少。从这一观点出发，当我们感觉到增加新功能需求时，应该保持保守的态度。我曾经做过的一些最令人满意的编码工作就是删除了数千行已经没用的代码。
SRE的职责是运维一个服务。该服务由一些相关的系统组件组成，为最终用户提供服务（可以是内部用户或外部用户）。SRE 的终极责任是确保该服务可以正常运转。为达成这个目标，SRE需要完成以下一系列工作：开发监控系统，规划容量，处理紧急事件，确保事故根源被跟踪修复等。这一部分将主要讨论SRE维护大型分布式计算系统的指导理念和最佳实践。
离开了监控系统，我们就没有能力辨别一个服务是不是在正常提供服务。没有一套设计周全的监控体系就如同蒙着眼睛狂奔。作为一个合格的系统运维人员，我们需要在用户之前发现系统中存在的问题。
事后总结和问题根源分析 我们的目标是接收警报，然后人工解决新的、有挑战性的服务问题。反复不断地修复同样的问题简直太无聊了。事实上，这个理念是SRE和传统运维团队理念中最大的不同点。下面两章详细描述了这个主题。
如果一个面向最终用户的业务系统在每个季度想要达到99.99%!的(MISSING)可用度，那么每个季度共有13分钟的不可用时间（参见附录A）。这个要求说明了on-call工程师必须在分钟级别上响应生产事故（更确切地说，13分钟内）。如果一个系统的SLO更为宽松，那么响应时间可以在几十分钟内。
一旦接收到报警信息，工程师必须确认（ack）,on-call工程师必须能够及时定位问题，并且尝试解决问题。必要的话，on-call工程师可以联系其他团队，或者升级（escalate）请求支援。
先宣布事故发生，随后找到一个简单解决方案，然后宣布事故结束，要比在问题已经持续几个小时之后才想起流程管理更好。应当针对事故设立一个明确的宣布条件。Google团队依靠下面几个宽松的标准——如果下面任何一条满足条件，这次事故应该被及时宣布。 ● 是否需要引入第二个团队来帮助处理问题？ ● 这次事故是否正在影响最终用户？ ● 在集中分析一小时后，这个问题是否依然没有得到解决？
大多数云计算应用都是优化以下5项的某种组合：在线时间、延迟、规模、创新速度和隐私。
John入职的第一天，所有新的工单就全部指派给了他。同时，主管告诉John可以寻求任何一个有经验的SRE成员的帮助来了解每个工单的背景知识，以便处理。“当然了，你会有很多东西要学习，这个只能靠你自己了”，主管说道，“最后你一定会学会快速处理这些工单的。某一天你就会突然开窍，发现你已经掌握了我们全部的工具，全部的流程，以及全部的系统知识。”这时候一个老成员补充了一句，“我们这里都是摸着石头过河的。”
● 在服务技术栈中增加一个小的，但是用户可见的功能修改，接下来跟随这个修改一直到发布到生产环境中。了解开发环境的配置和二进制文件的发布流程可以确保他们和开发团队联系密切。 ● 针对现有的服务监控盲点增加新的监控。新手需要了解监控逻辑，同时将这些异常情况与系统知识相结合。
对事故的渴望：事后总结的阅读和书写
“忘记过去的人必然会犯重复的错误。” ——George Santayana，哲学家和散文家 事后总结（参见第15章）是持续改进的一个重要部分。这是找出某次大型事故的根本原因的一种手段，对事不对人。当书写事后总结时，一定要记住这个文档的最佳受众可能是一个还没有入职的工程师。不需要多么特别的编辑过程，Google某些最好的事后总结只需要小小的改动就可以变成学习材料。
多SRE团队要维护一个“on-call学习检查列表”。该列表中包含一系列阅读材料，以及关于系统的各种技术和知识的完整列表，学员必须充分掌握该列表才能进行见习oncall
让有经验的on-call成员“反向见习”学员。学员会成为主on-call，负责处理所有相关的问题，但是资深的on-call成员会在一旁观察，让其独立地检查问题，而不会做任何修改操作。资深SRE同时可以提供积极的帮助，帮忙确认要执行的动作，以及提供必要的提示。
● 灾难预案与演习● 书写事后总结的文化● 自动化与降低日常运维负载● 结构化的、理智的决策
Google SRE本质上还是软件工程师，他们对重复性的、被动性的工作十分反感。在我们的文化中强调避免反复执行一项重复性的工作。如果一项工作可以自动进行，为什么还需要我们来重复执行呢？ 自动化可以降低运维负载，同时节省工程师的时间。他们可用这些时间去主动改进服务的其他方面。
自动化可以以更高的效率、更低的成本来完成这些工作。而且，自动化通常比人工完成工作的重复性更强、更可靠，这意味着自动化可以产出更多高标准的产品。
自动化在这个环节中减少了这种错误带来影响的可能性。一
每次on-call轮值应该处理不超过两起事故（平均每12小时1个）：应对和修复事故都需要时间，书写事后总结以及处理Bug也需要时间。事故频繁会造成响应质量的下降，同时也意味着系统设计中存在一个或多个设计缺陷，监控系统过于敏感，之前书写在事后总结中的问题没有及时修复等。
SRE团队最终可能会由于系统事故出现的越来越少而失去熟练性，这可能会造成原本很小的事故需要花很长的时间来解决。通过进行周期性的假想灾难演习可熟悉应对紧急事故的文档与流程。