除了你自己，没有人会在乎原因，别人只会关注结果 - 所以，你永远都需要一个 Plan B

周末带小孩去儿童医院看病，恰逢北京市社保服务出现问题，从医院的任何一台终端输入信息从按下 Enter 一刻起，到服务器返回响应，至少要 10 分钟，于是长长的队伍中不耐烦的气氛开始节节上升。一般人不懂什么超时、什么系统宕机；只知道排队不动，于是开始骂医院、骂社保中心，稍微懂点的则开始骂写系统的程序员。。。


在这背后的关键，其实都是没有一个合理的 Plan B.

先说说社保中心的系统。作为这样一个关联北京市所有医院的核心系统，其可靠性是至关重要的；不用说 BAT，任何一家稍微像样点的互联网公司你都很难想象它能出这样的在线服务问题。而作为在线系统的设计者，服务的降级、扩容、防攻击，数据的容灾备份都是必须要考虑的。比如像 9/27 上午的这个情况，最差的 plan B 也应该是切到一个备份的在线系统上（甚至缓存住都可以），然后主系统重启，逐步恢复服务。

再说说医院。医院肯定也知道，不能完全避免连接社保中心服务出现问题的可能性；那么，当社保中心真的出问题了的时候，是不是真的只能两手一摊呢？连不上社保中心，难道就不能给病人看病了吗？是不是可以先缓存用户信息，延迟实时结算，先给病人看上病呢？ 这样总是比不作为地干等着系统恢复要强一些：系统应该是面向用户提供便捷服务的工具，当它出问题的时候不应该成为制肘工作正常进行的障碍，这时候就需要一个合理的 Plan B 登场救火了。

最后说说我们最无辜的患者们。先不说目前紧张的医患关系，病人来医院看病，本身就处于弱势的一方。当出现意外情况的时候，也需要尝试是否有其他的积极的解决问题的方式，而不是一味地焦急与愤怒。（比如当时看系统的症状是连接超时的问题的时候，可以建议挂号的医生重启一下终端，这样我这个号挂出来节约了，呃，5分钟…，虽然治标不治本，但至少是个尝试）


其实我们工作生活中的 Plan B 无处不在：你设计了一个 NB 的系统，立项的时候总要考虑一个不那么 NB 的至少能 work 的 “土方案” 以保证你能在 deadline 之前至少不会两手空空死得很惨；你出去旅行，总要考虑留一下意外发生时更改计划以继续成行，至少不会流浪街头。

总之，你总是需要一个合理的 Plan B.