Categories
程式開發

DevOps 10年:你是不是忘了DevOps中的Ops


本文要點

  • DevOps的核心前提是讓開發和運維能夠協作,以加快兩者的速度。
  • 在開發和運維之間使用相同的工具棧可以讓他們產生共鳴並共享相同的語言。
  • “運維”是一個內涵豐富的概念,組織在進行DevOps轉換之前,需要從業務和技術的視角理解它的含義。
  • 儘管容器是一項偉大的技術,但是它也拉大了團隊之間的距離。
  • 在DevOps轉換時,忽略運維人員是取敗之道。

在DevOps的初期,當我們在歐洲舉辦第一次devopsdays會議時,感覺社區的一部分主要來自有運維背景的人,他們所討論的是如何減少停機時間、加速部署和提高平台的穩定性,從而提高他們的生活質量。

接下來我將回顧一下在過去的十年間DevOps的簡要歷史(其中有像戰爭那樣的故事),包括它的成就和缺點。

創新者接受開發和運維的協作

在2009年,我們中的很多人都遇到過這樣的情景:開發團隊將不可用的製件拋出了牆外並希望運維人員能夠解決它。我們疲於處理開發團隊所造成的副作用,而忽略了他們將代碼提交到版本控制後需要發生的事情。

與此同時,老舊的手工運維已經無法滿足我們的擴展需求了。借助虛擬化,組織正在從數台物理服務器轉變成數百個虛擬機。在早期的devopsdays會議上,我們討論的話題包括基礎設施即代碼、構建自動化、監控和度量的改善以及如何發揮敏捷、開源和雲的威力。

而另一方面,社區的另外一部分人是想要變得更快的開發人員,他們將運維人員視為瓶頸。他們需要更好的平台、更快的響應時間以及更便捷的可擴展性。

這兩組人都意識到協作才是前進的方向。開發人員如果不提前與運維人員討論他們的需求,那麼就不會得到他們想要的平台。同時,運維人員如果不提前與開發人員討論他們的需求的話,運維人員也不可能得到易於在生產環境運維的製件。因此,筒倉(silo)被焚毀,而橋樑搭建了起來,來自整個組織的具有不同技能的人員開始在跨功能的團隊中協同工作。軟件交付對每個人來說都變得更加連續和平滑。 DevOps的時代已經到來。

早期的採用者改變了他們的工作方式

隨後,人們開始關注那些成功的DevOps早期實踐者,並且想知道我們為何不能像他們那樣工作,我們為何不能更快地交付,我們為何不能構建更穩定的平台。

第一個“DevOps轉換”開始出現。大型組織想要和那些“酷”孩子一樣。有些人意識到敏捷和交付速度對他們的業務至關重要。而其他人則只想僱傭已經在“做DevOps”的酷孩子。

這些大型組織意識到他們需要演進,這就邁出了第一步。但是,改變是很困難的,而且很多宣稱成功的“DevOps轉換”並沒有達到預期。對於在一線工作的團隊來講,並沒有什麼根本的改變。

每個組織都有自己的挑戰和歷史。要達到幸福的彼岸,他們所要選取的道路也是不同的。但是,直到今天,我依然看到很到組織都聲稱他們想要改變,而在他們的轉變計劃中並沒有將運維人員包含進來。將運維人員從對話中排除出去的話,他們該怎樣“做DevOps”呢?在他們的DevOps轉換中,運維人員該處於什麼位置呢?

我參與的第一個項目是幫助一個組織實現“更加DevOps”,這是一家150人組成的SaaS平台公司,他們在部署到生產環境並保持其技術棧啟動和運行方面遇到了嚴重的問題。他們高速增長,失去了對基礎設施和部署的控制。他們所面對的是一片混亂,每個人都在互相指責。在這個過程中,我們所做的第一件事就是向運維人員講解基礎設施即代碼以及持續交付。我們知道,在後續的流程中,運維團隊將負責支持開發人員,以實現業務應用的持續交付。

現在,因為運維人員理解了CI/CD的基礎知識,並且開始使用與開發人員相同的工具,所以在對事情的理解方面,他們有了共識。運維人員更好地理解了需要交付什麼內容:製件應該是什麼樣子的,在部署中要涉及到哪些階段,以及開發人員選擇的工具如何提供幫助。開發人員和運維人員之間的鴻溝消除了,至少大幅度縮小了。雙方現在使用共同的語言,使用相同的工具,並且朝著建立(更好的)協作和理解的文化邁出了重要的一步。

早期大多數人所識別出的局限性

我目睹的下一個大規模轉變並不包含運維人員。在該組織中,甚至沒有明確從DevOps的視角來看,運維到底意味著什麼。有些人編寫代碼,而另外一些人則從業務角度(比如,在目錄中添加新的產品)“運維”該應用程序。對於他們來說,將具有這兩種技能的人組合到一個團隊中就是DevOps,但是仍然沒有人負責高度技術化的運維領域。我花了18個月的時間,終於遇到了一位工程師,從技術角度來看,我認為他有資格成為運維人員。

這位擁有深厚運維知識的人“忙於”在生產環境救火,而且在這個大型組織的DevOps轉換談話中,並沒有將他包含進來。他在不同的大樓中為不同的法人實體工作,儘管是集團中的一員,但是他還是因為缺少動力而決定離職了。然而,組織卻依然聲稱要進行“DevOps”。

