当初我曾错过：快速使用亚马逊AWS的14个经验分享

在今天的文章中，我整理出了大量当初曾经错过、而至今仍将我追悔莫及的Amazon Web Services（简称AWS）使用心得。在几年来的实践当中，我通过在AWS之上新手构建及部署各类应用程序而积累到了这些经验。虽然内容有些杂乱，但相信仍然能给各位带来一点启示。

从物理服务器向“云环境”转移的过程不仅仅是一项技术任务，同时也意味着我们的思维方式需要作出针对性的转变。总体而言，在物理环境下我们需要关注的只是每一台独立主机; 它们各自拥有自己的静态IP，我们能够对其分别加以监控。而一旦其中一台发生故障，我们必须尽最大可能让其快速恢复运转。大家可以以为只要将基础设施转移到AWS环境之下，就能直接享受到“云”技术带来的种种收益了。遗憾的是，事情可没那么简单(相信我，我亲身尝试过了)。在AWS环境之下，我们必须转变思维，而且这方面的任务往往不像技术难题那么容易被察觉。因此，受到了SehropeSarkuni最近一篇帖子的启发，我将自己几年来积累得出的AWS 使用心得汇总于此，而且说实话、我真希望自己当初刚刚接触AWS时能有人告诉我这些宝贵经验。这些心得总结自我在AWS之上部署个人及工作应用程序时的亲身感受，其中一部分属于需要高度关注的“疑难杂症”(我自己就是直接受害者)，而另一部分则是我听其他朋友说起过、并随后亲自确认有效的解决方案。不过总体而言，为了积累这些经验，我确实付出了相当惨痛的代价：)

应用程序开发

千万不要把应用程序状态保存在自己的服务器上。

之所以这么说，是因为一旦我们的服务器发生故障，那么应用程序状态很可能也随之彻底消失。有鉴于此，会话应当被存储在一套数据库(或者其它某些集中式存储体系、memcached或者redis当中)而非本地文件系统内。日志信息应当通过系统日志(或者其它类似方案)进行处理，并被发送至远程位置加以保存。上传内容应当直接指向S3(举例来说，不要将其存储在本地文件系统内，并通过其它流程随后迁移到S3)。再有，任何已经处理过或者需要长期运行的任务都应该通过异步队列(SQS非常适合处理此类任务)来实现。

编辑点评:对于S3上传内容而言，HN用户Krallin指出，我们可以彻底避免其与自有服务器的接触，并利用预签名URL保证用户的上传数据被直接发送至S3当中。

将额外信息保存在日志当中。

日志记录通常包含有时间戳以及pid等信息。大家也可能希望将实例id、服务区域、可用区以及环境(例如分步环境或者生产环境等)添加进来，而这些都能在日后的调试工作中作为参考。大家可以从instance metadata service当中获取到这些信息。我所采用的方法是将这些信息作为引导脚本的组成部分，并将其以文件形式存储在文件系统当中(例如/env/az或者 /env/region等)。这样一来，我就用不着持续查询元数据服务来获取这些信息了。大家应当确保这些信息能够在实例重新启动时得到正确更新，毕竟我们都不希望在保存AMI时发现其中的数据还跟上次完全一样，这肯定属于非正常状况。

如果我们需要与AWS进行交互，请在当前语言中使用对应SDK。

千万不要试图自己动手。我当初就犯过这个错误，因为我认为自己只是单纯需要向S3上传内容，但随着后续服务的持续增加、我发现自己的决定简直愚蠢至极。AWS SDK的编写质量很高，能够自动处理验证、处理重试逻辑，而且由Amazon官方负责维护与迭代。此外，如果大家使用EC2 IAM角色(大家绝对应该这么做，这一点我们后面会进一步提到)，那么该SDK将帮助我们自动获取到正确的证书。

利用工具查看应用程序日志。

大家应当采用管理员工具、系统日志查看器或者其它方案，从而帮助自己在无需在运行中实例内使用SSH的方式查看当前实时日志信息。如果大家拥有集中式日志记录系统(我强烈建议大家使用此类系统)，那么当然希望能在不使用SSH的情况下完成日志内容查看任务。很明显，将SSH引入正处于运行状态的应用程序实例会引发诸多弊端。

运营心得

如果将SSH引入自己的服务器，那么自动化机制恐怕将无法生效。

在全部服务器上禁用SSH访问。

