发生在眼前的故事：做好最坏的打算，往往事情不会去到最坏的地步（二）

续《发生在眼前的故事：做好最坏的打算，往往事情不会去到最坏的地步（一）》

以下事情发生在9月22日的8:45~11:30AM

周一早上，系统E上线的第一个早上，8:45分公司还没有上班，致电项目经理A，询问服务人员是否已经到位，得到的回答是

1. 项目组同事在7点钟已经到达客户办公，利用客户8点钟上班前一个小时进行最后的生产系统测试；
2. 从8点上班到现在系统目前运行正常；
3. 项目组的同事已经分为三个部分的人员开展工作，同事cdw负责对系统进行健康监控，同事lq负责在QQ或者电话上回答问题，另外一个同事负责后续功能点的开发；

在了解完这些情况后，我要求项目组向我提供系统E的健康监控数据，主要是系统E目前的吞吐率，也就是平均每秒完成的请求数，项目经理A说等会监控后，用短讯通知我。

11:01分收到cdw同事以下的短讯：到目前为止，系统当前的会话数是126个，最高会话数是162个，总会话数是341个。

11:05分收到cdw同事的电话，我正在忙，告知等会回电。

11:30分左右，打电话给项目经理A，告知除了系统的会话数外，其实我们最关心的是系统的吞吐率，并发访问量，也就是每秒钟完成的请求数，可以从中看到系统的访问量的多少，通过经验值可以知道系统的繁忙程度以及运行的正常程度。项目经理A说同事cdw正在通过控制台监控，还不太会如何从控制台上看到这些指标。我的回答是：OK，那好好学习如何看Weblogic控制台。

另外告知项目经理A，除了从系统的技术角度看系统的繁忙以及吞吐量外，还可以从业务的角度看系统的吞吐量，比如，早上新建的单据有多少单，处理完毕多少单，与上线前的旧系统对比环比趋势如何？这些数据都能够说明系统的运行情况。

项目经理A在电话里回复，等他们进行数据收集后再告知我，目前系统的运行还一切正常。

 

以下事情发生在9月22日的4:00~4:30PM

周一的工作总是较为繁忙，一来也考虑到系统E刚上线，项目组同事还有一些服务的工作在进展，所以等到下午4点打电话询问项目经理A系统的运行情况，回答是：上午和我通完电话后，大概12左右，系统又发生类似“死机”的现象了！该现象是由我方的监控人员发现的，刚好是在中午下班的时刻，所以我们很快就重启服务恢复！

听到项目经理A这么说，我骂了项目经理A：

1. 发生了这样重大的故障，为什么发生了4个小时，而且是我电话才告诉我，如果我们忙的话，是不是准备将问题瞒下去！这种做法是温水煮“青蛙”!#$%@#!$
2. 如果这个时候，用户投诉我们，我们连事情都不知道，那是多么的被动！
3. 我们的业主有知情权，虽然当时在中午吃饭的时间，用户量也不大，我们监控及时，对故障的响应很快！但是，我们现在不能保证没有下次，有下次的话，也不一定还会在系统较沉寂的时刻，所以我们必须知会业主，我们存在这种情况，但是我们正在严密监控！
4. 4个小时，证明公司还未能定义并且执行故障的升级服务流程，项目经理A领导Z知道了，Z的领导W和F还不知道，我们怎么能及时调动资源进行危机处理呢！

我骂完后，项目经理A领导Z已经在2点半左右通知了架构组的同事dy，但是目前还没有解决！我说好吧，当务之急，我马上调动资源解决问题，另外继续监控服务健康情况，项目经理A需要写一个报告告知业主，这个事多难做也得做。（事后情况是项目经理A当天还是没有告知业主，还是报了侥幸心理！）

和A通完电话后，和dy的领导F打电话，他说他也是才刚刚听dy说这个事情，我说，由于没有及时升级到我们，其实错过了最好的跟踪处理时机，鉴于以往已经发生的情况，我现在赶会公司，赶快就事情开展处理。今天我们只能算是“好彩”，刚好故障发生的时间不在业务繁忙时段，而且我们有备而来，及时恢复了，但是我们不能掉以轻心，因为下一次，我们不一定有这样的“运气”！

 

（补序：国庆前的一个周，是在紧张忙碌的节奏中度过，现在凭记忆以及手机的短讯、通话记录整理回忆，希望能够重构整个故事，顺便预告一下，现世报其实是有的！）