天天看點

Google 釋出:DevOps 2022現狀報告保護軟體供應鍊2022 新發現

在過去的八年中,全球超過 33,000 名專業人士參與了Accelerate State of DevOps 調查,使其成為同類研究中規模最大、運作時間最長的一項。Accelerate State of DevOps 報告提供了資料驅動的行業洞察力,這些洞察力檢查了推動軟體傳遞以及營運和企業績效的能力和實踐。

在2021 年,有超過220億條記錄因資料洩露事件而暴露,數家大公司也是以遭受巨大影響和損失。是以,安全性仍然是企業的首要考慮因素,同時企業也緻力于確定客戶資料的安全以及他們的業務正常運作。

綜合考慮到資訊安全現狀,Google Cloud 的 DevOps 研究和評估 ( DORA ) 團隊在9月28日釋出的 2022 Accelerate State of DevOps Report(文末檢視擷取報告方式)中着重關注安全問題。

保護軟體供應鍊

為了分析安全與 DevOps 之間的關系,報告中探讨了軟體供應鍊安全這一主題,該主題在前幾年的調查中隻涉及到了一小部分。DORA 團隊使用了 Google 定義的 SLSA架構和美國國家标準研究院(NIST)的安全軟體開發架構(SSDF)的供應鍊級别來評估組織,綜合這兩個架構能夠探索影響組織如何實施和思考軟體安全實踐的技術和非技術方面。

總體來說,報告發現新興安全實踐的廣泛采用超乎預期。在 SLSA 和 NIST 的 SSDF 推廣的所有實踐中,使用應用程式級安全掃描作為生産釋出的持續內建/持續傳遞 (CI/CD) 系統的一部分是最常見的做法,63% 的受訪者表示這是“非常”或“完全”成立。此外,儲存代碼曆史和使用建構腳本也很成熟,而簽署中繼資料(metadata)和需要兩個人的審查過程還有很大的增長空間。

Google 釋出:DevOps 2022現狀報告保護軟體供應鍊2022 新發現

報告指出,企業在實作應用程式安全方面面臨的最大挑戰更多地與文化有關,即高信任、低責備的文化(high-trust, low-blame culture),而不是任何技術缺陷。與注重權力或規則的低信任、高責備文化相比,注重績效的人更有可能采用新興的安全實踐。該報告指出,專注于加速軟體傳遞而不實施有意義的 DevSecOps 最佳實踐的企業發現自己處于一個适得其反的惡性循環,導緻應用程式在生産環境中成功部署的頻率降低。

不僅如此,報告結果表明,專注于建立有意義的安全實踐的團隊減少了開發人員的倦怠。為此,資料表明企業文化和現代開發流程(例如持續內建)是企業軟體安全的最大驅動力,同時也是企業尋求改善其安全狀況的最佳起點。

2022 新發現

今年 DORA 團隊持續關注和探索軟體傳遞和營運表現。在報告中,将使用四個關鍵名額對 DevOps 團隊進行分類:部署頻率(deployment frequency)、變更前置時間(lead time for changes)、平均恢複時間(time to restore service)和變更失敗率(change failure rate),以及 DORA 團隊去年引入的第五個名額,可靠性(reliability)。

軟體傳遞表現

從這幾個名額來看,受訪者分為三類——高、中和低。在軟體傳遞表現方面,今年的高績效人員(high performer)群體融合了去年的高績效人員和精英績效人員(Elite)群體。

Google 釋出:DevOps 2022現狀報告保護軟體供應鍊2022 新發現

今年報告基于對1350名 DevOps 專業人士的調查。如下面圖表中的百分比細分所示,高績效人員(high performer)處于四年低點,低績效人員(low performer)從 2021 年的 7% 急劇上升到 2022 年的 19%。然而,中績效人員(medium performer)群體擴大到 69% 。也就是說,如果将今年的低、中和高群組與去年進行比較,就可以發現,總體上軟體傳遞性能向略高的方向轉變。今年的高績效人員表現更好——他們的表現融合了去年的高績效和精英(elite)群體。相較而言,低績效人員的表現也比去年好,因為今年的低績效人員是去年低績效和中等績效的集合。

DORA 團隊計劃進行進一步的研究,以幫助使用者更好地了解這一轉變,但就目前而言,持續發展的疫情可能會阻礙團隊分享知識、協作和創新的能力,進而導緻高績效者和表現不佳者的數量增加。

Google 釋出:DevOps 2022現狀報告保護軟體供應鍊2022 新發現

營運表現

就 DevOps 而言,軟體傳遞表現并不是全部,它還可以對企業的整體營運情況做出貢獻。為了更深入地研究,DORA 團隊對五個名額旨在代表的三個類别進行了群組分析:吞吐量(throughout)——代碼更改的前置時間和部署頻率的組合)、穩定性(stability)——恢複服務的時間和更改失敗率的組合和運作性能(operational performance)——可靠性。

通過資料分析,出現了四種不同類型的 DevOps 組織,這些群組在實踐和技術能力上存在顯着差異,是以進一步細分為以下四類:

  • Starting:這個群組在任何次元上都表現得既不好也不差。該群組可能處于其産品、功能或服務開發的早期階段。由于這個群體的人員更加專注于獲得回報,了解産品的市場契合度或者産品相關的延伸和探索,是以他們并不是太關注可靠性。
  • Flowing:這個群組在所有特性上都表現良好:高可靠性、高穩定性、高吞吐量。通過調研發現,隻有 17% 的受訪者能夠達到這種狀态。
  • Slowing:在這個群組中,受訪者部署頻率并不高,但是當他們準備開始部署時,部署成功的機率很大。在受訪者中,有1/3都屬于這個群組,這個群組也成為樣本中最具代表性的群組。盡管這個群組中的部分企業正在努力逐漸改進,但這些企業及其客戶對目前的應用程式和産品狀态還是非常滿意的。
  • Retiring:這個群組的狀态處于,正在開發一些對于他們和他們的客戶仍然有價值,但不再處于積極開發中的服務或應用程式。

繼續閱讀