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流水線上的系統的高度內建，實作了全棧式無感覺的監控。
原文釋出時間為：2018-11-14
本文來自雲栖社群合作夥伴“
高效運維”，了解相關資訊可以關注“
”。