加速發展：2021 年開發運作現狀

Google Cloud 開發運作研究與評估 (DORA) 團隊在今年的《加速發展：開發運作現狀》報告中，呈現了歷時七年的研究成果，以及全球超過 32,000 名專業人士提供的資料。

我們的研究探討了有助於提升軟體推送、運作和機構成效的能力和做法。 我們採用嚴格的統計方法，試圖瞭解哪些做法有助於創造卓越的技術推送成效，以及豐碩的業務成果。 針對這個目標，我們提供了以資料為依據的深入分析資訊，說明何種技術開發及推送方式最有效率且成效最好。

我們的研究持續顯示，在軟體推送和運作方面表現卓越，也有助於機構提升技術轉型方面的成效。 為方便以整個業界為基準評估團隊，我們採用了集群分析法來劃分具有實質意義的成效類別 (例如低、中、高或卓越成效團隊)。 當您的團隊大致瞭解自己在業界中的相對成效表現後，就可以根據我們預測性分析所發現的結果，針對實際做法和能力改善關鍵成果，最後晉升到更高的成效類別。 今年我們特別強調的重要做法包括：達成可靠性目標、在整個軟體供應鏈中整合安全性、製作優質內部技術文件，以及充分運用雲端發揮最大潛能。 此外，COVID-19 疫情導致企業紛紛開始採用遠距工作模式，因此我們也探討了積極正向的團隊文化是否有助於減輕這方面的影響。

為了達成具有實質意義的改善成果，團隊必須秉持不斷向上提升的理念。 您可以使用基準來評估目前的狀態、根據研究中所調查的能力來找出限制，並嘗試各種改善措施，藉此排除這些限制。 嘗試可能會成功，但失敗也在所難免，無論結果如何，團隊都可以從中汲取經驗，並據此採取具有實效的行動。

卓越成效團隊的數量持續增加，且不斷提高標準。

在我們的研究中，卓越成效團隊目前占所有團隊 26%，而且他們變更實際工作環境的前置時間也縮短了。產業持續加速發展，而團隊也因此實質受惠。

SRE 和開發運作是相輔相成的理念。

如果運用我們的網站可靠性工程 (SRE) 夥伴所建議的現代化運作做法，團隊的運作成效通常比較高。優先追求卓越的推送和運作表現的團隊，機構成效也最高。

愈來愈多團隊採用雲端技術，並從中獲得重大優勢。

團隊持續將工作負載遷移至雲端，而完整運用雲端五大能力的團隊，軟體推送和運作 (SDO) 成效，以及機構成效均獲得提升， 採用多雲端的做法也呈現增加趨勢，這樣團隊就能充分運用每個供應商的獨特優勢。

安全的軟體供應鏈不但是必備要件，更有助於提升成效。

由於近年來惡意攻擊數量顯著增加，機構不能再被動因應，而必須主動採取診斷措施。 在整個軟體供應鏈中整合安全做法的團隊，可以快速、可靠且安全地推送軟體。

高品質的技術文件是成功導入開發運作能力的基礎。

我們首次針對內部技術文件的品質，以及有助於提高這類品質的做法進行評估。 具備高品質文件的團隊不但能更順利導入技術做法，整體成效也更理想。

正向積極的團隊文化有助於在艱困時期減少工作疲乏現象。

團隊文化對於團隊推送軟體的能力，以及達成或超越機構目標的能力，均具有重大的影響。在 COVID-19 疫情期間，具有創造型^1,2文化的包容性團隊較不容易出現疲乏現象。

____________________________

1. 根據 Westrum 的機構文化分類學，創造型團隊文化指的是能密切合作、突破溝通藩籬、失敗後積極找出原因，並能共同承擔決策風險的團隊。

2. Westrum, R. (2004 年)。《A typology of organizational cultures》(機構文化分類學)。BMJ Quality & Safety，13(suppl 2)，ii22-ii27。

我們將檢視團隊如何開發、推送和運作軟體系統，然後將作答者劃分為四個成效群集：卓越、高、中、低成效。 針對這份報告詳列的各項調查結果，只要將您團隊的成效與每個群集的成效比較，就能瞭解團隊的表現。

軟體推送和運作成效

為了因應不斷變化的產業需求，機構必須快速可靠地推送及運作軟體。 您的團隊愈快完成軟體修改，就能愈快為客戶提供價值、進行實驗，並獲得寶貴的回饋意見。 我們花費七年時間收集資料、進行研究，據此制定出用於評估軟體推送成效的四項指標，並完成驗證。 自 2018 年起，我們納入了第五項指標來涵蓋運作能力。

所有五項指標皆表現出色的團隊也展現出卓越的機構成效。 我們將這五項評估標準稱為軟體推送和運作 (SDO) 成效。請注意，這些指標著重於系統層級的表現，因此有助於避免軟體指標常見的陷阱，例如導致功能相互競爭，以及為達到局部最佳化而犧牲整體成果。

軟體推送成效的四項指標可用來檢驗處理量和穩定性。 我們採用程式碼變更的前置時間 (也就是從程式碼提交到投入實際工作環境所需時間) 和部署頻率來評估處理量，而穩定性的評估依據則是發生事件後還原服務所需時間和變更失敗率。

根據四項軟體推送指標的集群分析結果，可以得出四個不同的成效等級：卓越、高、中、低。個別等級的處理量和穩定性衡量標準，以統計學的角度來看存在顯著差異。和往年一樣，成效卓越的團隊在四項指標中都大幅領先其他團隊，而低成效團隊在所有項目的表現都明顯較差。

第五項指標代表運作成效，並且是現代化運作做法的評估標準。運作成效的主要指標是可靠性，代表團隊能否實現承諾及聲明，為他們運作的軟體提供相應的服務水準。以往我們評估的是可用性而不是可靠性，但由於可用性是可靠性工程的一個明確重點，我們已經將可靠性納入評估標準，以便更充分反映可用性、延遲、效能和擴充性。 具體來說，我們要求作答者評量他們達成或超越可靠性目標的能力。 我們發現，推送成效高低不同的團隊如能一併優先考慮運作成效，結果也較為理想。

和先前的報告一樣，我們將卓越成效團隊和低成效團隊比較，藉此呈現特定能力的影響力。 不過，今年我們想特別說明運作成效的影響力。 在所有推送成效類別 (從成效低落到成效卓越) 當中，我們看到將達成或超越可靠性目標視為優先任務的團隊，在多項結果中獲得重大優勢。

