文章來源：本文根據嘉爲藍鯨2021研運治理實踐大會嘉賓段亞浩的演講總結得出
原文作者：公衆號 嘉爲藍鯨
背景
Why：爲什麼需要DevOps？
伴隨着新一代信息技術（人工智能、區塊鏈、雲計算、大數據等，通常稱之爲ABCD）的深度應用，全面推進數字化轉型，已成爲了新時期企業生存和發展的必然選擇。
DevOps作爲支撐數字化轉型的基石，通過體系化的研發實踐導入、軟件架構的整體革新、組織管理理念的不斷升級和企業文化的影響塑造，來幫助企業改善整個軟件交付過程，實現高質量和高效率兼得，同時持續改善企業內部的文化建設（工程師文化、學習型組織等）。
What：什麼是DevOps？
什麼是DevOps，這個概念已經並不陌生，但對於各個團隊來說都會有自己的側重點：開發希望只編寫代碼，其他的事都不用管，全部自動化完成。而運維希望，每次的部署都是小步的、短週期的，從而進行充分的測試驗證，保證部署上線時不容易出問題。在開發和運維之間則希望能更好地溝通協作，在保證質量的情況下來提升交付效率。
以下是DevOps Master白皮書中對DevOps知識體系的定義，即一個基礎三大支柱，以精益管理的基礎，通過敏捷管理、持續交付和ITSM來支撐從需求到運營的端到端的過程。
精益管理
在精益管理方面強調的是內建質量，通過單建流的方式實現小批量的交付，同時建議整個組織轉型爲學習型的組織。
敏捷管理
敏捷管理方面，需求是要條目化的，需求拆分到什麼顆粒度，任務多大比較合適，都要有一定的標準。同時要做DoD，即對完成的明確定義，比如開發要做單元測試，能把整個功能向其上下游，即業務、測試做show case。開發敢把自己實現的功能做演示，那麼基本可以認爲他的功能開發是比較成功的、bug是少的，否則也不敢做展示。
持續交付
在持續交付裏面有兩個重要的概念，一個是自動化，一個是流水線。自動化這一塊要求所有過程全部自動化，如測試自動化，部署自動化等。同時，還需要建立一個可重複且可靠的流水線，保證隨時可觸發、持續性的。
IT服務管理（ITSM）
最後是ITSM，傳統的方式一般都會有上線評審會，需要做一連串繁瑣流程的審批。這部分有些審批環節是非必要的，則建議能去掉的就去掉，能精簡的就精簡，儘量避免影響整個交付過程，保證業務的連續性。
How：DevOps平臺選擇的常見疑問
到底是自研好還是採購一個平臺好？
企業原本已經有了一些工具，應該如何做遷移、替換？
公司各個部門都有各自的工具，如何將其集成打通？
引入了工具、平臺，但試點團隊用的效果並不理想，應該如何處理？
這幾個問題在DevOps的建設過程中是非常常見的，以下通過系統地思考和梳理，總結了十個關鍵點，作爲企業進行DevOps平臺建設的建議或參考依據。
平臺選擇的依據
1.研發協同
- 開發模式，平臺可以支撐傳統開發模式和敏捷開發模式，即支持穩敏雙態；
- 對產品和項目管理提供支持，通過主辦系統和輔助系統的協同實現項目集管理；
- 底層流程引擎可以通過拖拉拽方式實現各種模式的靈活自定義和配置。
研發協同，通過需求這個核心抓手，實現對軟件交付全生命週期的精細化、可視化管理，貫穿各個階段進行跟蹤與管控，從而對團隊中的瓶頸或研發效能較低的部分能夠快速洞察，以便不斷進行協同優化。
2.分支策略
對於開發人員，更多的是希望自己能夠專注在代碼開發中，期望平臺能夠支持多種類型的分支策略。支持分爲兩個層面，鬆散型和強綁定型，這裏希望是強綁定的，即平臺固定支持幾種模型，自動化創建分支、合併分支、打tag等等，解決研發人員一切分支煩惱，使其能夠聚焦於重大問題解決，專注於功能代碼的實現。
3.代碼評審
平臺需要能夠提供代碼評審能力。谷歌作爲代碼評審的佼佼者，不僅將評審經驗總結爲最佳實踐分享出來，同時還開發了一個工具，即Gerrit。其兩個優秀的特點：通常我們都希望開發主幹的代碼是比較穩定的，bug少的；在這裏Gerrit提供了評審分支，未通過評審的代碼，是不允許合入遠端分支的，以此來保證遠程分支不被新代碼破壞。第二個好處是可以多人評審，通過打分機制進一步提高代碼的質量。
4.質量門禁
軟件交付的各個階段都需要對質量進行把控，如果沒有達到標準的話是不允許通過的。舉個例子，代碼質量門禁應該怎麼做？最好的方式是有代碼規範的掃描，有安全的掃描，在單元測試方面覆蓋率最起碼的要達到60%以上，並且通過率達到100%，否則是不能通過的。對質量的把控，就需要平臺具備質量門禁的功能。
5.CI引擎
常見的CI引擎一般使用較多的是Jenkins，入門簡單使用方便，但併發量太高時，無法避免會出現一些問題。這就要求CI引擎能夠滿足穩定性、可擴展性的需求。首先是功能上，要能支持常見的CICD場景。第二點是可通過可視化的，拖拉拽的方式創建流水線，方便快捷。第三點，架構支持橫向擴展，比如說根據併發量進行自動擴縮容。第四點是CI引擎可以支持各種操作系統，複雜構建環境等。除此之外，流水線的插件、模板、代碼檢查規則集等其他能力也是對平臺CI引擎的衡量指標。
6.自動化測試
- 需要支持分層測試框架；
- 可以快速集成常用的測試工具，複用企業已有測試資產；
- 支持測試左移，主要強調兩個點，一是測試人員在需求澄清階段就可介入，二是可以在開發測試環境中提前做一些測試工作。
7.配置分離
配置中心可以把不同環境的所有配置進行納管，一方面可以統一管理配置，另一方面應用和配置分離可以實現一個製品包從不同測試環境一步步晉升到生產環境的要求。
8.容器/非容器發佈的支持
平臺需要支持傳統的發佈模式和容器發佈模式，即支持統一應用發佈。既可以發佈到雲上，也可以發佈到容器集羣上，當然，對傳統的應用也要能夠進行主機發布。
9.製品庫
- 對私庫類型的支持；
- 對製品包類型的支持；
- 元數據可追溯；
- 支持多數據中心同步分發；
- 支持嚴格權限管理、安全掃描等功能。
10.綜合能力
- DevOps平臺需要對各種研發模式有很好地支撐，如敏穩雙態的支持；
- 對常見開發語言的支持，不同開發語言會涉及不同的構建方式；
- 對部署方式的支持，傳統的方式、灰度方式等；
- 對部署載體的支持，對虛擬機支持、對容器支持等。
以上從四個方面分析了平臺需要具備的能力，嘉爲藍鯨DevOps平臺設計理念從四個方面：一站式平臺、自動化一切、數據流貫通、高可擴展性，可以覆蓋以上闡述的內容。
一站式平臺
實現底層工具的集成打通，毋需在各個工具之間切換，支持研運人員高效協同。
自動化一切
通過插件化能力實現交付過程完全自動化，支持異構化應用持續交付。
數據流貫通
一站式一體化平臺，數據收集、分析、展示統一口徑、統一標準，實現精益度量。
高可擴展性
架構高可用的，並支持通過研發商店進行能力擴展。
嘉爲藍鯨DevOps的能力，可以滿足從協同、到開發、到集成、到測試、到運維、到度量的各種場景。
有平臺就夠了嗎？
整個平臺的能力建成之後，我們還要思考下一個問題：有平臺就夠了嗎？
顯然，回答是否定的。
僅有DevOps平臺還是不夠的，平臺僅是一個皮囊，我們還需要給平臺賦予靈魂。這就要求企業結合自己的實際情況，將其特有的研發模式、工作流程、工作規範與平臺進行深入融合，這樣的平臺纔是一個符號企業自身特點的平臺。有了靈魂以後，還需要把各階段自動化腳本進行完善，即自動化一切，初步建成完整的平臺能力。再對企業不同角色進行賦能，使其具備快速交付用戶價值所需要的能力。最後通過試點項目總結企業自己的最佳實踐，並進行推廣，從而實現組織級的效能提升。
DevOps的建設從來都不是簡單的平臺引入。有了平臺以後還需要：
- 前期需要系統地諮詢、專業的教練進行引導，構建組織及建設藍圖；
- 結合企業自身實際，對流程、規範體系進行優化，而後與平臺進行深度融合；
- 融合平臺後，一般通過試點項目完成最佳實踐的演進；
- 最佳實踐推廣，在推廣過程中進行團隊建設，包括技術能力、協同能力、工程師文化以及學習文化的建設，不斷識別團隊中的問題，持續改進；
- 通過團隊敏捷教練的培養、工程教練的培養，持續反哺優化整個過程。
DevOps平臺的建設是一個長期的、持續改進的過程，伴隨着工具、平臺的引入，企業也需要不斷地調整，以達到整個組織的敏捷化、高效化，從而實現業務價值交付層面的提升，推進整個企業從內到外的數字化進程。
如您需要演講PPT，可私信或關注公衆號獲取