本文轉載至微信公眾號：EAWorld

關於作者：

胡帥

普元資訊高階軟體架構師，計算機軟體與理論碩士。曾供職於IBM中國開發實驗室，參與Rational Team Concert, Rational Insight等產品研發，曾經擔任著名開源BI產品BIRT社群顧問。為工行，招行，建行，美國通用等大型企業提供DevOps以及BI產品諮詢實施服務。在DevOps以及BI方面積累了豐富的研發與實施經驗。

2010年，我曾在IBM供職，開始參與DevOps相關的產品研發與實施工作。今天看來，我也許是國內較早的DevOps踐行者。這兩年DevOps在國內開花結果的時候，我見到了很多錯誤轉型的亂象。本文中，將為大家分享自己對DevOps行業發展的觀察，並向介紹DevOps轉型的路途中都有哪些陷阱。希望通過本文，大家能更夠撥雲見日，真正的使DevOps成為企業生產力增長的助推器。

本文目錄：

一、軟體工程的發展
二、DevOps轉型陷阱
三、DevOps核心實踐
四、DevOps生態環境

一、軟體工程的發展

1、工具的發展

首先說DevOps並不是一種工具，而是一種理念或者團隊文化。為了實現這一種理念，於是就有一系列的軟體工程的支援工具（Computer Aid Software Engineering）。說到CASE，就不得不說一說，兩個軟體巨頭：微軟和IBM。我們以他們的軟體工程之路，來說明行業的發展歷程。

早在1997年微軟就推出了視覺化的開發工具，Visual Studio（VS），相信寫過C或者C++的同學們一定不會對這個工具陌生。接下來.Net框架的誕生，讓微軟統一了開發平臺的架構，整個VisualStudio所支援的C#, VB, C++等可以編譯成中間語言，託管在.Net Framework之上執行。可惜那時微軟足夠有錢，還在走閉門造車的路子。

.Net不僅不跨平臺，整個VS的架構也比較封閉，只有商用的軟體才會為VS生產外掛。與此風格截然不同的IBM，走開放路子的Eclipse在2004年誕生了，Eclipse的誕生漸漸拉開了開源軟體對抗企業軟體的序幕。

進入2005年左右，軟體工具進入協同開發的階段，微軟推出了伺服器端TFS (Team Foundation Server)。TFS的推出，使得多個程式設計師可以方便的進行程式碼配置管理，任務管理，以及資料分析，構建等工作。這時軟體開發工具已經開始和軟體過程相結合，將敏捷的思想注入到工程實踐中。在IBM一方，Eric Gamma（相信看過GOF設計模式，以及一些列Eclipse書籍的同學們不會對這個名字陌生）等大師將Eclipse中單人持續交付的體驗拓展到整個團隊，使得整個團隊在一個統一過程，同一平臺，統一計劃中，互動性的完成工作。

Rational Team Concert誕生了，它使得大規模（500人以上）工程化的軟體開發與設計變得更加容易。一直到2012年左右，DevOps文化漸漸在市場中盛行起來。其實對於傳統軟體來講，做部署並不擅長，所以這兩家巨頭都不約而同的收購了兩個做持續交付軟體的公司：In Release和 Urban Code。於是全生命週期的協同開發工具已經完備，DevOps 從概念到落地都有了完整的鏈路。從兩個巨頭的軟體工程之路可以看到，DevOps的出現是一個漸進的過程。它的內生原因是人們不斷追逐軟體生產的工程化，產業成本降低以及效率的提升。

過去20年，軟體開發工具的發展趨勢是不斷的將軟體生命週期不同階段的工具整合起來，形成一個大而全的軟體生產平臺。一個企業採用單一的生命週期工具有時候會受到學習成本，遺留系統，整合壁壘等諸多原因的制約。而微服務化的DevOps開發工具則幫助使用者解決這一問題，諸多PaaS平臺上的DevOps實踐就是以微服務工具鏈的形式推出。可以說微服務的設計方法與相關的支援工具，和DevOps這種小團隊，持續迭代持續交付的理念簡直是天作之合。

2、組織的變化

團隊組織結構也在這些年發生了微妙的變化。不管是全棧工程師還是流行的NoOps都在說明專業的界限被打破，開發團隊由技術向業務轉型。

對於很多測試人員來說，這是一個憂傷的話題。很多IT公司的功能測試部門FVT已經被開發人員所取代。取代的基礎是用各種自動化軟體，做到更好的單元測試，冒煙測試。並且在迭代的後期利用開發人員的閒暇時間來完成手動測試。傳統的測試人員需要培養自身承擔自動化測試用例，效能測試用例，系統測試等複雜測試工作的能力。