我們每年一再看到產業進化，並加速發展軟體推送能力，不僅推送速度更快，可靠性也更高。 高成效和卓越成效團隊首次占作答者的三分之二。 此外，相較於先前的評估結果，今年卓越成效團隊再次將標準提高，進一步縮短變更的前置時間 (從 2019 年的不到 1 天進步到 2021 年的不到 1 小時)。 不僅如此，有別於往年，我們也首次看到只有卓越成效團隊將變更失敗率降至最低。在先前的調查中，中等成效和高成效團隊也同樣能做到。

處理量

部署頻率

與往年一致，卓越成效團隊表示，會例行視需求部署，每日部署多次。相較之下，低成效團隊的部署頻率每六個月不到 1 次 (每年不到 2 次)，相較於 2019 年的調查，成效再度下滑。 正規化的年度部署次數介於最高成效團隊的每年 1,460 次 (以每天 4 次部署 x 365 天計算)，到低成效團隊的每年 1.5 次 (2 次部署和 1 次部署的平均值) 之間。 據這項分析的估計，卓越成效團隊部署程式碼的頻率是低成效團隊的 973 倍。

變更的前置時間

卓越成效團隊的變更前置時間低於 1 小時，表現優於 2019 年。變更的前置時間指的是從程式碼提交，到成功部署在實際工作環境中所需的時間。 最高成效團隊在 2019 年的變更前置時間為不到 1 天，相較之下，表現已有明顯進步。 對比卓越成效團隊，低成效團隊需要超過 6 個月的前置時間。 卓越成效團隊的前置時間為 1 小時 (「不到 1 小時」的保守估計)，低成效團隊為 6,570 小時 (以每年 8,760 小時和 6 個月內 4,380 小時的平均值計算)，卓越成效團隊的變更前置時間比低成效團隊快 6,570 倍。

穩定性

還原服務所需時間

成效卓越團隊的服務復原時間不到 1 小時，而低成效團隊則為 6 個月以上。 針對這項計算，我們選擇保守的時間範圍：成效卓越團隊為 1 小時，低成效團隊則為 1 年 (8,760 小時) 和 6 個月 (4,380 小時) 的平均數。 根據這些數據，卓越成效團隊服務復原時間比低成效團隊快 6,570 倍。 相較於 2019 年，卓越成效團隊的服務復原時間維持相同，但低成效團隊則有增加。

變更失敗率

卓越成效團隊的變更失敗率介於 0%–15% 之間，而低成效團隊的變更失敗率則介於 16%–30% 之間。 為這兩個範圍取平均數，卓越成效團隊的變更失敗率為 7.5%，低成效團隊則為 23%。 卓越成效團隊的變更失敗率優於低成效團隊達三倍之多。 相較於 2019 年，今年卓越成效團隊的變更失敗率維持相同，而低成效團隊則有改善，但兩者以外的團隊則顯得較差。

將卓越成效團隊與低成效團隊比較，我們發現卓越成效團隊：

• 程式碼部署頻率提高 973 倍
• 從程式碼提交到進行部署所需的前置時間加快 6570 倍
• 變更失敗率降低 3 倍 (變更失敗的可能性為低成效團隊的 1/3)
• 事故後復原時間加快 6570 倍

我們該如何改善 SDO 和機構成效？ 我們的研究提供以實證為依據的指南，協助您全力發展有助於提高成效的能力。

今年的報告檢視了雲端、SRE 做法、安全性、技術做法以及團隊文化等方面的影響。 在本章節中，我們會逐一介紹這些能力，並說明每個能力對於各種成果的影響。 針對熟悉 DORA 開發運作現狀研究模型的使用者，我們製作了一項線上資源，提供今年和以往使用的所有模型³。

^{____________________________}

3. https://devops-research.com/models.htm

____________________________

和《加速發展：2019 年開發運作現狀》的結果一致，愈來愈多機構選擇多雲端和混合雲解決方案。在我們的問卷調查中，有一項問題是作答者主要的服務或應用程式託管於何處，結果顯示公有雲的使用率有升高的趨勢。 56% 的作答者表示使用公有雲 (包括多個公有雲)，較 2019 年增加了 5%。 今年我們同樣特別詢問多雲端使用情形，21% 的作答者表示已部署到多個公有雲。21% 的作答者表示未使用雲端，而是使用資料中心或地端部署解決方案。 最後，34% 的作答者表示使用混合雲，29% 表示使用私有雲。

藉由混合雲或多雲端加速達成業務目標

今年我們看到混合雲和多雲端的使用率均有成長，對於企業關切的成果具有重大影響。相較於未使用雲端的作答者，使用混合雲或多雲端的作答者超越機構成效目標的可能性為 1.6 倍。我們也看到 SDO 產生強大效應，混合雲和多雲端使用者在部署頻率、變更的前置時間、復原時間、變更失敗率，以及可靠性等方面獲得優異成效的可能性為 1.4 倍。

採用多雲端的理由

類似我們 2018 年的調查，我們詢問作答者選用多個公有雲供應商的理由， 只不過今年作答者只須說明選用多個供應商的主要理由，而非選擇所有適用答案。 超過四分之一 (26%) 的作答者表示，採用這種方式是為了充分運用每個雲端供應商的獨特優勢。 這意味著，當作答者多選擇一個供應商時，可能是看上該供應商具備現有供應商所沒有的優點。 遷移至多雲端第二常見的理由是可用性考量 (22%)。一如預期，採用多個雲端供應商的作答者達成或超越可靠性目標的可能性為 1.5 倍。

選用多個供應商的主要原因

基準異動

導入雲端基礎架構的方式至關重要

以往我們發現，每個作答者採用雲端的方式不盡相同。 因此，運用雲端協助達成業務目標的效益也有所落差。 我們探討了雲端運算的必備要素 (根據美國國家標準暨技術研究院 (NIST) 的定義)，希望藉此瞭解造成這些落差的因素，並以此為指導方針。我們根據 NIST 的雲端運算定義，調查了必要做法對於 SDO 成效的影響，而不單只是調查雲端採用情形對於 SDO 的影響。

結果是，我們已連續三次發現，同樣都是使用雲端技術，但真正造成差異的是團隊導入雲端服務的方式。 卓越成效團隊符合 NIST 所有雲端必備要素的可能性為 3.5 倍。 使用雲端基礎架構的作答者當中，只有 32% 表示同意或非常同意他們已符合所有五項 NIST 定義的雲端運算必備要素，較 2019 年增加了 3%。 整體而言，NIST 定義的雲端運算要素採用率已增加 14%–19%，其中以機動彈性增幅最大。

