專注基礎或創新?DevOps成功需兼顧兩者

DevOps團隊正在經歷著傳統主義者與創新者之間的鴻溝——隨著團隊承受著利用最新進展的壓力,這種裂痕正在加深。傳統主義者正在努力保留基礎,對DevOps早期懷有敬意,並且不走捷徑(只需看看CrowdStrike)。另一方面,創新者準備好以最新技術抓住他們的英雄時刻。

對於高效能的DevOps職能,您必須同等重視這兩者。DevOps的火箭船總是會升空,但它航行的成功很大程度上取決於在倒數開始之前所做的工作。團隊如何採納NASA的思維模式?讓我們深入探討……

回歸基礎:可靠、可重複的構建
控制中的流程:為了確保每次準確發射火箭,「標準」需要盡可能標準化。流程通常在組裝和部署構建時失去標準化,這是因為存在不同的技術和不同的環境,而不是為每個環境(無論其用途如何)創建一個單一的升級途徑。對於較低環境的每個構建本質上都是「彩排」,所以當您最終進入生產環境時,您可能已經至少在相同的腳本中以相同的方法構建了兩個不同的東西。在DevOps中,例行工作是一切,但您必須將每件事都視為潛在的CrowdStrike時刻。

端到端捕獲:負責構建的人員會在過程中學到新方法,這些方法往往只存在於他們的腦海中。不幸的是,隨著環境在代碼和硬體方面不斷更新,這些策略可能無法跟上這些環境的變化。儘管這可能會感到乏味,但DevOps團隊需要對環境有一個實際且經過驗證的端到端圖像。這可以採取敘事、視覺、錄製視頻等形式。但目標是捕獲。根據2023年DevOps狀態報告,文檔質量推動了所研究的每一項技術能力的成功實施,從持續集成到基於主幹的開發再到可靠性實踐。

減少手動步驟:只要有可能,人工干預應僅用於決策點,而不是完成或糾正「勞役」任務。有時會誤解這個概念。在討論CI/CD時,「持續集成」理想情況下意味著只需按一個按鈕,您就可以促進代碼,它可以通過所有環境在升級路徑中向上,並最終進入生產環境。這是一種能力,如果您需要,只需單擊一個按鈕,更改就會以您自動化流程的週期速度顯示在生產環境中。另一方面,「持續部署」是一個人為決定去做確切的事情——很少有構建過程如此例行、低風險或如此緊急,以至於您會選擇消除人工干預。通常,最佳實踐是進行高度自動化的構建,並具有自動化通知和警報,以便人工干預。

創新:關注機會
基礎架構即代碼:構建的一個挑戰是需要同時解決多個問題,例如來自開發團隊的功能升級;可能需要根據生產或較低環境的經驗而插入的缺陷;底層系統的修補程序和更新。發生碰撞或遺漏的可能性在動態環境中相對較高。基礎架構即代碼(IaC)通過每次從頭開始構建整個堆棧來解決這個令人沮喪的首次構建成功障礙。IaC預先假設您具有容器化能力,並且可以虛擬構建和部署,但它是DevOps中一種非常強大的創新,因為它能夠確保首次、每次構建都是乾淨且完整的。

通過MLOps創建自適應構建:每個構建的重要部分是確定將與部署的源代碼一起部署的驗證和驗證「包」。能夠準確定位風險、減速和失敗點至關重要。但在沒有針對特定版本評估這些的方法的情況下,默認決定是在每個版本中包含整個驗證,這會延長構建和發佈時間週期。一個很好的起點是應用ML/AI來創建自適應構建,可以自動化檢查,並確保符合標準且安全且性能良好。將此構建優化基礎架構與正在進行的數據管道相結合,可確保其保持實時相關和優化。儘管很多工作可以由熟練的人工完成,但這些都是ML/AI非常適合的任務。

納入SRE:站點可靠性工程(SRE)代表著DevOps的下一步,它打破了筒仔,並在那些創建代碼和那些直接與客戶互動的人之間創建了連續性。將SRE納入DevOps的一種方式是創建一個輪值名單,其中每個開發人員定期在諸如二級支援的服務台工作,例如六週。在開發團隊中將服務台人員作為業務分析師或開發人員(取決於他們的技術背景)進行「輪值」同樣有益。SRE模型創造的協作和見解有可能改變最終用戶體驗。

結論
當前,DevOps傳統主義者與創新者之間的「操作張力」可能正在增長;畢竟,DevOps的秘密一直是使困難的事情變得例行化。

但好消息是團隊需要這兩者。這僅僅是關於找到方法將這些思維模式結合在一起,解釋它們對於成功的DevOps職能所帶來的影響,並確定方式來通過給予這兩者同等的重視來加強DevOps努力。