當DevOps相關的平臺統一後，開發驗證階段的產品部署架構，部署模式可以無縫切換到生產態。對於實際的生產態部署來說也許就是一個環境的切換，為了確保萬無一失，在一個準生產系統之上演練上線工作。因此傳統的開發和運維人員之間的界限會越來越模糊，以及雲平臺對於服務FailOver策略的處理越來越成熟。

今後的運維團隊可能非常的輕量級。軟體工程的大方向是被經濟利益所驅動的，所以DevOps運用之後很多開發人員也許會“被迫”去做更多測試，運維的工作，是不是有點無奈？

3、軟體過程的發展

直至今天，瀑布開發模式仍舊是許多組織採納的方式。不用質疑，瀑布方式在中國有一定的文化基礎。但是漸漸的我們意識到嚴格的瀑布模式往往會造成一定的資源浪費。比如在相同的人員和相同的時間長度下，傳統過程交付可能花費大量的時間去完成是一份完整的需求文件，但是留給軟體開發的時間少之又少，再加上需求的變化。回頭來看需求文件往往已經過時。

類似RUP（Rational Unified Process）的迭代開發模式就是儘可能的早的獲得使用者的意見，控制風險。它其實是介於敏捷和瀑布之間的一種模型，不如敏捷靈活但是控制性比敏捷更強。RUP的迭代雖然允許需求和開發並行，但是他仍然強調大部分需求內容都應該在主要開發工作之前完成，而不是敏捷中程式碼就是設計，需求和開發互為彼此，不斷完善的方式。顯而易見敏捷需求的時間大大減少了，所以後期調整需求的代價較之瀑布和迭代來講也更低。

XP極限程式設計甚至不太推崇大家做過度的設計，類似於一個CRUD的功能，程式設計師有時會不自覺的追求更高的拓展性，搞出了一個框架來。這讓我想起來一個很有意思的問題。那就是專案與產品的細微區別。做專案大多是為了追求短期利益，滿足客戶功能需求為先，良好的拓展性並不是專案的核心需求。不必要的設計會影響接納需求變化的能力，這和擁抱改變的想法有些不一致。類似在ThoughtWorks這種做敏捷諮詢的公司，客戶會另外付錢購買程式碼重構的effort。而產品研發的需求相對固定，並且一個產品要有良好的發展，必須培養一個良好的生態系統，擁抱未來不同的拓展需求。長期來看框架和平臺化反而符合產品的利益。所以敏捷中倡導有些原則有時要辯證的看。

敏捷方法在國內還沒焐熱，大規模敏捷的軟體過程已經誕生。然而在很多敏捷大師的眼中，SAFe和Less只不過是穿了馬甲的RUP。敏捷不能大規模開展嗎？其實不是不能開展，而是如何開展的問題。大家知道敏捷推崇的是小團隊文化，類似亞馬遜倡導的Two-pizza團隊，建議團隊規模維持在7人左右。然而動輒幾千人的跨國研發組織，如何開展敏捷的確是一個問題，這就是大規模敏捷存在的意義。

二、DevOps轉型陷阱

DevOps簡單的來翻譯就是運維開發一體化。但是究竟如何來一體化，怎麼做才能一體化？可能不同人對DevOps有著不同的理解，這取決於大家在哪個場合被什麼人安利的。認識的盲點也就造成了實踐的誤區。

比如說自動化，基礎設施即編碼，配置管理資料庫的應用，看板方法在運維中的應用等等，可以說這一切都是有關DevOps的實踐，而又不是DevOps的全部。向DevOps轉型的路上有很多坑，我們先從文化轉型談起。

1、文化轉型陷阱

很多人好奇敏捷和DevOps是什麼關係。敏捷是一種軟體開發過程，最初只是在軟體開發中推廣，很多人提出由開發敏捷轉型到運維敏捷，從而到業務敏捷。這個提議毋庸置疑，不管從文化，流程以及工具層面都是很好的延伸。可以說敏捷方法，敏捷工具為DevOps理念提供了很好的理論指導和工具支援。近些年來很多公司逐漸開始進行敏捷實踐，比如說專案經理變成了Scrum主管，使用者故事替代了以前的需求，開發計劃變成了更短的衝刺計劃。以前每週一次的組會變成了每天的站會。一開始大家都精神滿滿，久而久之覺得每天的站會太麻煩。而Scrum主管還是以前那個逼著大家幹活兒的專案經理。衝刺使得開發週期變短了，能做的功能也變少了。頻繁上線給運維人員帶來更大的壓力，生產環境的Bug似乎比以前還要多。

