https://newera17031.activehosted.com/index.php?action=social&chash=19de10adbaa1b2ee13f77f679fa1483a.2906&nosocial=1
https://newera17031.activehosted.com/index.php?action=social&chash=19de10adbaa1b2ee13f77f679fa1483a.2906&nosocial=1

觀點

災害發生時,您準備好了嗎?

2007 / 11 / 19
MICHAEL YBARRA
災害發生時,您準備好了嗎?

House of LaRose是位於俄亥俄州Brecksville市的一家飲料經銷商,在幾年前的除夕應該是個歡樂的地方。這個家族經營的中型企業剛剛搬進美金3千萬的30萬平方英呎的工作地點,並擁有Oracle 10g資料庫運行的尖端倉庫管理系統,這個管理系統協助卡車車隊一天運送遍及全州的成千上萬個飲料容器,一年1千2百萬個。後來公司Novell NetWare系統的主機板燒掉了,引起一連串的伺服器故障,造成業務上的停頓。LaRose公司在美國的飲料經銷商中擁有比同業更尖端的IT環境,但它卻沒有災害復原(DR)或企業永續經營(BC)計畫。
IT管理者Dan Brinegar打電話給Novell公司,該公司說要花3天的時間才有新的主機板。因此他就打給俄亥俄州附近的公司找到可以借用的備品,讓他的公司可以在數小時內回復上線。
「這可真是個警訊」Brinegar說。「ERP系統一停機,整個公司就會突然停止運轉。」
災害復原過去一向都只留給大企業,但在日漸增多的24小時提供服務的商業領域中,越來越多的中型企業也漸漸地瞭解到,如果停止運轉他們就無法提供服務。應用系統對高可用度(HA)的要求一直都在成長。市場調查研究機構(Forrester Research)估計在過去5年裡,企業對關鍵的營運資料庫應用系統的數量呈倍數的成長。然而,仍有許多企業未準備妥當。Gartner的調查中發現,中型企業及大型企業大部分的停頓,都是因為自認完善但不夠標準的災害復原計畫。
「你的生意和你資料的完整一樣」,一位在美國田納西州富蘭克林市的中型電子製造商(Telco Solutions)負責災害復原業務部經理Ricky Bajaj說。為了要保護它的資料,Telco公司最近全面大修它的企業永續經營/災害復原(BC/DR)策略,決定將這項功能委外,委外在中型企業中是很常見的解決辦法。
越來越多的公司沒有選擇的餘地。公開上市公司面臨沙氏法案(SOX)的命令要對資料做保留,然而,在同業中的私人公司,它們就不像酒業及金融業必須要符合政府的紀錄保存及服務的永續性規定。
「即使當規定沒有明確地命令執行BC/DR規劃時,監管機構要求公司企業都要遵從他們對資訊的稽核和要求,不管是什麼!」Forrester分析師R?diger Krojnewski和Bill Nagel在最近的一篇名為「規劃你的下一個災害」報導中提到。「起因於災害或是其他營運上的中斷都不能做為無法達到這樣要求的藉口,更糟的是管理者可能會因無力從災害中復原所暴露的不遵從而被處以罰金。」
Forrester估計自911恐怖攻擊以來,已經實施高可用度(HA)及DR解決辦法的大型企業數量成長已超過50%了。儘管DR計畫對資源被困住的中型企業而言可能更具挑戰性,但仍然有基本的規則可遵循以擔保及時的復原及最高的連續性。
這有個編制DR/BC計畫的指南。
*評估
第一步是藉由實施營運衝擊分析(BIA),針對IT及整個企業所面臨的弱點再做詳細檢查。什麼是可能的威脅(停電、天災、恐怖主義)以及就損失收入、生產力和名聲而言什麼是可能的後果呢?哪些系統是不可或缺的?哪些又是非關鍵的呢?辨認在特定的區域可能盛行的威脅將可協助確定資料中心的位置、資料中心地點的間隔,以及DR最有成本效益的技術。建立容許完全恢復正常運作的時間─復原時間目標(RTOs),以及就時間上而論資料損失可容許的數量─復原點目標(RPOs)。
Gartner分析家Donna Scott說營運衝擊分析(BIA)需要一項存在於營運和技術之間共同的企劃。「你必須瞭解什麼是在你營運中最關鍵的,也是你必須去保護的,」她說。「你必須真正地瞭解你的營運。IT是無法自行做到。」
她提到營運衝擊分析(BIA)是不同於安全評估。BIA集中於評估營運流程的重點性以及評估所使用的應用系統,以及當一段時間無法取得應用系統和基礎設施做變化時的衝擊。
有時還真是需要一個真實的災害來喚醒一家公司。幾年前當颶風Rita正朝著休斯頓時,LifeGift Organ Donation Center公司實行它的DR計畫:IT人員將設備裝載上卡車運到達拉斯去。管理階層瞭解到需要一個更好的計畫,因此與位在達拉斯的IT服務公司CompuCom簽約接管DR規劃。
CompuCom公司的解決方案架構師Charley Ballmer替LifeGift公司設計了BIA,評估颶風及水災氾濫為最有可能的災害,其次是地方石油業的恐怖攻擊。BIA將LifeGift公司最重要的營運流程列為器官追蹤和病患溝通,並且為這些應用系統建立了15分鐘的RTO,然而會計方面卻給了24小時的故障復原的時間。
「當他們進入到DR模式時(在Rita颶風期間)他們的計畫都成為泡影了,」Ballmer說,並指出一個更大的災害可能造成公司無可挽回的後果。「他們沒有做硬體和策略上的投資。」
現在CompuCom 從它自己的操作中心管理LifeGift 的IT環境,遵守ITIL的規範,並且每六個月徹底地測試DR的故障復原系統。Ballmer又說LifeGift公司已準備好要安然度過一場大的暴風雨,而且僅受到最小的服務中斷。

