出品666709作者簡介6811擴展閱讀78簡介18云云DevOps8文化3601摘要22022加速DevOps狀態(tài)報告01摘要在過去的8年里，我們撰寫了加速：DevOps狀態(tài)報告(AccelerateStateof視那些預(yù)測DevOps核心產(chǎn)出的能力和實口軟件交付效能(Softwaredeliveryperformance)——軟件交付效能的四個關(guān)鍵指標(biāo)：部署頻率、變更前置時間、變更失敗率和服務(wù)恢復(fù)時間；口運維效能——第五個關(guān)鍵指標(biāo)是可靠性；口組織績效——組織實現(xiàn)績效和盈利目標(biāo)的此外我們還關(guān)注了導(dǎo)致其他結(jié)果 意推薦他們團(tuán)隊的可能性。01摘要3供應(yīng)鏈我們利用軟件安全制品的供應(yīng)鏈級別(SupplyChainLevelsforSecureArtifacts，簡稱SLSA)框架來探索支持軟件供應(yīng)鏈安全開發(fā)的技術(shù)實踐。我們還使用了國家標(biāo)準(zhǔn)與技術(shù)協(xié)踐。有效地發(fā)現(xiàn)易受攻擊的依賴項，從而減少生產(chǎn)代碼中的漏洞。A顯現(xiàn)。01摘要42022加速DevOps狀態(tài)報告1.組織績效的驅(qū)動因素全實踐，影響組織績效的關(guān)鍵因素1)組織和團(tuán)隊文化的贊助和領(lǐng)導(dǎo)的支持，那么它的組織績效往往會更高。)也往往會導(dǎo)致更高水平的組織績效。最后，提供靈活工作安排的公司往往會有高水平的組織績效。2)可靠性3)云織績效。我們發(fā)現(xiàn)使用公共云的組織也更有可能實現(xiàn)SLSA實踐——可能是因為云提供商鼓勵并為01摘要52022加速DevOps狀態(tài)報告2.環(huán)境的重要性站點可靠性工程(SRE)實踐對團(tuán)隊達(dá)到可靠性目標(biāo)能力的影響是非線性的。在團(tuán)隊烈地預(yù)測可靠性。持續(xù)增長的可靠性會影響組織的效能。起來，可以培養(yǎng)出比各部分總和更出色的軟件交付效能。似的結(jié)論：01摘要62022加速DevOps狀態(tài)報告”績效。但并非總是如此(適用于一個組織的東西不一定適用于偶爾的失敗做好準(zhǔn)備，因為我們正在研究什么適合我們的團(tuán)隊。認(rèn)認(rèn)識到持續(xù)改進(jìn)必要性的團(tuán)隊，往往比那些沒有認(rèn)識到這一點的團(tuán)隊，有更高的組織績效。02如何比較？72022加速DevOps狀態(tài)報告02如何比較？你是否好奇自己的團(tuán)隊與業(yè)內(nèi)其他團(tuán)隊相比如何?本節(jié)內(nèi)容包括了DevOps效能的最新基效能最常見組合的聚類。02如何比較？82022加速DevOps狀態(tài)報告和運維效能們團(tuán)隊表現(xiàn)出出色的組織績效。我們將這五種度量稱為軟件交付和運維(SDO)效能。請注意，02如何比較？92022加速DevOps狀態(tài)報告1)軟件交付和運維效能的五個指標(biāo)可以從吞吐量和穩(wěn)定性的角度考慮軟件交時間(即從代碼提交到生產(chǎn)中發(fā)布的時間)發(fā)生后恢復(fù)服務(wù)的時間和變更失敗率來衡第五個指標(biāo)代表運維效能，是對現(xiàn)代運維實踐的衡為可用性是可靠性工程的一個特定焦點，我們在們要求受訪者對他們達(dá)到或超過可靠性目標(biāo)的能力具有不同程度交付效能的團(tuán)隊得到了更好的結(jié)果(例如，更少的職業(yè)倦怠)。02如何比較？102022加速DevOps狀態(tài)報告表2-1件交付效能度量低中高署頻率對于我們使用的主要應(yīng)用程序或服務(wù)，我們的組織將代碼部署到生產(chǎn)環(huán)境或?qū)⑵浒l(fā)布給終用戶的頻率是多少?次之間間按需部署(每天多次部署)變更前置時間對于我們從事的主要應(yīng)用程序或服務(wù)，變更產(chǎn)中成功運行的代碼需要多長時間)?個月之間一個月之間之間務(wù)恢復(fù)時間對于我們使用的主要應(yīng)用程序或服務(wù)，當(dāng)發(fā)復(fù)服務(wù)?一個月之間之間不到一天變更失敗率對于我們使用的主要應(yīng)用程序或服務(wù)，對生產(chǎn)或發(fā)布給用戶的更改中有多少百分比會導(dǎo)發(fā)修復(fù)、補丁)?46%-60%0%-15%02如何比較？112022加速DevOps狀態(tài)報告精英效能聚類的特征。工感覺自己取得了長足進(jìn)步的團(tuán)隊或組織。一個可能的假設(shè) (我們目前缺乏數(shù)據(jù)支持)是，軟件開發(fā)在實踐、工具和信息共享方面的創(chuàng)新減少了。這可的高效能和精英效能之間。2022年的低效能聚類似乎介于2021年的低效能和中等效能02如何比較？122022加速DevOps狀態(tài)報告團(tuán)隊要么還沒有建立起，要么正在建立起一種我們正在許多現(xiàn)代團(tuán)隊中看到的DevOps02如何比較？132022加速DevOps狀態(tài)報告3)對交付效能和運維效能進(jìn)行聚類我們決定對這五個指標(biāo)所代表的三個類別進(jìn)行聚類分析：吞吐量(代碼變更前置時間和部合)、穩(wěn)定性(服務(wù)恢復(fù)時間和變更失敗率的組合)和運維效能(可靠性)。這樣做的組況而不考慮運維效能，那么就遺漏了全局的一個關(guān)鍵部分。能量受訪者復(fù)時間敗率間率間31%-5%有時符合期之間次之間不到??時通常符合期不到?天按需(每天多次部署)不到?天通常符合期之間次之間個??六個46%-60%通常符合期之間02如何比較？142022加速DevOps狀態(tài)報告類)。每個聚類都有獨特的特點，每個聚類都有獨特的特點，占應(yīng)答者中的很大比例特性或服務(wù)開發(fā)的早期階段。他們可能不太關(guān)注可靠性，因與市場的契合度，更廣泛地說，是探索。們的應(yīng)用程序或產(chǎn)品的當(dāng)前狀態(tài)感到滿意?！八ネ司垲悺?theRetiringcluster)看起來像一類團(tuán)隊，他們正在開發(fā)對他們和他02如何比較？152022加速DevOps狀態(tài)報告這些聚類在實踐和技術(shù)能力方面明顯不同。鑒于流動聚類(TheFlowingcluster)展示了高水平的軟件交付和運維效能，我們決定研究一下它們在實踐和技術(shù)能力方面與其他聚類的區(qū)別。提供靈活性：公司對員工工作安排的靈活性持續(xù)集成(CI)：將分支集成到主干中的頻率持續(xù)交付(CD)：專注于將變更安全、可持續(xù)和高效地投入生產(chǎn)的能力的那樣。有低吞吐量和高積極的工作文化(根據(jù)Westrum的說法，這是一種“生機型”工作文化);這是一個不常見的組合。更常見的是按比例看到吞吐量和工作文化(高/高或低/低)。我們希望02如何比較？162022加速DevOps狀態(tài)報告特征(穩(wěn)定性差和吞吐量差)，這似乎與DORA之前的大多數(shù)發(fā)現(xiàn)不一致。但我們并不是責(zé)們的團(tuán)隊將付出職業(yè)倦怠和完成計劃外工作的代價。的組織績效，特別是流動聚類。成型的階段。因此有更成熟的DevOps流程。也就是說，數(shù)據(jù)顯示，一個組織的規(guī)模與組織績效呈正相關(guān)，其原因可能與技術(shù)無關(guān)。會損害組織的效能。何定義他們的組織績效目標(biāo)也不同。衰退聚類可能具有較高的短期組織績效，但我們想知道它們將如何執(zhí)行長期效能。職業(yè)倦怠會導(dǎo)致人員流失嗎?他們能夠擴展他們的流程嗎?02如何比較？172022加速DevOps狀態(tài)報告構(gòu))；在組織的層面上提出組織績效問題。組織通常有很多團(tuán)隊，受訪者可能會意學(xué)是最有效的。)，03如何改進(jìn)?182022加速DevOps狀態(tài)報告03如何改進(jìn)?1.如何在眾多成果中獲得提升?DevOps指導(dǎo)，幫助您的團(tuán)隊專注于DevOps實踐和能力，以計劃外工作和錯誤傾向，不僅作為提高SDO和組織績效的手段，而且作為目標(biāo)本身。最后，今年我們確信的宣布，實踐和能力似乎對這些結(jié)果產(chǎn)生了影響。03如何改進(jìn)?192022加速DevOps狀態(tài)報告的做的對您可以在我們的網(wǎng)站上找到今年和往年的研究模型。超越DORA四個關(guān)鍵指標(biāo)的內(nèi)容DORA和運維的效能？美國利寶相互保險公司的跨職能軟件工程師團(tuán)隊JennaDailey分享說，一個小型團(tuán)隊利用DORA的研究來幫助團(tuán)隊識別瓶頸，轉(zhuǎn)向測試驅(qū)動開發(fā)方法，并實現(xiàn)整體效能的改進(jìn)。在利寶相互保險公司近期的分享中詳細(xì)了解利用數(shù)據(jù)和DORA指標(biāo)提升軟件質(zhì)量和交付的方法。03如何改進(jìn)?202022加速DevOps狀態(tài)報告2.云包云的人數(shù)，包括那些不使用私有云的人數(shù)，從去年的21%下降到只有10.5%。多個公有云的使用率從21%上42.5%這個比例。我們還看到私有云的使用率小幅增長至32.5%，高于去年報告的29%。使用量增長用量增長03如何改進(jìn)?212022加速DevOps狀態(tài)報告高出14%。如我們在前幾年所展示，并在本報告中繼續(xù)驗證，云計算的使用對整體組織績效產(chǎn)積極影響。與未使用云的同行相比，使用云的受訪者超過組織績效目標(biāo)的可能性高出14%。我們的調(diào)研顯示，云計算使團(tuán)隊能夠在軟件供應(yīng)鏈安全性和可靠性等方面有令人驚訝的是，所有類型的云(公共云、私有云、混合云和多云)的用戶都與變更失究中進(jìn)一步調(diào)查此現(xiàn)象，而不是推測其原因。但除了少數(shù)例外，云原生應(yīng)用程序(最初為云設(shè)計和架構(gòu)的應(yīng)用程序)的使用在我們調(diào)查的所有內(nèi)容中都表現(xiàn)出積極的信使用任何公有或私有云計算平臺都對文化和工作環(huán)境成果有積極貢獻(xiàn)(例如，生機型文化、更低的職業(yè)倦怠、更高級別的穩(wěn)定性和更高的員工滿意度)。云用戶在這些文化成果上的得分高出16%。同比增長03如何改進(jìn)?222022加速DevOps狀態(tài)報告混合云和多云(包括私有云)的使用似乎對軟件交付效能指標(biāo)(MTTR、交付周期和部署頻率)產(chǎn)生負(fù)面影響，除非受訪者具有高級別的可靠性。1)混合云和多云推動組織績效烈信號。與非云用戶相比，混合云或多云(包括私有云)的使用似乎會對幾個軟件交付效能指標(biāo)(MTTR、交付周期和部署頻率)產(chǎn)生負(fù)面影響。這一發(fā)現(xiàn)進(jìn)一步說明了穩(wěn)健的SRE實踐的重要性以及可靠性在將無法獲得可靠的服務(wù)。超過50%的從業(yè)者報告說利用了不同云提供商的獨特優(yōu)勢。多個云服務(wù)商獲得的好處03如何改進(jìn)?232022加速DevOps狀態(tài)報告使用云計算的五個特征是效的重要開端2)云計算的五個特征使用云計算技術(shù)。我們通過詢問調(diào)研參與者關(guān)于美國國家標(biāo)準(zhǔn)與技術(shù)研究院(NIST)定義。按需自服務(wù)–消費者可以根據(jù)需要自動創(chuàng)建計算資源，而無需與云計算提供商進(jìn)行任何人工交互。無所不在的網(wǎng)絡(luò)接入—廣泛接入，消費者可以通過手機、平板電腦、筆記本電腦物理和虛擬資源資源的確切位置，用，用戶可以隨時占用任意數(shù)量的資源。帳戶)03如何改進(jìn)?242022加速DevOps狀態(tài)報告本報告驗證了DORA前三年的研究，得出的結(jié)論是，組織中這五個特征的存在對軟件交付和運維效能產(chǎn)生積極影響。我們還發(fā)現(xiàn)，具備這些特征會以積極方式影響組織的流程，從而提高組織績效。具備云計算的五個特征是實現(xiàn)更高組織績效的漫程的第一步在2022年，我們看越來越多的團(tuán)隊在使我們看到越來越多的團(tuán)隊采用云計算的五增長2022加速DevOps狀2022加速DevOps狀態(tài)報告3.SRE和DevOps一個成功的技術(shù)團(tuán)隊對其組織的貢獻(xiàn)不只是交付代碼——需要比交付高質(zhì)量代碼貢獻(xiàn)更多可靠性是衡量團(tuán)隊履行這些承諾的標(biāo)準(zhǔn)，今年我們繼續(xù)探索軟件交付和運維的可靠性這個SRE在許多組織中得到SRE別目標(biāo)(SLO)盡可能客觀地評估這些方法落地的程度，我們十分注意在我們提供給受訪者的調(diào)查問卷中使用中性的描述性語言。我們還收集有關(guān)可靠性工程成果的數(shù)據(jù)：團(tuán)隊能夠?qū)崿F(xiàn)其可靠性目標(biāo)的程度。輸入和輸出——SRE實踐和可靠性成果——與其他DevOps能力均反映在我們的預(yù)測模型中。定性至關(guān)重要實踐。在如此廣泛的團(tuán)隊中，數(shù)據(jù)揭示了可靠性、軟件交付和結(jié)果之間的微妙關(guān)系：當(dāng)可靠性較差時，軟件交付效能并不能預(yù)言組織的成功。然而，隨著可靠性的提高，我們開始看到軟件交付對業(yè)務(wù)成功的積極影響。03如何改進(jìn)?262022加速DevOps狀態(tài)報告SRE但只有在達(dá)到采用門送到脆弱的生產(chǎn)環(huán)境中并不會使用戶受益。正如站點可靠性工程師長期以來所斷言的那樣，可靠性是任何產(chǎn)品最重要的“特征”。我們的研究支持這樣的觀察，即信守對用戶的承諾是改進(jìn)軟件交付以使組織受益的必要條2)承認(rèn)J-曲線在實現(xiàn)可靠性的道路上，有哪些挑戰(zhàn)等待著您？在O'Reilly的出版物“SRE的企業(yè)路線圖”1中，DORA的調(diào)查貢獻(xiàn)者JamesBrookbank和SteveMcGhee反思了他們在已建立的組織中實施SRE的經(jīng)驗，并建議“承認(rèn)變革的J曲線”。之前在2018年DevOpsJ出往會獲得新的、持續(xù)的成就。我們今年的研究揭示了我們研究的技術(shù)團(tuán)隊的J曲線模式：當(dāng)團(tuán)隊參與較少的可靠性工程實踐時——表明他們在采用SRE的過程處于早期階段——這些實踐并不能預(yù)言更好的可靠性結(jié)果。然而，隨著團(tuán)隊采用更多的SRE，他們達(dá)到了一個拐點，即使用SRE開始強googleresourcespractices-and-processes/enterprise-03如何改進(jìn)?272022加速DevOps狀態(tài)報告E應(yīng)該為一路上的挫折做好準(zhǔn)備。這可和工具都將調(diào)整為新的指導(dǎo)原則。但起步嘗試SRE并且在未來堅持不懈的升的成果投資人員、流程與工具ps程受益于工程師在流程和工具方面的更多嘗試。使用云計算和持續(xù)集成等實踐可以預(yù)言03如何改進(jìn)?282022加速DevOps狀態(tài)報告4.專業(yè)的DevOps能力(DevOps技術(shù)能力)p到產(chǎn)品環(huán)境的迭代過程).03如何改進(jìn)?29.2022加速DevOps狀態(tài)報告高效能組織使用Cl的達(dá)到可靠性交付目標(biāo)的松耦合架構(gòu)。比，其組織績效比不使用這些功持續(xù)集成持續(xù)集成(通常稱為CI)是外循環(huán)動的構(gòu)建項目并對自動對每次提交否已具備準(zhǔn)備部署的條件。此過程使他們能夠更有信心地進(jìn)行交付代I代碼倉庫部署到生產(chǎn)環(huán)境的關(guān)鍵過效的提升交付效率。達(dá)到交付可靠性目標(biāo)的高績效員工使用CI的比例是其他公司的1.4倍。03如何改進(jìn)?302022加速DevOps狀態(tài)報告2)基于主干進(jìn)行開發(fā)開發(fā)是將代碼不斷合并到主干中，并避免將長期存在的功能保留在分支中的做快軟件交付速度。他們有軟件交付的整體質(zhì)量下降人計劃外的工作量增加人增加出錯率人提高變更失敗率擁有16年以上工作經(jīng)驗的研發(fā)人員選擇基于主干開發(fā)的方式，這部分人群意識到基于主人提高整體軟件交付質(zhì)量減少計劃外工作量降低出錯率降低變更失敗率常痛苦。03如何改進(jìn)?312022加速DevOps狀態(tài)報告3)持續(xù)交付持續(xù)交付(CD)是一種軟件開發(fā)的實踐方式，它有以下特征：使團(tuán)隊能夠隨時將軟件部署到生產(chǎn)環(huán)境或交付給最終用戶確保軟件代碼在其全局的交付生命周期(流水線)中處于可部署狀態(tài)，包括新功能能夠正常工作的場景。部署每個構(gòu)建的軟件，而持續(xù)交付僅要求可以隨時的進(jìn)行部署所構(gòu)建的軟件。4)CD驅(qū)動軟件交付能力深度較高的團(tuán)隊更有可能具有以更高的頻率將代碼部署到生產(chǎn)環(huán)境，以及具備以更短的時03如何改進(jìn)?322022加速DevOps狀態(tài)報告與與僅專注于版本控制或僅專注于持續(xù)交付的團(tuán)隊相比，將版本控制和持續(xù)交付相結(jié)合的團(tuán)隊在高軟件交付能力方面高出2.5倍。效可以提高2.5倍。5)CD會增加計劃外工作6)技術(shù)實踐和持續(xù)交付一些場景，當(dāng)其中一些單獨的技術(shù)功能與CD結(jié)合使用時會發(fā)生什么現(xiàn)看到的證據(jù)表明，與僅采用CD的團(tuán)隊相比，同時采用松耦合架構(gòu)和CD的團(tuán)隊在預(yù)測錯誤發(fā)生率方面，比平均水平要高出43%，如服務(wù)中斷、安全漏洞和顯能力(如CD)時，請務(wù)必注意持續(xù)交付對團(tuán)隊的整體效能的影響。03如何改進(jìn)?332022加速DevOps狀態(tài)報告7)松耦合架構(gòu)的架構(gòu)設(shè)計可以實現(xiàn)以下效果：合對其系統(tǒng)進(jìn)行配合更改，具備自主性構(gòu)建的軟件是否采取基于松耦合的架構(gòu)設(shè)架構(gòu)的存在與團(tuán)隊在多個維度上所統(tǒng)計的。03如何改進(jìn)?342022加速DevOps狀態(tài)報告8)松耦合架構(gòu)的優(yōu)勢們的公司或被公司的同事推薦到他們的項目中。用微服務(wù)技術(shù)架構(gòu)的方式。專注于使用松耦合架構(gòu)構(gòu)建軟件的團(tuán)隊處于更有利的地位，可以在穩(wěn)定性、可靠性和研發(fā)吞吐量方面表現(xiàn)的更加出色。的協(xié)調(diào)成本。展，而無需與其他團(tuán)隊進(jìn)行溝通協(xié)調(diào)。心，但這個時候，需要優(yōu)先實現(xiàn)系統(tǒng)的松耦合架構(gòu)。離的一種有效方法是提高服務(wù)和組件之間的“可測試性”。如果您的設(shè)計允許您單獨測試服03如何改進(jìn)?352022加速DevOps狀態(tài)報告RE9)令人驚訝的發(fā)現(xiàn)證明了將安全問題交與專業(yè)的團(tuán)隊進(jìn)行負(fù)責(zé)的好處(請參考：為什么供應(yīng)鏈安全很重要)。03如何改進(jìn)?362022加速DevOps狀態(tài)報告5.文化方法。每個組織都有自己獨特的文化，我們的研究一直表明，文化是組織成功和員工幸福是通過選擇工具、項目實踐、組織協(xié)同等方式，來快速、可靠、安全的進(jìn)行開發(fā)工作并交付軟件。我們可以通過組織文化等因素的影響，來幫助領(lǐng)導(dǎo)者了解組織文化正在面臨的挑戰(zhàn)，并協(xié)助領(lǐng)導(dǎo)者正面應(yīng)對這些挑戰(zhàn)。因此，培養(yǎng)一個積極向上并健康的組織文化是組織的優(yōu)先事項，如果不解決組織文化的相關(guān)事情，組織文化所帶03如何改進(jìn)?372022加速DevOps狀態(tài)報告今年，我們繼續(xù)通過使用Westrum的組織類型學(xué)模型的方式，來衡量一個組織中的文化健康狀m員身體和精神方面職業(yè)倦怠的情況。。的團(tuán)隊——其組成在過去12個月里沒有太大變化的流失的團(tuán)隊可能更難保持高質(zhì)量的產(chǎn)出。病態(tài)型組織機型組織缺少合作合作程度一般度合作溝通被阻礙不重視溝通培養(yǎng)溝通方式逃避責(zé)任各擔(dān)責(zé)任擔(dān)責(zé)任建立部門墻建立部門墻打破部門強失敗時尋找替罪羊失敗時公平懲罰失敗時追根溯源壓制新想法認(rèn)為新想法會招引麻煩接納新想法03如何改進(jìn)?382022加速DevOps狀態(tài)報告高效能的組織更有可能對工作進(jìn)行靈活的安排?；钚匀邕h(yuǎn)程辦公模式、職場辦公模式、遠(yuǎn)程和職場相結(jié)合的混合辦公模式。我們進(jìn)行了調(diào)查，辦公模式之間進(jìn)行自由自由度，對組織有直接的好處。怠職業(yè)倦怠(Burnout)指個體在工作重壓下產(chǎn)生的身心疲勞與耗竭的狀態(tài)，會產(chǎn)生對工作員工有自殺念頭的風(fēng)險[1]。去年，我們在新冠肺炎大流行的背景下分析了職業(yè)倦怠的影響，我們發(fā)現(xiàn)，一個有活力、職業(yè)倦怠率存在很大的關(guān)聯(lián)。[1]*MaslachC,LeiterMP.Understandingtheburnoutexperience:recentresearchanditsimplicationsforpsychiatry.WorldPsychiatry.2016Jun;15(2):103-11.doi:10.1002/wps.20311.PMID:27265691;PMCID:PMC4911781.03如何改進(jìn)?392022加速DevOps狀態(tài)報告靈活的工作模式會降低員工的職業(yè)倦怠，并增加員工推薦團(tuán)隊為良好工作地的意愿。S將他們的團(tuán)隊推薦給朋友或同事的意愿。我們也發(fā)現(xiàn)團(tuán)隊NPS與領(lǐng)導(dǎo)力認(rèn)同感相關(guān)。更有意愿向他人推薦自己的團(tuán)隊相關(guān)。待他們的組織我們還讓被調(diào)查人員預(yù)測未來1年內(nèi)發(fā)生安全漏洞或系統(tǒng)完全中斷的可能性。結(jié)果表明，我們發(fā)現(xiàn)在軟件交付效能較高的組織工作的員工基本不認(rèn)為需要通過改變當(dāng)前的做法來改善業(yè)務(wù)成果。03如何改進(jìn)?40表性雖然我們繼續(xù)強調(diào)文化的重要性，但我們承認(rèn)改變甚至改善組織的文化并非易事。作為04供應(yīng)鏈安全為何重要412022加速DevOps狀態(tài)報告04供應(yīng)鏈安全為何重要士懷疑，一場軟件供應(yīng)鏈安全危機正在04供應(yīng)鏈安全為何重要422022加速DevOps狀態(tài)報告域的安全性。在本章中，我們重點討論兩個倡議。軟件制品的供應(yīng)鏈級別(SLSA，發(fā)音為"salsa")和NIST安全軟件開發(fā)框架(SSDF)。兩者都提供了一系列的防御措施，每一種都軟別是，經(jīng)得到了適度的采用，但仍有很大的空間。軟件供應(yīng)鏈安全實踐已經(jīng)得到了適度的采用。但仍有很大的空間。的技術(shù)方面的采用似乎取決于是軟件開發(fā)安全實踐的一個主要驅(qū)度低的組織文化更有可能建立SLSA和SSDF實踐。好的安全實踐帶來了更多04供應(yīng)鏈安全為何重要432022加速DevOps狀態(tài)報告的以更好地了解企業(yè)目前在識別和解決其構(gòu)建的軟件中的安全漏洞方面所做的工作。今年的分為兩類。?要求受訪者同意或不同意某項聲明的問題(例如。"我的組織有一個有效的方法來可以使用必要的工具來執(zhí)行安全測試")。?問及受訪者如何確立或未確立的安全實踐的情況(例如，"構(gòu)建是通過構(gòu)建腳本定試發(fā)現(xiàn)受訪者偏向于同意一些與安全相關(guān)的問題。而關(guān)于SSDF的問題則更自然地了AF了SSDF結(jié)。04供應(yīng)鏈安全為何重要44SLSA實踐集中式CI/CDCICD建的。絕不是在開發(fā)人員的工作站上歷史記錄保留修訂和他們的修改歷史被無限期地保存下來構(gòu)建腳本構(gòu)建是通過構(gòu)建腳本完全定義的，而不是其他任何東西構(gòu)建文本文件構(gòu)建定義和配置被定義在文本文件中，存儲在版本控制系統(tǒng)中。參數(shù)元數(shù)據(jù)構(gòu)建元數(shù)據(jù)(例如，依賴性、構(gòu)建過程、構(gòu)建環(huán)境)關(guān)于一個工件的元數(shù)據(jù)包括所有的構(gòu)建參數(shù)依賴元數(shù)據(jù)構(gòu)建元數(shù)據(jù)(例如，依賴性、構(gòu)建過程、構(gòu)建環(huán)境)關(guān)于一個工件的元數(shù)據(jù)包括所有的構(gòu)建參數(shù)元數(shù)據(jù)生成構(gòu)建元數(shù)據(jù)(如依賴關(guān)系、構(gòu)建過程、構(gòu)建環(huán)境)要么是由構(gòu)建服務(wù)避免輸入動態(tài)的(即所有需要的源和依賴都是預(yù)先獲取的)。有編輯構(gòu)建元數(shù)據(jù)(例如：依賴性、構(gòu)建過程、構(gòu)建環(huán)境)關(guān)于工件的元數(shù)據(jù)元數(shù)據(jù)可用構(gòu)建元數(shù)據(jù)(例如：依賴關(guān)系、構(gòu)建過程、構(gòu)建環(huán)境)對需要它的人來說是可用的(例如通過中央數(shù)據(jù)庫)，并以他們接受的同事審閱格式交付修訂歷史中的每一個變更都必須由兩個可信的人單獨審查和批準(zhǔn)。在提交之前，必須由兩個可信的人批準(zhǔn)元數(shù)據(jù)簽名構(gòu)建元數(shù)據(jù)(例如，依賴性、構(gòu)建過程、構(gòu)建環(huán)境)關(guān)于一個工件是如何產(chǎn)生的，由我的構(gòu)建服務(wù)簽署表1.與SLSA相關(guān)的調(diào)查問題04供應(yīng)鏈安全為何重要45SSDF實踐安全評審對我所負(fù)責(zé)的應(yīng)用程序的所有主要功能都進(jìn)行了安全審查持續(xù)代碼分析/測試全測試有效地應(yīng)對威脅我的組織有一個有效的方法來應(yīng)對安全威脅團(tuán)隊整合安全角色被整合到我們的軟件開發(fā)團(tuán)隊中文檔化需求記錄軟件的所有安全要求(包括第三方和開放源碼)。定期審查要求定期審查安全要求(每年一次，如有需要可提前)。產(chǎn)元數(shù)據(jù)如，依賴性、構(gòu)建過程、構(gòu)建環(huán)境)由構(gòu)建服務(wù)或構(gòu)建元數(shù)據(jù)生成，或由讀取構(gòu)建服務(wù)的構(gòu)建元數(shù)據(jù)生成器生過程集成在我的公司，軟件安全協(xié)議被無縫地嵌入到我們的開發(fā)過程中。橫跨項目的標(biāo)準(zhǔn)流程監(jiān)控安全報告能存在的漏洞。有必要的軟件我可以使用必要的工具來執(zhí)行安全測試表2.與SSDF相關(guān)的調(diào)查問題答：非常不同意、不同意。04供應(yīng)鏈安全為何重要462022加速DevOps狀態(tài)報告納者對我們安全問題的回答。我們發(fā)現(xiàn)，使用持續(xù)集成/持續(xù)交付(CI/CD)系統(tǒng)進(jìn)行生產(chǎn)發(fā)布是最常見的做法，63%的CI作為供應(yīng)鏈安全的中央集成點。我們的模型分析(在下一節(jié)中組織就很難確保針對他們創(chuàng)建的軟件制品運行一套一致的掃描器、靜態(tài)分析工具(linters)和測試。除了CI/CD，其他普遍建立的實踐包括無限期保存代碼歷史記錄(60%)，完全通過腳本定義的構(gòu)建(58%)，保持構(gòu)建之間的隔離(57%)，以及在源代碼控制中存儲構(gòu)建定義(56%)。更差一些的，兩個最不常見的做法是要求兩個或更多的審查員來批準(zhǔn)每個代碼變更(45%)和簽署構(gòu)建元數(shù)據(jù)以防止/檢測篡改(41%)。04供應(yīng)鏈安全為何重要472022加速DevOps狀態(tài)報告聲明。同意程度最高的說法是81%的受訪者同意"我們正在努力監(jiān)測來自公共來源的同意："我公司現(xiàn)有的軟件安全盡的)影響。04供應(yīng)鏈安全為何重要482022加速DevOps狀態(tài)報告受訪者的百分比圖1.建立SLSA的做法A04供應(yīng)鏈安全為何重要492022加速DevOps狀態(tài)報告受訪者的百分比圖2.建立SSDF的實踐關(guān)于建立SSDF實踐的調(diào)查回復(fù)。與SLSA類似，大多數(shù)受訪者認(rèn)為他們的組織遵循了所有這些做法。502022加速DevOps狀態(tài)報告于公司遵循良好的安全實踐？應(yīng)用安全只是軟件開發(fā)的一個方面，因此也是對開發(fā)人員的時間和注意力的許多競爭性需于的過我的代碼。我和大多數(shù)工程師一樣，我通常會避開他們"。改善軟件安全的方法之一是減少遵循安全實踐的障礙。與我們交談過的開發(fā)人員希望做正查數(shù)據(jù)表明，有幾個因素使開發(fā)者更容易"做安全的事"。特征以多種方式表現(xiàn)在更健康的安全實踐中，例如鼓勵軟件工程師對供應(yīng)鏈安全更加積極主的感知風(fēng)險。的回答尺度有可能偏向于"同意"的回答，這可以解釋這種差異。進(jìn)行，那么你的工程師就更有可能使512022加速DevOps狀態(tài)報告的SLSA實踐有關(guān)，這可能是安全問題得到開發(fā)者關(guān)注的時候，一個單獨的調(diào)查發(fā)現(xiàn)的關(guān)鍵系而源碼控制的缺乏反過來又使得首先擁有一個集中的構(gòu)建系統(tǒng)成為一種挑戰(zhàn)。訴我們在他們的開發(fā)工作站上進(jìn)行安全掃描將有助于節(jié)省時間和精力。通常會提到兩種情況：1)希望提前知道他們是否在一個具有已知漏洞的依賴項上構(gòu)建，這樣他們就可以在構(gòu)建然CI的"后援"是必要的，但在本地運行相同的安全工具的能力將幫助他們更快更有效地上面討論的文化和技術(shù)因素是安全的最大驅(qū)動因素，但不是唯一的驅(qū)動因素。其他值得注意的因素包括?工作安排的靈活性(例如，組織是否支持在家工作？)?云的使用(公有或私有)。?感覺到企業(yè)重視并投資于你的團(tuán)隊?團(tuán)隊的低流動率然而，這些因素似乎大多與Westrum文化(例如，靈活的工作安排，感覺自己受到組織的大型組織工作)相關(guān)。這些數(shù)據(jù)使我們相信，組織文化和現(xiàn)代開發(fā)流程(如持續(xù)集成)是一安全態(tài)勢的組織的最佳起點。522022加速DevOps狀態(tài)報告的幾率會降低。同樣，我們在2022年上半年進(jìn)行了單獨的研究，發(fā)現(xiàn)在CI期間運行漏洞掃依賴項中的漏洞的可能性：使用此類工具的受訪者報告在自己的代碼或其中一個依賴項中識別安全漏洞的可能性幾乎是其他受訪者的兩倍。簡而言。影響，而當(dāng)CI被牢固確立后，可視化。532022加速DevOps狀態(tài)報告?zhèn)儼l(fā)增加開發(fā)人員愉悅的機制。DF幫助他們將安全實踐納入現(xiàn)有的開發(fā)工作流程的工具增加開發(fā)人員05意外發(fā)現(xiàn)542022加速DevOps狀態(tài)報告05意外發(fā)現(xiàn)雖然每年的DevOps狀態(tài)報告都聚焦于當(dāng)年的調(diào)查結(jié)果，但我們盡最大可能將一系列的DevOps狀態(tài)報告和相關(guān)研究(如：對職業(yè)倦怠和文化的研究)作為上下文去解讀我們的調(diào)。下的那一年，可能已經(jīng)改變了DevOps的根基。最后，對模型中涵蓋的內(nèi)容的細(xì)微調(diào)整，可能也會改變各個變量之間的關(guān)系[1]。[1]JudeaPearl的《BookofWhy》和RobertMcElreath的明了你在統(tǒng)計模型中做什么和不05意外發(fā)現(xiàn)552022加速DevOps狀態(tài)報告的真實性存疑，或至少尚未匹配多項研究的實驗證據(jù)(甚至是矛盾的)，因此負(fù)責(zé)任的做法是繼續(xù)開展后續(xù)研究，試圖重現(xiàn)結(jié)果并剖析其原因[2]。一直有觀察到，主干開發(fā)的實踐對軟件交一直有觀察到，主干開發(fā)的實踐對軟件交年以來，在每年的研究過程中我們都能看件交付效率帶來了負(fù)面影響，這與過往研效能對組織績效會起到正面運維效能并不高。這與過往的研究結(jié)果相付效能和組織績效的關(guān)系是很明確的。究報告中的結(jié)論相反?？紤]到這一結(jié)果是如此的反常，我們迫切希望了解是否能夠在未來的研究中重現(xiàn)該結(jié)果，同時聆聽社ical05影響。一種解釋是，兩者之間不一定有因果關(guān)系。今年，我們在一項新的聚類分析 05影響。一種解釋是，兩者之間不一定有因果關(guān)系。今年，我們在一項新的聚類分析 分子集聚焦于可靠性卻忽視了軟件交付效能。我們相信兩者是解耦的，從某種程度使軟件交付效能對組織績效提升起到正面可靠性工程對軟件交付效能產(chǎn)生了不利的2022加速DevOps狀態(tài)報告結(jié)論不符。一種假設(shè)尤其是在高效能的團(tuán)隊中更是如此。在收集到更多數(shù)據(jù)之前，我們還沒有什么證據(jù)能夠支持或駁斥這一觀點。構(gòu)、CI、CD)看起來可以預(yù)測職業(yè)倦怠 收集的樣本中，許多受訪者的職業(yè)生涯起我們可能更多的與負(fù)責(zé)實現(xiàn)技術(shù)能力的人群進(jìn)行了訪談，而非負(fù)責(zé)創(chuàng)建計劃和監(jiān)督實施的人群。技術(shù)實現(xiàn)的過程可能比監(jiān)督更具挑戰(zhàn)性，我們希望能夠投入進(jìn)一步的0方法來維護(hù)安全的軟現(xiàn)和效能(例如，使用技術(shù)能力、更好的軟件交付效能和更好的組織績效)之間有實際上就是技術(shù)能力影響軟件交付效能和組織績效的機制。05意外發(fā)現(xiàn)572022加速DevOps狀態(tài)報告SLSA付效能和組織績解釋這些新的模式，或者，我們是否傾向于將其視為異常值(我們?nèi)匀恍枰獓L試解釋)。一如既往的，我們歡迎來自社加入DORACommunity(munity)來繼續(xù)探討這些意外發(fā)582022加速DevOps狀態(tài)報告06個人和企業(yè)統(tǒng)計概況感謝您對我們的研究和著高度的一致性。受訪者592022加速DevOps狀態(tài)報告統(tǒng)計數(shù)據(jù)別受訪者比例較高(今年為18%，2021年為12%)。男性受訪者的比例(76%)低于2021年(83%)。據(jù)(25%)相同。殘障情況我們根據(jù)“聯(lián)合國華盛頓小組殘人士的比例與我們2021年的報勢群體從屬情況受訪者是否屬于弱勢群體可以從年是我們了解弱勢群體信息的第06個人和企業(yè)統(tǒng)計概況602022加速DevOps狀態(tài)報告從業(yè)經(jīng)驗)的一小部分。從業(yè)經(jīng)驗06個人和企業(yè)統(tǒng)計概況612022加速DevOps狀態(tài)報告統(tǒng)計數(shù)據(jù)門85%的受訪者工作于開發(fā)或工程團(tuán)隊(19%)，或擔(dān)任經(jīng)理(17%)。IT受訪者比例(19%)較去年(9%)增加了1倍多。首席級別高管的比例(2021為9%，今年下降至4%)和顧問的比例(2021年為4%，今年下降至1%)較去年下業(yè)我們觀察到大多數(shù)受訪者在技06個人和企業(yè)統(tǒng)計概況622022加速DevOps狀態(tài)報告區(qū)06個人和企業(yè)統(tǒng)計概況632022加速DevOps狀態(tài)報告雇雇員規(guī)模人組織的受訪者(15%)、以及工作于20–99人組織的受訪者(15%)。今年，我們還允許06個人和企業(yè)統(tǒng)計概況642022加速DevOps狀態(tài)報告團(tuán)06個人和企業(yè)統(tǒng)計概況652022加速DevOps狀態(tài)報告署目標(biāo)07總結(jié)662022加速DevOps狀態(tài)報告07總結(jié)ps交付和運維效能的新方法。應(yīng)：工作場所文化和靈活性導(dǎo)致更好的組織績效；08致謝672022加速DevOps狀態(tài)報告08致謝告的投入和指導(dǎo)。以下的致謝是按字母順序列出的。09作者簡介6809作者簡介ClairePetersClairePeters是谷歌的用戶體驗研究員。她的研究包括elicationModernizationProgram 擁有哥本哈根大學(xué)應(yīng)用文化分析碩士學(xué)位。DaveFarleyDoingWhatWorkstoBuildBetterSoftwareFaste》源LMAXDisruptor項目杜克獎(DukeAward)的獲得者。Dave是ContinuousDelivery的先驅(qū)，CD、DevOps、TDD和軟件設(shè)計領(lǐng)域的思想領(lǐng)袖和專家實踐2022加速DevOps狀態(tài)報告建出色的軟件方面有著悠久的記錄。在他的twitter、2022加速DevOps狀態(tài)報告09作者簡介692022加速DevOps狀態(tài)報告DaniellaVillalba入懺DaveStanke創(chuàng)公司首席技術(shù)官、產(chǎn)品經(jīng)理、擁有哥倫比亞大學(xué)技術(shù)管理碩士學(xué)位。DerekDeBellis。09作者簡介702022加速DevOps狀態(tài)報告EricMaxwellplicationModernizationrogram JohnSpeedMeyersJohnSpeedMeyers是Chainguard的安全數(shù)據(jù)科學(xué)的戰(zhàn)略和預(yù)算評估中心工作過。John擁有PardeeRAND務(wù)學(xué)士學(xué)位。Kaiyuan“Frank”Xu和用戶反饋，提高開發(fā)人員的產(chǎn)品卓越性。在谷歌之前，Kaiyuan在微軟對Azure和PowerPlatform產(chǎn)品進(jìn)行了多年的定性和定量用戶研究。他在華盛頓大學(xué)獲得了09作者簡介712022加速DevOps狀態(tài)報告NathenHarveyNathenHarvey是谷歌的開發(fā)人員關(guān)系工程師，他的職持一致。Nathen有幸與一些最好的團(tuán)隊和開源社區(qū)合共同編輯并貢獻(xiàn)了《97ThingsEveryCloudEngineerShouldKnow》(O’Reilly2020)。ToddKulesza博士學(xué)位。09作者簡介722022加速DevOps狀態(tài)報告譯者簡介朱少民科技進(jìn)步獎，術(shù)會議程序委員、思科(中國)軟件有限公司QA高級總監(jiān)等。茹炳晟權(quán)威指南》等書籍，國內(nèi)外各大技術(shù)峰會的聯(lián)席主席，出品人和吳駿龍訊云最具價值專家TVP。極客時間《容量保障核心技術(shù)與在軟件質(zhì)量體系、服務(wù)容量保障、服務(wù)穩(wěn)定性建設(shè)、軟件研發(fā)效能等領(lǐng)域深耕多年，善于通過創(chuàng)新手段解決質(zhì)量和效能難題，擁有多項國內(nèi)外09作者簡介732022加速DevOps狀態(tài)報告顧黃亮互聯(lián)網(wǎng)數(shù)據(jù)中心產(chǎn)業(yè)技術(shù)創(chuàng)新戰(zhàn)略聯(lián)盟(NIISA)智庫專家委員會副主任最有價值專家MVP，《研發(fā)運營一體化(DEVOPS)能力成熟度模型》IT致力于企業(yè)智慧運維體系的打造。王永雷聘專家，開源社成員s理專家，為大中華區(qū)的企業(yè)客戶提供企業(yè)級的軟件安全和開源合規(guī)治理解決方案。專注于企業(yè)級的開源軟件治理最佳實踐方案研究參與中國信通院開源治理工具能力評估標(biāo)準(zhǔn)的起草和制定參與中國信通院開源成熟度評估標(biāo)準(zhǔn)起草和制定李威JFrog中國解決方案架構(gòu)師及運維經(jīng)驗，帶領(lǐng)團(tuán)隊從零到一實踐DevOps轉(zhuǎn)型。現(xiàn)就職于JFrog寫《軟件研發(fā)效能權(quán)威指南》09作者簡介742022加速DevOps狀態(tài)報告張樂前百度工程效率專家、前京東DevOps平臺產(chǎn)品總監(jiān)與首席架構(gòu)長期在擁有數(shù)萬人研發(fā)規(guī)模的一線互聯(lián)網(wǎng)公司，負(fù)責(zé)研發(fā)效