@Lenciel

如何做预估

目录

每年年初和年中，世界上就会有很多人开始做预算。

你从预算就可以看出一个人的思考力。

过去（现在好像不太让这么问了）你去一些像 Google 这样的公司面试，会被问一些看起来很无厘头的问题，比如「一辆校车内可以容纳多少个高尔夫球? 」

这类问题其实有个门类叫「费米问题」：

In physics or engineering education, a Fermi problem, Fermi quiz, Fermi question, Fermi estimate, or order estimation is an estimation problem designed to teach dimensional analysis, approximation, and such a problem is usually a back-of-the-envelope calculation.

在《编程珠玑》里，它被称为 back-of-the-envelope calculations (BotEC)。

有点拗口。

其实就是说，在信息不完整的情况下，凭借对问题域的深刻理解和洞察，作出一些假设使得问题复杂度大大降低，从而可以在信封背面那么巴掌大的纸上写写算算，就得出和正确答案同一数量级内的近似解。

费米自己是这方面的超级高手，在上课的时候经常问学生「地球的大气有多重」或者「芝加哥有多少钢琴调音师」，但他在这方面最有名的一个轶事是：

「 1945 年 7 月，世界上第一颗原子弹在美国新墨西哥州沙漠爆炸。40 秒钟后，爆炸引起的滚滚气浪冲到科学家们进行观测的大本营里。第一个起身的是物理学家费米。在原子弹爆炸之前，费米从笔记本里扯下一张纸，将其撕成碎片。当他感受到气浪所带来的第一下波动时，马上将碎纸片举过头顶抛撒出去。它们在空中飘动，然后纷纷扬扬地落到地面，距离费米大约有 2.3 米。经过初步估算，费米宣布这颗原子弹的爆炸能量为 1 万吨 TNT 当量。后来，相关专家经过几个星期的分析和计算，得到的数值和费米宣称的非常接近。」

回到预算。

产研等部门预算的难度在于，要在一个季度或者一年的开始就对机器、带宽、人力等资源根据业务的发展和系统的构建，进行预估。

你怎么在一张纸上推算出这些数值？

熟悉你的问题域

其实就是熟悉那些数字。

Jeff Dean 说，数字很重要。

好的架构师应该对系统的数字特别敏感。

好的技术管理者不但应该熟悉架构师脑子里面的这些数字，还要熟悉一些管理上的数字。

多少人适合成为一个组？每个人最好有多少个直线汇报对象？各种类型的业务研发团队测试、开发、运维的比例是多少比较合适？

一点点数学

Little’s Law

之前我介绍过，这个跟队列有关的数学理论。

其中， 是队列中的平均物件数， 是新物件到达队列的平均速度， 是物件在队列中的平均等待数。

它可以用在各种地方，因为我们工作中的很多东西都可以被建模成队列。

比如分析你的研发团队效率的瓶颈在什么地方，是可以用上它的：你会发现 WIP 不是越高越好，也不是越低越好。

再比如你有一个服务平均需要 200 毫秒处理一个请求，如果它每秒需要处 1000 万个请求(rps)，你要准备多少机器：

如果每个请求占用 CPU 比较可观，那么就意味着需要有 2000K 线程处理请求，于是 8 核的机器大概需要 250K：嗯，这是一个例子，如果你做出来用户需求是这个体量的服务，恭喜你。

幂运算做近似

这个更容易：因为在对数空间，乘法就变成了加法。

比如，假设有 8 万用户以 120 mbps 的速度观看 UHD 视频。而我们租用的 CDN 承诺 1 Gbps 的速度，那么我们需要多少台机器？

我们做一些简化，把 8 万近似为，120M 近似为：

如果你精确的计算：

10K 和 9.6K 对于预算阶段来说可以说没有什么区别，但是 (5 + 8 - 9) 可比下面那个好算多了。

其他

前面提到的这几个近似法则不是全部，还有一些比如 72 法则对你估算随着业务发展资源怎么准备也很有用。

对于「费米问题」更深的讨论，则可以看这里。

但我主要想说的是：

  1. 熟悉基础设施、中间件的那些数字（主要是数量级），是做预算和做架构的基本功。
  2. 学会一些简单的数学法则，可以让快速做估算变得很轻松。
  3. 交给其他人的预算，体现了自己的思考能力，别瞎做。

关于中台的一次讨论

人生的第一次直播献给了右军和 TGO。

1、几位嘉宾，你们怎么看中台建设，有人把它当成了灵药，也有人说不灵。先请各位聊聊，中台究竟要解决哪些问题？

对我来说，在大多数时候，中台主要解决没有中台造成的焦虑问题。

就好像当年别人家里有了「家庭影院」，于是家家户户不整几个音箱功放就觉得自己的日子过得很不是滋味一样。

因此，可能有 95% 的公司，组织和业务都还没有准备好，因此建设中台不解决任何问题：搞明白中台是什么并且遏制住建设中台的冲动才解决问题。

这也是为什么 TGO 组织的这种讨论挺好的。

剩下那 5%，在公司的组织和业务都成熟的情况下，中台主要就是解决一个复用的问题：笼统来说，软件最大的优势就是低成本复用所以 scale 的时候边际成本很低。

只不过，过去我们解决复用主要是通过平台化，或者具体来说，通过暴露 API 或者暴露结构化、单元化的服务来复用。这种复用是没有业务属性的，业务方需要自己非常熟悉各种平台的各种 API，自己根据自己的业务逻辑去调用和拼装。其次这样的复用也是没有组织依托的，并不会有一个有运营、有服务的团队来跟业务沟通需求。中台只是通过：

  1. 站在业务角度对可复用的领域模型的处理进行完整的封装
  2. 通过组织的支撑对中台的运营和服务进行闭环的支撑

