小公尺自動化運維平台演進設計思路

2021-09-17 04:56:40 字數 3094 閱讀 2900

現如今,隨著雲計算和分布式的落地和發展,越來越多的伺服器都轉到雲上,微服務架構的落地也讓現在的 it 系統架構越來越複雜。我們的服務、應用所面對的規模也越來越大,這樣的需求需要強大的運維管控系統在後面支撐。

智慧型運維(aiops)的概念現在很火,旨在借助人工智慧機器學習和演算法將it運維人員從繁重的工作中解救出來,但是對於智慧型運維大家都在探索當中,aiops的技術並不是很成熟。大多數企業還處在對自動化運維的需求迫在眉睫的階段,需要運用專業化、標準化和流程化的手段來實現運維工作的自動化管理。因此本次infoq記者採訪了小公尺資深架構師孫寅,和大家一起了解小公尺的自動化運維平台是如何演進的。

小公尺自動化運維平台從2023年開始建設。截止目前,小公尺有300+業務線,5w+伺服器規模。6年裡伴隨著網際網路業務的陡峭增長,小公尺運維平台也發生了天翻地覆的變化。平台整體建設情況大致可以分為三個階段:

這個階段,平台主要在解決一些基礎痛點問題,如資產難以管理、軟硬體難以有效監控、人肉發布效率低下錯誤率高等,因此孵化了cmdb+服務樹、監控系統(falcon)、發布系統等幾個一直沿用至今的工具型平台的核心元件。並且借助推廣這幾個核心元件,對業務進行了基礎標準化。

在此階段,團隊逐步補齊了整個運維閉環中的各個環節,如預算交付、os自動安裝和環境初始化、網域名稱、負載均衡、備份等。並通過打通運維閉環中的各個環節和體系化設計,建設起了跨越系統的自動化體系,如伺服器交付自動初始化、各種場景的監控自動發現、發布和負載均衡變更聯動等等。

在此階段,以容器paas為標準化載體,構建自動化程度更高、能力更豐富、體系更內聚的基礎架構生態系統,包括:

配置管理(cmdb)由於和內部資產、環境、流程有比較緊密的耦合關係,業內也並沒有比較成熟的開源實現,因此基本完全自研。

部署發布系統使用了puppet對執行環境進行變更和管理,植入了god為每個程序提供自動恢復的能力,使用了docker來解決編譯一致性的問題,同時也支援了靜態發布docker容器。

小公尺早期使用了開源監控系統zabbix,但由於監控規模得擴大、監控場景得複雜化、配置難度大等原因,我們內部自研了監控系統falcon,也就是業內著名的企業級監控open-falcon。隨著使用場景得繼續豐富,目前也已支援監控資料旁路到elasticsearch、儀錶盤支援grafana,同時還在探尋資料儲存使用時序資料庫beringei,以支援更好的擴充套件性和便於實現更豐富的報警判別功能。

由於整體建設的規劃比較清晰,因此並沒有比較大的挑戰,如果一定要找,可能在於一些魔鬼細節上面。比如:

靈活的服務樹設計,並未能解決組織架構頻繁變更後帶來的樹結構混亂,同時因為體系中的各種系統都與服務樹有很強的耦合,以致後期不得不想辦法構建一棵新的組織結構樹,來為服務樹「打補丁」;

忽略了服務命名的posix規範,以致於一些嚴格遵守命名規則的開源元件出現了衝突。

標準化的問題,是所有平台體系的共通問題,無標準,不平台。早期平台標準化的主要有三個方向:

服務命名,這個標準主要是通過服務樹來完成的,體系中的各種系統也都統一使用相同的服務命名規範,因此服務命名逐漸就成了事實標準;

服務目錄,這個標準是通過部署發布系統來規範的,使用該系統的服務,會自動按照相應的規範生成目錄。目錄的標準化,也繼續推進了其他和執行環境有關的自動化系統的演進;

監控方法,這個標準是通過監控系統來實施的,各種型別場景的監控,都以遵循監控系統的監控協議來上報,並可實現為監控系統的外掛程式。

後期在dcos階段,由於服務都在容器雲內排程,執行環境高度內聚,很多標準可以由平台自動生成,標準化也就因此變得更加容易。

