<samp id="mpowf"></samp>

<delect id="mpowf"></delect>

<label id="mpowf"></label>

<label id="mpowf"><div id="mpowf"></div></label>
<del id="mpowf"></del>

<del id="mpowf"></del>

<button id="mpowf"><dfn id="mpowf"></dfn></button>

<strike id="mpowf"><dfn id="mpowf"><option id="mpowf"></option></dfn></strike>

<button id="mpowf"><dfn id="mpowf"></dfn></button>

<strike id="mpowf"><dfn id="mpowf"></dfn></strike><label id="mpowf"></label><label id="mpowf"><div id="mpowf"></div></label>

<button id="mpowf"><xmp id="mpowf">

新聞動態

【新聞資訊】2019加速度DevOps全球狀態報告 中文版(二)

發布時間:2019-09-29 點擊數:9364

上周我們發布了《2019加速度DevOps全球狀態報告》中文版的第一期,主要介紹了報告的前兩節內容,關于本次報告的概述,以及調查的人員情況。

致謝:DevOpsDays中國社區

致謝:申請翻譯、參與翻譯、校審的志愿者

本期翻譯:杜靜嫻,徐東偉,校審:劉征

文稿呈現:張潔

組委會:張揚、張樂、孫振鵬、許峰

本期,將介紹報告的第三節內容,主要是對此次報告研究模型的理解和解讀。

 

如何進行比較?




3.1軟件交付和運維效能

組織越來越依賴于他們交付和運營軟件系統的能力,以實現他們的目標。為了比較這個關鍵結果指標上的效能,行業需要一種方法來度量開發和交付實踐的有效方法。在過去的六年里,我們開發并驗證了四個度量標準,它們提供了軟件交付和效能的高級系統視圖,并預測了組織實現其目標的能力。去年,我們增加了一個關注運維能力的額外指標,并發現該指標有助于組織交付卓越的成果。我們將這五個度量稱為軟件交付和運維效能(SDO),它們關注于系統級的輸出。這有助于避免進入軟件度量的常見陷阱,避免讓不同的功能自相矛盾,并導致局部優化而忽略了整體結果。

 

開發和交付過程有效性的前四個指標可以根據吞吐量和穩定性進行評估。我們使用代碼更改從簽入到發布的前置時間,以及部署頻率來度量軟件交付過程的吞吐量。

穩定性是用故障恢復時間來測量的,從檢測影響到用戶的事件到對其進行補救所花費的時間,以及變更失敗率,這是對發布過程質量的一種度量。



許多專業人士認為增加吞吐量將制約軟件交付過程的可靠性和服務的可用性,故而權衡取舍這些 度量指標。然而,我們連續六年研究持續表明,速度和穩定性是相互促進的結果。2019年的數據中四個軟件交付指標的聚類分析揭示了四類不同性能的組織概況,其中吞吐量和穩定性度量在統計上有顯著差異5。和前幾年一樣,我們的高效能組織在所有四個方面都做得更好,而低效能組織在所有方面都做得更差。

5 可用性不包括在我們的聚類分析中,因為可用性度量不以相同的方式應用于軟件解決方案的,它并不是以服務形式提供的,例如打包的軟件或固件。

 

除了速度和穩定性之外,可用性對運維性能也很重要。在高層次上,可用性代表了技術團隊和組織對他們正在運行的軟件信守承諾和主張的能力。值得注意的是,可用性是關于確保產品或服務對最終用戶可用并可被其訪問6??捎眯苑从沉藞F隊如何定義他們的可用性目標,跟蹤他們當前的可用性,并從任何中斷中學習,確保他們的反饋循環是完整的。用于度量可用性的項目構成了有效和可靠的度量結構。

6 團隊可以使用服務級別協議(SLAs)和服務級別目標(SLOs)定義他們的可用性目標,并使用服務級別指標(SLIs)度量他們的性能。有關開發SLAs、SLOs和SLIs的更多信息,可以查看拜爾等人編寫的《站點可靠性工程:谷歌如何運行生產系統》一書(2016)


由于不是正態分布,所以使用中位數報告。

除非另有說明,否則基于Tukey的事后隨機分析,所有差異都有顯著差異。

a、b、c 根據Tukey的事后隨機分析,平均值存在顯著差異;中位數由于底層的分布不會顯示出差異。

d 根據Tukey的事后隨機分析,平均值并沒有顯著差異。

* 有關四個指標的可視化呈現,請參閱附錄a。

 

