云头条讯：对AWS来说值得纪念的大事是2006年3月14日发布亚马逊S3，距今已有十年时间。回顾过去这十年，对于构建和运营需要确保安全性、可用性和扩展性的服务，以尽可能低的成本获得稳定性能，我们在这方面获取了大量的经验教训。考虑到 AWS是在全球范围构建和运营这些服务方面的开拓者，这些经验教训对我们的业务来说至关重要。正如我们之前常说的那样，“没有面向经验的压缩算法”。鉴于AWS每月有100多万个活跃客户，而这些客户反过来自己可能要服务成千上万客户，所以有的是机会获得更丰富的经验，并且不断改进我们服务客户的方式。

　　我从这些经验教训中挑选出了几条与大家分享，希望对你也有所帮助。

　　1. 构建与时俱进的系统。

　　几乎从一开始，我们就知道，我们构建的软件不会是一年后还在运行的软件。预期目标是，随着用户数出现一两个数量级的增长，我们需要重新考虑并修改架构，确保我们能够处理好规模问题。

　　但是我们无法采用通过维护停运来升级系统的老套方法，因为全球各地的许多公司全天候依赖我们的平台，需要确保24/7的可用性。为此，我们需要构建这样一种架构：可以在服务不停运的情况下推出新的软件组件。亚马逊的杰出工程师马文·泰默（Marvin Theimer）有次开玩笑说，打个恰当的比方，亚马逊S3 的演变之路好比是，一开始是单引擎Cessna飞机，后来慢慢升级成波音737，后来升级成波音747，现在升级成一大群空客A380。我们一直在空中加油，确保飞机正常飞行，将客户从一种飞机挪到另一种飞机，而客户对此毫不知情。

　　2. 预料无法预料的事情。

　　故障是难免的；久而久之，每个系统最终都会出现故障：从路由器到硬盘，从操作系统到破坏TCP 数据包的存储单元，从暂时性错误到永久性故障，不一而足。无论你使用质量最好的硬件还是价格最低的部件，故障总归是难免的。

　　在大规模环境下，这成了一个更重要的经验教训：比如说，由于S3 处理数万亿个存储事务，哪怕出错概率极小的问题也会变成实际的重大问题。许多那些故障场景可以事先预料到，但更多的故障场景在设计和构建时却是未知的。

　　为此，我们需要构建容忍故障这种平常现象的系统，即使我们不知道会是什么样的故障。哪怕“院子着火”，系统也要能够继续运行。能够确保部件受到影响后，整个系统不必停运，这点很重要。我们逐渐培养了一种基本的技能：控制故障事件的“波及范围”，那样可以保持系统的整体运行状况。

　　3. 提供基本服务，而不是提供框架。

　　我们很快就开始发现，客户喜欢使用的服务是不断改进的服务。客户摆脱传统 IT 硬件和数据中心的束缚后，开始开发系统，而这些系统新的、有趣的使用模式是之前从未有人见过的。正因为如此，我们需要异常灵活，确保可以满足客户的要求。

　　我们提供的最重要机制之一是，为客户提供一系列基本服务和工具，那样他们可以挑选自己偏爱的方式来使用AWS云，而不是只提供一种迫使他们使用的包罗万象的框架。这种方法让我们的客户能够获得巨大成功，连后几代AWS服务也可以充分利用客户已经习惯使用的同一套基本服务。

　　认识到这一点同样很重要：除非你的客户手里有了服务，开始用服务实际构建产品，否则很难预测客户有哪些优先事项。这就是为什么我们常常交付最少功能特性的新服务，让客户可以帮助推进路线图，用新的功能扩展服务。

　　4. 自动化是关键。

　　开发需要运营的软件服务与构建需要交付给客户的软件大不一样。管理大规模系统需要一种完全不同的观念，确保我们满足客户在可靠性、性能和可扩展性等方面的要求。

　　做到这一点的一种主要机制是，尽可能实现管理自动化，消除易出差错的手工操作。为此，我们需要构建一套管理API，控制我们系统运营的主要功能。AWS还在帮助客户做好这项工作。通过将你的应用程序分解成一个个必要的独立模块，每个模块都有自己的管理 API，你就可以运用自动化规则，在大规模环境下保持可靠、稳定的性能。一个可靠的判断标准是，如果你需要使用SSH登录到服务器或实例，那么仍有更多方面需要实现自动化。

　　5. API搞好后永远不变。

　　我们已经在亚马逊零售方面获得了这个经验教训，但是它对AWS以API为中心的业务而言变得更为重要。一旦客户开始使用我们的 API 构建应用程序和系统，我们就不可能再改变那些API，因为如果我们那么做的话，会影响客户的业务运行。我们知道，设计API是一项非常重要的任务，因为我们只有一次把API做好的机会。

　　6. 了解资源使用情况。

