前车之鉴：聊聊我在云基础设施中掉过的坑

2021 年 12 月 20 日 InfoQ

作者｜ Mathew Duggan

译者｜核子可乐

策划｜罗燕珊

随着自己在职业道路上不断成长，我总在会议上找到那种奇妙的、颇有点超现实意味的“既视感”。同事们偶尔提到的小状况，不禁让我想起之前曾经就同一个问题开过的会。我也还记得，自己当初的某个糟糕选定让接下来的几个月变得如同噩梦。于是我条件反射般地蹦起来，大呼“千万别如何如何！”同事们吓了一跳，但他们不知道这种反应的背后是种深深的恐惧。

所以我想用这篇文章聊聊自己犯过的最大错误，希望能给各位后来者一点指引。其实我知道，无论看不看本文，该犯的错都会犯、该掉的坑都要掉。但无论是给您做个提醒、还是给自己做个回顾，我都希望能用一篇文章整理自己那些曾经深以为然、甚至投入不少精力的灾难性决定。

1 别贸然把应用程序从数据中心迁移到云端

各位云支持者先别急着喷。我个人也是云服务的忠实粉丝，但咱们应该承认，运行在物理数据中心内的应用程序很少能无缝迁移至云端。我先后参与过三次尝试，内容都是把专为特定数据中心编写的应用程序大规模迁移至云端；而每一次都会冒出预想不到的状况，把原本美好的迁移期望击个粉碎。

当初遇到第一个无法解决的云迁移问题时，我的心情就如图所示

开发人员在编写和测试应用程序的同时，已经对目标环境的运作方式做出了假设或者说预期。服务器该如何工作、我的应用程序能获得怎样的性能、网络可靠性如何、传输延迟大概处在怎样的水平等等。任何一位拥有丰富工作经历的朋友，都会在接触项目的一刹那就整理出大致的判断；但如果想把应用程序打包起来、特别是比较陈旧的应用程序，再转移到其他运行环境时，总会出现种种奇怪的现象。我们开始遭遇前所未有的错误，还得忍受一个个为了支持迁移而不得不做的架构决策。

很快，大家就会发现迁移的预期价值被消耗殆尽，而某些糟糕的尝试（例如通过直连服务将本地数据中心与 AWS 无缝桥接起来）还会引发意外后果。总之，我们的决策清单开始快速堆积、增长，也给云服务商带来一个又一个极端案例。在此期间，我们还会找到很多根本不可能迁移的东西，于是被迫卡在两个环境之间——需要继续维护的数据中心，外加新的云账户。当初的意气风发已经不在，如今心里只剩下后悔。

经验分享

把应用程序移植到云端。请务必为开发人员提供一个与数据中心完全隔离的环境，引导他们将应用程序移植到云端，之后再给应用程序安排 4 到 8 小时的停机时间。在此期间，我们可以分步进行持久层切换，之后再更改 DNS 条目以指向新的云端版本。这是必要之恶，任何想要逃避这段停机时间的尝试都会带来一个又一个更错误的决定。总之，直面成本、大步向前。

或者更直接点，在应用程序开发之初就充分考虑到云环境的特性。

2 别总想自主编写加密系统

不知道是太倒霉了还是怎么样，我总会遇上自主编写的系统。很多组织都特别喜欢原创加密系统，有时候是把环境变量注入系统、有时候是调用基于 RSA 密钥的解密 API。好吧，我承认自己也曾经是那种自以为是的家伙，总以为这事“不会特别困难”。

有一次，我肯定是疯了心了，突发奇想要在自己负责的 PostgREST 应用中管理自有 secrets。所以我编写了程序，能够根据各种标准生成 JWT 并将其返回至应用程序。如此一来，应用就能安全无忧地访问 secrets 了……至少理论上能。