隨選自助式服務

消費者可以視需求自動佈建運算資源，不必和供應商的人員進行任何互動。

73% 的作答者使用隨選自助式服務，較 2019 年增加了 16%

多元的網路存取方式

功能全面開放給團隊成員使用，並可透過多種用戶端存取，例如手機、平板電腦、筆記型電腦和工作站。

74% 的作答者採用了多元的網路存取方式，較 2019 年增加 14%

資源集區

使用多用戶群模型匯集供應商資源，並且視需求動態指派及重新指派實體和虛擬資源。客戶通常無法直接控制這些資源的確切位置，但可以在較高抽象層指定國家/地區、州/省或資料中心等位置。

73% 的作答者採用了資源集區，較 2019 年增加 15%。

機動彈性

可以彈性佈建及釋出處理能力，以便根據需求快速擴充或縮小規模。 可供佈建的消費者處理能力有如無限量供應，並可隨時以任意數量配置。

77% 的作答者導入了機動彈性，較 2019 年增加 18%。

計量服務

雲端系統在與服務類型 (例如儲存、處理、頻寬和有效使用者帳戶) 相應的抽象層使用計量功能，透過這種方式自動控制和最佳化資源使用情形。 資源使用情形可加以監控、控制，並產生報表，讓資訊公開透明。

78% 的作答者使用了計量服務，較 2019 年增加 16%。

隨著開發運作社群開始參與公開會議和對話，Google 內部一群志同道合的員工也紛紛響應，並逐漸興起一股運動：網站穩定性工程 (SRE)。 SRE 和其他類似的做法，如 Facebook 生產工程原則，都提倡許多相同的目標和技術，推動開發運作的發展。 2016 年，我們發布第一本關於網站穩定性工程的著作⁴，讓大眾瞭解 SRE 的概念。自此以後，這項運動便開始蓬勃發展，至今已形成一個全球性 SRE 從業人員社群，讓每個人得以攜手合作推廣技術運作的做法。

但難以避免的，令人困惑的問題也隨之出現。 SRE 和開發運作有何差異？ 我需要兩者擇一嗎？ 哪一種比較好？ 事實上，兩者並不衝突，SRE 和開發運作反而有高度互補性，我們的研究也顯示出這兩種做法的目標一致。 SRE 是一套學習規範，優先考量跨部門通訊和心理安全感，與成效導向的創造型文化核心價值相同，這種文化是卓越成效開發運作團隊的典型特質。 SRE 提供了一些由本身的核心原則延伸出的實用技巧，包括服務水準指標/服務等級目標 (SLI/SLO) 指標架構。 透過精實產品架構，我們可以瞭解如何實現這項研究所支持的快速客戶意見回饋週期；SRE 架構則提供了做法和工具的定義，有助於提高團隊持續履行對用戶承諾的能力。

2021 年，我們擴大了運作的調查範圍，分析對象從服務可用性擴展到更廣泛的可靠性類別。 今年的調查納入了幾個以 SRE 做法為依據的項目，藉此評估團隊以下各方面的表現：

• 根據以使用者為主的行為來定義可靠性
• 運用 SLI/SLO 指標架構，根據錯誤預算來決定工作的優先順序
• 利用自動化來減少人工作業需求以及會干擾工作的警示
• 定義規範和備災演練以利事故應變
• 在整個軟體推送生命週期整合可靠性原則 (「盡早納入可靠性」)

在分析結果時，我們發現有證據表明，在這些現代化運作做法上表現卓越的團隊達到更高 SDO 成效的可能性為 1.4 倍，實現更佳業務成果的可能性為 1.8 倍。

我們的研究發現，絕大多數的團隊均已採用 SRE 做法：雖然各團隊的採用深度有實質差異，但 52% 的作答者表示已在某種程度上使用這些做法。資料顯示，採用這些方法預計可提升可靠性以及整體 SDO 成效：SRE 有助於開發運作邁向成功。

此外，我們也發現如在運作方面採用共同責任模式 (反映出開發人員和運作人員共同獲得多少資源來達成可靠性目標)，有望帶來更理想的可靠性成果。

除了改進成效的客觀評估標準之外，SRE 也提升了技術從業人員的工作體驗。 肩負繁重運作工作的人員往往較容易出現疲乏現象，但 SRE 在這方面具有正面效果。 我們發現團隊採用 SRE 做法的程度愈高，成員出現疲乏現象的可能性就越小。 SRE 可能也有助於資源最佳化：採用 SRE 做法而達成可靠性目標的團隊表示，相較於未實施 SRE 的團隊，他們有更多的時間可編寫程式碼。

我們的研究顯示，從低成效到卓越成效團隊，任何 SDO 成效水準的團隊均可能因增加使用 SRE 做法而受益。團隊表現愈出色，運用現代化運作模式的可能性也愈高：卓越成效團隊採用 SRE 做法的可能性為低成效團隊的 2.1 倍。然而即使是運作成效最高的團隊也有成長空間：只有 10% 的卓越成效作答者指出，他們的團隊已全面導入我們所調查的每一種 SRE 做法。隨著各產業的 SDO 成效不斷提高，每個團隊的運作做法都是一股重要的驅動力，能讓開發運作持續進步、更臻完善。

____________________________

4. Betsy Beyer 等人編輯，《Site Reliability Engineering》(網站穩定性工程) (O’Reilly Media 出版，2016 年)。

____________________________

說明文件

今年我們檢視了內部技術文件的品質。這些文件就是團隊開發的服務和應用程式適用的說明文件，包括使用手冊、README，甚至是程式碼註解等。我們評估技術文件品質的依據如下：

• 技術文件是否能協助讀者達成目標
• 技術文件內容是否正確、即時更新且詳盡
• 技術文件是否容易找到、妥善編排且清楚明瞭⁵

記錄和存取內部系統相關資訊是團隊技術工作的重要環節。 我們發現大約 25% 的作答者具備優質的技術文件，而這項技術文件工作的影響力顯而易見：具備較優質技術文件的團隊達成較理想軟體推送和運作 (SDO) 成效的可能性為 2.4 倍。相較於技術文件品質不佳的團隊，擁有優質技術文件的團隊推送軟體的速度更快，也更可靠。 技術文件不一定要完美無暇。 我們的研究顯示，技術文件品質的任何改善對於成效均有正面且直接的影響。

