昨天我們聊到 DevOps 是一種職缺，但它也只是一種「職缺名稱」，關鍵重點還是企業用人單位希望這個職缺能擁有哪些職能。

其實按上面這個論述，我們會發現該職缺叫什麼名稱似乎一點都不重要，只不過是普遍來說大家都把它稱呼為 DevOps 工程師而已。

因此你會發現，當你在搜尋 DevOps 職缺時，同時也會跑出 SRE 與 Full-stack 或一些有點像是 System admins 的職缺；反之亦然，如果搜尋 SRE 也會出現 DevOps 職缺。

這樣一來到底「DevOps 工程師」與 DevOps 的關聯性是什麼？

說穿了就是在我們前面幾天聊過的 DevOps 及 CI/CD 歷史中，有出現過的任何技術與工具，將它們全部放進一個職缺身上，那就是 DevOps 工程師了。

所以當企業需要一個

• 懂雲端、懂 Container、懂 CI/CD 的人？那就是 DevOps 工程師。
• 懂 K8s、可以架設內部自動化平台的人？找個 DevOps 工程師吧。
• 想要找人將現有的 VM + 單體架構，開始轉移到 Container + microservices 架構？還是 DevOps 工程師。
• Production 環境需要有人輪班照顧，最好他可以同時排除 Dev 與 Ops 異常狀況？又是你 DevOps 工程師。
• 聽見一堆 IaC 工具很棒很潮，想要導入大量自動化工具？就是你了！DevOps 工程師。

（梗圖來源：memes.tw）

畢竟是「工程師」嘛，不就是擅長使用工具、總是在追趕最求最新最厲害的技術，既然公司打算要使用這些 DevOps 工具，那就請一位 DevOps 工程師來，這聽起來很正常、沒毛病啊～

老實說，這聽起來還真的沒毛病。如果你的團隊確實需要導入這些工具，來實踐被包含在 DevOps 範疇內的各種實踐方法，例如大家第一時間都想到的—CI/CD Pipeline，那找一個會使用這些工具的員工，作為「即戰力」填補該缺口，我覺得完全合情合理。唯獨有一件事是需要大家想一想的！

還記得我在文章「Day2：DevOps 失敗了？」提到的各種案例嗎？

• 當你的 DevOps 工程師建構出一條 CI/CD Pipeline 時，所有的團隊都買單嗎？
• 當你的 DevOps 工程師離開後，你的 CI/CD Pipeline 還會持續有人使用、持續維護與改善嗎？
• 當你的 DevOps 工程師離開後，你的 DevOps 轉型還會持續進行下去嗎？

以及我在 Day18 最後留下的提問「你覺得 CI/CD Pipeline 是公司請一位 DevOps 工程師就能搞定的東西嗎？」

如果你的公司及團隊規模很小，我覺得請一位同時擁有「開發 + 維運 + Infra」經驗的工程師來擔任 DevOps 工程師，確實是一個可以考慮的選項；因為規模小，他一個人是有機會發揮影響力來影響整個團隊，獨自打通從軟體開發、交付、部署至維運的整個工作流程，然後建立出團隊共同的協作原則，讓團隊的 DevOps 持續改善之旅能夠往前推進。

但當團隊規模變大，甚至是產品的規模變大時，狀況恐怕就沒有這麼簡單了。
（事實上我覺得就算是小團隊，也不簡單，畢竟雙拳難敵四手啊。）

所以說，企業聘請 DevOps 工程師，完全沒問題！只要沒有忘記後續要讓 DevOps 背後的精神「交付價值、持續改善」能夠深入成為企業與團隊文化的一環，讓工程面的改善與商業價值建立連結，打破 silos、形成長遠的正循環、發揮深遠的影響力。那麼在欠缺懂得使用「工具」的工程師之狀況下，需要招募 DevOps 工程師，那就去招募吧！

最後再補充一點，如果你仔細去搜尋，也是有企業不止招募 DevOps 工程師，也同時招募像是 DevOps Manager、DevOps Lead 或其他像是 Agile/DevOps coach 的角色，除了工程面也打算同步從軟性角度並行推動 DevOps。（但真的很少見⋯⋯）

好啦！連續兩天都在聊 DevOps 職缺，最後的最後，讓我反問各位讀者，請問「你覺得 DevOps 是不是一種職缺？」

歡迎告訴我，你的答案與看法喔！DevOps 輕鬆聊，我們明天見！（啊啊啊，明天要寫啥才好～）