企業(yè) DevOps 落地實踐經(jīng)驗分享
來源：InfoQ架構(gòu)師頭條
鏈接：https://mp.weixin.qq.com/s/uMAh-uqerEpLtrrp-UYTTw
DevOps 始于 2009 年，這種范式讓許多組織能夠加快軟件交付速度和提升業(yè)務(wù)績效，正如“Accelerate 報告”及其著名的 DORA 指標——速度、穩(wěn)定性和恢復——所描述的那樣。
敏捷首當其沖，與 DevOps 成為組合，在相同的工作流中平衡業(yè)務(wù)價值和技術(shù)交付。
最近的一些實踐，如可靠性或安全性，都采用了“SRE”和“DevSecOps”這兩個術(shù)語。
然而，來自 谷歌、Puppet、CircleCI 和 Dynatrace 等公司的各種 DevOps 狀態(tài)報告都揭示了他們對這個生態(tài)系統(tǒng)的一些相似的發(fā)現(xiàn)——難以持續(xù)及時交付業(yè)務(wù)價值和創(chuàng)新、孤立的團隊缺乏一致性、碎片化的工具鏈和質(zhì)量的犧牲。
本文將分享如何利用過去幾年積累的經(jīng)驗和實踐，通過質(zhì)量工程來改進 DevOps 范式，從而帶來更多的價值，并解決這些已知的痛點。
DevOps 沒有固定的宣言，理由很簡單——為演進留下空間。
“我們并沒有對 DevOps 做出確切的定義。我們讓它朝著各個方向擴展，研究不同方向之間的改進可能意味著什么。人們很糾結(jié) DevOps 究竟是應該是怎樣的?！薄狿atrick Debois，Snyk（之前的 DevOpsDays）顧問，摘自由 Puppet 和 CircleCI 提供的“2020 年 DevOps 狀態(tài)報告”
最初促進開發(fā)和運營流程的 DevOps 概念走向了多個方向。在安全性方向有了“DevSecOps”，在深入 研究企業(yè)實踐 后，谷歌甚至將可靠性作為指標的一部分添加了進去。
圖 1. DevOps 繼續(xù)在許多方向上發(fā)展演進
但當前生態(tài)系統(tǒng)中的創(chuàng)新和競爭在不斷提高參與者的門檻。一些新公司可以在 不到 3 個月的時間 里達到 10 億美元的估值，這給同一領(lǐng)域現(xiàn)有的公司帶來了壓力。因此，85% 的公司 感到有必要通過軟件來重塑他們的業(yè)務(wù)以求得生存。
對于許多組織來說，軟件交付仍然是一個業(yè)務(wù)限制因素。
圖 2.?軟件限制因素會直接對業(yè)務(wù)造成限制
因此，DevOps 目前的發(fā)展狀態(tài)水平還不夠高。業(yè)務(wù)價值、安全性和可靠性只是保持競爭力需要滿足的部分需求。平衡質(zhì)量和速度需要一個跨越整個軟件生命周期（從業(yè)務(wù)想法到運維）的范式轉(zhuǎn)換，要“構(gòu)建得更好，構(gòu)建得更快”。
要達到這一水平，DevOps 必須能夠發(fā)展到通過全速質(zhì)量軟件（Quality at Speed Software）在工程系統(tǒng)的所有領(lǐng)域?qū)崿F(xiàn)持續(xù)的價值交付。
DevOps 最初在從代碼到運維方面進行了大量改進，這導致出現(xiàn)了許多專注于加速開發(fā)團隊和運維團隊之間的流程的方法。
然后，敏捷和精益等方法與 DevOps 結(jié)合，以便用更高的效率更好地關(guān)注價值交付，旨在實現(xiàn)“全速軟件（Software at Speed）”。還增加了一些具體的要求，如持續(xù)性實踐，包括監(jiān)控、安全性或測試。
圖 3.即使有了 Accelerate 報告中所提及的發(fā)現(xiàn)，質(zhì)量需求也只是剛剛開始被考慮到
Accelerate 報告解釋了軟件交付和業(yè)務(wù)結(jié)果之間的正相關(guān)關(guān)系，定義了執(zhí)行者類別——“精英”執(zhí)行者們每天穩(wěn)定地進行多次發(fā)布。
但隨著每天多次交付成為當今競爭的常態(tài)，只能通過交付更多的價值來獲得競爭優(yōu)勢。因此，DevOps 必須進行轉(zhuǎn)變，以便更好地與現(xiàn)有方法集成，創(chuàng)建全速質(zhì)量（Quality at Speed）流程。
圖 4.DevOps 必須簡化質(zhì)量流程
第一個改變是綜合“從客戶到代碼”和“從代碼到客戶”這兩個數(shù)字轉(zhuǎn)型流程，正如米其林集團首席信息官 Yves Caseau 在《數(shù)字轉(zhuǎn)型的精益方法》一書中所說的那樣。
DevOps 必須從一開始就將敏捷、全面質(zhì)量和精益啟動與全局視角相結(jié)合。將用戶描述與 CI/CD 平臺中的代碼部署聯(lián)系起來只是一個開始。共享的工作方式和支持工具必須進行更好地集成，以便實現(xiàn)更快、更有價值的從業(yè)務(wù)想法到運維的迭代。
第二個改變是創(chuàng)建專門的實驗、核心業(yè)務(wù)和技術(shù)平臺價值流。 與 DevOps 打破端到端孤島的思維模式保持一致，每個流必須能夠相互解耦迭代，以確保它們對質(zhì)量和速度的需求能夠得到滿足。
圖 5.左移是實現(xiàn)全速質(zhì)量軟件的范式之一?
SRE 和 DevOps 是專門用于滿足可靠性和安全性非功能性需求的流程。后續(xù)的演進目標是滿足軟件生命周期中的其他需求，如可觀察性、可用性和可持續(xù)性，避免無法實現(xiàn)它們或試圖在之后通過高成本的返工來恢復。
最后一個改變是系統(tǒng)性地應用端到端價值流約束理論。 整個生命周期中最薄弱的一點是確定 整個系統(tǒng) 的質(zhì)量和速度水平，價值流映射和移除限制因素必須成為 DevOps 改進習慣的一部分。
雖然這些演進改進了協(xié)作流程，獲得了更多價值，但預期的加速需要的不僅僅是方法。技術(shù)必須讓組織能夠快速地演化和采用軟件。
為了支持更快的迭代，DevOps 非常強調(diào)集成和部署階段的自動化。部署自動化通過為開發(fā)人員提供原生管道提升了軟件質(zhì)量，并降低了總體維護成本。2020 年 Puppet 報告 顯示，超過 60% 的公司表示他們的 DevOps 處于中期演進階段。
圖 6.GitLab 2022 年全球 DevSecOps 調(diào)查報告顯示，現(xiàn)代 DevOps 提升了安全性，但缺乏集成?
好的方面是在利用技術(shù)和思維方式的變化為開發(fā)人員提供自助服務(wù)功能方面取得了進展。所有這些逐步利用云原生功能的自動化經(jīng)驗讓我們能夠更好地設(shè)想目標架構(gòu)，從而幫助我們實現(xiàn)“更好、更快的構(gòu)建”。
通過自助服務(wù)改進的自動化和協(xié)作生成了更多關(guān)于流程執(zhí)行、性能和交互的數(shù)據(jù)。隨著運維數(shù)據(jù)科學的不斷成熟，部署的 MLOps 和 AIOps 組件將能夠提供跨生命周期的持續(xù)可見性和自動化，就像 Sealights 那樣。
圖 7.DevOps 架構(gòu)必須整合全速質(zhì)量平臺
DevOps 轉(zhuǎn)變需要整合以下這些平臺。
基礎(chǔ)設(shè)施平臺；
開發(fā)者平臺；
實驗平臺。
每一個平臺都是在彼此的基礎(chǔ)上逐步成熟，以最小的承諾和返工來滿足質(zhì)量要求。這種漸進式實現(xiàn)就是所謂的 最小可行架構(gòu)，通過交付最小的架構(gòu)增量來支持產(chǎn)品迭代，實現(xiàn)更好的目標匹配和更快的采用。
基礎(chǔ)設(shè)施平臺 讓運維團隊能夠通過自動化和云能力來提升生產(chǎn)力。這些改進可以用于構(gòu)建 開發(fā)者平臺，支持更快的核心業(yè)務(wù)變更迭代，同時又能滿足多種質(zhì)量需求，包括功能可用性、性能和安全性。
然后，業(yè)務(wù)可以利用滿足質(zhì)量需求的軟件交付加速周期來迭代業(yè)務(wù)變更。在這個階段，公司可以主張獨特的價值，并且可以通過實驗平臺提供的自助工具和集成解決方案更快地實現(xiàn)它們。
圖 8.Uber的實驗平臺
構(gòu)建基礎(chǔ)設(shè)施的工程師、開發(fā)人員和實驗平臺都要將用戶視為他們的客戶。每個平臺的滿意度和性能直接與它們試驗和改進業(yè)務(wù)的能力掛鉤，并最終提供良好的用戶體驗。
MACH（微服務(wù)、API、云、Headless）架構(gòu)顯著提升了平臺組件的模塊化、可組合性和可伸縮性。它不再是關(guān)于構(gòu)建孤立的模塊和框架，而是關(guān)于構(gòu)建可伸縮的平臺，為企業(yè)價值交付的加速周期提供支持。
這種技術(shù)轉(zhuǎn)變需要團隊在同一個愿景上保持一致，具備使其成為現(xiàn)實的靈感和動力，克服組織的阻力，并有效地改變在軟件生命周期中參與協(xié)作的參與者的習慣。
這里是管理發(fā)揮關(guān)鍵作用的地方。
Puppet 的 DevOps 報告 中提到了讓公司陷在 DevOps 轉(zhuǎn)變中間階段的文化障礙——阻礙冒險（21%）、責任不明確（20%）、缺乏快速確定優(yōu)先級的能力（18%）——導致反饋循環(huán)不足，限制了公司加快價值主張的速度。
成功實現(xiàn) DevOps 轉(zhuǎn)變的公司明白，有效的管理對于打破現(xiàn)有的藩籬并實現(xiàn)更快的迭代流程是必要的。但是，從遺留文化模型到 DevOps 模型的重大轉(zhuǎn)變讓許多管理人員被困在技術(shù)和工程問題的泥潭里。
DevOps 團隊需要專注于他們的工作，以便提高組織的成熟度和改進組織流程。然而，這導致一些人認為 DevOps 只是與工程問題有關(guān)。為了對迭代的端到端流程產(chǎn)生更大的影響，并交付更多的業(yè)務(wù)價值，管理者必須走出他們的舒適區(qū)。
圖 9.DevOps 中的管理轉(zhuǎn)變必須是端到端的，并且能夠增加價值交付
DevOps 中的管理者角色必須改變其定位。
提升（Shift Up）DevOps 的價值定位并增加交付；
分享愿景，為產(chǎn)出結(jié)果賦能；
驅(qū)動端到端轉(zhuǎn)型變化。
Shift Up 這個概念 來自軟件質(zhì)量，軟件質(zhì)量的定義、溝通和度量是在運維團隊之外完成的，以使整個組織系統(tǒng)在質(zhì)量需求上保持一致。例如，與 C 級高層、總監(jiān)和業(yè)務(wù)線經(jīng)理協(xié)作定義軟件產(chǎn)品的質(zhì)量需求。
其好處是通過讓關(guān)鍵利益相關(guān)者對每個角色的價值和對軟件產(chǎn)品的期望保持一致來改進變更管理。然后利用這個共識來獲得必要的投資和支持，以實現(xiàn)質(zhì)量需求和組織變化，特別是當它們涉及到技術(shù)時。
要讓 DevOps 成為實現(xiàn)成功的數(shù)字化轉(zhuǎn)型的必要條件也需要同樣的轉(zhuǎn)變。鳳凰項目就是一個很好的例子，它向我們展示了 DevOps 是如何幫助改進業(yè)務(wù)的。推動 DevOps 的管理者必須走出他們的舒適區(qū)，與業(yè)務(wù)利益相關(guān)者互動，促進一種觀念上的改變——即 DevOps 不是關(guān)于工程，而是關(guān)于加速業(yè)務(wù)再造。
第二個關(guān)于管理上的改變是在公司的所有團隊之間系統(tǒng)地共享 DevOps 愿景，而不是將想法局限在工程領(lǐng)域。這種鼓舞人心的愿景必須涉及業(yè)務(wù)目標、設(shè)想的未來、即將到來的變化、風險和計劃，這有助于團隊實現(xiàn)這些變化。
圖 10.DevOps 管理必須消除最重要的限制因素?
這就要求管理者關(guān)注端到端的領(lǐng)導力變革。他們首先需要實現(xiàn)控制管理，為他們的團隊賦能，解決跨組織的障礙，并改進業(yè)務(wù)價值交付。他們必須適當?shù)胤峙涔ぷ鳎苿幼畲蟪潭鹊淖兓l(fā)生。例如，當團隊需要花費幾天或幾周時間定義規(guī)范時，卻花時間在改進只能減少幾分鐘時間的自動化上。
管理層還要負責讓組織保持一致，創(chuàng)建與目標業(yè)務(wù)架構(gòu)保持一致的生態(tài)系統(tǒng)。
許多公司的重組都會更新可視化的組織結(jié)構(gòu)圖，但沒有做日常的業(yè)務(wù)做出任何改變。他們通常試圖讓每個人都參與進來，讓他們感受到“參與”和“包容”，但卻未能給陷入重組周期的公司帶來持久的變化和改善。
表面的重組有一個共同的問題，那就是沒有讓組織與流程保持一致，缺乏對不斷變化的交互和強有力決策的關(guān)注，比如哪些團隊應該首先做出改變，哪些職責必須發(fā)生改變，以及如何實現(xiàn)有效的責任模型。
DevOps 組織是關(guān)于如何實現(xiàn)業(yè)務(wù)再造。
圖 11.DevOps 組織必須在以產(chǎn)品為中心的組織中與業(yè)務(wù)相結(jié)合
為了擴大 DevOps 的影響，必須進行結(jié)構(gòu)化的改變。
定義真正的產(chǎn)品組織；
建立真正的“平臺即產(chǎn)品”團隊；
與職責模型保持一致。
要讓公司采用產(chǎn)品組織模式，首先需要消除“產(chǎn)品管理”（即業(yè)務(wù)）和“產(chǎn)品工程”（即“IT”）的藩籬，從全局考慮問題。這種人為的分離仍然在許多組織中存在，讓人們覺得藩籬仍然很重要，從而限制了溝通互動，造成了許多低效率的放任。
團隊必須作為單一的跨職能單位，在擁有端到端流程全部所有權(quán)的地方專注價值流的交付。挑戰(zhàn)在于如何組合團隊，以滿足他們職責范圍內(nèi)的特定質(zhì)量需求。例如，致力于用戶體驗的部門與財務(wù)后臺部門所面臨的挑戰(zhàn)是不一樣的。
實現(xiàn) DevOps 產(chǎn)品組織的第二個變化是采用《團隊拓撲》一書中所描述的“平臺即產(chǎn)品”方法。其目標是通過逐步創(chuàng)建一個提供自助服務(wù)平臺、支持跨職能團隊的專業(yè)角色或交付領(lǐng)導角色的平臺團隊讓 團隊的結(jié)構(gòu) 和交互與目標架構(gòu)保持一致。
圖 12.用團隊拓撲建立全速質(zhì)量增量組織?
為了實現(xiàn)上述的措施奏效，領(lǐng)導層必須做出強有力的投資決策，并向組織闡明這些投資決策。由于資源有限，公司不得不對投資做出權(quán)衡，但過多的妥協(xié)會導致績效降低，遠遠達不到要求。
領(lǐng)導層必須決定哪些團隊獲得更多的資源——甚至可以超出保證服務(wù)持續(xù)性所需的資源，而讓一些團隊仍然使用有限的資源。他們需要闡明哪些團隊必須為復雜的子系統(tǒng)（如單體系統(tǒng)）盡最大努力地工作，或者哪些決策仍然是中心決策，如為了保持一致性而采用的中心架構(gòu)。
近來的演變還包括為實現(xiàn)“全速質(zhì)量”目標而出現(xiàn)的特定角色?！敖桓端姓摺必撠焹r值交付流程，“實踐領(lǐng)導者”負責高標準地開發(fā)專業(yè)技能，并確保知識得到共享。
組織一致性是促進和維持業(yè)務(wù)和架構(gòu)轉(zhuǎn)變的主要動力之一。在日常工作中，結(jié)構(gòu)和交互的定義依賴于技術(shù)，但主要還是依賴于參與者跨生命周期的協(xié)作。最后一個重要的轉(zhuǎn)變是技能。
對 DevOps 技能的關(guān)注反映了生態(tài)系統(tǒng)的成熟度，對“云工程師”的培訓側(cè)重于自動化、基礎(chǔ)設(shè)施即代碼，或特定的云服務(wù)部署。雖然這些基本能力都是必要的，但還不足以為公司再造提供足夠的質(zhì)量和速度。
圖 13.DevOps 路線圖仍然停留在較底層的技術(shù)上（LinkedIn）
面臨的一個主要挑戰(zhàn)是技能專業(yè)化雖然提升了質(zhì)量，但同時也降低了交付速度。一方面，專業(yè)知識引入了更多的垂直領(lǐng)域，如“SRE”或“安全性”，但由于技能之間存在區(qū)別，這些專業(yè)角色之間的協(xié)作變得更加困難，這可能會影響價值交付的速度。
全球技術(shù)人才稀缺不利于應對這一挑戰(zhàn)。組織努力吸引和保留轉(zhuǎn)型所需的人才，而全球都面臨著直接限制公司轉(zhuǎn)型的人才稀缺的壓力。一些重新轉(zhuǎn)化人才和簡化技術(shù)的措施有所幫助，但還不夠。
為了實現(xiàn)全速質(zhì)量，組織必須通過以下幾個要素來平衡技能。
靈活和開放的職業(yè)道路；
在可擴展的技能（即平臺）上的投入；
用于技能發(fā)展的專門資源。
第一個轉(zhuǎn)變是擁抱更靈活、更開放的職業(yè)道路。許多組織甚至為 DevOps 引入了 Taylorism 模型，為特定任務(wù)設(shè)置了“云工程師”職位。不過，在利用他們的互補技能的同時，他們可以學習工作的中部分內(nèi)容，從而讓公司能夠加速進一步的轉(zhuǎn)型。
“T 型”技能出現(xiàn)在那些能夠結(jié)合垂直技能（如軟件工程師）和水平技能（如敏捷）的人身上。研究表明，這種模式正在朝著“π型”甚至“梳子型”的方向發(fā)展，人們能夠結(jié)合多種專長，從而讓與個人的合作變得更加快速，并讓他們可以有更豐富的職業(yè)生涯。
圖 14.在一個持續(xù)學習的生態(tài)系統(tǒng)中，DevOps 技能獲得橫向發(fā)展
這種適應和持續(xù)學習的能力意味著組織必須改變范式和生態(tài)系統(tǒng)來支持這種變化。他們必須為指導計劃進行專門的投入，引入實踐領(lǐng)導的角色來激勵人們，并確保每周有系統(tǒng)的培訓時間，而不是一年一次。
其他的實踐，如實踐社區(qū)、會議和演講，對于培養(yǎng)一個有吸引力的生態(tài)系統(tǒng)來說仍然是很有用的。在這里，人們可以獲得自我發(fā)展。Zalando、Uber 或 Netflix 等公司成功地將開源作為吸引人才的方式，同時對產(chǎn)品進行內(nèi)源化，讓人才能夠在產(chǎn)品上進行全球性協(xié)作。
雖然并非所有的公司都有這些巨頭那樣的規(guī)模和資源，但所有的公司都可以直接在可重用和可擴展的技能上投入，如技術(shù)集成和平臺。在一個技術(shù)組件變成模塊化服務(wù)的生態(tài)系統(tǒng)中，公司需要構(gòu)建的東西將更少，需要組合的東西將更多。
這種跨越方法、架構(gòu)、管理、組織和技能領(lǐng)域的 DevOps 轉(zhuǎn)變要求整個軟件工程系統(tǒng)進行橫向的演進，以便實現(xiàn)持續(xù)的價值交付。
文化、方法和自動化都是 DevOps 的良好開端，但我們的競爭生態(tài)系統(tǒng)只會維持那些能夠通過全速質(zhì)量軟件迅速改造和擴展其價值主張的組織。
我們在想，基于這種演變，DevOps 是否還應該保持同樣的叫法，畢竟它超越了“Dev”和“Ops”的界限，并成為支持組織數(shù)字化轉(zhuǎn)型的不可或缺的支柱。
DevOps 的未來是 質(zhì)量工程。
- END -
?推薦閱讀? 30天拿下高含金量K8s CKA+CKS雙認證！? Wireshark 找出 TCP 吞吐瓶頸 K8s Kubectl集群管理工具使用技巧 K8S 常用資源 YAML 詳解 DevOps與CI/CD常見面試問題匯總 我會在Docker容器中抓包了！ 19 個 K8S集群常見問題總結(jié)，建議收藏 運維高可用架構(gòu)的 6 大常規(guī)方案 運維監(jiān)控指標全方面總結(jié) 9 個實用 Shell 腳本，建議收藏！ 詳解 K8S Helm CI/CD發(fā)布流程 ES+Redis+MySQL，這套高可用架構(gòu)設(shè)計太頂了！ 一臺服務(wù)器最大能支持多少條TCP連接？ K8S運維必知必會的 Kubectl 命令總結(jié) 16 張圖硬核講解 Kubernetes 網(wǎng)絡(luò) 史上最全 Jenkins Pipeline流水線詳解 主流監(jiān)控系統(tǒng) Prometheus 學習指南 搭建一套完整的企業(yè)級 K8s 集群（二進制方式） 40個 Nginx 常問面試題 Linux運維工程師 50個常見面試題 點亮，服務(wù)器三年不宕機
