不要不小心把公司押在 AWS 上
不要不小心把公司押在 AWS 上
原文：https://medium.com/hackernoon/dont-accidentally-bet-your-company-on-aws-a454c4f66f78
让您的客户做好应对云服务中断的准备
2017 年 2 月 27 日星期一:又一位新客户开始使用我们的 Approov 认证服务。推出一个新客户，看着他的移动应用和我们的 AWS 托管服务之间的流量增长，这很有趣。我们新客户的第一天非常顺利。我热爱我的工作。
2017 年 2 月 28 日星期二:现在是凌晨，我正在为 Approov 运营支持待命。顺便说一下，我注意到我访问的一些网站有点慢；图像没有渲染。奇怪。亚马逊网络服务怎么样？S3 云存储正在经历错误率上升？持续小时？我们的 Approov 服务没有警报。嗯，这可能是紧张的一天。我热爱我的工作？
仅识别真正的应用程序
大约 9 个月前，我的公司 CriticalBlue 推出了一款新产品approv，这是一款云服务，可以动态证明你在手机上使用的应用是正版的，没有被篡改。你可以用有效的凭证登录零售商 X，但是如果零售商 X 的那个诱人的 50%折扣的应用程序是一个假的，你就不会得到你所支付的东西。
“移动优先”是产品经理的普遍思维方式，但不出所料，它也是网络罪犯的普遍目标。虚假应用从你的产品网站上吸引用户和收入，充满广告或窃取客户凭证的虚假应用会严重损害你的品牌。我们是底层系统性能优化方面的专家，所以我们很自然地会考虑二进制级认证来剔除虚假应用。
除了虚假应用，其他攻击主要集中在产品 API 的逆向工程上。利用机器人，竞争对手可以从产品后端获取有价值的信息，并利用你的信息将客户和利润转移到他们自己的网站上。或者，竞争对手可能试图用昂贵的应用层 API 调用来淹没您的产品服务器，从而降低您的服务质量，让您的客户感到沮丧。您需要一种方法来积极地过滤掉好的流量和坏的流量。
传统上，你用密钥来保护你的 API，但是任何隐藏在你的应用中的秘密都是黑客的诱人目标，所以我们去寻找一种方法来将这些秘密一起从应用中取出。我们的解决方案是在应用程序本身和外部服务之间划分身份验证。您的秘密现在完全脱离设备管理，这是一个巨大的胜利。客户同意我们的观点，正因为如此，Amazon Web Services 已经成为我们安全解决方案中的一个关键组件。
可用性工程
添加 Approov 服务只需要对您的普通应用程序开发和部署流程进行很少的更改。然而，它确实在我们自己的服务流中引入了云服务依赖。
依赖关系的可怕之处在于，假设你的公司和潜在客户的公司会一直存在，你很容易把赌注押在它们身上。正如一名工程师在我们的公司博客中写道，亚马逊的 S3 服务有 99.9%的正常运行时间保证，也就是说每月不到 44 分钟的停机时间。你最好做好 44 分钟的准备。
而且不要怪 AWS 他们向开发人员提供建议，并就性能和弹性架构提供广泛的指导。一个复杂系统的部分故障会经常发生，但是整个系统的故障必须变得非常罕见。
那么，在 2 月 28 日长达四个小时的 S3 停机时间里，我们是怎么做的呢？值得我们工程团队称赞的是，所有客户身份认证服务都保持正常运行。高可用性是产品设计的一个目标，因此最初的产品部署具有适度过度供应、冗余和弹性服务的特点，不同客户服务之间具有很强的隔离性。
我们确实使用 S3 来存储证明数据，但是我们在证明者本身上缓存关键数据，因此我们能够承受暂时的 S3 故障。在 S3 停机的几个小时里，我们继续为客户做见证。如果客户的每个冗余证明者都失败了，我们将很难重新启动他们的服务，但是我们可以承受 N-1 次失败。如有必要，我们准备将证明请求重定向到直通服务，以保持应用程序流量流动。
如果更多的 AWS 服务失败了怎么办？我们通过另一家云提供商维护冗余服务，并且可以在必要时进行故障转移。
我们继续测试和改进我们的可用性架构设计以及适应各种故障场景的速度。
吸引有经验的顾客
与有经验的客户一起工作可以在管理一个成功的发布方面有很大的不同。他们重视避免服务中断，并倾向于在提出新系统时逐渐给它们施加压力。
在我的新客户通过 S3 故障启动的情况下，该客户已经准备了一个保守的启动计划，包括广泛的生产前测试、用户透明的证明切换，以及监控和分析证明故障和性能变化的能力。
该客户同时提供 iOS 和 Android 应用程序。他们选择最初向不到 2.5 万用户发布单一平台。随着时间的推移，他们以可控的方式增加了两个平台上有资格实时升级到更安全的 Approov 支持应用程序的用户百分比。这是一个平稳的斜坡。
尽早培养这些客户是一个双赢的局面，因为他们通常愿意与经验较少的潜在客户分享他们成功的上市策略。
云服务成功
将产品推向市场需要一个深思熟虑的计划，这个计划在推广过程中不可避免地会发生变化。作为产品经理，您希望尽可能减少外部依赖。每个依赖项必须证明其利润贡献与失败和失去控制的风险是相称的。
使用云服务使我们最终能够为您提供更低的价格，因为我们只需要为您使用的服务收费，并且我们可以灵活扩展以满足需求，而不会产生维护我们自己的数据中心的最坏情况资本化成本。但是这确实引入了对 AWS 的依赖，您应该期待我们带您经历您关心的每一个合理的故障场景，以展示始终如一的高可用性服务。
优秀工程的回报是忠诚和精明的客户。他们帮助我们改进了产品，并带来了更多忠诚和精明的客户。
为失败做准备就是为成功做准备。
2017 年 3 月 22 日星期三:AWS 停机 3 周后，又是一个安静的运营支持日。工程人员对实时系统进行了一些测试，但没有触发操作警报。又是美好的一天。这位新客户在我们这里的月活跃用户已经超过了 1000 万，并且还在持续增长。我确实热爱我的工作。
前进
感谢阅读！如果你能推荐这篇文章(点击❤按钮)，让其他人也能找到，我将不胜感激。
要了解更多关于 API 安全和相关主题的信息，请访问approv . io或在 twitter 上关注@criitblue。
