一、持續(xù)部署
1. 現(xiàn)狀
由于沒有建立標(biāo)準(zhǔn)的持續(xù)部署流程，導(dǎo)致了版本管理混亂，制品管理混亂，上線持續(xù)時間長，上線測試覆蓋不全面，業(yè)務(wù)流量上升后故障較多，排查復(fù)雜。運維、測試、開發(fā)人員每次版本迭代的時候，都要可能需要經(jīng)歷一次通宵的歷練，并且這種在上線的第二天依然會出現(xiàn)很多線上故障。
2. 痛點
·自動化發(fā)布體系覆蓋率低。
·無標(biāo)準(zhǔn)化發(fā)布的流程。
·只注重敏捷、忽視質(zhì)量問題；
·變更頻繁導(dǎo)致故障率增加；
·開發(fā)語言種類多，發(fā)布制品管理混亂，發(fā)布方式復(fù)雜；
·安全問題容易被忽視。
二、工具介紹
1. Saltstack
基于ZeroMQ的開源的配置管理工具。筆者之所以選型使用saltstack，而放棄了ansible，原因是由于ansible基于ssh通信，在管控主機(jī)超過五百臺之后，基于消息隊列的命令下發(fā)方式無論在穩(wěn)定性還是速度上都優(yōu)于ssh協(xié)議。筆直另外選在saltstack的原因是，在服務(wù)的開發(fā)團(tuán)隊中存在著不同的技術(shù)棧并行的狀況，尤其是java和.net并存的情況下，saltstack對于windows的支持明顯要優(yōu)于ansible。更容易作為多平臺的底層發(fā)布工具。
而基于SaltStack打造自動化部署平臺主要是用grains、pillar、state三個特性，grains用于獲取默認(rèn)環(huán)境配置信息、pillar用于定義環(huán)境信息、state用于編排發(fā)布文件進(jìn)行發(fā)布。
2. Artifactory
全語言制品倉庫管理軟件，有開源版及企業(yè)版兩種。開源版支持maven制品管理；企業(yè)版支持全語言制品管理，支持元數(shù)據(jù)管理功能，提供高可用部署方式、匹配nvd及vulnDB數(shù)據(jù)庫，提供漏洞掃描能力。
三、針對上述痛點解決方案
1. 自動化發(fā)布覆蓋率低
通過搭建兼容多平臺部署統(tǒng)一發(fā)布工具，替換掉傳統(tǒng)的shell腳本拷貝的方式實現(xiàn)發(fā)布工具標(biāo)準(zhǔn)化。通過SaltStack的state特性，實現(xiàn)跨平臺的基礎(chǔ)服務(wù)發(fā)布、服務(wù)啟停、文件發(fā)布、配置發(fā)布、遠(yuǎn)程主機(jī)管理等90%以上手動操作。使用SaltStack的state編排文件，執(zhí)行遠(yuǎn)程命令，通過Artifactory獲取制品及配置，將需要的版本發(fā)布到線上。
主要方案在部署平臺中，通過json格式描述發(fā)布流程，通過yaml.dump(sls_json）將json文件轉(zhuǎn)換成yaml各位的配置文件，最終通過平臺調(diào)度saltstack執(zhí)行編排好的任務(wù)。
轉(zhuǎn)換后的yaml文件格式如下：
2. 標(biāo)準(zhǔn)化發(fā)布流程
·備份
發(fā)布任務(wù)編排的第一步就是備份，備份需采用本地備份加異地備份兩種機(jī)制，本地備份用于快速回滾，異地備份用于環(huán)境重建。
·切流量（藍(lán)綠部署）
對于服務(wù)，尤其是有狀態(tài)的服務(wù)，需要在注冊中心中進(jìn)行節(jié)點下線，確保本節(jié)點所有處理結(jié)束后，再進(jìn)行部署。
對于頁面，需要在負(fù)載均衡上將節(jié)點注銷，對沒有流量的web頁面進(jìn)行部署操作。
·部署
通過saltstack的sls特性，編排部署文件，對多個部署任務(wù)進(jìn)行統(tǒng)一進(jìn)行發(fā)布。
部署時我們希望可以在部署頁面查看到類似下述信息，如：部署包對應(yīng)的需求id、部署包對應(yīng)代碼的提交信息、部署包自動化測試的通過率、部署包的代碼掃描結(jié)果、部署包的安全掃描結(jié)果、部署包人工測試的結(jié)果等等。運維人員需要在發(fā)布過程中看到此類信息，來明確包是否通過了所有質(zhì)量關(guān)卡、具備了上線條件，從而判斷此次上線是否可以繼續(xù)進(jìn)行。這里我們使用了Artifactory的元數(shù)據(jù)功能，用于記錄軟件包誕生的整個生命周期的信息，并通過api方式對接到發(fā)布平臺。給運維人員一個完整的包的信息記錄。
·自動化測試
此處自動化測試主要可以理解為檢測服務(wù)端口通信是否正常、回歸線上功能是否可用、缺陷是否被修復(fù)、新特性是否部署完成等。同時此處需要預(yù)熱服務(wù)及站點，通過自動化的測試打通業(yè)務(wù)流程。
·流量回歸（金絲雀）
部分真實流量切換到已經(jīng)部署完成的應(yīng)用上，通過全鏈路日志追蹤或監(jiān)控指標(biāo)反饋來初步判斷新上線應(yīng)用是否健康運行，并將此結(jié)果作為后續(xù)發(fā)布或回退的依據(jù)。
·部署補(bǔ)全（滾動發(fā)布）
在使用低谷時間將流量牽引到已部署完成的應(yīng)用上，同時將其余應(yīng)用升級。
·變更管理通告
上線成功后需要及時的通知大家線上版本已變更，產(chǎn)品經(jīng)理需要及時更新文檔，運營人員需要及時對用戶進(jìn)行告知。
·回滾
任何發(fā)布都需要考慮回滾方案，對于單個應(yīng)用需要回滾到一個指定版本；對于多個應(yīng)用，需要明確一個回滾集，通過發(fā)布時的編排任務(wù)指定回滾的編排任務(wù)。對于數(shù)據(jù)庫等更新，如果回顧復(fù)雜，則需要在升級方案制定前就明確回滾方案或在業(yè)務(wù)中做好版本兼容。
3. 建立統(tǒng)一的制品管理倉庫
大多互聯(lián)網(wǎng)公司已經(jīng)對源碼倉庫有了統(tǒng)一的管理，但對于制品依然處于一個原始的管理狀況，比如使用ftp以及每種語言開源的管理倉庫。這里遇到的問題是，運維人員需要投入大量的精力維護(hù)不同的包管理平臺（如ftp、maven、nuget、pypi、docker鏡像中心等）。浪費掉大量運維團(tuán)隊的人力成本之外，也極度復(fù)雜了發(fā)布流程。發(fā)布人員需要在不同的平臺獲取上線的包，導(dǎo)致發(fā)布流程混亂，發(fā)布平臺配置混亂。并且大多數(shù)開源組件均不提供高可用能力，一旦硬件或軟件出現(xiàn)故障，都將嚴(yán)重的影響發(fā)布效率。
為了解決這種問題，我們采用Artifactory來管理所有語言的制品倉庫。與統(tǒng)一gitlab一個道理，我們把整個公司的制品統(tǒng)一管理，成為對接發(fā)布平臺的唯一包來源，從而規(guī)范了發(fā)布流程。
4. 漏洞掃描
目前安全團(tuán)隊掃描大多是在服務(wù)部署上線后進(jìn)行，這種情況下和容易造成由于版本有安全漏洞導(dǎo)致的整個迭代廢棄，所有包需要重新編譯，重新經(jīng)過測試流程以及上線過程，浪費掉大量的時間，降低迭代的速度。
解決辦法是將漏洞掃描步驟前置，在制品包構(gòu)造編譯的時候，乃至開發(fā)人員code代碼的時候就對外部引用、內(nèi)部公共庫進(jìn)行漏洞掃描，一旦匹配到高危漏洞，直接把提交或構(gòu)建終端。如果一定要繼續(xù)構(gòu)建，那么可以將掃描結(jié)果記錄到制品的元數(shù)據(jù)中，供測試人員，運維人員查看。目前JFrog Xray等安全掃描故居提供此類能力。也可以使用開源軟件，如cvechecker，在編譯流水線中對包進(jìn)行掃描，防止由于安全漏洞造成的整個迭代失敗。
四、后期完善
1.設(shè)置度量體系，提升發(fā)布質(zhì)量
敏捷開發(fā)模式下，開發(fā)人員和測試人員往往是匯報給同一位管理人員，出于快速迭代線上功能，往往有些團(tuán)隊會投機(jī)取巧、將沒有測試完整的包發(fā)布到線上進(jìn)行測試。該種問題的直接表現(xiàn)是，為了解決一個bug，可能多時間多次對同一個應(yīng)用或頁面進(jìn)行hotfix或發(fā)布新版本。這樣做是十分危險的，置線上業(yè)務(wù)穩(wěn)定于不顧。為了避免此類情況發(fā)生、我們可以采用一些措施或規(guī)范來約束開發(fā)團(tuán)隊。例如：
上線后觸發(fā)新bug數(shù)量
短時間內(nèi)對相同問題發(fā)布次數(shù)
由于上線原因造成的P5-P0級別故障的數(shù)量
上線后故障恢復(fù)時間
上線后回滾的次數(shù)
非上線時間內(nèi)緊急上線數(shù)量
…
通過收集上述數(shù)據(jù)，每月或固定周期對各個團(tuán)隊進(jìn)行考核。并對發(fā)布狀態(tài)復(fù)盤，通過制定規(guī)約，評估團(tuán)隊的交付質(zhì)量及交付能力，挖掘團(tuán)隊中的發(fā)布問題及痛點，從而提高發(fā)布質(zhì)量，減少線上故障率。
2.制定度量標(biāo)準(zhǔn)，進(jìn)行發(fā)布質(zhì)量考核
每團(tuán)隊初始分為100分，每月重置，每月用此分作為迭代質(zhì)量的一項標(biāo)準(zhǔn)，分?jǐn)?shù)不掛鉤kpi考核，只用來驅(qū)動開發(fā)團(tuán)隊去提高效率。
評判為兩個維度：項目組發(fā)布穩(wěn)定性得分、服務(wù)（站點、app、微服務(wù)等）發(fā)布質(zhì)量得分
·非上線時間發(fā)布hotfix（項目組減1分，服務(wù)減1分）
·代碼類hotfix，同一項目每天發(fā)布超過3次（項目組減1分，服務(wù)減2分）
·hotfix發(fā)布失敗或回滾（項目組減2分，服務(wù)減2分），發(fā)布是否失敗，由運維團(tuán)隊認(rèn)定。
·數(shù)據(jù)庫等腳本異常或執(zhí)行失?。椖拷M減1分）
·每月服務(wù)發(fā)布數(shù)量（取top5，服務(wù)按排序減5到1分）
·由于hotfix原因造成P2級以上的線上事故，項目組減5分，相關(guān)服務(wù)減5分
·項目組本月hotfix量如超過前3月平均值的30%，減10分
3. 變更管理
??????? 落地方式包括但不限于下述幾點：
·運維人員、對應(yīng)的開發(fā)及測試人員、產(chǎn)品經(jīng)理等微信通知
·大屏滾動播放最近的變更記錄
·變更記錄同步到監(jiān)控系統(tǒng)
五、總結(jié)
總結(jié)為一句話，雖然在敏捷開發(fā)模式下、產(chǎn)品、開發(fā)、測試團(tuán)隊都在小步快跑，但運維必須有自己的原則，一定要對整個上線流程制定規(guī)范、對DevOps工具鏈進(jìn)行統(tǒng)一管理。
線上穩(wěn)定大于一切！
