以下是基於容器的DevOps對人員和知識儲備的要求、落地後部門和流程的變化等相關內容，供感興趣的同學參考。

DevOps除了利用docker快速進行開發測試上線外，如何向公司說明採用DevOps後的好處？

我司的環境是：開發環境、測試環境、定時停業務釋出上線、上線功能性測試、上班時間生產、如出問題解決或回退（影響至少半天或1天）。

基於這樣的環境，Devops除了利用docker快速進行開發測試上線外，如何向公司說明採用Devops後的好處？
@wykkx

devops是以業務為中心的，所有的動作(加快上線部署，版本管理，問題記錄反饋，線上部署監控，釋出迭代，故障及時響應，快速版本回滾)都是為了更好和更快的滿足業務需求。本質上就是全方位的服務業務。

@caikai

DevOps是在傳統敏捷的基礎上，為了解決開發測試和運維脫節而出現的理念。我們在理論上就不贅述它能帶來的好處了，網路上討論的很多，總的來說，DevOps是一種工作模式，這種模式適合需求變化多、需要快速迭代、頻繁上線的場景，比如微服務架構的應用就更提倡使用DevOps的模式。但推廣DevOps並不容易，有很大的代價。

因此實際在做出是否採用DevOps時，理論的宣講往往是不夠的，需要用資料印證來說服決策層。那麼就需要自願的、或有領導安排的試點應用，我建議選擇程式碼掌控在自己手裡、發版也比較頻繁的應用，除了建立自動化流水線，還需要把應用相關的開發、運維人員編成同一個團隊，讓他們真正為同一套KPI而工作，負責應用的全生命週期，通過執行一段時間後，用DevOps前後的發版頻次、發版時間、發版成功率資料、溝通的效率來做比較，來決定DevOps你的部門的代價和收益。客觀地說，也不是所有的情況下DevOps都能帶來顯著的好處，比如現在和未來你也不需要微服務架構，1個月才發一次版，那麼你現有的流程和模式也許就已經運轉得很好了。

@於昺蛟

首先DevOps就不只是加速流水線那麼簡單（那是敏捷開發的事，別搞混了）。DevOps運用了敏捷思想加速開發沒錯，但是本質上DevOps還是一個迴圈改進業務系統的過程，先在這裡放張圖：

這個就是DevOps的迴圈圖。可以看到除了開發測試以外，DevOps更多的是持續的業務規劃，快速迭代，持續監控，以及通過監控資料和使用者反饋來優化系統。DevOps實際上是完全以業務為中心的方法。從初步構思、生產釋出、客戶反饋到基於反饋進行增強，DevOps不僅能最大限度提高產品或服務的交付速度，還可以幫助企業具備足夠的敏捷性和精益性，快速應對客戶需求、市場條件、競爭壓力或法規要求等方面的變化，因此 DevOps 對於所有這類企業而言不可或缺。

容器在傳統行業都還沒有普及，就開始搞基於容器的devops是不是更難落地？

@wykkx

這個問題問的好。在容器還沒有普及的前提下搞基於容器的devops難度確實大於傳統基於虛擬機器的devops，畢竟多了一層技術，這是事實。但是這個問題也要分角度去看，基於容器技術在帶來學習成本的同時也帶來了相應的優勢。

對於開發而言，基於容器技術可以遮蔽底層作業系統和環境變數的差異，可以防止程式碼被人修改(尤其是在做依賴開發時)，尤其是如果要做微服務改造，容器又具有天然優勢。帶來的直接成本是需要學習dockerfile的寫法。

對於測試而言基於映象更有利於版本的管理。

對於運維而言好處是可以快速實現擴容和更容易的高可用保證，但同時也需要去學習容器的運維知識。

所以在我看來，如果公司容器和devops都還沒有落地，可以選擇一個支援容器的devops平臺，然後用1-2個專案測試一下效果。記錄下遇到的具體問題，然後具有針對性的調整策略(先熟悉容器或者先落地devops)

基於容器的DevOps需要哪些支撐(平臺 和人員)？
@wykkx

平臺方面，首先要有一個友好的容器管理平臺，便於開發和運維人員使用，例如友好的dockerfile編寫，友好的映象製作功能，此平臺可以基於swarm或者k8s改也可以採用商業化產品。其次要有一個支援映象管理，利用映象釋出部署的的devops平臺，另外該平臺需要有ci/cd,監控告警，自動化運維能力。

@nuaays

首先基於devops的平臺支撐了哪些業務、面向了哪些客戶，

比如

–容器映象管理及平臺

主要牽扯到devops， 和幾乎所有會用到的映象的業務及人群；映象分為 需要保護的基礎映象， 可清理的整合測試的映象， 可能需要保護的release版本映象等。當然，除了基礎映象外，其他映象如果都可以通過程式碼某次提交能重新打包出相同映象的，可以只保護基礎映象。

映象管理平臺，業界比如Harbor等映象管理平臺都是在官方Registry之上加入管理介面、許可權、映象同步的功能， 推薦不同關鍵使用不同 的映象Registry做隔離，之間必要repo可以採取同步保持一致。

