如何理解事物的狀態？
您可以依賴您的意見，這些意見來自各種信息來源，例如網站上的出版物或經驗。 你可以問同事，熟人。 另一種選擇是看會議的主題：程序委員會是行業的積極代表，因此我們相信他們會選擇相關主題。 一個單獨的領域是研究和報告。 但有一個問題。 世界上每年都會對 DevOps 的狀態進行研究，國外公司發布報告，而關於俄羅斯 DevOps 的信息幾乎沒有。
但是進行這樣一項研究的日子已經到來，今天我們將討論結果。 這些公司共同研究了俄羅斯的 DevOps 狀態““和””。 Express 42 幫助技術公司實施和開發 DevOps 實踐和工具，並且是俄羅斯最早談論 DevOps 的公司之一。 該研究的作者 Igor Kurochkin 和 Vitaly Khabarov 在 Express 42 從事分析和諮詢工作，同時擁有來自不同公司的運營和經驗的技術背景。 8 年來，同事們研究了數十家公司和項目——從初創公司到企業——都有不同的問題，以及不同的文化和工程成熟度。
在他們的報告中，Igor 和 Vitaly 講述了研究過程中存在的問題，他們是如何解決這些問題的，以及 DevOps 研究原則上是如何進行的，以及 Express 42 決定自己進行研究的原因。 他們的報告可以查看 .
開發運營研究
談話是由伊戈爾·庫羅奇金發起的。
我們經常在 DevOps 會議上問聽眾，“你讀過今年的 DevOps 狀態報告了嗎？” 很少有人舉手，我們的研究表明只有三分之一的人在研究他們。 如果您從未見過此類報告，那麼我們馬上就說它們非常相似。 最常見的是這樣的短語：“與去年相比......”
這裡我們有第一個問題，然後是兩個問題：
- 我們沒有去年的數據。 俄羅斯的 DevOps 狀態對任何人都不感興趣；
- 方法。 不清楚如何檢驗假設，如何構建問題，如何分析、比較結果，尋找聯繫；
- 術語。 所有報告都是英文的，需要翻譯，一個通用的 DevOps 框架還沒有發明出來，每個人都想出了自己的。
讓我們來看看 DevOps 狀態分析在世界範圍內是如何進行的。
歷史信息
DevOps 研究自 2011 年以來一直在進行。 Puppet 是配置管理系統的開發商，是第一個實施這些系統的人。 當時，它是以代碼形式描述基礎設施的主要工具之一。 直到 2013 年，這些研究只是封閉式調查，沒有公開報告。
2013 年，IT Revolution 出現了，它是所有關於 DevOps 的主要書籍的出版商。 他們與 Puppet 一起準備了第一份 DevOps 狀態出版物，其中首次出現了 4 個關鍵指標。 第二年，ThoughtWorks，一家以其對行業實踐和工具的定期技術雷達而聞名的諮詢公司，參與了進來。 在 2015 年，增加了一個方法論部分，他們如何進行分析變得清晰起來。
2016 年，該研究的作者創建了自己的公司 DORA（DevOps 研究與評估），並發布了一份年度報告。 次年，DORA 和 Puppet 發布了他們最後一份聯合報告。
然後有趣的事情開始了：
2018 年，兩家公司分拆並發布了兩份獨立報告：一份來自 Puppet，第二份來自 DORA 與穀歌的合作。 DORA 繼續將其方法與影響關鍵指標和全公司績效的關鍵指標、績效概況和工程實踐相結合。 Puppet 提供了自己的方法，並描述了 DevOps 的過程和演變。 但這個故事並沒有紮根，2019 年 Puppet 放棄了這種方法並發布了新版本的報告，其中列出了關鍵實踐以及它們如何從他們的角度影響 DevOps。 然後又發生了一件事：Google 收購了 DORA，他們一起發布了另一份報告。 你可能見過他。
今年，事情變得複雜起來。 眾所周知，Puppet 發起了自己的調查。 他們比我們早了一個星期，而且已經結束了。 我們參與其中，看看他們對哪些話題感興趣。 現在 Puppet 正在進行分析並準備發布報告。
但是目前DORA和谷歌還沒有任何消息。 XNUMX 月，也就是調查通常開始的時候，有消息稱，DORA 的創始人之一妮可·福斯格倫 (Nicole Forsgren) 已經跳槽到另一家公司。 因此，我們假設今年DORA不會有研究和報告。
俄羅斯的情況如何？
我們還沒有做過 DevOps 研究。 我們在會議上發言，複述其他人的發現，Raiffeisenbank 翻譯了 2019 年的“State of DevOps”（您可以在 Habré 上找到他們的公告），非常感謝他們。 這就是全部。
因此，我們使用 DORA 方法和發現在俄羅斯進行了自己的研究。 我們使用 Raiffeisenbank 同事的報告進行研究，包括同步術語和翻譯。 與行業相關的問題取自 DORA 報告和今年的 Puppet 調查問卷。
研究過程
報告只是最後一部分。 整個研究過程包括四個主要步驟：
在準備階段，我們採訪了行業專家並準備了一系列假設。 在此基礎上，編制了問題，並啟動了整個 6 月的調查。 然後我們分析並準備了報告本身。 對於DORA，這個過程需要3個月。 我們在 XNUMX 個月內會面，現在我們明白我們幾乎沒有足夠的時間：只有通過執行分析，您才能了解需要提出的問題。
與會者
所有國外報導都以參與者的肖像開頭，而且大多數都不是來自俄羅斯。 俄羅斯受訪者的百分比每年在 5% 到 1% 之間波動，因此無法得出任何結論。
來自 2019 年 DevOps 加速狀態報告的地圖：
在我們的研究中，我們設法採訪了 889 人 - 這是相當多的（DORA 在其報告中每年對大約 XNUMX 人進行民意調查），我們已經實現了目標：
誠然，並非我們所有的參與者都到達了終點：結果證明完成百分比略低於一半。 但即使這樣也足以獲得代表性樣本並進行分析。 DORA 並沒有在其報告中披露填充百分比，因此這裡沒有進行比較。
行業和崗位
我們的受訪者代表十幾個行業。 一半從事信息技術工作。 其次是金融服務、貿易、電信和其他。 這些職位包括專家（開發人員、測試人員、運維工程師）和管理人員（團隊、小組、領域、主管的負責人）：
二分之一的人在一家中型公司工作。 每三分之一的人在大公司工作。 大多數人在最多 9 人的團隊中工作。 另外，我們詢問了主要活動，大部分與運營有關，約 40% 從事開發：
所以我們收集了不同行業、公司、團隊代表的信息進行比較分析。 我的同事維塔利·哈巴羅夫 (Vitaly Khabarov) 將講述這項分析。
分析比較
Vitaly Khabarov：非常感謝所有完成我們調查、填寫問卷並為我們提供數據以進一步分析和檢驗我們假設的參與者。 感謝我們的客戶和客戶，我們擁有豐富的經驗，這些經驗有助於確定行業問題並製定我們在研究中測試的假設。
不幸的是，你不能一方面列出問題，另一方面列出數據，以某種方式比較它們，說：“是的，一切都是這樣，我們是對的”然後分散。 不，需要方法學和統計方法來確保我們沒有弄錯，我們的結論是可靠的。 然後我們可以根據這些數據構建我們的進一步工作：
關鍵指標
我們以 DORA 方法論為基礎，他們在《Accelerate State of DevOps》一書中對此進行了詳細描述。 我們檢查了關鍵指標是否適合俄羅斯市場，是否可以像 DORA 一樣使用它們來回答這個問題：“俄羅斯的行業如何與外國行業相對應？”
關鍵指標：
- 部署頻率。 將應用程序的新版本部署到生產環境的頻率如何（計劃的更改，不包括修補程序和事件響應）？
- 交貨時間。 從提交更改（將功能編寫為代碼）到將更改部署到生產環境之間的平均時間是多少？
- 恢復時間。 在發生事件、服務降級或發現影響應用程序用戶的錯誤後，將應用程序恢復到生產環境平均需要多長時間？
- 不成功的改變。 生產環境中有多少部署會導致應用程序降級或事件並需要補救（回滾更改、開發修補程序或補丁）？
DORA 在其研究中發現了這些指標與組織績效之間的聯繫。 我們也在研究中對其進行了測試。
但要確保這四個關鍵指標能夠產生影響，您需要了解 - 它們之間是否存在某種關聯？ DORA 的回答是肯定的，但有一個警告：不成功的更改（更改失敗率）與其他三個指標之間的關係稍弱。 我們得到了幾乎相同的照片。 如果交付時間、部署頻率和恢復時間相互關聯（我們通過 Pearson 相關和通過 Chaddock 量表建立了這種關聯），那麼不成功的變更就沒有那麼強的關聯。
原則上，大多數受訪者傾向於回答他們在生產中發生的事件數量很少。 儘管我們稍後會看到，在不成功的更改方面，各組受訪者之間仍然存在顯著差異，但我們還不能將此指標用於此劃分。
我們將此歸因於這樣一個事實（正如在與我們的一些客戶進行分析和溝通過程中所證明的那樣），對什麼是事件的看法存在細微差別。 如果我們設法在技術窗口期間恢復了我們的服務性能，這是否可以視為事件？ 可能不會，因為我們解決了所有問題，我們很棒。 如果我們必須以我們熟悉的正常模式重新滾動我們的應用程序 10 次，我們可以認為這是一個事件嗎？ 好像沒有。 因此，不成功的更改與其他指標的關係問題仍然懸而未決。 我們將進一步完善它。
這裡重要的是，我們發現交付時間、恢復時間和部署頻率之間存在顯著相關性。 因此，我們採用這三個指標將受訪者進一步劃分為績效組。
以克為單位掛多少錢？
我們使用層次聚類分析：
- 我們將受訪者分佈在一個 n 維空間中，每個受訪者的坐標就是他們對問題的回答。
- 每個受訪者都被宣佈為一個小集群。
- 我們將彼此最接近的兩個集群合併為一個更大的集群。
- 我們找到下一對集群並將它們組合成一個更大的集群。
這就是我們將所有受訪者分組到我們需要的集群數量的方式。 借助樹狀圖（集群之間的連接樹），我們可以看到兩個相鄰集群之間的距離。 留給我們的只是在這些星團之間設置一定的距離限制，然後說：“這兩個星團彼此之間的區別很大，因為它們之間的距離是巨大的。”
但是這裡有一個隱藏的問題：我們對簇的數量沒有限制——我們可以得到 2、3、4、10 個簇。 第一個想法是——為什麼不像 DORA 那樣將所有受訪者分成 4 組。 但我們發現這些群體之間的差異變得微不足道，我們無法確定受訪者是否真的屬於他的群體，而不是鄰近的群體。 我們還不能將俄羅斯市場分為四組。 因此，我們確定了三個配置文件，它們之間存在統計學上的顯著差異：
接下來，我們按集群確定配置文件：我們為每個組獲取每個指標的中值，並編制了一個性能配置文件表。 事實上，我們得到了每組參與者的平均表現概況。 我們確定了三種效率配置文件：低、中、高：
在這裡，我們證實了我們的假設，即 4 個關鍵指標適用於確定績效概況，並且它們在西方和俄羅斯市場都適用。 各組之間存在差異，並且具有統計學意義。 我強調，就平均值而言的不成功更改指標而言，績效概況之間存在顯著差異，即使我們最初並未按此參數劃分受訪者。
那麼問題來了：如何使用這一切？
如何使用
如果我們將任何團隊的 4 個關鍵指標應用到表格中，那麼在 85% 的情況下我們不會得到完全匹配——這只是一個普通的參與者，而不是現實中的情況。 我們所有人（以及每個團隊）都略有不同。
我們檢查了：我們獲取了我們的受訪者和 DORA 績效概況，並查看了有多少受訪者符合這個或那個概況。 我們發現只有 16% 的受訪者肯定屬於其中一種概況。 所有其餘的都分散在兩者之間的某個地方：
這意味著效率概況的範圍有限。 要了解您在第一個近似值中的位置，您可以使用此表：“哦，看來我們更接近中等或高！” 如果您知道下一步要去哪裡，這可能就足夠了。 但如果你的目標是不變的，持續的改進，你想更準確地知道在哪裡發展，做什麼，那麼就需要額外的資金。 我們稱他們為計算器：
- 多拉計算器
- 計算器 Express 42*（開發中）
- 自己開發（您可以創建自己的內部計算器）。
他們需要什麼？ 理解：
- 我們組織內的團隊是否符合我們的標準？
- 如果沒有，我們可以幫助它，在我們公司擁有的專業知識框架內加快速度嗎？
- 如果是這樣，我們可以做得更好嗎？
您還可以使用它們來收集公司內部的統計數據：
- 我們有哪些團隊？
- 將團隊劃分為配置文件；
- 看到：哦，這些命令表現不佳（他們一點兒也沒有拉出來），但是這些很酷：他們每天都部署，沒有錯誤，他們的交付時間不到一個小時。
然後您會發現，在我們公司內部，對於那些尚未達到標準的團隊，有必要的專業知識和工具。
或者，如果你明白你在公司內部感覺很棒，你比很多人都好，那你就可以把眼光放寬一點。 這只是俄羅斯工業：我們能否獲得俄羅斯工業的必要專業知識以加速我們自己的發展？ Express 42 計算器將在此處提供幫助（正在開發中）。 如果你已經超出了俄羅斯市場，那麼看看 並走向世界市場。
美好的。 如果你在 DORA 計算器上屬於 Elit 組，你應該怎麼做？ 這裡沒有好的解決辦法。 你很可能處於行業的前沿，通過內部研發和投入更多資源可以進一步加速和提高可靠性。
讓我們繼續進行最甜蜜的比較。
對照
我們最初想將俄羅斯工業與西方工業進行比較。 如果我們直接比較，我們會發現我們的配置文件更少，而且它們彼此混合得更多，邊界更模糊：
我們的精英表演者隱藏在高績效者中，但他們就在那裡——這些是精英，達到了顯著高度的獨角獸。 在俄羅斯，精英形象和高級形象之間的差異還不夠明顯。 我們認為，由於工程文化、工程實踐實施質量和公司內部專業知識的增加，這種分離將在未來發生。
如果我們繼續在俄羅斯行業內進行直接比較，我們可以看到 High profile 團隊在各個方面都更好。 我們還證實了我們的假設，即這些指標與組織績效之間存在關係：知名度高的團隊不僅更有可能實現目標，而且更有可能超越目標。
讓我們成為高知名度的團隊，而不是止步於此：
但今年很特別，我們決定檢查公司在大流行病中的表現：知名團隊的表現和感覺都比行業平均水平好得多：
- 發布新產品的可能性提高 1,5-2 倍，
- 提高應用程序基礎設施的可靠性和/或性能的可能性提高 2 倍。
也就是說，他們已經擁有的能力幫助他們更快地開發、推出新產品、修改現有產品，從而征服新市場和新用戶：
還有什麼幫助了我們的團隊？
工程實踐
我將告訴您我們測試的每項實踐的重要發現。 也許其他東西對團隊有幫助，但我們正在談論 DevOps。 在 DevOps 中，我們看到了不同配置文件的團隊之間的差異。
平台即服務
我們沒有發現平台年齡與團隊概況之間存在顯著關係：低團隊和高團隊的平台幾乎同時出現。 但對於後者，平台平均提供了更多的服務和更多的編程接口，通過程序代碼進行控制。 平台團隊更有可能幫助他們的開發人員和團隊使用該平台，更頻繁地解決他們的問題和與平台相關的事件，並教育其他團隊。
基礎設施即代碼
這裡的一切都很標準。 我們發現基礎設施代碼工作的自動化與基礎設施存儲庫中存儲的信息量之間存在關係。 High profile 命令在存儲庫中存儲更多信息：這是基礎設施配置、CI/CD 管道、環境設置和構建參數。 他們更頻繁地存儲這些信息，更好地處理基礎設施代碼，並自動化更多處理基礎設施代碼的流程和任務。
有趣的是，我們沒有看到基礎設施測試有顯著差異。 我將此歸因於這樣一個事實，即 High profile 團隊通常擁有更多的測試自動化。 也許他們不應該被基礎設施測試單獨分散注意力，而應該被他們用來檢查應用程序的那些測試分散注意力，多虧了他們，他們已經看到了他們破壞的地方和地方。
整合與交付
最無聊的部分，因為我們確認您擁有的自動化程度越高，您對代碼的處理就越好，您就越有可能獲得更好的結果。
架構
我們想了解微服務如何影響性能。 事實上，他們沒有，因為微服務的使用與性能指標的增加無關。 微服務用於高配置命令和低配置命令。
但重要的是，對於高級團隊而言，向微服務架構的過渡使他們能夠獨立開發服務並推出。 如果該架構允許開發人員自主行動，而無需等待團隊外部人員，那麼這就是提高速度的關鍵能力。 在這種情況下，微服務會有所幫助。 只是他們的實施並沒有起到很大的作用。
我們是如何發現這一切的？
我們有一個雄心勃勃的計劃來完全複製 DORA 方法，但缺乏資源。 如果DORA用了很多贊助，他們的研究需要半年的時間，我們在很短的時間內完成了研究。 我們想像 DORA 那樣構建 DevOps 模型，我們將在未來這樣做。 到目前為止，我們僅限於熱圖：
我們查看了每個配置文件中跨團隊的工程實踐分佈，發現平均而言，知名度高的團隊更有可能使用工程實踐。 您可以在我們的網站上閱讀更多關於這一切的信息 .
為了改變，讓我們從復雜的統計數據切換到簡單的統計數據。
我們還發現了什麼？
工具
我們觀察到大多數命令都是由 Linux 系列的操作系統使用的。 但 Windows 仍處於流行趨勢 - 至少四分之一的受訪者指出使用其中一個或另一個版本。 市場似乎有這個需求。 因此，您可以培養這些能力並在會議上發表演講。
在編排器中，這對任何人來說都不是秘密，Kubernetes 處於領先地位 (52%)。 排在第二位的編排器是 Docker Swarm（約佔 12%）。 最流行的 CI 系統是 Jenkins 和 GitLab。 最流行的配置管理系統是 Ansible，其次是我們鍾愛的 Shell。
亞馬遜目前是領先的雲託管提供商。 俄羅斯雲的份額正在逐漸增加。 明年，看看俄羅斯雲提供商的感受，以及他們的市場份額是否會增加，將會很有趣。 它們是，它們可以被使用，這很好：
我將發言權交給 Igor，他將提供更多統計數據。
實踐的傳播
Igor Kurochkin：另外，我們要求受訪者說明所考慮的工程實踐在公司中的分佈情況。 在大多數公司中，有一種混合方法，由一組不同的模式組成，並且試點項目非常受歡迎。 我們還看到配置文件之間存在細微差別。 當專家小組改變工作流程、工具並與其他團隊分享成功實踐時，高知名度的代表更經常使用“自下而上的倡議”模式。 在 Medium，這是一項自上而下的舉措，通過創建社區和卓越中心影響整個公司：
敏捷和 DevOps
Agile 和 DevOps 之間的聯繫問題在業界經常被討論。 2019/2020 年敏捷狀態報告中也提出了這個問題，因此我們決定比較敏捷和 DevOps 活動在公司中的聯繫方式。 我們發現沒有敏捷的 DevOps 是很少見的。 對於一半的受訪者來說，敏捷的傳播開始得更早，大約 20% 的人觀察到同時開始，低調的標誌之一是缺乏敏捷和 DevOps 實踐：
命令拓撲
去年年底，這本書“”，它提出了一個描述命令拓撲的框架。 它是否適用於俄羅斯公司對我們來說很有趣。 我們問了一個問題：“你發現了什麼模式？”。
一半的受訪者觀察到基礎設施團隊，以及獨立的開發、測試和運營團隊。 獨立的 DevOps 團隊指出了 45%，其中 High 的代表更為常見。 接下來是跨職能團隊，這在高中也很常見。 單獨的 SRE 命令出現在高、中配置文件中，很少出現在低配置文件中：
DevQaOps 比率
我們在 FaceBook 上看到了 Skyeng 平台團隊組長的這個問題——他對公司中開發人員、測試人員和管理員的比例很感興趣。 我們詢問並查看了基於配置文件的響應：高配置代表為每個開發人員配備的測試和運營工程師較少：
2021年計劃
在明年的計劃中，受訪者指出了以下活動：
在這裡可以看到與DevOps Live 2020大會的交集，我們仔細回顧了節目：
- 基礎設施即產品
- DevOps 轉型
- DevOps 實踐分佈
- 開發安全
- 案例俱樂部和討論
但是我們的演講時間不足以涵蓋所有主題。 留在幕後：
- 平台即服務和產品；
- 基礎設施即代碼、環境和雲；
- 持續集成與交付；
- 建築學;
- DevSecOps 模式；
- 平台和跨職能團隊。
我們有 50 頁的大部頭，您可以更詳細地查看它。
總結
我們希望我們的研究和報告能夠激勵您嘗試新的開發、測試和運營方法，並幫助您導航、與研究中的其他參與者進行比較，並確定您可以改進自己方法的領域。
俄羅斯 DevOps 狀況的第一項研究結果：
- 關鍵指標。 我們發現關鍵指標（交付時間、部署頻率、恢復時間和變更失敗）適用於分析開發、測試和運營流程的有效性。
- 配置文件高、中、低。 根據收集到的數據，我們可以在統計上區分高、中、低的不同組別，在指標、實踐、流程和工具方面具有鮮明的特徵。 High profile 的代表顯示出比 Low 更好的結果。 他們更有可能實現並超越他們的目標。
- 2021 年的指標、流行病和計劃。 今年的一個特殊指標是企業如何應對疫情。 高級代表表現更好，用戶參與度更高，成功的主要原因是高效的開發流程和強大的工程文化。
- DevOps 實踐、工具及其開發。 企業明年的主要計劃包括DevOps實踐和工具的開發、DevSecOps實踐的引入以及組織架構的改變。 DevOps 實踐的有效實施和發展是在試點項目、社區和卓越中心的形成、公司上下層的倡議的幫助下進行的。
我們很想听聽您的反饋、故事和反饋。 我們感謝所有參與研究的人，並期待您明年的參與。
來源： www.habr.com