*明確定義
建立起實際且具體的營運復原目標。復原時間以及復原點目標這些要求必須在談及風險報酬時明確的規定。也就是說,企業真正需要保護到什麼樣的程度,而又要為此付出多少代價?CIO必須採取有組織的有條理的方法,利用刊載的方法論包含ITIL、COBIT、ISO 17799和27001用以明確定義風險、威脅以及控制方法。
但實際上定義企業需要多麼健全的DR計畫是商業決策。Forrester的Krojnewskig說董事有時候會要求不切實際的或是過度昂貴的永續性。而這時IT就必須提供對現實狀況的檢視。
「問題的關鍵是IT和企業的人沒有共通的語言,」他說。「挑戰者的角色必須是個內部IT人員。你願意為預防措施付出多少錢?金錢的範圍完全是商業決策。」
CIO應該要用文件詳細記錄依重要性等級安排的營運流程,通常在一到五級。面對用戶及合作夥伴的應用系統很容易分為一個層次的重要性,當後援辦公室作業的重要性式微時。有些應用系統因為它們與重要系統的互動方式,可能需要被提升其重要性。
當Chris Formes成為一家美金8億8千8百萬美元的公開上市公司(Brookfield Homes)的IT經理時,因為這公司沒有DR計畫,所以他就聘用了承包商來作威脅評估,並且設計一項復原策略。以最高標準的故障復原連續性,這項計畫需求20萬美元的硬體投資以及第一年9萬美元的服務費用。「我認為適當的擁有計畫是很重要的,」他說。「但當我看到這數字與公司的總裁坐下來談後,發現我們做的事似乎不怎麼合理,萬一像地震這樣的災害,反正我們也都無法做事。」
相反地,位在加州的Del Mar 公司選擇8小時的RPO和磁帶備份配合,聘請位在亞歷桑那州的Insight Enterprise公司利用磁帶系統每小時對儲存區域網路(SAN)進行快照。這家公司也推出Mimosa系統的NearPoint email解決方案把它的Microsoft Exchange server的資料存檔。企業營運持續性的費用下降了到一個月1,200美金。
「DR只不過是一張保險單,」Formes說。「它既是風險也是補償。在我們的案例中它不值得冒險(就整體的企業營運持續性而言)。我們並未損失任何的收入。我們可能會受到阻礙,但是家園的建設程序是不會停止的。」

