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