在這個案例中,我們採取的措施是讓一定數量的專家退出,他們實際上是工作流程中的瓶頸(如果你讀過《鳳凰項目》一書的話,會明白這就是書中“Brent”的角色)。我們要求他們基於Scrum的方式構建基礎設施即代碼的新組件。我們甚至帶著他們去了另外一座城市,這樣他們就不會被老同事打擾了。幾個月之後,他們重新回到之前的團隊,但是現在他們有了全新的工作方式。即便是最老的Unix系統管理員也變成了敏捷的佈道師,他們都宣傳技術設施即代碼的方式,而不是手動為生產環境打補丁。

後期的大多數人過於關注工具

我最近為一家大型的金融機構進行了培訓。我被拉過來對他們的DevOps轉換進行健康檢查。我很快就听到很多DevOps教練都提到他們不允許和運維人員交談。他們告訴我運維是由另外一家公司負責的,這家公司並沒有參與DevOps的轉換過程。

我詢問了高層管理人員,但是他們回答說,對此無能為力,因為這是總部做出的不可逆轉的決定,而總部位於另外一個國家。他們不完善的解決方案就是在中間構建一個“DevOps團隊”,該團隊沒有任何運維和開發經驗,甚至不能訪問生產環境。這個新團隊將為整個組織建立一個持續交付管道,從而允許開發團隊一直部署到測試環境,運維人員會從這裡開始接管並手動部署一切。

這種方式的最終結果就是一個無人使用的工具棧,因為它並不匹配開發人員的需求。另外,他們依然需要為運維人員創建手工工單(ticket)來部署自己的服務。很多人決定離開該組織,包括本地的高層管理人員,他們都明白無法實現真正的DevOps轉換。

我從這些(以及其他的)轉換中得到的教訓就是,我們需要超越工具的範疇,要將每個人都真正包含進來。如果在轉換過程中不將運維引入進來,那麼將永遠無法填補開發和運維之間的鴻溝,帶來的後果只能是浪費時間並損耗人們的積極性。

“這能夠在我的工具上運行,接下來就是運維的問題了”

圍繞採用DevOps所產生的問題並不總是單純的組織問題,通常還會有工具的問題。並非所有的工具都能帶來相同的收益。

最近,我看到很多組織都在宣稱他們在採用DevOps,因為他們實現了工具X。但是,仔細看一下的話,工具X通常會讓開發人員更容易,但是付出的代價則是隱藏了運維的複雜性。在如何管理工具X的討論中,內部的運維團隊通常會排除在外,他​​們會再次變得無比沮喪。我們重新回到了“開發 VS 運維”的思維模式,開發團隊(和管理團隊)聲稱運維人員在阻礙他們。工具X對於他們來說可能非常簡單,但是他們忽略了監控、安全性、備份、擴展、度量指標、網絡和許多其他的非功能性需求,而這些都是需要運維團隊解決的。

不幸的是,這種痛苦模式的工具數量正在不斷增加。在這十年的DevOps中,我們已經從“這能夠在我的機器上運行,接下來就是運維的問題了”變成了“這能夠在我的工具上運行,接下來就是運維的問題了”。我將其稱為Dev-oops,而不是DevOps,其他的人則將其稱為雲原生。

讓運維人員使用和開發人員相同的工具集,並讓他們使用相同的模式,這樣能夠為他們提供一種通用的語言,可以實現更好的相互理解。正確地使用工具是提升組織協作的堅實基礎。不過,如果工具選擇是在隔離的情況下做出的,並且由不同的團隊獨立操作,那麼可能會在團隊之間造成更大的隔閡

結論

儘管有了很多進步,但許多組織中的DevOps仍然處於起步階段。我們要將如何提高開髮質量整理出來,並引入核心實踐,如基於主幹的開發(trunk-based development)、測試場景等。

DevOps的基本前提是在開發人員和運維人員之間進行協作,調整他們不同的技能集以快速且安全地交付和運行,但許多組織仍然經常忽略這一點。

所以,十年來我們一直在說每個人都應該被包括在內,在任何DevOps轉換中,討論和路線圖不僅要包括開發人員,還要包括運維人員。遺憾的是,事實並非如此。

希望在下一個10年,我們能解決這個問題。

作者介紹

Kris Buytaert是一位資深的Linux和開源顧問。他是DevOps運動的發起者之一,目前在Inuits工作。他經常在各種國際會議上發表演講,或組織國際會議,並在不同的書籍、論文和文章中撰寫了關於該主題的內容。他大部分時間都致力於彌合開發人員和運維之間的鴻溝,他強烈關注高可用性、可伸縮性、虛擬化和大規模基礎設施管理項目,試圖建立能夠扛得住10樓測試(指的是在基礎設施中任選一台機器,將其從10樓扔下,能夠在5-10分鐘之內恢復基礎設施的測試——譯者註)的基礎設施,也就是今天所謂的雲,同時積極推動DevOps的理念。他的博客名為“一切都是該死的DNS問題”,可以通過這裡訪問。

原文鏈接Did You Forget the Ops in DevOps?