最近在網上看了不少有關CI/CD的文章，其實基本是雷同的，且內容也不是非常完善。確實，當前持續集成用到的開源工具無非還是Git、Jenkins、Ansible(Fabric)這些，不同的應該是各公司的技術框架差異，發佈審覈流程不同，從而使配置細節也有較大不同。接下來我要分享的一系列文章均是圍繞生產版本發佈、集羣中間件搭建以及監控來寫，並且都是這些年（2014-至今）我們一直還在用的技術（包括具體環境搭建以及前後端發佈等細節），歡迎拍磚，共同探討。
我們一直沿用的一套流程如下：
0、在公司內部搭建gitlab服務器，員工自行在公司gitlab服務器通過公司郵箱完成賬號註冊。
1、配置管理員在gitlab上創建project(項目或倉庫)，建議按業務線或功能先分group(組)，然後再在group下創建具體的project，避免所有project混在一個group。
2、源碼放在源碼project；編譯後可用於發佈包放在可發佈的project。
3、配置管理員對已註冊開發人員分配權限（master、develop、Reporter等），權限可在group上分配，也可細到某個project。
4、開發人員通常只分配develop權限且在develop分支進行開發，開發人員不允許直接提交代碼到master(主分支)，如需提交到master，則需要發出合併請求，由項目管理者review後決定是否合併。
5、源代碼合併後，由合併者打tag觸發jenkins構建出用於發佈的版本包，並推送到對應發佈代碼的project中，同步tag，同時根據最新tag發佈到測試環境。
6、在經過代碼審查、集成測試、功能測試以及安全性測試等都通過後，且經產品人員確認同意發佈，再使用jenkins將測試通過的tag發佈到RC環境。
7、RC運行正常，產品人員確認同意發佈到生產，再使用jenkins將RC通過的tag（測試和RC的tag均是同一個）發佈到生產環境。
8、如果發佈後出現異常，則使用jenkins按上一次正常tag進行回滾。
上述是一個較理想的流程，但實際開發過程中，一名開發人員可能身兼多職，包括編碼、測試等，所以可能更通用的流程如下圖1描述所示。
圖1
同樣，一般中小規模公司，一般只有一到兩名運維人員，那麼在維護上述發佈框架同時，該名運維人員常備的技能如下：
0、與開發、測試、產品同學之間的和諧溝通及協調能力。
1、Gitalb搭建以及配置管理功能，包括備份恢復、郵件通知、權限分配、通過API創建project、Webhooks、tag（標籤）規範化並實現自動生成tag等常用維護操作。
2、Jenkins環境搭建以及配置管理功能。包括插件安裝、權限分配、郵件通知、腳本創建job、參數化構建等。
3、腳本編寫能力，包括Shell、Fabric或藉助Ansible完成代碼編譯、推送、發佈（回滾也是發佈）等。
4、日誌集中收集，如配置syslog-ng和ELK，個人更傾向於用syslog-ng完成集中收集，然後用ELK來展示，因爲在發佈過程中開發人員更習慣使用tailf來查看發佈過程中是否報錯以便及時回滾。
5、監控，推薦使用Zabbix+Grafana，也可使用Nagios。實現對網絡設備監控（CPU、內存、溫度、接口流量等）、服務器硬件監控（通過IPMI接口獲取硬件故障信息）、系統監控（內存、CPU、磁盤空間和IO、負載、網卡流量、文件句柄等）、集羣中間件監控（集羣狀態、CPU、內存使用、日誌等）服務監控（進程、端口、響應狀態碼、日誌等）、數據庫監控（常用命中率指標、表空間、慢查詢、日誌等）、業務監控等，確保業務7*24不時不中斷穩定運行。
6、集羣中間件搭建以及維護能力，諸如Zookeeper、Redis、Mongodb、RabbitMQ、RocketMQ等。
7、數據庫集羣搭建以及維護能力，包括Oracle、MySQL。不過，現在中小規模公司基本在雲上，主要用的是RDS，個人覺得阿里雲RDS的性能監控可視化做得非常棒，遠超AWS。
總結：幹運維真得非常不容易，分分鐘就會當背鍋俠，請對運維好一點！
下一篇：Gitlab搭建與配置技巧