小米自動化運維平臺演進設計思路

本文從小米運維平臺功能、運維平臺架構設計、如何實現運維平臺標準化流程、運維平臺實踐等方面介紹了小米自動化平臺的演進過程。

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

智能運維(AIOps)的概念如今很火,旨在藉助人工智能機器學習和算法將IT運維人員從繁重的工做中解救出來,可是對於智能運維你們都在探索當中,AIOps的技術並非很成熟。大多數企業還處在對自動化運維的需求迫在眉睫的階段,須要運用專業化、標準化和流程化的手段來實現運維工做的自動化管理。所以本次InfoQ記者採訪了小米資深架構師孫寅,和你們一塊兒瞭解小米的自動化運維平臺是如何演進的。數據庫

背景介紹

小米自動化運維平臺從2013年開始建設。截止目前,小米有300+業務線,5W+服務器規模。6年裏伴隨着互聯網業務的陡峭增加,小米運維平臺也發生了天翻地覆的變化。平臺總體建設狀況大體能夠分爲三個階段:安全

一、工具型平臺(2013~2014年)服務器

這個階段,平臺主要在解決一些基礎痛點問題,如資產難以管理、軟硬件難以有效監控、人肉發佈效率低下錯誤率高等,所以孵化了CMDB+服務樹、監控系統(Falcon)、發佈系統等幾個一直沿用至今的工具型平臺的核心組件。而且藉助推廣這幾個核心組件,對業務進行了基礎標準化。網絡

二、體系化平臺 (2014~2015年)架構

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

三、數據中心操做系統(DCOS)(2016年至今)框架

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

監控:豐富細化了各類具體場景的監控,如公有云、網絡設備、南北/東西網絡、域名、負載均衡、容器集羣等;端到端訪問質量監控,模擬用戶真實訪問發現最後一千米問題;分佈式調用跟蹤監控,穿透式跟蹤故障點;精準報警和根因分析,整合各種型監控,依賴決策樹、機器學習等能力自動尋找根因;機器學習

服務組件:自助建立集羣,自動配置最佳實踐,具有故障自愈能力的服務組件,如MySQL、Redis、Memcached、Kafka、ES等;

CI/CD:打通整個開發、測試、交付鏈條的自動化Pipeline;

服務治理:流量路由、流量鏡像、服務保護、白名單、熔斷、鏈路跟蹤、服務拓撲

故障:故障注入、故障自愈、故障跟蹤。

平臺架構設計

整個平臺的體系架構,可參考下面圖示:


圖示底部是IaaS層的各類資源及其管理平臺,如網絡管理、多雲接入、域名、負載均衡等;

上面承載了龐大的PaaS體系,劃分爲四大部分,容器、應用、服務治理、故障容災;

左右兩側是一些公共能力,如CMDB、監控、安全;

配置管理(CMDB)因爲和內部資產、環境、流程有比較緊密的耦合關係,業內也並無比較成熟的開源實現,所以基本徹底自研;

部署發佈系統使用了Puppet對運行環境進行變動和管理,植入了God爲每一個進程提供自動恢復的能力,使用了Docker來解決編譯一致性的問題,同時也支持了靜態發佈Docker容器;

小米早期使用了開源監控系統Zabbix,但因爲監控規模得擴大、監控場景得複雜化、配置難度大等緣由,咱們內部自研了監控系統Falcon,也就是業內著名的企業級監控Open-Falcon。隨着使用場景得繼續豐富,目前也已支持監控數據旁路到ElasticSearch、儀表盤支持Grafana,同時還在探尋數據存儲使用時序數據庫Beringei,以支持更好的擴展性和便於實現更豐富的報警判別功能。

平臺建設難點

因爲總體建設的規劃比較清晰,所以並無比較大的挑戰,若是必定要找,可能在於一些魔鬼細節上面。好比靈活的服務樹設計,並未能解決組織架構頻繁變動後帶來的樹結構混亂,同時由於體系中的各類系統都與服務樹有很強的耦合,以至後期不得不想辦法構建一棵新的組織結構樹,來爲服務樹「打補丁」;再好比忽略了服務命名的POSIX規範,以至於一些嚴格遵照命名規則的開源組件出現了衝突。

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

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

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

三、監控方法,這個標準是經過監控系統來實施的,各類類型場景的監控,都以遵循監控系統的監控協議來上報,並可實現爲監控系統的插件。

後期在DCOS階段,因爲服務都在容器雲內調度,運行環境高度內聚,不少標準能夠由平臺自動生成,標準化也就所以變得更加容易。

整個平臺體系的設計思路,可以一以貫之,各個系統間有不少聯合設計,以完成更長路徑的自動化,而不只僅解決每個原子事務的自動化。好比預算交付系統,和服務樹、監控系統配合,達到自動監控基礎監控項的能力;再好比,域名系統、負載均衡系統、雲對接系統、發佈系統配合,達到自動配置管理接入層的能力;還有,動態CMDB、分佈式跟蹤、決策樹配合,獲得故障精準定位能力。

平臺實踐

小米的自動化運維平臺主要指的是容器雲平臺。衆所周知,基於Docker、Mesos、kubernetes等開源組件實現的容器雲平臺,天生具備資源編排能力,對無狀態應用的擴容也無比簡單。

資源協調方面,咱們增長了基於LVM的磁盤空間資源,以及基於tc模擬的帶寬控制資源,用於更精細化控制容器間的資源隔離;

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

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

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

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


上圖爲某服務的自動擴縮配置,因爲業務代碼按照監控標準,已上報了JobAlarmCount指標,所以系統可與監控系統對接,直接使用該指標自動生成集羣監控策略,並以此做爲自動擴縮容的觸發條件。

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

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

小米自動化運維的技術探索

前沿技術方面,目前主要在探索這樣幾個方向:

混沌工程:對於天天層出不窮的可靠性問題,依靠人(SRE)的經驗天天去排除,是既不靠譜也不經濟的方式。混沌工程是把經驗轉化爲探索規則,對在線系統進行或計劃或隨機的應用探索,來學習觀察系統的反應,以發現系統不可靠因素的工程體系;

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

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

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

寫在最後

結合小米幾年間自動化運維平臺建設的經驗,孫寅認爲,當前這個技術時代,無論企業規模大或小,都建議不要繞開開源自造輪子。若是企業規模小,直接用開源組件來解決企業痛點,若是企業規模大,能夠改進或借鑑開源組件以解決性能和擴展性類問題,將各類開源技術組裝、二次開發來解決複雜場景裏的功能需求。

同時不管起步處於哪一個階段,都應該自訂標準,由於開源組件僅是解決某一類問題的痛點,但標準是將來讓組件協同,解決總體複雜場景問題的基礎。

關於做者 孫寅,前百度資深架構師,曾負責百度運維平臺多子系統;現小米資深架構師,負責小米運維體系基礎架構、基礎平臺。
相關文章
相關標籤/搜索