當我看到那些不像我一樣主要在線下成長的年輕一代時，我為他們感到有點遺憾。我已經三十多歲了，所以我知道在成長過程中盡快接入撥號網路（以避免長時間阻塞電話線）存取幾個維基百科頁面來完成我的任務是什麼感覺。什麼。透過親身經歷我們所有人口袋裡的個人電腦的崛起，我覺得自己並沒有免疫，但更有能力利用它來為自己謀利，而不是僅僅因為更加“ 互聯”而成為其無限幸福和滿足的虛假承諾的受害者。
另一方面，還有另一場革命，我沒有直接參與其中，這場革命是在 2009 年 O'Reilly Velocity 會議上著名的Flickr演講之後，在 00 年代全世界的 IT 部門中發生的。事件讓DevOps聲名大噪，並展示了一個可以從孤立的、發展緩慢的基於ITIL的組織轉向更好的組織的未來。
不到 5 年前，我最近從教學轉向了科技。我不知道在任何其他不實踐 Flickr 演講中所傳授的實踐的專業環境中工作會是什麼樣子。敏捷方法論和「DevOps」仍然難以確定的定義是我從未質疑過的現狀。
但我現在對此表示懷疑。如果我認為，未來的世代缺乏基本的視角，並且可以從了解沒有智慧型手機的生活是什麼樣子中獲益匪淺。我必須將同樣的邏輯應用在自己身上，並且齊心協力去理解 DevOps 到底是什麼？它是對什麼的回應？它最初的承諾是什麼？人們如何以及為何最終成為 DevOps 工程師？未來成為 DevOps 工程師意味著什麼？
DevOps 如何開始及其最初的承諾
我有時想知道，在開發人員必須填寫基礎設施配置請求表並等待數天或數週才能得到服務的日子裡，情況一定是什麼樣子。我聽說過那種文化中典型的運營人員的故事，他們總是互相指責，脾氣暴躁，最喜歡說的詞是“NO“和“Where's my pager?“ 。
John Allspaw 和 Paul Hammond 以及他們著名的速度演講「每天 10+ 部署：Flickr 上的開發和運維合作」的許多與會者不必懷疑，開發人員和維運團隊之間的常見摩擦一定是對他們來說一切都太生動了。
多年來，我多次觀看了這個演講，有幾件事對我來說很突出。首先，我沒有意識到當時的談話包含瞭如此多的髒話，或者也許只是奧爾斯帕先生。另一個是演講者提出的關鍵訊息，即開發和營運團隊實際上共享相同的目標。為業務賦能。
他們繼續討論組織可能希望採用的工具和文化特徵來實現一天的多次生產部署。他們談到了自動化基礎設施、功能標記、共享警報和監控，所有這些都圍繞著新的協作文化結合起來，這種文化重視信任以及對系統故障和避免指責的更健康的態度。
具有巨大影響力的《DevOps 手冊》和《站點可靠性工程》書籍在很大程度上進一步明確了 DevOps 在接下來的幾年中的含義。
前者的開頭章節用幾句話描述了 DevOps 的做事方式渴望解鎖什麼
“[多個團隊共同努力]實現計劃工作快速進入生產（例如，每天執行數十、數百甚至數千次程式碼部署），同時實現世界一流的穩定性、可用性和安全性。”
我們兌現了承諾嗎？
當我想到 Flickr 演講中提出的想法時，我的腦海中浮現出一種走在巨人肩膀上的感覺。這些對許多人來說一定是革命性的想法是我所知道的唯一的職業現實。因此，無論是否可以對當前的 DevOps 方法、最佳實踐和工具進行改進，我都對迄今為止所取得的所有進展表示感謝。我問過 2009 年之前配置伺服器或進行駭客攻擊的人，他們都證實現在的情況比那時好。
話雖如此，大多數公司是否都在瘋狂地進行運輸，同時實現世界一流的穩定性、可用性和安全性？很大程度上沒有。
DevOps 世界即使擁有裝滿現代可用工具的龐大工具箱，仍然執行該演講中提出的完全相同的框架。
用亞當雅各的話來說
「問題不在於我們沒有對系統的每個單獨部分進行足夠的最佳化。我們在每一步都建立了更有效率的工具。但是整個系統是如何組合在一起的呢？使用體驗如何？這與 2009 年的情況基本相同，這也是我們陷入困境的原因。
孤島仍然存在，交接容易出錯，而且在許多情況下協作相當強迫和僵化。任何擔任 DevOps 工程師一段時間的人都會有一長串他們認為自己的組織出錯的事情，並且通常對自己的組織解決問題的能力也同樣缺乏信心。
Adam 是一位經驗豐富的 DevOps 實踐者，他甚至呼籲第二波 DevOps ，它不僅僅是簡單地改進工具，而是邀請我們跳出框框思考，挑戰既定規則，看看另一面會發生什麼。
說到DevOps實踐者，這些人是誰？一個人如何以及為何成為一個人？
人們最初是如何進入 DevOps 的？
在短短 15 年裡，科技業取得了長足的發展。 DevOps 工程師、SRE 和平台工程師等職位現在在招聘網站上很常見，也是技術招聘人員的熱門專案。然而，在 IT 世界之外，這些術語仍然鮮為人知。儘管發展迅速，DevOps 還不是一個人們渴望加入的職業；相反，許多人只是“陷入其中” 。
在與我表弟交談後，我偶然進入了 DevOps，在我獲得 CCNA 憑證後決定反對嚴格的網路工程路徑後，他建議我選擇 DevOps。我很好奇誰最終會進入 DevOps，以及未來的工程師是否會選擇它作為他們的第一個職業選擇，我詢問了/devops Reddit 子版塊，並對各種不同的意見感到驚訝。
我發現了一些「我剛剛陷入其中」的人：
其他人則適度看好新一代：
其他人則不那麼樂觀：
儘管 DevOps 的定義仍然存在很大爭議，但它似乎不太可能將自己定位為學生在招聘會上聽到或永久加入到大學課程中的職業。這可能是因為我們傾向於想像自己在特定領域表現出色，相信專業化會增加我們成功的機會。
小時候，我夢想著成為一個著名樂團的主音吉他手，擁有神級的粉碎能力。我並沒有夢想能夠相當擅長演奏所有樂器。
在 DevOps 中，沒有吉他獨奏。為了脫穎而出，您需要熟悉一長串工具、語言、框架、超大規模器和流程。最優秀的 DevOps 工程師本質上都是通才。這種模組化、樂高式的工作和體驗性質可能會讓 DevOps 在 IT 部門之外不太受歡迎。
通才、修補匠的案例和膠水的概念
不可能嘗試對 DevOps 從業者應該具備哪些特徵形成非主觀的描述，但根據我的短暫經驗以及我從與比我更有經驗的人的對話中學到的東西，出現了一些特徵。
通才
您讀過「如何在 DevOps 領域找到工作」指南嗎？還記得知識要求部分嗎？ Linux、Docker、CI/CD、Git、Hypersclaer、網路等。
如果您曾經面試過開發人員或產品設計等職位，您很可能需要在流程的某個階段展示自己的作品集。在 DevOps 面試中這種情況很少見。我想不出有誰定期組裝和更新 DevOps 組合？ DevOps 角色的模組化和分散式系統建構性質並不適合在產品組合中進行精心策劃的展示。
作為一個厭倦了教高中英語七年的人，我自然而然地被 DevOps 所吸引，這個領域要求我學習許多工具和概念，並以協作方式將它們拼湊在一起。不深入專注於任何一個概念，而是提高快速學習新事物的技能，這就是我培養的癒傷組織。在這樣的環境中茁壯成長的多面手正好適合。
修補匠
在 DevOps 方面表現出色的人可能會認為自己是修補匠。
我喜歡這個想法，它適合我遇到的許多 DevOps 工程師。僅僅為了了解事物的知識而對學習事物如何工作感興趣是我所遇到的 DevOps 導師的一個共同特徵。當然，花週末在家庭實驗室安裝更強大的開關或在 3D 列印機上渲染新的迷你雕像並不能直接展示 DevOps 技能，但這些背景知識比憑證更能表明 DevOps 的潛在成功。
膠水
複雜系統中的許多工作可能會受到關注，因為很難規劃或預測。由於 DevOps 涉及將工具編織在一起來建造平台或交付系統，因此需要大量的黏合劑。
流程必須到位並自動化，以跟上技術堆疊中每個工具附帶的技術債務和維護工作。那些能夠自然而然地、常常吃力不討好的充當黏合劑，透過自動化、溝通或改進重複流程連接系統的不同部分的個人，對於組織的成功至關重要。這項技能不是您在履歷中列出的內容，但與修補匠的好奇心和通才的開放性相結合，它是一個強大的組合。
目前狀態：平台與 DevOps
這些討論中常出現錯誤的二分法，通常是出於行銷原因：DevOps 已死，平台才是未來。平台工程師的目標是為開發人員提供對傳統 Ops 相關元件（k8s、IaC 元件、IAM）的自主權，而無需直接交互，使開發人員能夠自助服務並保持獨立。
精心設計的、針對特定環境的平台可以提高開發人員的速度。根據2023 年 Puppet DevOps 狀況報告，超過三分之二 (68%) 的受訪者認為採用平台工程後開發速度提高了。然而，速度不應該是唯一的衡量標準。正如georgouslyhumble在 Reddit 上指出的那樣，有時目標是在滿足新的組織要求的同時保持現有的速度。例如，日誌記錄 sidecar 可以在不改變開發人員速度的情況下標準化日誌收集，從而增強平台以滿足不斷成長的公司要求。
維運工作仍然複雜且動態，熟練的維運人員對於超過一定複雜性閾值至關重要。平台為開發人員提供支持，但請注意，它們不一定會減少孤島或更緊密地整合開發和營運團隊。
團隊在堆疊中新增工具時要謹慎，因為新工具通常會帶來快速累積的維護和維護開銷。像Glasskube這樣可以減少營運開銷的工具是不可或缺的。我們需要更多這些工具來為未來建立強大且高效的 DevOps 平台。
未來預測
某種類型的平台將會勝出
勝出的系統、平台或工作方法不必「教導」使用者如何一起工作和協作。未來的系統只有在使團隊協作成為最簡單、最直觀、最自然的工作方式，同時抽像出開發人員和維運人員都無法完成的工作的情況下，才能在不影響安全性和穩定性的情況下提供無限軟體交付的難以置信的可能性。
為了創造它，我們必須跳脫框架思考。
第二波 DevOps 可能是一種方式
值得慶幸的是，有許多不安分、不墨守成規的人為 DevOps 領域的方法、流程和工具的不斷改進做出了貢獻。
有人可能會說，重新思考 DevOps 的正式運動已經出現，這非常令人興奮。
通才和修補匠越多越好
最有能力不斷連結拼圖、閉合回饋循環並重新思考糟糕想法的人是那些不怕用深度專業化換取專業通用化的人。那些敢於冒險並通過一路修修補補、測試和提出問題來快速學習的人將使這艘象徵性的船在越來越快地走向卓越工程的過程中保持漂浮。
如何找到足夠的這些人是另一個問題。
結論
看起來我還不太明白為什麼人們長大後不想成為 DevOps 工程師，也許這是一個相對較新的領域，再加上通才通常不被認為是最酷的孩子這一事實的混合體。
展望下一波人才，無論他們是有意識地選擇還是偶然進入 DevOps 角色，有一件事是肯定的：了解該領域的歷史是關鍵。這是未來工程師能夠培養辨識當前狀態與理想未來之間差距的唯一方法。如果忽視這一差距，現狀就會佔上風，我們將注定陷入停滯的平庸。
不可否認，自 DevOps 時代之前以來，技術格局已得到極大改善，但同樣明顯的是， DevOps 15 年來仍在站穩腳跟。
經驗豐富的專業人士需要保持敏銳的眼光，辨識並鼓勵周圍的年輕修補匠、通才和“粘合者”，不要擔心追逐某些頭銜，而是幫助重新定義DevOps 並將其發展為能夠實現2009 年最初願望的東西。
如果您喜歡這類內容並希望看到更多內容，請考慮在 GitHub 上給我們一個 Star 來支持我們🙏
原文出處：https://dev.to/glasskube/why-nobody-grows-up-wanting-to-be-a-devops-engineer-2jli
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式