一款小产品有十个功能，经营者却只有一个人。想让每处都同样稳定，听起来负责，现实里可能意味着关键地方反而没得到足够照顾。
这就是“可靠性预算”想讨论的事：有限的钱、时间和维护精力，究竟先保护哪段工作。它并不只是一笔服务器费用，还包括发现问题、恢复服务和检查结果所需的投入。
设想一个活动工具，平时帮主办方生成宣传文案，活动当天还负责签到。文案晚几分钟，可以先用已有版本；签到名单突然打不开，入口可能马上排起长队。两项功能写在同一张菜单里，失败后果却差得很远。此时，能离线查阅的签到名单，可能比文案再快一点更有价值。
工程领域还有一个相关但不同的词，叫“错误预算”。它根据服务目标，规定能够容许多少未达标情况，用来协调功能开发和稳定性工作。Google 公布的政策示例中，预算超出后，会暂停大部分变更，把注意力转向可靠性。资料：Google
这里的启发，是维护不能永远排在“有空再做”。如果新功能每次都有明确需求，稳定性工作却只靠临时想起，时间自然会不断流向前者。提前说明什么情况要先修稳定性，能让压力之下的取舍少一些随意。
“没有人投诉”也不是可靠的全部证据。客户可能正在手工补单，员工可能每天重新核对一次文件。页面没停，工作却靠额外的人力才勉强完成。那些藏在系统外面的补救，仍然是产品的真实成本。
可靠性的投入还要看有没有实际效果。文件备份到了另一个地方，只说明复制过；出问题时能完整恢复，才说明这份准备能派上用场。应急入口藏得太深，或者只有开发者本人会操作，到了忙乱的时候也可能用不上。
我觉得，对小团队而言，可靠性是一种对客户处境的理解。客户在哪个时刻最不能等，哪种错误最难挽回，决定了优先保护的地方。它不需要把每个角落都修成同样规格，却需要让关键承诺有现实支撑。
资源有限确实意味着取舍，但不能用来轻轻带过数据丢失或重复收费。如果某段关键业务暂时保障不了，缩小服务承诺，比把所有功能都列为“稳定可用”更诚实。