backup是个相对论

工作互备，是很多团队领导者都关注的事情。显然，当一项任务由两个（甚至两个以上的人）来完成，当任务交付使用后出现问题时，不会因为其中某一个成员的缺席而导致问题一时处理不了。

如果某个任务只是由一个人来担当。那么，无论大小，当此人不在时，尤其是这个任务比较重大，比如说是个项目时，后续问题的处理将是悲剧性的。你别指望文档说明，也别太指望工作交接，多数程序员是懒得写甚至不屑于写项目文档的，多数程序员的文档编写能力也一般般，再者，更现实的情况是，需求总是变，文档更新不上。到最后只能是死抠一行行的代码逻辑了，这就会耗费相对较长的时间。

这里要说的是工作的互备。 其实互备也是相对的。每一个任务都有分工，最终细化到每个人头上。结对编程？一般的团队也不具备结对编程的条件，BAT这样的大公司除外。

上周四是我们上线日，team内一个哥们的程序要上线，是修复的一个程序bug。通常上线是要等到下班后才可以。下班后产品过来，恰好这哥们下楼吃晚饭去了。产品就给他打电话，然后就让运维发布生产了。要知道，我们的项目是个高频业务，线上持续有大量交易的。

当然，这次发布我是当晚事后才知道的，是产品让我监控系统有没有问题，我才得知刚上的线。 我大概查了一下生产日志，并未发现问题。万幸！否则，虽然我们是一个项目组的，如果发布后出现问题影响了交易，而我们又不能立即定位到原因，也许就会被用户投诉，再做一番折腾。 所以，对于这种高频系统的上线，当事人还是在场比较好一些。