风险意识，决定了是事半功倍，还是事倍功半，甚至决定了...

序：

昨日吃饭，路上遇到了同事L，谈起他以及他所在项目小组工作，L告诉我他的一个真实的、新鲜出炉的故事，虽然L以前也听过我有关于部署实施的培训课，但是他说在工作中真正在吃了亏之后，才能更好地体会到其中的问题。
场景：

故事实际发生在上周四周五。计划的事情如下：

1. 同事L的项目组服务于业主Z，业主Z计划在周四晚上开始停机，对IT基础支持环境的Oracle数据库进行升级，计划从9i升级到10g。IT基础环境的维护工作，做为长期的外包服务，业主Z是交给了第三方服务商J负责进行。
2. 同事L的项目组根据计划，借着此次IT系统升级停机，顺便进行应用系统O的模块S升级。L之前已经和服务商J的同事交流过。
3. 按照商定的计划，周四晚上进行升级，服务商J在周五凌晨2点完成DB升级，之后由我们进行应用系统O的功能性验证和模块S的升级。

真正的结果，实际情况如下：

1. 到了凌晨2点，当同事L询问服务商J是否已经完成升级时，答案是还没有完成。
2. 到了凌晨3点，回答还是没有完成。
3. 到了凌晨4点，回答依然。
4. 直到凌晨6点半，DB终于升级成功。
5. 离8点业主人员开始上班，只剩下1个半小时，测试应用系统O，发现运行不正常，经过同事的排查，最终发现是应用的驱动程序不匹配，但是此时已经到了9点半。
6. 周五早上大家都很累了，没有进行模块S升级，本身没有正常运行，周五中午团队就回家休息了，直到周六大家休息回来后才接着再干，最终完成了任务。

分析：

我相信很多同事对这个案例的分析也不会特别复杂。不外乎就象我的评论如下：

1. 象这种IT基础架构的调整，从以往实践工作来看，是属于风险是比较高的工作。一般都会安排在周六、日进行。想起10年前，当年我还在做学徒的年代，跟者DBA周六、日对Sybase数据库进行升级，数据量的大小现在看来当然不算什么了不起，不就是几个G，但是在当年一台机器才只有16M内存来看，那可是一个大型的数据库。
2. 我不会在制定计划的时候，将自己的任务可行性建立在他人一个风险度很高的任务上，而不存怀疑，这是非常危险的。在此场景下，我不会安排我的任务计划在凌晨2点开始。
3. 退一万步，即便是我也象L一样，将任务安排在凌晨2点开始，那我在计划的时候一定也会定义好失败条件（部署终止条件）。而不会让事情发展为2点，delay到6点半。根据以往的部署培训，定义好系统部署的终止条件是非常有必要的。
4. 退一万步，即便是我也象L一样，将任务安排在凌晨2点开始，我一定不会让同事都在现场一直苦等，我会让同事先回家休息，凌晨才根据情况到现场集中。
5. 根据以往部署经验，特别是越大、越重要的系统，越是需要进行演练。当然同事会告诉我，数据库数据很大的，好几个T。呵呵，越是VLDB，你都不演练一下，哪能准确进行耗时估计，不要连周六、日都无法升级完毕？！我希望同事养成习惯，不要管系统的规模的大小，进行事前演练，会让你成为老手。

L君经历了这样的事情后，当然对以上原则的认识是加深了很多。他告诉我，哎哟，很多工作还是太相信人了。我告诉他，风险意识不是要告诉你不相信人、不能信任人，如果是这样是和和谐社会的建设相抵触的！也没有一本书这么说。风险意识是要让我们认清自己/团队的处境，对全局有基本的把握，风险意识的出发点是怀疑自己、不是怀疑别人，才能看到自己没有盲点，存在怀疑是为了保证团队的利益，希望他能够从职业的角度去思考。

体会：

但愿L以后能不再犯同样的错误决定，但是人真的能够从自己以往的错误中吸取教训吗？很多事情就是说容易，做起来难，俺岳父告诫我：“说易行难”是这个道理。金融风暴之前，身边有的人，把公司关了，把房子押了，拿了钱投到股市；也有人，拿着股票去抵押，再套现接着投入股市。现在事后看来，真的很疯狂。但是理智告诉我，这绝对不是人类第一次，也不是最后一次。