服务挂了不可怕，恢复太慢才可怕：可靠性也是产品完成度

早期团队最容易把「页面能打开、主流程能走通」当成产品做完了。真正的考试往往在发布之后：支付回调漏了一条、第三方接口突然超时、一次小改动把登录弄坏。用户不关心问题出在云服务、接口还是你自己的代码，他只看到一件事——关键时刻用不了。

所以，好产品并不等于永远不出错。那种承诺既不现实，也没必要。真正的完成度，是出错后能多快发现、多快恢复，以及能不能把损失限制在最小范围。

先把「99%」翻译成人话

99% 可用率听起来已经很高，但按 30 天计算，仍然等于 7 小时 12 分钟不可用；99.9% 还有 43 分 12 秒；做到 99.99%，才缩到 4 分 19 秒左右。三个数字只差小数点后一位，用户感受到的却可能是「一下午都进不去」「偶尔卡住」和「几乎没察觉」。

再算一笔更贴近早期项目的账。假设一个月有 1 万次关键操作，失败率 1% 就是 100 次失败；降到 0.1% 后只剩 10 次。若每次失败都要客服花 15 分钟解释和补单，前者要消耗 25 小时，后者只要 2.5 小时。可靠性不是看不见的工程洁癖，它会直接变成客服成本、退款、差评和流失。

小团队最常犯的三个错

• 只有用户投诉，没有主动告警。服务已经坏了半小时，团队还在群里讨论是不是个别现象。用户成了免费的监控系统，也成了最先受损的人。
• 会发布，不会回滚。新版本出了问题，只能现场改代码、重新打包。修复动作越多，新的错误越容易混进来。一个能在 5 分钟内切回上一版的方案，常常比多写十个功能更值钱。
• 什么都想保，结果一起挂。非关键模块出错时，登录、下单、查询也被拖死。成熟的产品会降级：推荐暂时不显示没关系，核心操作必须继续走。

早期项目不需要豪华配置，需要三条底线

• 给核心路径单独设指标。不要只看「网站是否在线」，要看注册成功率、关键操作成功率、接口响应时间。先定一个能守住的目标，例如关键操作成功率 99.9%，再用数据判断是否达标。
• 每次发布都准备撤退路线。保留上一版、数据库变更可兼容、开关能关闭新功能。发布前先问一句：「如果五分钟后出错，我们怎么退回去？」答不上来，就还没准备好。
• 故障时说人话。告诉用户哪里受影响、正在做什么、何时再更新。沉默会把一次技术问题变成信任问题；清楚的状态说明，反而能让用户看见团队是否靠谱。

51kaifa.app 做早期项目时，会把监控、日志、备份和回滚写进交付清单，而不是等故障发生后再补。预算有限时可以少做几个边缘功能，但不能让核心路径处于「坏了才知道」的状态。好产品的底线，不是看起来完整，而是关键时刻靠得住。