人工响应的两分钟极限与发布风险

[[可用性的两大决定因素MTBF与MTTR]]中，降低MTTR这条路很快会撞上一个物理极限：一个正常人类从收到突发报警，到正确分析出问题所在、找到正确解决方案、并正确实施完成，理论极限大概是2分钟——这个标准已经”高到天上去了”，实际情况是一个训练有素的Oncall工程师2分钟内能看清报警、连上VPN、找到dashboard就已经算不错了；即便是已知问题、已有应对方案，敲对命令、完全执行成功也至少需要15-20分钟。这个极限直接推出一个残酷的结论：如果按人工响应的实际速度来算，一个服务想达到4个9，一年只能坏一次，坏两次就超标了——纯靠人力去保障4个9以上的可用性，本质上是在”靠运气”，这也是为什么Google内部只有4个9以上的服务才配备SRE、且SRE必须5分钟内上线处理否则报警自动升级——因为超出3个9之后，考验的已经不是”人反应快不快”，而是业务本身的自愈能力、架构的容灾容错设计、灾备系统的完善程度。回到MTBF这一侧，影响服务MTBF的最大因素，用一句夸张但准确的话说就是”发布，发布，还是发布”（术语上叫Age Mortality Risk）——一般来说只要不去碰一个服务，它一年都不太会坏；更新越频繁，坏的可能性就越大，因为凡是软件都有Bug，修Bug的更新本身也会引入新的Bug，所以发布新版本、上新功能，正是MTBF最大的敌人。这条洞察把”提高MTBF”和”降低MTTR”这两个抽象目标，具体落到了两个可操作的方向上：MTTR的瓶颈在于人力响应速度天生有极限，所以必须靠架构自愈来突破；MTBF的最大威胁来自发布本身，所以必须靠变更管理来控制。