企業(yè)DevOps變革的剖析與實(shí)踐

1、技術(shù)創(chuàng)新 變革未來(lái)企業(yè)DevOps 變革的剖析與實(shí)踐目錄DevOps 開(kāi)發(fā)法剖析1以價(jià)值流的角度看 DevOps 的實(shí)戰(zhàn)2符合精益原則的 DevOps 真實(shí)世界開(kāi)發(fā)模式3問(wèn)答與回答4 The Three Ways ModelDevOps 目標(biāo)(Goal)我們?cè)噲D建立的東西DevOps 開(kāi)發(fā)法剖析CAMS Model實(shí)行DevOps的方式、做事的方式需要學(xué)習(xí)并反復(fù)練習(xí)的東西DevOps從業(yè)者的價(jià)值參考模型支持 DevOps 的原則- By Gene Kim描述DevOps運(yùn)動(dòng)核心價(jià)值的字母縮略- By John Willis 和 Damon Edwards DevOps是一個(gè)文化和業(yè)務(wù)問(wèn)題The

2、 Three Ways Model指向DevOps 目標(biāo)我們?cè)噲D建立的東西DevOps 開(kāi)發(fā)法剖析第一步、系統(tǒng)思維 第二步、回饋第三部、文化、持續(xù)實(shí)驗(yàn)與學(xué)習(xí) 系統(tǒng)思維第三步三步工作法 讓定義完成存在于每一個(gè)價(jià)值流的節(jié)點(diǎn)，成為一種回饋的機(jī)制在 Safe to fail 機(jī)制下，在看得見(jiàn)的實(shí)驗(yàn)中安全的失敗學(xué)得知識(shí)。價(jià)值流中的定義完成實(shí)驗(yàn)學(xué)習(xí)的 Safe to fail流程與度量第一步速度(度量)度量必須與流程結(jié)合，成為流程改善的指針才不至于變成浪費(fèi)。第二步在步驟中學(xué)習(xí)在行動(dòng)中學(xué)習(xí)與改善DevOps 開(kāi)發(fā)法剖析人 - 多功能團(tuán)隊(duì)基礎(chǔ)設(shè)施即代碼 任何事都可度量協(xié)作及回饋 CAMS Model實(shí)行Dev

3、Ops的方式需要學(xué)習(xí)并反復(fù)練習(xí)的東西文化 自動(dòng)化 度量 分享 CLAMSCulture、 Lean、 Automation、Measurement、Sharing.LeanC. L . A .M .S .運(yùn)用精益原則更頻繁地交付價(jià)值；在價(jià)值鏈中盡量 除去手工步驟分享成功和失敗 的經(jīng)驗(yàn)來(lái)相互學(xué)習(xí)度量并使用數(shù)據(jù) 來(lái)優(yōu)化交付周期By Patrick Debois文化人精益務(wù)實(shí)自動(dòng)化流程測(cè)量依據(jù)分享協(xié)作各個(gè)角色實(shí)現(xiàn)有 效協(xié)作和溝通；(難以複製的) CAMS + Lean = CLAMSIdeaValue需求開(kāi)發(fā)運(yùn)維AgileKanbanLean分享 Sharing度量 MeasurementLEAN

4、精益/文化 Culture (自我負(fù)責(zé)、技術(shù)債)Lead Time自動(dòng)化 Automation開(kāi)發(fā) 測(cè)試分享:不責(zé)備 追蹤 / 監(jiān)控 跨功能團(tuán)隊(duì)敏捷從來(lái)就不是採(cǎi)用單一工作法的問(wèn)題精實(shí)七大原則環(huán)繞看板方法崁入完 整性看板關(guān)注輻射信息關(guān)注精益原則消除浪費(fèi)站 在 看 板 前 要 做 什 麼?輻射信息 授權(quán)團(tuán)隊(duì)精實(shí)七大原則環(huán)繞看板方法崁入完 整性盡量延 遲決策消除浪費(fèi)著眼全體增強(qiáng)學(xué)習(xí)盡快交付看板關(guān)注輻射信息關(guān)注精益原則消除浪費(fèi)輻射信息站 在 看 板 前 要寫 下 來(lái)，貼 上 去! 0.7規(guī)范AL(1)1. Ask questionOKR 目標(biāo) 和 關(guān)鍵成果(2) Objectives and Key

