正文
这段已有八年时间处于无用状态的代码由于标识值的更新而被唤醒了。僵尸灾难发生了，只剩下破产一条路。
InfoQ：采取哪些措施本可以避免问题的发生？
Henney：可以说完美风暴中的任何一个贡献因素都是有问题的，但是这些因素的组合被证明会引发更为严重的问题。更改其中任何一个贡献因素都有可能阻止或至少降低损害：
-
服务器是手工更新的：这是一个迫切需要自动化的任务。
-
失败的更新并未得到关注：没有人去审查更新。飞机舱门虽然是手工上锁的，但飞行安全是通过机组成员间的交叉验证得以提升。
-
无用代码并非真的无用，除非确实被移除。他们早在几年前就应该移除那些多余代码。
-
有时确实是出于十分现实的考虑而将标识、记录等改做他用，而非添加新的。但是如果完全可以添加新的而非回收利用，就应该去添加新的。
-
企业在处理违规交易系统中缺失了上报流程。通常很难预期能得到准确的交易失败情况，但是如果采用高速交易系统意在实现比交易员更快交易的话，很明显这也会导致金钱更快的损失，因为高速交易系统放大了交易能力。企业应该具有清晰的上报流程，最好是具有一种中止机制（Stop-the-line Culture）。
-
在发生故障的45分钟里，他们在不了解错误原因的情况下将正确的更新进行了回滚。这使得问题更为复杂化，而非解决了问题。一个实时系统不知因何出错，却手忙脚乱地处理，只会让事情变得更糟。不要这样做。
