本文要點
- DevOps已經“跨越了鴻溝”：優秀的實踐者佔了所有組織的20%，幾乎是原來的三倍，這表明任何人都可以做到卓越的DevOps。
- 雖然良好實現的雲計算策略可以幫助交付更好的結果（有助於提高速度、穩定性和可用性），但其他因素如領導力、文化、流程和技術實踐等也有助於提高績效。
- 爲了充分利用雲，我們需要對NIST定義的五個基本特性進行投資：按需自助服務、廣泛的網絡訪問、資源共享、快速伸縮和服務可度量。
- 貫穿軟件開發和交付過程的自動化帶來了很多好處。
- 表現最好的實踐者正在利用構建社區的結構性解決方案來擴展他們的DevOps實踐：社區實踐和基礎解決方案讓組織可以逐步成長爲DevOps組織，並且可以以組織或產品爲中心。
由Nicole Forsgren博士和Dustin Smith博士主導的最新的DevOpss加速狀態報告於2019年8月發佈。該報告展示了最新的研究成果，展示了對軟件開發和組織績效有貢獻的能力和實踐。InfoQ就2019年報告的主要發現、最成功的DevOps和雲策略以及驅動業務成功的技術採訪了Nicole Forsgren博士。
InfoQ：祝賀Forsgren博士發佈了最新的DevOps加速狀態報告！這是一個巨大的創舉，今年的報告絕對令人吃驚。感謝您接受InfoQ的採訪。您想和我們的讀者分享的要點是什麼？
**Dr. Forsgren：**今年我們有許多重要的發現：
- 這個行業在不斷進步，每個人都有可能做到最好。我們發現，表現最好的實踐者，也就是表現最好的那羣人，幾乎是原來的三倍。這確實令人興奮，它證實了許多其他分析師的報告。
- 我們今年還做了一件過去幾年都沒做過的事，那就是除了績效之外，還深入研究了生產力。
- 正如我們在前幾年所做的，我們調查了有利於績效提升的文化、過程和技術實踐。我們能夠重新驗證一些發現；例如，雲是一個關鍵的區別。
- 我們看到了一系列確鑿的發現，關於變更審批應該如何進行。特別重要的變更審批對績效有負面影響，而明確的變更審批過程對績效有正面影響。
- 今年我們還加了一個不錯的部分，關於大規模轉型。
InfoQ：您提到的一個重要發現是DevOps已經“跨越了鴻溝”。這一里程碑事件是否會給其他公司敲響警鐘，更快地跟上這一趨勢？對於那些在理解DevOps、雲計算和自動化的重要性方面有困難的大公司來說，這可能是一個機會，可以開始探索這些領域。
Dr. Forsgren: 現在不管什麼類型的技術，它正好符合你的要求是再好不過了：這是一個安全的舉措。這不再是一場賭博，你沒有處在前沿。我們現在瞭解了很多關於技術轉型成功的因素。我已經做了六年的DevOps報告了，所以它不是一個瘋狂的新奇事物。對於許多組織來說，他們都可以放心地說，“我們絕對要在雲上投資”。一些高度監管的組織現在都在雲中，我們現在可以安全地將數據放到公有云中。
不僅如此，在很多方面，我們知道它是安全且有保障的——我們知道它更安全，更有保障。對我們而言，這是一個很好的發展方向，我們瞭解自動化、投資、CI/CD方面的能力和實踐，CI應該是什麼樣的，CD應該是什麼樣的，我們的流程應該是什麼樣的，這樣才更可能成功。所以現在，從管理人員的角度來看：如果我正在做重大投資決策，我知道我有很大的可能性取得成功。
舉個例子：我跟幾家銀行交流過，他們說“你知道我們幾年前被傷過，我不想衝在前面，我想做一個快速的跟隨者，我想成爲第二波的第一人”。我們已經深入DevOps轉型，這是一個安全而明智的舉動，甚至那些討厭風險而非常謹慎的公司也在採用這些方法，並努力追趕——利用我們從其他行業獲得的十年經驗。
InfoQ：很高興聽到這個消息！我們知道，如果我們在技術、流程和文化方面進行正確的投資，並利用好雲，那麼就可能實現大規模的DevOps。爲什麼我們仍然沒有在自動化方面投入足夠的資金，我們可以做些什麼來幫助組織理解他們需要進行的投資，他們如何才能在這方面做得更好？
Dr. Forsgren：開發和交付技術需要投資並執行，目的是爲客戶交付價值。我有時會說：如果我們想要更好的表現，我們需要投資，也需要執行。如果我是健身房會員，我也需要去健身房，我還需要鍛鍊。
我經常看到以下兩種脫節的情況：
首先，從某些高管或領導層的角度來看，我們有時認爲，我們可以開一張支票，然後走開，但仍能讓它生效。實際上，我們還必須改變我們開發軟件的方式，當我們在雲中開發和交付軟件時，它實際上會極大地改變我們交付價值的方式。
第二個脫節是我們如何談論採用和實現雲計算。有時高管們會說：“我們進行了投資，但還沒有看到回報。”所以，我問：“你說的雲是什麼意思？”我們可能會與15家不同的公司討論雲，關於雲對他們意味着什麼，我們會收到15個不同的答案。因此，我們使用NIST的定義來定義雲計算。雲是不可互換的，主要的雲提供商有明顯的不同。但是，即使雲提供商之間存在這些差異，你也必須進行架構設計並實現自動化，從而以正確的方式使用和訪問雲：
- 按需自助服務：當有人需要提供計算資源時，它需要隨需應變並支持完全自助的服務。你必須能夠立即快速地配置並訪問它，否則你將失去在雲上的好處。
- 廣泛的網絡訪問：你需要能夠跨不同的設備、手機、筆記本電腦、平板電腦訪問你的網絡。
- 資源共享：然後我們需要能夠按使用付費。
- 快速伸縮：我開玩笑說這是“就像變魔術一樣突然變化”——上上下下。
- 服務可度量：你只需要爲你使用的東西付費；大多數公有云處 理都可以這樣處理。
有一些部分是需要組織付出真正的努力才能解決的——通常是自助服務部分和廣泛的網絡訪問。如果我們不改變訪問和使用基礎設施的方式，我們就無法得到遷移到雲的全部好處。回到我那個類比：我可以付費成爲健身房會員，但如果我不去健身房並進行鍛鍊，我就得不到成爲會員的好處。
InfoQ：在2017年接受InfoQ採訪時提到，您一直在擴展其他組織領域的研究，比如領導力。在DOES 2017大會上，您介紹了當年的研究，並討論了變革型領導與僕人型領導的區別。您能給我們介紹一下嗎？
Dr. Forsgren：組織有績效目標，他們試圖推動業務結果。所以，我們想要研究一種與結果更一致的領導模式。在我爲那年的研究做準備時，我發現很多學術文獻和研究表明，變革型領導模式比服務型領導模式更適合驅動績效。（變革型領導推動業務成果）這一假設之前沒有在技術變革這樣的背景下被研究過，所以我們對其進行了測試，我們能夠找到證據證明變革型領導在技術變革中的深遠影響。我們沒有繼續研究下去，因爲每年都有很多東西要研究！
我們注意到，變革型領導並不要求員工有直接下屬，這一點很重要，因爲DevOps具有草根文化背景。任何人都可以成爲冠軍和團隊的一員，並幫助激勵和領導他們的團隊或組織。我們在Accelerate一書中着重介紹了這一點。
InfoQ：關於基層工作的文化，我真的很喜歡您針對組織大規模DevOps轉型時的策略所做的分析。您能談談這個嗎?
Dr. Forsgren：謝謝！那一部分很棒，其靈感來自於我們中的一位顧問Sam Guckenheimer。這個分析是由Dustin主導的，我喜歡他發現的模式。他從對整體模式的廣泛觀察開始，我們注意到一些常見的模式，比如Big Bang很少被使用（並且在優秀的實踐者中使用頻率最低）。然後，Dustin和我聊天時說想要了解那些高水平的精英級實踐者在使用什麼樣的擴展策略——也就是說，如果有人想問最好的人在做什麼，我們能把模式告訴他們嗎？高水平的精英級實踐者中間存在四個清晰的模式，這與我在與我合作的企業中所看到的相呼應：
- 社區建設者：46%——側重於實踐社區、草根研究和概念驗證（POC）；
- 大學：只有9%——側重於教育和培訓，有卓越中心、培訓中心、實踐社區；
- 新用戶（Emergent）：23%——側重於草根研究和實踐社區；
- 試驗者：22%——針對Big Bang和DOJO之外的策略活動較多。
總的來說，我們看到，他們使用的大多數策略都是利用構建社區的結構化解決方案。通過這種方式，他們已經建立了對任何類型的變化都有很強彈性的組織，比如部門重組、產品戰略變更等等。當市場條件需要時，公司可以繼續調整。(我將在報告中詳細介紹每種策略的定義和模式。)
需要指出的是，這些工作仍然需要資源，無論是買午餐或棕色食品袋的錢，還是用時間資源，如20%的時間。
InfoQ：關於成熟度模型的一個問題。我真的很喜歡您對成熟度模型的描述。我完全同意您的看法，我認爲它們源於瀑布模型的角度和方法，我們非常習慣這些成熟度模型和路線圖，它們可以告訴我們如何以及何時我們會變得更加成熟，這無疑會限制DevOps團隊儘快創新的能力。
爲什麼我們仍然要DevOps成熟度模型，花無數時間定義標準？在大多數情況下，我們最終都沒有遵循它們。就像瀑布項目計劃一樣，它們永遠不會得到更新，阻礙了團隊探索和加速。
Dr. Forsgren：在某些組織中，有幾個原因可以解釋那爲什麼會存在。它們很容易推銷，因爲那讓人舒服，讓人安心。然後，領導者們想知道未來兩年、三年、五年將會發生什麼。如果你給我一個成熟度模型，從中你可以知道你現在的位置，接下來的位置，以及再接下來的位置…這是非常強大的，因爲它給我一種安全感，它給我一種安心的感覺，它讓我可以長期計劃。這會讓人覺得那人（給你模型的人）很專業。事實上，它們都是虛構的。它們都是編造的，就像CMMI是編造的一樣。我們會有不同程度的投入，一些組織做了很多計劃和嘗試，但它們都是編造的。
相反，我們應該做的是基於約束的模型，即：
- 這就是我現在的處境。
- 我知道下面這些事情會讓我變得更好。
當我們找出25到30件能讓我們變得更好的事情時，這個清單可能會讓人有點不知所措。縮小範圍，優先考慮最大的限制。你可以通過幾種不同的方式來識別你的約束條件：
- 你可以使用基於流程的約束模型和價值流映射。在這個方法中，你繪製出價值流，及時描述我們浪費時間的地方，然後確定最大的約束。
- 另一種選擇是使用基於能力的約束模型。在這種方法中，列出了對重要結果（通常是速度和穩定性）有貢獻的能力。DORA的研究做了這項工作，你可以在免費的DevOps現狀報告中找到這些內容，或者在Accelerate一書中找到。然後，你可以藉助工具通過算法來確定你的約束（DORA的評估就可以做到這一點），或者你可以詢問你的團隊，交付軟件時最頭痛或負擔最大的功能是什麼。
- 有些團隊同時使用這兩種方法。
這裏的挑戰在於，你基本上得告訴一位高管，你只知道明年的路線圖。這讓人不舒服。不僅如此，這是在說我們只知道一年內會怎樣，這意味着我們不是專家。但問題是：我們是專家。因爲現在，我們是知道如何診斷真正的問題並繼續前進的人。這很強。
我與許多管理人員一起工作，我沒有向他們推銷成熟度模型，而是教他們如何根據團隊的需要定製自己的基於約束的模型，並跟蹤進度。
我想說的是，當你談論單一工具時，成熟度模型很好。你可以測量對工具或其基本安裝的瞭解程度，或者我們可以討論人們從採用一項技術到成爲專家的進展情況。但是，如果你談論的是像技術轉型這樣的事情，它太複雜了，有太多的事情在起作用，你要緊密結合組織的約束。
InfoQ：回到2019年DevOps狀態報告的結果，該研究證實，吞吐量和穩定性都是可能的，不需要折中。您認爲，只要我們實現自動化，不需要折中，就兩者都可能實現嗎？
Dr. Forsgren：在過去的六年中，我們的分析證實，速度和穩定性是相輔相成的。在這項研究中，我收集了兩個速度指標和兩個穩定性指標。我們每年都觀察到，速度與穩定性是同向變動的。
但我要指出，速度和穩定性在高端實踐者那裏是同向變動的，不需要折中，它們在低端實踐者那裏也是同向變動的，不過，他們是在速度上陷入掙扎，在穩定性上也陷入掙扎。
現在回答問題的下一部分，是否必須自動化？不！你的意思是，這很重要，如果你想做得更好，是的，自動化是必要的，但如果你想保持糟糕的速度和穩定性，因爲沒有折中，自動化就是不需要的。如果我們不投資於自動化，我們就會處處受阻。你的觀察很有趣也很聰明。因此，我們確實需要提高自動化程度，而且我確實認爲，在軟件開發和交付過程中提高自動化程度將幫助我們提高績效和業務成果。這並不是唯一的原因，有幾個因素影響了績效，還有流程，比如小批量工作，這有助於我們獲得更小段的代碼，這是一種改進的文化，這是雲計算的使用。
自動化有一些優勢，比如有良好的自動化測試套件、部署自動化。
自動化的另一個好處是它爲你提供了可重複性、可審覈性，並最終在安全方面產生了巨大的影響。所以，就質量而言，你獲得了下游效應。也讓你流程中的反饋循環更快速，所以你的代碼會變得更好，因爲如果它在我的腦海裏還記憶猶新，我得到更快的反饋，我立即可以改進我的代碼，而不是三個月後得到反饋，我必須弄清楚我當時在想什麼。自動化有很多非常好的好處。
InfoQ：接下來是一個相關問題：爲什麼組織在自動化投資方面存在困難？我採訪了Scrum的創始人Jeff Sutherland，他也給出了同樣的反饋。他和大公司合作過，他對自動化也有同樣的看法。我們需要僱傭有自動化技能的人嗎?
Dr. Forsgren：我們不需要僱傭有自動化技能的人，我認爲我們需要僱傭有發展思維的人，他們聰明，想要學習自動化。那些聰明的人，那些能夠很好地識別和理解這個過程的人，會找到編碼的方法。我不擔心人，我擔心的是那些不理解將不同東西自動化所帶來的價值的組織，相反，他們會堅持當前的方式，不管是變更審批過程還是其他的什麼，因爲這是一直以來的方式。
我們永遠不會失去自動化的機會，特別是當我們的人非常聰明且有創造力的時候。我們發現了自動化的機會，然後就有新的東西冒出來了，總有一些東西等你去發現。
InfoQ：自動化是否有助於提高開發人員的參與度，因爲他們需要使用最新的技術？
Dr. Forsgren：我認爲提升並具備進行自動化的能力提高了許多人的士氣。
有些人有時會擔心這可能會威脅到他們的工作，但我認爲這通常是一個機會，管理層可以藉機澄清他們不會失去工作。
如果有什麼不同的話，這意味着他們將做更多令人興奮的工作，因爲有令人興奮的挑戰需要解決。如果你的工作中有一部分是你可以自動化的，那就意味着它是重複的，有一些新的、有創造性的東西還沒有被發現我們，那需要你的專業知識來發現。
我曾與一些大型組織合作，他們採用這種方法來幫助改變這種表述方式和思維方式。
InfoQ：我該如何在我自己的組織中利用這份報告來幫助我們填補空白或制定路線圖呢？
Dr. Forsgren：我們設計並組織了2019年報告，這樣任何人都可以打印一兩頁，以此作爲指導或指南。我在網上看到幾家公司打印了一兩個（或者幾個）頁面，然後把它們掛在辦公室的牆上，比如雲頁面。人們也會拿出一兩頁，把它們做成幻燈片。這就是爲什麼這個報告是完全開放的，沒有任何限制。
比如，如果你想預測SDO性能，就可以這樣做。我確實看到了人們在推特上發佈的照片。他們打印出來，然後圈出他們當前對於未來六個月的關注焦點。
InfoQ：2019年的報告提供了很多有價值的數據。領導者和執行人員面臨的挑戰之一是如何將研究和數據應用到我們的路線圖和日常工作中。您是否正在考慮開發開源藍圖或指南來幫助組織着手將您的研究應用到他們的團體和組織中？
Dr. Forsgren：在資源方面，DevOps加速狀態報告是我們對行業社區的重要綜述。我們也在準備同行評議的學術論文，但這些論文不太適合大衆消費。我們也有一個執行摘要，正在準備發佈。
我們目前正在研究一些藍圖，以幫助組織擴展他們的轉型，並根據我們的研究採用雲。
InfoQ：您之前提到過您喜歡研究，而且喜歡研究很多東西。您是怎麼進入研究領域的？
Dr. Forsgren：我實際上是技術背景。我一開始是一名程序員，做了幾年的開發。我也做過幾年的系統管理員，做過一點諮詢工作。我意識到我的一些問題在類別上看起來非常相似，研究的目的是分類回答問題，這樣你就可以用一種概括的方式來回答它們。與此相關的是，我經常會去找我的經理或我正在做的項目的經理，提出解決方案。很多時候，他們會反駁說：“哦，那在這裏行不通，因爲我們和其他組織不一樣。”我意識到，如果我有很好的研究和數據，可能有助於消除我遇到的阻力。這就是我開始考慮做研究的原因。
InfoQ：您能分享一下您的研究方法嗎？您是如何闡述假設的？您是否利用過敏捷技術，比如衝刺、演示、快速反饋循環等？
Dr. Forsgren：在Accelerate一書的第二部分中有很多這方面的內容。一旦我開始研究設計，你實際上無法做衝刺。在早期的研究中，我埋頭於文獻，勾勒出假設，然後弄清楚什麼適合於今年的研究報告，什麼將超出範圍。
在這一年中，我廣泛地收集各種想法。爲了做到這一點，我把我們過去6年研究的內容以及我想要重新驗證的內容記在心裏，那就是模型的核心部分，因爲它是模型的一部分。
在這一年中，我從多個來源廣泛搜索，確定研究設計中應包含什麼內容：
- 我觀察這個行業的趨勢。我和分析師交流，看看他們的雷達上出現了什麼。但我必須在這兩者之間取得平衡。有一些趨勢正在形成衝擊，但如果它還不夠普遍，我就必須在考慮研究設計時對其進行權衡。舉個例子，混沌測試和混沌工程是當前的大趨勢，但是它們的應用還不夠廣泛，所以我還沒有把它們包括在DevOps報告類型的研究設計中。
- 我每年都會和一些顧問一起工作。今年這份報告的顧問有來自谷歌的Kelsey Hightower、Adrian Cockroft、Sam Guckenheimer和Gene Kim。
- 我也參加過幾次會議，與幾家公司、高管和企業級開發人員交流過，也與中小型企業和初創公司交流過，因爲我想了解他們在規模擴張方面面臨的挑戰。我也想看看什麼對他們真正有用。
- 我還會關注相關領域的最新研究（包括在期刊和會議上發表的研究），以確保我瞭解正在發生的事情。
很多，但我很喜歡，這也很重要，可以確保我們贏得這個行業。
InfoQ：我知道您將參加今年的DevOps企業峯會。您能讓我們的讀者先睹爲快嗎？
Dr. Forsgren：Dustin Smith博士是今年這份報告的第二作者，我將介紹2019年的報告中我們最喜歡的一些發現。然後，我將與Christina Maslach博士（加州大學伯克利分校）和Andre Martin博士（谷歌）一起在Workplace Engagement Panel上發言。
受訪者簡介
Nicole Forsgren博士是DevOps研究與評估中心的聯合創始人、首席執行官和首席科學家。她最著名的工作是測量技術過程，她是迄今爲止最大的DevOps研究的首席研究員。她曾是一名教授、系統管理員和性能工程師。她的研究成果已經在幾家同行評審的期刊上發表。Forsgren在亞利桑那大學獲得了管理信息系統博士學位，是克萊姆森大學和佛羅里達國際大學的附屬研究機構。
原文鏈接：