目录
每年年初和年中，世界上就会有很多人开始做预算。
你从预算就可以看出一个人的思考力。
过去（现在好像不太让这么问了）你去一些像 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
之前我介绍过，这个跟队列有关的数学理论。
\[L = \lambda * W\]其中，\(L\) 是队列中的平均物件数，\(\lambda\) 是新物件到达队列的平均速度，\(W\) 是物件在队列中的平均等待数。
它可以用在各种地方，因为我们工作中的很多东西都可以被建模成队列。
比如分析你的研发团队效率的瓶颈在什么地方，是可以用上它的：你会发现 WIP 不是越高越好，也不是越低越好。
再比如你有一个服务平均需要 200 毫秒处理一个请求，如果它每秒需要处 1000 万个请求(rps)，你要准备多少机器：
\[requests = 10Mrps * 0.2s = 2000K\]如果每个请求占用 CPU 比较可观，那么就意味着需要有 2000K 线程处理请求，于是 8 核的机器大概需要 250K：嗯，这是一个例子，如果你做出来用户需求是这个体量的服务，恭喜你。
幂运算做近似
这个更容易：因为在对数空间，乘法就变成了加法。
比如，假设有 8 万用户以 120 mbps 的速度观看 UHD 视频。而我们租用的 CDN 承诺 1 Gbps 的速度，那么我们需要多少台机器？
我们做一些简化，把 8 万近似为\(10^{5}\)，120M 近似为\(10^{8}\)：
\[\frac{10^{5}*10^8bps}{10^{9}bps} = 10^{(5 + 8 - 9)} = 10^{4} = 10K\]如果你精确的计算：
\[\frac{0.08M*120Mbps}{1000 Mbps} = 9.6K\]10K 和 9.6K 对于预算阶段来说可以说没有什么区别，但是 (5 + 8 - 9) 可比下面那个好算多了。
其他
前面提到的这几个近似法则不是全部，还有一些比如 72 法则对你估算随着业务发展资源怎么准备也很有用。
对于「费米问题」更深的讨论，则可以看这里。
但我主要想说的是：
- 熟悉基础设施、中间件的那些数字（主要是数量级），是做预算和做架构的基本功。
- 学会一些简单的数学法则，可以让快速做估算变得很轻松。
- 交给其他人的预算，体现了自己的思考能力，别瞎做。