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