小米自动化运维平台演进设计思路
嘉賓 | 孫寅
編輯 | 張嬋
小米自動化運維平臺建設大致分為三個時期，整體建設的規(guī)劃比較清晰，能夠一以貫之。本文介紹了小米自動化運維平臺的演進思路。
現(xiàn)如今，隨著云計算和分布式的落地和發(fā)展，越來越多的服務器都轉到云上，微服務架構的落地也讓現(xiàn)在的 IT 系統(tǒng)架構越來越復雜。我們的服務、應用所面對的規(guī)模也越來越大，這樣的需求需要強大的運維管控系統(tǒng)在后面支撐。
智能運維（AIOps）的概念現(xiàn)在很火，旨在借助人工智能機器學習和算法將 IT 運維人員從繁重的工作中解救出來，但是對于智能運維大家都在探索當中，AIOps 的技術并不是很成熟。大多數(shù)企業(yè)還處在對自動化運維的需求迫在眉睫的階段，需要運用專業(yè)化、標準化和流程化的手段來實現(xiàn)運維工作的自動化管理。因此本次 InfoQ 記者采訪了小米資深架構師孫寅，和大家一起了解小米的自動化運維平臺是如何演進的。
背景介紹
小米自動化運維平臺從 2013 年開始建設。截止目前，小米有 300+ 業(yè)務線，5W+ 服務器規(guī)模。6 年里伴隨著互聯(lián)網(wǎng)業(yè)務的陡峭增長，小米運維平臺也發(fā)生了天翻地覆的變化。平臺整體建設情況大致可以分為三個階段：
?1. 工具型平臺（2013~2014 年）
這個階段，平臺主要在解決一些基礎痛點問題，如資產(chǎn)難以管理、軟硬件難以有效監(jiān)控、人肉發(fā)布效率低下錯誤率高等，因此孵化了 CMDB+ 服務樹、監(jiān)控系統(tǒng)（Falcon）、發(fā)布系統(tǒng)等幾個一直沿用至今的工具型平臺的核心組件。并且借助推廣這幾個核心組件，對業(yè)務進行了基礎標準化。
?2. 體系化平臺 （2014～2015 年）
在此階段，團隊逐步補齊了整個運維閉環(huán)中的各個環(huán)節(jié)，如預算交付、OS 自動安裝和環(huán)境初始化、域名、負載均衡、備份等。并通過打通運維閉環(huán)中的各個環(huán)節(jié)和體系化設計，建設起了跨越系統(tǒng)的自動化體系，如服務器交付自動初始化、各種場景的監(jiān)控自動發(fā)現(xiàn)、發(fā)布和負載均衡變更聯(lián)動等等。
?3. 數(shù)據(jù)中心操作系統(tǒng)（DCOS）（2016 年至今）
在此階段，以容器 PaaS 為標準化載體，構建自動化程度更高、能力更豐富、體系更內聚的基礎架構生態(tài)系統(tǒng)，包括：
-
監(jiān)控：豐富細化了各種具體場景的監(jiān)控，如：
公有云、網(wǎng)絡設備、南北 / 東西網(wǎng)絡、域名、負載均衡、容器集群等；
端到端訪問質量監(jiān)控，模擬用戶真實訪問發(fā)現(xiàn)最后一公里問題；
分布式調用跟蹤監(jiān)控，穿透式跟蹤故障點；
精準報警和根因分析，整合各類型監(jiān)控，依賴決策樹、機器學習等能力自動尋找根因。
-
服務組件：自助創(chuàng)建集群，自動配置最佳實踐，具備故障自愈能力的服務組件，如 MySQL、Redis、Memcached、Kafka、ES 等；
-
CI/CD：打通整個開發(fā)、測試、交付鏈條的自動化 Pipeline；
-
服務治理：流量路由、流量鏡像、服務保護、白名單、熔斷、鏈路跟蹤、服務拓撲；
-
故障：故障注入、故障自愈、故障跟蹤。
平臺架構設計
小米自動化運維平臺的整個平臺體系架構，可參考下面圖示：
-
圖示底部是 IaaS 層的各種資源及其管理平臺，如網(wǎng)絡管理、多云接入、域名、負載均衡等。
-
上面承載了龐大的 PaaS 體系，劃分為四大部分，容器、應用、服務治理、故障容災。
-
左右兩側是一些公共能力，如 CMDB、監(jiān)控、安全。
配置管理（CMDB）由于和內部資產(chǎn)、環(huán)境、流程有比較緊密的耦合關系，業(yè)內也并沒有比較成熟的開源實現(xiàn)，因此基本完全自研。
部署發(fā)布系統(tǒng)使用了 Puppet 對運行環(huán)境進行變更和管理，植入了 God 為每個進程提供自動恢復的能力，使用了 Docker 來解決編譯一致性的問題，同時也支持了靜態(tài)發(fā)布 Docker 容器。
小米早期使用了開源監(jiān)控系統(tǒng) Zabbix，但由于監(jiān)控規(guī)模得擴大、監(jiān)控場景得復雜化、配置難度大等原因，我們內部自研了監(jiān)控系統(tǒng) Falcon，也就是業(yè)內著名的企業(yè)級監(jiān)控 Open-Falcon。隨著使用場景得繼續(xù)豐富，目前也已支持監(jiān)控數(shù)據(jù)旁路到 ElasticSearch、儀表盤支持 Grafana，同時還在探尋數(shù)據(jù)存儲使用時序數(shù)據(jù)庫 Beringei，以支持更好的擴展性和便于實現(xiàn)更豐富的報警判別功能。
平臺建設的難點
由于整體建設的規(guī)劃比較清晰，因此并沒有比較大的挑戰(zhàn)，如果一定要找，可能在于一些魔鬼細節(jié)上面。比如：
靈活的服務樹設計，并未能解決組織架構頻繁變更后帶來的樹結構混亂，同時因為體系中的各種系統(tǒng)都與服務樹有很強的耦合，以致后期不得不想辦法構建一棵新的組織結構樹，來為服務樹“打補丁”；
忽略了服務命名的 POSIX 規(guī)范，以致于一些嚴格遵守命名規(guī)則的開源組件出現(xiàn)了沖突。
標準化的問題，是所有平臺體系的共通問題，無標準，不平臺。早期平臺標準化的主要有三個方向：
-
服務命名，這個標準主要是通過服務樹來完成的，體系中的各種系統(tǒng)也都統(tǒng)一使用相同的服務命名規(guī)范，因此服務命名逐漸就成了事實標準；
-
服務目錄，這個標準是通過部署發(fā)布系統(tǒng)來規(guī)范的，使用該系統(tǒng)的服務，會自動按照相應的規(guī)范生成目錄。目錄的標準化，也繼續(xù)推進了其他和運行環(huán)境有關的自動化系統(tǒng)的演進；
-
監(jiān)控方法，這個標準是通過監(jiān)控系統(tǒng)來實施的，各種類型場景的監(jiān)控，都以遵循監(jiān)控系統(tǒng)的監(jiān)控協(xié)議來上報，并可實現(xiàn)為監(jiān)控系統(tǒng)的插件。
后期在 DCOS 階段，由于服務都在容器云內調度，運行環(huán)境高度內聚，很多標準可以由平臺自動生成，標準化也就因此變得更加容易。
整個平臺體系的設計思路一以貫之，各個系統(tǒng)間有很多聯(lián)合設計，以完成更長路徑的自動化，而不僅僅解決每一個原子事務的自動化。例如：
預算交付系統(tǒng)，和服務樹、監(jiān)控系統(tǒng)配合，達到自動監(jiān)控基礎監(jiān)控項的能力；
域名系統(tǒng)、負載均衡系統(tǒng)、云對接系統(tǒng)、發(fā)布系統(tǒng)配合，達到自動配置管理接入層的能力；
還有，動態(tài) CMDB、分布式跟蹤、決策樹配合，得到故障精準定位能力。
平臺實踐
小米的自動化運維平臺主要指的是容器云平臺。眾所周知，基于 Docker、Mesos、kubernetes 等開源組件實現(xiàn)的容器云平臺，天生具有資源編排能力，對無狀態(tài)應用的擴容也無比簡單。
資源協(xié)調方面，我們增加了基于 LVM 的磁盤空間資源，以及基于 tc 模擬的帶寬控制資源，用于更精細化控制容器間的資源隔離。
擴容能力方面，小米的實現(xiàn)有一些時代的烙印，也有一些巧妙之處值得借鑒：
-
早期使用 Mesos 的 Batch 任務框架 Chronos，來實現(xiàn)定時擴縮容能力。這種方式比較巧妙地解決了實現(xiàn)定時難以解決的分布式容錯問題；
-
用 Falcon 的集群監(jiān)控策略 + 觸發(fā)鉤子，作為自動擴縮容的條件，這樣繼承了業(yè)務已有的監(jiān)控指標和監(jiān)控策略，同時還可自動作為抑制報警的條件。
舉例說明這種方案的聯(lián)動效果：
上圖為某服務的自動擴縮配置，由于業(yè)務代碼按照監(jiān)控標準，已上報了 JobAlarmCount 指標，因此系統(tǒng)可與監(jiān)控系統(tǒng)對接，直接使用該指標自動生成集群監(jiān)控策略，并以此作為自動擴縮容的觸發(fā)條件。
該例中當 JobAlarmCount 的集群平均值連續(xù) 1 次大于 100，就觸發(fā)擴容，每次擴容 5 個實例，當連續(xù) 5 次小于 5，就觸發(fā)縮容，每次縮容 2 個實例。每次觸發(fā)擴縮容，都通過報警機制發(fā)送到 uic.dev 報警組，同時擴縮容的上下限，分別是 50 和 20。這樣的自動擴縮容配置，可以在業(yè)務出現(xiàn)容量問題時，快速（連續(xù) 2 次）觸發(fā)擴容，當業(yè)務恢復正常后，平緩觸發(fā)縮容。同時實例數(shù)量的上下限，用于保護資源和業(yè)務的可靠性。
小米自動化運維的技術探索
前沿技術方面，小米自動化運維目前主要在探索這樣幾個方向：
混沌工程：對于每天層出不窮的可靠性問題，依靠人（SRE）的經(jīng)驗每天去排除，是既不靠譜也不經(jīng)濟的方式。混沌工程是把經(jīng)驗轉化為探索規(guī)則，對在線系統(tǒng)進行或計劃或隨機的應用探索，來學習觀察系統(tǒng)的反應，以發(fā)現(xiàn)系統(tǒng)不可靠因素的工程體系；
Service Mesh（服務網(wǎng)格）：通過把 RPC 框架可以完成的功能，下沉到基礎設施層，以便統(tǒng)一迭代建設，同時解決多語言棧難以統(tǒng)一的痛點；
故障精準報警（根因分析）：業(yè)內有工程和機器學習兩個流派，我們選擇工程派，用動態(tài) CMDB+ 分布式跟蹤 + 決策樹來尋找根因；
故障自愈：在根因分析的基礎上，通過構建靈活的預案構筑框架，逐步提升可故障自愈的比例。
寫在最后
結合小米幾年間自動化運維平臺建設的經(jīng)驗，孫寅認為，當前這個技術時代，不管企業(yè)規(guī)模大或小，都建議不要繞開開源自造輪子。如果企業(yè)規(guī)模小，直接用開源組件來解決企業(yè)痛點，如果企業(yè)規(guī)模大，可以改進或借鑒開源組件以解決性能和擴展性類問題，將各種開源技術組裝、二次開發(fā)來解決復雜場景里的功能需求。
同時無論起步處于哪個階段，都應該自訂標準，因為開源組件僅是解決某一類問題的痛點，但標準是未來讓組件協(xié)同，解決整體復雜場景問題的基礎。
作者簡介
孫寅，前百度資深架構師，曾負責百度運維平臺多子系統(tǒng)；現(xiàn)小米資深架構師，負責小米運維體系基礎架構、基礎平臺。
總結
以上是生活随笔為你收集整理的小米自动化运维平台演进设计思路的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 不止 JDK7 的 HashMap ，J
- 下一篇： 减少该死的 if else 嵌套