VUCA 這個詞在高效運維社群好幾個分享當中都有提到過，現在是變幻莫測的時代，有很多不確定性、易變性、複雜性、模糊性，我們現在的需求變得越來越模糊不確定。以前開發使用瀑布型的模型，完成一個交付可能需要幾個月的時間，需求是固定的。但是現在面對越來越多的競爭對手，越來越多的新需求，我們會有很多的不確定性。比如上線一個類似拼多多的拼團業務模型，業務部門往往希望在幾周內進行需求交付。

因此，VUCA 帶來的持續不斷的變化，對於底層的監控系統造成了非常大的挑戰，包括技術棧的挑戰，包括人員的專業能力上的挑戰。所以很多時候，VUCA帶來的變化也意味著各種不確定的挑戰。

一. Fintech的挑戰

大家認為運維的第一要務是什麼？

從表面看，運維是一個消耗的部門，會消耗很多金錢和資源，所以對於我們來說運維的第一要務是止損。只有保證線上系統的高可用性，保證業務穩定性，以避免不必要的損失。

上圖是一家諮詢公司給出的資料，每分鐘的Downtime對企業造成的損失。而對於金融行業，尤其是銀行而言，這個數字往往會更大。

所以 VUCA 帶來的變化給我們帶來了很多的困擾。

最大的困擾就是基礎架構急速擴容：基礎架構的容量會指數級的增長。

其次的困擾就是新技術和新產品的引入：原先銀行傾向於使用小機，但是現在我們有越來越多的虛擬化、大資料平臺。有些企業會去IOE，會引入華為、浪潮等一些國產品牌；在組成虛擬化叢集的時候，時不時會有一些相容性和穩定性的問題。怎麼去監控這些新產品，怎麼去發現潛在的問題，這對於我們的運維人員來說也是很大的挑戰。

再次，對於人員技術棧的深度要求越來越高。剛進入IT行業，我是一個只會玩玩windows伺服器的系統管理員，而現在除了windows，還需要精通linux、虛擬化、儲存技術、伺服器軟硬體、python指令碼語言，除此之外還要了解一些演算法、安全、DevOps、Scrum敏捷等技術。隨著IT行業技術不斷的革新，對於人員技術棧的深度要求也是日益提高，這也可以從現在招聘崗位的薪資價格和對面試人員的能力要求中看得到。

最後一點，不同團隊之間的協作。開發、業務、運維人員常常會站在自己的角度提出需求：

開發看重程式碼交付的有效性和效率；業務看重的是業務可用性和一些運營指標；運維更多關注底層基礎架構的穩定性。如何滿足各方面不斷變化的需求，也是VUCA時代給我們帶來的挑戰。

二. Fintech環境下的監控目標

FinTech環境下的監控目標是什麼呢？

在移動網際網路時代來臨之前，可以說我們長期處於在傳統的銀行業，伺服器數量、人員數量都是在一個比較小的規模上。然而我們現在處於移動網際網路的時代，金融科技的環境下，發生了很多的變化，我們有兩個APP，一個是手機網銀APP，一個是掌上生活APP。

面向網際網路的應用使得我們的基礎環境，有一個指數性的增長。我們現在會有幾千臺伺服器，甚至上萬的伺服器，我們的架構也會從以前的單點應用伺服器，轉變成越來越多的使用微服務、分散式等更先進的技術解決方案，而應用數量也增長了很多。

開發語言仍然使用Java，C#等比較傳統的開發語言，但也會逐漸使用python，ruby等比較熱門的語言。所個環境的變化，使得我們也引入 Devops、Scrum 敏捷等等一系列的概念、方法論到組織中。

對於運維人員而言，我們需要監控的東西有很多。一般而言，監控的層次是一個金字塔形的架構。通常我們會從作業系統層進行監控，在它之上，我們需要監控中介軟體和應用；在它之下，我們還需要監控虛擬化層、儲存、硬體等。而在每個層面，我們需要監控的東西也是多樣的，比如我們監控資料庫，會有MySQL，SQLserver等多個產品。

另外，對於監控的閾值標準，每個企業都有自己的標準。即使在團隊內部，開發和運維人員也有各自考量的圍度。在企業內部，運維人員常常需要面對多個開發團隊，因此對於運維人員而言，需要了解的技術也會隨之增多，有時候甚至要通過閱讀程式碼去了解如何部署監控，瞭解需要監控那些指標等。

