波仔
📡 第七章 网络硬件设备的选购要点
📄 一句话概括

「多备几台」是最常见的做法，也是最没依据的做法。备件数可以用泊松分布算。 100 台设备、年故障率 3%、周转 30 天，备 3 台就够——而「备 10 台」是浪费。

📝 本节和前面几节的关系

07.08 与 07.09 讲的都是「买之前」的账，07.10 讲「买之后」的账。 而维护的第一笔支出就是备件：备多了浪费，备少了停机，而这个「几台」是可以算的。

一、备件是个概率问题

故障是随机事件，所以「要备几台」其实是在问「缺件的概率降到多少我能接受」。 而这正好是泊松分布回答的问题。

100 台设备、年故障率 3%、备件周转 30 天：在 30 天的窗口里，期望要换 0.25 台。

备件数 缺件概率 五年内缺一次

0 台 21.85% 100.0% 1 台 2.58% 79.2% 2 台 0.21% 11.7% 3 台 0.01% 0.8%

备 1 台，单次缺件 2.6%，五年内至少缺一次 79%。 备 2 台降到 11.7%，备 3 台基本不用担心。

所以「100 台备 3 台」是有依据的，「备 10 台」是浪费。 而「一台都不备」意味着五年内一定会遇到一次缺件。

二、周转周期才是杠杆

这个模型里最敏感的变量不是「故障率」，是「周转周期」：

周转天数 期望需求 台 备 2 台够不够

7 天 0.06 够 15 天 0.12 够 30 天 0.25 够 60 天 0.49 不够 90 天 0.74 不够

把周转从 30 天压到 7 天，备件需求直接降到四分之一。 所以「本地有备件库」比「多备几台」更划算： 备件库是共享的，成本摊到多个项目上；而多备的机器是独占的，放着也会过保。

这也解释了「为什么原厂支持贵」：它卖的不是零件，是「把周转压到 4 小时」的能力。 而 4 小时与 30 天的差别，按上表算就是「要不要备件」的差别。

三、其他三件维护的事

一、定期巡检： 光模块的收发光功率、风扇转速、温度、电源状态——这四项都是「有告警之前先劣化」的指标。

二、配置备份：换机时最痛的不是硬件坏，而是「配置找不到」。 而备份这件事的投入产出比极高：一次脚本，长期有效。

三、固件管理：不升级会留漏洞，乱升级会出新问题。 所以固件策略应该是「跟随安全公告，不跟随版本号」。

这三件事都不在采购合同里，但它们决定了「买回来的设备能不能安稳跑五年」。 而它们的成本，比备件与支持费都低一个量级。

四、动手 Demo：备件要备几台，可以算出来

这段用泊松分布算不同备件数下的缺件概率，再把周转周期从 7 天扫到 90 天，看它是怎么影响备件需求的。

n, rate, wd = 100, 0.03, 30
lam = n * rate * wd / 365.0
def pois(k, lm):
    return math.exp(-lm) * lm ** k / math.factorial(k)
for k in range(0, 5):
    cum = sum(pois(i, lam) for i in range(k + 1))
    short = 1 - cum
    at_least_once = 1 - (1 - short) ** 60

实跑输出：

--------------------------------------------------------------------
备件要备几台，可以算出来
--------------------------------------------------------------------
**「多备几台」是最常见的做法，也是最没依据的做法。**
**备件数可以用泊松分布算：缺件概率降到多少，就备几台。**

**场景：100 台设备，年故障率 3%，备件周转周期 30 天。**

  年故障台数 ＝ 100 × 3% ＝ 3 台。
  在 30 天的周转窗口里，期望要换 0.25 台。

  备件数     缺件概率     五年内缺一次 概率
  ---------------------------------------------
  0 台       21.85%       100.0%
  1 台       2.58%        79.2%
  2 台       0.21%        11.7%
  3 台       0.01%        0.8%
  4 台       0.00%        0.0%

**备 1 台，单次缺件概率 2.6%，五年内至少缺一次 79%。**
  备 2 台降到 11.7%，备 3 台基本不用担心。
  **所以「100 台备 3 台」是有依据的，「备 10 台」是浪费。**

**这个模型里最有用的一个变量是「周转周期」**：

  周转天数     期望需求 台     备 2 台够不够
  ----------------------------------------------
  7 天         0.06            够
  15 天        0.12            够
  30 天        0.25            够
  60 天        0.49            不够
  90 天        0.74            不够

**把周转从 30 天压到 7 天，备件需求直接降到四分之一。**
**所以「本地有备件库」比「多备几台」更划算**——
  备件库是共享的，成本摊到多个项目上。
  多备的机器是独占的，而且放着也会过保。

**这条 Demo 的用法**：把自己的设备数、故障率、响应时间代进去，
**算出来的数直接写进采购合同的「备件条款」。**

lam 那个式子是全段的核心：期望需求 ＝ 设备数 × 年故障率 × 周转天数 ÷ 365。 注意分母是 365——它把「年」换算成「周转窗口」。

「五年内缺一次」用「1 减去「一次都不缺」的概率的 60 次方」算： 60 是五年里的周转窗口数（12 个每月 × 5 年）。 这个式子的意思是「60 次里至少失败一次的概率」。

这条 Demo 的用法： 把自己的设备数、故障率、响应时间代进去，算出来的数直接写进采购合同的「备件条款」。 「备件 3 台、4 小时到场」这种条款，比「提供完善的售后支持」有用得多。

30 秒实验

  1. 数一下你单位有多少台设备。
  2. 问一下年故障率大概是多少（一年坏几台）。
  3. 算一下按 30 天周转，需要备几台。

常见误区

  1. 凭感觉定备件数。它可以用泊松分布算，「备几台」有明确依据。
  2. 只盯故障率。周转周期才是杠杆，压到 7 天能省四分之三备件。
  3. 以为买了设备就没事了。巡检、配置备份、固件管理都不在合同里。
自测三问（点开对答案） 1. 备件数为什么可以用泊松分布算？ —— 因为故障是随机事件，「缺件概率」就是「需求超过备件数的概率」。 2. 100 台设备、年故障 3%、周转 30 天，备几台合适？ —— 备 3 台，五年内缺件概率 0.8%；备 2 台是 11.7%。 3. 为什么「本地备件库」比「多备几台」划算？ —— 备件库是共享的，成本摊到多个项目；多备的机器独占且会过保。

下一节：最后一项——保修到底保了什么。

相关笔记