嘉賓 | 孫寅
編輯 | 張嬋
小公尺自動化運維平台建設大致分為三個時期，整體建設的規劃比較清晰，能夠一以貫之。本文介紹了小公尺自動化運維平台的演進思路。
現如今，隨著雲計算和分布式的落地和發展，越來越多的伺服器都轉到雲上，微服務架構的落地也讓現在的 it 系統架構越來越複雜。我們的服務、應用所面對的規模也越來越大，這樣的需求需要強大的運維管控系統在後面支撐。
智慧型運維（aiops）的概念現在很火，旨在借助人工智慧機器學習和演算法將 it 運維人員從繁重的工作中解救出來，但是對於智慧型運維大家都在探索當中，aiops 的技術並不是很成熟。大多數企業還處在對自動化運維的需求迫在眉睫的階段，需要運用專業化、標準化和流程化的手段來實現運維工作的自動化管理。因此本次 infoq 記者採訪了小公尺資深架構師孫寅，和大家一起了解小公尺的自動化運維平台是如何演進的。
小公尺自動化運維平台從 2013 年開始建設。截止目前，小公尺有 300+ 業務線，5w+ 伺服器規模。6 年裡伴隨著網際網路業務的陡峭增長，小公尺運維平台也發生了天翻地覆的變化。平台整體建設情況大致可以分為三個階段：
這個階段，平台主要在解決一些基礎痛點問題，如資產難以管理、軟硬體難以有效監控、人肉發布效率低下錯誤率高等，因此孵化了 cmdb+ 服務樹、監控系統（falcon）、發布系統等幾個一直沿用至今的工具型平台的核心元件。並且借助推廣這幾個核心元件，對業務進行了基礎標準化。
在此階段，團隊逐步補齊了整個運維閉環中的各個環節，如預算交付、os 自動安裝和環境初始化、網域名稱、負載均衡、備份等。並通過打通運維閉環中的各個環節和體系化設計，建設起了跨越系統的自動化體系，如伺服器交付自動初始化、各種場景的監控自動發現、發布和負載均衡變更聯動等等。
在此階段，以容器 paas 為標準化載體，構建自動化程度更高、能力更豐富、體系更內聚的基礎架構生態系統，包括：
公有雲、網路裝置、南北 / 東西網路、網域名稱、負載均衡、容器集群等；
端到端訪問質量監控，模擬使用者真實訪問發現最後一公里問題；
分布式呼叫跟蹤監控，穿透式跟蹤故障點；
精準報警和根因分析，整合各型別監控，依賴決策樹、機器學習等能力自動尋找根因。
配置管理（cmdb）由於和內部資產、環境、流程有比較緊密的耦合關係，業內也並沒有比較成熟的開源實現，因此基本完全自研。
部署發布系統使用了 puppet 對執行環境進行變更和管理，植入了 god 為每個程序提供自動恢復的能力，使用了 docker 來解決編譯一致性的問題，同時也支援了靜態發布 docker 容器。
小公尺早期使用了開源監控系統 zabbix，但由於監控規模得擴大、監控場景得複雜化、配置難度大等原因，我們內部自研了監控系統 falcon，也就是業內著名的企業級監控 open-falcon。隨著使用場景得繼續豐富，目前也已支援監控資料旁路到 elasticsearch、儀錶盤支援 grafana，同時還在探尋資料儲存使用時序資料庫 beringei，以支援更好的擴充套件性和便於實現更豐富的報警判別功能。
由於整體建設的規劃比較清晰，因此並沒有比較大的挑戰，如果一定要找，可能在於一些魔鬼細節上面。比如：
靈活的服務樹設計，並未能解決組織架構頻繁變更後帶來的樹結構混亂，同時因為體系中的各種系統都與服務樹有很強的耦合，以致後期不得不想辦法構建一棵新的組織結構樹，來為服務樹「打補丁」；
忽略了服務命名的 posix 規範，以致於一些嚴格遵守命名規則的開源元件出現了衝突。
標準化的問題，是所有平台體系的共通問題，無標準，不平台。早期平台標準化的主要有三個方向：
後期在 dcos 階段，由於服務都在容器雲內排程，執行環境高度內聚，很多標準可以由平台自動生成，標準化也就因此變得更加容易。
整個平台體系的設計思路一以貫之，各個系統間有很多聯合設計，以完成更長路徑的自動化，而不僅僅解決每乙個原子事務的自動化。例如：
預算交付系統，和服務樹、監控系統配合，達到自動監控基礎監控項的能力；
網域名稱系統、負載均衡系統、雲對接系統、發布系統配合，達到自動配置管理接入層的能力；
還有，動態 cmdb、分布式跟蹤、決策樹配合，得到故障精準定位能力。
小公尺的自動化運維平台主要指的是容器雲平台。眾所周知，基於 docker、mesos、kubernetes 等開源元件實現的容器雲平台，天生具有資源編排能力，對無狀態應用的擴容也無比簡單。
資源協調方面，我們增加了基於 lvm 的磁碟空間資源，以及基於 tc 模擬的頻寬控制資源，用於更精細化控制容器間的資源隔離。
擴容能力方面，小公尺的實現有一些時代的烙印，也有一些巧妙之處值得借鑑：
舉例說明這種方案的聯動效果：
上圖為某服務的自動擴縮配置，由於業務**按照監控標準，已上報了 jobalarmcount 指標，因此系統可與監控系統對接，直接使用該指標自動生成集群監控策略，並以此作為自動擴縮容的觸發條件。
該例中當 jobalarmcount 的集群平均值連續 1 次大於 100，就觸發擴容，每次擴容 5 個例項，當連續 5 次小於 5，就觸發縮容，每次縮容 2 個例項。每次觸發擴縮容，都通過報警機制傳送到 uic.dev 報警組，同時擴縮容的上下限，分別是 50 和 20。這樣的自動擴縮容配置，可以在業務出現容量問題時，快速（連續 2 次）觸發擴容，當業務恢復正常後，平緩觸發縮容。同時例項數量的上下限，用於保護資源和業務的可靠性。
前沿技術方面，小公尺自動化運維目前主要在探索這樣幾個方向：
service mesh（服務網格）：通過把 rpc 框架可以完成的功能，下沉到基礎設施層，以便統一迭代建設，同時解決多語言棧難以統一的痛點；
故障精準報警（根因分析）：業內有工程和機器學習兩個流派，我們選擇工程派，用動態 cmdb+ 分布式跟蹤 + 決策樹來尋找根因；
故障自癒：在根因分析的基礎上，通過構建靈活的預案構築框架，逐步提公升可故障自癒的比例。
結合小公尺幾年間自動化運維平台建設的經驗，孫寅認為，當前這個技術時代，不管企業規模大或小，都建議不要繞開開源自造輪子。如果企業規模小，直接用開源元件來解決企業痛點，如果企業規模大，可以改進或借鑑開源元件以解決效能和擴充套件性類問題，將各種開源技術組裝、二次開發來解決複雜場景裡的功能需求。
同時無論起步處於哪個階段，都應該自訂標準，因為開源元件僅是解決某一類問題的痛點，但標準是未來讓元件協同，解決整體複雜場景問題的基礎。
作者簡介
小公尺自動化運維平台演進設計思路
現如今，隨著雲計算和分布式的落地和發展，越來越多的伺服器都轉到雲上，微服務架構的落地也讓現在的 it 系統架構越來越複雜。我們的服務 應用所面對的規模也越來越大，這樣的需求需要強大的運維管控系統在後面支撐。智慧型運維 aiops 的概念現在很火，旨在借助人工智慧機器學習和演算法將it運維人員從繁重的...
小公尺自動化運維平台演進設計思路
現如今，隨著雲計算和分布式的落地和發展，越來越多的伺服器都轉到雲上，微服務架構的落地也讓現在的 it 系統架構越來越複雜。我們的服務 應用所面對的規模也越來越大，這樣的需求需要強大的運維管控系統在後面支撐。智慧型運維 aiops 的概念現在很火，旨在借助人工智慧機器學習和演算法將it運維人員從繁重的...
小公尺自動化運維平台演進設計思路
現如今，隨著雲計算和分布式的落地和發展，越來越多的伺服器都轉到雲上，微服務架構的落地也讓現在的 it 系統架構越來越複雜。我們的服務 應用所面對的規模也越來越大，這樣的需求需要強大的運維管控系統在後面支撐。智慧型運維 aiops 的概念現在很火，旨在借助人工智慧機器學習和演算法將it運維人員從繁重的...