整個平台體系的設計思路一以貫之,各個系統間有很多聯合設計,以完成更長路徑的自動化,而不僅僅解決每乙個原子事務的自動化。例如:

小公尺的自動化運維平台主要指的是容器雲平台。眾所周知,基於docker、mesos、kubernetes等開源元件實現的容器雲平台,天生具有資源編排能力,對無狀態應用的擴容也無比簡單。

資源協調方面,我們增加了基於lvm的磁碟空間資源,以及基於tc模擬的頻寬控制資源,用於更精細化控制容器間的資源隔離。

擴容能力方面,小公尺的實現有一些時代的烙印,也有一些巧妙之處值得借鑑:

早期使用mesos的batch任務框架chronos,來實現定時擴縮容能力。這種方式比較巧妙地解決了實現定時難以解決的分布式容錯問題;

用falcon的集群監控策略+觸發鉤子,作為自動擴縮容的條件,這樣繼承了業務已有的監控指標和監控策略,同時還可自動作為抑制報警的條件。

舉例說明這種方案的聯動效果:

上圖為某服務的自動擴縮配置,由於業務**按照監控標準,已上報了jobalarmcount指標,因此系統可與監控系統對接,直接使用該指標自動生成集群監控策略,並以此作為自動擴縮容的觸發條件。

該例中當jobalarmcount的集群平均值連續1次大於100,就觸發擴容,每次擴容5個例項,當連續5次小於5,就觸發縮容,每次縮容2個例項。每次觸發擴縮容,都通過報警機制傳送到uic.dev報警組,同時擴縮容的上下限,分別是50和20。

這樣的自動擴縮容配置,可以在業務出現容量問題時,快速(連續2次)觸發擴容,當業務恢復正常後,平緩觸發縮容。同時例項數量的上下限,用於保護資源和業務的可靠性。

前沿技術方面,小公尺自動化運維目前主要在探索這樣幾個方向:

service mesh(服務網格):通過把rpc框架可以完成的功能,下沉到基礎設施層,以便統一迭代建設,同時解決多語言棧難以統一的痛點;

故障精準報警(根因分析):業內有工程和機器學習兩個流派,我們選擇工程派,用動態cmdb+分布式跟蹤+決策樹來尋找根因;

故障自癒:在根因分析的基礎上,通過構建靈活的預案構築框架,逐步提公升可故障自癒的比例。

結合小公尺幾年間自動化運維平台建設的經驗,孫寅認為,當前這個技術時代,不管企業規模大或小,都建議不要繞開開源自造輪子。如果企業規模小,直接用開源元件來解決企業痛點,如果企業規模大,可以改進或借鑑開源元件以解決效能和擴充套件性類問題,將各種開源技術組裝、二次開發來解決複雜場景裡的功能需求。

同時無論起步處於哪個階段,都應該自訂標準,因為開源元件僅是解決某一類問題的痛點,但標準是未來讓元件協同,解決整體複雜場景問題的基礎。

作者簡介

小公尺自動化運維平台演進設計思路

嘉賓 孫寅 編輯 張嬋 小公尺自動化運維平台建設大致分為三個時期,整體建設的規劃比較清晰,能夠一以貫之。本文介紹了小公尺自動化運維平台的演進思路。現如今,隨著雲計算和分布式的落地和發展,越來越多的伺服器都轉到雲上,微服務架構的落地也讓現在的 it 系統架構越來越複雜。我們的服務 應用所面對的規模也越...

小公尺自動化運維平台演進設計思路

現如今,隨著雲計算和分布式的落地和發展,越來越多的伺服器都轉到雲上,微服務架構的落地也讓現在的 it 系統架構越來越複雜。我們的服務 應用所面對的規模也越來越大,這樣的需求需要強大的運維管控系統在後面支撐。智慧型運維 aiops 的概念現在很火,旨在借助人工智慧機器學習和演算法將it運維人員從繁重的...

小公尺自動化運維平台演進設計思路

現如今,隨著雲計算和分布式的落地和發展,越來越多的伺服器都轉到雲上,微服務架構的落地也讓現在的 it 系統架構越來越複雜。我們的服務 應用所面對的規模也越來越大,這樣的需求需要強大的運維管控系統在後面支撐。智慧型運維 aiops 的概念現在很火,旨在借助人工智慧機器學習和演算法將it運維人員從繁重的...