极速快乐十分是官方

DevOps原則,聽伍道長細細道來


講師簡介

伍斌_Ben,悟道者,ThoughtWorks軟件開發咨詢師。著有《馴服爛代碼:在編程操練中悟道》,譯有《測試驅動數據庫開發》和《優質代碼》。自1993年大學畢業以來,先后做過程序員、測試工程師、項目經理和軟件開發咨詢師。2013年4月創辦全棧開發者的編程操練社區“bjdp.org北京設計模式學習組”

perforce

分享內容介紹

DevOps原則所追求的愿景是什么?

DevOps的實踐包括Scrum和用戶故事的實踐嗎?

還是僅僅指自動化測試和部署?

DevOps與Agile和Lean的關系是什么?

有哪4個維度可以用來組織豐富多彩的DevOps原則?

這些原則有沒有一些所對應的實踐的例子?

讓我們一起在本次分享中尋找上述問題的答案。

分享內容總結

Dev指的是“開發”,Ops指的是“運維”,那么到底什么是DevOps?它的原則是什么?它和敏捷和精益的關系是什么?

要回答這些問題,讓我們先觀察一下DevOps的起源

DevOps的起源可以分為兩條線。

第一條線就是比利時獨立咨詢師Patrick Debois。2007年他在比利時參與一個測試工作時,需要頻繁往返于Dev團隊和Ops團隊。Dev團隊已經實踐了敏捷,而Ops團隊還是傳統運維的工作方式。看到Ops團隊每天忙于救火和疲于奔命的狀態,他在想:能否把敏捷的實踐引入Ops團隊呢?

第二條線是當時雅虎旗下的圖片分享網站Flickr。這家公司的運維部門經理John Allspaw和工程師Paul Hammond,于2009年6月23日,在美國圣荷西舉辦的Velocity 2009大會上,發表了演講 “每天部署10次以上:Flickr公司的Dev與Ops的合作”。

這個演講有一個核心議題:Dev和Ops的目標到底是不是沖突?傳統觀念認為Dev和Ops的目標是有沖突的——Dev的工作是添加新特性,而Ops的工作是保持系統運行的穩定和快速;而Dev在添加新特性時所帶來的代碼變化,會導致系統運行不穩定和變慢,從而引發Dev與Ops的沖突。然而從全局來看,Dev和Ops的目標是一致的,即都是“讓業務所要求的那些變化能隨時上線可用”。

了解了這個演講的議題后, Debois擼起袖子,于2009年10月30至31日,在比利時 城市根特,以社區自發的形式,舉辦了一個名為DevOpsDays的大會。這次大會吸引了不少開發者、系統管理員和軟件工具程序員來參加。 會議結束后,大家繼續在“推特”上聊。 Debois把DevOpsDays中的Days去掉,而創建了#DevOps這個“推特”聊天主題標簽,DevOps誕生了。

Flickr公司的兩位演講者所表達的“Dev和Ops的共同目標是讓業務所要求的那些變化能隨時上線可用”這一觀點,其實就是DevOps的愿景。而要達到這一點,可以使用一個現成的工具:精益。因為源自豐田生產方式的精益的一個愿景,就是“Shortest lead time”,即用最短的時間來完成從客戶下訂單到收到貨物的全過程。這恰好能幫助實現DevOps的上述愿景。《持續交付》的作者之一Jez Humble也體會出精益在DevOps中的重要性,以至于他把DevOps的CAMS框架修訂為CALMS,其中增加的L指的就是Lean(精益) 。

從上面DevOps的起源能夠看出三點:

1)DevOps源自草根社區,最初并沒有什么自頂向下設計出來的理論框架;
2)DevOps背后的原則,就是上面兩條線中所涉及的敏捷和精益的原則;
3)DevOps的愿景是讓業務所要求的那些變化能隨時上線可用。

因為DevOps源自草根,沒有什么框架,所以如何定義DevOps成了DevOps社區里面的一個大難題。一些DevOps從業者,紛紛給出自己的DevOps框架。其中比較有名的框架有上文提到的Damon Edwards所定義并被Jez Humble所修訂的CALMS,和Gene Kim所定義的The Three Ways。

本人試著從“人、產品、流程和工具”4個維度,來把DevOps的一些原則進行梳理。 其中,“高于”表示右邊的實踐雖然不如左邊的好,但還是有價值的。“而非”表示右邊的實踐并不值得推薦。這就是本文標題中“實例化”的由來。

要想讓DevOps這顆樹苗茁壯成長,企業要為其提供一個良好的土壤——即企業文化。而企業文化,是企業領導者所塑造的。 只有領導者身體力行,不僅自己做試驗和持續改進,并給工程師時間來做試驗和持續改進,這樣所創造出良好的土壤,才能讓那些自動化工具和基礎設施在企業內部得到有效利用。

試驗并改進流程 而非 指責人的過失

DevOps對于國內大部分企業都是新事物,需要做試驗來“摸著石頭過河”,做試驗就有失敗的時候,此時就要調整流程,而不是怪罪于人,否則企業沒有人會去繼續嘗試DevOps。

