乾貨|DevOps 之精益思維

乾貨|DevOps 之精益思維

與很多公司聊DevOps的時候,大多數公司都說“已經實現了DevOps”。再往下聊,發現這些企業對“實現了DevOps”的理解是已經使用Jenkins實現了流水線。是的,在大多數人的概念中,DevOps已經和Jenkins之類的流水線工具劃上了等號。

DevOps定義和重心的發展和演變

“DevOps是一組過程、方法與系統的統稱”,但我們也不用拘泥於概念,因為每年DevOps權威組織對DevOps的定義或者對DevOps所關注的重心都在發生變化。

我們來看看DevOps的定義的發展變化:

2008年

還沒有人提出這個DevOps名詞,只是強調需要敏捷架構。

2009年

DevOps第一次被提出來,被定義為開發運維一體化。

2010年

DevOps的概念被明確為“一組過程、方法與系統的統稱。用於促進開發、技術運營和質量保障之間的溝通、協作與整合”。

2011年

DevOps被定義為“一種強調Dev和Ops之間溝通合作的文化、運動或慣例”。通過自動化式的交付與變更流程,使得構建、測試、發佈軟件能夠更加地快捷、頻繁和可靠。

2016年

DevOps被定義為旨在統一開發和運維的一種軟件工程文化和實踐。目標是:

• 與業務目標保持一致

• 更短的開發週期

• 更高的部署頻率

• 更可靠的軟件發佈

2017年

興起的DevOps運動,強調了DevOps的重心——“將軟件建設的所有環節進行自動化&全面監控”。

精益是DevOps發展的必然途徑

開發過程為什麼會無法衡量?

實現“與業務目標保持一致、更短的開發週期、更高的部署頻率、更可靠的軟件發佈”,這一持續交付的目標肯定是無比正確的。但是我們如何達到朝著這個目標靠近呢?

來看看這些問題:

從需求被接收到交付上線,通常需要多少時間?

這個時間是否是合理的、能不能被繼續壓縮、壓縮會不會帶來質量的問題?

開發、測試、發佈整個流程哪個環節是瓶頸?

開發人員和測試人員的合理配比應該是多少?

我們的測試覆蓋率是多少?

我們的發佈成功率算高還是算低?

我們要從哪裡開始改進/如何去改進?

……

貌似這些問題大多難回答,你會說基本上都比較難以衡量啊。在沒有數據支撐決策的時候,我們更多的是憑直覺來進行衡量,根據過去的認知、現有的經驗來進行管理和優化。

世界上沒有任何事物是不能被衡量的。

所有看似無法量化的難題,

只要能讓你知道得比以前多, 就是一項成功的衡量。

——道格拉斯‧哈伯德

之所以無法衡量,主要的原因是大部分企業所實現的流水線只是一個流程執行的黑匣子,DevOps整個業務鏈條的過程無法被覆蓋,過程數據沒有被記錄、收集和分析,我們缺乏數據的支撐。

需要DevOps的表面原因

將軟件建設的所有環節自動化,以達到持續、正確、快速,這也是為了DevOps的根本目標。通過儘量減少人的參與,讓計算機按照預定義的檢查和處理邏輯執行,以工業化的方式減少了人工操作導致的響應等待時間,同時也減少因為人為疏忽導致的錯誤。

將軟件建設的所有環節進行全面監控,可以發現自動化各個流程節點中產生的告警和異常,需要人為進行確認是否可以被忽略,或者需要干預處理。例如:代碼掃描發現了開發人員拷貝代碼的問題,單元測試發現有測試不通過的問題等等。

上面這兩點,我認為只是 “將軟件建設的所有環節進行自動化&全面監控”的表面原因。

精益是DevOps的靈魂

“將軟件建設的所有環節進行自動化&全面監控”有更重要的任務,那就是通過自動化和全面監控,全面自動記錄或收集軟件建設過程的數據,這些數據接下來可以發揮巨大的價值——發現持持續交付的過程中,哪些環節存在浪費或者風險,然後進行持續優化。

這就是我們所謂的精益。

通過統一的DevOps平臺,對軟件建設的過程數據進行收集和監控,然後以直觀的精益看板的形式展現,我們可以更容易發現問題、分析問題、解決問題。只有精益求精,整個團隊共同協作、持續改進,才能讓我們的軟件持續交付更快、更穩、更強,達到“與業務目標保持一致、更短的開發週期、更高的部署頻率、更可靠的軟件發佈”。

這就是我所理解DevOps “精益”思維。

在我規劃DevOps產品的時候,我認為精益是DevOps的靈魂。而大多數的企業和DevOps產品並沒有重視“精益”,我以為我是孤獨者。

直到拜讀了一位60多歲的臺灣資深敏捷開發諮詢師李智樺寫的書,發現我的思路還是有同道中人的。而且李老不只是同道,甚至是遠遠的走在了前面,能提供方法論的導師。

例如,李老畫的這一個看板就能體現出來的非常多信息量:

