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

[[258731]]

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

此次宕機引發(fā)眾多網(wǎng)友吐槽，不過網(wǎng)友的反應(yīng)很現(xiàn)實，他們心中關(guān)心的只有“花唄”：

阿里云方面表示，從 3 月 2 日 23:55 分左右開始，監(jiān)控發(fā)現(xiàn)華北 2 地域可用區(qū) C 部分 ECS 實例狀態(tài)異常。

后經(jīng)排查處理，為 ECS 服務(wù)器等實例出現(xiàn) IO HANG，其他地域及可用區(qū)經(jīng)過排查后未發(fā)現(xiàn)此類情況。所謂 IO HANG，就是云服務(wù)器的磁盤無響應(yīng)。

對此，阿里云回應(yīng)稱，經(jīng)緊急排查處理后全部恢復(fù)，針對本次故障，將根據(jù) SLA 協(xié)議，盡快處理賠償事宜，但阿里云并未公開詳細(xì)的賠償細(xì)節(jié)。

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

經(jīng)過 10 多年發(fā)展，云計算技術(shù)已經(jīng)逐漸成熟，企業(yè)對于云計算的接受程度也在進(jìn)一步提高。

由于云計算能夠給企業(yè) IT 運營、業(yè)務(wù)創(chuàng)新等帶來明顯效用，上云已經(jīng)成為企業(yè)常態(tài)。

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

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

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

此次阿里云宕機事件，凡是會讀寫故障盤的系統(tǒng)軟件或服務(wù)程序，都會受到影響，涉及很多互聯(lián)網(wǎng)公司、App、網(wǎng)站。云上不可能做到絕對不出事，所以，容災(zāi)災(zāi)備才是負(fù)責(zé)任的做法。

針對企業(yè)的特點，構(gòu)建健全的容災(zāi)制度、完整的容災(zāi)方案、良好的容災(zāi)系統(tǒng)，并在實踐中不斷的進(jìn)行評估、反復(fù)測試、隨時調(diào)整并加以改善，是刻不容緩的。

將重要業(yè)務(wù)分別放在不同的“籃子”里，選擇多個云服務(wù)供應(yīng)商，也是個不錯的選擇。

再來看看知乎網(wǎng)友@千杯不醉的評論：

公有云故障年年有，去年騰訊云故障導(dǎo)致客戶數(shù)據(jù)丟失鬧的沸沸揚揚，這次是阿里云。這兩家都是業(yè)界標(biāo)桿，猶且如此。

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

我想起一件往事，大概兩年前，與多家網(wǎng)絡(luò)設(shè)備友商一起在上海某金融客戶處討論設(shè)備冗余架構(gòu)。

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

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

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

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

再者，云服務(wù)的高可用性跟你的投入也有很大關(guān)系，金融業(yè)云服務(wù)之所以可用性好，在于他們相對來說不計成本，用相對較好的設(shè)備，搭建高度冗余的數(shù)據(jù)中心架構(gòu)。

就像阿里云的這次故障，如果能夠利用阿里云的 Region-AZ-DC 多級架構(gòu)進(jìn)行響應(yīng)的冗余部署，相信業(yè)務(wù)基本可以不受影響。

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

事實證明，雞蛋不要放到一個籃子里(DC)，籃子不要放到一輛車上(AZ)，車不要走同一條路(Region)?；诖耍蚁嘈哦嘣票貙⒊蔀橐粋€趨勢。

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

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

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

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

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

如何做好基礎(chǔ)設(shè)施監(jiān)控，防范意外停機?

基礎(chǔ)設(shè)施監(jiān)控是基礎(chǔ)設(shè)施管理的一個組成部分。它是 IT 管理員防范意外停機的首道防線。嚴(yán)重的問題可能導(dǎo)致基礎(chǔ)設(shè)施出現(xiàn)大量停機時間，有時導(dǎo)致嚴(yán)重的經(jīng)濟損失。

監(jiān)控系統(tǒng)從你的基礎(chǔ)設(shè)施收集時間序列數(shù)據(jù)，以便對其進(jìn)行分析，預(yù)測基礎(chǔ)設(shè)施及底層部件即將出現(xiàn)的問題。這使得 IT 管理員或支持人員有時間在問題發(fā)生之前準(zhǔn)備并運用解決方案。

一套良好的監(jiān)控系統(tǒng)具有以下功能：

• 長期測量基礎(chǔ)設(shè)施的性能
• 節(jié)點級分析和警報
• 網(wǎng)絡(luò)級分析和警報
• 停機分析和警報
• 回答事件管理和根本原因分析(RCA)的五個 W

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

• 實際問題是什么?
• 什么時候發(fā)生的?
• 為什么會發(fā)生?
• 什么系統(tǒng)或部件出現(xiàn)停機?
• 需要采取什么措施才能在將來避免?

建立強大的監(jiān)控系統(tǒng)

有許多工具可以構(gòu)建可行且強大的監(jiān)控系統(tǒng)。就有一個決定是使用哪個工具;答案在于你希望通過監(jiān)控實現(xiàn)的目標(biāo)以及要考慮的各種財務(wù)和業(yè)務(wù)因素。

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

日志收集和分析

日志大有幫助。日志不僅有助于調(diào)試問題，還提供了大量信息，幫助預(yù)測即將發(fā)生的問題。遇到軟件組件問題時，應(yīng)首先分析日志。

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

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

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

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

圖 1：日志工作流程

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

• 始終通過安全的連接傳輸日志。
• 應(yīng)在受限制的子網(wǎng)內(nèi)實施日志/監(jiān)控基礎(chǔ)設(shè)施。
• 應(yīng)僅限于利益相關(guān)者訪問監(jiān)控用戶界面(比如 Kibana 和 Grafana)。

節(jié)點級度量指標(biāo)

并非一切都記入日志!沒錯，日志監(jiān)控的是軟件或進(jìn)程，而不是基礎(chǔ)設(shè)施中的每個部件。

操作系統(tǒng)磁盤、外部掛載的數(shù)據(jù)磁盤、Elastic Block Store、CPU、I/O、網(wǎng)絡(luò)數(shù)據(jù)包、入站和出站連接、物理內(nèi)存、虛擬內(nèi)存、緩沖區(qū)空間和隊列是很少出現(xiàn)在日志中的一些主要部件，除非它們出了故障。

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

Grafana 使用 Prometheus 收集的數(shù)據(jù)來實時直觀地顯示節(jié)點的當(dāng)前狀態(tài)。

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

警報和通知

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

Prometheus 使用其內(nèi)部的 Alertmanager 和 Grafana 來創(chuàng)建預(yù)定義的警報規(guī)則，可以基于配置的規(guī)則發(fā)送警報。Sensu 和 Nagios 是提供警報和監(jiān)控服務(wù)的其他開源工具。

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

監(jiān)控工作流程和架構(gòu)

良好的監(jiān)控架構(gòu)是強大而穩(wěn)定的監(jiān)控系統(tǒng)的支柱。它可能看起來像這個圖：

圖 2：Devops 監(jiān)控架構(gòu)

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

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】