我們還證實了去年的發現,更好的軟件交付與更高的可用性是密切相關的。分析表明,可用性度量與軟件交付性能顯著相關,精英和高效能組織一致報告了更高的可用性,精英擁有強大可用性實踐的可能性是其他組織的1.7倍7 。

7 還應該注意的是,這些實踐中沒有一個只適用于云。

 

行業的速度在增加

許多分析師報告稱,該行業在DevOps和技術轉型方面“跨越了鴻溝”,我們今年的分析證實了這些觀察。隨著向云技術的轉變,行業發展速度正在加快,速度和穩定性都在提高。這重申了技術的重要性,使組織能夠向利益相關者交付價值。

 

SDO效能對行業和組織的影響

我們進行了額外的分析(例如,使用控制變量),以查看行業和組織大小是否對SDO效能有顯著影響。我們沒有發現任何證據表明行業對經濟有影響,零售業除外。這表明,所有類型和規模的組織,包括金融服務和政府等受到高度監管的行業,都能實現高水平的效能。我們對零售業的研究結果表明,那些從事零售業的人在速度和穩定性方面獲得了收益。

 

我們發現有證據表明,與員工少于5000人的組織相比,大型企業組織(員工超過5000人的組織)的效能較低。這可能是由于在大型組織中看到的幾個因素造成的,最顯著的是重量級流程及控制,還有緊密耦合的架構,引入了延遲和相關的不穩定性。我們敦促企業不要把這些發現作為業績不佳的借口,而是要認識到卓越是可能的,要開始一個持續改進的項目,并向其他取得優秀業績的企業組織尋求靈感和指導。



3.1.1 吞吐量

部署頻率

根據精英效能組織的反饋,他們通常會按需部署,并且每天都會做多次部署,在過去幾年里一直如此。相比之下,低效能組織的部署頻率為一個月一次(一年12次)至六個月一次(一年2次)不等,這一數據比去年有所下降?;谝陨蠑祿?,我們可以計算標準化的年度部署次數,其范圍從高效能組織的一年1,460次(按照一天4次部署*365天計算)到低效能組織的一年7次(取12次和2次的平均數)?;谶@項分析,我們可以看到,精英效能組織部署代碼的頻率比低效能組織高出208倍。值得注意的是,與很多公司的實踐相比,每天4次部署是一個保守的估計。例如:CapitalOne 每天部署50次8,或者例如Amazon、Google以及Netflix每天部署幾千次(生產環境里的數百項服務的合計值)。


變更前置時間

同樣地,根據精英效能組織的反饋,他們的變更前置時間,即從提交代碼到代碼成功部署到生產環境的時間不到1天,這一數據比去年稍有下降,去年精英效能組織報告的變更前置時間為不到1小時;相比之下,低效能組織則需要1到6個月的前置時間。如果按照精英效能組織需要24小時前置時間(這是取自于“不到1天”的保守估算)、低效能組織需要2,555小時前置時間(對1個月730小時和6個月4,380小時求平均數而得)來計算,精英效能組織比低效能組織在變更前置時間方面快106倍。

 

3.1.2 穩定性

服務恢復時間

根據精英效能組織的反饋,其服務恢復時間在1小時以內,而低效能組織則在1周到1個月之間。我們采用了比較保守的計算方法:對精英效能組織取值1小時,對低效能組織取1周(168小時) 和1個月(5,040小時)的平均值?;谶@個計算方法,精英效能組織的服務恢復時間比低效能組織快2,604倍。如前所述精英效能組織和低效能組織在服務恢復時間這一指標上的表現與去年相同。

 

變更失敗率

根據精英效能組織的反饋,其變更失敗率指標在0%到15%之間,而低效能組織則在46%到60%之間。取平均值的結果為,精英效能組織的變更失敗率為7.5%,低效能組織的變更失敗率為53%。這一結果說明精英效能組織在這個指標上領先低效能組織7倍。如前所述,精英效能組織和低效能組織在變更失敗率這一指標上的表現與去年相同。


3.2 如何使用研究模型



如果你想提高SDO效能或組織效能,請查看具有這些結構體的模型,并前往報告的相應部分,了解應該關注哪些能力(請關注第三期)。

 

如果你想提高生產力,請查看具有生產力結構體的模型,并前往報告的相應部分,了解應該關注哪些能力(請關注第四期)。

 

如何使用這兩個模型來指導轉型