總兒胭脂，要合理地，有效地部署一個較為完善的監控系統，從技術、平臺、組織的各個角度來說，都是非常複雜的。

另外一方面，相信大家也會碰到類似的問題：作業系統、資料庫和網路管理員都會說自己負責的系統是健康的，而業務上卻反饋了一些異常甚至不可用。歸根結底是由於某些監控的不到位，監控深度不足。我把監控深度定義成了四個部分：

第一部分是可用性監控：這是最簡單的層面監控，比如：監控埠是否活。

第二部分是效能監控：比如：雖然CPU正常運作，但CPU的佔用率是否一直處在一個很高的水平？

第三部分是日誌監控：主要是應用日誌監控，其次還有安全審計日誌、系統日誌等。這些日誌監控可確保我們人員操作的合規性。應用日誌也會為後續的全鏈路監控提供跟蹤依據，為故障定位作為參考依據。

最後一部分是自定義監控：我們會有很多來自於業務方面的需求，自己定義的指標，比如過去十分鐘的成交量有多少，雖然這些kpi可以通過其他方式查詢到，但是如果能夠直接整合在監控系統中進行查詢，提供附加的自定義監控，那就能更好地滿足業務監控需求，從業務的角度去了解企業業務的執行狀況。

綜上所述，監控的深度有以下這四方面：可用性監控、效能監控、日誌監控、自定義監控。

三. 為什麼選擇 Zabbix?

選擇監控產品的話主要有三種方式：一是完全自研發（如小米的open-falcon），二是基於開源產品進行二次開發（如Zabbix，nagios），三是使用純粹的商業化產品（如scom，tivoli）。

開源產品可以很好的滿足自身的需求，但是開發週期較長，對於開發人員的要求較高，短期內很可能沒有太多的產出；

而商業產品雖然有完善的售後支援，但商業產品基本是閉源的，廠商更注重契約精神，對於一些個性化的需求，要麼難以實施，要麼實施週期非常長，難以進行定製化或者個性化的監控。同時很少有哪一塊商業監控產品能夠滿足全棧級別的監控。

而基於開源產品的二次開發，雖然需要一定的學習成本，但有較好的相容性和可定製化，不需要花大量的資源去購買商業許可和支援，對於有一定研發能力的企業來說，是比較理想的選擇。

另外由於異構平臺的相容性，我們也希望有一款能夠覆蓋大多數監控需求的產品，實現統一監控，綜合考慮最後我們選擇Zabbix，因為它在監控的廣度和深度上處在一個較好的平衡點。

Zabbix有哪些特點？

四. 最佳實踐&案例分享

最後，分享一下關於Zabbix的一些最佳實踐，這些最佳實踐可能會對大家在實際環境當中使用Zabbix（或者其他監控系統），會有一定的借鑑作用。

4.1 分散式自動化監控

以前我們的監控系統都是單點的，隨著伺服器的增加，我們會更注重監控系統本身的穩定可用性。

伺服器數量持續增長，應用數量也在增長，對監控系統的壓力也會有所增大。同時我們需要有一個平臺——而不是多個平臺去做監控——有多個平臺，勢必會導致監控噪音，或者重複新增監控。

另外，我們需要減少人為手工新增監控的情況發生——這可能導致一些監控的遺漏，或者說即使這個監控物件加入了監控系統，但沒有合理地增加必要的監控專案。因此必須通過自動化監控（而非手動監控）去確保監控的有效性。

上圖中，在每個網路區域會有一個Proxy，相當於班長的角色，它會收集班裡面的所有資訊，proxy會去和master溝通，這樣的話會避免在防火牆上開放太多額外的埠。這也是個分散式監控，使用者可以通過Web端訪問Zabbix，去實時瞭解當前系統的狀態。防火牆上只開通了必要埠，這樣的話不需要打通很多的網路，提升了整個系統的安全性。

對於自動化監控，在Zabbix中可以輕鬆實現。管理員只需要定義3個要素：監控的主機，模版（某一型別的主機有哪些監控專案；監控專案觸發的閾值時多少）以及負責人（某一型別的主機由誰來負責管理）。

