DevOps 的分與合

2020 年 4 月 7 日
筆記

抽象的 DevOps

「 DevOps 是使軟件開發和 IT 團隊之間的流程自動化的一組實踐，以便他們可以更快，更可靠地構建，測試和發佈軟件。DevOps 的概念建立在建立團隊之間協作文化的基礎上，這些團隊過去一直在相對孤島中運作。」

類似於這種的 DevOps 相關的描述聽起來特別抽象，非常學術，非常教科書，讓人感覺無法落地，不知道該如何入手。很多團隊在了解 DevOps，實踐 DevOps 的時候不能很好的多維度看待 DevOps，實踐的過程也很痛苦，不知道這種新型的理念如何實際提升自己團隊的戰鬥力。

本文從開發和運維兩個視角多層次的講解什麼場景應該 Dev 和 Ops、什麼場景應該 DevOps，即 DevOps 的分與合，並使用一個 Demo 示例告訴大家 DevOps 中的關鍵步驟持續部署如何實踐。

DevOps 的兩個視角

DevOps 從字面上看就是開發和運維，也有翻譯為開發運維（運營）一體化。我們這裡的兩個視角不是別的東西，正是開發和運維。這裡的開發，不能簡單的理解為開發工程師，指代的是整個軟件的研發過程所含的所有要素，涵蓋需求分析、開發、測試等等，其終點是可交付的軟件製品。同樣運維不僅僅是運維工程師，指代的是軟件交付後投產過程以及後續的運營，反饋等系列過程，其起點是接受交付的軟件製品。

這麼兩個視角的區分是隱含着軟件工程背後的邏輯的，就像一棟大樓，他的建設方是建築和設計公司，他的運營方是物業公司一樣，兩者之間有相對清晰的界限。

我們需要回顧軟件行業的發展，來看為什麼 DevOps 被提出來，為什麼現在要強調 Dev 和 Ops 的緊密結合以及什麼場景要緊密結合，什麼場景不需要。

以下四個方面促使了軟件行業開始意識到 DevOps 的作用：

網絡化：典型的傳統軟件代表 Office 系列，Photoshop 等大都不需要網絡支持，單體安裝在電腦上即可使用，這類軟件不牽涉運維，所以更沒有 DevOps 概念。新型的以互聯網為基礎的軟件，例如微信，騰訊會議等都是建立在網絡基礎上的，這屬於典型的 C/S 的架構，C/S 架構中服務器端軟件地位極為重要，服務器端軟件是隱藏在眾多用戶背後的不可見的，需要穩定性、安全性等運維訴求，就引出了開發和運維工作的協同化訴求。
Web 化：相對於 C/S 的軟件，B/S 的軟件在用戶端的部分（C/S 是桌面或者手機應用，B/S 是網頁）上有更高的更新發佈頻率，需支持更新過程不停止服務，無感更新等特性，對軟件的交付速度和質量有了更高的要求，這也引出了開發和運維工作的協同化訴求。
雲化：傳統的 ERP，CRM，HRM，視頻會議系統都是有軟件供應商獨立實施給客戶方，而這些軟件也都在逐步雲化，產生了例如銷售易，騰訊會議，釘釘，企業微信等 SaaS 應用軟件，這類 SaaS 化的軟件對 DevOps 訴求更為迫切。
敏捷化：傳統的外包軟件交付模式因其反饋周期長，實施成本高等弊病已經開始大規模的轉向敏捷、小步快跑、高速迭代的模式，更高的交付速度要求開發和運維之間必須建設協作文化，流程，標準以及工具。

如果你的軟件不符合上述四個發展方向，看到這裡就夠了，你不需要去實踐人云亦云的 DevOps，嘗試只會給你帶來不必要的麻煩。

DevOps 正逐漸把開發和運維中間的界限模糊掉：

本文在探討完畢兩個視角、雙向移動、四個層面後會把開發和運維的中間重疊部分（軟件交付）為主題來詳細闡述這一 DevOps 實踐的最大難題。

開發視角

開發階段關注的信息和概念跟運維運營階段有相當大的差異又有部分的重疊：

運維視角

同樣的，運維階段關注的信息和概念與開發階段有相當大的差異，又有部分重疊：

視角的聚焦

在對 DevOps 概念進行理解，全局考慮的時候需要能像上文中提的一樣理解開發階段和運維階段的廣義性，但在本文設計的持續部署話題，因篇幅限制，會把視角聚焦在開發階段的結束和運維階段，考慮狹義的運維概念（即傳統理解的運維工程師的工作範疇）通過剖析運維工程師的工作內容變化來討論 DevOps 的分與合。