5、Results設(shè)定目標(biāo)。運(yùn)用關(guān)鍵成果驗(yàn)證目標(biāo)是否達(dá)成。硝煙中的Scrum和XP克李柏格. Henrik KnibergAL: Action Learning敏捷從來(lái)就不是採(cǎi)用單一工作法的問(wèn)題 趨勢(shì)是朝度量前進(jìn)度 量說(shuō) 明Solution問(wèn) 題系 統(tǒng) 分 析、指 標(biāo)取 得 數(shù) 據(jù)開(kāi)發(fā)部門經(jīng)常會(huì)有的疑惑?問(wèn)題: 持續(xù)開(kāi)發(fā)讓客戶滿意的功能，能增加多少利潤(rùn)?企業(yè)效能 = 實(shí)際工時(shí)Lead time企業(yè)利潤(rùn) = 銷售量 X 單價(jià) - 成本持續(xù)開(kāi)發(fā)令客戶滿意的功能，能增加多少利潤(rùn)?度 量說(shuō) 明Solution問(wèn) 題系 統(tǒng) 分 析、指 標(biāo)取 得 數(shù) 據(jù)問(wèn)題: 企業(yè)的利潤(rùn)跟開(kāi)發(fā)團(tuán)隊(duì)的效能，有什么關(guān)系?指 標(biāo)問(wèn)

6、題:企業(yè)的利潤(rùn)跟開(kāi)發(fā)團(tuán)隊(duì)的效能，有什么關(guān)系?問(wèn) 題系 統(tǒng) 分 析、指 標(biāo)取 得 數(shù) 據(jù)說(shuō) 明問(wèn)題:企業(yè)的利潤(rùn)跟開(kāi)發(fā)團(tuán)隊(duì)的效能，有什么關(guān)系?問(wèn) 題系 統(tǒng) 分 析、指 標(biāo)取 得 數(shù) 據(jù)說(shuō) 明問(wèn)題:企業(yè)的利潤(rùn)跟開(kāi)發(fā)團(tuán)隊(duì)的效能，有什么關(guān)系?問(wèn) 題系 統(tǒng) 分 析、指 標(biāo)取 得 數(shù) 據(jù)說(shuō) 明問(wèn)題:企業(yè)的利潤(rùn)跟開(kāi)發(fā)團(tuán)隊(duì)的效能，有什么關(guān)系?問(wèn) 題系 統(tǒng) 分 析、指 標(biāo)取 得 數(shù) 據(jù)說(shuō) 明如何衡量萬(wàn)事萬(wàn)物? 確定范圍 Identify Scope定義程序 Define Procedures確定范圍和定義程序活動(dòng)摘要收集資料 Collect Data分析資料 Analyze DataSummary of Iden

7、tify Scope and Define Procedures Activities實(shí)施過(guò)程 Implementing the Process- 卡內(nèi)基梅隆大學(xué)-建立軟件測(cè)量過(guò)程確定 問(wèn)題 范圍設(shè)定 指標(biāo)、公式進(jìn)行 系統(tǒng)分析進(jìn)行數(shù)據(jù)擷取資料分析、說(shuō)明 OKR (Object & Key Result) 目標(biāo)關(guān)鍵結(jié)果如何量化 Sprint 的目標(biāo)達(dá)標(biāo)率?- 傳奇 CEO 安迪.格魯夫，1999 OKR (Object & Key Result) 目標(biāo)關(guān)鍵結(jié)果如何量化 Sprint 的目標(biāo)達(dá)標(biāo)率?【 0.76 】0.70.61.0設(shè)定Sprint 要達(dá)成目標(biāo)制定目標(biāo)的 Key Results檢視

