【IT168 业界资讯】　　有的时候，屋漏就是会偏逢连夜雨，曾经发生过的几个大当机事件，更是重新证明了这件事，凡事都有可能发生。 事实上，现在多数大型企业的系统，在设计时就会考虑到备援和容错的问题，如果只是出现单一个错误，往往还会有其他可用的补救方法。事实上，现在多数大型企业的系统，在设计时就会考虑到备援和容错的问题，如果只是出现单一个错误，往往还会有其他可用的补救方法。

　　但是为什么大当机的事件还是会发生呢？但是为什么大当机的事件还是会发生呢？ 仔细去观察这些事件会发现，之所以会造成广泛受到世间关注的长时间大当机，很多时候都是因为错误连锁造成的，也就是说，并不是单纯的一个原因，而是几个连续发生的错误，一个接着一个，才造成无可挽救的当机。仔细去观察这些事件会发现，之所以会造成广泛受到世间关注的长时间大当机，很多时候都是因为错误连锁造成的，也就是说，并不是单纯的一个原因，而是几个连续发生的错误，一个接着一个，才造成无可挽救的当机。

　　4个连环错误，造成日本11万台ATM无法正常运作

        过去曾发生的日本多家银行ATM系统连锁大当机事件，就是很典型的例子。 4个连环错误，造成日本11万台ATM无法正常运作过去曾发生的日本多家银行ATM系统连锁大当机事件，就是很典型的例子。 这个事件的开端，最早只是起因于部分区域的突然停电，导致ATM系统需要重新启动。这个事件的开端，最早只是起因于部分区域的突然停电，导致ATM系统需要重新启动。 由于停电发生的时间是在半夜，当时值班的人员刚好经验不足，启动的同时在设定与操作上，发生了错误，但是当下并没有人发现，系统看起来也正常运作。由于停电发生的时间是在半夜，当时值班的人员刚好经验不足，启动的同时在设定与操作上，发生了错误，但是当下并没有人发现，系统看起来也正常运作。

　　一切看起来只是个半夜发生的小事件而已，不过随着时间过去，问题越来越大。一切看起来只是个半夜发生的小事件而已，不过随着时间过去，问题越来越大。 由于先前的设定错误，导致各个银行间跨行转帐的中继系统连线无法正常运作，每个跨行转帐的动作，结束后却无法从系统中断，随着越来越多人使用跨行转帐的功能，系统的负担也就越来越重。由于先前的设定错误，导致各个银行间跨行转帐的中继系统连线无法正常运作，每个跨行转帐的动作，结束后却无法从系统中断，随着越来越多人使用跨行转帐的功能，系统的负担也就越来越重。

　　之所以会有这样的问题，是因为系统设计上，各个银行ATM间的中继系统，在执行跨行转帐动作时，系统的设定会自动去搜寻负荷较轻的连线网路。但是由于先前谈到的那间银行，在系统重开时的设定错误，使得跨行转帐的动作结束后，一直无法获得结束的回应。随着工作的累积，这时候，中继系统会自动判断这裡的网路或是对方的系统过于忙碌，所以又会发送需求，切换到其他原本预备好的线路。但是原本的需求却还悬在系统中，这样反覆下去就成了一个迴圈，系统不停的去找更为空閒的连线，然后逐渐吃掉中继系统的运算能力。雪上加霜的是，这个原本设计上没有考量到的问题，随着时间越接近早上，使用该银行跨行转帐功能的使用者越来越多，状况就越来越严重。

　　隔天早上，症状开始浮现时，一开始只是几台该银行的ATM不能运作，整个系统的运作效能低落。但IT人员还在调查原因的同时，突然就像是雪崩一样，连接各个银行ATM业务的中继系统停止运作了。后来才发现，事情发生当时，处理器的运算负载量已经超出了平常的4倍，随着早晨来到，使用者数量一口气爆增，就挤爆了整个系统的负荷能力。而后随着中继系统的停止，连带波及到了其他1,700多间不同银行体系大大小小分行的ATM运作，总共11万台ATM就这样无法使用，时间长达将近一天。当时日本IT杂志针对这个事件的评语是：事实总是比小说情节还要来得离奇。

　　谁也没想到，一间银行的ATM系统设定错误，竟然会造成如此大的连锁反应。综观这个事件，会发现最后的结果是4个不同的连锁错误造成的。首先当然是停电问题，突然的停电，导致部分区域的ATM无法正常运作；其次就是设定操作的错误，由于单一银行重新开启系统时，设定操作的错误，埋下了之后整个系统崩溃的祸因；第三则是负责处理各个银行间ATM转帐功能的中继系统，本身设计上的考量失误，没有考虑到这样的状况；第四就是发现问题与处理速度的能力不够强，加上原本的设计没有考量到突然大规模爆量的使用负载，最终才造成了11万台ATM的大规模停摆。

