摘要：第 8章. 災害防護計畫
第 8章. 災害防護計畫
災害防護計畫（disaster planning）是系統管理者很容易忘記的主題 — 這不是什麼輕鬆的話題，而且總有其他更急迫的事情得先完成。然而，就這麼放手不管，是系統管理者最不該做的事情之一。
雖然說到災害，我們總是最先想到天災（例如火災、洪水、或颱風）；但除了天災之外，還有許多人禍（例如建築工人不小心切斷了纜線，或是水管漏水等等）也會造成災難。因此系統管理者應該謹記在心，任何導致企業無法正常運作的因素，都該算是災害。
第 8章. 災害防護計畫
災害防護計畫（disaster planning）是系統管理者很容易忘記的主題 — 這不是什麼輕鬆的話題，而且總有其他更急迫的事情得先完成。然而，就這麼放手不管，是系統管理者最不該做的事情之一。
雖然說到災害，我們總是最先想到天災（例如火災、洪水、或颱風）；但除了天災之外，還有許多人禍（例如建築工人不小心切斷了纜線，或是水管漏水等等）也會造成災難。因此系統管理者應該謹記在心，任何導致企業無法正常運作的因素，都該算是災害。
我們不可能列出所有可能發生的災害，但在此，我們將與您分享各種災害中，最常見的意外事件；我們將從可能引起災害的因素面來探討，而非災害發生的可能性。
8.1. 災害的種類
一般來說，造成災害的因素有四種：
硬體故障
軟體出問題
環境出問題
人為疏失
8.1.1. 硬體故障
硬體故障很容易了解 — 硬體壞了，工作因此而停擺。比較難了解的，是故障的成因、以及如何降低所造成的不便。底下是一些您可以採取的方案：
8.1.1.1. 儲存備用硬體
要降低硬體故障所帶來衝擊的最簡單方法，就是手頭上留有一些備用品。當然，有兩項前提：
有足夠技能的專人可以隨時診斷問題，找出故障的硬體並替換之。
有可替換的硬體。
底下章節將更進一步為您解說這些問題。
8.1.1.1.1. 擁有足夠的技能
根據您過去的經驗，以及所牽涉的硬體，修復技能可能不成問題。但是，如果您沒有處理過硬體問題，那建議您找間電腦補習班，補充一點電腦維修的知識。雖然這些課程不是為維護您企業伺服器所設計；但卻是非常好的基本知識來源（例如使用工具與元件，基本的診斷步驟等等）。
提示
在開始自己動手做之前，記得先確定出問題的硬體：
已經不再保固期間內
不在任何維護服務的範圍內
如果您嘗試修理的硬體在保固期間內、或屬於任何維護合約，那麼您可能會違反某些條款，讓您的硬體不再受保固合約的保護。
不過只需要一點點基本技巧，就可以有效地診斷出問題，並替換出問題的硬體 — 如果您沒選錯備用硬體的話。
8.1.1.1.2. 要儲存哪些備用硬體？
這問題正好反映了災害復原計畫的多面性。要儲存備品前，有幾樣東西是我們要考慮的：
最大可容許停機時間
修復所需的技巧
購置備品的預算
儲存備品所需的空間
其他硬體是否可以使用同樣的備品
以上每個因素都跟該儲存哪些備品息息相關。舉例來說，拿整台電腦當備品，可以將停機時間降到最低，也最不需要修復技巧；但比起儲存一顆 CPU 或一條記憶體來說，價格可貴多了。然而，如果您公司裡面，有幾十台同樣的伺服器，那麼準備一台伺服器當備品，絕對划算。
不管最後的決定是什麼，底下將討論的問題絕對無法避免。
8.1.1.1.2.1. 要儲存多少備品？
備品的庫存量同樣是個多面性的問題。底下是主要考量因素：
最大可容許停機時間
預計故障率
補充庫存品的預計時間
購置備品的預算
儲存備品所需的空間
其他硬體是否可以使用同樣的備品
從某個角度來看，如果有個系統可容許的最大停機時間是兩天，公司可能一年才會用到一個庫存備品，而且備品的補充時間為一天，那麼算下來，只要儲存一個備用品就可以了（甚至不用儲存任何備品，只要您能確保可以在廿四小時內拿到零件即可。）
從另一個角度來看，如果某系統的最大可容許停機時間只有短短幾分鐘，備用品幾個月就會用到一次（同時需要幾個星期才補得進來），那麼您架上可能需要放上五六個（甚至更多）備用品才行。
8.1.1.1.3. 不是備品的備品
什麼叫不是備品的備品？如果您有台正在使用中的電腦，恰好是另一台高優先順序電腦的備品，那麼前者就是「不是備品的備品」。這方法有以下好處：
不用花太多錢在「不具產能」的備品上
能確定備品是可以用的
不過，這方法也有缺點：
低優先順序的工作，會因為系統被挪作備品，而遭到中斷
如果低優先順序的電腦故障，那麼高優先順序的電腦等於沒有備品
根據這些限制，拿另一台工作中的電腦當備品，是絕對可行的；但是備品的工作負荷，以及被挪去取代另一台電腦對企業整體的衝擊，都會對結果產生不利的影響。
8.1.1.2. 服務合約
服務合約（service contract）的好處，在於將硬體故障的問題，交給別人去解決。事實上，您要做的只是確定的確有故障，而且不是軟體問題即可。接下來，打通電話，某個人就會出現，把一切搞定。
這看起來很簡單；不過跟生活中的大部分東西一樣，事情沒有外表看到的那麼簡單。在簽一份服務合約之前，有些東西是一定要注意的：
保修時間
反應時間
零件的可取得性
可用的預算
哪些硬體需要涵蓋在合約中
我們將在以下章節，為您詳述所有細節。
8.1.1.2.1. 保修時間
不同的服務合約可以滿足不同的需求。其中最大的不同之一，就是維修保固的時間。除非您願意付額外費用，否則別想服務人員可以隨傳隨到。
相反地，根據您所簽的合約，您會發現也許在某幾天或某些時間，您是不能打電話找人的；即使可以，技術人員也不見得會出勤。
大部分保修所涵蓋的時間，都以每天幾小時，每週幾天來算，並以工程人員的上班時間為準。最常見的時間是：
週一到週五，09:00 到 17:00
週一到週五，每天 12/18/24 個小時（開始與結束時間由合約雙方協商）
週一到週六（或週一到週日），時間同上
正如您所預期的，合約上的工時愈長，價格就愈貴。一般來說，延長週一到週五的工時，會比增加週六與週日的工時來得便宜。
不過如果您願意花點心思做些動作，還是有其他降低成本的方法。
8.1.1.2.1.1. 維修中心服務
如果您經驗老到，知道電腦哪裡故障，不需要技術人員到府服務，那不妨考慮「維修中心服務（depot service）」。這類服務的名稱眾多，可能也叫「自行送修服務（walk-in service）」或「抱修服務（drop-off service）」。但不管名稱為何，指得都是使用者自行將硬體送到製造商所成立的維修中心，由維修中心的技工為使用者服務。
維修中心的好處，在於送修速度取決於您自己，不必花時間等技術人員有空，然後舟車勞頓地上門維修。維修中心的技師不隨著客戶電話出動，而是等在維修中心。所以只要您把東西送到維修中心，就會有人幫您服務。
因為維修服務都在維修中心完成，所以不太可能出現缺乏零件的情形。這可以降低零件要隔日才會送到您辦公室，或是得開上大老遠的車，到最近的辦公室去拿料件之類的麻煩事。
不過這不是全無缺點的。別的不說，您就不能選擇服務時間 — 只有在服務中心開門的時候，才有人為您維修。另一個問題是，維修中心的技師採上下班制，如果您的電腦在星期五下午四點半出了問題，您五點才送到維修中心，那可能要到下個星期一早上，技術人員才會開始為您檢查。
另一個缺點，是維修中心的距離。如果您的公司位於市中心，那可能不是什麼大問題。但如果您的辦公室位於郊區，那可能要開大老遠的車，才找得到維修中心。
提示
在決定是不是要採用維修中心這個方案前，想想把硬體送到維修中心的整個實際流程。您要開自己的車，還是公司的車？如果是自己的車，那麼空間夠不夠？保險是不是涵蓋這個過程？您一個人能不能把硬體裝上車？需不需要多一個人幫忙？
雖然想這些問題好像太市儈了些；但在決定這個方案前，這些問題都該考慮清楚。
8.1.1.2.2. 反應時間
除了保修時間外，許多合約還指定了長度不等的反應時間。這指得是從您打電話尋求服務開始，到技術人員到達的時間。您可以想見，反應時間愈短，服務合約的價格就愈貴。
這反應時間有它的限制，例如從製造商那兒開車到您的辦公室，得花上個把個鐘頭，佔去大部分回應時間[1]。通常四個小時是比較快的回應時間，比較慢的回應時間從八小時（依照標準上班工時來說，這相當於「隔天」）到廿四小時。跟其他的服務合約一樣，這些時間都是可以談的 — 只要您出得起價錢。
注意
雖然底下說的事情不常發生，但也時有所聞：有時候製造商會曲解合約裡回應時間的意思。有時候製造商會先派個人過來 — 任何人都行 — 好趕上合約上所說的回應時間。這個人好像會先看看問題，然後打電話回「辦公室」，請人送「正確的零件」過來。
但事實上，這個人只是在拖時間，等真正能處理的人到達現場。
在某些特殊情況下（例如大規模的停電），這可以理解；但是如果這情形一直發生，那麼您該考慮打電話給他們經理，要求個合理的解釋。
如果您需要非常短的反應時間（預算也非常充裕），那麼還有個方法可以把反應時間縮到最短 — 零秒。
8.1.1.2.2.1. 零回應時間 — 僱用專職的技術人員
有些情況下（您的公司是附近區域中，最大的客戶），某些需求（公司不允許「任何」停機時間）與某些財務資源（如果真要問多少錢，答案會嚇死你）相結合，您可能會樂意僱用一個全職、專責的技術人員。這方式的好處非常明顯：
立即處理任何問題
更積極地處理系統維護問題
如您所想的，這方法會「非常」貴，尤其是僱用 24x7 的技術人員。但如果這樣對您的企業比較好，那為了達到最大經濟效益，那麼以下幾點請務必牢記在心。
首先，這些技術人員要比其他員工需要更多資源，例如工作空間、電話、門禁卡與鑰匙等等。
如果沒有合適的零件，那麼技師也無用武之地。因此您應該為這些技術人員準備獨立、上鎖的空間，儲存這些備用零件。同時，您也該要求技師隨時清點零件數量，以符合公司需求，避免被其他的技術人員挪作他用。
8.1.1.2.3. 零件的可取得性
很顯然，當您硬體出問題的時候，零件容不容易取得，會成為關鍵性的角色。根據合約的內容，這是另一個需要考量的因素，因為需要零件的不是只有您而已，其他公司也需要。另一家公司如果從您的製造商那兒，買了更多東西，那麼他們可能會得到更好的合約，更容易拿到零件（甚至更容易找到人服務）。
不幸的是，在這種情形下您也無法多做些什麼；除非找經理談一談。
8.1.1.2.4. 可用的預算
如以上所述，根據服務項目的不同，合約價格也不同。記得服務合約是長期支出，每次合約到期前，就得洽談新合約，再付一次錢。
8.1.1.2.5. 哪些硬體需要涵蓋在合約中
還有個地方可以讓您節省成本。假設您有份維修合約，僱用了 24x7 的技術人員，隨時可用的備用品等等。您從這硬體商買的所有硬體，都包含在合約內，即使是辦公室門口櫃台用的電腦也不例外。
這台電腦「真的」需要包含在 24x7 的合約內嗎？不管您公司的櫃台人員在怎麼使用這部電腦，時間也只限於早上九點到下午五點而已；不太可能是：
有人在下午五點到隔天早上九點，還在使用這部電腦（更不要說週末假日）
除了早上九點到下午五點外，電腦壞了會馬上有人知道
因此，把這台電腦納入星期六午夜的維修合約內，根本就是浪費錢。
比較適合的作法，是把合約拆成兩個部份，一邊是比較無關緊要的硬體，另一邊是需要廿四小時運作的重要硬體。這樣的話，就可以有效地降低成本。
注意
如果您有廿台完全相同的重要伺服器，您可能會想，把其中一兩台電腦納入昂貴、高級的合約中；其他伺服器則放進較便宜的合約中。然後，不管哪一台伺服器在週末當機，您都可以說，「當機的這部」就是昂貴合約所保固的機器。
「千萬不要這樣做。」不只因為這是不誠實的行為，同時製造商也會使用序號來紀錄所有硬體。即使您有辦法規避這些檢查，一旦被發現，要付出的金額會比您誠實的代價高出許多。
8.1.2. 軟體出問題
軟體出問題通常會引起更長的停機時間。舉例來說，管理者發現某些號稱高穩定度的品牌電腦，最近開始出了問題。某些天的固定時刻，當程式執行時，會導致系統當機。這很顯然是軟體出了問題；其他軟體相關的問題可能不會那麼嚴重，但一樣還是具有破壞力。
出問題的軟體可以分成兩種類型：
作業系統
應用程式
這兩種問題對系統有著不同的衝擊，我們將在接下來的章節為您詳細討論。
8.1.2.1. 作業系統出問題
在這種情形下，作業系統要負起所有的責任。這又可以分成以下兩種情形：
當機
停止回應
記得，作業系統出問題會讓電腦停止運作，當時執行的所有程序都無法繼續進行。因此，作業系統出問題會對整個企業生產造成影響。
8.1.2.1.1. 當機
當作業系統無法從錯誤中回復時，就會當機。當機的原因不一而足，從無法處理硬體問題，到作業系統核心撰寫不良等等，都有可能。系統當機時，除了重新開機以恢復運作外，別無他法。
8.1.2.1.2. 停止回應
當作業系統停止處理系統事件時，電腦就卡死在那裡，稱為「停止回應（hang）」。引起這問題的，可能是「死結（deadlocks）」（兩個程式互相等待彼此所擁有的資源），也可能是「活結（livelocks）」（兩個以上的程式互相回應彼此的活動，卻不從事任何有意義的行為）。但不管是那種情形，結果都是一樣的 — 電腦完全失去生產力。
8.1.2.2. 應用程式出問題
跟作業系統失效不同的是，應用程式出問題所引起的範圍有限。有些應用程式只會影響單一使用者；相反地，如果是伺服器級的應用程式出問題，那麼影響的可能就是連接該服務的眾多應用程式，牽連廣泛。
跟作業系統出問題一樣，應用程式會當掉或是停止回應；唯一不同的是，當掉或停止回應的，只有應用程式本身而已。
8.1.2.3. 尋求幫助 — 軟體支援
硬體廠商會對自己的硬體提供技術支援，許多軟體廠商也不例外。除了明顯的不同外（例如不需要備品、大部分工作在電話上就可以解決等等），軟體支援的合約跟硬體合約非常類似。
軟體廠商所提供的技術支援不盡相同。底下是目前常見軟體合約的種類：
文件
自我技術支援
網頁或電子郵件技術支援
電話技術支援
現場技術支援
每種技術支援都將在以下章節中詳述。
8.1.2.3.1. 文件
雖然文件常常被人所忽略，但它可以算是最初階、最基本的支援工具。不管是線上文件或是紙本的手冊，裡面通常都包括了非常有用的訊息，可以解決許多問題。
8.1.2.3.2. 自我技術支援
自我技術支援靠得是使用者，利用網路上的資源，解決自己的軟體問題。通常這些資源多半是 FAQ （常被問到的問題集，Frequently Asked Questions）或知識庫（knowledge bases)，並以網頁方式呈現。
FAQ 通常沒什麼選擇功能，使用者只是上下捲動網頁，希望在一堆問題與答案中，能找到有用的資訊。而知識庫則複雜的多，使用者可以輸入關鍵字搜尋。知識庫的涵蓋範圍極廣，是解決難題的好工具。
8.1.2.3.3. 網頁或電子郵件技術支援
通常在網路上使用自我技術支援時，您也會看到一些電子表格或電子郵件位址，讓您輸入問題，轉給技術人員。乍看之下，這是自我技術支援網頁的一大改進；但實際效果還是要看回覆電子郵件的技術人員，如何回答問題而定。
如果技術人員很忙，那就很難從他們身上，得到任何資訊；因為他們的主要考量是盡快回您的信，然後再回其他信件。主要原因是幾乎所有這類技術人員的工作績效，都重量不重質。也因為如此，所以使用者很難透過電子郵件的魚雁往返，獲得即時與有用的回應 — 尤其當技術人員只是匆忙回信，然後要趕快處理下一封信的時候。
如果您希望能得到最好的服務，建議您在信中詳述所有技術人員可能會問到的問題，例如：
清楚地描述問題
加上所有相關的版本編號
說明您已經採取過哪些步驟以解決問題（安裝了最新的修正程式、以最基本的設定重新開機等等）
您能提供給技術人員的資訊愈多，就愈有可能得到您需要的訊息。
8.1.2.3.4. 電話技術支援
電話技術支援顧名思義，就是透過電話直接跟技術人員溝通。這方式跟硬體技術支援差不多，同樣有多種等級的服務（例如不同的支援時間、回應時間等等）。
8.1.2.3.5. 現場技術支援
現場支援有時也稱為現場諮商，通常只在解決特定問題、或是做重大變更時才會用到，例如首次安裝與設定軟體、重大的升級等等。您可以想見，這是所有軟體技術支援中，最昂貴的一種。
不過還有其他場合，公司會採用現場支援。舉例來說，有家只有一名系統管理者的小公司，準備安裝第一台資料庫伺服器。這安裝規模（還有公司本身）都不足以大到再請一位專職的資料庫管理者。這時，從資料庫廠商聘請一位專家來安裝資料庫（日後需要的話，可以再請他偶爾過來看看），會比讓系統管理者接受不常用的訓練課程要便宜得多。
8.1.3. 環境出問題
即使硬體運作順暢，即使軟體設定無誤，也運作正常，還是有可能會發生問題。系統之外最常見的問題，就是系統所處的環境出了紕漏。
環境問題可以分成四個方面：
建築物完善與否
電力系統
空調
天氣與外在世界的影響
8.1.3.1. 建築物完善與否
建築物看起來方方正正，簡單無比；但卻擁有多種機能。它提供了受遮蔽的處所，其中的四時氣候自成一格。建築物裡面提供了電力，也讓其中的東西免於火警、竊盜、以及其他破壞行為。一棟大樓有這麼多種機能，不難想像如果其中一個環節出錯，會造成多大的傷害。底下是可能會發生的情況：
屋頂會漏水，水流進資料中心去。
多種建築物系統（例如水系統、廢水處理系統、或空眨尳êB物不適合使用。
樓層的載重不足，您無法把想要的裝置放進資料中心裡。
建築物可能出的問題太多，不能一一列舉。以上所描述的只是冰山一角，您不妨運用您的創造力，想想其他的可能性。
8.1.3.2. 電力系統
由於電力是電腦系統的命脈，因此不管系統管理者到了哪裡，都要把電力系統當作首要考量。電源問題會產生多種不同層面的影響，詳細情形會在以下章節中討論。
8.1.3.2.1. 電力系統的安全性
首先，要先看看您的電力系統是否安全。跟其他的資料中心一樣，您資料中心的電力來自電力公司的電線。因此，要確保電力來源無虞，您能做的並不多。
提示
在電力公司的服務範圍邊陲地帶，不妨考慮從兩個電力來源獲取電力。
一個是您所在區域的電力公司
另一個則是鄰近區域的電力公司
從鄰近區域的電力公司獲取電力，成本可大可小，適用於大型企業。然而，採用這方式的企業多半認為，獲得的效益高過成本。
要檢查的主要項目，包括電線是怎麼拉進您公司所在的建築物裡。電線位於地表之上還是之下？地表上的電線可能會：
因為惡劣的天氣（刮風、下雪、閃電等）而遭到損害
因為交通事故，導致電線桿或變壓器受損
動物迷途而導致電線短路
不過，地表下的電線也有以下缺點：
建築工人不小心挖錯地方，弄斷了電線
洪水
閃電（雖然跟地表上電線比起來，發生機率小得多）
從電線一路找進公司，進公司前是不是還有個變壓器？這變壓器是不是就在停車場，倒車不慎就會撞到？還是樹倒下就會壓壞？所有的開關是不是都上鎖，以避免閒雜人等接觸？
進到建築物以後，電源線（或電力箱）是不是會遇到其他問題？例如漏水問題會不會導致電力室淹水？
跟著電源線連到您的機房，有沒有什麼東西會無預警地中斷電源供應？例如機房的電路是不是跟其他非機房的電路串在一起？如果是的話，機房外的電力負載一旦過高，就會連帶影響機房一起跳電。
8.1.3.2.2. 電力品質
確定機房的電力來源無虞，還是不夠。您也必須確定機房的電力品質夠好。底下有幾點是您需要考慮的：
電壓
電力公司的供電電壓必須穩定，電壓的伏特數不能過低（這通常稱為 sags、droops、或
brownouts）或過高（通常稱為「突波（spikes 或 surges）」）。
波形
電流的波形應該是乾淨的正弦波，「總諧波失真（THD，Total Harmonic Distortion）」要低。
頻率
頻率要穩定（大部分國家的電流頻率不是 50Hz 就是 60Hz）。
雜訊
電源不應該包括任何「無線電頻率干擾（RFI，Radio Frequency Interference）」或「電磁波干擾（EMI，Electro-Magnetic Interference）」。
電流
電流供應要充足，才足以驅動機房裡的所有設施。
直接從電力公司輸出的電源，通常無法符合機房的標準。因此，機房通常會額外裝設電源配備，以改善這情況。底下是幾種可行的方法：
突波保護器
突波保護器（surge protector）正如其名稱所指 — 會將電源中的突波過濾掉，以保電源純淨。沒有突波保護器的話，那麼機房裝置就可能會因為電源相關的問題，而遭到損壞。
電力調節器
電力調節器（power conditioner）所用的方法較為多樣化，依照配備的不同，電力铡?/p>
馬達發電機組
基本上，馬達發電機組（motor-generator set）是由一般電源所驅動。馬達連上一個大型的調速輪，調速輪則連到發電機上面去。馬達帶動調速輪與發電機，產生的足夠電力再提供給機房使用。這樣一來，機房所用的電力就與外部電力隔絕開來，消弭所有電力相關的問題。如果外部電力瞬間不足，調速輪也可以達到調節的作用，因為在調速輪速度變慢，慢到無法提供足夠電力前，還有幾秒鐘的緩衝期。
不斷電系統
有些不斷電系統（Uninterruptible Power Supplies，通常簡稱為 UPS）包含了大部分（但不是全部）電力調節器的功能[2]。
有了以上最後兩種技術，我們就可以開始討論說到電源問題時，大多數人想到的第一個問題 — 備用電源。接下來的章節，我們將與您討論多種備用電源及其運作方式。
8.1.3.2.3. 備用電源
說到電力，每個人大概都聽過「停電（blackout）」這個字眼。停電就是完全失去電源供應，時間可能從不到一秒到幾週。
由於停電的時間長短差異甚大，因此我們需要使用不同的技術，針對不同情形做處理。
提示
平均起來，最常見的停電只會持續數秒；比這更長的，都不常見。因此一開始您不妨把重心放在解決幾分鐘的停電問題上，然後再以其他方法解決更長的停電問題。
8.1.3.2.3.1. 提供幾秒鐘的電力
因為大部分停電只會持續幾秒鐘，所以您的備用電力計畫需要滿足這兩項特點：
在很短時間內切換到備用電力（這稱為「轉移時間（transfer time）」）
從幾秒鐘到幾分鐘不等的「續航時間（runtime）」，指得是備用電力能持續的時間
能滿足這兩種特點的，只有馬達發電機組與 UPS。前者的調速輪能讓發電機在停止運轉前，還能提供幾秒鐘的電力。不過馬達發電機組多半體積龐大，價格也高，只有中大型的機房才用得起。
而另一種技術 — 稱為 UPS — 就沒有馬達發電機組太貴的缺點，即使停電時間更長也不怕。
8.1.3.2.3.2. 提供幾分鐘的電力
UPS 種類繁多 — 從小到給低階個人電腦提供五分鐘電力，到給整個機房提供超過一小時電力的，應有盡有。
UPS 由以下部份所組成：
轉換開關（transfer switch）可以從主要電源切換到備用電源
電池，提供備用電力
整流器（inverter）能將電池的直流電（DC）轉換為機房設備所需的交流電（AC）
除了大小與電池容量外，UPS 還分成兩種類型：
離線（offline）UPS 只有在主電源失去作用時，才會從整流器開始供電。
線上（online）UPS 會持續從整流器供電，只有當主電源失效時，才會從電池透過整流器供電。
這兩種 UPS 優劣互見。離線 UPS 通常比較便宜，因為整流器不需要一直運作。但平時管理者無法得知整流器是好的還是壞（除非停電，才會發現）。
線上 UPS 則可以為機房提供乾淨穩定的電力，畢竟線上 UPS 是廿四小時提供電源的。
但不管您使用哪一種 UPS，都得仔細計算，選用容量夠大的 UPS（這樣才能確保 UPS 能提供足夠的電壓與電流），「同時」您也要決定，當停電發生時，UPS 能為機房提供多久的電力。
要決定這時間，您得先從 UPS 所提供的負載量著手。先看看機房裡面所有裝置需要多少電力（通常每個裝置的電源接頭旁邊，都會列出這些資訊），寫下伏特數（voltage）、瓦特數（watts）、以及（或）安培數（amps）。有了這些資訊後，換算成「伏安數（VA，Volt-Amps）」。如果您已經有了瓦特數，不妨把這些資訊當成伏安數；如果您只有安培數，把它乘以伏特數，就可以得到伏安數。把所有伏安數加總起來，就是 UPS 所需要的伏安數。
注意
嚴格來說，這些方法算出來的伏安數並不十分準確；不過要得到正確的數據，您得知道每個裝置的電源係數，可是這些數據多半付之闕如。不管怎麼說，先前算出來的數據反映的是最壞狀況，所以用起來安全無虞。
要決定續航時間，那就比較偏商業問題，而非技術問題 — 您打算提供多長時間的防護，又打算投資多少錢？大多數伺服器選擇的續航時間都低於一小時，最多不超過兩小時，因為超過這時間，電池價格不菲。
8.1.3.2.3.3. 提供幾小時（以上）的電力
如果電力服務會中斷好幾天，那麼要付出的代價可就大了。能提供長期電源的，恐怕只有用引擎 — 主要是柴油或汽油引擎 — 驅動的發電機。
注意
千萬記得，使用引擎的發電機運轉時，一定要定期加油。您一定要知道發電機全速運轉時的「燃燒」速率，並確保油料能源源不絕地送到。
到這兒，您的選擇可就多樣化了；如果您的公司夠有錢的話。您不妨找個專家為您的企業把脈，找出最適合的方案。很少系統管理者擁有足夠的知識，知道如何規劃與安裝發電系統。
提示
您可以租用大小不等的可移動式發電機，這樣可以省下購置發電機的大筆費用。但是請記得，當您的所在區域發生大規模災害時，要租到一台發電機可不是容易的事，而且肯定所費不貲。
8.1.3.2.4. 為更長時間的電力中斷擬定計畫
停電五分鐘沒什麼，頂多只是摸黑工作，造成不便；但如果停電長達一小時？五小時？一天？甚至一週呢？
事實上，即使機房可以正常運作，外在環境也會慢慢影響您的組織。考慮以下幾種狀況：
如果控制機房環境因素的裝置缺乏電力，那怎麼辦？
如果控制大樓環境因素的裝置缺乏電力，那怎麼辦？
如果個人工作站、電話系統、以及燈光等都沒電了，那怎麼辦？
重點是，公司可以忍受多少電力不足所帶來的不便？如果公司不能容忍任何停電事件，那麼就要為停電時間，準備隨時可用的電力來源，例如為整棟大樓準備非常大的發電機。
當然，這種等級的計畫不會憑空發生。造成您斷電的原因，也很有可能造成辦公室以外的區域斷電。即使您的辦公室有源源不絕的備用電力，外在世界遲早會影響到您的公司。
8.1.3.3. 暖氣、空調、以及冷氣
目前辦公大樓裡面的暖氣、空調、以及冷氣（合稱HVAC - Heating、Ventilation 與 Air Conditioning）系統多由電腦控制，非常的複雜，以提供人們舒適的工作環境。
機房通常會加裝額外的通風設備，好將許多電腦與相關設備所產生的熱能排出。HVAC 系統如果故障，就會危及機房的正常運作。由於機房的複雜度高，又多是電子機件設備，因此有非常多種故障原因。底下是幾個例子：
通風設備（通常是電子馬達所帶動的風扇）會因為電路負荷過大、軸承問題、皮帶 / 滑輪故障等問題，而失去作用。
冷卻裝置（又叫「冷卻器（chillers）」）會因為冷媒外漏，或是壓縮機與（或）馬達故障，而無法達到冷卻效果。
HVAC 的修理與維護都屬專業領域 — 一般的系統管理者都會把這部份交給專家處理。系統管理者該做的，則是每天檢查 HVAC 裝置是否正常運作（即使不是每天，也要經常檢查），並依照製造商的建議，定期保養維護。
8.1.3.4. 天氣與外在世界的影響
有幾種天氣型態，會給系統管理者帶來麻煩：
大雪與結冰可能會讓空铡?/p>
強風可能會吹斷電力與通訊設施，有些強風甚至會危及建築物本身。
還有些天氣會引起問題，即使有些狀況不是那麼的引人注意亦然。舉例來說，酷熱的天氣會讓冷氣系統超過負荷，整個區域會電力不足，甚至斷電。
雖然面對大自然，我們不能多做些什麼；但知道天氣對機房所帶來的影響，能讓您在天氣轉壞時，及早做準備，好讓機房正常運作下去。
8.1.4. 人為疏失
有人說，電腦「總是」完美的。仔細探究這說法，您就會發現，所有電腦錯誤的背後，都有人為疏失的影子。在本章節裡，我們將與您討論最常見的人為疏失及其影響。
8.1.4.1. 終端使用者的疏失
電腦常因使用者操作錯誤，而造成嚴重的影響。但是受限於作業環境的權限，使用者疏失的影響都侷限在一定的範圍內。使用者通常只會使用電腦上的幾種應用程式，所以會發生問題的地方，多半是這些應用程式。
8.1.4.1.1. 應用程式使用不當
當應用程式使用不當時，會造成幾種問題：
使用者不小心複寫了檔案
使用者輸入到應用程式的資料錯誤
檔案命名或組織不當
使用者意外地刪除了檔案
這清單還可以繼續列下去，但仍不足以涵蓋所有情形。因為使用者缺乏管理者的權限，所以他們犯的錯誤通常僅限於個人檔案。也因此，最好的方法可從兩方面著手：
教育使用者如何妥善使用應用程式，以及管理檔案的正確技巧
定期備份使用者的檔案；並能儘速回復使用者的檔案
除此之外，沒有其他辦法可以將使用者疏失的損害降到最低。
8.1.4.2. 操作人員的疏失
跟一般使用者比起來，操作人員與電腦的聯繫更強更深入。終端使用者發生的錯誤多半與應用程式有關；操作人員則牽連更廣。雖然操作人員所牽涉的動作並非全面性的；但還是可能深及系統內部，如此一來，就會造成嚴重的後果。因此，嚴格要求操作人員遵循既定的程序，才能有效避免他們犯錯。
8.1.4.2.1. 未能遵循程序
每個操作人員手邊都應該有本手冊，詳述每個動作應有的步驟與程序[3]。但即使您已經制定了操作程序，操作人員還是沒有遵循指示。原因可能是：
環境已經改變，但程序沒有被更新。現在環境再度改變，而操作人員只能以記憶行事。結果，即使程序更新（話說回來，上一次沒有更新，這次大概也不會更新），操作人員也不會注意到。
環境改變，但沒有相對應的步驟。這跟前一個情形很像，只是更超出控制。
有正確的標準程序，但操作人員沒有（或無法）遵循這些程序。
根據您公司的管理架構，可能除了跟負責的主管談一談以外，別無他法。但不管怎麼樣，盡您所能的解決問題，可能是最好的方法。
8.1.4.2.2. 在操作步驟中犯錯
即使操作人員依循步驟，即使操作準則是正確的，還是有可能出錯。通常錯誤發生多半是因為操作人員不小心（這時，操作人員的管理問題就浮上檯面了）。
另一個解釋，則是過程中有誤。如果是這種情形，稱職的操作人員應該會發現不對勁，而尋求他人協助。請鼓勵操作人員發現問題時，馬上與相關人員接觸。雖然大部分操作人員技術純熟，能獨立解決問題；但有時候問題牽涉到其他領域，可能一開始問題不大，但卻錯失了最初的黃金時間，讓您無法立即解決問題，也可能危及操作人員的飯碗。
8.1.4.3. 系統管理者的疏失
跟操作人員不同，系統管理者負責管理公司的電腦，工作包羅萬象。同時還有一點不同，那就是系統管理者的操作步驟通常不記載在手冊裡。
因此，系統管理者稍不注意，就有可能犯下錯誤，多繞圈子。在日常操作中，系統管理者能存取所有電腦系統（還有至高無上的管理權限），要不小心讓系統無法運作，有得是機會。
系統管理者可能會因為設定錯誤，或是維護失敗，而導致災難發生。
8.1.4.3.1. 設定錯誤
系統管理者常常要設定電腦系統，包括：
電子郵件
使用者帳號
網路
應用程式
這清單可以繼續寫下去。實際的設定工作大異其趣，有些設定得靠編輯文書檔完成（設定檔的語法起碼有上百種），有些設定則需要特地的設定工具。
這些設定大異其趣，也正反映了每個設定工作需要不同的專業知識，挑戰管理者的能力。舉例來說，設定郵件傳輸代理程式所需的知識，跟設定網路連線的知識，就截然不同。
也因此，我們應該對管理者只犯下「這麼少」錯誤，感到驚訝才是。不管怎麼說，設定一直是，將來也會是，系統管理者的最大挑戰。有沒有什麼辦法，讓這過程不會再出錯誤呢？
8.1.4.3.1.1. 將改變納入控制
管理者應該仔細審視每次設定的改變。雖然改變可大可小；但它依舊是改變，有機會對系統造成威脅。
許多公司都有一定的程序，管理改變的過程。其目的在於幫助系統管理者（以及會受到影響的所有團體）管理整個變更的過程，降低錯誤發生的機率。
把改變納入控制，通常可以分成幾個步驟。以下是個範例：
初期的研究
初期的研究會明確定義：
改變發生的本質
如果改變成功，會有什麼影響
如果改變失敗，有什麼因應的備案
評估可能會發生哪些錯誤
初步研究可能包括設定一段時間，將系統關閉做測試；或是用另外的測試硬體，建立特別的測試環境，然後改變設定看看。
排程
接下來，我們要把眼光移到實際變更的作業上。排程包括改變的順序以及時間（為了避免失敗，排程中應該也包括回溯的順序與時間），還要確保您有足夠的時間變更系統，也不會跟其他的系統活動相衝突。
這個過程的產物是張清單，上面詳列系統管理者準備變更設定的所有步驟。為免更新失敗，每個步驟都該有回溯的方式。通常每個步驟都會附上預估的執行時間，讓系統管理者知道，每個更新步驟是否跟上進度。
執行
到這階段，就要開始實際的安裝作業，整個過程應該直接而平順。如果變更不成功，就應該要回溯到原來的樣子。
監控
不管改變是否完成，系統管理者都該仔細監控整個作業環境，看看每件事情是不是都運作正常。
撰寫文件
如果改變完成，所有的相關文件都該更新，以反映現實狀況。
很顯然，不是改變所有設定都需要這麼仔細。建立新的使用者帳號，就不需要初步的研究；排程方面，只要看管理者有沒有時間建立新帳號即可，執行上應該很快；監控方面，則要確定使用者能使用這帳號；撰寫文件方面，大概只要寫封電子郵件，告知新使用者的主管即可。
但如果改變設定變得非常複雜，就需要更正式的步驟，以管制所有的改變程序。
8.1.4.3.2. 在維護過程中犯了錯誤
因為我們很少會對日常維護工作做計畫或追蹤，因此這類錯誤總是防不勝防。
系統管理者每天都會遇到這類問題，尤其當使用者發誓，他們什麼都沒做過的時候 — 電腦就是壞了。會這麼說的使用者多半不記得他們做過什麼事；當類似的事情降臨到您身上的時候，您同樣什麼都不會記得。
記得，如果要以最快的速度找出問題所在，您一定要記得在日常維護時做了哪些修改。完整地對改變流程做紀錄並不切實際，因為每天可能有上百件事情要做。那系統管理者該怎麼記得這一千零一件小事呢？
答案很簡單 — 隨手寫筆記。不管是記在筆記本上，PDA 上，或是在受影響的檔案上加註解，隨手記下來就對了。只要能追蹤做過哪些事情，就有機會找出與錯誤之間的關聯。
8.1.4.4. 技術人員的疏失
有時候該幫助您，讓系統正常運行的人，反而讓事情變得更糟。這不是某種陰謀論；而是這種倒霉事可能發生在任何專家身上。這種情形也常發生在程式設計師身上：明明解決了一個問題，但反而造成更多的問題。
8.1.4.4.1. 維修不當的硬體
在這種情形下，技術人員可能誤判了問題，做了不必要（或沒有任何用處）的維修動作；抑或診斷正確，卻維修失敗。有時候可能是換上了另一個壞的硬體，或是維修時，沒有遵照正確的指示。
這也是要隨時注意維修人員的原因。如此一來，您可以注意到是不是有其他相關問題應運而生；否則技術人員可能會將其他問題當成新問題，與原來的問題無關。結果，時間都浪費在追尋錯誤問題的解答上。
8.1.4.4.2. 修好一個東西，又弄壞另一樣東西
有時候，即使問題診斷正確，也修理成功，卻又出現了新問題。例如您換了新的處理器，但卻不小心把包裝用的防靜電袋子留在機殼裡，結果影響了散熱，導致系統過熱而當機。或者您換下 RAID 陣列中壞掉的硬碟，卻不小心碰掉另一顆硬碟的接頭，結果陣列還是無法正常運作。
這類事情可能出於長期的漫不經心，也可能是臨時出狀況，但怎麼說都是發生錯誤。您一定要做的，就是嚴格監督技術人員的修理情形，同時確定他們離開前，系統可以正常運作。
注
[1]
這通常是最好的情形，因為技術人員多半從自己的辦公室算起，放射狀地負責一塊區域。如果您正好在這區域的一邊；而技師正好在另一邊，那麼反應時間會更久。
[2]
關於 UPS 技術的詳情，您可以在 第 8.1.3.2.3.2 節中找到。
[3]
如果您的公司沒有這樣的手冊，建議您與操作人員、管理階層、以及使用者，一起製作手冊。沒有這些文件，資料中心將會失去控制，日常運作很有可能會一團混亂。
