蔡翔華
招商銀行信用卡中心 技術經理
GOPS 金牌講師
首先跟大家分享一個句子：
We didn't do anything wrong, but somehow we've lost.
Stephen Elop (Nokia CEO)
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有哪些特點？
開源免費，社區支持。它沒有社區版和商業版之分。
分佈式高可用。很多的監控軟件可能就是單點，沒有緩存，沒有HA等等這些技術。而Zabbix在這方面有這些必要的特性。
低級別發現和自動發現。隨著我們的監控設備數量越來越多，我們發覺添加監控這一步很煩，要麼就是重複添加了，要麼就是遺漏添加了，出故障之後你才發覺有些必要的監控沒添加。所以低級別發現和自動發現這兩個功能是非常有用的，它能大大提升監控的準確性和及時性。
全棧級的監控。前文提到了我們需要監控的平臺以及在每個平臺中不同的產品。我們的確可以搭建多套獨立的平臺去完成監控，但是能否有一個平臺可以實現全棧級統一的監控？Zabbix可以。
可定製。現在很多企業都在引入DevOps流水線，但很少有將監控納入其中的。監控在整個DevOps流水線中應該是一個重要構成部分，因為CI/CD更多偏向於持續交付，但是交付完之後對於運維人員來說，還需要進行持續監控。Zabbix提供了標準的API可以和DevOps流水線做一個很好的集成。
四. 最佳實踐&案例分享
最後，分享一下關於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可以通過這種方式做自動化帶外管理。帶外管理痛點如下：
不靠譜! 機房人工巡檢不及時、有遺漏。
太坑爹! 固件缺陷等潛在問題無法及時發現。
太繁瑣!HP、DELL、Huawei等多套管理平臺，無法統一。
成本高! 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流水線上的系統的高度集成，實現了全棧式無感知的監控。
現在我們有越來越多的中文文檔，越來越多的Zabbix中文社區的夥伴正在貢獻自己的一些心得，社區資源比較豐富，也有定期的線下活動，大家有興趣的話可以關注一下開源社區的公眾號。
閱讀更多 高效運維 的文章
