你的災難恢復計劃是否包括服務提供商中斷的意外情況?我們知道理論上每臺計算機系統都會發生故障。但是，我們有時需要經歷中斷，才能在更加內部的層面了解問題，并正確的進行計劃。

你是否可以在2017年2月的Amazon Simple Storage Service(S3)故障期間有效的執行災難恢復(DR)計劃?也許你的災難恢復計劃是針對另一個云服務商，但你仍然需要從Amazon Web Services的故障中吸取教訓。需要特別強調的是，你需要了解DR計劃的每個元素的服務級別協議(SLA)，特別是在你控制之外的其它元素。

問題出在哪?

那次的AWS故障是源于一個相當簡單的問題——一名進行日常維護的AWS工程師錯誤的輸入了命令。這導致了管理和監控S3的AWS基礎設施不能正常運行。在美國東部1區使用S3的所有應用程序都無法創建新對象。

對于DR應用程序來說，這次故障意味著新的備份無法被保存，這可能會違反客戶恢復點目標(RPO)。 DR應用程序也無法從現有備份中進行任何恢復，從而影響恢復時間目標(RTO) 。

AWS用了大約6個小時才完全恢復服務。根據AWS的說法，S3每月的目標是提供 99.9%的可用性，這使得每月停機時間應該少于44分鐘。顯然，AWS應該償還部分服務費用，因為他們在那個月似乎只達到了90%的可用性。所以如果你在AWS服務中斷期間遇到了一個DR事件，那么這將是一個小小的安慰。你得等到故障恢復后才能使用上次完成的備份進行恢復。

我們應該如何應對?

從這次AWS故障中學到的第一課是你無法控制云服務。了解可用的服務級別將使你能夠確定特定的云服務是否滿足你的DR需求。

云服務商和你的主數據中心同時發生故障的概率很低。通過簡單的Google搜索可以了解到，自亞馬遜2006年推出服務以來，已發生大約三次重大的S3服務中斷。在我看來，你的數據中心和AWS之間的網絡鏈接相對于你的RPO / RTO更具風險。你的DR計劃中是否列入了這些風險?使用災難恢復服務(DRaaS)是否仍然具有商業意義?

如果這次故障讓管理層對云端的DR感到不安的話，可以采取一些進一步的措施，例如使用更多的站點。舉個例子來說，US-East-1區域(北弗吉尼亞州)的冬季風暴不會影響到EU-West-1 區域(愛爾蘭)。通過將S3存儲桶從US-East-1復制到EU-West-1，或者備份應用程序直接向兩個區域發送備份數據，你應該可以免受AWS區域故障帶來的影響。

你甚至可以選擇在遠程辦公室部署與S3兼容的存儲系統，并且讓你的備份軟件寫入該站點。

對于還不信任云服務商的用戶，您可以將備份發送到具有完全獨立基礎設施的兩個不同的云提供商。不過這么做的缺點是將備份發送到兩個位置意味著支付更多的存儲和網絡傳輸費用。另外還需要管理多個災難恢復計劃，每個站點都需要有一份。通過簡單的數學計算你可能會發現為此付出的額外成本相對于得到的額外可用性來說是不劃算的。

任何計算機系統都會有、并將會有停機時間。基于云的DRaaS也不例外。如果您的災難恢復受到云端故障的影響，你的公司是否理解云端的DR故障(例如AWS服務中斷)對于業務連續性可能造成的影響?

雖然大多數企業不愿意增加他們的開支來讓DR獲得更好的可用性，但仍然有少數企業愿意為此投入，以換取更可靠的災難恢復系統。