10 Lessons from 10 Years of Amazon Web Services（译文）

前言

亚马逊在2006年3月14日发布AWS，到现在差不多10年了。回首过去的10年里，我们在构建安全，高可用性，可扩展性，低成本的服务方面积累了几百条经验与教训。由于AWS是建设并在全球运营这些服务的先驱，这些教训对我们的业务至关重要。正如我们以前多次说，“没有压缩经验的算法”，每月有超过百万的活跃客户，这些客户服务几个亿的用户，在这个过程我们不乏机会积累经验并持续优化从而为客户提供更好的服务。

我选择了下面这些经验教训，与大家分享，希望它们对你们有用。

1. 构建不断进化的系统

几乎从第一天开始,我们知道自己开发的软件在一年后将不会继续运行。我们需要重新审视和改进架构，以确保我们可以解决订单规模增长一到二个数量级所带来的问题。但是我们不能采取停电检修这种旧方法升级系统，这是因为遍布世界各地的海量业务需要我们的平台提供7*24小时高可用性服务。我们需要建立这样架构：能够在不停止服务的情况下引入新的组件。Marvin Theimer,亚马逊杰出工程师，曾开玩笑地说，亚马逊S3的演变可以被描述为从当初的单引擎飞机，随着时间的推移飞机不断升级，先是升级到737，然后是一组747，现在成了3805的空中舰队。在此期间，我们在飞行过程中完成加油，而客户甚至没有觉察到这一点。

感悟：唯有变化才是确定，系统应该保证灵活性与扩展性。云计算系统是需要不断进化，开发人员也需要不断进化

2. 总有想不到的

异常总是会发生的，随着时间的推移，一切都会出现异常：从路由器到硬盘，从操作系统到内存单元，从瞬态错误到永久性故障。无论你使用的是最高品质的硬件或最低成本的硬件，这些总是会发生的。在大规模系统中更是如此，例如，在S3中处理和存储的万亿交易，任何异常，即使是最小的可能性也将成为现实。部分这样的异常可以事先预见的，但更多的异常却在设计和开发过程中未能被发现。

我们需要开发一个视异常为常态的系统，即使我们不知道会有什么样的异常。即使“房子着火了”，系统也需要保持运行。重要的是在整个系统在不宕机的情况下能够处理这些异常。我们掌握隔离异常与控制异常的影响范围的方法从而使整个系统能够正常运行。

感悟：异常是常态，如何处理异常是系统设计阶段必须考虑到的问题。

3. 提供基元而不是框架

我们很快意识到，客户的需求是不断变化的。当客户摆脱传统的IT硬件和数据中心的限制，他们开始使用感兴趣却没有应用过的模式搭建系统。因此，我们努力做到超级敏捷以确保满足客户的需求。

其中一个最重要的策略是向客户提供的基元和工具，让客户从中选择最合适他们的集合，而不是只提供一个框架中，迫使他们不得不使用。这种做法使我们的客户取得了成功，其后的AWS服务也同样利用这些客户已经熟悉的基础服务。

同样重要的是我们不知道客户下一个关心问题是什么，直到他们开始使用我们的服务。这就是为什么我们经常用最少的功能集提供新的服务，让我们的客户能够帮助推动产品路线图规划与新功能的开发。

感悟：客户的需求是下一个产品。立足基础，理解客户的需求，才能满足客户。

4. 自动化是关键

提供云计算服务不同于开发并交付软件，管理大规模系统需要不同的思维方式，以确保满足用户的高可用性，高性能和可扩展性的需求。

这其中关键的一点是尽可能地实现自动化管理以避免容易出错的手动操作。要做到这一点，我们需要实现管理API从而管理我们的业务的关键功能。AWS可以帮助客户做到这一点。通过为应用程序的每一个分解组件提供管理API，从而应用自动化的规则来保证可靠性和预期的性能。

如果你需要SSH到一个服务器或一个实例，那么你仍然需要更多的自动化，这是一个衡量自动化水平的好方法。

感悟：用人管理代码，用代码管理机器

5. APIs are forever（API是不会变的）

这是我们从亚马逊零售业务经验中吸取的教训，它的重要性甚至超过了AWS中那些以API为中心的业务。

一旦客户开始使用我们的API构建他们的应用程序和系统，改变这些API变得不可能，因我们修改这些API,会影响客户的业务运营。我们只有一次机会定义API,所以设计API是一个非常重要的工作。

感悟：接口优先，实现其次，实现可以调整，而接口一旦上线就没有什么回旋的余地。

6. 监控资源应用

当构建一个服务，一定要有服务及其运营成本的数据以确定相应的计费方式，尤其是对于运行高营业额-低利润率的业务。AWS理所应当关注服务的成本，这样我们在为客户的提供服务的同时能够明确在哪些地方可以提高运营效率，以进一步削减成本，以更低的价格回馈客户。