那麼對於運維工程師的基本工作而言，可以把模型簡化為如下兩個方面：

業務運維的左移

在高頻次的程序發佈，爆髮式業務增長的場景下，運維團隊越來越痛苦，在加上很多團隊沒有合適的工具系統和標準化的部署流程，經常會看到團隊內的雙向吐槽：

開發團隊說：

為什麼我們這邊修好了 bug 今天不能給我發佈？我需要查一下生產環境日誌要等 3 個小時？運維同學能不能不要總是抄錯配置項？

運維團隊說：

請用文檔詳細撰寫清楚發佈步驟和注意事項並仔細評估發佈風險。運維團隊已經排滿了所有發佈計劃，你這個修復問題不嚴重，請等下周再排。

運維團隊陷入無限的機械性重複勞動中，而其中大部分工作都是低槓桿的執行發佈，查詢日誌，執行回退等。

這屬於 DevOps 的分離的場景，團隊與團隊之間有工作壓力不均，信任感缺失，目標不一致等問題，建議嘗試做一些業務運維的左移，也即在合適的工具系統基礎上把業務運維的部分權力或者人員分配到開發團隊，使之可以完成大部分的程序發佈、配置更新、日誌查詢等工作，解放運維。

形成下圖效果，從人員上可以是開發兼職業務運維，也可以是開發團隊有專職業務運維人員，其本質是業務運維的主要工作閉環在開發團隊內部，實現高效運轉。

這樣即在某種程度上實現了 Dev 和 Ops 的合。

基礎設施運維的右移

信息數據的安全訴求，以云為代表的基礎設施的虛擬化、彈性化、甚至於代碼化的發展也給運維團隊的基礎設施運維工作帶來了新的挑戰和機遇。我們會發現基礎設施運維團隊在雲的發展下漸漸的實現了右移（把基礎設施全信任的交給雲處理）。

在沒有雲主機的年代，運維團隊不得不扛着沉重的服務器去機房裡，對照着官方指南，安裝操作系統、配置網絡策略；雲主機時代，容器還未到來之時，運維團隊擺脫了物理服務器，卻不得不維護大量的服務器軟件，安裝、卸載、批量發佈等，去維護業務運行的基礎軟件環境；在有了 Kubernetes，Docker 等容器技術之後，運維工程師從維護軟件運行基礎環境中解脫，轉而做更上層的基礎設施：監控體系、負載均衡等；不遠的將來，當 Serverless 重構雲計算體系的時候，運維人員連監控體系、負載均衡等都不需要關注了，全量交給雲來解決。

雲的不斷發展的歷程也是一個逐步吞噬基礎設施運維人員工作的歷程，如今運維人員在雲的基礎上有了雲 LB 不需要再運維 HAProxy，Nginx 等，有了雲數據庫不需要再運維 MySQL、Redis 等。如此種種，基礎設施運維的工作都右移給了雲。

當然這個右移不是一蹴而就的，是個漸進的過程，需要行業慢慢去接受，也需要雲的成熟與發展。最近沸沸揚揚的微盟運維人員刪庫跑路事件是一個很好的佐證，他們使用了騰訊雲，騰訊雲最終幫他們找回了數據，但他們基礎設施運維的右移程度不夠高，換句話說叫做雲原生滲透不夠深，如果使用的是類似於雲數據庫這類雲提供的數據庫基礎設施，那也許大可不必使用硬盤恢復技術來找回數據。

誠然，雲產品還有長遠的路要發展，但在現有的雲的能力下，各位可以思考下，自己團隊的基礎設施運維右移了多少，阻礙右移的問題是什麼，右移不夠導致浪費了多少人員精力，帶來了多少風險。

DevOps 的四個重要層面

認真評估你的軟件的交付機制以及運維團隊左移和右移的程度是你選擇採用何種 DevOps 分合策略，以及 DevOps 實踐是否成功的關鍵因素。

DevOps 的分與合，與運維工作的左移右移，雲技術的發展，雲原生標準的統一有極大關係，DevOps 概念可以在很多層面上得到體現，本文就其中主要的，可以讓 DevOps 團隊真切感知的四個層面來做簡要介紹：

從人員管理層面看 DevOps

要想實踐 DevOps 的分與合，必須要配置上合適的團隊配置。這裡有若干種配置的分類：

