【IT168 业界资讯】　　因为硬体问题而造成大当机事件的状况，常见的原因可以归纳为二：一个是硬体性能预估保留的评估错误，无法面对突然来临的大量处理需求；另一个则是备援机制的维护不确实，导致需要切换到备援机制的时候，无法正确运作，反而引发连锁错误而当机。

　　当然正如先前所谈到，通常会造成严重的当机的原因，往往都是因为不同错误的连锁问题造成，但是硬体发生问题，却常常是很多当机事件之所以之后会一发不可收拾的源头。当然正如先前所谈到，通常会造成严重的当机的原因，往往都是因为不同错误的连锁问题造成，但是硬体发生问题，却常常是很多当机事件之所以之后会一发不可收拾的源头。

        Web应用最常发生性能不足的问题，中介设备常被忽略

　　硬体的记忆体、处理器或整体设备性能不足，进而造成大当机事件的状况，最常发生在Web相关的应用上。 由于Web应用较难预估使用者的可能数量，当需求大量涌进的时候，往往会造成系统无法负荷，进而导致当机。由于Web应用较难预估使用者的可能数量，当需求大量涌进的时候，往往会造成系统无法负荷，进而导致当机。 这种状况在社群网站、售票、网购的系统上，最常出现。这种状况在社群网站、售票、网购的系统上，最常出现。

　　举例来说，台湾高铁售票系统刚上线时，就曾发生过这种状况。举例来说，台湾高铁售票系统刚上线时，就曾发生过这种状况。 2007年1月，当高铁正式开始售票的时候，就发生了多次自动售票机当机的事件，当时交通部路政司司长尹承蓬表示，1月17日当天16馀万张车票的交易，已经是高铁公司当时售票系统的上限。 2007年1月，当高铁正式开始售票的时候，就发生了多次自动售票机当机的事件，当时交通部路政司司长尹承蓬表示，1月17日当天16余万张车票的交易，已经是高铁公司当时售票系统的上限。 之后交通部高铁局局长庞家骅才进一步指出，高铁公司将再增加4 台伺服器，由原本的4台扩充至8台，用来解决当时系统当机的问题。之后交通部高铁局局长庞家骅才进一步指出，高铁公司将再增加4 台伺服器，由原本的4台扩充至8台，用来解决当时系统当机的问题。

　　这就是很典型的性能空间预留不足所造成的问题，一般直接的思考就会想到透过增加后端伺服器、频宽来解决这样的问题。这就是很典型的性能空间预留不足所造成的问题，一般直接的思考就会想到透过增加后端伺服器、频宽来解决这样的问题。 但其实事情往往不是这么简单，有的时候，系统效能和前端整合设备的介面，以及中间负载平衡设备或是闸道器设备，也有很大的关係，许多因为硬体能力不足而造成大当机的事件，这些设备往往才是主因。但其实事情往往不是这么简单，有的时候，系统效能和前端整合设备的介面，以及中间负载平衡设备或是闸道器设备，也有很大的关系，许多因为硬体能力不足而造成大当机的事件，这些设备往往才是主因。

　　举例来说，日本某间网路购物厂商，也曾有过类似的问题。 该厂商的购物终端设备，除了Web直接订购之外，也能够透过便利商店的Kiosk和部分连锁书局的专用购物Kiosk设备进行连线。该厂商的购物终端设备，除了Web直接订购之外，也能够透过便利商店的Kiosk和部分连锁书局的专用购物Kiosk设备进行连线。 某次当一个热卖商品正式开卖没多久，便利商店Kiosk连线购物的功能很快就当机无法使用了。某次当一个热卖商品正式开卖没多久，便利商店Kiosk连线购物的功能很快就当机无法使用了。 事后发现，由于便利商店的Kiosk购物介面与Web不同，所以在系统设计时，使用者购物资讯传回该购物厂商后端系统前，必须透过中介转换的伺服器，将资讯转换为适当格式后才能输入该厂商的Web应用伺服器。事后发现，由于便利商店的Kiosk购物介面与Web不同，所以在系统设计时，使用者购物资讯传回该购物厂商后端系统前，必须透过中介转换的伺服器，将资讯转换为适当格式后才能输入该厂商的Web应用伺服器。 书店专用的Kiosk上也採用相同做法，但是由于事前的评估低估了便利商店的使用量，所以当热卖的商品上线开卖时，便利商店Kiosk专用的中介伺服器无法承受同时涌入的大量需求而当机，导致整个系统无法完成交易，使得商品销售的业务上遭受了一定的损失。书店专用的Kiosk上也采用相同做法，但是由于事前的评估低估了便利商店的使用量，所以当热卖的商品上线开卖时，便利商店Kiosk专用的中介伺服器无法承受同时涌入的大量需求而当机，导致整个系统无法完成交易，使得商品销售的业务上遭受了一定的损失。

　　当时台湾高铁的售票系统也有类似的需求，当需要整合不同介面的终端时，中介设备往往是设计与规画上的瓶颈，容易因为低估需求而出错，导致当机。当时台湾高铁的售票系统也有类似的需求，当需要整合不同介面的终端时，中介设备往往是设计与规画上的瓶颈，容易因为低估需求而出错，导致当机。 其实很多网站的当机事件，也常常不是因为Web应用的伺服器被击溃，而是前面的负载平衡设备无法承受突然涌进的流量而导致当机。其实很多网站的当机事件，也常常不是因为Web应用的伺服器被击溃，而是前面的负载平衡设备无法承受突然涌进的流量而导致当机。 举例来说，2008年，知名游戏网站巴哈姆特遭受DDoS攻击事件，虽然是攻击事件，但最先倒下也是负载平衡设备，而不是后端的应用伺服器。举例来说，2008年，知名游戏网站巴哈姆特遭受DDoS攻击事件，虽然是攻击事件，但最先倒下也是负载平衡设备，而不是后端的应用伺服器。

　　其实准备伺服器来面对突如其来的流量，很多企业已经都有了这样的常识，当流量暴增或是伺服器停止运作时，至少确保75％的运算效能，已经是很多企业设计系统的标准。其实准备伺服器来面对突如其来的流量，很多企业已经都有了这样的常识，当流量暴增或是伺服器停止运作时，至少确保75％的运算效能，已经是很多企业设计系统的标准。 不过如果每台伺服器的运作使用率比较低，也可以多准备伺服器来预防这样的问题。不过如果每台伺服器的运作使用率比较低，也可以多准备伺服器来预防这样的问题。 例如准备4台伺服器，3台运作、1台预备，在这样的架构下，理论上只要每台伺服器的运算负荷没有超过33％，任1台伺服器无法运作的时候，预备的伺服器随时都可以接手。例如准备4台伺服器，3台运作、1台预备，在这样的架构下，理论上只要每台伺服器的运算负荷没有超过33％，任1台伺服器无法运作的时候，预备的伺服器随时都可以接手。 加上现在伺服器虚拟化的应用也比较成熟，这一类的准备已经是多数企业IT人员都已经做到，或是已经拥有的常识。加上现在伺服器虚拟化的应用也比较成熟，这一类的准备已经是多数企业IT人员都已经做到，或是已经拥有的常识。

　　但是从历次几场相关原因的大当机事件来看，反而网路中介设备、中介伺服器的需求评估，常常会是被忽略的一环。 例如先前谈到日本的例子。例如先前谈到日本的例子。 而虽然没有被证实，当时台湾高铁数次售票系统当机的原因，也有不少人直指是资料传输到后端核心售票系统前，中介伺服器的准备数量不足造成。而虽然没有被证实，当时台湾高铁数次售票系统当机的原因，也有不少人直指是资料传输到后端核心售票系统前，中介伺服器的准备数量不足造成。