產品思維 高于 項目思維

根據這一個原則可以定義“人”的組織結構——團隊結構,即可以按照產品而不是項目來組建團隊。這種自治的全功能團隊,能令團隊的不同角色目標一致,比起從目標不一致的各種職能團隊(比如Dev團隊、Tester團隊和BA團隊)抽調人員拼湊成臨時的項目團隊,磨合期更短,更加有戰斗力。

產品

質量和安全內建 而非 晚期度量和檢查

通過持續改進流程,“一次就把事情做對”,這樣就能在不進行后期大規模檢查的情況下保證高質量,同時保證質量的成本也趨近于零。

客戶反饋 高于 按期交付

產品是否實現了價值,只有通過客戶的反饋才能知道。很多團隊往往過分關注交付期限,而忽視經常從客戶那里獲得反饋。這樣做的后果,就是雖然按期交付,但是產品卻不是客戶所期望的,造成返工或項目失敗。

基于不可變容器的微服務 高于 單塊應用

產品需要能快速地開發、測試和部署才能有效地交付價值。對于復雜度高的大型產品,如果可以由多個微服務組合而成,每個微服務都能獨立地開發、測試、部署和上線。這比起必須集成各個模塊才能進行手工測試的單塊應用來說,能實現各個微服務之間的并行研發,加快每個微服務的開發下游至上游的反饋環的反饋速度,進而縮短項目進度,讓價值交付得更快。

流程

管理層實踐Improvement Kata和Coaching Kata進行流程持續改進 高于 用結果導向進行管理

傳統按結果導向進行管理的一個弊病,就是團隊成員會把注意力放到結果上,而不是產生這樣結果的原因——即過程改進之上。這樣的后果就是,大家會把精力放到如何讓報表好看,而不是真正地提高團隊成員的持續改進能力來真正達到所期望的結果。企業管理層可以參考《豐田套路》一書來帶頭實踐Improvement Kata和Coaching Kata,讓企業產生持續改進的文化。

全局優化 而非 局部優化

由于大部分按職能組織團隊的企業內部所存在的部門割據的問題,導致大家都在做本職能部門內做局部優化,而沒人做部門間的整體優化。有些部門間的扯皮時間甚至長達數月,嚴重影響了產品的交付。這提醒我們,全局優化來提高企業整體競爭力,才是各個部門賴以生存的保障。

單件流 高于 庫存

單件流指的是,正在制作的產品的各個模塊,能從最初的對其增加價值的加工步驟,直接傳遞到下一個增值加工步驟進行加工,并最終被傳遞到客戶手中,在這個過程中,各個步驟之間沒有發生等待或者排隊的現象。而如果在各個步驟的傳遞過程中發生了等待或排隊,那就等同于建立了庫存。 軟件開發中的庫存就是讓項目延期的最大原因。而企業如果能做到單件流,那么就相當于消滅了庫存,讓價值在不同環節之間流動得最快,進而實現了前文所提到的全局優化。

工具

自動化 高于 手工

按照固定流程所進行的手工工作,比如手工回歸測試和手工部署工作,無趣、緩慢且無法審計。如果能將其代碼化,且用版本控制系統管理起來,并加以自動化,這既能節省以后手工運行的大量時間,又能體驗到開發測試和部署腳本工作的樂趣。

基礎設施及代碼 高于 手工配置

傳統Ops的部署工作有些需要用鼠標在界面上點來點去,效率很低;效率高一些的Ops用了自動化腳本,但很多腳本都沒有進行版本控制。如果能夠將基礎設施的維護工作都通過編寫代碼并加以版本控制來完成,那么讓團隊了解基礎設施的配置,并方便做自動化, 大幅度提升Ops的工作效率。

部署流水線 而非 每日構建

有些團隊每晚做一次代碼構建。這樣做的問題是:團隊程序員們每天代碼的提交會有很多,如果晚上構建發現了錯誤,第二天從這些眾多提交中發現誰導致的錯誤,將是一個很困難的事情。推薦的做法是每一次代碼提交,都能自動觸發部署流水線來檢查該提交是否通過了自動化單元、驗收和性能等測試。一旦發現問題,就能輕松定位是誰在哪個環節出現了什么問題。

總結一下,DevOps的原則來自從業者們的在日常工作中運用Agile、Lean原則的具體實踐。這些原則可以按照“人、產品、流程和工具”4個維度來組織。這些原則和實踐的目的,都是要實現DevOps的愿景——讓業務所要求的那些變化能隨時上線可用。

精彩問答

請問老師,devops的實踐在legacy系統中如何運用呢?有沒有可能呢?

在legacy系統中,也是可以運用DevOps的某些原則的,比如“質量和安全內建 而非 晚期度量和檢查”、“客戶反饋 高于 按期交付”、“全局優化 而非 局部優化”、“單件流 高于 庫存”、“自動化 高于 手工”等等。是有可能的。我聽到一句很給力的話:其實沒有Legacy的系統,而只有Legacy的思維模式。

