基於最近幾年從事與DevOps的相關實踐，對這篇文章的觀點深有體會，所以記錄在這里。加粗部分是我比較深有體會的，但是對於最后作者對於“運維”有些悲觀，我有點不敢苟同，反而對於運維的要求其實是更高了，”自動化-容器化-集群-智能化“代替了傳統的“人肉”
1. DevOps 的本質
DevOps從本質來講只是倡導開發運維一體化的理念（MindSet）。這個理念的提出是為了解決很多企業面臨的轉型挑戰，也就是將業務數字化，並且縮短數字化業務上線的周期，快速試錯，快速占領市場。
DevOps並沒有改變固有的軟件生命周期：需求，設計，開發，測試，交付。但伴隨着基礎設施，軟件設計方法等的改變，軟件開發的思路，或者方式產生了比較大的變化。
DevOps帶來的最大好處是，軟件生命周期數據鏈路的打通
這不僅僅是運維和開發的結合。從頂層視角看，這是業務和生產的緊密結合。以前從業務和開發是脫節的。想要查看需求的實現進度，需要大量的人工匯報，更別提運營了。而現在以一個微服務實現一個特性的粒度來看，可以從需求，開發，測試，部署一直追溯到這個特性運營情況。這也是DevOps成為數字化企業基因的原因，業務和生產實現了完美的結合。
從敏捷實踐的角度來講，你會發現開發組織中參與者好似生物體中的神經元，大家各司其職，自成一體，接受反饋，並向外主動反饋。團隊的自組織使得工作更加自然，能產生更大的效能。由以前的項目經理驅動，改為自我驅動的協作方式。每個人都可以給相關的團隊以及責任人提需求，大家有機的協調在一起。
2. 一個DevOps改造案例
這里給大家分享一個改造案例，公司A存在的問題：
- 軟件交付周期很長，一年只能交付一個大版本，以及一個小版本。
- 人員分工不明確，一個決定的做出往往需要很多人參與。
- 用大量的時間挖掘需求。在真正的開發期，會發現用戶的需求仍在改變。需求分析的時間被浪費。
- 采用瀑布模式開發，在不同時期，某些角色的人員會無事可做。
- 在軟件交付過程中，開發與運維人員需要花費大量的時間去協調產品安裝，配置中出現的問題。
改造步驟：
-
第一階段：
行動：為了實行DevOps，公司A為不同的生命周期購置了支撐工具，涵蓋JIRA, PagerDuty，GitHubEnterprise，Jenkins等。公司針對每個工具都進行了專門培訓，專人管理。結果：大家開始將不同的工具應用到軟件生產的各個環節中，統一的工具塑造了統一的工作方式，創造了工作契約。統一工具的運用確實對軟件交付帶來了一些積極的改變。
-
第二階段：
問題：各個工具仍舊是割裂的，代碼管理和任務管理無法協調。開發人員聲明已經完成的工作，測試人員卻發現無法找到構建來完成測試。運維人員和開發人員只是利用了同一種工具，而沒有做到工作產物的共享。
行動：公司A開始關注工具所提供的能力而不是功能，將不同工具的關鍵交付物連接起來，形成可追溯的管理。開發人員發現提交的代碼可以產生可用構建后才聲明功能完成。並且用同一個任務來追溯開發到上線的工作。尤在開發與運維結合方面，運維人員可以利用開發人員已經實現的部署設計，進行發布演練，確保軟件平滑交付。
-
第三階段：
問題：有了好的工具，但是公司A發現雖然開發到運維的路通了，但是軟件質量卻難以保證，甚至在產品發布日期鄰近的時候，仍有很多未完成的任務，測試團隊頂着很大的壓力，最終還是會發生不少測試逃逸，產品的技術欠債比較大。
行動：在開發階段采取分支開發的方法，功能實現並且通過一定的代碼測試之后才能合並到主干。開發人員負責部分的測試任務，由於對產品比較熟悉，所以加快了測試效率。專門的測試團隊會承擔例如性能測試等更加專業的測試任務。有節奏的控制軟件開發的進度，在軟件發布的穩定期嚴格控制代碼提交，每個新功能的開發負責人會和運維人員一起進行發布演練，DevOps的好處終於開始見效。
-
第四階段：
問題：團隊前期在需求分析中會花費大量的時間進行文檔編寫，但開發開始后，開發人員會花費大量的時間對文檔進行理解，並且用戶對需求的調整最終導致文檔失去維護的意義；大家的主動性不強，需要領導的督促才能進行工作安排。行動：公司A意識到他們之前只是采用看似敏捷的方式，實際瀑布的方式做開發。比如說項目經理變成了Scrum主管，周會變成了每天的站會。在進行調研分析后，公司A決定開始進行敏捷實踐。分階段的按照重要程度以及優先級進行需求規划，周期性的互動使得客戶在第一時間可以看到期望的需求被逐步實現，雙方都避免最后一科的意外。開發人員發現可以對自己負責的任務有話語權之后，大大激發了積極性，大家開始主動的從Backlog中尋找重要的任務去實現。
從以上的例子可以看出，一個好工具的運用會對工作產生積極的影響，但是更核心的是人做事思維，以及人與人之間的協作方式才會體現DevOps的好處，我想從這點大家可以看到為什么DevOps是一種Mindset。
3. 微服務、容器和DevOps的關系
微服務只是一種設計思路，或者說他給出了如何用正確的方法來進行SOA的實施。理論上來講他的確和DevOps沒什么關系，但是從如何實踐DevOps的角度來講，微服務是非常有意義的。此外，隨着諸如Spring Cloud以及微軟Fabric等SDK的完善，微服務開發模式也逐步完善，實現了概念的落地
Docker可謂是一種敏捷化的虛擬化技術（較之虛擬機而言）。其實微軟Fabric或者CloudFoundry也都脫離開容器的概念提供了微服務開發的解決方案，所以這兩者並不是強綁定的關系。但是容器用不可變配置架構實現了微服務從開發到運維的質量保真度，這恰好解決了粒度小，數量多的微服務所帶來的運維難題。再加上K8S，Swarm等容器雲的支持，docker容器已經形成了事實上的標准。
如何利用這個強大的運行環境幫助企業敏捷，推進業務數字化，並且加快業務的投產？ DevOps為上面所說的開發模式提供了軟件生產線。
所以總結的來講，企業業務敏捷是DevOps發展的直接推動力，容器雲，以及微服務為DevOps提供了技術可行性。而敏捷幫助提高DevOps工作效能。
對於團隊的拆分，這個問題真的要結合產品規模來看。團隊的拆分有很多辦法，貝索斯說的two pizza team，是建議一個團隊中的人盡可能少，不要超過兩個Pizza能吃飽的規模。用敏捷實踐來講，可以分為多個特性團隊，以及維護團隊，不同的團隊各司其職，合理分工。在我以前的實踐中，三個人可以做一個Feature，來交付一個月迭代的工作量。
當然將原有的巨石應用分割成更小的微服務是挑戰很大的事情。因為理論上的微服務的設計對現有的團隊組織結構，以及工程師設計能力都帶來了一定的挑戰。有些組織按照DDD（領域驅動的設計）的方式去實踐微服務，會發現以前一個應用的復雜度變得很高，對項目管理來講也是一件頭疼的事情。現在有個比較新的看法就是，大家宣稱做微服務（MicroService）的時候，實際上做的是迷你服務（MiniService）。迷你服務的粒度較之微服務的粒度更粗一些，關注度由一個域Domain，變成了能力。一個迷你服務提供一種能力，這種能力的提供也許是跨越多個域的。
最好的方法是以一個團隊能承擔的任務划定微服務的界限比較好，這樣以來，不論是任務管理，代碼構建，產品部署都會比較好做。
更關注服務的能力，這樣也會減少因為跨域而帶來的復雜事物處理
4. 為什么落地DevOps還是那么難？
我認為DevOps概念對市場的教育工作已經完成了，並且它宣傳在國內有點泛濫的趨勢，甚至一些以前做項目管理工具的廠商也宣傳他們在做DevOps。究其原因在於DevOps的概念太大，幾乎可以成為軟件工程的代名詞。
至於落地的痛點，我覺得有以下幾個：
-
DevOps對於組織來講是一個系統工程化的投入，在貫徹的過程中，需要一個組織建立標准，統一紀律，而這個過程往往需要組織中的強力部門自始至終的貫徹執行。
-
DevOps對組織現存的管理方式，或者人員知識結構多少帶來了一些挑戰。
-
認為購置了工具就是DevOps，卻忽略了工具產物之間的聯系。
-
認為有了全生命周期的工具就是DevOps，忽略了軟件過程方法的運用，所以很多組織停留在用舊的方法使用新的工具上。
開啟DevOps工具和文化缺一不可。DevOps的最高目標是讓組織內的人都具有相同的工作理念，最終形成一種工作文化。而有些倡導者談到如何去培養這種文化就顯得有點空談了。我認為在形成DevOps文化的過程中，敏捷實踐必不可少。過去的敏捷實踐更多的是在開發階段，而現在DevOps的理念下，其實可以很順暢的將部署階段的事情也納入敏捷實踐中。讓合適的人去做合適的事。當然團隊文化的改變需要一個過程。
我認為以敏捷方法為核心配合以下三個方面來開啟DevOps。
-
看板：以任務的狀態為核心，管理在制品的生產情況。任務是自組織團隊的工作契約。
-
基線：以工件的版本為核心，選取合格的交付物。比如說開發團隊決定哪個代碼提交版本，或者編譯的構建版本為最終交付的版本。度量指導基線的產生。
-
流水線：以生命周期的階段為核心，控制基線交付物的投產。比如說一個合格的代碼基線目前處於編譯態，還是部署態。自動化工具圍繞管道互相集成。
其實工具和文化最終的落實還是要靠人的提高，特別是通過上一段舉出的例子。
DevOps會重新塑造IT組織的研發系統，從工具到文化，再到方法。因此參與這個生態系統的所有人都應該關注。
-
從開發的角度看：開發人員會變得更加業務化，有更多的機會和客戶交流。開發人員將從以前對代碼負責，轉向編譯構建負責，對測試負責，甚至對部署物負責。敏捷可以讓需求足夠的小，這樣就可以讓一個開發人員變得全生命周期化了。
-
從運維的角度看：其實運維的前景是有些悲觀了，至少運維的規模要縮減很多。
原因有三。首先，自動化部署工具的發展，使得部署工作提前了，以前碎片化的腳本，被更加規范化的部署設計代替，用設計驅動腳本生成，這都是自動化的。其次，基礎環境的改善使得開發環境和生產環境的差異性極大縮小了，企業完全可以制造一個和生產環境一樣的預發環境，來保證交付的成功率。容器技術的不可變配置也保證了同樣的鏡像在不同的環境中不會出現太大的差異。最后，運維工作相對開發工作來講，可以自動化，甚至運用人工智能的空間都比較大。我們已經看到百度已經開始AIOps。