適當時間的計劃停機其實可以讓你免遭損失。除非你絕對少不了，否則別信需要7*24、隨時可用的服務這套論調。
問一下自己：當你宣布（或請求）停機窗口，以便完成升級或進行維護時，你那些用戶會有啥反應？我想情況恐怕不妙。
多年前，在除了超大型IT部門外的所有環境，計劃停機還是一件很平常的事；而如今，很少有企業輕易讓你申請到很長的停機窗口。哪怕在凌晨時分這樣的時間段，連明顯不需要7*24服務的一些部門（比如三班倒的制造工廠或者設有急診室的醫院）都很難拒絕自己的用戶訪問數據。
其中的原因有多方面，但是說穿了還是日常業務過于依賴IT系統——而服務器虛擬化技術的出現，在很大程度上大大改進了規避災難的能力。公司企業對數據入了迷、上了癮；而技術取得了長足進展，以至于我們IT人士輕易就能滿足他們這個“癮”。
遺憾的是，這種情況帶來了雙重影響：它造就了一種氛圍，即連針對計劃停機再小的請求都常常被拒絕或被推遲；當災難發生時，用戶們毫無準備、束手無策。
停機的三個好處
首先，停機對于確保系統的穩健性和可靠性大有幫助。如果你得等上數周、乃至數月才能為基礎架構打上重要補丁，這無異于自招麻煩。雖然現代化IT基礎架構中的系統大多基本上不用停機就可以打上補丁，但是對于另一些系統而言，要打上最新版本，你就得關掉電源，因而給至少幾個用戶帶來不便。
就拿你那些普通的交換機和路由器來說吧。它們常常一放就是好多年，順暢無阻地運行。實際上，我在上一周碰到的一只桌面級匯聚交換機其正常運行時間超過了2000天。這足以那家廠商的產品確實很可靠，但是我可以打賭：這個設備的固件里面存在很大的安全漏洞——大得好幾輛小車都能通過，很容易被人鉆空子。
其次，如果能充分利用計劃停機窗口，你就能檢驗高可用性功能、演練災難恢復計劃。要是你很少檢驗自己的高可用性或災難恢復功能，那么當你真正需要這些功能時，它們失靈的可能性就要大得多。我在去年寫過一篇博文，當時有位讀者的留言可謂是一針見血：“任何功能要是每天使用不到一次，那么每當你使用它時，別指望它每次都行。你使用它的次數越少，當你實際使用時，它失靈的可能性就越大。”憑本人的經驗，這句話再對不過了。
你知道自己的高可用性系統應該如何工作，但是你確信它們會正常工作嗎？你有沒有使用冗余交換機的光纖通道存儲區域網（SAN）？有沒有使用冗余的核心網絡交換機或數據庫集群？你是否讓我可以不用提醒廣大用戶，就在工作時間段關閉其中一個系統呢？
如果你反對，這表明你根本就不夠確信。只有在計劃停機窗口期間有意關掉基礎架構的冗余部分，你才能夠確信自己的高可用性系統會按原本的方式正常工作。要不然，你就會搞清楚：要是自己有時間或預算，應該把精力主要投入在哪個環節，以求改進。
最后但可能也是最重要的一點是，計劃停機讓廣大用戶多多少少體會了萬一真的發生災難，會出現什么樣的情況。在我親眼目睹的幾起非常嚴重的基礎架構停運事件中，最糟糕的情況莫過于用戶們一片茫然、不知所措。是的，關鍵業務系統的停運會影響生產力，這是完全可以料到的；但你會驚訝地發現，只要采取異常簡單的措施，其實原本可以避免許多最嚴重的影響。要是你不偶爾關閉系統，看看會發生什么情況，也許永遠也不知道那些措施。
據理力爭
雖然給廣大用戶帶來不必要的麻煩看起來像是沒事找事，但是如果有充足的理由，關掉基礎架構的一部分還是能給企業帶來實實在在的好處。嚴酷的現實是，對計劃停機請求堅決說不的企業終究會發現自己遭到非計劃停機，由于災難恢復機制未經考驗，結果蒙受的損失要大得多，而廣大用戶對無法訪問數據的日子又毫無準備。盡管據理力爭讓人不悅，但是下一次你的停機請求遭到反對時，你還是要竭力搬出這個理由。這么做也許不招人待見，但是總比不這么做要強得多。
京公網安備 11010502049343號