當今技術環境的系統愈來愈複雜，專家和專業性角色也愈來愈多元，他們分別在這些系統中接掌不同層面的工作。 從安全性到測試工作，技術文件是分享專業知識和指南的重要媒介，讓資訊不只是在這些專業性子團隊之間流通，還能與更龐大的團隊分享。

我們發現，技術文件的品質將影響團隊能否成功導入技術做法。 而這些做法則可望改善系統技術能力，例如觀測能力、持續測試和部署自動化等。 我們發現擁有優質技術文件的團隊：

• 導入安全性做法的可能性為 3.8 倍
• 達成或超越可靠性目標的可能性為 2.4 倍
• 導入網站穩定性工程 (SRE) 做法的可能性為 3.5 倍
• 充分運用雲端技術的可能性為 2.5 倍

如何提升技術文件品質

技術層面的工作涵蓋搜尋及使用資訊，但優質的技術文件有賴人員編寫及維護內容。 我們 2019 年的研究發現，存取內/外部資訊來源的能力是生產力的基石。 今年的研究更深入進行調查，除了檢視團隊技術文件的品質，也分析了可能影響這些文件品質的做法。

我們的研究顯示，下列做法對於技術文件品質具有顯著的正面影響：

記錄產品和服務的重要應用方式。決定哪些系統相關資訊必須記錄在文件中非常重要，而讓讀者瞭解應用方式，資訊和系統就能實際發揮功用。

製作明確的指南，據以更新及編輯現有技術文件。 技術文件相關作業大部分是維護現有內容。 如果團隊成員知道如何更新或移除不正確或過時的資訊，團隊就能確保技術文件品質，即使系統隨著時間不斷變更也不受影響。

定義權責人員。擁有優質技術文件的團隊較可能明確定義技術文件的擁有權。 擁有權有助於釐清編寫新內容，以及更新或確認現有內容變更的責任歸屬。 擁有優質技術文件的團隊較可能針對所開發的應用程式所有主要功能編寫這類文件，而明確定義擁有權則有助於全面顧及各項細節。

將技術文件納入軟體開發流程中。 已製作技術文件的團隊若能隨著系統變更持續更新內容，其技術文件的品質往往較高。 和測試一樣，製作及維護技術文件的工作也是高成效軟體開發流程不可或缺的一環。

在考核績效及考量升職人選時認可技術文件工作方面的貢獻。表揚機制與整體文件品質密切相關。 編寫和維護技術文件是軟體工程工作的核心環節，獲得應有重視有助於提升文件品質。

其他有助於提升技術文件品質的資源包括：

• 編寫及維護技術文件的相關訓練
• 程式碼範例或不完整技術文件的自動化測試
• 各種指導原則，包括技術文件格式指南，以及如何針對全球讀者編寫文件的指南等

技術文件是成功導入開發運作能力的基礎。 優質的技術文件能讓個別開發運作能力的投資成果倍增，包括安全性、可靠性和充分運用雲端技術等。 只要導入重視優質技術文件的做法，就能獲得更強大的技術能力和更高的 SDO 成效。

____________________________

5. 根據技術文件相關研究歸納出的品質指標，這些研究包括：

— Aghajani, E. 等人 (2019 年)。《Software Documentation Issues Unveiled》(軟體技術文件問題揭密)。 2019 年 IEEE/ACM 第 41 屆國際軟體工程大會論文集，1199-1210。https://doi.org/10.1109/ICSE.2019.00122

— Plösch, R.、Dautovic, A. 和 Saft, M. (2014 年)。《The Value of Software Documentation Quality》(軟體技術文件品質的價值)。 國際優質軟體大會論文集，333-342。https://doi.org/10.1109/QSIC.2014.22

— Zhi, J. 等人 (2015 年)。《Cost benefits and quality of software development documentation: A systematic mapping》(成本效益和軟體開發技術文件品質：系統性對應)。Journal of Systems and Software，99(C)，175-198。https://doi.org/10.1016/j.jss.2014.09.042

____________________________

安全性

[盡早導入] 並全程整合

技術團隊持續加速發展及進化，安全威脅的數量與複雜度也不落人後。 根據 Tenable 2020 年的《Threat Landscape Retrospective Report》(安全威脅概況回顧報告) 中的資料，2020 年有超過 220 億筆機密個人資訊或企業資料外洩⁶。安全性不能事後才檢討，也不能是推送前的最後一個步驟，必須整合至整個軟體開發流程中。

如要安全地推送軟體，安全性做法的革新速度必須超越惡意人士攻擊手法推陳出新的速度。 2020 年 SolarWinds 和 Codecov 軟體供應鏈遭受攻擊，駭客竄改了 SolarWinds 的建構系統和 Codecov 的 bash 上傳工具指令碼⁷，藉此將惡意程式碼暗中嵌入這些公司數千個客戶的基礎架構中。由於這些攻擊的影響層面極為廣泛，業界的因應對策必須由原來的被動防範轉變為主動診斷：軟體團隊應假設他們的系統已經遭入侵，並在供應鏈中建置安全防護措施。

我們發現卓越成效團隊導入安全性做法的表現優異，和先前的報告結果一致。 今年，達成或超越可靠性目標的卓越成效團隊，在自家軟體開發流程中整合安全防護措施的可能性為 2 倍。這表示已加快軟體推送流程，同時維持本身可靠性標準的團隊，已找到方法整合安全性檢查和相關措施，同時兼顧可快速/穩定推送軟體的能力。

除了在推送和運作方面展現高成效以外，在整個開發流程中整合安全防護措施的團隊達成或超越機構目標的可能性為 1.6 倍。重視安全性的開發團隊也因此在業務方面有重大斬獲。

____________________________

6. https://www.tenable.com/cyber-exposure/2020-threat-landscape-retrospective

7. https://www.cybersecuritydive.com/news/codecov-breach-solarwinds-software-supply-chain/598950/

____________________________

正確的做法是什麼

強調安全性的重要並建議團隊將其列為優先考量，雖然乍看不難，但這有別於傳統的資訊安全對策，因此需要調整一下做法。 如要整合安全防護措施、改善軟體推送和運作成效，並提升機構成效，可以採取下列做法：

藉由測試來確保安全性。 將安全性需求測試納入自動化測試流程中，包括一些應使用預先核准程式碼的項目。

