(2)
應用服務相依性關係沒有隨時
維護更新，導致服務啟動異常，
除錯時間將導致評估誤差。
(3)
根據
IDC Report
統計，
80%
以上的服務中斷問題來自人為
疏失，可想而知人為操作可能
帶來的
RTO
時間誤差機率有多
高，這是個非常關鍵且最難掌握
的誤差因素。
3.
應用服務等級與
RPO
、
RTO
關聯，
您定義了嗎？
企業考量
RPO
、
RTO
時間不建
議採用統一的標準評估方式，建議將
服務區分關鍵應用與非關鍵應用等
級，並依據各等級決定其可容許之
RPO
、
RTO
時間，以便適切降低總體
建置及維運成本。
4.
備援中心是否應具備與主營運中心
相同的服務能量水平？
因各行各業服務型態及企業文化
不同，對備援中心的服務能力要求自
然不同，故建議管理者在上述的大前
提下，仍能將服務區分關鍵應用與非
關鍵應用等級，並依據各等級決定其
服務轉移至備援中心時，是否仍需維
持與主中心相同的運算能力，以降低
總體建置及維運成本。
5.
備援中心建立在哪比較適當呢？
台灣地形多為斷層，備援中心設
置地點及距離的選擇相形重要，但並
非本篇主要探討內容，故筆者在此僅
提醒，不再多做說明。
二、跟傳統備援計畫說
Bye-Bye
備援計畫一直是各企業
IT
面臨的
困擾，演練計畫更是大家最不願意碰
觸的議題，故很多
IT
人員一旦快要碰
觸到此議題都會自然失憶⋯哈哈。
為甚麼大家這麼不想碰？這就得
從傳統備援計畫帶來的挑戰說起。誠
如圖一範例所示，各式應用程式、資
料庫、作業系統都有其特有的備份
/
備援方式及架構，若應用服務搭配不
同儲存，那變化就更多了。就算最後
搭配第
3
方備份
/
備援軟體也不見得
能將所有應用服務囊括統一管理並制
定備援計畫。
整體備援計畫將因上述各個因
素，導致必需思考的環節及應用服務
關聯性變得更為複雜，另外由於技術
複雜，更需要搭配專業的技術人員來
完成設定，無論在人員培訓或維護管
理上都是一大難題。
一旦真實災難發生，備援切換成
功率又是多少？相信大多數企業都有
建立備援中心，也相信大家對以下媒
體常常報導的類似對話並不陌生：『某
某企業系統發生問題，備援計畫啟動
失敗，經過多日搶修後系統終於恢復
上線』。
傳統備援計畫在傳統環境就已經
是
IT
管理員的困擾，更遑論企業內部
若已採用雲端
/
虛擬化環境。
建議已經部建雲端
/
虛擬化環境
的企業審慎評估，是否應當適時與傳
統備援技術說
Bye-Bye
，
並轉而採用
專為雲端
/
虛擬環境量身打造的備援
技術
(
台語：打斷手腳重練反而勇
)
。
013
Technology Forum 2015
雲端
資料
BYOD
與資
網路