以下是具體的實現方式：Zabbix會自動定期掃描使用者定義好的網段

（192.168.0.0/16；123.1.0.0/24）。只要定義一次，之後就會每隔一定時間去掃描一次。然後發現網段中存在Windows伺服器，Zabbix自動會將它加入到監控系統，並關聯Windows模板。同時我們定義這些Windows伺服器是屬於Windows團隊的管理員進行管理，並讓兩者形成關聯。

因此，管理員需要人工進行的只是定義主機網段，定義關聯模版，定義關聯團隊。只要把這些定義完後，Zabbix就會自動定期掃描，一旦匹配這些規則便自動進行關聯，省去人為干預的不準確性。

這種自動化監控避免監控缺失或者監控噪音，不需要手動新增監控，只需要定義規則，把後面所有的持續監控的事情都交給了Zabbix去做，這樣最大程度減少了整個環節當中人為介入的不可控性。

4.2 雙維度管理

在實際監控的過程中，我們可能會遇到這要的情況：我們監控者一臺伺服器上的資料庫、中介軟體和作業系統。

因為視角不同監控的需求也不同：資料庫團隊只關注資料庫的報警，中介軟體團隊只關注中介軟體的報警，作業系統團隊只關注作業系統的報警，各團隊之間只希望收到和自己有關的報警。同時處於安全合規的考慮，在確保報警的有效性的同時，我們還需要確保監控許可權最小化。

在Zabbix 中，我們把監控定義成了兩個維度，一個平臺維度（Platform），一個業務維度（Service-Line）。

平臺維度是指所監控的主機上執行著哪種資料庫、中介軟體或者作業系統中。

業務維度是指所監控的主機屬於那個業務條線。比如一臺用於使用者系統的Linux伺服器，同時也跑著Tomcat中介軟體，我們將把它放入P-APP-Tomcat、P-OS-Linux及S-Business-User組中。

所有的P組都會和對應的模板進行關聯，以實現標準化監控；S組和人員關聯，確保只有業務相關聯的人員可以檢視監控和收到監控報警。因此，監控既不會有遺漏，也降低了監控噪音。實現了自動化、標準化的監控。

4.3 告警通知

部署完了監控後，接下來我們進一步討論告警通知機制。總的來說，我們遵循分層通知、多渠道通知、細化通知內容的原則。

分層通知：對於不同的嚴重程度的報警，我們設定了不同的報警級別和報警策略。Zabbix中有5種報警級別，實際生產過程中，我們使用了其中的三種：Disaster，Warning和Information。

我們定義Disaster為直接影響生產的問題，需要管理員立即處理，這些報警也會在第一時間通知到對應的管理員及其直屬領導，以及7x24小時的監控中心值班人員；

而對於一些潛在的問題，或者急迫性沒那麼高的問題，我們會設定成Warning級別，這些報警只會傳送給對應的管理員，管理員可選擇立即或者稍後處理。Information級別的報警一般用於測試或者不重要的報警級別。

多渠道通知：我們通過大螢幕展現、Email、簡訊等多個方式進行告警通知。確保第一時間可以將這些通知觸達到使用者。

細化通知內容：如下圖可見，當告警通過簡訊等渠道被觸發時，我們會盡可能將所有的問題納入在告警中，包括了報警的狀態，具體觸發報警的內容，報警的伺服器及IP地址，當前狀態的具體值，聯絡人和電話。

之所以這麼做，可以讓相應人員第一時間瞭解當前監控物件的狀態；同時，7x24小時的值班人員也可以第一時間聯絡對應的管理員，精準觸達。

4.4 面板展現

無論哪一類的監控系統，多需要有完善的檢視展現功能。傳統商業軟體的定製化較差，或者沒有那麼容易上手，無法滿足自定義的需求。在Zabbix中，提供了豐富的圖形展現功能。

隨著Zabbix版本的不斷迭代，檢視展現得到了不斷提升。如上圖，這是一個在Zabbix2.2版本中的一個面板展現，我們會把整個面板分成上下兩部分。上半部分的每一朵雲就是一類業務系統，比如使用者登入系統，安全系統等等。可以通過不同的顏色知道當前系統的健康狀態：