　　这4个问题，有些是事件当天24小时内发生，但多数却都是早远就已经埋下的祸因。就像电影阿波罗13号的主角说的：「原来这个问题早在我当上太空人的2年前就已经出现了。」从半夜到早晨，IT人员也有多次机会可以做紧急的处置，但是这个时机也错过了。

　　掌握流程与系统运作的透明度，避免二次灾害才是良策

　　这就是一个很典型的系统大当机实例，在这个业界，每当当机事件发生的时候，大家常常会打趣的说，一定是因为乖乖没有放，或是放错颜色，才会造成当机。不过其实如果仔细的去检视每个大当机事件背后的原因，其实可以找到很多值得吸收的教训。正所谓失败为成功之母，这些他人曾经犯过的错误，很有可能也是你可能犯下的错误。

　　从这一点来看，本次的封面故事就是想透过整理与归纳一些大当机事件的原因，让读者能够从中获得一些有价值的教训。细节我们将在之后细谈，不过要先说明的是，不光是想办法避免当机这件事情很重要，如何在当机事件发生之后，妥善的应对，也是一门重要的学问。当机事件发生的时候，如果没有妥善的处理，溷乱很有可能还会再造成更大的溷乱。

　　再举一个日本银行曾经发生过的事件，来说明妥善应对的重要性。有两间日本的银行进行合併，合併的同时，代理自动收取电费、电话费等的扣款业务系统也同步进行了整併。

　　这个转帐扣款系统的运作是这样的，每天早上10点自动处理由电力公司或电信业者传来的资料，整个系统细分成10个运作的步骤，一个接一个步骤处理，然后把资料传到后端的检核系统，和资料库比对，如果其中任何一个步骤发生了问题，就会需要人工重新检查，然后再重新执行。以这样的安全机制，避免转帐发生任何错误。转帐和扣款手续验证、处理完毕之后，再回传给委託处理的公司，然后达成帐务资料的一致性。

　　不过就在两间银行合併的期间，系统重新上线后，发生了一些问题，导致原本应该是例外的人工检查流程，变成了常例，系统把多数的自动转帐检查流程，都视作异常，要求人工重新检查。问题发生之后，IT人员在数日内就把这个系统的问题解决完毕，一切看起来又回复正常。但过了一周，结帐的时刻到了，却发现，将近20万件帐务发生了重複扣款的问题，很多用户的帐户被重複扣款，同一笔帐务被扣了两次钱。

　　事后追查，发现在系统出现问题的那几天，由于很多业务都转为由人工审核输入资料，平常银行并没有应对这样状况的计画，所以人工处理的速度不够快，导致越来越多的资料累积，等着人工处理。在这个时候，前端每天早上自动处理的系统，接到的累积需求越来越多，批次资料处理的需求逐渐变得庞大，导致整个系统的处理速度低落。也就是正当IT人员着眼于处理后端审核机制的问题时，其实前端的系统也连带的出现了问题，很多动作已经停摆。

　　而当IT人员终于解决了审核系统的问题，把流程重新切回自动化的时候，却误把已经部分由人工审核通过的帐务资料，重新又输入一次到系统中，这使得这些理当已经完成扣款，并且已经回传给委託公司的帐务，又重新跑了一次流程。而系统本身原有的审查机制，也由于那几天出现问题的时候，没有记录到这些帐务已经处理完毕，于是自动完成了第二次的扣款程序。最后，导致了将近20万件帐务重複扣款的事件。

　　从这个事件可以看出，当机事件发生的时候如何不造成整个流程溷乱，进而发生第二次的灾害与错误，缩小被害范围，是多么重要的一件事情。否则原本可以内部处理完毕的事情，很有可能就会扩大为影响整个企业商誉的重大事件。而之所以会造成这种状况的原因，很多时候是因为在处理当机事件的一片溷乱之中，IT人员有时候无法掌握整个流程运作的全貌，会疏漏了很多细节，然后造成二次灾害。

　　要避免这一点，IT人员流程与系统运作的掌握，就是很重要的一个课题。透明化，其实也正是解决这个问题的良策。当机事件的发生可能难免，毕竟Shit Happens，但是应对之道的预备，以及危机当时的临场反应，其实往往有赖于平时IT人员能不能够看到整个企业系统与流程运作的全貌，而透明化，换句话说也就是提高IT人员对这些知识的掌握度，就是其中的关键。

　　接下来，我们将从硬体、软体面来看，并辅以各种曾经发生过的当机事件实例，来归纳出可供参考的经验。最后，我们将提供面对当机事件时，企业该如何应对的几个步骤与方法，期望提供一些帮助。