　　另外，据了解，某知名售票系统常常发生无法订票的原因，很多时候是使用者使用习惯的关係。另外，据了解，某知名售票系统常常发生无法订票的原因，很多时候是使用者使用习惯的关系。 使用者为了买到热门的票券，常常打开多个网页视窗占用连线数量，长达几个钟头，并且反覆地以重新整理的方式试图抢购。使用者为了买到热门的票券，常常打开多个网页视窗占用连线数量，长达几个钟头，并且反覆地以重新整理的方式试图抢购。 使得系统维护者无论如何增加频宽和伺服器的数量，就是无法解决问题。使得系统维护者无论如何增加频宽和伺服器的数量，就是无法解决问题。 其实这也意味着考量到不同消费族群的使用习惯，在硬体设计的评估上也需要事先准备，其实要解决这种问题也不是不可能，只是投资是否合乎企业的利益，还需要再考虑清楚。其实这也意味着考量到不同消费族群的使用习惯，在硬体设计的评估上也需要事先准备，其实要解决这种问题也不是不可能，只是投资是否合乎企业的利益，还需要再考虑清楚。

        备援机制也需要注意维护，否则会造成更大的灾难

　　还记得2009年初的桃园机场大当机事件吗？ 这次长达36小时左右的大当机，主要问题是第一航厦的护照查验系统，因为硬碟损害影响机场正常运作，虽然桃园机场第一航厦与第二航厦的系统有交互备援机制，但是由于备援的第二航厦系统，竟然同时也因为硬碟受损而无法运作，才导致护照查验系统完全无法使用。这次长达36小时左右的大当机，主要问题是第一航厦的护照查验系统，因为硬碟损害影响机场正常运作，虽然桃园机场第一航厦与第二航厦的系统有交互备援机制，但是由于备援的第二航厦系统，竟然同时也因为硬碟受损而无法运作，才导致护照查验系统完全无法使用。 当时影响范围包括桃园机场、松山机场、台中机场、高雄机场、金门水头码头以及马祖福澳港等。当时影响范围包括桃园机场、松山机场、台中机场、高雄机场、金门水头码头以及马祖福澳港等。

　　虽然当时内政部移民署副署长黄碧霞对外发表声明指出，依据初步判断，已经排除人为因素的可能。虽然当时内政部移民署副署长黄碧霞对外发表声明指出，依据初步判断，已经排除人为因素的可能。 但事实上这整个大当机事件的真相如果真是因为硬碟损坏，那就非常令人匪夷所思，而且很明显的有人为维护、操作的错误因素在其中。但事实上这整个大当机事件的真相如果真是因为硬碟损坏，那就非常令人匪夷所思，而且很明显的有人为维护、操作的错误因素在其中。 不过由于相关人士都无法出面证实，所以事件的全貌也就如此埋没。不过由于相关人士都无法出面证实，所以事件的全貌也就如此埋没。

　　不过，事后追查发现，当时，由于护照查验系统的维护厂商，才刚从大同公司转由神通电脑负责不到几天，双方竟然没有完成交接，导致神通电脑是在完全不了解系统架构与概况的情况下，抢修护照查验系统，最终虽然也完成抢修，这可能是造成抢修时间拉长的原因之一。不过，事后追查发现，当时，由于护照查验系统的维护厂商，才刚从大同公司转由神通电脑负责不到几天，双方竟然没有完成交接，导致神通电脑是在完全不了解系统架构与概况的情况下，抢修护照查验系统，最终虽然也完成抢修，这可能是造成抢修时间拉长的原因之一。

