在上一篇?DevOps 淵源：角色消融?中我們分析了在作坊式團隊中的責任重疊，也回顧了 DBA 角色的消融。那么，如今我們講的 DevOps 又是什么角色的消融呢？ 我想你已經猜到了，接下來要消融的角色就是運維人員了。那這次又是什么生產力決定了怎樣的生產關系的變化呢？實際上，不止是開發人員的生產力的變化，而是包括了運維的生產力在內一起發生了變化。

DevOps = Dev + Ops

---

視線再次回到上面的作坊式小團隊里。以上面那種手工部署的方式，面對少數幾臺服務器問題還不明顯。當業務擴大，用戶量迅速在兩個月里從 20 萬增長到 50 萬，服務器也從 3 臺增加到了 10 臺，針對他們來對應用程序的部署和日常維護的工作量徒增，繼續手動操作帶來的錯誤和其他不可控風險（如偶見的服務器環境問題）讓人越來越不放心了。這時候，運維人員們撿起了多年不寫的腳本，開始了服務器環境自動化的過程。

另一頭，開發人員開始引入持續集成實踐來保障質量：單元測試被引入、發布版本也可以自動化了。當他們開始實施端到端自動化測試的時候，猛然發現對服務器環境的準備過程竟于生產環境如此類似。

在小團隊里，開發人員和運維人員就坐在隔壁，類似于上學時同桌的你。他們很快決定通過結對編程的方式高效地整合他們的工作，并繼續統一的工具鏈體系來提供在開發階段和生產環境的各類需求。包括代碼編譯、創建新服務器、安裝依賴軟件、部署（遷移）數據庫、多環境配置、自動化測試，以及版本發布流程全部都能夠在統一的軟件上完成了。

那么，這倆同桌，他們是 Dev，還是 Ops 呢？他們共同宣布了一個新詞：DevOps。DevOps 讓運維工作展現在 Dev 面前，讓他們從更廣的視角來看待等整個系統，代碼不光要寫完，還要能夠自動地部署到服務器上。DevOps 不是指運維的消失，而是以更高效和可靠的方式在做運維。

樸實地說，DevOps 包括從代碼開發開始，到產品部署到產品環境，再到產品在生產環境的運行期間的監控與維護為止的整個過程。這也是大多數人所理解的 DevOps。如果讓一個開發人員來用一個詞形容 DevOps 的話，他會說自動化。

DevOps 運動

---

至此，作坊式團隊里的 DevOps 故事也就講完了。我們看到，小團隊在組織層面的包袱很小，而在實踐層面也比較容易跟上，往往他們的迫切的問題是開發進度太緊，面對技能不足，卻沒有足夠的時間和機會來夯實技能。要解決這些問題，除了團隊客觀條件亟待改善之外，還有產品思路和發布規劃的優化。這對于小的團隊說來，只要決策人下定決心，整個團隊成功實踐 DevOps 并不困難。

那么，情況在其他團隊是怎樣的呢？

我們來看一下大一些的團隊。由于他們并不缺人手，上述過程就會是另一番景象。再回頭看一眼上面的過程，我們不難發現有很多風險很大的地方（例如，開發人員自己編譯一個新的程序包，直接放到服務器上），而風險則往往是大團隊需要盡力去防止的。于是他們有一系列流程管控措施來防止問題出現在生產環境中。他們有獨立的需求分析部門，有嚴格的代碼審查流程（甚至團隊），專門的版本發布團隊或者負責人，以及話語權很高的質量和風險管理體系。

相比而言，大一些的團隊，掌握 DevOps 技能并不成為大的挑戰——他們有足夠的資源可以在短時間里快速構建這些能力，相反，他們更大的挑戰卻是在團隊結構不變的情況，大家各個“專門”的角色如何向 DevOps 實踐看齊，并讓這種機制持續下去。這正是 DevOps 運動劍峰所指。《鳳凰項目》講了一個 IT 運維經理臨危受命，通過三步工作法，以及同事間協作幫助的情況下，拯救了一家歷史悠久的汽車配件制造商的故事。這本書還介紹了開發運維模式的 “三步工作法”。

第一工作法是建立從左到右的高效工作流。典型做法是持續自動化構建、集成和版本部署等。第二工作法是在這個工作流的相反方向，從右向左建立逐級的快速反饋流，及早發現問題，謹防問題向更右邊流動。典型做法是高效的代碼檢查，堅守持續集成紀律，測試前移和自動監控機制等。第三工作法是在組織層面，構建快速試錯和學習成長的氣氛和文化。典型做法是放權和信任、復盤問題，規模化創新等。

這樣看來，DevOps 不再只是開發團隊的事了，獨角戲是唱不持久起來的。它一定還還涉及到圍繞開發團隊的其他角色，如與其他開發團隊的關系和與非開發部門的協作等，它還涉及到企業文化的構建，才能讓 DevOps 深化和持久地實踐下去。

回顧與討論

---

在上一篇，我們主要講了作坊式團隊中角色重疊，這種重疊天然是由于他們的天然壓力所決定的。于是，事實中不少小團隊長年累月地受困于無盡的需求變更，還沒來得及思考怎么打造好團隊，團隊里的力量就在一次次更新的過程被不斷稀釋得只剩下一團亂象。但如果團隊幸運地遇到了懂得打造工程師文化的負責人，那他們反而更能利用優勢，在 DevOps 運動中成為最具活力的那一群。

各司其職并通力協作是大型項目的常見做法，人類的各項大型工程一次次成功地實踐著這樣的經驗。然而在 IT 領域這樣的協作模式正在受到挑戰。近年來，我們發現不少產品是由只有少數人的團隊研發的，在短時間取得了巨大的成功。

芬蘭的游戲公司 SuperCell 以 5~7 人小團隊的模式在短時間里快速地推出不同的游戲，同時收集用戶的喜好信息，據此決定進一步投放到這個游戲的資源。如果受不到歡迎，就快速宣布失敗、分析教訓并用于新游戲的研發。到他們被騰訊以 86 億美元被收購時，整個公司不超過 200 人。

這些不斷踴現的案例讓不少大型團隊也在思考如何更好地調整姿態來嘗試接受 DevOps，讓它成為團隊的日常風格，從而提升團隊效能。不過，作為一個探索性命題，我們不妨深入再想一層：如果說 DevOps 是 IT 開發團隊需要考慮的方法論的話，那么對于大型企業來說，組織層面又該怎么辦？

上面提到，DevOps 對企業文化是有所期待的，而文化這種一般變起來是相當難的，對于那些暫時還是業務驅動的企業來說尤其如此。顯然，這時候，對于改變企業文化來說，DevOps 作為一種驅動力來說是遠遠不足的。答案在數字化轉型體系可以找到，它正是企業組織整體的敏捷性。在這個體系中，它更將學習型組織設定為企業整體的文化。當然，要在更廣的層面去轉型，更是談何容易？不過，換個思路來想，IT 團隊的 DevOps 相當于自下而上的轉型，而企業層面的數字化主動轉型則是由上而下的轉型。大膽地想象一下，假如數字化轉型獲得成功，團隊的 DevOps 文化會不會自然踴現呢？

原文地址?：https://blog.jijiechen.com/post/devops-the-future/

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的DevOps 实践：千里之行的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。