我还要为 PostgREST 辩护几句，它很好地完成了预期任务。但问题是，后来出现的 secrets 管理情况比初步预计要复杂得多。我们先是碰到了缓存问题，也就是在面对每小时上百万次的服务访问压力之下，怎么继续保留一部分服务器作为事实来源。虽然后来我们调整 Nginx 配置解决了这个问题，但我其实应该提前就想到。

之后的问题再次狠狠打了我的脸。新版本推送倒不成问题，但 secrets 却往往无法在客户端上实现版本化。我对应用程序进行了身份验证，也能查看正确的 secrets；但在轮替期间会有两条 secrets 同时处于正确状态，这一点我是真的没想到。跟之前的问题一样，这事不难修复，但随着时间推移我在服务中遇到了越来越多的极端状况，也最终承认自己犯了个大错误。

回到现实，secrets 管理是那种典型的高风险、低回报服务。这类功能既不会直接提升客户体验、也不会得到管理层的认同，它只会用没完没了的调试不断浪费我的时间，同时逼着我边调边学新知识。就为了这样一项小小的原创功能，我把从多区域可用性（跨区域同步问题）到服务强化等方向试了个遍。

经验分享

直接用 AWS Secrets Manager 或者 Vault。我个人更喜欢 Secrets Manager，但大家可以随意选择。总之，选什么都比自己写要好，因为原创方案往往没考虑到那些极端状况、而且跟现成服务比也没啥优势。我要用自己的体会告诉大家，一个小小的原创应用很可能成为系统宕机、拉升运营成本的罪魁祸首。

3 不要自主运行 Kubernetes 集群

我知道，很多朋友都觉得自己完全有能力运行 Kubernetes 集群。什么 etcd 啦、设置各种证书啦，分分钟搞定。没错，但面对“该不该自主运行 K8s 集群”这个问题时，我们不妨走一遍以下决策树：

你所在的是全球财富百强企业吗？如果不是，请放弃。因为虽然可以，但真的没有必要。

直接用现成的 K8s 集群，能让我们享受到服务商添加的一系列强大功能。AWS EKS 就包含不少令人惊艳的选项，包括在 kubeconfig 文件中支持 AWS SSO、以及使用 IAM 角色让 ServiceAccounts for pod 访问 AWS 资源等等。最重要的是，整个控制平面的年运行成本还不到 1000 美元。如果这还不能说服你那颗骚动的心，那咱们再聊点实在的。

云服务的一大优势，就是让别人帮你做 beta 测试。

我不明白这么简单的道理为什么很多人老是不懂。没错，你当然可以顺畅运行自己的 K8s 集群，但图什么呢？AWS 那边有成千上万的 beta 测试员帮我们保障 EKS 的迭代升级。更重要的是，AWS 的工程师水平很高、稳定可靠；而勉强在 AWS 中运行自有集群的唯一回报，似乎只是让自己拥有可以随时“更换云服务商”的错觉。是的，只是种错觉，后面我会再具体讨论。

经验分享

把一切交给云服务商。交给他们，问题就归他们管了。让开发人员们过得舒服点、轻松点，不好吗？

4 别针对多家云服务商做设计

其实我一直就是这么想的，但有位经验老道的经理说服了我，强调企业应该有能力随时更换云服务商。这话听起来也有道理，所以我们就踏上了这条“不归路”。现在的我，会称这种思路为“过早优化症候群”。

按照多云设计思路，我开始审查“多云兼容性”并通过自主维护的 SDK 替代 AWS 提供的预制 SDK。而这一切都是为了营造某种虚假的安全感，即如果 AWS 这家大受欢迎的云巨头哪天突然不行了，我们就能比较顺畅地完成大规模负载转移并值回投入的成本。我猜大家这么干是想证明自己有某种厉害的前瞻性，或者是野心太大把脑回路给带偏了。

而这也是我们做过的最愚蠢的尝试，大大提高了向客户交付产品的难度。既然选择了 AWS，请拜托各位别假装自己的应用程序还需要面向其他云环境部署。如果 AWS 过几天消失了，那确实得迁移应用程序；但有几个人敢说自己的公司能开得比 AWS 久？既然没这个信心，干嘛要在跟当前云无关的翻译层上浪费那么多时间、投入那么多金钱？