*更新
營運不停地在改變,因此任何的DR/BC計畫也得跟著改變。為了確保IT的基礎設施變化不會使計劃變得失去作用,因此定期檢查是必要的。這計畫有涵蓋到新的業務種類嗎?被中斷的服務已從DR情況中消除了嗎?
企業的領導者及IT需要定期的相互諮商以保持事情的更新。他們理應每年都要重新檢視現有的技術,及不管什麼時候採用的新技術。週期性地再視察威脅評估-威脅和它們潛在的影響。災害復原應該被視為變更管理的一部分,Krojnewski說。在LifeGift公司隨著技術的變更而更新DR計畫是件容易的事,而且這家公司對於CompuCom公司的IT可以委外也感到很滿意。
「災害復原變得只占計劃投資的7%或8%而已,」已成為公司的CIO的Ballmer說。「我們做到比他們(業務主管)預期的花費還要低的金額,並且縮短了復原時間目標。」

*確保買進
獲得你希望從來就不需要用的預算可能有點難。DR可能有點貴而且也不會帶來收入。投資報酬率(ROI)可能很難估計。
IT應該要提供建議和執行計畫,但是DR整體的責任必須由各業務主管(LoB)負起。CIO應該證明DR投資是有理的,好讓LoBs可以爭取預算。要用數字來測量DR可能會有困難,但是在測試期間IT至少應該要測量任何一個解決方案的有效性。Krojnewski建議要讓BC/DR準備的階段性變化明確,並且測量花費在每一階段性變化占經營成本的百分比。建立標準的BC/DR服務等級,並且測量經由服務的災害復原花費占經營成本的百分比。每隔一年就評估這些服務等級的技術。
「買進在那些業務主管了解他們必須倚靠IT的公司裡變成更容易了,」Krojnewski說。「但就是有些公司跟IT的關係處不好,就很難得到DR預算上的資助。IT被視為是個成本中心,很難讓業務主管對DR有興趣,除非他們被管理的單位逼迫。」
在LaRose,Brinegar 在那次除夕機器中斷運行之後,他跑去找管理階層然後爭取到一項DR計畫。
「這兩天可以做的我們都準備好了,」Brinegar說。「只有6個小時,但是(管理部門)給了我一張支票,因此我可以做我所需要做的。我的職責就是「查看會發生什麼事而我們又將會損失多少錢。」這是我頭一次在還未離開辦公室之前就被告知說「買吧!」。通常都需要數個月的爭論且未決。管理部門已明瞭到我們是非常脆弱的。」

*公司自建或委外?
一旦計畫到位時,其中最重要的決定就是IT是否具有專業知識和資源可以實施該項計畫,或是有無必要尋求外部的援助。Forrester指出接受查訪的大部分企業瞭解到DR的執行會是個挑戰,比預期需要更多的功夫,在12個月中最少一次對意外的中斷有經驗。Gartner公司的Scott說只有四分之一到三分之一的大型企業委外DR,然而卻有四分之三的中型企業委外DR。
「也許投資發展完善的計畫是很沒意義的」Scott說。「何時風險會變得很高呢?對於中型企業而言委外是相當吸引人的。你可以降低整體的成本還可以保護你的生意。」
如果決策是要尋求援助,那麼考慮使用系統整合商或更完善的外包商。一些公司與更好的搭擋合作,而其他公司則是使用RFI/RFP程序。
在Telco Solutions的Bajaj說公司的決策很明顯的是要從自做磁帶備份轉換成委外DR。公司聘請位在多倫多的管理服務供應商Asigra。
「這是不必花腦筋理解的事情,」Bajaj說。「讓我們把焦點放在我們的核心競爭力。我們是個製造商,我們的競爭力不是IT。我們要做我們在行的事。當我可以以成本的50%委外時,我不想要支付6、7萬美金雇用人去管理這東西。我可不想要依靠一位員工;我寧可仰賴一家公司。」

*演練
演練具有某些風險-需要計畫的停機時間和可能的營運後果。但不演練更是危險。有效的DR需要每年徹底的演練,以及演練在任何變化之後對計畫的影響。確保故障復原情況在你需要它時,真的可派上用場。
不僅是技術,步驟也是需要排練,如此一來如果遇到真實的災害大家才知道要怎麼做。
「公司演練做的不夠,」Scott說。「如果你不演練那麼你就沒有方法;你會有安全的假象。」

Michael Ybarra是《CIO Decisions》雜誌資深的專題作家。