“如果不瞭解團隊自治，責任共擔，面向交付，那就不瞭解DevOps文化。”

2、工具轉型陷阱

不論是之前的敏捷，還是現在的DevOps，很多人對於CASE工具都有一個誤區，覺得用了這個工具，就具有相應的軟技能。但是用了一陣子之後才發現完全不是這回事兒。為什麼會出現這種假象呢？
我們知道工具僅僅是現實工作中的一部分，如果僅僅是部署了DevOps工具，然而人員和整個工作流程並未改變會出現什麼？很可能出現的情況下是，大家用共同的工具進行工作，當然也取得了比之前好一點的效果，但是工具壁壘並沒有消除。

“如果CASE工具只是孤島，那就很難幫助企業培養好的DevOps實踐。”

3、DevOps的雙刃劍

其實風險本身並不可怕，可怕的是拒絕風險，或者放任風險。大家可能已經看過很多DevOps宣傳，覺得實行DevOps之後可以做到萬無一失，從開發到交付是分分鐘搞定的事情。其實這裡有個陷阱。那就是工具可以幫助生產到交付快速進行，但是從另一個角度講，如果一旦出現問題，錯誤也可能會很快傳遞到生產環境中。所以如何快速捕捉問題，解決問題，而不是讓問題傳遞，這才是DevOps要處理的問題。另外儘早的在持續交付的初期發現問題，比如說有價值的缺陷，然後把它作為單元測試的目標去防範，這對於團隊來說是一個不斷成長的過程。

“精益的側面是控制風險，所以要小心風險和DevOps流程一起傳遞。”

三、DevOps核心實踐

剛才說了很多DevOps轉型中的陷阱，也就是說一不小心就會栽到坑裡，覺得DevOps就是那樣了，做著挺彆扭，更沒帶來什麼好處。要知道DevOps實際上是一種面向軟體交付的理念。文化轉型真的挺難，到底該怎麼做呢？我們從三個維度講述DevOps的核心實踐。

1、自治的小型化團隊

這點對於很多公司，特別是目前國內的諸多公司來講也許很難做到。組織的自治意味著控制力的減弱。控制力的減弱加上人類天生的惰性將導致專案的失敗。這可能是團隊轉型中存在的共同問題。實際上自治並不是說缺乏管理，而是說對目標做出正確的期望，對結果做出合理評價。中間的過程通過一系列的檢查點做出指導和糾正。其餘的工作交給團隊去協調完成。

首先敏捷實踐中將使用者故事，任務等明確責任人，這是非常好的做法。明確了責任，大家才能向目標邁進。而另一個責任共擔的好辦法是讓每個人參與團隊計劃的制定，大家幫助任務的負責人共同估算出故事點。這樣不僅會培養團隊成員的責任感，並且最終估算的結果會比專案經理自己做出的決策更加準確。在專案執行的時候，看板等工具的運用使團隊中每個參與者的工作都具有相同的可見性。以看板中待辦項以及任務狀態確定每天站會的內容。而不是架構師彙報技術難點，專案經理彙報開發狀態，大多數人被忽略的情況。

不超過10人的小團隊被很多企業證明是一個良好的實踐。可以讓對的人去做擅長的事，如果團隊過大很多人無法承擔合適自己的角色也是一種浪費。另外隨著持續交付的演進，產品總有新的需求，也有舊的問題。如何合理分配人員從而做到一石二鳥？一些組織開始將團隊分為若干個特性團隊和維護團隊。這樣能帶來以下好處：

• 每個特性團隊都有一個架構師，同時也是Scrum主管。由於人數小所以很容易做到工作進度與工作量的管理。
• 特性團隊和維護團隊，互相輪崗。在維護團隊中，成員可以接觸客戶，新成員可以通過修復Bug熟悉產品，對產品足夠成熟後再輪崗到特性團隊。
• 不同的小團隊甚至可以不用在一個地方。
• 從DevOps的角度，一個大的產品團隊就可以完成專案開發到上線的整個交付工作。

2、可控的全程追溯工具

用一句之前流行的話來說，那就是有了這麼多高大上的工具之後，還是做不好DevOps。如何正確的使用DevOps工具呢？核心的概念其實就是讓我們在工具上所做的事情在不同的生命週期時可以做到全鏈路的可追溯，因此我們給出以下實踐：

