【51CTO.com原創稿件】相信很多 IT 界的朋友，昨天都被這條新聞刷屏了：阿里云宕機故障導致華北地區多家公司 App 和網站癱瘓。雖然目前阿里回應稱故障已全部修復，但宕機事件對企業用戶的影響和損失是巨大的。

[[258731]]

3 月 3 日凌晨，有微博網友反映阿里云疑似出現宕機事故。這次宕機出現得絲毫沒有征兆，以至于聽說有不少工程師都是半夜里被從被窩里薅出來的。

此次宕機引發眾多網友吐槽，不過網友的反應很現實，他們心中關心的只有“花唄”：

阿里云方面表示，從 3 月 2 日 23:55 分左右開始，監控發現華北 2 地域可用區 C 部分 ECS 實例狀態異常。

后經排查處理，為 ECS 服務器等實例出現 IO HANG，其他地域及可用區經過排查后未發現此類情況。所謂 IO HANG，就是云服務器的磁盤無響應。

對此，阿里云回應稱，經緊急排查處理后全部恢復，針對本次故障，將根據 SLA 協議，盡快處理賠償事宜，但阿里云并未公開詳細的賠償細節。

而根據阿里云開發者論壇上的網友說法，賠償通常是按照故障時間的 100 倍進行的，而方案則根據包年包月預付費模式和按量付費模式有所不同，但總額不超過支付的單臺云服務器費用總額。

經過 10 多年發展，云計算技術已經逐漸成熟，企業對于云計算的接受程度也在進一步提高。

由于云計算能夠給企業 IT 運營、業務創新等帶來明顯效用，上云已經成為企業常態。

同樣是 3 月 3 日的消息，全球云管理服務廠商 RightScale 發布 2019 年云狀況調查報告，受調查用戶表示 2019 年在公有云服務上的支出增長速度將是私有云的 3 倍，而包括阿里云在內的全球公有云廠商將受益于這一趨勢。

根據 RightScale 報告，在被調查企業中公有云采用率為 91%，私有云采用率為 72%，也就是說，差不多超過 9 成的企業已經有工作流跑在公有云上。這一數據較上年持平，但較幾年前出現了大幅上升。

公有云市場的大幅增長，除了其成本低，擴展性好之外，安全性越來越高也是重要的原因。但盡管雙方約定的可用性為 99.99%，但意外的發生仍不可避免。

此次阿里云宕機事件，凡是會讀寫故障盤的系統軟件或服務程序，都會受到影響，涉及很多互聯網公司、App、網站。云上不可能做到絕對不出事，所以，容災災備才是負責任的做法。

針對企業的特點，構建健全的容災制度、完整的容災方案、良好的容災系統，并在實踐中不斷的進行評估、反復測試、隨時調整并加以改善，是刻不容緩的。

將重要業務分別放在不同的“籃子”里，選擇多個云服務供應商，也是個不錯的選擇。

再來看看知乎網友@千杯不醉的評論：

公有云故障年年有，去年騰訊云故障導致客戶數據丟失鬧的沸沸揚揚，這次是阿里云。這兩家都是業界標桿，猶且如此。

到目前為止沒有看到其他云服務商借機營銷，吹噓自己有多牛逼，為什么?借用前邊某位仁兄說的，做技術的，一定要心存敬畏。

我想起一件往事，大概兩年前，與多家網絡設備友商一起在上海某金融客戶處討論設備冗余架構。

某 H 司突然發起攻擊，你們的設備就那么容易出故障嗎!眼中滿是鄙夷，似乎他家產品永遠不會出問題。

這一下惹惱了其他友商，同時向客戶建議，讓 H 司簽署永不出問題承諾，結果 H 司啞口無言。

就這次事件來說，有人說公有云就是不行，還是私有云牛逼，能達到多少個 9。

我做私有云多年，只想跟大家說，不是私有云可用性好，而是公有云故障傳播面廣，影響大。

再者，云服務的高可用性跟你的投入也有很大關系，金融業云服務之所以可用性好，在于他們相對來說不計成本，用相對較好的設備，搭建高度冗余的數據中心架構。

就像阿里云的這次故障，如果能夠利用阿里云的 Region-AZ-DC 多級架構進行響應的冗余部署，相信業務基本可以不受影響。

你或許會說，如此部署成本高啊。對啊，所有的商品都是用合適的錢買合適的服務。

事實證明，雞蛋不要放到一個籃子里(DC)，籃子不要放到一輛車上(AZ)，車不要走同一條路(Region)。基于此，我相信多云必將成為一個趨勢。

也有網友吐槽到阿里云一年一宕機，今年特別早!在 2018 年 6 月，阿里云曾出現技術故障。盡管官方最終給出的故障時間僅為 30 分鐘，而恢復時間需要 1 小時。

但阿里云最終仍將其定義為 S1 級別事故，即核心業務重要功能不可用，影響了部分用戶，造成了一定損失。

根據 IDC 統計，阿里云占據近一半中國公有云市場。根據阿里云數據，有 40% 的國內網站和 50% 的獨角獸公司都在使用阿里云。因此，阿里云每次的故障事件，都會引起軒然大波。

這是一場發生在周末的宕機時間，因微博的傳播而備受關注。第三方機構 Forrester 分析師戴鯤稱，華北 2 地域是阿里云最早開通服務的華北地域之一，而 ECS 服務器又是阿里云最為核心的 IaaS(基礎設施即服務)之一，影響程度應當是相對較大的。

那么如何做好基礎設施監控，防范意外停機呢?下面小編將介紹一些開源工具以及如何用它們來構建一套強大的監控架構。

如何做好基礎設施監控，防范意外停機?

基礎設施監控是基礎設施管理的一個組成部分。它是 IT 管理員防范意外停機的首道防線。嚴重的問題可能導致基礎設施出現大量停機時間，有時導致嚴重的經濟損失。

監控系統從你的基礎設施收集時間序列數據，以便對其進行分析，預測基礎設施及底層部件即將出現的問題。這使得 IT 管理員或支持人員有時間在問題發生之前準備并運用解決方案。

一套良好的監控系統具有以下功能：

• 長期測量基礎設施的性能
• 節點級分析和警報
• 網絡級分析和警報
• 停機分析和警報
• 回答事件管理和根本原因分析(RCA)的五個 W

而回答事件管理和根本原因分析(RCA)的五個 W指的是：

• 實際問題是什么?
• 什么時候發生的?
• 為什么會發生?
• 什么系統或部件出現停機?
• 需要采取什么措施才能在將來避免?

建立強大的監控系統

有許多工具可以構建可行且強大的監控系統。就有一個決定是使用哪個工具;答案在于你希望通過監控實現的目標以及要考慮的各種財務和業務因素。

雖然一些監控工具是專有的，但許多開源工具(無人管理的軟件或社區管理的軟件)的效果甚至比閉源工具還好。

日志收集和分析

日志大有幫助。日志不僅有助于調試問題，還提供了大量信息，幫助預測即將發生的問題。遇到軟件組件問題時，應首先分析日志。

Fluentd 和 Logstash 都可用于收集日志，我選擇 Fluentd 而不是 Logstash 的僅有原因是因為它獨立于 Java 進程。

它是用 C + Ruby 編寫的，得到 Docker 等容器運行時環境和 Kubernetes 等編排工具的廣泛支持。

日志分析是指分析逐漸收集的日志數據，并生成實時日志度量指標。Elasticsearch 是這方面的一款強大工具。

最后，你需要一個工具來收集日志度量指標，以便能夠使用易于理解的圖表和圖形直觀地顯示日志趨勢。Kibana 是我在這方面所青睞的選擇。

圖 1：日志工作流程

由于日志可能保存敏感信息，因此需要記住幾個安全要點：

• 始終通過安全的連接傳輸日志。
• 應在受限制的子網內實施日志/監控基礎設施。
• 應僅限于利益相關者訪問監控用戶界面(比如 Kibana 和 Grafana)。

節點級度量指標

并非一切都記入日志!沒錯，日志監控的是軟件或進程，而不是基礎設施中的每個部件。

操作系統磁盤、外部掛載的數據磁盤、Elastic Block Store、CPU、I/O、網絡數據包、入站和出站連接、物理內存、虛擬內存、緩沖區空間和隊列是很少出現在日志中的一些主要部件，除非它們出了故障。

那么，如何收集這類數據呢?Prometheus 是個答案。你只需在虛擬機節點上安裝針對特定軟件的導出器，并配置 Prometheus，從這些無人值守的部件收集基于時間的數據。

Grafana 使用 Prometheus 收集的數據來實時直觀地顯示節點的當前狀態。

如果你在尋找一個更簡單的解決方案來收集時間序列指標，不妨考慮 Etricbeat，這是 Elastic.io 的內部開源工具，它可以與 Kibana 一起使用以取代 Prometheus 和 Grafana。

警報和通知

沒有警報和通知，你就無法充分利用監控。除非利益相關者(無論他們人在哪里)接到有關問題的通知，否則他們就無法分析和解決問題、防止客戶受到影響并在將來避免它。

Prometheus 使用其內部的 Alertmanager 和 Grafana 來創建預定義的警報規則，可以基于配置的規則發送警報。Sensu 和 Nagios 是提供警報和監控服務的其他開源工具。

人們在開源警報工具方面遇到的問題是，配置時間和過程有時看起來很費勁，但是一旦設置好，這些工具的效果比專有工具還好。然而，開源工具的突出優點是我們可以控制它們的行為。

監控工作流程和架構

良好的監控架構是強大而穩定的監控系統的支柱。它可能看起來像這個圖：

圖 2：Devops 監控架構

你要根據自己的需求和基礎設施來選擇工具。許多企業組織使用本文中討論的開源工具來監控基礎設施并確保正常運行時間很長。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】