乾貨|DevOps 之精益思維

嘉維藍鯨的DevOps理念

一些企業把Jenkins的應用叫做DevOps。

不可否認,用Jenkins這個流水線工具,可以實現把集成或部署的任務組合為一個流程進行執行,加快了交付的效率。

一些廠商把自己的容器平臺叫做DevOps。

不可否認,用容器交付應用,可以讓部署和水平擴展的過程變得更簡單、更快,也加快了交付的效率。

如果以夠用就好的心態來看待,那麼恭喜你達到了DevOps的初級階段。

但是,Jenkins 不是DevOps平臺,只能幫你把各個任務連接到一起執行;容器就更不是DevOps平臺了,它只是幫助實現應用更容易的部署和擴展的技術。至於協作、精益、持續改進,都不是他們所考慮的問題。

嘉為科技與騰訊藍鯨一起,在藍鯨平臺之上開發了DevOps社區版並集成於藍鯨平臺社區版,作為CI/CD組件;然後在DevOps社區版的基礎上,又繼續研發更強大的嘉維藍鯨DevOps企業版。

嘉維藍鯨DevOps平臺在企業的軟件或者功能還是需求的時候就開始記錄和跟蹤,直到最後的交付和運維,持續優化,提供了全業務鏈的業務及改進支撐。

嘉維藍鯨DevOps產品體系架構

乾貨|DevOps 之精益思維

最後,再與大家分享一下我們做DevOps產品的幾個重大的理念:

01

融合

提供覆蓋軟件建設全業務鏈的DevOps平臺,在統一的平臺上,融合對協作、開發、測試、運維的工作管理支持,同時收集和記錄DevOps業務鏈的過程數據。而不是團隊各個角色分散用自己的工具,導致無法監控,也無法獲得用於改進的數據。

02

集成

集成騰訊藍鯨平臺的強大自動化運維組件,並重新按照項目進行組織,提供的不再是底層的工具,而是DevOps業務平臺的交付和運維功能。每一個集成進來的藍鯨組件,例如:CMDB、監控平臺、故障自愈、標準運維、管控平臺等都是業界領先的,為用戶提供強大的管理和擴展能力。

03

精益

通過收集和監控的各個組件、各個過程的執行數據,提供直觀的精益看板進行展示,作為企業持續改進的依據,能幫助企業發現目前項目或研發團隊存在的問題,持續改進DevOps團隊生產和交付,最大化體現DevOps的價值。

DevOps Master培訓

行業最火熱的DevOps認證課程體系來了!

課程名稱

DevOps Master認證培訓

課程簡介

《鳳凰項目》沙盤

DevOps的應用

開發和部署

生命週期結束

DevOps基礎

規劃、需求和設計

運維和彈性伸縮

DevOps補充

授課講師

乾貨|DevOps 之精益思維

殷越

資深企業架構師EA,企業軟件開發顧問,學領未來軟件開發專家組領軍人。

近二十年企業IT信息系統開發設計經驗,十餘年企業軟件項目諮詢、培訓經驗,曾就職於大型通信業、製造業、安利中國等知名企業,歷任開發經理、軟件架構師、項目總監等職。

曾獲微軟企業信息主管會議廳指定金話筒講師,微軟中國第三屆十大金牌講師,EXIN認證首批DevOps Master培訓師。

曾為中國移動、中國海關、廣東國稅、南方航空、工商銀行、中興通訊等眾多知名企業提供了培訓、諮詢和項目輔導服務。

乾貨|DevOps 之精益思維

高磊

資深企業IT運維及安全管理專家,企業IT項目管理諮詢師;學領未來IT管理及基礎架構專家組領軍人。

近二十年企業IT運維與項目管理諮詢、輔導和培訓的豐富經驗,曾就職於大型製造業企業、知名證券公司IT管理部,歷任IT架構師、數據中心總監等職。

曾獲微軟中國第三屆十大金牌講師、PMI優秀項目管理師、EXIN認證高級ITSM培訓師。

曾為華為、華潤、南方電網、安利、中國移動、美的、匯豐等百餘知名企業提供了培訓、諮詢和項目輔導服務。

課程收穫

對企業:提升產品、服務交付的質量與效率;促進技術團隊融合,打造更具戰鬥力的促進技術團隊;通過響應變化提升客戶價值;減少瓶頸。

對個人:證明你的知識與技能;持續的學習與改進;成為DevOps的推動者。

開課時間

6月27日——29日

開課地點

嘉為教育(深圳)

聯繫電話

0755-83668518

交通指引

公交:上海賓館站下

地鐵:一號線華強路站C出口

關於我們

學領未來——嘉為教育傾力打造的IT職業發展學習平臺,依託於嘉為教育專業企業人才培養的經驗,為眾多客戶提供包括職業發展與成長顧問、能力評測與提升建議、學習資源與學習管理、人才評價與認證服務的O2O立體化學習成長體系。

關注我們

乾貨|DevOps 之精益思維


分享到:


相關文章: