論災備之重要性：七場無法預見的數據中心災難
譯文今天要談到的都稱得上是“隨機事件”，而數據中心運維人員將會因它們的出現而徹夜無眠。在慨嘆之余，大家不妨捫心自問，您的災難恢復方案是否足以應對這些罕見的意外狀況?
洪水、火災、太陽耀斑以及四驅汽車造成的車禍：這一切都是數據中心運維人員根本無法想象，但卻能夠切實帶來風險的潛在災難。接下來，我們將一同了解相關情況。
現任OpenStack基金會執行董事的Jonathan Bryce二十多歲時曾是達拉斯沃思堡的Mosso Cloud公司的創始人。令他畢生難忘的是2009年12月18日這家公司所遭受的突發事件。
這次事故源自某位身患糖尿病的司機。他當時在Rackspace數據中心——也就是Mosso業務托管所在位置——附近突然陷入昏迷，他的SUV就直接撞上了該數據中心的電力變壓設備。在車禍出現之后，Mosso的業務仍然能夠正常運轉，但這僅僅是接下來一連串最終導致服務停機的小機率事件的前奏。
我們要如何為這樣一種看似不可能發生的狀況作好災難恢復規劃?“這僅僅是大家需要了解，且確實可能發生的故障根源的其中一種，”Bryce表示。
Robert von Woffradt身為愛荷華州州政府CIO也結合自身發表了看法，該州主要數據中心遭遇意外火災后他在博客當中談論了此事。相信2012年遭遇了由颶風桑迪引發的洪水的下曼哈頓辦公樓群與各醫院也會對此表示認同。
即使大家自認為已經針對地震、洪水與火災作好了萬全的準備，那么我們提醒一句——您有沒有考慮到偶爾出現的太陽耀斑?就在2012年，一次強大的太陽耀斑現象差一點就破壞了地球上的眾多電力傳輸系統。如果這次爆發的出現再早一周，地球將受到直接影響，科羅拉多州大學的Daniel Baker在2014年接受NASA科學新聞采訪時指出。耀斑的影響力將沖破地球大氣層，進而導致意外之外的嚴重輸電線路電壓震蕩。
大家可能會認為這樣的風險離自己非常遙遠，但事實會給我們實實在在的教訓。就在1859年，太陽耀斑的干擾在地球上引發了所謂“卡林頓事件”，電報局所部署的線路由于電壓瞬間增高而全面失控，一些辦公室甚至直接起火。
親身經歷過災難事態的CIO與數據中心管理者們紛紛指出，大家所能拿出的***應對措施就是提前做好準備。“至少每年對系統進行一次全面崩潰測試。不要相信什么模擬結果，直接將其離線，”Wolffradt在愛荷華州政府遭遇火災危機后所發表的一篇博客中建議道。
下面我們就一同來看實際發生過的各類數據中心災難事故——其中一些非常可怕，另一些則有些匪夷所思——當然，也歡迎大家在評論欄中分享您自己的災難應對故事。
#p#
愛荷華州火災
2014年2月18日下午，當時愛荷華州政府正像平常一樣組織生產生活——但其主數據中心突然爆發電氣火災。考慮到當地天氣預報的提醒，IT運維團隊當時正在積極準備應對當晚可能出現的暴雪天氣，因此火災的發生簡直令人始料未及，愛荷華州政府CIO Robert von Wolffradt在2014年3月25日發布在GovTech.com網站上的一篇博文中回憶道。
火災警報出現在當天下午3點鐘，數據中心陷入電力中斷狀態，建筑物內濃煙四起，工作人員則開始快速撤離。警報觸發了數據中心內的FM-200煙感滅火系統，好在噴淋的及時起效將火災范圍控制在了設施中的瞬態電壓抑制箱內部(如上圖所示)。作為數據中心內的電流控制裝置，這套電壓抑制單元由于過熱而熔化。州政府的公共服務小組立即開始構建備用線路，而電力也在幾個小時之后得以恢復。
隨著電力傳輸再度起效，數據中心內的門扉、風扇以及換氣裝置開始重新工作，不過警方及消防人員仍然要求IT工作人員待在大樓之外。直到事發后的三個半小時，州政府方面才確定數據中心已經適合工作人員進入。
Wolffradt必須快速決定如何采取進一步處理措施，而與市民、供應商以及員工工資相關的開銷損失很可能高達1.62億美元。工作人員迅速對數據中心進行了殘留清理，而IT團隊則在當天晚9點恢復了存儲區域網絡、防火墻與網絡核心。快速恢復現有功能意味著整套設施面臨著沒有瞬態電壓抑制單元的保護。但Wolffradt仍然決心以再次上線為***要務，不過他手上還有備用數據中心作為***的底牌。
到當晚11點，其它額外系統也開始陸續上線，其中包括服務咨詢臺以及暴風雪即將到來前各橋梁及高速公路必不可少的交管監控攝像頭。
一同得到恢復的還有財務系統與各虛擬化應用程序。其它系統在當天夜間依次恢復正常，到第二天晚上備用數據中心將接管州政府的各項處理任務。“當天晚上，我們兩度利用國土安全體系中的語音通知系統向各部門負責人及核心工作團隊通報***動向，”Wolffradt回憶道。他同時指出，當時關于數據中心發生火災的種種謠言可謂甚囂塵上，而他作為CIO則必須頻繁與其它各責任方進行溝通。在事件發生后，他甚至需要親自向州長及其他州政府官員匯報重要信息。
Wolffradt在他的博客當中分享了這樣一條關鍵性教訓：一定要將各大型企業系統彼此分離，例如將電子郵件系統安置在獨立的設施當中。另外，在火災當中，公共服務與人力資源部門“是***的朋友”，他們將幫助大家完成各項后續任務。恢復運作的***障礙是說服警方及消防人員允許IT團隊重新進入數據中心，他在博文中寫道。數據中心所在的建筑物中共有上千名政府工作人員，其中大部分都是在IT團隊重返現場的很長一段時間后才再次回歸工作崗位的。
三星火災
不，這不是三星公司的什么新型智能手機代號——就是字面的意思，三星，著火了。
2014年4月20日，一場大火侵襲了三星公司位于韓國果川的辦公大樓。大火從三星SDS數據中心所在的建筑物開始燃起。至頂網韓國分站的作者Jaehwan Cho在他的Twitter上發布了從韓國聯合通訊社獲取到的圖片資料，可以看到濃煙與火光正從大樓的一側噴涌而出，猛烈的熱流挾帶著燃燒殘片一同掉落在樓體外部。
根據Data Center Knowledge網站的報道，三星公司的IT人員及該建筑物內的其他人員被快速疏散，過程中只有一位員工因被墜落的碎片劃傷而掛彩。
這場火災給眾多三星設備用戶造成了影響，相當一部分智能手機、平板設備以及智能電視用戶無法正常進行數據檢索。在為期數小時的整個過程中，設備用戶始終無法正常訪問相關內容，直到果川備用數據中心的恢復系統起效后一切才重歸正常。三星官方在一篇博文當中就此作出了道歉。
#p#
關注管線檢查工作
2009年7月3日西雅圖費舍爾廣場的電氣室發生了火災，這直接導致Authorize.net支付門戶、微軟必應旅游服務、Geocaching.com服務、Dotster域名注冊服務以及Web托管供應商AdHost等數十個站點瞬間陷入癱瘓。直到第二天早晨，電力供應才得以恢復。
根據《普吉特海灣商業雜志》的報道，Geocaching與AdHost兩個網站分別于次日上午10點重新上線，而其它各服務的恢復過程則更為漫長。此次火災顯然始于傳輸線纜管線(如上圖所示)，而據該雜志的估算，此次費舍爾廣場用于維修及更換設備的成本大約為1000萬美元。
颶風桑迪引發發電機故障
與東海岸類似，2012年10月底肆虐一時的颶風桑迪在陸續襲擊了弗吉尼亞州、特拉華州、馬里蘭州以及新澤西州后最終將矛頭指向了曼哈頓。伴隨著一波猛烈的海水潮涌之后，巨浪撲上紐約市頭并導致下曼哈頓地區的多家站點陷入癱瘓。
位于下曼哈頓75街區的Peer 1托管設施因此成為災難恢復工作人員的噩夢。雖然該棟建筑物的十八層擺放有用于持續提供電力且不至于受到洪水影響的多臺備用發電機，但風暴來襲時直接灌滿了該建筑物的地下室，并且摧毀了應急發電機的燃油泵送系統。一旦遭到海水浸泡，整套電路立刻失去了作用。(考慮到911事件，紐約地區要求各辦公樓管理方控制樓內所儲存的燃油量)。因此，發電機只能依靠非常有限的一點燃料強行啟動，而工作人員根本沒辦法為其提供充足的補給。Peer 1建議客戶以數小時為周期實施系統關閉計劃，并排遣幾名員工到現場幫忙以防止出現數據丟失狀況。
為了避免系統停機，Peer 1的工程技術團隊決定扛起水桶為樓上的發電機輸送燃油供給。燃油被運抵街區后，再以人力方式被慢慢抬上十七層——那里正是發電機的油箱所在，負責為樓上的發電機提供動力來源。Peer 1公司的托管服務客戶們——其中包括網站開發企業SquareSpace以及在線項目管理供應商Fog Creek軟件公司——組織起由25位員工構成的隊伍，幫助現場人員進行燃油輸送。從10月30日晚到10月31日晚，他們一刻不停地承擔起了原本應由泵機完成的工作。
到10月31號的午飯時間，他們已經順利加滿了油箱并終于能夠休息一會兒。為了吃上午飯，他們需要徒步走過布魯克林橋——因為當時曼哈頓街道已經被徹底堵死了。很明顯，在Peer 1的災難恢復規劃中既沒有人力送油方案，也不包含徒步就餐計劃，但正是在這些奮戰在現場的工作人員的努力之下、系統并沒有因為颶風的肆虐而陷入停機。
#p#
一輛SUV引發的慘劇
Rackspace公司的主機托管業務及由其承載的Mosso Cloud運行在位于達拉斯的同一座數據中心內部，但2007年11月13日一場無妄之災使其在數小時內陷入了癱瘓。
一位大型四驅車司機——同時也是一位糖尿病患者——由于病發而出現短暫昏迷。他沒能正常轉向鄰近的街道，而是一路向前直沖，并從丁字路口處奔向路邊外側的護堤。護提這樣的斜坡令瘋狂突進的SUV越過一排停放的車輛而沖向空中，并在落地時撞上了一棟容納著Rackspace基礎設施供電裝置的建筑物——一陣火光帶閃電之后，電力供應中斷了。
由于需要切換至備用供電線路，這棟建筑物的冷卻系統出現了暫時性停頓。不過業務運作過程并沒有被打斷，因為這套計算設備能夠在遭遇此類緊急情況下利用應急電池繼續工作。該設施的工作人員立即通過重啟規程幫助該建筑物的冷卻機制重新運轉，而緊急處理人員則努力將闖入的車輛清理出去并接入新的電力變壓裝置、關閉設施的全部供電體系并從輔助供電裝置切換回主供電裝置。
在其災難恢復規劃當中，電池電源與應急發電機再次立下大功。數據中心到這時仍沒有發生運行中斷現象，事故只不過讓供電網絡的運轉功率有所下降。不過冷卻系統中的大型水冷機組在分步重啟過程中出現了問題。其在重啟中再度陷入癱瘓，而且工作人員發現已經沒辦法在不進行深入排查之前讓其重新恢復工作。
Rackspace公司總裁Lew Moorman在事故之后的一篇博文當中提到，“兩套冷卻機組無法重新啟動，這使得數據中心出現了過熱。”由計算設備產生的熱量足以使現場氣溫急劇上升，而Rackspace公司的現場管理人員決定“分階段關閉設備以***程度降低硬件受損”與客戶數據丟失的可能性。
這次中斷一直持續到當天晚間10點50分，也就是事故發生后的五個小時。軟件即服務供應商37signals——Rackspace托管下的企業客戶之一——向客戶發布了評論意見：“這次接連出現的意外事件擊垮了我們為數據中心建立的復雜備份系統。我們將努力工作，從而進一步對系統加以分散，并最終得以應對此類極為罕見的外來因素所導致的停機事故。”除了增加客戶流失的風險之外，據報道稱Rackspace公司還為此次事故向客戶支付了350萬美元賠償金。
焊接工作惹麻煩
2015年1月9號，一座將被作為Amazon.com數據中心的大型建筑物發生火災，起因則是一名焊工不慎點燃了現場的建筑材料。此次火災觸發了弗吉尼亞州阿什本當地的三級警報。濃烈的黑煙在幾英里之外都清晰可見。Amazon公司發言人在接受當地ABC新聞媒體采訪時指出，此次火災造成了大約10萬美元損失，但同時補充稱“并沒有對Amazon業務運營帶來任何影響”——因為當時該數據中心尚未投入使用。
#p#
太陽風暴
也許洪水、火災以及車禍已經足夠令人頭痛了，但真正可惜且避無可避的還是要數太陽風暴侵襲地球大氣層這類大事件。太陽耀斑有時候會引發所謂的太陽風暴，在這種情況下太陽表面的日冕物質會由于劇烈活動而沿爆發前的軌跡被直接拋射出去。
這種案例確實非常罕見，但一旦真正發生，太陽表面濺出的物質會沖破太空直接向四面八方砸去。而當這些帶電粒子接近地球大氣層時，極高的前進速度會創造出強大的磁力空間。在此空間內，導電材料會自動產生電流——正如通電線纜一樣。而管線及電話系統這類長度可觀的導體甚至會迎來巨大的瞬態電壓。
這種威脅確實是真實存在的，倫敦的Lloyds網站甚至專門發布過一篇《太陽風暴或將威脅北美電網》的風險評估報告。
根據這篇報告所言：“電網體系可靠性的一大威脅正源自地磁風暴——而這會由太陽風暴在大氣層上方快速通過而引發。……由此帶來的過載電壓將使電網系統陷入崩潰，更糟糕的是，昂貴的超高壓變壓器亦有可能因此而發生大規模損壞。”
1989年，這樣的風暴就直接襲擊了加拿大，瞬態電壓升高導致魁北克省的水電電網變壓器出現損壞。據估計，這次事件造成的破壞相較于1859年美國的太陽風暴災害還算比較輕微——當初被稱為“卡林頓事件”的耀斑活動直接導致美國多位報務員遭受電擊，另有幾處電報局發生火災。1989年的這場事故直接觸發了東北電力協調委員會及中大西洋地區委員會所布設的斷路器及過載保護設備，如果不是這樣、美國的整體電網幾乎全面遭到毀滅。新澤西州的一處核電站就在升壓變壓器發生損壞后被迫切斷了與電網間的傳輸通道。
再把目光投向近期，2012年太陽風暴曾與地球公轉軌道相交于一點——或者說幾乎相交于一點。此次風暴在地球抵達前九天剛剛通過，從天體規模來看這樣的微小間隙簡直稱得上險過剃頭。
總結陳詞
前面提到的各類場景確實讓人始料未及，而且即使是身經百戰的數據中心運維人員也沒把握將其妥善解決。不過好消息是，相關企業機構快速公布了其恢復方案，且足以成為我們在規劃未來災難恢復機制時的寶貴借鑒。
大家有沒有親身經歷了這類堪稱挑戰想象力的特殊事件?而處理過此類災難恢復工作的您又有什么經驗愿意與大家共享?另外，您心目中最恐怖的災難噩夢是怎樣的?請在評論欄中留下您的真知灼見。
原文標題：7 Data Center Disasters You'll Never See Coming
