**高有效性的設計者與管理者要面對的不是有效性的時候, 而是失效的時候才是真正的戰場, 當然這個失效的程度有很多種層級, 從最簡單的只須要簡單的 Bug Fixed, 或 Trouble Shoting 就可以了, 最糟糕的就是災難的發生, 這個災難有可能是實體的, 也可能是虛擬的.
既然有效性的確保是 24hrs 的, 代表一個負責高有效性的人很有可能也要 24hrs 待命 Standby, 這看起來很可怕, 但做得好的話出事的狀況也沒這麼多, 且通常也有第一線的網管人員先行處理後, 才會輪到系統設計人員, 只是要做得好, 相對的心態本身也該是 24hrs 才對.**
雖然說能夠處理到所有的情境 Scenario 都沒問題, 但這個所有是不可能達到的, 因此有時多做幾個環節的話就不太會有問題, 尤其是機制本身的 Fault Tolrance 夠好的話, 備援機制夠完整, 只要確保幾個問題, 就很難會遇到緊急處理的機會.
系統會出問題是必然, 當然有時真的會有機瘟的現像, 就像是我們做 RAID 1 時也是確保當一顆硬碟掛掉時沒問題, 但有時屋漏偏逢連夜雨, 我也遇過兩次同時壞掉兩顆硬碟過, 一次是真的很麻煩, 另一次當時就學乖了, 雖然還是 Download 了, 但幸而有在做備份, 只要復原就好.
但有些系統說要保證同時有兩個以上出問題還能夠正常運作的成本是很高的, 我們往往都只會在資源有限下設計在一個機器或環節出問題還能夠保持運作, 若有相關聯的第二套系統出問題往往就會有問題, 或者是動用到備份了, 因為要做雙 Redundance 是很麻煩的及昂貴的, 甚至是整個邏輯是不一樣的.
當然這邊所說的災害 Disaster, 絕不是只是硬碟或一台機器的問題, 而是一整個機房, 或是一棟房子, 甚至是一個城市, 一個國家的問題, 有時我們也會說, 若真的國家出問題, 很多系統就不用玩了, 但若這是個跨國產業鏈, 事情也沒那麼簡單.
的確在災害的保障下, 我們會有要求異地備份的距離, 雖然距離越遠會須要更高的管理成本, 甚至在系統邏輯設計上說要做到完全的 Redundance, 完全的 Load Balance, 完全的 Fault Tolance 或 Fail Over 是不太可能的, 但啟動備援機制在一定的 Downtime 復原是可以做到或可以在一定資源限制被要求的, 這也是要做到的災害管理.
只是這個災害也未必是天災, 有可能是安全性被入侵, 或者個 BI 企業智慧有有很重大的缺陷所造成, 但身為一個 IT Director 或顧問本來就應該在此時站出來做災害管理, 甚至經驗的差異是在這邊, 利用限有的工具去完成災害的復原是最直接的, 畢竟想要找出 Solution 或規劃或引進設備技術去復原是往往緩不濟急的.
所以要去試想:
這些都不是不可能遇到的, 而我們要該如何去做回應, 有時說不定是深呼吸是該要做的第一件事.