伍老師能介紹下工作中具體如何落地的嗎,具體案例?

這個問題是不是講DevOps轉型如何落地?如果是的話,那么在工作中具體落地的方法是個很大的話題,而且實施方法因組織的具體情況而異。但我個人認為,轉型能否落地最重要的一點,就是專注在“因”,而不是“果”上。就是“菩薩畏因”的“因”和“眾生畏果”的“果”。“因”其實就是工程師的“行為模式”。要改變“行為模式”,就需要老師。老師可以是組織內有經驗的經理,還可以外請教練。沒有轉型經驗的組織,需要讓有經驗的人帶一下。具體案例可以參考Flickr. :-)

devops原則是針對所有軟件產品,還是主要針對線上產品?

這些原則可以針對所有軟件產品來定制。定制時需要注意:要做試驗,來找到適合自己組織的實踐方式。

老師,這里提到的集成自動化,主要是那個層面的自動化測試呢?測試一般來說會有,單元,接口,到功能,ui。但是感覺到多數項目只會devops集成到api的自動化測試。這個會有一個通用的做法什么的嗎?

這里提到的自動化,可以包括自動化測試和自動化部署,及一切可以用代碼來自動化的手工操作。您提到的各種層面的自動化測試,需要按照測試金字塔來組織:即少量的UI自動化測試、中等數量的Service自動化測試和大量的自動化單元測試。

測試金字塔可以參考老馬的博客:https://martinfowler.com/bliki/TestPyramid.html

基礎設施設置工具推薦哪些,chef,ansible或者salt?

我這里有張圖,體現了一些配置管理工具和DevOps工具誕生的時間順序。

這些工具的對比,大家可以參考:https://www.upguard.com/articles/the-7-configuration-management-tools-you-need-to-know

請教下老師:目前在您實踐DevOps的過程中,組織結構是如何演化的?

即用什么樣的辦法讓組織結構從現有的以部門為單位,轉向為以產品為單位?

最佳實踐是什么?

另外問下,您目前一個產品團隊,里面的成員結構和成員構成大概有哪些,人數如何?

我所看到的企業DevOps轉型,組織的結構是公司高層由上到下來重新組合,來講原先以職能劃分的團隊,調整為以產品為核心的特性團隊。其實我覺得沒有最佳實踐,只有經過了在自己組織中試驗并改進后得到的較好實踐。但總原則是特性團隊包括業務人員、開發人員、測試人員和運維人員,且各個角色的核心人員相對穩定,不會隨著項目變化而解散。

人數可以參考亞馬遜的“兩個披薩”團隊(即團隊外出吃飯,兩個大披薩就能喂飽)的設計:http://blog.jasoncrawford.org/two-pizza-teams

微服務和單件流,在 現實中存在4端,相互交叉版本依賴,這也做到微服務單個發布個集成,和單件流,這種情況怎么來完善和實施devops? 也難做到完全單個情況?

就是我們應用存在4端,劃分微服務后,存在依賴太嚴重了,很慢做到單體價值交付,和單個微服務做ci這樣……能否知道有解決方案之類的?

如果拆開微服務后,發現幾個微服務的依賴太嚴重,那么多半是因為拆分的不合理導致的。微服務拆分原則是每一個微服務都能實現“自治”,微服務的拆分原則可以參考老馬的“微服務”博客:http://www.10tiao.com/html/551/201603/404584177/1.html

就是我們應用存在4端,劃分微服務后,存在依賴太嚴重了,很慢做到單體價值交付,和單個微服務做ci這樣……能否知道有解決方案之類的?


關于perforce軟件

Perforce軟件幫助公司更加協作安全地構建復雜的產品。它的高擴展源代碼管理和協作平臺Perforce Helix,使全球團隊可以在任何類型或者大小的文件上進行合作。它支持集中和分布式的工作流,同時利用先進的行為分析保護知識產權。Perforce被世界上最有創新精神的品牌所信任,包括阿迪達斯、三星、NVIDIA, Intuit, Pixar,Salesforce, EA, Ubisoft和VMware。公司總部在加利福尼亞的Alameda,以及位于英國、加拿大和澳大利亞辦公室,并且他們的合作伙伴遍布全球。

關于龍智

上海龍智作為Perforce在中國地區的唯一合作伴,為中國地區的用戶提供Perforce的咨詢、銷售、技術支持服務。

龍智面向國內外企業提供ALM解決方案及實施等服務,合作產品包括Perforce高效安全版本管理引擎、Atlassian專業的項目跟蹤管理工具、Zephyr實時的產品測試管理工具和Parasoft全球領先的自動化軟件錯誤預防。

聯系我們:400-7755-506

极速快乐十分是官方 山西泳坛夺金开奖结果查询 安徽快3均值 今日短线黑马股票推荐 河南十一选五加奖 十二生肖开码结果查询 秒速时时彩两面技巧 怎么用黑科技赚钱 黑龙江36选7开奖电视 幸运飞艇pk10稳赢公式 3d开机号十期直100期