將安全性審查整合至每一階段。 將資訊安全性 (InfoSec) 整合至整個軟體推送生命週期的日常工作中。 其中包括成立 InfoSec 團隊，讓該團隊在應用程式的設計和架構規劃階段提供建議、參與軟體試用，並在試用期間提供意見回饋。

安全性審查。 針對所有主要功能進行安全審查。 建構預先核准的程式碼。 要求 InfoSec 團隊建構預先核准且簡單易用的程式庫、套件、工具鏈及流程，讓開發人員和 IT 運作人員在工作中使用。 盡早並頻繁要求 InfoSec 參與。要求 InfoSec 參與應用程式開發的規劃及後續所有階段，方便他們盡早辨識出安全相關弱點，讓團隊有充裕時間可加以修正。

建構預先核准的程式碼。 要求 InfoSec 團隊建構預先核准且簡單易用的程式庫、套件、工具鏈及流程，讓開發人員和 IT 運作人員在工作中使用。

盡早並頻繁要求 InfoSec 參與。要求 InfoSec 參與應用程式開發的規劃及後續所有階段，方便他們盡早辨識出安全相關弱點，讓團隊有充裕時間可加以修正。

如前文所述，高品質技術文件有助於團隊發揮各項能力的效益，安全性也不例外。 我們發現擁有高品質技術文件的團隊，在整個開發流程中整合安全防護措施的可能性為 3.8 倍。 機構中並非所有人員都具備加密技術的專業知識。 在機構中分享這類相關知識的最佳方式就是採用備有技術文件的安全性做法。

我們的研究顯示，持續推送軟體更新以推動開發運作轉型的機構，較可能訂有高品質、低風險且符合成本效益的流程。

我們特別評估了下列技術做法：

• 鬆耦合架構
• 主幹式開發
• 持續測試
• 持續整合
• 採用開放原始碼技術
• 監控和觀測能力做法
• 資料庫變更管理
• 部署自動化

我們發現雖然這些做法全都有助於改善持續推送軟體更新的成效，但鬆耦合架構和持續測試的影響力最大。 舉例來說，今年我們發現，達成可靠性目標的卓越成效團隊採用鬆耦合架構的可能性較高，是低成效團隊的三倍。

鬆耦合架構

我們的研究持續顯示，您可以設法降低服務和團隊彼此依存關係的細膩程度，藉此改善 IT 成效。 事實上，這種做法最有望提高持續推送軟體更新成效。 只要使用鬆耦合架構，各團隊就能分別調整規模、失敗、測試並部署，互不影響。 團隊可以按照自己的步調行動，並將工作分成較小的批次來處理，這樣積累的技術債不僅較少，失敗時也能更快復原。

持續測試和持續整合

我們的研究顯示，持續測試最有望提高持續推送軟體更新成效，這點與前幾年的調查結果類似。 達成可靠性目標的卓越成效團隊運用持續測試做法的可能性為 3.7 倍。 在整個推送流程中盡早整合並頻繁測試，並由測試人員全程配合開發人員，團隊就能以更快的速度進行疊代，以及變更產品、服務或應用程式。 您不僅可以使用這種意見回饋循環為客戶提供價值，同時也能輕鬆整合自動化測試和持續整合等做法。

持續整合也有助於改善持續推送軟體更新作業。 達成可靠性目標的卓越成效團隊運用持續整合做法的可能性為 5.8 倍。 在持續整合做法中，每一個修訂版本都會觸發軟體建構流程，並執行一系列能在幾分鐘內提供意見回饋的自動化測試。 您可以藉由持續整合來減少成功整合所需的手動協調工作，這類工作往往相當複雜。

如同 Kent Beck 和「極限編程」(Extreme Programming) 社群所定義，持續整合 (這個詞就是出自該社群) 還包含主幹式開發的做法，詳述如下⁷。

主幹式開發

我們的研究持續顯示，高成效機構已導入主幹式開發的可能性較高；開發人員會將工作劃分為較小的批次，然後頻繁將工作成果合併至共用的主幹。事實上，達成可靠性目標的卓越成效團隊使用主幹式開發的可能性為 2.3 倍。 低成效團隊較可能使用長效型分支版本及延遲合併的做法。

團隊每天至少應合併工作一次，如有可能，每天可合併數次。主幹式開發和持續整合密切相關，因此您應同時導入這兩種技術做法，因為兩者相輔相成能產生更大的效益。

部署自動化

在理想的工作環境中，重複性工作應由電腦執行，讓人類專心解決問題。 導入部署自動化能協助團隊進一步朝這項目標邁進。

透過自動化方式將軟體從測試階段推送到實際工作環境，就能提高部署速度和效率，藉此縮短前置時間。 這種方式也可以降低部署出錯的可能性，因為手動部署出錯的機率較高。 如果您的團隊使用部署自動化，就能立即獲得意見回饋，這有助於加速改善服務或產品。 雖然您不需要同時導入持續測試、持續整合和自動化部署，但若搭配使用這三種做法，就可能獲得更大幅度的改善。

資料庫變更管理

無論是編寫及維護程式碼，還是管理資料庫，透過版本管控追蹤變更都是極為重要的環節。 我們的研究發現，達成可靠性目標的卓越成效團隊實施資料庫變更管理的可能性更高，是低成效團隊的 3.4 倍。 此外，資料庫變更管理如要成功，關鍵在於所有相關團隊必須協力合作、溝通交流，以及公開資訊。 雖然您可以選擇導入特定的做法，我們仍建議每當需要變更資料庫時，團隊應共同審查變更，然後再更新資料庫。

____________________________

8. Beck, K. (2000 年)。《Extreme programming explained: Embrace change》(極限編程詳解：導入變更)。Addison-Wesley Professional

____________________________

監控與觀測能力

和前幾年一樣，我們發現監控和觀測能力做法有助於持續推送軟體更新。 順利達成可靠性目標的卓越成效團隊，較傾向採用具觀測能力的系統健康監測解決方案，可能性為 4.1 倍。 觀測能力做法能讓團隊更瞭解系統，有助於縮短確認及排解問題所需的時間。 我們的研究也顯示，採用理想觀測能力做法的團隊能投入更多時間編寫程式碼。 針對這項調查結果，可能的解釋是導入觀測能力做法有助開發人員縮短搜尋問題成因的時間，進而直接排解問題，最後再繼續編寫程式碼。

開放原始碼技術

