在過去帶領 DevOps 團隊的經驗裡，有時會遇到團隊成員對於身為 DevOps 工程師的價值有所疑惑或迷思：
- 🤔 我們好像只是在做各種工具的整合…是不是要像開發人員一樣寫程式，這樣才比較厲害！？
- 🤔 是不是要像開發團隊一樣面對市場客戶的需求，這樣才能產生價值的交付？
- 🤔 是不是打造完工具鏈，DevOps 團隊就不需要存在了？
本文同步刊登於 DZone - Addressing Concerns About Being a DevOps Engineer
認真做好每一樣事物，這才是工程
在工程的世界裡，每個領域絕對都有它專業價值的存在，只是使用的技術、工具及面對的客群不同。雖然各種 IaC 或 XaC 的工具，不像廣為人知的 Java、TypeScript、Python 等程式語言，但在撰寫的過程中，仍然需要基於邏輯地去考量彈性度、模組化等，以及如何透過測試維持品質。有時更因為它是基礎設施或與合規相關，所以相顯之下它所衝擊的範圍也較為龐大，而需更加謹慎。且在五花八門的工具世界裡，選擇一個適合您組織文化、流程、團隊技術線的解決方案，也是個大哉問，不落入貨物崇拜尤為重要。因此，只要保持好奇心、積極的態度，把事情做對，不論背後所採用的技術為何，這就是工程的美妙。
基於產品思維打造 DevOps 平台
在某些情況下，DevOps 團隊可能會覺得疲於整合工具與救火，而不清楚自己在組織中扮演什麼樣的角色，交付怎樣的價值？但試著想像，當 CI/CD 流水線無法提供服務時，利害關係人將為此而發狂。因為功能無法快速地交付到正式環境而產生市場價值；問題或事故無法被立即修正解決。DevOps 平台在業務上扮演著如此重要的角色，因此它必須要能夠獲得組織文化的支持，且被視為一項產品，而非只是某一階段的專案。身為 DevOps 工程師，必須要與利害關係人（例如：稽核人員、安全團隊等）及顧客（例如：開發團隊）溝通合作，建立該產品的使用者故事，如同產品的功能需求，描繪Who（對象）、What（怎麼做）、Why（為什麼做）及對應的驗收條件。
DevOps 平台的使用者故事：
身為開發者，我需要服務的指標看板，使我能夠隨時監控並分析服務在正式環境中的狀態。
身為產品負責人，當正式環境的應用服務持續崩潰時，我希望能透過監控機器人告警負責的開發團隊，使開發者能夠迅速地被通知並趕快修正錯誤。
除此之外，每一階段的成果展示與推廣，可以使平台的用戶更貼近平台，並從中獲得用戶回饋，如同公司銷售到市場的產品一般，使每一位 DevOps 成員了解該產品的目標與附加價值，才能更加地靠近真正的 DevOps。
持續改善
沒有 100 分的流程！
即便當下 100 分，隨著環境、時間、技術等推移，下個階段同樣的模式也不一定適用。我們常常看到很多的分享案例一直採用慣性的模式，而未能持續的識別瓶頸和改善，最終果實將不再甜美。因此，DevOps 的團隊絕對是需要持續的存在，而非隨著某個專案的生命週期終止而結束。為了提供有效的平台和流程，DevOps 團隊及他們的顧客必須要能夠無隔閡的進行合作，並持續尋找流程中的浪費與瑣事，將這些改善任務放入產品需求列表，使 DevOps 團隊能夠打造更流暢、更以顧客為中心的平台。
- Photo by kalei peek on Unsplash
- Icons made by Freepik from Flaticon