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

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

現現在，隨着雲計算和分佈式的落地和發展，愈來愈多的服務器都轉到雲上，微服務架構的落地也讓如今的 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+分佈式跟蹤+決策樹來尋找根因；

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

寫在最後

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

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

關於做者 孫寅，前百度資深架構師，曾負責百度運維平臺多子系統；現小米資深架構師，負責小米運維體系基礎架構、基礎平臺。