这听起来确实有点疯狂，我知道，但在大家的安全组当中、请务必确保端口22不向任何人开放。如果各位想从今天的文章中获得什么启示，那请千万牢记以下一点：如果将SSH引入自己的服务器，那么自动化机制恐怕将无法生效。从防火墙级别(而非服务器本身)禁用SSH有助于整套框架实现思维转变，因为这样一来我们就能了解到哪些区域需要进行自动化改造，同时大家也能更轻松地恢复访问来解决当前面临的问题。在意识到再也不必将SSH引入实例之后，大家肯定会像我一样感到浑身轻松。没错，这是我在实践中了解到的最惊世骇俗、但也却具实用性的心得。

编辑点评:很多人对这项心得表现出了高度关注(HackerNews网站上还出现了不少值得一读的评论意见)，因此我们要在这里多说几句。我个人也会通过禁用入站SSH来蒙骗自动化机制(哦，我只是SSH一下来修复某个问题，马上就撤)。当然，如果我需要在某个实例中进行主动调试，那么我仍然可以在安全组中将其重新启用，因为有时候我们确实没有其它办法来调试特定问题。另外，具体情况还取决于我们实际使用的应用程序类型：如果大家应用程序的正常运行要求各位能力通过SSH将信息传递至服务器，那么将其禁用肯定不是什么好主意。这种阻断进站SSH的办法确实适合我，也迫使我对自己的自动化机制加以精心打理，不过必须承认、这种方式并不适合每一位用户。

服务器只是暂时性手段，没必要太过关注。我们要关注的仅仅是服务本身。

如果某台服务器出现了故障，大家完全没必要对其太过关注。这是我在利用AWS来替代物理服务器之后，亲身获得的最直接的便利成效。一般来讲，如果一台物理服务器无法正常工作，技术人员总会暂时陷入恐慌。但在AWS当中，大家就完全不必担心了，因为自动伸缩机制会很快帮我们建立起新的实例。 Netflix公司在此基础之上还跨出了更具前瞻意义的步伐，他们组建了Simian Army团队，并尝试Chaos Monkey等极为激进的测试项目——它会随机关闭生产环境下的某些实例(他们还利用Chaos Gorilla项目随机关闭可用区。我甚至得到消息，说是Chaos Kong项目会直接关闭基础设施大区……)。总而言之，我想表达的意思是：服务器总会发生故障，但这不该影响到我们的应用程序。

不要为服务器提供静态/弹性IP。

对于一款典型的Web应用程序，大家应当将一切部署在负载均衡机制之下，并在不同可用区之间对资源使用情况加以平衡。虽然我也遇到过一些需要使用弹性IP机制的情况，但为了尽可能提高自动伸缩效果，大家还是应该利用负载均衡机制取代在每个实例中使用独有IP的作法。

将自动化普及到各个角落。

不只是AWS，自动化机制应该作为整体运营工作中的通用性指导方针，其中包括恢复、部署以及故障转移等等。软件包与操作系统更新都应该由自动化方案所管理，具体可表现为bash脚本或者Chef/Puppet等。我们不该把主要精力放在这些琐碎的杂事上。正如前文中所提到，大家还需要确保禁用SSH 访问，从而快速了解到自己的执行流程中还有哪些方面没有实现自动化改造。请记住前面提到的重要原则：如果将SSH引入自己的服务器，那么自动化机制恐怕将无法生效。

每位员工都要拥有一个IAM账户。永远不要登录主账户。

通常情况下，我们会为服务设置一个“运营账户”，而整个运营团队都将共享登录密码。但在AWS当中，大家当然不希望遵循同样的处理方式。每位员工都要拥有一个IAM账户，其中提供与其需求相符的操作权限(也就是最低权限)。IAM用户已经可以控制基础设施中的一切。截至本文撰写时，IAM用户惟一无法访问的就是计费页面中的部分内容。

如果大家希望进一步保护自己的账户，请确保为每位员工启用多因素验证机制(大家可以使用谷歌Authenticator)。我听说有些用户会将MFA令牌交付给两名员工，并将密码内容交付给另外两名员工，这样主账户在执行任意操作时、都至少需要两名员工的同意。对我来说这种作法有点小题大做，但也许您所在的企业确实需要如此高强度的控制机制。

我最后一次从CloudWatch收到操作警告大约是在一年之前……

将警告信息转化为通知内容。

如果大家已经将一切步骤正确部署到位，那么运行状态检查机制应该会自动清除故障实例并生成新的实例。在收到CloudWatch警告信息时，我们一般不需要采取任何行动，因为所有应对措施都能以自动化方式实现。如果大家得到警告称相关问题需要手动干预，那么请做好事后检查、看看能不能找到一种可以在未来通过自动化方式将其解决的途径。我最后一次从CloudWatch收到操作警告大约是在一年之前，而且对于任何一位运营人员来说、能够不再被警告消息打扰了清梦都应该算是天大的好消息。

文章内容及图片来自网络，如果侵权，请联系：901070669@qq.com，我们将及时处理；