許多開發人員都已採用開放原始碼技術，而他們對於這些工具的熟悉度能讓機構增添一分優勢。 封閉原始碼技術的主要缺點在於，機構對內或對外轉移知識的能力會受到限制。 舉例來說，您很難招募到已熟悉貴機構內部工具的人才，而開發人員也無法將自己累積的知識轉移給其他機構。 相較之下，大多數開放原始碼技術都有支援社群，開發人員可在其中尋求協助。 開放原始碼技術提供更普及的存取管道、成本相對低廉，並可靈活自訂。達成可靠性目標的卓越成效團隊運用開放原始碼技術的可能性為 2.4 倍。 我們建議您改變策略，在進行開發運作轉型時，應採用更多開放原始碼軟體。

如要進一步瞭解技術開發運作能力，請前往以下網址參閱 DORA 能力相關資訊：https://cloud.google.com/devops/capabilities

COVID-19

今年我們調查了 COVID-19 疫情期間影響團隊表現的因素。 特別是 COVID-19 疫情對於軟體推送和運作 (SDO) 成效是否有負面影響？ 團隊是否因此更容易出現疲乏現象？ 最後，哪些因素確實有助於減少疲乏現象？

首先，我們試圖瞭解疫情對於軟體推送和運作成效有哪些直接影響。 許多機構將翻新視為優先要務，希望藉此因應劇烈的市場變化 (例如由現場採購改為線上採購)。 在「如何進行比較」章節中，我們討論到，軟體產業的成效不僅顯著加速成長，且未來仍會維持此一趨勢。 目前在我們調查的對象中，絕大多數均為成效較高的團隊，而卓越成效團隊則進一步將標準提高，以更高的頻率部署，而且前置時間更短、復原時間更快，變更失敗率也更低。同樣地，GitHub 研究人員進行的一項研究顯示，開發人員 2020 全年的活動 (包括推送、提取要求、已審查的提取要求，以及每位使用者留言的問題⁹) 呈現增長的趨勢。業界持續加速發展，而且似乎不是拜疫情所賜，而是完全無懼疫情，但值得注意的是，在這段危急的時期，並未出現 SDO 成效下滑的趨勢。

疫情改變了我們的工作方式，許多人也因此改變了工作的地點。 基於這個原因，我們探討了為因應疫情而採取遠距工作的方式，究竟產生了哪些影響。 我們發現 89% 的作答者因為疫情的緣故而在家工作。只有 20% 作答者表示疫情爆發前曾在家工作。 轉換到遠距工作環境對於開發軟體、執行業務及協同作業的方式產生了重大影響。 對許多人而言，在家工作就無法和同事隨時在走道上對話，或面對面協同合作。

____________________________

9. https://octoverse.github.com/

____________________________

如何減少疲乏現象？

儘管如此，對於團隊是否會陷入遠距工作導致的疲乏感中，我們確實發現一項關鍵的決定因素：文化。 團隊若具有創造型文化，成員都能感覺獲得團隊認同，產生歸屬感，在疫情期間出現疲乏現象的可能性也會減半。這項調查結果突顯出優先思考團隊和文化的重要性。 表現較出色的團隊都能順利因應更艱困的時期，儘管團隊及成員同樣都承擔著壓力。

文化

普遍來說，文化是任何機構皆難以避免的人際暗流， 涵蓋任何可能影響員工對機構及彼此之間的想法、感受和應對方式的事物。 所有機構各自都有獨特的文化，而我們的調查結果一致顯示，文化是提升機構和 IT 成效最重要的動力來源之一。 具體來說，我們的分析指出，創造型文化 (衡量依據為 Westrum 機構文化分類學的定義，以及機構成員的歸屬感和認同感) 有助於提高軟體推送和運作 (SDO) 成效。舉例來說，我們發現達成可靠性目標的卓越成效團隊具有創造型文化的可能性更高，是低成效團隊的 2.9 倍。 同樣地，創造型文化有助於提高機構成效，並降低員工疲乏率。 簡單來說，機構文化不容小覷。 所幸，文化就像液體，可以兼具多種面向且保持流動，因此具有可塑性。

成功執行開發運作的關鍵在於，機構是否擁有能夠跨部門合作的團隊。 我們在 2018 年發現，高成效團隊透過單一跨部門團隊開發及推送軟體的可能性為 2 倍。這項結果再次突顯出協同合作對於提升機構成效無比重要。 而其中的關鍵在於，哪些因素有助於建立理想的環境，鼓勵並重視跨部門合作？

多年來，我們不斷推廣建構文化的實質效益，並協助開發運作社群清楚瞭解文化對於機構和 IT 成效的影響。 首先我們採用 Westrum 的機構文化分類學，從運作的角度來定義文化。 他提出三種類型的機構：權力導向、規則導向和成效導向。 我們在研究中採用這個架構，並發現成效導向的機構文化可讓資訊流、信賴度、創新，以及風險分擔發揮最佳效益，這與高 SDO 成效密切相關。

隨著我們對文化和開發運作的瞭解日新月異，我們設法擴展最初對於文化的定義，納入其他社會心理因素，像是心理安全感。高成效機構的文化較可能鼓勵員工適度承擔經評估過的風險，而不必畏懼負面結果。

歸屬感和認同感

由於文化對於成效一向都具有強大影響力，今年我們擴展了模型，試圖研究員工的歸屬感和認同感是否強化了文化的正面效果，讓成效有所提升。

心理學研究顯示，人類天生就有和他人建立並維持緊密穩定關係的傾向¹⁰。我們都希望在所處的各種團體中擁有與他人緊密相連，以及被接納的感覺。歸屬感會帶來許多有益身心的優點。 舉例來說，研究指出歸屬感對於積極性有正面影響，並能提升學術成就¹¹。

要形成這種緊密相連的感覺，其中一個要素就是設法讓員工樂於全心投入工作，同時高度重視並認同員工的獨特經驗和背景¹²。致力打造具有包容性的文化，在組織機構內部營造歸屬感，有助於建立活力充沛、多元發展，且積極進取的工作團隊。

我們的調查結果指出，相較於較不正向積極的機構文化，在重視歸屬感和包容性的成效導向機構中，員工較不會出現疲乏現象。

有鑑於證據顯示社會心理因素可能影響 SDO 成效和員工疲乏程度，我們建議如果您想要成功推動開發運作轉型，務必在轉型計畫中編列預算，投資解決文化相關問題。

____________________________

10. Baumeister 和 Leary，1995 年。 《The need to belong: Desire for interpersonal attachments as a fundamental human motivation》(歸屬感需求：渴望人際依附關係為人類原始動機)。Psychological Bulletin，117(3)，497–529。https://doi.org/10.1037/0033-2909.117.3.497

11. Walton 等人，2012 年。《Mere belonging: the power of social connections》(單純歸屬感：社交聯繫的力量)。 Journal of Personality and Social Psychology，102(3)：513-32。https://doi.org/10.1037/a0025731

12. Mor Barak 和 Daya，2014 年，《Managing diversity: Toward a globally inclusive workplace》(管理多元性：邁向全球化的包容性職場環境)。Sage。 Shore、Cleveland 和 Sanchez，2018 年；《Inclusive workplaces: A review and model》(包容性職場環境：評論與模型)，Human Resources Review。https://doi.org/10.1016/j.hrmr.2017.07.003

《加速發展：2021 年開發運作現狀》報告集結了七年的研究心血和超過 32,000 份業界專業人士的問卷回覆，歸納出能協助團隊和機構獲得最大成效的軟體開發和開發運作做法。

今年來自全球各行各業的 1,200 名專業人士分享了他們的經驗，協助我們進一步瞭解有助於實現更高成效的因素。總而言之，受訪者和企業統計結構評估標準的取樣比例仍然維持高度一致性。

和前幾年類似，我們收集了每一位問卷作答者的特徵資訊，類別包括性別、身心障礙和弱勢族群。

受訪者和企業統計結構

今年在公司規模、產業和區域等企業統計結構類別的取樣比例和之前的報告一致。其中超過 60% 作答者的職務為工程師或主管，三分之一來自科技業。此外，也有來自金融服務業、零售業和工業/製造業的業界代表參加問卷調查。

____________________________

13. https://www.washingtongroup-disability.com/question-sets/wg-short-set-on-functioning-wg-ss/

____________________________

性別

和先前的問卷調查一樣，在今年的取樣對象中，83% 為男性，12% 為女性，1% 為非二元性別。作答者表示在自己所屬的團隊中，有 25% 包含女性，較 2019 年 (16%) 顯著增加，但與 2018 年 (25%) 相當。

身心障礙

我們遵循《Washington Group Short Set》(華盛頓身心障礙小組簡短問題集)，整理出六個方面的身心障礙情形¹³。我們已連續三年諮詢身心障礙相關資訊。身心障礙者比例和 2019 年的報告一樣，均為 9%。

弱勢族群

具有弱勢族群成員身分指的可能是種族、性別或其他屬性。我們已連續四年諮詢弱勢族群相關資訊。具有弱勢身分的作答者所占比例從 2019 年的 13.7% 小幅增加至 2021 年的 17%。

年資經驗

今年問卷調查的作答者年資經驗較豐富，41% 具備 16 年以上的工作經驗。超過 85% 的作答者擁有 6 年以上的工作經驗。

部門

作答者大多任職於開發或工程團隊 (23%)、開發運作或 SRE 團隊 (21%)、主管階層 (18%) 及 IT 運作或基礎架構團隊 (9%)。我們發現顧問人員的比例降低 (從 2019 年的 4% 下降到 2%)，高階主管則增加 (從 2019 年的 4% 上升到 9%)。

產業別

和前幾年的《加速發展：開發運作現狀》報告一樣，大多數作答者都來自科技業，然後依序為金融服務業、零售業和其他產業。

員工

和前幾年的《加速發展：開發運作現狀》報告一致，作答者來自各種不同規模的機構。22% 的作答者任職於擁有超過 10,000 名員工的公司，7% 任職於擁有 5,000 到 9,999 名員工的公司。15% 的作答者則任職於擁有 2,000 到 4,999 名員工的公司。此外，也有一定比例的作答者來自以下規模的公司：擁有 500 到 1,999 名員工的公司占 13%，擁有 100 到 499 名員工的公司占 15%，擁有 20 到 99 名員工的公司占 15%。

團隊規模

半數以上的作答者 (62%) 任職於擁有 10 名以下成員的團隊 (6 到 10 人占 28%，2 到 5 人占 27%，1 人團隊則為 6%)。19% 則任職於擁有 11 到 20 名成員的團隊。

區域

在今年的問卷調查中，來自北美洲的作答者比例減少了 (2019 年為 50%，2021 年為 39%)。另一方面，歐洲 (2019 年的 29% 上升到 2021年 的 32%)、亞洲 (2019 年的 9% 上升到 2021年 的 13%)、大洋洲 (2019 年的 4% 上升到 2021年 的 6%) 及南美洲 (2019 年的 2% 上升到 2021年 的 4%) 的作答者比例皆增加。

作業系統

各作業系統分布情形也和先前的開發運作現狀報告一致。我們也要肯定及感謝作答者的協助，讓我們知道作業系統清單可能需要更新。

今年我們特別關注作答者將他們開發的主要服務或應用程式部署在何處。 出乎我們意料，大部分的作答者使用容器 (64%)，48% 使用虛擬機器 (VM)。 這可能反映出產業趨勢轉向更現代化的部署目標技術。 我們檢視了各種規模的企業之間的差異，但並未發現部署目標之間有顯著差異。

堅持本身原則並善用自身能力的團隊可以快速可靠地推送軟體，同時直接為業務帶來價值。今年，我們調查了 SRE 做法、安全軟體供應鏈、優質技術文件的影響，並重新審視了我們探索雲端應用的方式。每個指標都有助於提高員工和團隊的效率。我們要突顯的是，能否運用這些能力為使用者建構合適的解決方案才是關鍵所在，而不是讓使用者適應解決方案。

我們要感謝對今年的問卷調查有所貢獻的每一位參與者，並希望這項調查能協助您和貴機構打造更出色的團隊和更優異的軟體，同時維持工作與生活的平衡。

今年報告能順利完成，有賴一群陣容龐大的人士熱心貢獻。 調查問題的設計、分析、撰寫、編輯和報告設計均由我們同仁負責，他們為實現這個龐大計畫而花費許多心力。 全體作者由衷感謝所有人對今年報告的付出和指導。 銘謝對象名單按字母順序排列。

Dustin Smith

Dustin Smith 是 Google 的人因心理學家和員工使用者體驗研究經理，他加入 DORA 專案已有三年時間。過去七年，他持續研究周遭系統和環境對人有何影響，範圍涵蓋各種不同情境：包括軟體工程、免費遊戲、醫療保健和軍事等。他在 Google 的研究辨識出能讓軟體開發人員在開發過程感到更快樂，且更有效率的環境。他加入 DORA 專案已有兩年時間。Dustin 擁有威奇塔州立大學的人因心理學博士學位。