　　此外，也有不少人猜测，是否因为不熟悉系统，以致于第一线维修人员动手维修时，没有依照标准作业程序，造成磁碟连锁当机，导致更严重的问题，否则，一般情况下，由于有RAID架构的保护，不太会因为单一硬碟出问题，且在有备援系统的状况下，还陆续引发连锁当机的情况。此外，也有不少人猜测，是否因为不熟悉系统，以致于第一线维修人员动手维修时，没有依照标准作业程序，造成磁碟连锁当机，导致更严重的问题，否则，一般情况下，由于有RAID架构的保护，不太会因为单一硬碟出问题，且在有备援系统的状况下，还陆续引发连锁当机的情况。 有趣的是，护照查验系统已经有10多年的历史，那一次大当机也不是第一次当机，据了解2008年就先后有过4次当机事件，只是当机时间短，所以并没有引起太多关注。有趣的是，护照查验系统已经有10多年的历史，那一次大当机也不是第一次当机，据了解2008年就先后有过4次当机事件，只是当机时间短，所以并没有引起太多关注。 据了解，之前的当机都是在几十分钟内就完成，由于没有人可以证实，所以不确定这些小规模的当机，是否和之后这次停摆36小时的事件有关，但很有可能已经有一些问题徵兆显现。据了解，之前的当机都是在几十分钟内就完成，由于没有人可以证实，所以不确定这些小规模的当机，是否和之后这次停摆36小时的事件有关，但很有可能已经有一些问题征兆显现。

　　这个例子除了显示出日常维护的松散，以及行政流程完全不考虑交接过程的严重过失之外，也揭露了一个重要的问题，那就是平常养兵千日，用在一时的备援机制，其实也需要花心思去维护，否则在真正需要的时候，反而可能是另一场灾难的开始。 这其中还有许多值得探讨的问题，例如公营单位的委外制度，让第一线的IT人员都没有能力处理任何问题，只能极度仰赖厂商，这样的做法是否正确？这其中还有许多值得探讨的问题，例如公营单位的委外制度，让第一线的IT人员都没有能力处理任何问题，只能极度仰赖厂商，这样的做法是否正确？ 不过那已经是制度面的问题，在这裡我们暂且打住。不过那已经是制度面的问题，在这里我们暂且打住。

　　此外，今年农历年前，中国信托商业银行的当机事件也是一个血淋淋的例子。 2月5日晚上6点20分，中国信託商业银行的机房发生大当机，导致包括银行端信用卡、网路银行、自动柜员机、客服中心与台湾彩券电脑型彩券交易系统等业务服务皆中断。 2月5日晚上6点20分，中国信托商业银行的机房发生大当机，导致包括银行端信用卡、网路银行、自动柜员机、客服中心与台湾彩券电脑型彩券交易系统等业务服务皆中断。 中国信託紧急抢修后，才在7点20分机房恢复营运，终于让民众赶在开奖前买到彩券。中国信托紧急抢修后，才在7点20分机房恢复营运，终于让民众赶在开奖前买到彩券。 事后中国信託商银对外发布新闻稿表示，当机原因是不断电系统（UPS）故障异常。事后中国信托商银对外发布新闻稿表示，当机原因是不断电系统（UPS）故障异常。

　　会发生这个事件，是因为2月5日中国信託商银的机房正在进行停电演练，模拟台电供电异常时，机房的备援措施能否发挥功效，以确保机房的运作不受台电跳电或断电等问题的影响。会发生这个事件，是因为2月5日中国信托商银的机房正在进行停电演练，模拟台电供电异常时，机房的备援措施能否发挥功效，以确保机房的运作不受台电跳电或断电等问题的影响。 但是当切断台电供电来测试发电机是否正常时，中间会有30秒的空窗期，必须仰赖UPS供电。但是当切断台电供电来测试发电机是否正常时，中间会有30秒的空窗期，必须仰赖UPS供电。 巧合的是，当时UPS的电池电量不足，导致这短短30秒电力中止，让整个系统因为无电可用而停摆。巧合的是，当时UPS的电池电量不足，导致这短短30秒电力中止，让整个系统因为无电可用而停摆。 据了解，主因是因为UPS的电池已经使用了7年，老化后电量不足。据了解，主因是因为UPS的电池已经使用了7年，老化后电量不足。