比如紅的就代表這個系統存在Disaster級別的報警，黃色就代表存在Warning級別的報警，這樣也方便管理員第一時間處理這些故障。也可以通過形狀知道當前系統是否處在維護狀態（橘色的長方形表示這個系統處於維護模式）。

下半部分提供了一個告警列表，通過告警列表可以獲知相當多的資訊：當前告警的級別，當前哪些告警時活躍的，是什麼時候發生的，發生了多久等等。

3.4版本以後，包括現在4.0的版本，可以做很多定製化。提供更多樣的展現。

如果覺得Zabbix的展現不夠滿意，也可以尋求Grafana、EChart等第三方的外掛來實現。

4.5 自動化帶外管理

帶外管理是比較高階的功能。很多時候伺服器會莫名其妙宕機了，我們需要進入機房去找伺服器，然後使用一個移動工作臺登陸，非常麻煩。

Zabbix可以通過這種方式做自動化帶外管理。帶外管理痛點如下：

 ●  成本高! KVM專有裝置需要額外購買，額外KVM交換機支援。授權、機房容量都是成本。

各種廠商都提供了自己的帶外管理軟體，上面這三個圖分別對應的是惠普、戴爾、華為的三個帶外管理介面。他們的基本功能類似：重啟伺服器、伺服器軟硬體配置、韌體升級等操作。

我們會把這些機器的管理口，全部接入帶外網路。帶外網路中會有一臺DHCP伺服器自動分配IP地址。OOBProxy這個Zabbix代理會定期掃描整個網段。一旦發現有對應的伺服器上線，就會將它加入Zabbix並套用帶外的模版。該模版基於IPMI標準實現，因為通過的標準協議，所以不需要考慮品牌的差異性。同時通過Zabbix收集到的資料將為CMDB提供標準化資料。事實上，通過這個方案，初步實現了替換KVM平臺，去除了昂貴的硬體和授權成本。

4.6 持續整合/持續交付

釋出應用的時候必然會對伺服器、中介軟體、應用等進行一系列的操作，這個時候就會產生監控噪音。如何降低上線過程中的噪音，如何和其他平臺做持續整合，也是監控平臺需要考慮的。另一方面，在現有業務擴張越來越大，如何科學、合理地進行容量規劃，也是監控系統的職責之一。比如我們現在有一個新的搶購應用，如何評估這個系統需要多少伺服器、多少資源，Zabbix可以提供這方面的參考依據。

大多數正在進行持續整合的企業，都會有版本控制（如git）和持續整合（如Jenkins）平臺，同時通過一些配置管理工具（如anisble）對各個基礎平臺進行配置管理。

在上圖中，如要進行上線釋出Jenkins就會通過呼叫Zabbix標準的API將對應的監控物件放入維護模式，避免了在上線釋出過程當中，監控噪音的產生。同時Zabbix會將它收集到的資料和CMDB同步，CMDB的資料也會和其他DevOps平臺進行共享，保證我們線上配置是最新的、可用的。同時Zabbix也會接入一些通知平臺，微信、簡訊、郵件等，從而將告警第一時間通知使用者。

因此，Zabbix為整個持續整合和持續交付提供了標準的API，可以和DevOps的流水線進行高度整合。同時它也可以收集各種資料，為後期的容量規劃，做一個參考依據，而不是拍腦袋決定後面需要多少資源。

綜上所述，大家可以根據上述的最佳實踐評估哪個監控平臺更適合各自企業的需求。Zabbix的好處在於開源免費，我相信Zabbix從功能性上來說，不一定有BAT的自有監控平臺那麼強，但是它投入的資源非常少，是一個適合中小企業進行全棧式監控的平臺。

從管理成本和資源開銷層面來說，Zabbix也是非常綠色高效的，不需要花太多人力在監控層面。但需要明確的是任何監控平臺都不是萬能的，Zabbix也不例外。對一些非常深入的需求，比如對某個應用做詳細分析，任何平臺都無法自動實現。但總的來說，Zabbix覆蓋了80%的監控需求。使用Zabbix的最大收益是減少了人工介入，通過它的自動發現、低級別發現等高階功能，以及和其他DevOps流水線上的系統的高度整合，實現了全棧式無感知的監控。

原文釋出時間為：2018-11-14

本文來自雲棲社群合作伙伴“高效運維”，瞭解相關資訊可以關注“高效運維”。