简单来说，SRE的职责是运维一个服务。该服务由一些相关的系统组件组成，为最终用户提供服务（可以是内部用户或外部用户）。SRE 的终极责任是确保该服务可以正常运转。为达成这个目标，SRE 需要完成以下一系列工作∶开发监控系统，规划容量，处理紧急事件，确保事故根源被跟踪修复等。这一部分将主要讨论SRE 维护大型分布式计算系统的指导理念和最佳实践。

AbrahamMaslow 曾经将人的生活需求分类论述（参见文献【Mas43】）。鉴于此，我们可以将一个服务的健康程度指标分为低级需求∶能够正常对外提供服务，和高级需求∶SRE 能够主动控制服务状态，而不是被动救火。这个理念从多年实践中积累得来，却一直没有被详细定义过。

2013 年年末至 2014年年初，Google SRE，Mikey Dickerson，准'临时被抽调加入一个由美国政府组建的小组，负责帮助解决 healthcare.gov线上遇到的问题。在尝试向来自其他背景的人解释 Google SRE 是如何看待服务可靠性问题时，这个理念才第一次被详细定义下来。

我们用图Ⅲ -1中的层级模型来详细论述一下服务可靠度指标的基本需求和高级需求。

监控

离开了监控系统，我们就没有能力辨别一个服务是不是在正常提供服务。没有一套设计周全的监控体系就如同蒙着眼睛狂奔。作为一个合格的系统运维人员，我们需要在用户之前发现系统中存在的问题。在第 10 章将讨论有关警报系统的设计哲学和工具。

应急事件处理

SRE并不是为了on-call值班而值班，on-call 值班只是我们实现服务目标的一种工具。经常参与轮值有助于每一个SRE了解和熟悉大型分布式计算系统的失败模式。如果我们可以找到一种方式使得值班不再必要，SRE肯定会第一时间采用。在第 11 章中，将详细解释我们是如何平衡 on-call 轮值与其他工作的。

一旦SRE 发现了系统中存在的问题，要如何解决呢?正确的解决方案不一定是当场把问题一次性修复好，而可以靠降低系统准确度、关闭一些不重要的功能，或者将用户流量导向其他没有问题的任务实例等手段暂时缓解问题。解决方案的细节肯定是和每个服务和团队相关的。但是如何有效地应对紧急问题的方法论是每个团队都适用的。

在第12章中，我们提供了一套结构化方案来解决问题的第一步∶找到问题所在。

在应急事件处理中，由于压力很大，很多情况下人们急于解决问题，会绕开必要的流程。

在第 13 章和第 14 章中，我们讨论了如何通过合理的流程有效地减小事故的影响范围，以缓解整个部门由生产事故带来的压力。

事后总结和问题根源分析

我们的目标是接收警报，然后人工解决新的、有挑战性的服务问题。反复不断地修复同样的问题简直太无聊了。事实上，这个理念是 SRE 和传统运维团队理念中最大的不同点。下面两章详细描述了这个主题。

第 15 章，描述了如何建立起"无指责"、"对事不对人"的团队文化，只有做到这一步，才能有效了解到在一次事故中哪些地方出现了问题（以及哪些地方做得非常好）。

第 16 章，在这个基础上，我们简要描述了一个内部工具，事故跟踪系统。SRE 团队使用该系统跟踪最近发生的生产事故、原因以及解决的具体过程。

测试

当我们发现经常出现问题的组件或者流程时，下一步就是如何避免它再次发生故障。通过增加测试，保证软件在发布到生产环境中时不会出现某些类型的问题。在第 17章中详细描述了相关的最佳实践。

容量规划

在第 18章中，我们给出了一个具体的工具开发实践案例。SRE 利用Google 内部工具Auxon，自动化进行服务容量规划。

容量规划后，我们还需要保证合理的负载均衡体制能够正确地使用这些服务容量。在第19 章中，我们讨论了用户请求是如何发送到数据中心的。在第 20章和第 21章中，我们详细描述了数据中心中的负载均衡体系是保障服务可靠度的关键。