8、團(tuán)隊(duì) KeyOKRtimeline運(yùn)用 OKR 驅(qū)動(dòng) Sprint 沖刺Sprint backlogSprint target了解目標(biāo)解構(gòu)目標(biāo)結(jié)合目標(biāo)趨近目標(biāo)檢核/達(dá)成目標(biāo)Sprintprocess檢視個(gè)人 Key Result 達(dá)成度Result 達(dá)成度制定個(gè)人目標(biāo)Key Results0.70.3XXXXXXXXX1.0目錄DevOps 開(kāi)發(fā)法剖析1以價(jià)值流的角度看 DevOps 的實(shí)戰(zhàn)2符合精益原則的 DevOps 真實(shí)世界開(kāi)發(fā)模式3問(wèn)答與回答4 以價(jià)值流的角度看 DevOps 的實(shí)戰(zhàn)DevOps 價(jià)值流 Kanban Driven DevelopmentBusinessCustomer

9、輸 出 入DevOps 看板驅(qū)動(dòng)開(kāi)發(fā)PoolDesignVerifyRefine mentUser Story用戶故事持續(xù)維運(yùn)發(fā)布布署運(yùn)維監(jiān)控完成創(chuàng)意看 板度 量團(tuán) 隊(duì)指 標(biāo)Mid StreamReady(分類)(中斷)II. 解決方案模式I. 需求與問(wèn)題模式功能交付分析實(shí)作測(cè)試完成商業(yè)工程開(kāi)發(fā)看板運(yùn)維看板需求看板輸 出 入看板驅(qū)動(dòng)開(kāi)發(fā)將度量融入流程PoolDesignVerifyRefine mentUser Story分析實(shí)作測(cè)試完成企業(yè)戰(zhàn)力的效能度量用戶故事持續(xù)維運(yùn)發(fā)布布署運(yùn)維監(jiān)控完成創(chuàng)意需求的業(yè)務(wù)價(jià)值度量研發(fā)的效能度量維運(yùn)的效能度量業(yè)務(wù)+產(chǎn)品團(tuán)隊(duì)多功能團(tuán)隊(duì)看 板度 量團(tuán) 隊(duì)指 標(biāo)需求差

