作者簡介
周少冉 百度高級研發工程師
負責百度智能運維（Noah）部署產品的設計和研發工作，對部署上線有着廣泛的實踐經驗。
背景
在互聯網公司中，除了我們熟知的開發，測試，產品之外，還有一羣非常重要的人。他們主要負責服務器的維穩和日常上線更新工作。沒有了他們的存在，我們的服務器肯定會出現各種未知的問題。沒錯，他們就是傳說中的運維(OP)同學。 OP同學的兩大工作事項：一維護服務器穩定運行；二進行模塊上線。大部分人都認爲一非常重要，是OP同學最費精力的事兒，對於模塊上線，很多人覺得只是將文件進行簡單替換就好。事實真的是這樣嗎？那我們不妨先看下某位OP同學真實經歷再下結論吧。
OP小強同學受難記
小強同學是公司的一名OP，日常主要工作就是負責服務器的穩定和上線。在公司開始發展階段，業務不是很多，幾臺服務器就能夠輕鬆搞定，每次找他上線的開發(RD)和測試(QA)同學，他都能輕鬆熟練的幫他們進行上線。
隨着公司業務發展，服務器日益增多，找他來上線的RD和QA也絡繹不絕，平時能夠輕鬆完成上線的小強，發現每次都手動上線，又費時又費力，還經常出錯，這樣下去總是不行的，得想個辦法。於是他就找了RD同學，希望他能夠幫自己，寫個自動化腳本實現一鍵上線。
RD同學雖然不樂意，但是也考慮到實際情況，就答應幫助小強同學，讓小強說一下上線場景。小強想了一下說，上線嗎，無非就是替換個包之後，運行起來就可以了。那你就按照：下載新文件→替換舊文件→開啓服務這種順序開發吧。
不到三天，RD同學幫小強開發出了一個程序。只需要填寫下載地址，替換路徑和開啓服務命令，就可以完成上線自動化。有了這個神器，小強自然省了不少力氣，對開發同學自然也是感激不盡。
到了週末，小強約上自己的女盆友出來約會。
本來兩個人開開心心的。結果小強突然收到一條短信，短信提示某個服務突然停掉了。公司最近爲了服務器的穩定，對每臺服務器都安裝了報警提示功能。只要是有服務或者機器發生異常，就會對OP立馬進行提示，以便最快的速度進行修復。
是立馬解決報警上線問題，還是先好好陪自己的女朋友？小強陷入了兩難境地。To be,or not to be,that is a question.
沒辦法，作爲一名職業的OP，問題再小也是問題。簡單安撫女盆友之後，立馬就趕回家，打開電腦檢查問題。得出的結果是，RD同學在週末加班完之後，要進行上線測試。期間必須要關掉正在運行的服務，才能做文件替換。這個報警正是因爲服務關掉而觸發的。
小強同學很鬱悶，這種報警屬於假報警，本不應該是值得關心的問題。結果因爲這個，搞砸了難得的約會。
第二天剛到公司，立馬就來了一個新難題。QA和RD同學都要同時上線。而上線的代碼是完全相同的，但是因爲一個要部署在測試環境，一個要部署在開發環境，所以要上線兩次。小強心裏覺得，還好還好，只要上兩次而已。但是當他看到源文件的時候...
原因是因爲本次上線的文件多達100個。這樣通過自動化腳本的時候，光下載那一步就得耽誤好久。而且只是因爲開發和測試的環境不同，代碼一摸一樣，卻要對每個環境都要上線一次，這不是浪費時間和資源嗎？但是沒辦法，只能硬着頭皮上線。小強爲了能夠提高速度，同時開了多個程序下載。不到一會，服務器就出現了I/O過高的問題。
當他千辛萬苦部署好測試環境後，想再次部署開發環境的時候，發現了上線失敗。爲什麼呢？經檢查發現，是因爲週末RD曾經上線過的文件夾用的是RD名字。本次小強要更新這個文件夾，用自己的名字當然會提示權限失敗，當然上線就失敗了。哎，沒辦法，小強只能跟那位RD同學溝通一番了。
結果，一天下來，發現自己啥事情都沒有做，僅僅就光完成這兩部分上線。
好不容易熬到了週五。爲了彌補上週對女盆友的缺憾，小強早早就約了週末再次出去玩，而女盆友也是開心的答應了。結果在週五晨會的時候，經理下達全公司服務器都開始使用Docker。因爲Docker容器的概念，能夠實現快速部署和節省資源。所以這就需要所有OP同學在短期內，能夠迅速把環境搭建好，不影響RD和QA的進度。所以，宣佈本週OP要進行加班。不用說，女盆友又是非常的不爽了。
小強看着前幾周還能用的自動化部署程序已經很難跟上現在的上線了。心中這叫一個苦。無奈之餘，只能苦中作樂的寫句歌詞了：
明天你是否會想起
昨天失敗的日記
明天你是否還惦記
被上線折磨的OP
百度OP和他的獨孤九“薦”
小強覺得自己的公司規模還不算很龐大，就把OP已經累的不行了，那如果是大型互聯網公司，那些OP應該怎麼活呀。他突然想到自己的同學在百度也是一名OP，好像就沒有這樣的煩心事。那麼他們究竟是如何做到的呢？他們的上線腳本究竟強在哪裏了？抱着求教的心，找到了在百度工作的同學小李。
小李聽到小強的苦惱，稱這些問題在百度早已被解決。然後開始教小強如何破解這些難題。
第一“薦”：下載限速
一臺服務器成爲下載源的話，那麼就會出現很多機器同時要下載這臺機器的資源。久而久之，這臺機器肯定會出現I/O過高的性能問題。通常的做法是，下載的時候，要進行限速，這樣就能避免有的服務下載過快導致I/O飛速增長。
第二“薦”：下載格式
百度內部每次上線的文件也會有很多。所以在上線的時候，要進行統一格式。要把所有的文件統一壓縮成一個後綴名爲.tar.gz的文件。這樣可以達到兩個好處：一是下載時間會呈現斷崖式下降；二是在寫腳本文件的時候，只針對這一種格式進行解壓即可。
第三“薦”：多樣下載
傳統的下載方式是把源文件放在一個固定的機器上。但是如果這個源文件在多個機器上的話，傳統的下載方式就不是最優選擇。可以通過採取P2P的方式，讓有源文件的機器都下載源，這樣大幅提高下載效率。
第四“薦”：配置派生
針對不同的環境，要上線不同的源包，這種方式是不可取的，因爲會極大消耗資源，推薦的做法是配置派生。具體的做法就是在需要加載的文件後綴名爲.template，成爲模板。在上線包的某個路徑下，存放着一個conf_template.value文件。它的作用是專門匹配所有.template文件的值。這樣，不同的環境，就有不同的.template文件，而conf_template.value又會保存不同的值，就可以實現替換。解決了同樣的代碼在不同的環境需要不同的配置文件問題。
第五“薦”：報警屏蔽
上線過程中會遇到需要停止服務的現象，通常這種情況產生的報警，我們稱之爲假報警，或者是無用報警，因此就必須要將它進行屏蔽。在報警端可以提供一個API。每一次上線的時候，拼湊參數調用API進行屏蔽。等到上線完成後，再通過另外的參數恢復報警功能。這樣就解決了上線過程收到無用報警的問題。
第六“薦”：備份文件
很多情況下，替換完後的文件在執行的時候，並非達到了我們預期後的結果，甚至很多時候都出現了未知問題。所以比較好的做法就是先要備份一箇舊文件。如果上線遇到問題，要馬上進行回滾操作。
第七“薦”：節約空間
每一次上線，都會產生額外的文件，比如開始的下載包，以及解壓後的文件。這些文件如果長期不處理，會給服務器的空間造成不小的負擔。所以，切記一定要在部署完成後，將下載後的文件進行清理。
第八“薦”：總覽全局
說了這麼多，肯定已經很亂了把。每一個步驟都明白，但是連在一起，就是不知道誰先誰後了。其實如果把一個上線流程想象成一個家庭換燈泡過程，那流程馬上就能想到了。
我們很容易就寫出一套換燈泡的上線流程。如果把獲得燈泡類比爲下載源文件，關上開關就是停止服務，拿下舊燈泡就是備份文件，打開開關就是開啓服務，扔掉包裝就是刪除下載文件。這樣是不是就很容易得出一套完整的上線流程呢？
第九“薦”：自制流程
跟所有的武俠祕笈一樣，一旦招數定死了，那麼它的威力會大打折扣。這套上線流程也是這樣。雖然已經定義了規範上線流程，但是仍然有可能會遇到有用戶有特殊的情況滿足不了。所以我們要在這套流程的基礎上，可以讓用戶隨意更改流程順序，或者添加流程。
通常的解決辦法就是把所有的流程都寫入一個文件中，每一步都對應的一個Key，而Value則是對應的函數入口。這樣用戶想自定義流程，只需要更改Key的位置就可以了。
說完九“薦”之後，小強同學猛然開竅，明白了自己傳統腳本跟百度內部腳本之間的差別，也明白了一整套上線流程的規範。不過他還有最後一個問題：
“這套上線流程，適用於目前比較流行的Docker嗎？”
“當然適用啦。我們可以把每一個容器當成一個小系統。這套上線流程對系統內上線都是可以用的。百度現在的Matrix單機上線就採用這套方式。“
彩 蛋
小強聽完小李介紹後，很是羨慕在百度工作的小夥伴。經過多年的經驗，百度同學已經將很多已知的問題化於無形，大大提升了工作效率。不禁問到，你們這裏現在還招人嗎？
小李聽到後，哈哈一笑。說，當然有啦。目前2020年的校招已經開始啦！歡迎各位有志之士加入我們~
閱讀推薦
運維實踐
智能運維架構 | 架構集成 | 網絡判障 | 監控數據採集 | 監控報警 | 網絡異常 | 分佈式監控系統 | 數據可視化 | 單機房故障自愈 | TSDB數據存儲 | 異常檢測 | 流量異常檢測 | 複雜異常檢測 | 報警風暴 | 實時計算 | 故障診斷 | 日誌監控 | 網絡監控可視化 | HBase實踐 | 多維度數據 | 容量管理
運維產品
百度雲BCM | 企業級運維平臺 | 基礎設施管理引擎 | 運維知識庫 | 通告平臺 | 百度名字服務 | 業務部署 | 數據配送 | 集羣控制系統 | 外網監控 | 內網監控 | 部署變更 | 配置管理 | 站點監控
精品推薦
AIOps全解析 | AIOps中的四大金剛 | 智能運維 | AIOps時代 | 運維演進
↓↓ 點擊"閱讀原文" 【瞭解更多精彩內容】