• 從需求出發，驅動任務執行。
• 任務和程式碼生產相結合，進行追溯。
• 以任務為單位進行持續整合。
• 以需求為單位進行持續交付。
• 以質量為綱，進行系統驗收。
• 運維規範化。
• 隨時隨地的溝通。
• 持續監控，持續改進。

參照上面的實踐，我們來舉個例子。開篇我們講了兩個業界著名的DevOps支援平臺，他們是緊耦合DevOps工具。隨著開源軟體越來越多，功能越來越強大，甚至某些已經超過了商業軟體的能力。因此越來越多的公司都會基於本公司原有的開源工具之上構建DevOps環境。我們儘量的選取了公有云和私有云中都有的工具版本進行說明。

通過上面的實踐，就可以將一個DevOps平臺搭建起來了。根據使用者的需要可以在私有云和公有云的不同選擇不同的版本進行平臺建設。只有將這些核心工件整合起來才能形成有效的可追溯鏈路。

這種整合方式給運維帶來的改變可能要多於傳統的研發，因為傳統的運維在方法論，工具，規範程度等方面還遠不及開發，比如說：

• 與很多成熟的開發流程脫節，以及生產環境的相對隔離造成了運維的黑賬本（碎片化的指令碼）。
• 環境部署後，使用者和管理者的資訊不同步造成了很多殭屍系統。

近些年來，基礎設施既編碼（IaC）以及配置管理資料庫（CMDB）的應用實際上就是為了解決上面問題。既然運維實際採用一系列的指令碼來部署和管理系統，那麼就應該把這些指令碼和開發程式碼一樣統一化管理，甚至納入。而CMDB的作用就是將運維的工作成果和企業的其他IT資產統一管理，消除那些殭屍系統。

3、實時的度量驅動

軟體開發過程中充滿了各種各樣不確定的因素，有時一個小情況的出現就會成大程度影響軟體產品的按時交付。對於中高層管理者來講，只能通過重複的人工週報月報來獲取資訊。然而不及時，且摻雜人工資料的報告講給決策支援帶來很大的誤導。DevOps就是要將資料鏈路打通，為管理者提供實時，準確的生命週期資料。使管理者在風險到來之前有效的對其管控。

可能在傳統的印象中度量不就是一堆報表嗎？其實這裡有個很大的誤區，那就是度量的方法更多的是通過資料看趨勢，事先為管理決策作出支援，而不是事後分析。比如說專案經理在看到缺陷開啟不斷呈現上升趨勢就應該去尋找問題，進行干預。Scrum主管在看到任務週轉時間要長於原先的預估時間，那就要評估原先的衝刺計劃是否能達成。實施度量正是切合敏捷的擁抱變化的理念，幫助專案的參與者儘早的發現問題，在需要的時刻做出干預。有關於度量更多的資訊，請參看我以往的微課堂記錄。

4、三者融合的最佳實踐

用什麼方法能將三者融合起來呢？我們發現使用Kanban（看板）Baseline(基線)和Pipeline(管道)這三種方法可以將任務管理，版本控制，過程管理緊密的聯絡在一起。

• 看板：以任務的狀態為核心，管理在製品的生產情況。任務是自組織團隊的工作契約。
• 基線：以工件的版本為核心，選取合格的交付物。比如說開發團隊決定哪個程式碼提交版本，或者編譯的構建版本為最終交付的版本。度量指導基線的產生。
• 管道：以生命週期階段為核心，控制基線交付物的投產。比如說一個合格的程式碼基線目前處於編譯態，還是部署態。自動化工具圍繞管道互相整合。

那什麼又是將這三者融合在一起的方法呢？答案就是工作項（WorkItem）。它涵蓋了需求（長篇故事，特性，使用者故事），開發（任務，缺陷）,測試（測試用例，測試計劃）等。

• 工作項是看板展示的最小單元，看板的泳道就是工作項的狀態。
• 基線是通過需求工作項規劃，任務工作項生產，測試工作項驗收的最終產物。
• 工作項是生命週期不同交付物的容器，交付物的最終投產通過管道體現。

四、DevOps生態環境

最近這幾年可以說IT行業發生了一個質的改變。不論從方法論，還是軟體工具以及基礎設施都讓軟體開發這件事與業務結合的越來越緊密。可以說DevOps就是雲平臺開發運營的指導思想。在人員角色方面，推崇全棧工程師，讓開發者更貼近業務。在開發方法方面，而在這個平臺之上從開發到運營流轉的交付物就是以微服務方法開發的應用。在物理形態方面，以容器的方式交付到生產部門運營。對於使用者來講，這種業務的最終交付形態可能就是一系列的API介面，或者直接可用的應用。一切都變得平滑起來。