在创业初期，我们不知道S3服务应该采用哪种计费方式：我们曾认为应该对存储和带宽资源计费;经过一段时间，我们认识到请求的数量也应当计费。如果客户有许多微小的文件，即使他们上百万次数请求服务，消耗的存储和带宽都不会很高。我们不得不针对资源使用各个维度调整计费方式使AWS成为是一个可持续发展的业务。

感悟：无监控不系统，无度量不优化。作任何商业服务不仅要有成本意识，而且应该作到度量成本。

7. 从一开始集成安全

保护你的客户应该永远是你的首选，对于AWS来说亦是如此。不管运营的角度，还是策略方面，这将永远是我们的头号投资领域。

我们很快地发现只有在一开始就把安全考虑进去才能提供安全的服务。安全团队的工作不是服务开发完成之后进行验证，他们必须在服务设计的第一天确认安全已经落实，且稳如泰山。总之对于安全，没有任何妥协。

感悟：安全是基本功能。

8. 加密是一等公民

加密是为确保客户能控制谁有权访问他们的数据一个关键机制。十年前，加密工具和服务很难使用，直到几年前我们学会更好地将加密集成到我们的服务当中。最早的加密是从S3服务端开始的。如果您想检查我们的数据中心的任何磁盘，任何数据都不可访问的。但随着亚马逊推出CloudHSM（硬件安全模块）和Amazon Key Management Service（密钥管理服务），客户可以加密自己的密钥，从而不再需要AWS来管理钥匙。一段时间以来，每个新服务均支持加密。例如，Amazon Redshift的每个数据块默认以随机密钥加密，随后这些随机密钥被私钥再加密。私钥由客户提供，确保他们是唯一可以解密和访问他们的关键业务数据或个人身份信息。

加密仍然是我们业务的重点。我们将继续为我们的客户提供更加便捷的加密方式，使他们能够更好地保护自己及其客户的数据。

感悟：一定不要让核心数据裸奔。

9. 网络相当重要的

AWS已经支持许多不同类型业务：大规模的事务处理，大规模网站流量，视频转码，高性能并行计算。其中每个业务具有独特的要求，但都涉及到网络。

利用AWS特有的数据中心技术，我们实现了弹性网络以满足客户的各种不同网络负载。随着时间的推移，我们确信自己开发的硬件解决方案能够帮助客户实现他们的目标。这使我们能够满足非常具体的要求，比如实现不同AWS用户在网络方面达到最高级别的安全（也就是实现不同租户之间的网络隔离）。

AWS设计的网络硬件和软件是如何进一步提高我们的客户性能的另一个成功的例子是解决虚拟机的虚拟网络访问的问题。由于网络接入是不同客户共享的，导致客户的网络访问时常有明显的抖动。开发一个支持SRIOV网卡让每个虚拟机拥有自身的虚拟网卡，从而使延迟时间降低2倍以上，并在延迟网络环境的改善超过10倍。

感悟：网络是服务的交付与实现的交通运输线，重要性不言而喻。传统网络难以满足云计算的需求，所以以SDN与NFV为基础的新网络技术会得到广泛的应用，但是这些技术很有可能是由云计算厂商自己开发利用，而不是由思科等传统网络设备商决定的，因为云计算厂商更需要这样的技术也更理解云计算对网络的需求。云计算厂商也有决心来作这件事：既然网络需求会不断变化，那应该将变化掌握在自己手中，另一方面，云计算作为未来长期存在的互联网基础设施，从长远来看网络产品的自研也可以节省一大笔成本。

10. 保持开放

随着时间的推移，AWS团队通过提供多种服务和功能已经为客户创造了非常广泛而深入的平台。AWS上现有服务数量远远超过我们开发的服务数量：通过我们的合作伙伴，该平台不断扩展新的方向，已经成为一个丰富的生态系统。

例如，我们合作伙伴Stripe在AWS上为Twilio提供支付服务。还有许多客户基于AWS构建自己的平台服务于特定垂直需求：飞利浦正在建设自己的Healthsuite数字平台来管理医疗数据，Ohpen已经建立了AWS零售银行业务的平台，Eagle Genomics已经建立了一个基因处理平台，还有很多。最重要的是，目前在AWS平台上没有条条框框告诉我们的合作伙伴，他们可以做什么和不能做什么。没有条条框框的限制解放了创新，并诞生了许多意想不到的发明，这是一定要遵循的。

感悟：云计算提供开放平台，让百花齐放！云计算是互联网的基础的设施！

后记

这是亚马逊CTO Werner Vogels在AWS发布十年之际写的一篇文章，亚马逊是云计算的先驱和全球的领导者，作为亚马逊CTO还常写一些技术性文章，必定是真知灼见，这些经验教训为今后的系统设计提供了很好的参考，有助于权衡决策。

第一次翻译一篇完整的文章，表达与措词方面有很多不足，把它发出来了，主要想看看以后能取得多大的进步。

最后，虽然翻译水平一般，但是还是建议：有时间结合工作认真地读一遍原文

文章目录

前言