最后，在第 22章中，我们讨论了如何从系统设计层面与战术层面应对"连锁故障"。

软件研发

GoogleSRE 模型的要点之一就是 SRE一半的精力都花在设计和开发大规模软件系统上。

在第 23 章中，我们解释了Google许多系统的核心组件——"分布式共识"系统（Paxos 的新说法），例如全球分布式定时任务系统。在第24章中，我们描述了SRE是如何设计和部署一个跨数据中心的定时任务系统的。

第25章描述了批量数据处理系统的几种形态∶从定时运行的 MapReduce程序，到实时数据处理系统。不同的系统架构可带来不同的新奇与反直觉的挑战。

在第 26 章中，我们详细描述了数据一致性的重要性，如何确保之前存储的数据可以被安全地读取回来。

产品设计

最后，在第 27章中，我们描述了处于整个可靠度金字塔模型顶端的产品设计理念。我们解释了Google是如何改进产品设计，以确保全球用户在产品上线第一天起就拥有最好的用户体验的。

扩展阅读

如前文所述，有效的测试（这里的测试同时指软件层面的测试，也指流程、组织上的灾难演习）是非常困难的。如果测试的方法不对，甚至会对整个服务的可靠性带来影响。在一篇 ACM 论文中（参见文献 【Kril2】），我们解释了Google是如何通过全公司的灾难演习来确保公司可以在大型灾难发生时正常工作的。

容量规划，有时候经常被说成是一种通过大量神奇的表格进行的黑魔法。但是通过文献【Hix15a】中的这篇文章，我们详细描述了正确地进行容量规划并不一定需要用水晶球预见未来的能力。

最终，文献 【War14】描述了Google的一种新的网络安全方法论。通过这项计划，我们正在逐步将有高权限的内网验证替换为使用用户设备和用户身份验证。当读者进行下一个网络设计的时候，可以试验一下这种方式。

简单来说，SRE的职责是运维一个服务。该服务由一些相关的系统组件组成，为最终用户提供服务（可以是内部用户或外部用户）。SRE 的终极责任是确保该服务可以正常运转。为达成这个目标，SRE 需要完成以下一系列工作∶开发监控系统，规划容量，处理紧急事件，确保事故根源被跟踪修复等。这一部分将主要讨论SRE 维护大型分布式计算系统的指导理念和最佳实践。

AbrahamMaslow 曾经将人的生活需求分类论述（参见文献【Mas43】）。鉴于此，我们可以将一个服务的健康程度指标分为低级需求∶能够正常对外提供服务，和高级需求∶SRE 能够主动控制服务状态，而不是被动救火。这个理念从多年实践中积累得来，却一直没有被详细定义过。

2013 年年末至 2014年年初，Google SRE，Mikey Dickerson，准'临时被抽调加入一个由美国政府组建的小组，负责帮助解决 healthcare.gov线上遇到的问题。在尝试向来自其他背景的人解释 Google SRE 是如何看待服务可靠性问题时，这个理念才第一次被详细定义下来。

我们用图Ⅲ -1中的层级模型来详细论述一下服务可靠度指标的基本需求和高级需求。

监控

离开了监控系统，我们就没有能力辨别一个服务是不是在正常提供服务。没有一套设计周全的监控体系就如同蒙着眼睛狂奔。作为一个合格的系统运维人员，我们需要在用户之前发现系统中存在的问题。在第 10 章将讨论有关警报系统的设计哲学和工具。

应急事件处理

SRE并不是为了on-call值班而值班，on-call 值班只是我们实现服务目标的一种工具。经常参与轮值有助于每一个SRE了解和熟悉大型分布式计算系统的失败模式。如果我们可以找到一种方式使得值班不再必要，SRE肯定会第一时间采用。在第 11 章中，将详细解释我们是如何平衡 on-call 轮值与其他工作的。

