10 年 Amazon Web Services 总结得到的 10 个经验教训

汉王笔记 2017年07月17日收藏

2006年3月14日，Amazon S3的发布，意味着AWS时代的开启，离现在差不多刚好10年。回首过去的10年间，我们学到了许许多多有关于构建和运营服务所需的安全性，可靠性，可扩展性，以及如何用尽可能低的成本提供可预测性能的经验教训。考虑到AWS是在全球建设和运营这些服务的先驱，这些教训对我们的业务至关重要。正如我们以前说过多次，“没有用于经验的压缩算法”。AWS每月有着过万的活跃用户，而且这些用户反过来可能服务着他们自己数以亿计的客户，所以，我们不但不乏获得更多经验的机会，而且这可能是我们所能提供的最好的改进了。

我精心总结了一些经验教训想与大家分享，希望能对你有用。

1.建立可进化的系统

不知道从什么时候开始，我们认识到我们构建的软件不会是一年后运行该软件的样子。人们期望重新审视和修改架构，所以我们要确保我们可以解决规模的问题。

但是，我们不能采取通过停运维护来升级系统的旧方法，因为世界各地的企业依赖我们平台7天/24小时的可用性。我们需要建立这样一个体系结构，它可以方便地引入新的软件组件，而不需要考虑停止服务。Marvin Theimer，Amazon杰出的工程师，曾开玩笑地说过，Amazon S3的演变可以被很恰当地比喻为一开始作为一架单引擎塞斯纳飞机起飞，但随着时间的推移，飞机升级到737，然后是一组747，一路向前，现在俨然成为了空客380大舰队。在这期间，我们只能在半空中给飞机加油，同时将这架飞机的乘客转移到另一架飞机上，而不让他们意识到这一点。

2.接受意外

失败是必然的，随着时间的推移，一切最终都将失败：从路由器到硬盘，从操作系统到存储单元损坏TCP数据包，从瞬态错误到永久性故障。这是一个事实，无论你使用的是最高品质的硬件还是成本最低的组件。

这个经验教训在大规模环境中甚至更重要：例如，由于S3要处理数万亿的存储事务，任何误差，即使最轻微的可能性都将成为现实。许多这样的故障情形可以事先预见，但在设计和建造阶段更多的是未知。

我们需要构建一个能够拥抱失败并视失败为当然的系统，即使我们确实不知道失败在哪里。系统需要保持运行，即使“房子着了火”。能够管理受影响的部分而毋需停止整个系统很重要。我们已经具备了管理一个失败事件“爆炸半径”的基本技能，这样可以维持系统的整体运行状况。

3.提供基元而非框架

很快，我们开始认识到，客户想要的服务是永远没有终点的工作。当客户留下约束，以前的IT硬件和数据中心时，我们就得开始开发从来没有人见过的、使用模式又新又有趣的系统。因此，我们需要极度敏捷，以确保我们能够迎合客户的需求。

我们提供的最重要的机制之一是向客户提供基元和工具集，在那里他们可以挑选他们从事AWS云的首选方法，而不是只提供一个强迫他们使用的框架，甚至框架中已经囊括了所有一切。这种做法使我们的客户获得很大的成功，以致于后来几代的AWS服务也沿用了完全相同的基元服务，因为客户已经习惯了。

同样重要的是要认识到我们很难预测哪些侧重点更为客户所喜爱，直到他们亲身体验过服务，并真正开始用它来构建。这就是为什么我们发布新服务时经常带一个极简的功能集，并允许客户帮助推动路线图通过新功能来扩大服务。

4.自动化是关键

需要进行操作的开发软件服务，从根本上来说和构建需要发布给客户的软件完全不同。管理大规模的系统要求非常不同的思维方式，以确保能够满足客户的可靠性，性能和扩展性的期望。

实现这一点的关键机制是，要尽可能多地自动化管理，删除容易产生的错误和手动操作。要做到这一点，我们需要构建管理API来控制业务操作的关键功能。 AWS可以帮助客户做到这一点。通过将你的应用程序分解为基本的构建块，每一个带一个管理API，这样你就可以应用自动化的规则规模化地维持可靠和可预测的性能。一个立见分晓的检验办法是，如果你需要SSH到服务器或实例，那么你还有更多可以自动化的地方。

5. 永远的API

这个经验教训是我们从Amazon零售中所吸取的，但在AWS的以API为中心的业务中更有价值。一旦客户使用我们的API开始构建他们的应用程序和系统，就不能再改变那些API，否则会影响客户的业务运营。我们得谨记，设计API是一个非常非常非常重要的任务，因为我们只有一次机会。