我们最终得到的只是一堆始终跟不上节奏的库，开发人员也被搞得身心俱疲、没工夫研究 AWS 发布的一系列最新功能。这些自定义库发挥不了 AWS 的云功能优势，我们自己也从来没试过更换云服务商或者搞什么双云部署。因为从经济层面讲，这么干没有任何意义。开发团队空耗许久，最终什么都没有得到。

经验分享

如果各位身边还有人鼓吹“必须保证不必依赖于单一云服务商”，拜托替我骂醒这家伙。与数据中心类似，在 AWS 当中设计、测试并成功运行多年的应用程序往往都带有与环境相匹配的某些预期和模式。针对其他不可知设计做出的优化，都必然在牺牲当前云服务商功能价值的同时、给开发团队带来本不必要的额外工作压力。

别当那种站关说话不腰疼的人，跟所有人对着干往往当不成力挽狂澜的英雄、反而让我们沦为众目睽睽下的小丑。另外，就算大家基本认定转向其他云服务商具有可靠的经济意义，也请至少留出 3 个月时间开展应用程序测试和移植，之后再考虑到底要不要具体实施。

云服务商当然会产生依赖性，就像编程语言一样。我们不可能随随便便就决定更换，甚至全面移植也不太现实。所以大家不妨把迁移议案当成一种演习偶尔试试，同时把大部分精力集中在产品与当前环境的充分融合上。

5 别没完没了地增加警报

相信大家在工作中都见过这类情境。办公室里摆着一台显示器，专门展示图表或者 CloudWatch 警报之类。某些警报会隔段时间就定期被触发，但同事们已经习以为常，直接当作没看见。继续追问，他们的回答也只是“我们只想看看到底会报多少次警，没突然增多就行。”

这种不在意的态度终究会体现在真正紧急的警报当中，导致我们没能把握时机解决关键问题。那能不能减少警报数量呢？不行，服务管理团队觉得还是应该提醒一下，哪怕没人看。所以随着时间推移，似乎没人能说清到底哪些警报重要、哪些不重要；只有新人报道时会再提起这事，然后同事们把前面的话重新解释一遍。最终，系统一定会发生大崩溃，因为某条“不要紧”的警报里藏着非常要紧的信息，但却根本没人关注。

我就这么干过，而且捏造出了“设置警报肯定有设置的道理”来搪塞新员工。我错了，我当初应该支持“干翻一切、推倒重来”的观点。希望多年前让我痛心疾首的决定，不要在当下成为各位读者朋友的现实隐患。

经验分享

只要警报响起，就一定代表着系统无法自行恢复、必须马上介入的状况。警报应该具有严肃性，我们也不该把故障内置到应用程序的设计之内。比如“有时候我们的服务需要重新启动，通过 SSH 连接并重启就行了”，这属于常态、不该被设置成警报。如果说重启失败，那又是另一个问题，咱们不要把二者搞混淆了。

别让垃圾警报慢慢污染我们的生活。如果平台上的所有警报几乎都没有实际意义，请果断推倒重来。如果系统每天要发出 600 封提醒邮件，那跟一封都不发没有任何区别。过量的警报只会让我们神经麻木，代表着我们当前根本得不到警报系统的保护。人类的大脑结构就是这样，我们不能指望一个人在持续收到垃圾警报之后，还能敏锐地从中找到真正重要的那条。

6 不要用 Python 编写内部 CLI 工具

这事我只简单谈两句。

没人知道怎么正确安装和打包 Python 应用程序。如果你决定用 Python 编写内部工具，那面前只有两条路：要么保证应用具有完全可移植性，要么请选择 Go 或者 Rust 语言。相信我，否则在安装过程中遇到麻烦的用户很可能提着刀来追杀你。

原文链接：

https://matduggan.com/mistakes/

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！

今日好文推荐