Daniella Villalba

Daniella Villalba 是專門負責 DORA 專案的使用者體驗研究員。她致力於瞭解能讓開發人員保持愉快並提高生產力的因素。加入 Google 前，Daniella 曾研究過冥想訓練的優點、影響大學生體驗的社會心理因素，以及目擊者記憶和虛假供詞等主題。她在佛羅里達國際大學取得實驗心理學博士學位。

Michelle Irvine

Michelle Irvine 是 Google 的技術文件撰寫專員，負責幫助員工熟悉開發人員工具。加入 Google 前，她曾在教育出版業任職，以及擔任物理模擬軟體的技術文件撰寫專員。Michelle 擁有滑鐵盧大學的物理學士學位，以及修辭與傳播設計碩士學位。

Dave Stanke

Dave Stanke 是 Google 的開發人員關係工程師，負責為採用開發運作和 SRE 做法的客戶提供相關建議。在職業生涯中，他曾擔任過許多職務，包括新創公司技術長、產品經理、客服人員、軟體開發人員、系統管理員，以及平面設計師。他擁有哥倫比亞大學科技管理碩士學位。

Nathen Harvey

Nathen Harvey 是 Google 的開發人員關係工程師。在職業生涯中，他曾協助團隊瞭解自己的潛能，同時針對業務成果來調整技術。Nathen 曾獲得難得的機會，和一些頂尖團隊和開放原始碼社群共事，協助他們運用開發運作和 SRE 原則和做法。Nathen 曾參與編輯 O’Reilly 2020 年出版的《97 Things Every Cloud Engineer Should Know》(所有雲端工程師都應知道的 97 件事)，貢獻一己之力。

研究設計

這項研究運用了以理論為基礎的跨區隔設計。這種以理論為基礎的設計稱為推論式預測，是當今商業和科技研究中最常採用的類型之一。如果研究團隊無法使用純實驗性設計，且偏好實地實驗，推論式設計就能派上用場。

目標人口及取樣

這項問卷調查的目標人口是實際運用技術和參與轉型，或有密切關係的從業人員和領導階層，尤其是熟悉開發運作的人員。我們透過電子郵件名單、線上宣傳管道、線上研討會、社群媒體來宣傳這項問卷調查，並請求使用者在自己的人際網路上分享 (也就是所謂的滾雪球取樣法)。

建立隱性構念

我們盡可能使用先前經過驗證的構念，精心設計出我們的假設和構念。我們根據理論、定義以及專家意見來建立全新構念。然後，我們會採取額外步驟來釐清意圖，藉此確保問卷調查收集的資料有很高的可能性是可靠且有效的¹⁴。

統計分析方法

集群分析：我們運用集群分析法，根據部署頻率、前置時間、服務復原時間以及變更失敗率，來衡量軟體推送成效概況。由於缺少業界或理論支持的理由，無法預先決定集群數量，因此我們運用了隱性類別分析¹⁵。此外我們還運用了貝葉斯訊息量準則 (Bayesian information criterion) 來決定最理想的集群數量。

評估模型：進行任何分析之前，我們會先採用探索性因素分析辨識出構念，其中主成分分析採用方差最大化旋轉¹⁷。我們使用平均變異抽取量 (AVE)、相關性、克隆巴赫係數¹⁸和組成信度，針對收斂和分歧效度和信度確認了統計檢定。

結構方程式模型：我們使用偏最小平方 (PLS) 分析來測試結構方程式模型 (SEM)；偏最小平方是一種以相關性為依據的 SEM¹⁹。

^{________________________}

14. Churchill Jr, G. A. 《A paradigm for developing better measures of marketing constructs》(發展理想行銷構念評估標準的範式)，Journal of Marketing Research 16:1，(1979 年)，64–73。

15. Hagenaars, J. A. 和 McCutcheon, A. L. (編輯)。(2002 年)。《Applied latent class analysis》(應用隱性類別分析)。Cambridge University Press。

16. Vrieze, S. I. (2012 年)。《Model selection and psychological theory: a discussion of the differences between the Akaike information criterion (AIC) and the Bayesian information criterion (BIC)》(模型選擇與心理學理論：淺論赤池訊息量準則 (AIC) 和貝葉斯訊息量準則 (BIC) 之間的差異)。Psychological methods，17(2)，228。

17. Straub, D.、Boudreau, M. C. 和 Gefen, D. (2004 年)。《Validation guidelines for IS positivist research》(IS 實證主義者研究之驗證指南)。Communications of the Association for Information systems，13(1)，24。

18. Nunnally, J.C.《Psychometric Theory》(心理計量學理論)。紐約：McGraw-Hill，1978 年

19. Hair Jr, J. F.、Hult, G. T. M.、Ringle, C. M. 和 Sarstedt, M. (2021 年)。《A primer on partial least squares structural equation modeling (PLS-SEM)》(偏最小平方結構方程式模型 (PLS-SEM) 入門)。Sage publications。

如要進一步瞭解開發運作能力，請參閱 https://cloud.google.com/devops/capabilities

如要尋找網站穩定性工程 (SRE) 相關資源，請前往：

https://sre.google

進行開發運作快速檢驗：

https://www.devops-research.com/quickcheck.html

探索開發運作研究計畫：

https://www.devops-research.com/research.html

進一步瞭解 Google Cloud 應用程式翻新計畫：

https://cloud.google.com/solutions/camp

閱讀《開發運作轉型投資報酬率：如何量化翻新計畫的影響力》白皮書：

https://cloud.google.com/resources/roi-of-devops-transformation-whitepaper

查看之前的開發運作現狀報告：

2014 年開發運作報告：https://services.google.com/fh/files/misc/state-of-devops-2014.pdf

2015 年開發運作報告：https://services.google.com/fh/files/misc/state-of-devops-2015.pdf

2016 年開發運作報告：https://services.google.com/fh/files/misc/state-of-devops-2016.pdf

2017 年開發運作報告：https://services.google.com/fh/files/misc/state-of-devops-2017.pdf

《加速發展：2018 年開發運作現狀》報告：https://services.google.com/fh/files/misc/state-of-devops-2018.pdf

《加速發展：2019 年開發運作現狀》報告：

https://services.google.com/fh/files/misc/state-of-devops-2019.pdf