对中台的一些想法

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

一开始有人开始提出“中台”这个概念的时候,我对此是嗤之以鼻的,认为又一个的炒作的概念。对于中台,我的认识是,将一个垂直领域的东西做成一个 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. 举个例子,从上手成本上说,一个库你可以看一下函数声明就上手开始用了,对于一个框架,你要知道它是怎么运行的,它是怎么调用你的代码的。

对中台的一些想法”已经有一条评论

  1. 同感,想到了python 最流行的requests库,它的崛起很大程度是因为设计简单,“简单”就是最好的竞争力。没有人喜欢去区分 urllib urllib2一大堆东西,更多的时候requests.get 是真正好的设计。

Leave a comment

电子邮件地址不会被公开。 必填项已用*标注