一旦SRE 发现了系统中存在的问题，要如何解决呢?正确的解决方案不一定是当场把问题一次性修复好，而可以靠降低系统准确度、关闭一些不重要的功能，或者将用户流量导向其他没有问题的任务实例等手段暂时缓解问题。解决方案的细节肯定是和每个服务和团队相关的。但是如何有效地应对紧急问题的方法论是每个团队都适用的。

在第12章中，我们提供了一套结构化方案来解决问题的第一步∶找到问题所在。

在应急事件处理中，由于压力很大，很多情况下人们急于解决问题，会绕开必要的流程。

在第 13 章和第 14 章中，我们讨论了如何通过合理的流程有效地减小事故的影响范围，以缓解整个部门由生产事故带来的压力。

事后总结和问题根源分析

我们的目标是接收警报，然后人工解决新的、有挑战性的服务问题。反复不断地修复同样的问题简直太无聊了。事实上，这个理念是 SRE 和传统运维团队理念中最大的不同点。下面两章详细描述了这个主题。

第 15 章，描述了如何建立起"无指责"、"对事不对人"的团队文化，只有做到这一步，才能有效了解到在一次事故中哪些地方出现了问题（以及哪些地方做得非常好）。

第 16 章，在这个基础上，我们简要描述了一个内部工具，事故跟踪系统。SRE 团队使用该系统跟踪最近发生的生产事故、原因以及解决的具体过程。

测试

当我们发现经常出现问题的组件或者流程时，下一步就是如何避免它再次发生故障。通过增加测试，保证软件在发布到生产环境中时不会出现某些类型的问题。在第 17章中详细描述了相关的最佳实践。

容量规划

在第 18章中，我们给出了一个具体的工具开发实践案例。SRE 利用Google 内部工具Auxon，自动化进行服务容量规划。

容量规划后，我们还需要保证合理的负载均衡体制能够正确地使用这些服务容量。在第19 章中，我们讨论了用户请求是如何发送到数据中心的。在第 20章和第 21章中，我们详细描述了数据中心中的负载均衡体系是保障服务可靠度的关键。

最后，在第 22章中，我们讨论了如何从系统设计层面与战术层面应对"连锁故障"。

软件研发

GoogleSRE 模型的要点之一就是 SRE一半的精力都花在设计和开发大规模软件系统上。

在第 23 章中，我们解释了Google许多系统的核心组件——"分布式共识"系统（Paxos 的新说法），例如全球分布式定时任务系统。在第24章中，我们描述了SRE是如何设计和部署一个跨数据中心的定时任务系统的。

第25章描述了批量数据处理系统的几种形态∶从定时运行的 MapReduce程序，到实时数据处理系统。不同的系统架构可带来不同的新奇与反直觉的挑战。

在第 26 章中，我们详细描述了数据一致性的重要性，如何确保之前存储的数据可以被安全地读取回来。

产品设计

最后，在第 27章中，我们描述了处于整个可靠度金字塔模型顶端的产品设计理念。我们解释了Google是如何改进产品设计，以确保全球用户在产品上线第一天起就拥有最好的用户体验的。

扩展阅读

如前文所述，有效的测试（这里的测试同时指软件层面的测试，也指流程、组织上的灾难演习）是非常困难的。如果测试的方法不对，甚至会对整个服务的可靠性带来影响。在一篇 ACM 论文中（参见文献 【Kril2】），我们解释了Google是如何通过全公司的灾难演习来确保公司可以在大型灾难发生时正常工作的。

容量规划，有时候经常被说成是一种通过大量神奇的表格进行的黑魔法。但是通过文献【Hix15a】中的这篇文章，我们详细描述了正确地进行容量规划并不一定需要用水晶球预见未来的能力。

最终，文献 【War14】描述了Google的一种新的网络安全方法论。通过这项计划，我们正在逐步将有高权限的内网验证替换为使用用户设备和用户身份验证。当读者进行下一个网络设计的时候，可以试验一下这种方式。