第一種模式屬於 Dev 和 Ops 分的比較徹底的類型，這種人員模型可以適配業務運維左移程度較少，交付流程較為標準化的場景，運維團隊制定流程，流程和運維服務共享給所有開發團隊。

第二種模式屬於 Dev 和 Ops 合的比較徹底的類型，這種人員模型可以適配業務運維左移程度很高，基礎設施運維右移程度也很高的場景，基本上實現了每個開發團隊配合雲就能完整實現閉環，已經沒有傳統意義的獨立運維部門。

第三種模式屬於 Dev 和 Ops 部分分開、部分合併的類型，這種人員模型可以適配業務運維左移程度較多，但基礎設施運維右移程度較少的場景，適用於希望能實現開發團隊閉環，又對雲基礎設施有信任問題，需要自建基礎設施（例如私有雲，或基於公有雲的私有基礎設施）類型的團隊，這種模式跟第二種模式的唯一差異是是否有自主基礎設施運維團隊，在超大規模 DevOps 建設私有雲的場景多見。

第四種模式屬於 Dev 和 Ops 的合併已經達到極致，可以完全無運維團隊工作，在使用雲基礎設施和合適的開發工具基礎上就可以實現開發團隊內完整閉環，例如全量使用 Serverless 技術，無需擔心負載均衡，彈性擴縮容，監控等基礎設施工作。

沒有哪個模式是完美的，在實踐自己的 DevOps 人員配置的時候，要想清楚自己的實際場景，當想清楚自己的人員配置的時候，要想保持高效就要考慮這些人與人之間信息如何流轉順暢。

從信息流轉層面看 DevOps

DevOps 是一種協作文化，協作流程，而協作的本質是順暢、精準的信息流轉。一個簡化的典型的 DevOps 信息流轉模型大致如下：

信息流轉順暢和精準的根本在於信息是否是結構化、流程化、標準化的。一個所有信息流轉都依賴聊天群、開會、郵件等形式解決，看似能夠一觸即達的信息流轉，往往會有重點不突出，信息遺漏，信息依賴人為跟進等問題，其實是不順暢也不精確的。

核心要把握 DevOps 實踐團隊的如下節點是否信息傳輸順暢且精準：

開發交付測試階段：信息提供方是開發、主接收方是測試、抄送方是產品經理、項目經理、運維等，這個提測申請是否結構化？是否具備標準？有沒有流程？是否有專用工具支撐？
測試回饋：信息提供方是測試，主接收方是開發、抄送方產品經理、項目經理等，這個信息最簡單的方式是採用體系化的缺陷管理系統配合上下游來一起管理，細化流程和標準後即可實現順暢，精準傳達
交付發佈：信息主提供方是開發，主接收方是運維，抄送方是產品經理、測試、項目經理等，這個階段的自動化程度是相當重要的，要想實現自動化，前提是結構化、流程化、標準化先行。在本文的後續段落中會以 Kubernetes 體系的自動部署為實戰來介紹如何結構化、流程化、標準化最終實現自動化

這幾個關鍵環節都定義好標準和流程的時候，再次要去看其他環節的細化信息流轉問題，接下來就是需要考慮使用何種工具系統為此標準和流程提速的時候了。

從工具系統層面看 DevOps

DevOps 的協作文化目的是提升團隊的效能，而自動化工具是必備的，好的工具體系應該是整合的、角色切面的、自動流轉的。工具系統目標是順暢精準的傳輸信息並且高效的執行機械化操作。

整合性：DevOps 的開源、商業軟件有很多款，然而大多數軟件系統之間都是弱整合狀態，很多都是宣稱支持 OAuth 或者 LDAP 用戶體系就算整合了，這裏面的差距還很大，例如 Jira 的項目和 GitLab 的項目，GitLab 的項目與 TestLink 的測試計劃，這些實際的概念在不同的系統之間都遵從着不同的產品設計哲學，實際上弱整合的工具系統在提升團隊信息流轉效率上並沒有太大幫助。

角色切面：好的 DevOps 工具系統應該像是一個為工廠量身定製的生產流水線，各個角色各司其職，關注精準的信息，執行標準的操作，輸出標準的結果。在弱整合的工具系統里可能不同系統的用戶、角色、權限設計都有很大差異，難以實現角色切面。例如一套基於 Jira + GitLab + Jenkins + Kubernetes 的體系，運維角色應該加入 Jira 的項目中么？產品經理是否需要關注 Jenkins 的 Job 執行狀態？