6.了解资源使用情况

当为一个服务构建财务模型以确定相应的收费模式时，对于服务以及操作的成本一定要确保有很好的数据资料，尤其是对于那些容量大利润低的业务。AWS要有意识地作为关于成本的服务供应商，这样我们才有能力提供服务给客户，并确定哪些领域可以提高业务运营效率以进一步削减成本，然后将那些节省下来的资金用一种价格更低的形式回馈给客户。

这里举一个S3的例子，在早期我们不知道需要资源为某些使用模式提供服务：我们曾假设存储和带宽是我们应该收费的资源；在运行一段时间之后，我们发现请求的数量也是一种同样重要的资源。如果客户有许多微小的文件，那么即使他们有数以百万计的请求，存储和带宽也不会很多。我们不得不调整我们的模型以考虑到资源使用的所有方面，让AWS成为一个可持续发展的业务。

7.彻底的安全构建

保护客户应该总是首选目标，所以理所当然的，它一直都是AWS的首选目标……无论是从运营的角度，还是工具和机制方面：这将永远是我们的第一位的投资领域。

其中一种我们快速学到的方法是构建安全服务，在服务设计的一开始就集成安全很有必要。安全团队并不是在已建成之后做验证的一群人。他们必须在第一天就携手确保安全是彻底的，是稳如泰山的。当涉及到安全性的时候，没有妥协。

8.加密是一等公民

加密是确保客户能够全面控制谁有权访问他们的数据的一个关键机制。十年前，用于加密的工具和服务很难使用，然后几年后在我们的业务操作中，我们学会了如何加密以便于更好地融入到我们的服务中。

它始于在S3中通过提供服务器端加密用于依从性用例。如果你想在我们的数据中心检查任何磁盘，没有数据会允许访问。但随着Amazon CloudHSM（用于硬件安全模型）和之后Amazon Key Management Service的推出，客户可以使用他们自己的密钥进行加密，这意味着AWS不再需要管理用户的密钥。

一段时间以来，对加密的支持已经集成到每个新服务的设计阶段。例如，在Amazon Redshift中，每个数据块用随机密钥默认加密，并且这些随机密钥的集合再用主密钥进行加密。主密钥可由客户提供，确保他们是唯一可以解密和访问关键业务数据或个人身份信息的人。

加密仍然是我们业务的重点。我们将继续努力让我们的客户更方便地使用加密技术，确保他们能够更好地保护他们自己和他们的客户。

9.网络的重要性

AWS支持许多不同的工作负载：从大容量事务处理到大规模视频转码，从高性能并行计算到大量的网站流量。每个工作负载都有独特的要求，当涉及到网络的时候。

AWS开发了一个独特的技能，从而革新了数据中心的布局和操作，这样我们就有了灵活的网络基础架构，用于满足客户的工作负荷，不管这些负荷是什么。随着时间的推移，我们懂得了不应该惧畏开发我们自己的硬件解决方案，这能确保我们的客户实现他们的目标。这使得我们能够满足非常具体的要求，例如彼此隔离网络上的AWS客户以实现最高水平的安全。

另一个AWS设计的网络硬件和软件，如何使我们能够进一步提高客户性能的成功例子是，解决来自于虚拟机的关于网络接入的虚拟化压力。由于网络接入是共享资源，客户以前有时可以在网络上体验到显著抖动。开发一个支持单根IO虚拟化的NIC，允许我们给每个VM它自己的硬件虚拟NIC。这降低了延迟2倍都不止，并且在网络的延迟变化中提升超过10倍。

10.没有守门人

随着时间的推移，AWS团队已经发布了很多服务和功能，旨在为客户创造了一个广阔而深入的平台。但是AWS不仅仅是我们内部构建的服务：合作伙伴发布的非常丰富的生态系统服务项目将这个平台扩展到许多新的方向。

例如，在AWS上，我们有提供支付服务的Stripe，也有让电话可编程的Twilio等等合作伙伴。我们的许多客户还在AWS上自己来构建平台，服务于特定的垂直需求：Philips正在建设他们的Healthsuite Digital Platform来管理医疗保健数据，Ohpen在AWS上建立了一个用于零售银行业务的平台，Eagle Genomics建立了一个基因组学处理平台，等等，还有很多。重要的是，目前在AWS平台上没有守门人告诉我们的合作伙伴他们可以做什么和不可以做什么。 “没有看门人”解放了创新过程，并为许多意想不到的创意打开了大门。

我期待在未来的10年时间中我们能学到更多，能为AWS客户做更多的事情。请记住，每一天都是新的一天。