一、持續部署

1. 現狀

由於沒有建立標準的持續部署流程，導致了版本管理混亂，製品管理混亂，上線持續時間長，上線測試覆蓋不全面，業務流量上升後故障較多，排查複雜。運維、測試、開發人員每次版本迭代的時候，都要可能需要經歷一次通宵的歷練，並且這種在上線的第二天依然會出現很多線上故障。

2. 痛點

l   自動化釋出體系覆蓋率低。

l   無標準化釋出的流程。

a)        只注重敏捷、忽視質量問題；

b)       變更頻繁導致故障率增加；

c)        開發語言種類多，釋出製品管理混亂，釋出方式複雜；

l   安全問題容易被忽視。

二、工具介紹

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. 標準化釋出流程

l   備份

釋出任務編排的第一步就是備份，備份需採用本地備份加異地備份兩種機制，本地備份用於快速回滾，異地備份用於環境重建。

l   切流量（藍綠部署）

對於服務，尤其是有狀態的服務，需要在註冊中心中進行節點下線，確保本節點所有處理結束後，再進行部署。

對於頁面，需要在負載均衡上將節點登出，對沒有流量的web頁面進行部署操作。

l   部署

透過saltstack的sls特性，編排部署檔案，對多個部署任務進行統一進行釋出。

部署時我們希望可以在部署頁面檢視到類似下述資訊，如：部署包對應的需求id、部署包對應程式碼的提交資訊、部署包自動化測試的透過率、部署包的程式碼掃描結果、部署包的安全掃描結果、部署包人工測試的結果等等。運維人員需要在釋出過程中看到此類資訊，來明確包是否透過了所有質量關卡、具備了上線條件，從而判斷此次上線是否可以繼續進行。這裡我們使用了Artifactory的後設資料功能，用於記錄軟體包誕生的整個生命週期的資訊，並透過api方式對接到釋出平臺。給運維人員一個完整的包的資訊記錄。

l   自動化測試

此處自動化測試主要可以理解為檢測服務埠通訊是否正常、迴歸線上功能是否可用、缺陷是否被修復、新特性是否部署完成等。同時此處需要預熱服務及站點，透過自動化的測試打通業務流程。

l   流量回歸（金絲雀）

部分真實流量切換到已經部署完成的應用上，透過全鏈路日誌追蹤或監控指標反饋來初步判斷新上線應用是否健康執行，並將此結果作為後續釋出或回退的依據。

l   部署補全（滾動釋出）

在使用低谷時間將流量牽引到已部署完成的應用上，同時將其餘應用升級。

l   變更管理通告。

上線成功後需要及時的通知大家線上版本已變更，產品經理需要及時更新文件，運營人員需要及時對使用者進行告知。

l   回滾

任何釋出都需要考慮回滾方案，對於單個應用需要回滾到一個指定版本；對於多個應用，需要明確一個回滾集，透過釋出時的編排任務指定回滾的編排任務。對於資料庫等更新，如果回顧複雜，則需要在升級方案制定前就明確回滾方案或在業務中做好版本相容。

3. 建立統一的製品管理倉庫

大多網際網路公司已經對原始碼倉庫有了統一的管理，但對於製品依然處於一個原始的管理狀況，比如使用ftp以及每種語言開源的管理倉庫。這裡遇到的問題是，運維人員需要投入大量的精力維護不同的包管理平臺（如ftp、maven、nuget、pypi、docker映象中心等）。浪費掉大量運維團隊的人力成本之外，也極度複雜了釋出流程。釋出人員需要在不同的平臺獲取上線的包，導致釋出流程混亂，釋出平臺配置混亂。並且大多數開源元件均不提供高可用能力，一旦硬體或軟體出現故障，都將嚴重的影響釋出效率。

為了解決這種問題，我們採用Artifactory來管理所有語言的製品倉庫。與統一gitlab一個道理，我們把整個公司的製品統一管理，成為對接釋出平臺的唯一包來源，從而規範了釋出流程。

4. 漏洞掃描

目前安全團隊掃描大多是在服務部署上線後進行，這種情況下和容易造成由於版本有安全漏洞導致的整個迭代廢棄，所有包需要重新編譯，重新經過測試流程以及上線過程，浪費掉大量的時間，降低迭代的速度。

解決辦法是將漏洞掃描步驟前置，在製品包構造編譯的時候，乃至開發人員code程式碼的時候就對外部引用、內部公共庫進行漏洞掃描，一旦匹配到高危漏洞，直接把提交或構建終端。如果一定要繼續構建，那麼可以將掃描結果記錄到製品的後設資料中，供測試人員，運維人員檢視。目前JFrog Xray等安全掃描故居提供此類能力。也可以使用開源軟體，如cvechecker，在編譯流水線中對包進行掃描，防止由於安全漏洞造成的整個迭代失敗。

四、後期完善

1. 設定度量體系，提升釋出質量

敏捷開發模式下，開發人員和測試人員往往是彙報給同一位管理人員，出於快速迭代線上功能，往往有些團隊會投機取巧、將沒有測試完整的包釋出到線上進行測試。該種問題的直接表現是，為了解決一個bug，可能多時間多次對同一個應用或頁面進行hotfix或釋出新版本。這樣做是十分危險的，置線上業務穩定於不顧。為了避免此類情況發生、我們可以採用一些措施或規範來約束開發團隊。例如：

上線後觸發新bug數量

短時間內對相同問題釋出次數

由於上線原因造成的P5-P0級別故障的數量

上線後故障恢復時間

上線後回滾的次數

非上線時間內緊急上線數量

…

透過收集上述資料，每月或固定週期對各個團隊進行考核。並對釋出狀態覆盤，透過制定規約，評估團隊的交付質量及交付能力，挖掘團隊中的釋出問題及痛點，從而提高發布質量，減少線上故障率。

2. 制定度量標準，進行釋出質量考核

每團隊初始分為100分，每月重置，每月用此分作為迭代質量的一項標準，分數不掛鉤kpi考核，只用來驅動開發團隊去提高效率。

評判為兩個維度：專案組釋出穩定性得分、服務（站點、app、微服務等）釋出質量得分

l   非上線時間釋出hotfix（專案組減1分，服務減1分）

l   程式碼類hotfix，同一專案每天釋出超過3次（專案組減1分，服務減2分）

l   hotfix釋出失敗或回滾（專案組減2分，服務減2分），釋出是否失敗，由運維團隊認定。

l   資料庫等指令碼異常或執行失敗（專案組減1分）

l   每月服務釋出數量（取top5，服務按排序減5到1分）

l   由於hotfix原因造成P2級以上的線上事故，專案組減5分，相關服務減5分

l   專案組本月hotfix量如超過前3月平均值的30%，減10分

 

3. 變更管理

        落地方式包括但不限於下述幾點：

l   運維人員、對應的開發及測試人員、產品經理等微信通知

l   大屏滾動播放最近的變更記錄

l   變更記錄同步到監控系統

五、總結

總結為 一句話，雖然在敏捷開發模式下、產品、開發、測試團隊都在小步快跑，但運維必須有自己的原則，一定要對整個上線流程制定規範、對DevOps工具鏈進行統一管理。

線上穩定大於一切！