fbpx

Amazon 服務中斷與業務復原

| monitoring, 雲端, AWS

amazon-outage-business-recovery-strategy

Amazon Web Services 的簡易儲存服務 (Simple Storage Service, S3) 經常發生故障中斷,正因如此,您需要備妥業務復原策略。

您必須能夠隨時隨地使用您需要的資料,這是維持業務運作的關鍵。那麼,倘若 AWS 或任何其他類似的雲端服務因故障而中斷,您的業務策略是什麼?Amazon 以能夠讓您隨時隨地取得您需要的資料為傲。而他們自豪的點在於,即使服務中斷,您仍然有辦法取得資料。舉例來說,Amazon 不久前宣稱他們從來沒有失去過整個資料中心。這種情況至少可以說非常罕見,不過,先不論 Amazon 所言是否完全屬實,至少他們仍然備妥了防故障機制,能夠因應整個大型資料中心出現故障的情況。

最近一次發生此類事故的時間點,是在 2017 年 2 月 28 日。當時,Amazon Web Services 的簡易儲存服務 (S3) 發生故障中斷,影響了整個網際網路的網站,許多企業此時才猛然警覺「雲端只不過是別人的電腦」。正因如此,您需要備妥業務復原策略。

若企業的網站受到波及,等於損失網站停擺期間的銷售業績,也有可能是在機能恢復前都得失去生產力。不過,這件事讓許多資訊長、技術長和 IT 專業人員心生疑竇:「如果是我的網站怎麼辦?萬一服務中斷,我所做的能否保證業務能夠繼續正常運作?」

改用雲端並非萬靈丹

雲端服務供應商宣傳 SLA (服務層級協議) 時,會號稱能夠維持「百分之 99.9999…」的正常運作時間,但是,即便服務只中斷了幾分鐘,一樣算是不符合 SLA。雲端服務不但號稱能達到這樣的 SLA,還能節省硬體、房地產,甚至包括 IT 人員在內的成本,站在財務的立場,改用雲端當然深具吸引力。昨天的事故給了我們一個教訓,單純將系統或資料移動到雲端,不見得就能保證 100% 的零事故時間。要擬定適當的業務復原方案,就必須瞭解資料所在位置,瞭解備援需求,還得針對服務供應商發生事故時可能引發的衝擊擬好避險計劃。

投資報酬率 (ROI)

多少保障才夠?多少才算太多?衡量投資報酬率向來是度量與統計的練習題。瞭解系統能用或不能用的價值,有助於判斷為復原策略投資多少才算值得。

為部落格網站擬定復原策略或許不值得,但若部落格網站能夠透過廣告創造營收,一旦服務中斷就會造成金錢損失。衡量業務損失成本時,應以高層次業務復原策略的投資成本為準。

業務復原策略分析還應該包括釐清復原時間目標,以及復原點目標 (分別是 RTO 和 RPO)。RTO 分析需判斷業務在服務中斷情況下能夠撐多久。RPO 分析則界定業務能夠容忍的資料遺漏期間上限。

以上一個範例中的部落格網站來說,由於損失廣告營收的緣故,其復原時間的閾值可能較低,但網站上的資料可能一星期才更改一次,因此,若使用備份復原是能最快完成復原程序的情況,復原點的閾值可能就較高。判斷多少防護措施才足夠時,應將這兩項因素皆列入分析考量。

多區域備援

AWS S3 事故侷限於名為 US-EAST-1 的區域,而各區域是相互隔離的。再者,雖然可以選擇使用區域專用端點 (亦即 http://s3-eu-west-1.amazonaws.com),但若使用預設端點 (http://s3.amazonaws.com),預設路徑會通過 US-EAST 區域,再重新導向至正確的端點。雖然事故範圍侷限在 US-EAST-1 區域,倘若網站需仰賴重新轉向,問題仍有可能擴大。

由於區域彼此隔離,如果您的網站在 S3 值區設定了跨區域複寫,也複寫了所有物件,而且您有能力將應用程式重新導向至另一個 S3 值區,網站擁有者應能設法還原服務。

由於實際根本原因仍不明朗,因此無法判斷這種方式能否加快服務還原速度,不過,如果您的 IT 團隊瞭解系統與配置 – 就連雲端的系統與配置都瞭若指掌,那麼,或許有其他方法能夠加快復原速度。

主動測試

前述關於跨區域複寫的部分包含了許多「如果」。

  • 「如果」您設定了跨區域複寫
  • 「如果」複寫了所有物件
  • 「如果」可以將應用程式重新導向

要知道團隊的復原策略能否奏效,唯一的方法就是經常測試復原程序,直到對這些策略有信心為止。千萬別等到發生需要復原的情況才第一次試著釐清該如何處理。

業務復原策略的備援部分

您聽過一句話:「別把雞蛋放在同一個籃子裡」。視資料的重要程度而定,同樣不建議您將所有資料全數交給同一個雲端供應商進行儲存。選擇這種方式可能既花錢又錯綜複雜,因此,您可以回頭運用投資報酬率計算公式,好好盤算若將資料交給多個供應商儲存能受惠多少。

您可以選擇 AWS、Microsoft Azure、Rackspace 以及其他企業級儲存方式,另一個選項則是混合雲端/內部部署解決方案。沒錯,您改用雲端就是為了擺脫內部部署系統,但是,視您的投資報酬率度量結果而定,就財務立場而言,混合復原解決方案也許比多個雲端供應商解決方案還要划算。

情況評估

系統故障可能會造成業務中斷、營收損失或生產力損失,這些都是白花花的鈔票。無論您將系統儲存於何處,S3 故障中斷事故都是一個警訊,提醒您好好評估自己的業務復原策略和程序,力求將發生事故的損失降到最低。別等到後悔莫及!New Call-to-action

轉自IPSWITCH中文官方部落格https://blog.ipswitch.com/tw/amazon-outage-and-your-business-recovery-strategy