　　为某项服务设计财务模式以确认合适的收费模式时，务必要拥有关于服务的成本及运营的可靠数据，对运行数量大、利润低的业务来说更是如此。作为一家服务提供商，AWS需要非常关注自己的成本，那样我们才有能力为客户提供服务，并确认我们可以在哪些方面提高运营效率，进一步降低成本，然后以更低的价格这种形式，将节省的那些成本惠及客户。

　　举例来说，在早期阶段，对于S3，我们不知道为某些使用模式提供服务需要哪些资源：我们当时假定，存储和带宽是我们应该收费的资源；后来运行一段时间后认识到，请求数量是种同样重要的资源。如果客户有许多很小的文件，那么即使他们提出数百万个请求，存储和带宽也不会占用太多资源。我们不得不调整模式，顾及到资源使用的方方面面，那样AWS就能确保业务可持续发展。

　　7. 一开始就做好安全。

　　保护好客户应该是头等大事，对AWS来说也是如此，从运营的角度和工具及机制的角度来看，都是如此。这永远是我们关注的首要方面。

　　我们很快学会的一个方法就是，为了构建安全服务，有必要在服务设计的初始阶段就做好安全。安全团队不是服务构建完毕后负责验证工作的团队。它们一开始就应该是合作伙伴，确保一开始安全就固若金汤。说到安全，根本没有妥协的余地。

　　8. 加密是头等大事。

　　加密是客户确保自己全面控制谁可以访问其数据的重要机制。十年前，用于加密的工具和服务用起来有难度，直到我们的系统运营几年后，我们才学会了如何将加密最有效地集成到自己的服务中。

　　最初是在S3中提供服务器端加密，以适合合规这一应用领域。如果你检查我们数据中心中的任何磁盘，会发现任何数据都访问不了。但是亚马逊CloudHSM（面向硬件安全模式）以及亚马逊密钥管理服务（Amazon Key Management Service）相继发布后，客户就可以使用自己的密钥进行加密，这样AWS不需要管理客户的密钥了。

　　支持加密的功能在每个新服务的设计阶段就集成进来，这种做法至今已有一段时日。比如在亚马逊Redshift中，每个数据块在默认情况下用随机密钥来加密，这些随机密钥的组合又用主密钥进行加密。主密钥可以由客户来提供，确保只有客户才能解密、才能访问其关键的业务数据或个人身份信息。

　　对我们的业务来说，加密继续是一个重要的优先事项。我们会继续让客户更容易充分利用加密机制，那样他们就能更有力地保障自己及其客户。

　　9. 网络的重要性。

　　AWS 逐渐支持许多不同的工作负载：从大容量事务处理到大规模视频转码，从高性能并行计算到海量网站流量，不一而足。那些工作负载对网络各自有着独特的要求。

　　AWS已掌握了一项独特的技能，实现数据中心布局和运营方面的创新，那样我们就能拥有灵活的网络基础设施，而基础设施可以灵活改变，适应客户工作负载的要求，无论是什么样的工作负载。我们已渐渐明白：我们不该害怕自行开发解决方案，确保客户能够实现其目标。这让我们能够满足非常具体的要求，比如说能够将AWS客户与同一个网络上的其他客户彼此隔离开来，获得最高的安全级别。

　　AWS设计的网络硬件和软件让我们能够进一步为客户提高性能，这方面的另一个成功例子就是处理虚拟化技术给网络访问带来的负担：虚拟机频繁访问网络。由于网络访问是一种共享资源，客户之前有时在网络上遇到严重的抖动现象。开发一种支持单根IO虚拟化的网卡，让我们得以为每个虚拟机分配各自的硬件虚拟化网卡。这大幅缩短了延迟，并将网络上的延迟稳定性提高了10倍。

　　10. 不设看门人。

　　随着时间的推移，AWS 团队交付了许多服务和功能，为客户构建了一个广泛又纵深的平台。但是，AWS 不仅仅关注内部开发的服务，还有一个非常丰富的生态系统，我们的合作伙伴在提供服务，它们共同将这个平台扩展到许多新的方向。

　　比如说，我们的合作伙伴Stripe在为Twilio提供支付服务，让电话系统在AWS上具有可编程性。许多客户还在AWS的基础上自行构建平台，满足垂直领域的具体要求：飞利浦在构建Healthsuite数字化平台，用于管理医疗健康数据；Ohpen在AWS上构建了一个面向零售银行业务的平台；Eagle Genomics 构建了一个基因组处理平台，不一而足。最重要的是，AWS平台上没有看门人规定我们的合作伙伴可以做什么、不可以做什么。“不设看门人”解放了创新流程，并为许多意想不到的发明创造了条件，许多发明势必会接踵而至。

　　我期望我们在接下来十年能学到什么样的经验教训，以及AWS客户能完成什么样的任务。别忘了，现在仍然是刚开始。