报喜不报忧造就了信息不对称，让我们面对项目风险无法及时做出反应

原以为博文《风险意识，决定了是事半功倍，还是事倍功半，甚至决定了...》中一文提到项目O已经完成升级，上周四从邮件看到了负责基础架构的同事Y邮件，谈及该项目在我们应用系统升级后，出现数据库驱动程序不兼容的情况，导致数据库连接泄漏而缓冲池耗尽的情况，从Y的邮件上看到情况已经处理完毕。

周一下午，我以QA身份参加了抽查了该项目的项目周会，结果很不幸，听到的用户“无可奈何”投诉，说项目O从上周三10月30日开始应用升级后，就不断造成系统死机，而我方处理问题的速度很慢，到周一还没有解决问题，周一上午11点多还再次出现死机情况。

经过细致了解，了解情况如下：

1. 10月29日周三升级后，已经出现问题，但是系统没有进行升级回滚；
2. 10月30日周四项目组进行系统进行部门核心模块的回滚，并且知会了基础架构部的同事Y要求支援，Y并且进行问题排查，认为原因已经找到，并且进行修复，完毕后发送了邮件知会了大家，包括我在内；
3. 10月31日周五上午10点左右，再次出现死机情况，证明30日晚的排查判定可能是错误的，此时Y赶到现场，初步排查后觉得更改数据源的使用方式；
4. 11月1日周六进行使用方式的替换测试和实施工作，由于环境原因，没有进行性能测试，但是从周六使用情况上看，看似正常；
5. 11月2日周日下午，项目组同事再次进行监控，发现系统正常；
6. 11月3日周一上午一早进行监控，发现系统存在工作不正常的情况，此时服务器上的资源非常紧张，中午进行了参数的调整；
7. 11月4日下午就到了我去现场开会了。

周五的情况，项目组有将情况知会部门经理，但是周六、周日以及周一的情况就没有及时知会。我去抽查的会前，信息只是到了周四的情况，所以从这个角度，信息不对称，让我们面对项目风险无法及时做出反应，容易错过协助救援的最佳时机。

会后，除了和项目经理L将工作协调安排外，做的第一件事情就是知会相关干系人，并且马上通知Y，要求他马上到现场解决问题。在这个方面，Y没有最终解决问题，又并没有及时上报，也是有责任的。

协调完资源后，经过昨晚和周二的处理，目前情况已经被控制，还需要观察一段时间，才能认定是否完全解决问题。Y在周二给我发的邮件中，谈及他的事后总结：

1. 解决一个故障，要从多个方面去优化，分工合作，打组合拳；
2. 做好最坏打算。

Y不是第一次处理这类事情，只是以往跟随我们处理情况，知道这些道理和自己亲自操刀，体会是很不一样的！但是，留给我们的思考：

1. 一定需要这种血的代价才能让人成长吗？
2. 如果刚好不是我抽查到这个项目，那么怎么办呢？

管理中心必须重视起这个问题了，CMMi过了级，是不是就应该着手马上对这些流程、监控加大力度监管呢？现在，我算是了解gcd管理、治理国家的难度了，如果体制上、组织上养成报喜不报忧，一定是面对风险无法及时做出反应的！还好，我们的业主不可能会象那些收封口费的记者，至少他现在还肯在会上告诉我们，投诉我们就是是投资我们！