来更进一步解决了平台化复用遇到的一些问题。

综上，我觉得如果公司一个主线业务都没有跑通，或者事业部事业群之间没有明显可以复用的功能或者没有复用的组织基础，那就先别整中台，先好好学习什么是中台。

2、​从组织的角度讲，如何确定中台项目的KPI并找到主要驱动人?

首先中台我觉得既然它跟平台有很大的不同就是有业务属性，有组织支撑，所以它一定是一个一把手工程：CEO 必须非常支持。

在此基础上，因为中台是解决能力复用的问题。所以横跨多条业务线的角色和组织是比较合适来思考和推进中台建设的。在大部分的组织里面， CTO 干这个可能比较好一些，因为销售、产品、运营一般是闭环到业务里面的比较独立的模块，很难要求某个业务里面的产品来抽象公司的业务都可以复用的中台：大部分情况下他们应该只是中台的用户，能提高质量的需求就已经很好了。但是如果 CTO 没有业务思考和抽象的能力，做起来也是够呛的。

KPI 的话，既然是为了复用，那么核心的就是一些跟效能有关的：使用量、易用性相关的指标。比如接入的数量、调用的次数等等，以及可靠性、是否自助等等。除此之外，接入中台的前台业务方的评价也可以是 KPI 的一部分。甚至，为了倒逼中台组织懂业务和承担业务职责，在早期还可以考虑和前台的技术部门共背一些指标：比如前台技术部门的 SLI、SLO、lead time 相关的，甚至是直接共背业务指标。

3、中台建设遇到过哪些困难，如何解决？

前面说了，中台需要专门的组织支撑，所以首先会遇到组织发展上的困难。

中台组织层面的方法论目前是很不成熟的。无论是按职能的，还是按项目的，还是矩阵的公司，你从现有的组织架构里面拆出中台和前台、后台的团队，然后还要确定这些团队之间的边界和职责，没有明确的方法。所以怎么调整是需要根据每个公司自己的情况做调整的。

组织架构调整的过程肯定会出现矛盾和冲突。特别是因为敏捷流程和产品经理的崛起，现在很多的技术负责人是靠手下面有多少研发，加多上班，拢了多少事情在手里，来保证自己的安全的。

DevOps、微服务，推行过程中都会有类似的挑战。

然后是系统架构上的困难。业务领域的抽象需要对业务的理解也需要技术的深度。有一些基础设施是必须完备的：比如统一的 API 网关，比如端到端的全链路的监控，比如容器化。你的云原生平台怎么做？CNCF 里的哪些自建？哪些用开源的？哪些用付费的？像我们很早就在生产环境全 Docker 化了，再比如 k8s 还不是现在这个地位的时候，我们选择了它而不是 mesos 或者 swarm。你的 PaaS 这层怎么做做什么？你的业务上能够复用的东西是什么？怎么抽象？怎么服务各个业务方？比如数据上，你的数据平台怎么搭建？元数据怎么管？指标体系怎么建？数仓怎么建？提供哪些数据产品（通常 BI、画像这些是最开始的选择）。

4、业务中台和数据中台建设有哪些区别?

这是一个答起来有点困难的问题，因为中台的定义是很模糊的。定义还很模糊的时候，就很难去谈区别。就好像有人问你幸福和快乐有什么区别一样，好像可以聊得很精彩，但其实什么是幸福什么是快乐每个人的定义都不一样，很容易鸡同鸭讲。

按照我对中台的定义，它一定要是针对业务领域的能力复用，它一定要有组织去运营去服务，因此，我心里所有的中台肯定都可以叫业务中台。数据中台可以说是特殊一点的中台。除开业务中台和数据中台，别的中台我觉得都没有叫中台的资格。

比如我看到很多同学在讲技术中台，对于我来说，好像大家讲的就是技术中台一般好像里面就是机器、云、容器等等 IaaS、PaaS 就是基础设施，我不太知道它为什么要被叫成技术中台，因为里面很多东西是没有业务属性的，也不需要运营的。

如果我们对业务中台和数据中台进行一下定义，这个问题可能是可以回答的。

如果你仅仅把业务里面一些相对独立的 domain，比如订单、用户、交易等等叫成业务中台，那么这算是一个相对狭义但确定的定义。

类似的，如果有一个部门负责对数据平台、数据仓库、数据治理等方面进行整合，并通过数据产品给各个业务方自助使用，那可能他们干的就叫「数据中台」。

这样来定义业务中台、数据中台的话，它们的内容就有了明显的区别，那么建设起来也就有了明显的区别。

比如业务上，在解决了基础设施的问题之后，怎么去确定有哪些 domain？如何进行抽象？里面有哪些能力可以被复用？

比如数据上，怎么先通过统一的数据通道、数据平台把数据的采集、清洗、存储统一？在此基础上，怎么通过面向业务支持而不是通过行政命令来实现包括数据质量、数据安全、元数据、生命周期管理在内的数据治理？最终怎么通过数据产品把数据的价值提供给业务方然后得到业务的反哺？

这次直播我最大的感受就是很多人对中台的认知还是很模糊的。不如我就，比较过分地说几点我的结论：

  1. 如果你还在想是不是要做一个中台，最好别做；
  2. 如果你是请外面的咨询公司来做中台，最好别做；
  3. 如果你是做外包的公司，可能你自己会有一个中台（复用嘛，前台改吧改吧就给客户实施了），但是别给用户做中台，随便人家多想要。