–構建打包及平臺

Dockerfile的編寫，基本的命令需要培訓給開發人員/測試人員，每個repo都需要有一個Dockerfile。

映象編譯： devops負責準備ready， 實現方式宿主機打包或者docker in docker 、打包叢集等可藉助Jenkins及相關外掛 檢測程式碼倉庫提交併自動觸發編譯打包。

–程式碼質量及平臺

DevOps環節中的靜態程式碼掃描和單元測試結果等由測試人員負責，開發人員也是關心的。

靜態程式碼質量平臺比如Sonarcube， 不同技術棧的單元測試結果評價方式可自己定義。

–服務部署及擴縮容、升降級

可以利用業界容器編排工具實現服務的部署，還需要考慮到叢集的劃分，是否需要SLB以便外網訪問。

服務的升降級，牽扯到新舊版本應用上下線及相關配置、相關中介軟體系統的配置。

釋出策略有藍綠、灰度等，企業結合自己業務特點選擇，不同策略牽扯到的人員也有略不同。

–服務日誌和監控

DevOps需要將日誌和監控系統分環境搭建好，並能提供友好的日誌查詢給開發測試使用。

執行監控指標已反饋業務人員，監控告警以多種方式及時給予devops及相關人員。

APM和鏈路跟蹤也需要其他元件實現而且是侵入程式碼的，需要開發人員和DevOps合作。

後續如devops專案上線，由誰主導運維了？
運維部門是否適合做為主導devops專案推進，整體架構需要拆分的話，需要開發部門主導，運維部門除了提供基於平臺外（當然可以建議多少資源呀？日誌檔案是否單獨掛載san共享盤呀之類的等），似乎沒有其它太多作用？後續如devops專案上線，由誰主導運維了？需要哪些人員，如何參與devops，職責如何劃分？

@wykkx

第一，需要明確的是devops不單單是開發與運維還需要質量或者測試人員的參與，而且測試人員正是連結開發與運維的重要環節。

第二，開發與運維經緯分明確實不太符合devops的文化，devops文化講究的是開發和運維各相互進一步，但是經緯分明也不阻礙devops落地。其實從發展的眼光來看，目前開發與運維經緯分明的現狀也是會慢慢改變的。

第三，在經緯分明的前提下，通過一個例子來說明devops落地：

開發人員負責寫程式碼，並生成映象，將映象推至映象中心，然後利用平臺進行單元測試。

測試(質量人員)利用devops平臺進行整合測試並將問題反饋給開發，以及負責定製釋出版本，並將釋出計劃告知運維人員。

運維人員拿到釋出計劃後結合具體情況安排釋出或者建議質量調整發布時間。釋出過程中根據自動化程度以及系統重要性知會開發排期支援。

運維的主導方還是原來的運維部門，只不過需要掌握devops平臺的方方面面，並且對業務架構要有更多理解，這樣才能夠在devops推廣中有更多話語權。

@nuaays

我覺得，如果是運維部門主導，首先運維部門要改變傳統運維Ops觀念，接納擁抱DevOps理念，從資源、流程、協作、優化、安全等方面參與到和開發測試一起構建DevOps專案

@於昺蛟

DevOps是以業務為核心的交付流程，所以開發測試運維只是DevOps迴圈裡的一半。真正的DevOps還要包括運營人員（執行時監控，資料分析），以及業務人員（持續需求分析，軟體設計，優化）。至於職責劃分上，DevOps相對模糊了職責劃分，而是重視各種角色之間充分的協作和信任。

計劃推進devops專案，在知識儲備上，當前瞭解docker/k8s，需要什麼樣的知識或技能儲備，才能更好的認識devops每一個環節呢？（或者說不被廠商忽悠呢？）
@wykkx

首先開發 測試運維都要對devops文化有一個基本統一的認識。開發同學要有良好的程式碼管理習慣或者說程式碼管理規範，並且能夠使用ci平臺進行持續單元測試。運維同學要熟悉python開發語言，有一個能夠hold住的cicd平臺，對監控的理解要至少提升到業務層面，並且具備批量處理的能力或者平臺。如果使用容器技術，開發測試和運維還需要對容器技術有一定了解。

@於昺蛟

就這麼講吧，雖然DevOps一眼就會讓人想到開發和運維，但事實上DevOps是一種文化，這種文化要involve組織中所有的利益相關方，包括業務、架構、設計、開發、測試、運維、安全……甚至合作伙伴和供應商。DevOps 文化的特徵是在各種角色間實現高度協作、專注於業務而非部門目標、團隊內部和團隊之間互相信任，並高度重視通過體驗進行學習。

所以如果真的某個人被指派成為這個大管家的話，那這個人除了必要的技術以外，更多的是要對業務和開發的整個流程都有深入的瞭解，知道整個交付管道的瓶頸在哪裡，如何推動整個團隊實現DevOps的最佳實踐，以及在哪裡可以推動業務創新。這麼講，推動DevOps最重要的工具還是人。