修复数据基础设施，我们省下6200个工程小时

我认识的成长期公司CTO，几乎每一位都背着一个基础设施问题，只是他们私下里决定不去看它。系统还能跑，问题就一直藏在视线之外，直到某件事把它拖到明面上来。

在我们这里，那个“某件事”是一家英国大型银行。这个新客户带着五倍于我们日常流量的预期来了。对一个刚起步的创业公司来说，产品市场契合度忽然变得真实起来。也正是在这一刻，原本被视为技术杂活的东西，可能演变成业务风险。

我们是一个联络中心可观测性平台，所以我们的工作就是为一些全球最大的联络中心处理海量实时交互数据。两年前我们只有五名工程师，数据基础设施是我们自己跑的。说实话我们还挺自豪，甚至在路演里都提过。那家银行潜在客户出现时，我们的本能反应是把它带来的规模当成又一件我们愿意、也能够内部搞定的事。但算一算账，结论并非如此，至少在不破坏我们对客户承诺的前提下做不到。

那家银行并没有制造这个风险，风险已经悄悄累积了大半年。我们依赖一套托管Elasticsearch，它变得不稳定，供应商的支持速度也不够快，让我们无法兑现对自己客户的承诺。这些我们全都知道，但那时已经习惯了绕着它干活，就像你无视车里那点异响，指望它自己会好。而银行这笔交易在一瞬间做的，就是拿走了我们继续无视它的能力。

你不再注意到的数据基础设施债

这就是我现在看着其他团队不断踏入的陷阱。系统一直嗡嗡运转，直到它不转了，于是问题永远不会自己挤上路线图。CTO和其他决策者最终拍板，往往是在赌注已经高到“从容”版本的决策不再可得的时候。到那时，总有个客户在盯着上线倒计时，而对于一个错不起的昂贵选择来说，这几乎是最糟糕的决策场景。

就我们自己而言，真把账算一遍，数字并不好看。让银行上线、其他一切维持现状，意味着我们五名工程师里有三名基本要住在基础设施里（只剩两个人去构建客户付费的产品）。我开始看清我们即将变成的样子：一家主要照看自己管道、真正的工作却爬不动的公司。说实话，我不想经营那样的公司。

在被逼之前先动

我们最终在银行上线之前改了架构，那时还有足够的缓冲让我们从容去做。我们从托管Elasticsearch迁到开源OpenSearch，并引入NetApp Instaclustr来运行OpenSearch和支撑我们可观测性平台的Postgres。不久后这层关系又延伸到我们的ClickHouse分析集群，我们的大部分处理实际上都在那里。重要的是，这些都是100%开源技术，能确保可移植性而不被锁定。不过，这次迁移背后的原则和技术本身同样重要。我想让我的工程师脱离凌晨两点的迁移业务和紧急打补丁业务，我想把那些时间原原本本还给产品。

有一个条件比其余的都重要，也是许多这类迁移悄悄死掉的地方。我们面向受监管行业销售（比如那家大银行），不能把数据随便倒进别人的云里、放弃对数据物理存放位置的控制。零回旋余地，所以无论选什么，都必须让我们把数据留在自己的环境里。如果过不了这一关，再“稳定”也救不了我们。

回报最后很容易用数字衡量，我给出我们的数字，因为它确实改变了我对这一切的看法。我们每年拿回了超过6,200个工程小时。那些时间以前消失在后台维护的黑洞里，以及那种吃掉一个冲刺（还有你指望能过的周末）的救火演练里。此后我们处理的交互已超过5亿次，ClickHouse分析层嚼过的洞察达到数万亿条，而我们过去总要提防的性能惊吓基本不再发生。故障切换变得，嗯，无聊了，而我曾为之失眠的升级，变成了一个普通的周二下午。

在交易替你做决定之前先做决定

这不是在主张把数据基础设施全盘外包。很多公司应该自己跑，对某些公司来说这甚至是真正的优势。我的观点更小，而且我觉得更难搪塞过去。谁來跑你的数据层这个问题，应该在它还是一个规划决策的时候就得到回答，而不是在一份已签的合同把它变成火灾之后。

CTO们仍然把这个顺序跑反了，增长逼出了问题。然后，过一阵子、在更不方便的时候，他们才去挑选项，而客户的时钟已经在滴答作响。评估被赶着做，迁移最后比本该的更冒险，这一切偏偏落在你对错误几乎零余量的时候。我们自己也差点那么干，没那样的相当一部分原因是运气。

如果你带着一支小型工程团队，心里对一笔大单会怎样冲击你的技术栈有一种低低的背景式担忧，请认真对待那种担忧。它在告诉你真实的东西。早动，成本是日历上一个你自主掌控的计划项目。但晚动，差不多还是同一个项目，当然，只不过它现在跑在你最大客户的日历上，一旦有闪失，几乎没有任何余量。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）