10、異性需求優(yōu)先序應(yīng)用程序的性能平均恢復(fù)時(shí)間(MT應(yīng)用程序的使用和流量錯(cuò)誤率可用性通過(guò)自動(dòng)化測(cè)試通過(guò)率交付時(shí)間部署時(shí)間部署頻率部署規(guī)模失敗的部署平均檢測(cè)時(shí)間(MTTO)客戶工單和回饋Mid StreamReady(分類)(中斷)目標(biāo): 速度、質(zhì)量、性能返工指標(biāo)%C/A解決方案模式需求與問(wèn)題模式功能交付輸 出 入看板驅(qū)動(dòng)開(kāi)發(fā)將度量融入流程、指針透明化PoolDesignVerifyRefine mentUser Story分析實(shí)作測(cè)試完成研發(fā)的Lead Time維運(yùn)的Lead Time需求的Lead Time持續(xù)維運(yùn)發(fā)布布署運(yùn)維監(jiān)控完成創(chuàng)意看 板度 量團(tuán) 隊(duì)指 標(biāo)平均恢復(fù)時(shí)間(MTTR)變更失敗率交

11、付時(shí)間部署頻率Mid StreamReady(分類)(中斷)用戶故事功能交付+=真實(shí)工時(shí)真實(shí)工時(shí)真實(shí)工時(shí)Total working Time Total Lead Time跟蹤從失敗中恢復(fù)需要多長(zhǎng)時(shí)間。=平均交付的失敗率(MTTF)。=成功的交付次數(shù)。 盡可能多部署更小的部署，減少部署的規(guī)模使測(cè)試和發(fā)布變得更加容易。目標(biāo)是快速發(fā)布程序碼(利特爾法則)。平均檢測(cè)時(shí)間(MTTD)平均恢復(fù)時(shí)間(MTTR)變更失敗率應(yīng)用程序的性能 通過(guò)自動(dòng)化測(cè)試通過(guò)率交付時(shí)間部署頻率應(yīng)用程序的使用和流量錯(cuò)誤率 部署時(shí)間部署規(guī)模可用性 需求差異性客戶工單和回饋 需求優(yōu)先序目的是擁有健壯的應(yīng)用程序監(jiān)控和良好的覆蓋將有助于

12、快速發(fā)現(xiàn)問(wèn)題。跟蹤從失敗中恢復(fù)需要多長(zhǎng)時(shí)間。故障恢復(fù)時(shí)長(zhǎng) Time to restore service可以看作是對(duì)失敗的跟蹤平均時(shí)間(MTTF)。部署前后均應(yīng)該運(yùn)用工具來(lái)查找性能問(wèn)題、隱藏的錯(cuò)誤和其他問(wèn)題。 了解代碼更改導(dǎo)致測(cè)試中斷的頻率的有用方法。目標(biāo)是快速發(fā)布程序碼。( 變更前置期 Lead time for changes )目標(biāo)是盡可能多地、部署更小的部署，減少部署的規(guī)模使測(cè)試和發(fā)布變得更加容易。查看訪問(wèn)你的系統(tǒng)的事務(wù)或用戶數(shù)量是否正常的數(shù)字依據(jù)。 是持續(xù)的性能和與時(shí)間相關(guān)的質(zhì)量問(wèn)題指標(biāo)。跟蹤實(shí)際部署需要多長(zhǎng)時(shí)間。跟蹤有多少功能、特性請(qǐng)求和錯(cuò)誤修復(fù)正在被部署?？捎眯浴^(qū)分為內(nèi)部:功能

13、被其它程序呼叫到的次數(shù)及外部:用戶用到的次數(shù)。 需求差異性；運(yùn)用需求對(duì)正矩陣來(lái)分析需求的種類。應(yīng)用程序問(wèn)題的最好和最差的指示器是客戶工單(遇到的BUG)和回饋(用戶的意見(jiàn))。運(yùn)用KANO模型分析需求的優(yōu)先序。說(shuō)明度量指標(biāo)Lead timeDeployment frequencyChange fail rate返工指標(biāo) %C/A = 精確度指標(biāo)完成時(shí)間和精確的總花費(fèi)時(shí)間的百分比(反應(yīng)每個(gè)步驟的輸出的質(zhì)量)。度量企業(yè) DevOps 轉(zhuǎn)型是否成功關(guān)鍵指標(biāo)可以確保企業(yè)能夠適應(yīng)市場(chǎng)的變 化，并且快速做出回應(yīng)?？梢源_保企業(yè)交付讓客戶滿意的 產(chǎn)品。部署頻率Deployment frequency變更交付周期

14、Lead Time變更失敗率Change fail rate問(wèn)題平均恢復(fù)時(shí)長(zhǎng)Mean time to recover敏捷性高質(zhì)量【 吞吐量指標(biāo)】【 穩(wěn)定性指標(biāo) 】Global Outcome Accelerate 書(shū)中強(qiáng)調(diào)的 Software Delivery Performance 的四大指標(biāo)。目錄DevOps 開(kāi)發(fā)法剖析1以價(jià)值流的角度看 DevOps 的實(shí)戰(zhàn)2符合精益原則的 DevOps 真實(shí)世界開(kāi)發(fā)模式3問(wèn)答與回答4 符合精益原則的 DevOps 真實(shí)世界開(kāi)發(fā)模式 運(yùn)用 看板來(lái)驅(qū)動(dòng)開(kāi)發(fā) DevOpsKanban Driven Development精益七大原則:消除浪費(fèi)、盡快交付、著眼

15、全體、延遲決策、崁入完整性、 授權(quán)團(tuán)隊(duì)、增強(qiáng)學(xué)習(xí)。第一步、快 第二步、回饋第三步、學(xué)習(xí)文化教工程師如何運(yùn)用看板來(lái)增進(jìn)效能。如何實(shí)踐一個(gè)人的敏捷開(kāi)發(fā)?作 法運(yùn)用看板方法來(lái)實(shí)踐 DevOps 三步工作法， 學(xué)習(xí)DevOps 所造成的學(xué)習(xí)文化第一步、快 第二步、回饋第三步、學(xué)習(xí)文化作 法 L = CL: LearningC: Change人或企業(yè)，只有當(dāng)其學(xué)習(xí)的速度大于環(huán)境變化的速度，才可能成長(zhǎng)。變革公式 - 雷格. 瑞文斯 Reginald RevansL: LearningL = P + QP: 有已知解答Programmed knowledge程序性知識(shí)Q: 無(wú)正確解答Questioning

16、insight洞察性提問(wèn)成年人的學(xué)習(xí)是他們已知的事物與對(duì)未知事物的新提問(wèn)和質(zhì)疑相結(jié)合的過(guò)程。變革公式 - 雷格. 瑞文斯 Reginald Revans 回饋(實(shí)驗(yàn))的好壞決定學(xué)習(xí)的成果。第三步建立具有創(chuàng)意和高信度的企業(yè)文化，支持動(dòng)態(tài)、嚴(yán)格的、科學(xué)的 實(shí)驗(yàn)，在整個(gè)過(guò)程中持續(xù)學(xué)習(xí)。個(gè)人效能看板LowHigh505全景模式 25 mins( 2 )反饋專注模式等待11【待辦事項(xiàng)】【Ready】【Doing】【檢核】【完成】個(gè)人效能看板LowHigh505全景模式 25 mins( 2 )健康反饋專注模式等待11X 5X 2X 1健康公司工作事業(yè)老婆交代維持大小【待辦事項(xiàng)】【Ready】【Doing

17、】【檢核】【完成】個(gè)人效能看板【待辦事項(xiàng)】【Ready】【Doing】【檢核】【完成】自我評(píng)比5件 事 清 單LowHigh505好 的?寄 信 給 自 己健康公司工作事業(yè)老婆交代不 好 的?進(jìn)行迭代X 2X 5X 2X 1切 換 模 式全景模式 25 mins( 2 )健康工作事業(yè)老 婆1/10維持大小反饋專注模式等待11一個(gè)人的敏捷運(yùn)用Scrum12345 件事清單緊急的事不重要， 重要的事不緊急。全景鬧鐘一種透過(guò)整點(diǎn)或半點(diǎn)時(shí)段 設(shè)定鬧鐘的方法。目的是維持有25分鐘以上 的時(shí)間差距。10:03 的整點(diǎn)或半點(diǎn)時(shí)段為10:30，10:15 的整點(diǎn)或半點(diǎn)時(shí)段則為11:00.全景模式 vs 專注模

18、式Inspection vs Focus回饋 Feedback例:【一個(gè)人的敏捷，回饋的好壞決定學(xué)習(xí)的成果】聚焦維持集中精神全面性(不遺漏)反饋學(xué)習(xí)Email12345 件事清單緊急的事不重要， 重要的事不緊急。全景鬧鐘一種透過(guò)整點(diǎn)或半點(diǎn)時(shí)段 設(shè)定鬧鐘的方法。目的是維持有25分鐘以上 的時(shí)間差距。10:03 的整點(diǎn)或半點(diǎn)時(shí)段為10:30，10:15 的整點(diǎn)或半點(diǎn)時(shí)段則為11:00.全景模式 vs 專注模式Inspection vs Focus回饋 Feedback例:【一個(gè)人的敏捷，回饋的好壞決定學(xué)習(xí)的成果】Email聚焦全面性反饋學(xué)習(xí)集中精神 問(wèn)題與回答【完成】LowHigh【問(wèn)題】【分析】

19、103【回答】【確認(rèn)】13 目標(biāo)導(dǎo)向設(shè)定目標(biāo)我們想作什么？設(shè)定關(guān)鍵結(jié)果 #1設(shè)定關(guān)鍵結(jié)果 #2設(shè)定關(guān)鍵結(jié)果 #3我們?nèi)绾沃朗欠褚堰_(dá)成了目標(biāo). 問(wèn)題與回答【完成】LowHigh【問(wèn)題】【分析】【回答】【確認(rèn)】10313一旦；當(dāng)你把眼光投注在哪一個(gè)要項(xiàng)的時(shí)候，實(shí)際上你就只看到那一部分， 你的思緒將被那一部分的內(nèi)容所牽動(dòng)，很難再看見(jiàn)其他的事所以我們要退后一步，不! 有時(shí)要退后很多步，才能比較清晰地看見(jiàn)全貌。(好有趣喔! 退遠(yuǎn)了卻反而看得更清晰)所以要調(diào)整范圍，試圖把我們?cè)谝獾氖路胚M(jìn)視線可及之處， 淡淡的審視它，不帶一點(diǎn)情緒，就是這樣，我們看見(jiàn)了全貌。項(xiàng)目開(kāi)始之初，首重看見(jiàn)全貌我們?cè)谀睦?WE AR

20、E HERE!System ThinkingLEANAgileWater-Scrum-fall 以敏捷為基礎(chǔ)走向精益的思維過(guò)程(由 開(kāi)發(fā) 到 運(yùn)維 再到 業(yè)務(wù)端)當(dāng)你在運(yùn)行 Scrum 的時(shí)候，眼睛里只會(huì)看到 項(xiàng)目，當(dāng)你往前一步開(kāi)始思考 DevOps 時(shí)，則眼前又多出現(xiàn)了 產(chǎn)品的生命周期，這時(shí)候你才能體會(huì)到，其實(shí)你在做全面性的規(guī)劃，其實(shí)是進(jìn)入系統(tǒng)思維的領(lǐng)域了， 在持續(xù)看見(jiàn)全貌之后，往前、往后看自己在哪里，接著你會(huì)開(kāi)始思考該從哪里下手呢?想到 三步工作法；想到限制理論里所說(shuō)的: 當(dāng)你在運(yùn)行 Scrum 的時(shí)候，眼睛里只會(huì)看到 項(xiàng)目，當(dāng)你往前一步開(kāi)始思考 DevOps 時(shí)，則眼前又多出現(xiàn)了 產(chǎn)品的

21、生命周期，這時(shí)候你才能體會(huì)到，其實(shí)你在做全面性的規(guī)劃，其實(shí)是進(jìn)入系統(tǒng)思維的領(lǐng)域了， 在持續(xù)看見(jiàn)全貌之后，往前、往后看自己在哪里，接著你會(huì)開(kāi)始思考該從哪里下手呢?想到 三步工作法；想到限制理論里所說(shuō)的: TOC (Theory of Constraints) 思考程序里的 五大核心步驟：第一步，找出系統(tǒng)中存在哪些約束。第二步，尋找突破（Exploit）這些約束的辦法。第三步，使企業(yè)的所有其他活動(dòng)服從于第二步中提出的各種措施。第四步，具體實(shí)施第二步中提出的措施，使第一步中找出的約束環(huán)節(jié)不再是企業(yè)的約束。 第五步，回到步驟1，別讓惰性成為約束，持續(xù)不斷地改善就從眼前 最大的限制 開(kāi)始著手吧! Sys

22、tem ThinkingLEANAgile第二步，尋找突破（Exploit）這些約束的辦法。第三步，使企業(yè)的所有其他活動(dòng)服從于第二步中提出的各種 措施。第四步，具體實(shí)施第二步中提出的措施，使第一步中找出的 約束環(huán)節(jié)不再是企業(yè)的約束。第五步，回到步驟1，別讓惰性成為約束，持續(xù)不斷地改善 就從眼前 最大的限制 開(kāi)始著手吧!當(dāng)你在運(yùn)行 Scrum 的時(shí)候，眼睛里只會(huì)看到項(xiàng)目， 當(dāng)你往前一步開(kāi)始思考DevOps 時(shí)，則眼前又多出現(xiàn)了產(chǎn)品的生命周期，這時(shí)候你才能體會(huì)到，其實(shí)你在做全面性的規(guī)劃，其實(shí)是 進(jìn)入系統(tǒng)思維的領(lǐng)域了，在持續(xù)看見(jiàn)全貌之后，往前、往后看自己在哪里，接著你 會(huì)開(kāi)始思考該從哪里下手呢?想到

23、 三步工作法；想到限制理論里所說(shuō)的: TOC 思考程序里的 五大核心步驟： 第一步找出系統(tǒng)中存在哪些約束。DevOps是一個(gè)文化和業(yè)務(wù)問(wèn)題- Patrick Debois企業(yè)文化精益敏捷Water-Scrum-fall傳統(tǒng)文化文化改變的過(guò)程相互依賴宣言Declaration of Interdependence， DOIWe Increase return on investment by making continuous flow of value our focus. (Value)我們通過(guò)專注的持續(xù)產(chǎn)出價(jià)值流,來(lái)增加投資報(bào)酬率。We Deliver reliable results by engaging customers in frequent inte