2 整体服务设计
一直以来，人们都相信80%的运营问题源于设计和开发，因此本节关于整体服务设计的内容篇幅最长，也最重要。系统出故障时，人们很自然倾向于首先去审视运营工作，因为这是问题实际产生的地方。不过，绝大多数运营问题都可以归因于设计和开发，或者最适合在设计和开发中解决。随后的内容凸显一个共识，即在服务领域，将开发、测试和运营严格分离不是最有效的方式。在环顾众多服务之后，我们发现了这样一个趋势——管理的低成本与开发、测试和运营团队间协作的紧密程度密切相关。
除了在这里讨论的服务设计最佳实践以外，随后一节“以自动化管理和预置为目标进行设计”对服务设计也有实质性的影响。有效的自动化管理和预置通常以一个受限的服务模型来实现。简单是高效率运营的关键，
这是贯穿本文重复出现的主题。在硬件选择、服务设计和部署模型上的理性约束，是降低管理成本和提高服务可靠性的强心针。
在运营友好的基础原则中，为整体服务设计带来最大影响的几条包括：
2.1 设计时为故障做好准备（Design for failure）。
在开发包含多个协同运作的组件的大型服务时，这是一条核心概念。这些组件会有故障发生，而且故障的产生很频繁。它们之间不会总是稳定地协作，也不会单独出现故障。一旦服务的规模达到10,000台以上的服务器和50,000块以上的磁盘，每天就会有多次故障发生。如果一有硬件故障产生就得采取紧急措施来应对，那么服务就无法以合理的成本可靠地伸缩。整个服务必须有承受故障而无须人工干预的能力。故障恢复的步骤必须非常简单，而且这些步骤应当进行频繁测试。斯坦福大学的Armando Fox 主张说，对故障恢复步骤进行测试的最佳方法，就是绝对不要用正常方式使服务停机，用粗暴的方式让它停转就可以了。乍听起来怎么做是违背直觉的，但是如果没有频繁使用故障步骤，那么它们在真正临阵时就可能溃不成军。
2.2 冗余和错误恢复（Redundancy and fault recovery）。
大型机模型是指购买一台价高块头大的服务器。大型机拥有冗余的电源供应，CPU可以热交换，而且总线架构也超乎寻常，使得这样一个紧密耦合的系统能够有可观的I/O吞吐量。这样的系统，最明显的问题就是它们的成本；而且即便有了所有这些费用高昂的设计，它们仍然不够可靠。为了达到99.999%的可靠性，冗余是必须存在的。实际上，在一台机器上实现4个9的可靠性都是相当困难的。这个概念在整个业界都耳熟能详，不过，将服务构建在脆弱而又非冗余的数据层之上的现象，到目前为止都屡见不鲜。要保证设计的服务其中的任何系统可以随时崩溃（或者因为服务原因被停止）但又仍然能符合服务水平协定（Service Level Agreement，简称SLA），是需要非常仔细的设计的。保证完全遵守这项设计原则的严格测试（acid test）步骤如下：首先，运营团队是否有意愿并且有能力随时让任意一台服务器停机并且不会让负载被榨干？如果答案是确定的，那么肯定存在同步冗余（无数据丢失）、故障侦测和自动接管。我们推荐一条普遍使用的设计方法，用于查找和纠正潜在的服务安全问题：安全威胁建模（Security Threat Modeling）。在安全威胁建模中，我们要考虑每一条潜在的安全威胁，并且相应实现恰当的缓和方案。同样的方法也适用于以错误适应和恢复为目标的设计。
将所有可以想象到的组件故障模式及其相应组合用文档记录下来。要保证服务在每个故障发生后都能继续运行，且不会在服务质量上出现不可接受的损失；或者判断这样的故障风险对于这样一个特定的服务是否可以接受（例如，在非地理冗余的服务中损失掉整个数据中心）。我们可能会认定某些非常罕见的故障组合出现的可能性微乎其微，从而得出确保系统在发生这种故障之后还能继续运行并不经济的结论。但是，在做这样的决定时请谨慎从事。在运行数以千计的服务器的情况下，每天都会有几百万种组件故障产生的可能，这时那些事件的“罕见”组合亮相的频繁程度，足以让我们瞠目结舌。小概率组合可能变成普遍现象。
2.3 廉价硬件切片（Commodity hardware slice）。
服务的所有组件都应当以廉价硬件切片为目标。例如，存储量轻的服务器可以是双插槽的2至4 核的系统，带有启动磁盘，价格在1,000 至2,500 美元之间；存储量大的服务器则可以是带有16至24个磁盘的类似服务器。主要的观察结果如下：
l 大型的廉价服务器集群要比它们替代的少数大型服务器便宜得多；
l 服务器性能的增长速度依然要比I/O性能的增长速度快很多，这样一来，对于给定容量的磁盘，小型的服务器就成为了更为稳定的系统；
l 电量损耗根据服务器的数量呈线性变化，但随系统时钟频率按立方级别变化，这样一来性能越高的机器运营成本也越高；
l 小型的服务器在故障转移（Fail over）时只影响整体服务工作负荷的一小部分。
2.4 单版本软件（Single-version software）。
使某些服务比多数打包产品开发费用更低且发展速度更快的两个因素是：
l 软件只需针对一次性的内部部署。
l 先前的版本无须得到十年的支持——针对企业的产品正是如此。相对而言，单版本软件更容易实现，附带客户服务，特别是无须费用的客户服务。但是在向非客户人员销售以订阅为基础的服务时，单版本软件也是同样重要的。企业通常习惯在面对他们的软件提供商时拥有重要的影响力，并且在部署新版本时（通常是个缓慢的过程），他们会习惯性想去掌握全部的控制权。这样做会导致他们的运营成本和支持成本急剧上升，因为软件有许多版本需要得到支持。最经济型的服务是不会把对客户运行的版本的控制权交给他们的，并且通常只提供一个版本。要把握好单一版本软件的产品线，必须：
l 注意在每次发布之间不要产生重大的用户体验变更。
l 愿意让需要相应级别控制能力的客户可以在内部托管，或者允许他们转向愿意提供这类人员密集型支持服务的应用服务提供商。
2.5 多重租赁（Multi-tenancy）。
多重租赁是指在同一个服务中为该服务的所有公司或最终用户提供主机服务，且没有物理上的隔离；而单一租赁（Single-tenancy）则是将不同组别的用户分离在一个隔离的集群中。主张多重租赁的理由基本上和主张单版本支持的理由一致，且它的基础论点在于提供从根本上成本更低、构建在自动化和大规模的基础之上的服务。
回顾起来，上面我们所展示的基本设计原则和思考如下：
l 设计时为故障做好准备
l 实现冗余和错误恢复
l 依靠廉价硬件切片
l 支持单一版本软件
l 实现多重租赁
我们约束服务设计和运营的模型，以此最大化自动化的能力，并且减少服务的总体成本。在这些目标和应用服务提供商或IT 外包商的目标之间，我们要划一道清楚的界限。应用服务提供商和IT外包商往往人员更加密集，并且更乐于运行面向客户的复杂配置。