簡(jiǎn)單來理解，自動(dòng)化運(yùn)維就是要通過機(jī)器的方式來簡(jiǎn)化整體的運(yùn)維過程，特別是優(yōu)化重復(fù)類型的工作，以提高運(yùn)維效率，減少因人工而引起的失誤操作。隨著運(yùn)維管理的復(fù)雜度和難度增大，自動(dòng)化運(yùn)維也基本成為了運(yùn)維平臺(tái)演進(jìn)的必經(jīng)之路。但如何落地自動(dòng)化運(yùn)維平臺(tái)，不同的企業(yè)因?yàn)檫\(yùn)維發(fā)展階段和業(yè)務(wù)體量的不同，都有不一樣的實(shí)現(xiàn)路徑。

　　以京東為例，它的物流系統(tǒng)有很多分支機(jī)構(gòu)， 比如倉(cāng)庫(kù)、分撥中心、轉(zhuǎn)運(yùn)中心等， 業(yè)務(wù)復(fù)雜的分支機(jī)構(gòu)可能會(huì)有自己的信息系統(tǒng)， 這些信息系統(tǒng)往往分布式地部署到全國(guó)各地，那如何基于自動(dòng)化運(yùn)維平臺(tái)管理好這些分支機(jī)構(gòu)的服務(wù)器、 信息系統(tǒng)， 降低因?yàn)榈赜蚍植荚斐傻倪\(yùn)維維護(hù)成本呢?京東資深架構(gòu)師趙玉開向 InfoQ 記者深入介紹了他們?cè)谧詣?dòng)化運(yùn)維平臺(tái)方面的一些探索和實(shí)踐。另外，趙玉開也將會(huì)在 9 月 10 日舉行的 CNUTCon 全球運(yùn)維技術(shù)大會(huì) 上分享相關(guān)話題，歡迎關(guān)注。

　　InfoQ：可以先介紹下目前京東物流系統(tǒng)自動(dòng)化運(yùn)維平臺(tái)的一些基本情況嗎?

　　趙玉開：京東物流系統(tǒng)自動(dòng)化運(yùn)維平臺(tái)從 2014 年開始啟動(dòng)到現(xiàn)在已經(jīng)歷了三各階段，到目前管理了 MySQL、JMQ、 Redis 及自研應(yīng)用等多種實(shí)例。

　　眾所周知，京東業(yè)務(wù)發(fā)展迅猛，每周都需要開倉(cāng)，數(shù)量多達(dá)十幾個(gè)。最初開倉(cāng)過程特別冗長(zhǎng)和復(fù)雜，開倉(cāng)過程中涉及到研發(fā)人員部署系統(tǒng)、運(yùn)營(yíng)人員手動(dòng)填寫多種申請(qǐng)、運(yùn)維人員不僅要負(fù)責(zé)中間件安裝，還要負(fù)責(zé)整個(gè)流程中每個(gè)環(huán)節(jié)的進(jìn)展確認(rèn)及協(xié)調(diào)，這直接導(dǎo)致了開倉(cāng)慢，且涉及到的各部門都需要投入大量的人力成本。

　　基于此，2014 年初我們啟動(dòng)了一期自動(dòng)化運(yùn)維平臺(tái)研發(fā)的項(xiàng)目，2014 年 10 月項(xiàng)目一期上線時(shí)，已基本解決了開倉(cāng)慢和人力成本的問題，也減少了開倉(cāng)過程中運(yùn)維同學(xué)的重復(fù)性工作內(nèi)容，制定標(biāo)準(zhǔn)化模板，解放了研發(fā)人員的重復(fù)性部署工作。運(yùn)營(yíng)人員可通過模板直接設(shè)置，將之前一些繁瑣的密碼、JMQ Token 等數(shù)據(jù)實(shí)現(xiàn)自動(dòng)化配置，大大減少了流程耗費(fèi)的時(shí)間。

　　一期上線后，得到了流程中各環(huán)節(jié)涉及部門的贊賞，并在得到大家積極反饋后，迅速進(jìn)入到二期項(xiàng)目。二期項(xiàng)目完成后，數(shù)據(jù)的初始化問題和研發(fā)日常批量部署問題也得到了解決，系統(tǒng)的自動(dòng)化程度已可以滿足日常的工作需求。

　　今年初，為接入更多物流作業(yè)單位，如分揀中心， 亞洲一號(hào)自動(dòng)化物流中心等，我們開啟了三期項(xiàng)目，目前項(xiàng)目還在持續(xù)前行中。

　　InfoQ：談?wù)勀銈兊淖詣?dòng)化運(yùn)維架構(gòu)?以及具體涉及到的技術(shù)棧?

　　我們的自動(dòng)化運(yùn)維的核心組件是 SaltStack， 我們基于 SaltStack 做了很多自定義的模塊、Grains 和 Runner， 通過這些自定義的模塊、Grains 以及 Runner 來支撐我們的開倉(cāng)、部署、數(shù)據(jù)同步等功能。

