轉載本文需註明出處：EAWorld，違者必究。
2010年，我曾在IBM供職，開始參與DevOps相關的產品研發與實施工做。今天看來，我也許是國內較早的DevOps踐行者。這兩年DevOps在國內開花結果的時候，我見到了不少錯誤轉型的亂象。本文中，將爲你們分享本身對DevOps行業發展的觀察，並向介紹DevOps轉型的路途中都有哪些陷阱。但願經過本文，你們能更夠撥雲見日，真正的使DevOps成爲企業生產力增加的助推器。程序員
本文目錄：數據庫
1、軟件工程的發展編程
2、DevOps轉型陷阱設計模式
3、DevOps核心實踐服務器
4、DevOps生態環境微信
首先說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這種小團隊，持續迭代持續交付的理念簡直是天做之合。
團隊組織結構也在這些年發生了微妙的變化。無論是全棧工程師仍是流行的NoOps都在說明專業的界限被打破，開發團隊由技術向業務轉型。
對於不少測試人員來講，這是一個憂傷的話題。不少IT公司的功能測試部門FVT已經被開發人員所取代。取代的基礎是用各類自動化軟件，作到更好的單元測試，冒煙測試。而且在迭代的後期利用開發人員的閒暇時間來完成手動測試。傳統的測試人員須要培養自身承擔自動化測試用例，性能測試用例，系統測試等複雜測試工做的能力。
當DevOps相關的平臺統一後，開發驗證階段的產品部署架構，部署模式能夠無縫切換到生產態。對於實際的生產態部署來講也許就是一個環境的切換，爲了確保萬無一失，在一個準生產系統之上演練上線工做。所以傳統的開發和運維人員之間的界限會愈來愈模糊，以及雲平臺對於服務FailOver策略的處理愈來愈成熟。
從此的運維團隊可能很是的輕量級。軟件工程的大方向是被經濟利益所驅動的，因此DevOps運用以後不少開發人員也許會「被迫」去作更多測試，運維的工做，是否是有點無奈？
直至今天，瀑布開發模式仍舊是許多組織採納的方式。不用質疑，瀑布方式在中國有必定的文化基礎。可是漸漸的咱們意識到嚴格的瀑布模式每每會形成必定的資源浪費。好比在相同的人員和相同的時間長度下，傳統過程交付可能花費大量的時間去完成是一份完整的需求文檔，可是留給軟件開發的時間少之又少，再加上需求的變化。回頭來看需求文檔每每已通過時。
相似RUP（Rational Unified Process）的迭代開發模式就是儘量的早的得到用戶的意見，控制風險。它實際上是介於敏捷和瀑布之間的一種模型，不如敏捷靈活可是控制性比敏捷更強。RUP的迭代雖然容許需求和開發並行，可是他仍然強調大部分需求內容都應該在主要開發工做以前完成，而不是敏捷中代碼就是設計，需求和開發互爲彼此，不斷完善的方式。顯而易見敏捷需求的時間大大減小了，因此後期調整需求的代價較之瀑布和迭代來說也更低。
XP極限編程甚至不太推崇你們作過分的設計，相似於一個CRUD的功能，程序員有時會不自覺的追求更高的拓展性，搞出了一個框架來。這讓我想起來一個頗有意思的問題。那就是項目與產品的細微區別。作項目大可能是爲了追求短時間利益，知足客戶功能需求爲先，良好的拓展性並非項目的核心需求。沒必要要的設計會影響接納需求變化的能力，這和擁抱改變的想法有些不一致。相似在ThoughtWorks這種作敏捷諮詢的公司，客戶會另外付錢購買代碼重構的effort。而產品研發的需求相對固定，而且一個產品要有良好的發展，必須培養一個良好的生態系統，擁抱將來不一樣的拓展需求。長期來看框架和平臺化反而符合產品的利益。因此敏捷中倡導有些原則有時要辯證的看。
敏捷方法在國內還沒焐熱，大規模敏捷的軟件過程已經誕生。然而在不少敏捷大師的眼中，SAFe和Less只不過是穿了馬甲的RUP。敏捷不能大規模開展嗎？其實不是不能開展，而是如何開展的問題。你們知道敏捷推崇的是小團隊文化，相似亞馬遜倡導的Two-pizza團隊，建議團隊規模維持在7人左右。然而動輒幾千人的跨國研發組織，如何開展敏捷的確是一個問題，這就是大規模敏捷存在的意義。
DevOps簡單的來翻譯就是運維開發一體化。可是究竟如何來一體化，怎麼作才能一體化？可能不一樣人對DevOps有着不一樣的理解，這取決於你們在哪一個場合被什麼人安利的。認識的盲點也就形成了實踐的誤區。
好比說自動化，基礎設施即編碼，配置管理數據庫的應用，看板方法在運維中的應用等等，能夠說這一切都是有關DevOps的實踐，而又不是DevOps的所有。向DevOps轉型的路上有不少坑，咱們先從文化轉型談起。
不少人好奇敏捷和DevOps是什麼關係。敏捷是一種軟件開發過程，最初只是在軟件開發中推廣，不少人提出由開發敏捷轉型到運維敏捷，從而到業務敏捷。這個提議毋庸置疑，無論從文化，流程以及工具層面都是很好的延伸。能夠說敏捷方法，敏捷工具爲DevOps理念提供了很好的理論指導和工具支持。近些年來不少公司逐漸開始進行敏捷實踐，好比說項目經理變成了Scrum主管，用戶故事替代了之前的需求，開發計劃變成了更短的衝刺計劃。之前每週一次的組會變成了天天的站會。一開始你們都精神滿滿，長此以往以爲天天的站會太麻煩。而Scrum主管仍是之前那個逼着你們幹活兒的項目經理。衝刺使得開發週期變短了，能作的功能也變少了。頻繁上線給運維人員帶來更大的壓力，生產環境的Bug彷佛比之前還要多。
「若是不瞭解團隊自治，責任共擔，面向交付，那就不瞭解DevOps文化。」
不管是以前的敏捷，仍是如今的DevOps，不少人對於CASE工具都有一個誤區，以爲用了這個工具，就具備相應的軟技能。可是用了一陣子以後才發現徹底不是這回事兒。爲何會出現這種假象呢？
咱們知道工具僅僅是現實工做中的一部分，若是僅僅是部署了DevOps工具，然而人員和整個工做流程並未改變會出現什麼？極可能出現的狀況下是，你們用共同的工具進行工做，固然也取得了比以前好一點的效果，可是工具壁壘並無消除。
「若是CASE工具只是孤島，那就很難幫助企業培養好的DevOps實踐。」
其實風險自己並不可怕，可怕的是拒絕風險，或者聽任風險。你們可能已經看過不少DevOps宣傳，以爲實行DevOps以後能夠作到萬無一失，從開發到交付是分分鐘搞定的事情。其實這裏有個陷阱。那就是工具能夠幫助生產到交付快速進行，可是從另外一個角度講，若是一旦出現問題，錯誤也可能會很快傳遞到生產環境中。因此如何快速捕捉問題，解決問題，而不是讓問題傳遞，這纔是DevOps要處理的問題。另外儘早的在持續交付的初期發現問題，好比說有價值的缺陷，而後把它做爲單元測試的目標去防範，這對於團隊來講是一個不斷成長的過程。
「精益的側面是控制風險，因此要當心風險和DevOps流程一塊兒傳遞。」
剛纔說了不少DevOps轉型中的陷阱，也就是說一不當心就會栽到坑裏，以爲DevOps就是那樣了，作着挺彆扭，更沒帶來什麼好處。要知道DevOps其實是一種面向軟件交付的理念。文化轉型真的挺難，到底該怎麼作呢？咱們從三個維度講述DevOps的核心實踐。
這點對於不少公司，特別是目前國內的諸多公司來說也許很難作到。組織的自治意味着控制力的減弱。控制力的減弱加上人類天生的惰性將致使項目的失敗。這多是團隊轉型中存在的共同問題。實際上自治並非說缺少管理，而是說對目標作出正確的指望，對結果作出合理評價。中間的過程經過一系列的檢查點作出指導和糾正。其他的工做交給團隊去協調完成。
首先敏捷實踐中將用戶故事，任務等明確責任人，這是很是好的作法。明確了責任，你們才能向目標邁進。而另外一個責任共擔的好辦法是讓每一個人參與團隊計劃的制定，你們幫助任務的負責人共同估算出故事點。這樣不只會培養團隊成員的責任感，而且最終估算的結果會比項目經理本身作出的決策更加準確。在項目執行的時候，看板等工具的運用使團隊中每一個參與者的工做都具備相同的可見性。以看板中待辦項以及任務狀態肯定天天站會的內容。而不是架構師彙報技術難點，項目經理彙報開發狀態，大多數人被忽略的狀況。
不超過10人的小團隊被不少企業證實是一個良好的實踐。可讓對的人去作擅長的事，若是團隊過大不少人沒法承擔合適本身的角色也是一種浪費。另外隨着持續交付的演進，產品總有新的需求，也有舊的問題。如何合理分配人員從而作到一石二鳥？一些組織開始將團隊分爲若干個特性團隊和維護團隊。這樣能帶來如下好處：
每一個特性團隊都有一個架構師，同時也是Scrum主管。因爲人數小因此很容易作到工做進度與工做量的管理。
特性團隊和維護團隊，互相輪崗。在維護團隊中，成員能夠接觸客戶，新成員能夠經過修復Bug熟悉產品，對產品足夠成熟後再輪崗到特性團隊。
不一樣的小團隊甚至能夠不用在一個地方。
從DevOps的角度，一個大的產品團隊就能夠完成項目開發到上線的整個交付工做。
用一句以前流行的話來講，那就是有了這麼多高大上的工具以後，仍是作很差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資產統一管理，消除那些殭屍系統。
軟件開發過程當中充滿了各類各樣不肯定的因素，有時一個小狀況的出現就會成大程度影響軟件產品的按時交付。對於中高層管理者來說，只能經過重複的人工週報月報來獲取信息。然而不及時，且摻雜人工數據的報告講給決策支持帶來很大的誤導。DevOps就是要將數據鏈路打通，爲管理者提供實時，準確的生命週期數據。使管理者在風險到來以前有效的對其管控。
可能在傳統的印象中度量不就是一堆報表嗎？其實這裏有個很大的誤區，那就是度量的方法更多的是經過數據看趨勢，事先爲管理決策做出支持，而不是過後分析。好比說項目經理在看到缺陷打開不斷呈現上升趨勢就應該去尋找問題，進行干預。Scrum主管在看到任務週轉時間要長於原先的預估時間，那就要評估原先的衝刺計劃是否能達成。實施度量正是切合敏捷的擁抱變化的理念，幫助項目的參與者儘早的發現問題，在須要的時刻作出干預。有關於度量更多的信息，請參看我以往的微課堂記錄。
用什麼方法能將三者融合起來呢？咱們發現使用Kanban（看板）Baseline(基線)和Pipeline(管道)這三種方法能夠將任務管理，版本控制，過程管理緊密的聯繫在一塊兒。
看板：以任務的狀態爲核心，管理在製品的生產狀況。任務是自組織團隊的工做契約。
基線：以工件的版本爲核心，選取合格的交付物。好比說開發團隊決定哪一個代碼提交版本，或者編譯的構建版本爲最終交付的版本。度量指導基線的產生。
管道：以生命週期階段爲核心，控制基線交付物的投產。好比說一個合格的代碼基線目前處於編譯態，仍是部署態。自動化工具圍繞管道互相集成。
那什麼又是將這三者融合在一塊兒的方法呢？答案就是工做項（WorkItem）。它涵蓋了需求（長篇故事，特性，用戶故事），開發（任務，缺陷）,測試（測試用例，測試計劃）等。
工做項是看板展現的最小單元，看板的泳道就是工做項的狀態。
基線是經過需求工做項規劃，任務工做項生產，測試工做項驗收的最終產物。
工做項是生命週期不一樣交付物的容器，交付物的最終投產經過管道體現。
最近這幾年能夠說IT行業發生了一個質的改變。不論從方法論，仍是軟件工具以及基礎設施都讓軟件開發這件事與業務結合的愈來愈緊密。能夠說DevOps就是雲平臺開發運營的指導思想。在人員角色方面，推崇全棧工程師，讓開發者更貼近業務。在開發方法方面，而在這個平臺之上從開發到運營流轉的交付物就是以微服務方法開發的應用。在物理形態方面，以容器的方式交付到生產部門運營。對於使用者來說，這種業務的最終交付形態可能就是一系列的API接口，或者直接可用的應用。一切都變得平滑起來。
如需成爲EAii架構研究院會員加入微信羣參與架構設計與討論直播，享受微課堂PPT搶先下載等權益，請直接回復您的微信號至此公衆號。
關於做者：
胡帥
普元信息高級軟件架構師，計算機軟件與理論碩士。曾供職於IBM中國開發實驗室，參與Rational Team Concert, Rational Insight等產品研發，曾經擔任著名開源BI產品BIRT社區顧問。爲工行，招行，建行，美國通用等大型企業提供DevOps以及BI產品諮詢實施服務。在DevOps以及BI方面積累了豐富的研發與實施經驗。
關於EAWorld
致力於軟件架構創新與實踐，加速企業數字化轉型，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
微信號：eaworld，長按二維碼關注
本文分享自微信公衆號 - EAWorld（eaworld）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。