雲平台宕機引發的系列思考，企業如何自救？

近日，一則阿里雲平台發生宕機的新聞引發眾網友關注。細數這兩年，國際主流雲廠商在安全性和可靠性層面做了不少努力，但所有服務都不可能百分百穩定，企業應該思考的是在問題出現時如何自救，而不是坐以待斃。

近兩年，因為雲平台宕機造成的事故數不勝數，比如gitlab曾因誤刪除引起服務中斷18小時，並且無法完全恢復；亞馬遜aws因一條錯誤指令引起宕機，隨後大部分網際網路，包括slack、quora和trello在內的企業平台停機4個小時；微軟azure公有雲出現超過8小時的儲存可用性問題；亞馬遜aws訪問儲存塊出現問題，影響s3儲存服務；谷歌自動化失效引起停運93分鐘；亞馬遜aws北維吉尼亞地區資料中心出現硬體問題等。

儘管雲平台會發生故障，但企業對雲的信賴度依然很高。gartner研究主管sid nag曾表示，雲服務市場的增長速度比幾乎所有it市場都要快，其中大部分增長是以傳統非雲服務為代價，尤其是基於雲計算的iaas需求在繼續增長，預計將在未來5年呈現最快增長趨勢。

在雲計算出現之前，企業內部自建資料中心依舊會出現很多問題，不少問題甚至是致命的。上雲之後，公有雲廠商至少可以幫助技術能力有限的企業進行合理範圍內的監控、預警和備份。不可否認，雲的出現確實解決了現階段企業在計算、儲存等方面的很多問題，但完全依靠雲計算廠商提供安全性的做法是不可取的。

企業應該具備容災意識，並在故障發生的第一時間採取措施彌補損失。因為雲而產生的故障風險一般分為兩類：一是因為誤操作導致的問題（其實用不用雲服務都有這個問題）；二是雲平台故障導致的問題。

在這種情況下，企業首先應該反問自己，如果不用雲平台，解決方案是什麼？常規的解決方案，比如定期備份歸檔策略，包括伺服器、資料庫、儲存等方面。

在雲計算環境下，平台基本都提供類似功能，例如伺服器有快照，資料庫和日誌有備份等。這些功能都「實用性」地提供了解決方案，並且比自己構建類似服務要簡單好用，但很多企業為了節省成本可能並未接受雲廠商的服務，此時就需要依靠企業自身的技術能力。

其次是許可權問題，雲平台的賬戶許可權管理嚴格避免無意或者惡意的誤操作，就像傳統環境下，如果root口令全公司都知道，那麼出了事情也不奇怪。

最後，通過堡壘機或者雲平台自帶的審計功能，至少知道發生故障時乾了什麼，怎麼幹的，這樣恢復環境比較容易。

無論是傳統環境還是雲環境，都不能做到絕對的「持續可用」。大部分情況下，雲環境的可用性和可靠性都比傳統環境要高，這主要是因為雲平台的運維更加專業。既然任何環境都有出現故障的可能，那麼需要重視的問題就是「發生故障時，應該怎麼辦」。

接受風險，這一點很重要。對於現階段國內的雲計算發展程序來看，上雲是不可避免的，在這種情況下，企業應該保持正確的心理，畢竟只要是系統，都會發生故障。國內主流雲計算廠商已經投入了大量精力和成本在可用性和可靠性層面，這肯定要優於不少技術能力不足、成本有限的企業自建伺服器。如果出現這種情況，那麼走應急預案，用非系統的方式盡量降低風險。例如，某個服務宕機了，及時在官網做出宣告。

其次，分散風險。雲環境的同城雙活、異地災備等方案基本就緒，盡量在經濟和人員條件可行的情況下使用這些分散風險的方法。如果故障只出在乙個伺服器集群，採用異地災備方案可以在最快時間切換到另乙個集群，從而保持系統可用。雖然還是會有中斷，但是可以最快時間恢復。

按照此模式，雲下系統做雲上災備也是防範傳統環境出現可用性問題的一種重要手段。作為企業的it人員，日常做到以下四點可以盡可能避免雲故障帶來的損失。

1、備份、備份，還是備份，要異機異地；

2、資料容災；

3、業務雙活；

4、定期對災備和雙活進行演練。

未來，雲服務很可能像水電煤一樣成為基礎設施，即便是這些基礎設施，我們也無法保證百分百可用。因此，如果自身服務非常重要，可以考慮租用多個雲服務互為主備，甚至自建機房，只是這樣成本和技術複雜度會成倍增加。

從統計上看，中小企業的運維水平遠低於主流雲平台，故障概率要高得多，損失更不可控。因此，不必對雲服務故障抱有恐懼，只需要保持正常的認知和高度災備意識即可。

雲平台宕機引發的系列思考，企業如何自救？

雲平台宕機引發的系列思考，企業如何自救？

雲平台宕機引發的系列思考，企業如何自救？

針對distinct疑問引發的一系列思考

相關推薦