自動流轉：自動流轉是為了解決重複性的機械勞動而設計的，要想具備自動流轉的特性，整合性和角色切面也必須設計的非常好，開發完畢到提測自動部署，測試通過到自動發佈，在設計好流程和標準後都是一些機械化的重複勞動。

工具系統不是萬能的，有時候你會發現有了好的人員結構、信息流轉方式、整合性的工具系統，實踐起 DevOps 還是有一定困難，那你可以看看如下這個點：技術架構。

從技術架構層面看 DevOps

技術架構對 DevOps 的影響主要體現在構建、部署、運維環節。不同的軟件類型，技術架構在這三方面是有很大差異的。例如單機手游，只有構建和發佈市場，基本不存在部署、運維環節。而微服務架構 SaaS 化的多租戶雲服務在這方面就複雜的多。

這裡以典型的服務器端應用的技術架構升級過程來作簡要分析，例如對於一個基於 Spring 框架寫成的 Java Web 應用，其發展歷程可能是這樣的：

單體 Tomcat：構建一般使用 IDE 配合 Maven/Gradle，少許團隊會使用 Jenkins 之類的進行自動化構建 war 包，部署往往選擇 scp/sftp 形式進行發佈，停機部署，需要運維人員專門人工操作，容易出現錯誤
多實例 Tomcat + Nginx 負載均衡 + 動靜分離：構建開始變的複雜，前端的 js css 等需要進行獨立的壓縮和上傳，部署過程有很多運維團隊開始選用 Ansible 之類的便於管理 Nginx 的複雜配置文件和多實例並行發佈，Ansible 等工具為自動化的發佈提供了諸多便利，但仍然要求運維人員去撰寫難以維護的 playbook 和服務器的基礎軟件環境
前後端分離 + 容器化：當以 Docker 為代表的容器技術開始流行的時候，團隊開始嘗試構建的結果不再局限到 war 包層面，可以把前端和後端分別構建出 Docker 鏡像，以 Docker 鏡像作為標準交付，但服務的配置信息、擴縮容能力，健康檢查等問題仍然困擾着運維團隊
微服務化架構 + 容積集群部署：以 Kubernetes，Istio Service Mesh等為代表的容器集群編排和微服務技術開始逐步進入大家的視野，部分團隊開始嘗試讓開發團隊自主通過 Kubernetes 工作負載 Yaml 文件、ConfigMap 等形式管理配置信息，使用 Service 配合微服務的流量控制體系進行灰度控制、服務降級、熔斷處理、標準化健康檢查監控等。
Serverless 無服務器架構：以 Serverless Framework、AWS Lambda、Knative 等為代表的新一代無服務器架構的服務器端應用已經幫助一些技術領先的團隊實現了進一步的去運維化，後端開發只需要按照雲函數的定義要求進行少量的聲明或者配置，即可實現全套的 CI/CD、負載均衡、彈性伸縮、生產級別高可用等能力。如果你還不知道什麼是 Serverless，歡迎來這裡了解： https://cloud.tencent.com/product/sls

雲的發展也映射着技術架構的變遷，也引領着基礎設施運維的右移，大致分為三個階段：

VM/虛擬機實現了去硬件化 Hardwareless
Container/容器實現了去操作系統化 OSless
雲函數/Serverless 實現了去服務化 Serverless

每一種技術架構的 DevOps 的實踐模式是有差異的，分與合的程度也不一樣。仔細品味這些技術架構的特點，認真評估自身團隊業務運維左移和右移的程度，就可以選擇出合適的人員管理模式、選擇適合自己的工具系統，形成順暢、精準的信息流轉，從而讓 DevOps 的實踐取得實質性成果。

DevOps 的粘合劑：持續部署

持續部署是軟件交付的一種形式，常用於服務器端軟件的交付，在這裡我們以 CODING CD + Kubernetes 來簡要講述一個服務器軟件持續部署模式，我們假定團隊現在的各方面基本情況如下：

業務運維部分左移：常規發佈、配置管理等基礎業務運維左移到開發團隊
基礎設施運維部分右移：基礎計算資源由雲全託管，直接使用雲的 Kubernetes 集群，負載均衡器，數據庫等
開發團隊和運維團隊分離：運維團隊更多的是制定業務運維規範標準和流程，在雲的基礎上層進行更高層次的基礎設施運維，如製作業務監控體系，信息安全，日誌系統等
整合式 DevOps 系統：直接使用 CODING 提供的集敏捷項目管理，測試管理，代碼管理，持續集成，製品庫，持續部署為一體的 SaaS 服務
簡單的微服務技術架構：未引入如 Istio 等高級微服務架構（引入微服務架構的持續部署跟此示例類似，但細節過多，不適於在此文詳述），使用 Docker 鏡像 + Kubernetes

