对中台的一些想法

声明：本文仅代表个人想法，不代表我的雇主的想法，也不代表我的同事的想法。

一开始有人开始提出“中台”这个概念的时候，我对此是嗤之以鼻的，认为又一个的炒作的概念。对于中台，我的认识是，将一个垂直领域的东西做成一个 SaaS 平台，它的价值就是避免一定程度的重复建设。举个例子，比如一家公司的很多个 BU 都有播放客户的广告的业务，那么追踪广告的效果就是每一个 BU 做的事情。这个事情需要做 N 遍，但是如果将广告效果追踪变成一个 SaaS 服务，就不需要大家都去做一遍了，只要接入并使用这个服务就可以。这是我理解的中台，可能和其他人的理解有出入。即使在最初提出“中台”的那帮人里面，估计也有很多不同的理解吧。

总之，后来我的 title 也不知不觉地变成了中台开发工程师。这篇文章就讲讲我们走过的弯路吧。

我们做的中台叫做故障定位中台。出现这个“中台”也有一定的历史原因，我们公司很多 BU 都有做故障定位的 SRE，也就有很多故障定位系统。我们在中台想做的就是把这些故障定位系统给统一接入进来，复用一些能力。

至于具体的实现就不多说了，没有什么魔法，如果让你来实现，估计跟我们现在的样子也不会差太多。主要说一下我们做的不好的地方吧。

简单

对于一个需要其他系统接入的中台来说，我觉得最重要的东西就是简单。在一个垂直的领域做中台，不可避免的要引入一些新的，抽象的概念。但是引入概念越少越好。印象比较深的，红姐以前试图教我设计 DSL 的时候说过，先实现功能，然后看哪些东西是可以去掉的，最后剩下的就是 DSL. 我觉得非常对。只有简单，才能让出错的概率更小，接入的成本才会低，别人才会愿意用你的系统。中台最大的失败就是没有人使用。

先实现功能，然后看哪些东西是可以去掉的，最后剩下的就是 DSL.

——thautwarm

我觉得一个产品在不知道将什么作为自己的竞争力的时候，“简单”就是最好的竞争力。比如 clock.sh ，一个可以托管 cronjob 的平台，创建一个新的任务只需要填写 4 个值，你的 cronjob 就可以跑起来了。

没有保持简洁，就没有用户。没有用户，也就没有后面的故事了。

而我觉得踩过的最大的坑， 就是这里。有同事之前是做交易系统的，我感觉他们设计的东西都非常复杂。以我们的接入接口来说，入参有 20 个参数，返回值需要用户填 20 个参数，就太复杂了。每次新用户接入，我基本上要给他们培训 4 个小时的时间，后续配合调试的成本也巨大。

作为一个平台，至少要做到用户自己看文档就可以进行接入。不然每次接入都需要进行特殊的培训，显然是不具备通用性的。

度量指的是对于接口方需要让他们看到一个运行的状态，知道自己的东西运行了多少次，效果是什么。

度量与统计（管理）

大部分的中台会作为一个服务提供方让别人来接入吧。所以就有对接入能力管理的要求。对于我们的平台来说，这个管理的需求统计这些接入方运行了多少次，失败了多少次，运行的效果如何。

不同的平台对于统计和度量的需求也不是一样的，分情况具体对待吧。我们的情况更有一些棘手，就是很难通过程序来判断运行结果的正确性。这里有一个悖论，就是如果我们如果事先知道一个结果对不对，那么就相当于我们已经知道了“正确的答案”了，后面做的事情也就没有必要了。所以现阶段我们的度量还是基于人工的。

集成功能

中台一个核心的思想就是 1）减少重复劳动，将一些轮子一次性做好，其他人只要用就可以了 2）结合一些已经有的系统，发挥1+1 > 2 的效果。

所以对于一些常用的操作，可以封装成 SDK。这句话说起来很简单，门槛也很低，谁都可以写。但是实际做的好不简单。可惜的是，很多喜欢写 PPT 的人认为“写代码是最简单的事情，是没有技术含量的事情，是谁都可以做的事情”。我见过的大多数的 SDK 都乱七八糟，一通乱写。

要注意一个点是，尽量地少抽象新的概念，如果没有必要，不要增加实体。尽可能地减少框架对用户的束缚。尽量让自己提供的东西成为一种“选择”，而不是一种“约束”。

说到这里，我又佩服 prompt-toolkit 写成了一个库，而不是一个框架。框架是它来调用你写的 API，就增加了很多的限制。而库是你去调用它的 API. 举个例子，从上手成本上说，一个库你可以看一下函数声明就上手开始用了，对于一个框架，你要知道它是怎么运行的，它是怎么调用你的代码的。