AWS 十周年，亚马逊 CTO 总结的 10 个教训
发布于 2016-04-11 06:25:00 | 217 次阅读 | 评论: 0 | 来源: 分享
亚马逊(Amazon)
亚马逊公司（Amazon，简称亚马逊；NASDAQ：AMZN），是美国最大的一家网络电子商务公司，位于华盛顿州的西雅图。是网络上最早开始经营电子商务的公司之一，亚马逊成立于1995年，一开始只经营网络的书籍销售业务，现在则扩及了范围相当广的其他产品，已成为全球商品品种最多的网上零售商和全球第二大互联网企业，在公司名下，也包括了AlexaInternet、a9、lab126、和互联网电影数据库（Internet Movie Database，IMDB）等子公司。
Amazon S3 的发布是 AWS 的新纪元，那是2006年3月14日，至今几乎10年了。回想这10年来，以尽可能最低成本构建一个要求安全、可靠、可伸缩、性能可预测的运营服务，我们学到了数以百计的教训。
鉴于 AWS 是全球领先的云服务建设和运营商，这些教训对我们的业务是极其重要的。就像我们以前常说的，“经验的积累没有压缩算法。” 每月超过100万活跃用户，而这些用户又可能向数亿自己的客户提供服务，这里绝不缺乏获取更多经验的机会，也许没有哪个系统能想我们这样持续改进对用户的服务。
我从这些教训里挑选了一些来与你分享，希望对你也有所帮助。
1. 搭建可进化的系统
从做AWS的第一天起，我们就清楚，我们正在开发的这套软件不是一劳永逸的。预期是用户每增加一两个数量级后，我们就需要重新考虑并修订架构，以确保应对规模增长产生的问题。
但是，我们不能用停机维护的老办法来升级系统，因为全世界许多客户都是依靠我们的平台提供7 x 24 小时的服务。我们需要构造一个无需停止服务就能引入新组件的架构。亚马逊杰出的工程师 Marvin Theimer 有一次开玩笑地说，对于Amazon S3 的演化最恰当的比喻是，从一架单引擎赛斯纳小飞机开始，随着时间的推移，升级成了波音737，然后是747机群，最后一路发展成目前庞大的空客380机队。在整个过程中，我们一直在空中加油，把乘客在飞机之间来回转移，而他们甚至没有任何察觉。
2. 接受一切意外
故障是一定会出现的，只是个时间问题：从路由器到硬盘，从操作系统到破坏了TCP数据包的内存单元，从短暂的错误到永久的故障。这是不可避免的，不管你用的是最高质量的硬件还是最低成本的元件。
在规模扩大后，问题更加凸显：比如，由于 S3 负责处理几万亿次的存储事务，任何一个哪怕最微小的出错可能性，都会演变为现实的故障。很多故障场景可以提前预料，但更多的在设计和开发阶段是未知的。
我们开发的系统需要拥抱故障，把故障作为自然存在，即使不知道故障会是什么样子。系统需要保持运行，即使“房子着火了”。能够在不关闭整个系统的同时处理受到冲击的部分，是非常重要的。我们掌握了控制故障“爆破半径”的基本技巧，这样就可以保持系统的整体健康。
3. 用原语，不用框架
很快，我们开始意识到用户以一种’持续建设’的方式使用我们服务。当用户摆脱IT硬件和数据中心的旧世界的束缚时，他们开始用闻所未闻的、有趣的新方式开发系统。因此，我们需要做到极尽敏捷才能满足用户的需求。
最重要的机制之一是，我们提供给用户的是原语和工具集，什么都有，他们可以拿来按照自己的喜好与 AWS 云结合，而不是仅仅提供一个框架来强迫他们使用。这个机制给我们的用户带来了巨大的成功，以至于AWS 后续的服务也采用了相同的机制，我们的用户对此已经习惯。
同样重要的一点是，在用户还没开始使用一个服务之前，我们很难准确预知到该服务的特定优先级。这也是为什么所有的新服务最初都会以最小的功能集发布，然后借助用户的反馈，再对该服务进行功能扩展。
4. 自动化是关键
开发供人操作的软件服务与制作发售给用户的软件是完全不同的。管理大规模系统需要非常不同的思维方式，以确保满足用户对可靠性、性能和伸缩性的要求。
实现这一点的关键机制是尽可能自动化管理，摒弃易于出错的人工操作。我们需要开发控制核心功能的管理 API 来达到这个要求。AWS 也帮助用户实现自动化，方法是将你的应用程序分解为基本的“积木块”，每一个都带有管理 API，你可以设置自动化规则来维持大型系统的可靠性和可预测的性能。一条不错的检验原则：如果你需要ssh登录到一台服务器或实例，那么你的自动化就是不够的。
5. 恒久的API
这是我们从亚马逊零售业务的经历总结出的一条教训，对 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 设计的网络硬件和软件是如何使我们为用户进一步提升性能的，这里有另一个成功的例子，就是在虚拟机上处理网络接入的“虚拟化税”（译者注：ZDNET这篇文章提到了虚拟化税virtualization tax，指反对虚拟化技术的人士认为虚拟化带来更多间接费用 ）。因为网络接入是个共享资源，用户以前偶尔会感受到明显的网络抖动。开发一款支持 single root IO 虚拟化的单网卡让我们可以给每台虚拟机自己的硬件虚拟网卡。这使延迟降低了 2 倍，整体网络的延迟不确定性降低了 10 倍。
10. 没有看门人
AWS 团队这些年发布了很多服务和特性，为用户创建了一个既有广度又有深度的平台。但是 AWS 完全不止是我们闭门造车出来的服务：借助于我们的合作伙伴交付的服务，一个非常丰富的服务生态系统形成了，将平台扩展到了很多新的方向。
例如，在我们的合作伙伴里，Stripe 提供支付服务，Twilio 使得 AWS 上可以编写电话语音应用。很多用户自己在 AWS 上层构建平台来满足特定的垂直需求：Philips 建立了 Healthsuite 数字平台用于管理医疗数据，Ohpen 在 AWS 上建立了银行零售平台， Eagle Genomics 建立了基因处理平台，还有很多很多。关键是，AWS 平台上没有看门人告诉我们的合作伙伴什么能做什么不能做。“没有看门人”解放了创新过程，打开了许多难以想象的创新大门，这样的结果是必然的。
我非常期待在下一个10年里看到我们还能学到什么，AWS 的用户能实现什么。记住，现在依然只是开始 ……