> 識別能夠改善你的目標的能力(即那些帶箭頭的,指向你想要改進的結構體的能力)。正如我們在本報告中指出的,這些是您的改進候選能力。(對于SDO和組織效能,我們在過去五年的研究中還識別了其他能力。)9

> 記住,加速轉型要從堅實的基礎開始,然后關注那些成為限制的能力:是什么能力導致了最大的延遲?你最頭疼的是什么?最大的問題在哪里?選擇三到五個,首先投入資源解決這些問題。如果你仍然有問題,不要擔心;通過關注當前最大的問題,你可以消除瓶頸,發現協同效應,以及避免不必要的工作。

> 這項工作還有其他重要成果。尋求提高SDO和組織效能的好處包括減少職業倦怠和部署痛苦(我們在2016年和2017年對此進行了研究),改善安全成果(我們在2017年和2018年對此進行了研究),以及文化(我們從2014年至2019年對此進行了研究)。提高生產力的其他好處包括改善工作/生活平衡和減少職業倦怠。

9:You can find all of our State of DevOps Reports at cloud.google.com/devops

 

如何閱讀研究模型

我們使用結構方程模型(SEM),這是一個用于測試關系的預測模型。每個框表示我們在研究中度量的結構體,每個箭頭表示結構體之間的關系。包含框(結構體)的較大的框是二級結構體。淺藍色的框與另一個結構體的之間的虛線表示一個控制變量。(參考第31頁和第57頁了解完整的模型。)帶有粗體文字的結構體表示我們今年首次調查的結構體。帶有粗體輪廓的結構體是團隊和組織的共同目標:SDO效能和組織效能或生產力。在識別你的目標以及閱讀模型時,請將這些內容牢記在心。


在解釋這兩個模型時,可以將這些帶箭頭的線讀作“預測”、“影響”、“驅動”或“強烈影響”。例如,二級結構體SDO效能由軟件交付效能和可用性結構體組成,這些共同驅動組織效能。災難恢復測試結構體驅動可用性。我們指出,災難恢復測試是今年新調查的一個結構體,用粗體文字標記。帶箭頭的線旁邊有一個(-),表示兩個結構體之間具有強烈的反向影響;例如,技術債務強烈地反向影響(或者說降低)生產力。

 

你可能注意到兩個研究模型之間有一些重疊

這是因為兩個目標——SDO效能和生產力——在很多方面都有關聯。它們都致力于以卓越地、向組織和個人交付價值的方式制造和交付技術。我們為支持軟件交付工作所做的很多事情,對于開發和交付軟件的人員的生產力提升也是大有裨益的,這也是講得通的。然而,盡管它們相似,但它們仍然在度量不同的結果,因此我們分別進行分析。這樣一來,他們就存在于兩種不同的研究模型中。

 

兩個研究模型的重疊部分告訴我們

> 明智地投資于SDO效能的提升可以減少精疲力盡,提高生產力也可以減少職業倦怠。這一結論對于組織和技術人員來說應該是鼓舞人心的,因為工作的需求會不斷增長。我們注意到,良好的工作/生活平衡是減少職業倦怠的關鍵。

> 心理安全文化有助于SDO效能、組織效能和生產力,表明健康文化的成長和培養會為組織和個人帶來好處。

> 在代碼可維護性、松耦合架構和監控方面的投資有助于支持SDO效能(通過持續交付達成)和生產力(通過減少技術債務達成),這突顯了良好工具和系統的重要性。

 



深圳青藍咨詢服務有限公司

話:0755-86950769

網:www.kytd17.com

箱:qinglan@shzhchina. com

 址: 深圳市南山區高新南一道06號TCL大廈B座3樓309室

深圳地鐵1號線高新園站C出口



久久久国产精品
<samp id="mpowf"></samp>

<delect id="mpowf"></delect>

<label id="mpowf"></label>

<label id="mpowf"><div id="mpowf"></div></label>
<del id="mpowf"></del>

<del id="mpowf"></del>

<button id="mpowf"><dfn id="mpowf"></dfn></button>

<strike id="mpowf"><dfn id="mpowf"><option id="mpowf"></option></dfn></strike>

<button id="mpowf"><dfn id="mpowf"></dfn></button>

<strike id="mpowf"><dfn id="mpowf"></dfn></strike><label id="mpowf"></label><label id="mpowf"><div id="mpowf"></div></label>

<button id="mpowf"><xmp id="mpowf">