前段时间看《与熊共舞》,我也用里面的方法分析了一下我们正在做的项目,但总感觉没什么风险。
但是昨天的一件事情给我上了一课。
我们的项目真的没有什么风险,对既存的一个项目做一个升级,主要增加两个机能,日本的担当很负责人,需求什么都定义的很好,以以往与他合作的经历来看,开发过程几乎不可能出现需求变更。涉及到的主要技术前期我们也都已经调查清楚。
唯一的一个问题是:
日方给我们提供的一个jar包存在着一个bug,使用的derby数据库版本也有一个bug,
他们共同作用,会导致jvm内存溢出。我们商量的结果是将他们放到下一个版本中对应。
但因为这两个bug的结果,日方给了我们两周时间,让我们看一下在不同的负荷下系统能运行多长时间。
所以理想的报告可能是这样:
系统在XXX负荷下,连续运行15天没有问题。
或者,系统在XXX负荷下,连续运行到第11天出现问题。
然而问题来了,当系统运行到第9天的中午,也就昨天中午,公司所在的整个写字楼停电1小时,
我们所有的测试环境全部down掉。
这是一件很郁闷的事情,因为以前停电都是有事先通知的。
这一问题是否可以避免呢?
弄一个ups电源?
然而这不是问题的重点,重点是我们没有想到可能会存在这样的问题。
在我们的做法中,即使事前通知会停电我们也无能为力。
在我们的做法中,如果谁不小心踢了电源一脚,我们仍然无能为力。
就如同大家写程序一样,大家对正常分支的考虑都算周到,然而对异常的考虑有时候就不是那么充分。
因为这里存在思维的盲点,这次的事情也一样。
所以这是以后修炼的一个方向,让整体的思维变得更为缜密。
让思维变得缜密是有方法可依的。
让思维变的缜密也必须依赖于方法与流程,不是哪个人可以凭空来的。
至少对于这次的问题,我们有机会想到。
要测试7*24运行,万一遇到XXX情况不久测试中断了吗?不久不能保证连续运行了吗?那怎么办?
这些问题都曾在我们心中闪过。
然而我们没有遵从与熊共舞中的建议:
风险管理即使留意心中的每一个问号,每一个不知道,哪怕他只是一闪而过。
(我做了意译,因为我忘记了原文)
如果我们没有想到这些问题也就算了,但我们明明已经想到,却又将他们亲手放走,这着实让人遗憾。
唯有见微知著,以后防微杜渐吧。