　　如下圖是一個(gè)指令執(zhí)行過程圖， 分為兩個(gè)部分， 上面部分為部署在 IDC 的模塊， 下半部分則是部署在庫(kù)房機(jī)房的模塊。

　　我們先逐個(gè)介紹部署在 IDC 部分的模塊：

　　Web 使用 Java 技術(shù)， 為用戶提供操作界面， 控制操作權(quán)限， 使用 Activiti 工作流引擎驅(qū)動(dòng)各種流程， 下發(fā)開倉(cāng)過程中的自動(dòng)化運(yùn)維指令。

　　Salt-API-Proxy 是 Salt-API 的代理層， 通過 Nginx 實(shí)現(xiàn)了反向代理， 在 Nginx 的配置中對(duì)發(fā)送指令的服務(wù)器 IP 做了限制， 另外可以通過配置指向工作的 Salt-API 服務(wù)器。

　　Salt-API 負(fù)責(zé)和 Salt-Master 交互發(fā)送 SaltStack 的 Runner 與 Module 的 API 指令， Runner 指令是運(yùn)行在 Salt-Master 服務(wù)器上的， 可以讀取 master 配置， 也可以在一個(gè) Runner 中協(xié)調(diào)執(zhí)行多個(gè) Module 運(yùn)行結(jié)果。

　　Salt-Master 有兩個(gè)職責(zé)， 一是接受 salt-api 指令， runner 在本地執(zhí)行， module 下發(fā)指令到對(duì)應(yīng)的 salt-minion， 另一職責(zé)是運(yùn)維同學(xué)手動(dòng)下發(fā)指令， 完成一些非常見的 minion 配置工作。

　　RsyncServer 負(fù)責(zé)中間件安裝文件， 自研軟件的文件存儲(chǔ)和下發(fā)， RsyncServer 的文件存儲(chǔ)是由 Salt-Master 發(fā)起的， Salt-Master 接受到 salt-api 的應(yīng)用部署指令后， 會(huì)從部署指令中獲得部署包下載地址， 然后下載到指定部署包存儲(chǔ)目錄， 并做解壓操作; RsyncServer 的文件下發(fā)指令則是有 salt-minion 端的 Module 執(zhí)行觸發(fā)的

　　倉(cāng)庫(kù)部門和 IDC 之間通過 VPN 聯(lián)通， 每個(gè)倉(cāng)庫(kù)的服務(wù)器上都安裝了 SaltStack 的 minion 端， minion 端是一個(gè) Python 進(jìn)程， 負(fù)責(zé)接收 Master 的 Module 指令， 并在本地執(zhí)行。另外 minion 端在執(zhí)行指令過程中需要將執(zhí)行過程中的輸出及時(shí)的輸出給用戶端， 讓用戶可以通過 Web 端查看執(zhí)行過程的情況， 即運(yùn)維的可視化， 我們是通過 minion 端的可視化模塊， 將執(zhí)行過程輸出通過 HTTP POST 方式發(fā)送給 Web 端， Web 端將 POST 內(nèi)容存儲(chǔ)到任務(wù)執(zhí)行過程輸出表中， 前端通過輪詢方式讀取輸出表中的增量消息顯示給用戶端。

　　我們采用的技術(shù)棧是 Java + Python。 前端界面展示、 工作流、權(quán)限控制、任務(wù)下發(fā)這些都是用的 Java 的 Spring MVC + MyBatis; 后端用的是 Python + Shell， Python 寫了大量的 SaltStack 自定義模塊。

　　InfoQ：為什么當(dāng)初要選擇 SaltStack 而沒有選擇 Ansible?

　　不可否認(rèn) Ansible 也是一個(gè)非常好的自動(dòng)化運(yùn)維工具， 但是基于以下兩點(diǎn)我們最終選擇了 SaltStack。

　　API 的易用性方面和 SaltStack 有差距， 我們的自動(dòng)化運(yùn)維系統(tǒng)一開始就有一個(gè)目標(biāo)， 將開倉(cāng)部署以及推廣版本這些功能開放給物流運(yùn)營(yíng)人員， 所以必須做好前端用戶體驗(yàn)， 這需要好用的 API， SaltStack 恰好有。

　　性能，標(biāo)準(zhǔn) SSH 連接的時(shí)候比較耗時(shí)，ZeroMQ 傳輸?shù)乃俣葧?huì)快很多。

　　InfoQ：在應(yīng)用部署自動(dòng)化這塊，你們是怎么做的?

　　應(yīng)用部署大致分為這么幾個(gè)步驟： 打包、下發(fā)文件、更新配置、停止啟動(dòng)實(shí)例、備份部署版本， 具體如下。

　　我們使用的公司統(tǒng)一的打包系統(tǒng)， 打包系統(tǒng)打好包， 部署任務(wù)審批通過，自動(dòng)化運(yùn)維系統(tǒng)就可以通過 API 獲得打包文件， 然后將部署包上傳到版本服務(wù)器， 并解壓縮，放到對(duì)應(yīng)版本目錄下。

