@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. 交给其他人的预算,体现了自己的思考能力,别瞎做。

欢迎留言