這種模式可能是適合目前國內大多數團隊的現狀的模式，具備相當的代表性，跟此模式有差異的團隊也可以通過此模式來品味本文的 DevOps 思考，去改進自身的實踐。

前提準備：

使用騰訊雲 TKE 創建一個 Kubernetes 集群： https://cloud.tencent.com/document/product/457/11741
準備好一套可以構建出 Docker 鏡像的源代碼，並提供對應的 Kubernetes Manifest 文件，示例代碼庫：https://wzw-test.coding.net/p/demo-for-cd/d/demo-for-cd/git
配置好自動構建過程：https://help.coding.net/docs/devops/ci/manual.html

本示例代碼比較簡單，我直接貼出幾個對應的核心文件：

app.py

from flask import Flask  app = Flask(__name__)    @app.route("/")  def hello():      return "<h1>歡迎使用 CODING CD!！</h1>"    if __name__ == '__main__':      app.run(debug=True,host='0.0.0.0')

Dockerfile

FROM python:3.7    COPY . /app  COPY pip.conf /etc/    WORKDIR /app  RUN pip install -r requirements.txt  ENTRYPOINT ["python"]  CMD ["app.py"]

Jenkinsfile

pipeline {    agent any    environment {      ENTERPRISE = "wzw-test"      PROJECT = "demo-for-cd"      ARTIFACT = "demo-for-cd"      CODE_DEPOT = "demo-for-cd"        ARTIFACT_BASE = "${ENTERPRISE}-docker.pkg.coding.net"      ARTIFACT_IMAGE="${ARTIFACT_BASE}/${PROJECT}/${ARTIFACT}/${CODE_DEPOT}"    }    stages {      stage('檢出') {        steps {          checkout([$class: 'GitSCM', branches: [[name: env.GIT_BUILD_REF]],                              userRemoteConfigs: [[url: env.GIT_REPO_URL, credentialsId: env.CREDENTIALS_ID]]])        }      }      stage('打包鏡像') {        steps {  sh "docker build -t ${ARTIFACT_IMAGE}:${env.GIT_BUILD_REF} ."          sh "docker tag ${ARTIFACT_IMAGE}:${env.GIT_BUILD_REF} ${ARTIFACT_IMAGE}:latest"        }      }      stage('推送到製品庫') {        steps {  script {            docker.withRegistry("https://${ARTIFACT_BASE}", "${env.DOCKER_REGISTRY_CREDENTIALS_ID}") {              docker.image("${ARTIFACT_IMAGE}:${env.GIT_BUILD_REF}").push()            }          }        }      }    }  }

deployment.yaml

apiVersion: apps/v1  kind: Deployment  metadata:    labels:      app: demo-for-cd    name: demo-for-cd-deployment  spec:    replicas: 3    selector:      matchLabels:        app: demo-for-cd    template:      metadata:        labels:          app: demo-for-cd      spec:        containers:        - image: demo-for-cd-image          name: demo-for-cd          ports:          - containerPort: 5000        imagePullSecrets:        - name: coding-registryservice.yaml  apiVersion: v1  kind: Service  metadata:    labels:    name: demo-for-cd-service  spec:    ports:      - name: http        port: 5000        protocol: TCP    selector:      app: demo-for-cd    type: LoadBalancer

在 CODING 平台實現簡單的開發與運維的切面

CODING 提供了團隊和項目兩個層面的基於角色的權限控制可以方便的實現不同角色的切面效果：

具體來講可以在團隊成員管理和項目成員管理進行具體角色的分配。

在此示例中我們的項目名稱叫做 demo-for-cd, 應用名稱叫做 flaskapp.

運維角色進行預配置

1. 配置雲賬號（讓 CODING 持續部署跟 Kubernetes 集群打通）

2. 創建應用 flaskapp

3. 把應用 flaskapp 跟項目 demo-for-cd 關聯：關聯後可以理解為這個應用的相關發佈權限和配置管理權限下放到項目中，映射我們提的「業務運維左移」思想

4. 在應用內創建部署流程：應用該怎麼部署，在什麼條件下部署，需要什麼資源這些由運維團隊制定，映射我們提的「交付發佈」要標準化，流程化