　　通過 SaltStack 的 API 下發(fā)部署指令給部署目標(biāo)服務(wù)器， 部署指令是一個(gè) SaltStack 自定義模塊， 該模塊首先會(huì)執(zhí)行 rsync 指令從版本服務(wù)器上同步變更文件。

　　文件下發(fā)之后更新配置， 通過 Web 接口請(qǐng)求自動(dòng)化運(yùn)維的 Web 端下發(fā)配置文件， 然后更新配置文件， 我們線上的配置文件是通過環(huán)境變量來配置的， 所以不管有多少個(gè)庫(kù)房， 都不需要更新配置文件， 只有在特殊需求是設(shè)置環(huán)境變量， 就可以依據(jù)當(dāng)前作業(yè)單位的不同改變下發(fā)的配置文件的內(nèi)容。

　　調(diào)用應(yīng)用的 stop.sh 腳本停止當(dāng)前實(shí)例， 再調(diào)用 start.sh 腳本啟動(dòng)實(shí)例， 這里有一個(gè)約定， 不管是 Web 應(yīng)用還是非 Web 應(yīng)用必須在部署目錄有一個(gè) bin 目錄下面有 start.sh 和 stop.sh 兩個(gè)文件。

　　如果步驟 4 執(zhí)行成功， 那么將此版本的文件備份到當(dāng)前服務(wù)器上， 以備回滾使用。

　　InfoQ：自動(dòng)化運(yùn)維解決了你們哪些問題?沒有解決哪些問題?

　　自動(dòng)化運(yùn)維解決了我們開倉(cāng)周期長(zhǎng)，人力成本高的問題， 提升了全國(guó)部署推廣的效率， 大大減少了運(yùn)維同事的重復(fù)性工作， 把對(duì)成熟版本的推廣工作交給了運(yùn)營(yíng)人員， 減少了研發(fā)同事在推廣上線工作上的時(shí)間。

　　現(xiàn)階段正在探索如何通過自動(dòng)化運(yùn)維技術(shù)快速排查問題， 另外就是我們未來會(huì)有一些自動(dòng)化的物流作業(yè)單位，如何用自動(dòng)化運(yùn)維平臺(tái)管理好這些自動(dòng)化的設(shè)備和設(shè)備軟件也是我們?cè)谔剿鞯摹?

　　InfoQ：自動(dòng)化運(yùn)維平臺(tái)上線了這么長(zhǎng)時(shí)間，有做過復(fù)盤嗎?有哪些經(jīng)驗(yàn)可以分享給讀者?未來有什么計(jì)劃?

　　做過一些復(fù)盤， 每一期開發(fā)結(jié)束下一迭代開始的時(shí)候都會(huì)做復(fù)盤， 對(duì)現(xiàn)有問題進(jìn)行總結(jié)， 同時(shí)收集下一步的需求。 目前看最深刻的體會(huì)是做自動(dòng)化運(yùn)維系統(tǒng)一定要做好元數(shù)據(jù)的管理，元數(shù)據(jù)要管理好服務(wù)器信息屬性、 應(yīng)用信息、應(yīng)用配置、實(shí)例管理以及作業(yè)單位， 這些元數(shù)據(jù)要在一開始就做好， 能自動(dòng)化收集的要自動(dòng)化收集， 動(dòng)態(tài)的參數(shù)一定要?jiǎng)討B(tài)控制， 比如 Redis、MySQL 都有主從關(guān)系， 元數(shù)據(jù)中要存儲(chǔ)這個(gè)主從關(guān)系， 但是不能寫死， 必須有機(jī)制來更新主從關(guān)系， 否則 Redis 哨兵程序更新了 Redis 主從關(guān)系， 或者 MySQL DBA 因?yàn)槟承┰蚯袚Q了 MySQL 的主從， 自動(dòng)化運(yùn)維系統(tǒng)的元數(shù)據(jù)沒有做對(duì)應(yīng)更新，再執(zhí)行指令時(shí)就會(huì)出問題， 甚至發(fā)生事故。

　　未來計(jì)劃有兩個(gè)方面：

　　繼續(xù)通過自動(dòng)化運(yùn)維系統(tǒng)來提升運(yùn)維效率、 降低研發(fā)對(duì)應(yīng)用運(yùn)維的投入。

　　做自動(dòng)化物流作業(yè)系統(tǒng)的自動(dòng)化運(yùn)維， 管好其中的設(shè)備和軟件服務(wù)。

　　InfoQ：在 CNUTCon 全球運(yùn)維技術(shù)大會(huì) 上，你將會(huì)為讀者分享哪些技術(shù)點(diǎn)?

　　這次大會(huì)我會(huì)給大家介紹下京東物流自動(dòng)化運(yùn)維平臺(tái)的技術(shù)架構(gòu)， 并詳細(xì)介紹自動(dòng)化開倉(cāng)、批量部署的技術(shù)細(xì)節(jié)。