<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1678611822423757&amp;ev=PageView&amp;noscript=1">

Amazon 服務中斷與業務復原

Missy Januszko| Feb 18, 2019 5:45:00 AM

| 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

Topics: monitoring, AWS, 雲端

Default HTML block

發表評論

您的電子郵件地址不會被公開。以下有標記*的為必填項目。

THIS POST WAS WRITTEN BY Missy Januszko

Missy Januszko is an independent IT consultant, with more than 20 years of experience as an enterprise hosting architect, large-scale infrastructure designer, and hosted application designer. She specializes in DevOps, automation and configuration management, PowerShell, and Active Directory, and has broad experience across the entire line of Microsoft business technologies. Missy is a co-author of “The DSC Book” with Microsoft MVP Don Jones, and she is also a conference speaker on DSC-related topics. She is a contributor to a number of open-source projects, including “Tug”, the open-source DSC pull server, and “Autolab”, an automated, rapid-install lab build.

免費試用

立即下載

聯絡我們

發送訊息

訂閱 Ipswitch 部落格