這裡有幾個細節需要注意：

運維在配置部署流程的時候需要制定流程啟動所需製品標準（此處映射我們提的交付流程的信息要結構化），我們聲明了啟動流程需要三個製品分別是: 一個 Docker 鏡像，一個 Deployment Manifest 文件，一個 Service Manifest 文件。

運維可選配置若干個自動觸發器來自動啟動這個流程（此處映射我們提的交付流程的信息在結構化的基礎上實現自動化），我們設置了當 Docker 鏡像庫出現新鏡像版本時自動觸發此流程。

可以給部署流程添加額外的通知推送用以告知相關人員（此處映射我們提的信息流轉要精準，區分主接收人和抄送訂閱），這裡可以把發佈事件信息同步到產品經理、項目經理等

幾個最佳實踐提示：

盡量做到版本化管理一切資源：版本化管理 Kubernetes 配置文件，管理容器鏡像，管理部署流程配置等等，這樣有助於快速的災難恢復，問題追溯等，這些能力 CODING 都已提供，可以很方便的實現。
可在流程中插入 Kubernetes Job，使用 run job 來處理發佈過程中的諸如數據庫表結構更新，數據遷移，靜態資源預編譯等過程
使用 Kubernetes ConfigMap 來管理配置項和配置文件，這樣所有的可交付製品類型就被限制為 Docker 鏡像和 Kubernetes Manifest，便於管控
可選使用獨立 Git 倉庫來管理 Kubernetes 文件，主要由運維團隊來管理，接受開發團隊的合併請求（可自由決定配置管理是否左移至開發團隊）

開發角色完成開發和發佈

在運維進行完上述配置後，開發人員就可以在項目里獨立進行發佈操作了（映射我們提的業務運維左移至開發團隊）。

開發團隊在確認新版本的三個製品（一個 Docker 鏡像，兩個 Kubernetes Yaml 文件）準備好後直接可以新建發佈單來執行發佈，因事先預配置好了流程標準，這裡開發無需跟運維團隊進行低效的無意義的其他形式的溝通，直接選定三個資源的版本即可執行發佈。

開發也可以通過上游的代碼倉庫、持續集成和製品庫的配合完成全自動化發佈，實現分鐘級自動上線。

其他場景的持續部署

持續部署是 DevOps 的關鍵環節，跟 DevOps 一樣與團隊的運維左移右移程度，技術架構等有很大關係，沒有哪個持續部署工具系統是可以涵蓋所有的場景的。CODING 持續部署希望能涵蓋大多數較新的技術體系，以及擁抱雲原生的部署場景。這裡給出幾點關於其他常見的持續部署的做法提示：

Ansible + 堡壘機場景：這類持續部署的核心在於 Ansible 的 Playbook 的撰寫質量，可以選擇直接接入 CI （如 CODING 持續集成、Jenkins）體系使用，實現快速部署。
雲主機的彈性伸縮組：CODING 持續部署支持基於雲主機鏡像配合彈性伸縮組的模式進行發佈，此模式較重，可以根據自己實際情況進行選擇。
scp/sftp，Git/SVN：建議儘快升級至容器等形態的方式發佈，在未升級前也可以考慮直接嵌入到 CI 中執行。
Serverless 場景：這種屬於基礎設施右移非常徹底的類型，大多數情況下不需要引入獨立的持續部署工具體系，可以考慮直接在 CI 甚至於 IDE 開發階段使用插件等機制添加部署能力，無需進行過度複雜的設置。CODING 持續部署不排除未來會針對 Serverless 部署場景添加更多的其他方面能力，如審批，通知等，以支持更安全穩定的發佈行為管控。

最後的總結：該分還是該合？

看到這裡，我相信你已經能夠把握住 DevOps 的幾個實踐的核心要素，DevOps 不是非黑即白的，只要有開發和運維的團隊自始至終都一直在實踐着 DevOps，只是效果有好壞，水平有高低。業務體系、團隊配置、技術架構、工具系統都有差異，脫離這些基本現實去喊口號，聊價值是無意義的。你的 DevOps 團隊要分還是要合，分合到什麼程度，請冷靜思考文中提到的幾個合。

作者簡介 王振威，CODING DevOps 研發四部總監，主要負責 CI、製品庫、CD 的產品設計及開發，在企業研發管理、代碼管理流程、敏捷開發實戰、容器雲技術落地、運維監控方案等方面有極為深刻的認識。