DevOps轉型中遭遇的陷阱與核心實踐指南
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平臺搭建起來了。根據用戶的需要可以在私有云和公有云的不同選擇不同的版本進行平臺建設。只有將這些核心工件集成起來才能形成有效的可追溯鏈路。
|
源工具 |
目標工具 |
核心工件 |
說明 |
|
ZenHub |
GitHub |
TaskID, CommitID |
通過任務可以看到相關的代碼提交。 |
|
GitHub |
Jenkins |
CommitID, BuildID |
哪些提交被哪些構建包括，一個構建包括哪些實際的需求。 |
|
Jenkins |
Swarm |
BuildID, InstanceID |
一個環境上部署的是哪些新的功能。 |
|
Swarm |
SauceLabs |
InstanceID, TestCaseID |
一個環境上的部署實例經過了哪些測試，以及測試的結果。 |
|
ITOP |
所有工具 |
IT資源信息 |
用CMDB進行核心資源的統一管理 |
|
MatterMost |
所有工具 |
團隊協作 |
|
|
oneAlert |
所有工具 |
各種事件消息 |
實時監控預警 |
這種集成方式給運維帶來的改變可能要多于傳統的研發，因為傳統的運維在方法論，工具，規范程度等方面還遠不及開發，比如說：
- 與很多成熟的開發流程脫節，以及生產環境的相對隔離造成了運維的黑賬本(碎片化的腳本)。
- 環境部署后，使用者和管理者的信息不同步造成了很多僵尸系統。
近些年來，基礎設施既編碼(IaC)以及配置管理數據庫(CMDB)的應用實際上就是為了解決上面問題。既然運維實際采用一系列的腳本來部署和管理系統，那么就應該把這些腳本和開發代碼一樣統一化管理，甚至納入。而CMDB的作用就是將運維的工作成果和企業的其他IT資產統一管理，消除那些僵尸系統。
3、實時的度量驅動
軟件開發過程中充滿了各種各樣不確定的因素，有時一個小情況的出現就會成大程度影響軟件產品的按時交付。對于中高層管理者來講，只能通過重復的人工周報月報來獲取信息。然而不及時，且摻雜人工數據的報告講給決策支持帶來很大的誤導。DevOps就是要將數據鏈路打通，為管理者提供實時，準確的生命周期數據。使管理者在風險到來之前有效的對其管控。
可能在傳統的印象中度量不就是一堆報表嗎?其實這里有個很大的誤區，那就是度量的方法更多的是通過數據看趨勢，事先為管理決策作出支持，而不是事后分析。比如說項目經理在看到缺陷打開不斷呈現上升趨勢就應該去尋找問題，進行干預。Scrum主管在看到任務周轉時間要長于原先的預估時間，那就要評估原先的沖刺計劃是否能達成。實施度量正是切合敏捷的擁抱變化的理念，幫助項目的參與者盡早的發現問題，在需要的時刻做出干預。有關于度量更多的信息，請參看我以往的微課堂記錄。
4、三者融合的最佳實踐
用什么方法能將三者融合起來呢?我們發現使用Kanban(看板)Baseline(基線)和Pipeline(管道)這三種方法可以將任務管理，版本控制，過程管理緊密的聯系在一起。
- 看板：以任務的狀態為核心，管理在制品的生產情況。任務是自組織團隊的工作契約。
- 基線：以工件的版本為核心，選取合格的交付物。比如說開發團隊決定哪個代碼提交版本，或者編譯的構建版本為最終交付的版本。度量指導基線的產生。
- 管道：以生命周期階段為核心，控制基線交付物的投產。比如說一個合格的代碼基線目前處于編譯態，還是部署態。自動化工具圍繞管道互相集成。
那什么又是將這三者融合在一起的方法呢?答案就是工作項(WorkItem)。它涵蓋了需求(長篇故事，特性，用戶故事)，開發(任務，缺陷),測試(測試用例，測試計劃)等。
- 工作項是看板展示的最小單元，看板的泳道就是工作項的狀態。
- 基線是通過需求工作項規劃，任務工作項生產，測試工作項驗收的最終產物。
- 工作項是生命周期不同交付物的容器，交付物的最終投產通過管道體現。
四、DevOps生態環境
最近這幾年可以說IT行業發生了一個質的改變。不論從方法論，還是軟件工具以及基礎設施都讓軟件開發這件事與業務結合的越來越緊密。可以說DevOps就是云平臺開發運營的指導思想。在人員角色方面，推崇全棧工程師，讓開發者更貼近業務。在開發方法方面，而在這個平臺之上從開發到運營流轉的交付物就是以微服務方法開發的應用。在物理形態方面，以容器的方式交付到生產部門運營。對于使用者來講，這種業務的最終交付形態可能就是一系列的API接口，或者直接可用的應用。一切都變得平滑起來。
如需成為EAii架構研究院會員加入微信群參與架構設計與討論直播，享受微課堂PPT搶先下載等權益，請直接回復您的微信號至此公眾號。
關于作者：
胡帥
普元信息高級軟件架構師，計算機軟件與理論碩士。曾供職于IBM中國開發實驗室，參與Rational Team Concert, Rational Insight等產品研發，曾經擔任著名開源BI產品BIRT社區顧問。為工行，招行，建行，美國通用等大型企業提供DevOps以及BI產品咨詢實施服務。在DevOps以及BI方面積累了豐富的研發與實施經驗。
