原以为博文《风险意识,决定了是事半功倍,还是事倍功半,甚至决定了...》中一文提到项目O已经完成升级,上周四从邮件看到了负责基础架构的同事Y邮件,谈及该项目在我们应用系统升级后,出现数据库驱动程序不兼容的情况,导致数据库连接泄漏而缓冲池耗尽的情况,从Y的邮件上看到情况已经处理完毕。
周一下午,我以QA身份参加了抽查了该项目的项目周会,结果很不幸,听到的用户“无可奈何”投诉,说项目O从上周三10月30日开始应用升级后,就不断造成系统死机,而我方处理问题的速度很慢,到周一还没有解决问题,周一上午11点多还再次出现死机情况。
经过细致了解,了解情况如下:
- 10月29日周三升级后,已经出现问题,但是系统没有进行升级回滚;
- 10月30日周四项目组进行系统进行部门核心模块的回滚,并且知会了基础架构部的同事Y要求支援,Y并且进行问题排查,认为原因已经找到,并且进行修复,完毕后发送了邮件知会了大家,包括我在内;
- 10月31日周五上午10点左右,再次出现死机情况,证明30日晚的排查判定可能是错误的,此时Y赶到现场,初步排查后觉得更改数据源的使用方式;
- 11月1日周六进行使用方式的替换测试和实施工作,由于环境原因,没有进行性能测试,但是从周六使用情况上看,看似正常;
- 11月2日周日下午,项目组同事再次进行监控,发现系统正常;
- 11月3日周一上午一早进行监控,发现系统存在工作不正常的情况,此时服务器上的资源非常紧张,中午进行了参数的调整;
- 11月4日下午就到了我去现场开会了。
周五的情况,项目组有将情况知会部门经理,但是周六、周日以及周一的情况就没有及时知会。我去抽查的会前,信息只是到了周四的情况,所以从这个角度,信息不对称,让我们面对项目风险无法及时做出反应,容易错过协助救援的最佳时机。
会后,除了和项目经理L将工作协调安排外,做的第一件事情就是知会相关干系人,并且马上通知Y,要求他马上到现场解决问题。在这个方面,Y没有最终解决问题,又并没有及时上报,也是有责任的。
协调完资源后,经过昨晚和周二的处理,目前情况已经被控制,还需要观察一段时间,才能认定是否完全解决问题。Y在周二给我发的邮件中,谈及他的事后总结:
- 解决一个故障,要从多个方面去优化,分工合作,打组合拳;
- 做好最坏打算。
Y不是第一次处理这类事情,只是以往跟随我们处理情况,知道这些道理和自己亲自操刀,体会是很不一样的!但是,留给我们的思考:
- 一定需要这种血的代价才能让人成长吗?
- 如果刚好不是我抽查到这个项目,那么怎么办呢?
管理中心必须重视起这个问题了,CMMi过了级,是不是就应该着手马上对这些流程、监控加大力度监管呢?现在,我算是了解gcd管理、治理国家的难度了,如果体制上、组织上养成报喜不报忧,一定是面对风险无法及时做出反应的!还好,我们的业主不可能会象那些收封口费的记者,至少他现在还肯在会上告诉我们,投诉我们就是是投资我们!