DevOps、SRE、Op 這些工程師，常常會面臨：身為維運工程師，常常花費相當多的時間、經歷跟注意力在基礎架構的建置上，而壓縮了協助企業用基礎架構設計軟體服務、提升使用者體驗的時間。然而兩者皆同樣重要 。
不過現在，維運工程師的工作內容逐漸改變了，變得更加細分：建制基礎架構、程式系統應用。
前臉書產品工程經理 Charity Majors 以他過去的經驗觀察，分析維運工程師的角色將如何轉變、如何未來可能遇到的困難等等。
工作內容的轉變
從整體性（Monolith）變成追求「微服務」（Microservices）
由於使用其他功能會牽涉到網絡躍點的問題，因此即使是 debug 裡最瑣碎的問題，也必須列入維運考量。微服務使得維運工程師的工作內容從過去「建設程式碼」變成「建設程式系統」，亦即會有更多 coding 加入維運工程師的工作中。
練習轉變角色：從觀測到觀察
觀測（Monitoring）是確認企業的基礎架構是健康的，並且找出應該採取哪些行動讓架構維持/變得健康；但更進階的維運工程師，還應該要能做到觀察（Observability）並瞭解使用者、用戶與程式碼之間的關係，並且將三者的關係變成可以提高 商業價值 的體驗 。
採用新的測試工具，但也不要忘記工作目標
雖然 Autoinstrumentation 工具可以幫你快速、自動地建構程式碼，但這些程式碼背後的商業目的、業務目標，這些工具是不會懂的，工程師得自己來。
未來的 Ops 工程師更細分，每個人都會做到 Ops 的工作了
在基礎架構的建置及開發上，有越來越多的雲端平台服務或是 API 提供相關的服務，工程師可以利用這些服務，解決基礎架構的問題或是加快建置的流程。對建立基礎架構相關問題有興趣的工程師，可以選擇如：AWS、Azure 等企業，將設計的服務產品出售給其他人。
若對「應用」更有興趣的維運工程師，則可以選擇另一條路：建構程式系統，並進一步協助工程團隊設計延伸軟體服務，創造商業價值。也就是說，自建基礎架構的工作內容將會越來越少。那空出來工作內容，會是什麼？
1. Vendor engineering
未來，企業將會把建造基礎架構的工作內容外包，因此一個能夠整合所有架構的工程師，將會越來越被重視。身為一個 SRE，你可以從下列這些面向學習：
- 學習如何評估供應商提供的組件，確保基本架構的相容性及整合性。
- 計算團隊的工作時間及人工成本。為了專注於核心業務，盡力減少多的工作。
- 學習管理成本，並在企業內部倡導、教育正確的解決方案。
2. Product engineering
基礎架構產品最大的問題之一：在使用多數建設工具時，都需要無止盡的培訓學習和認證，因為工程師設計產品時並沒有和設計師和產品管理討論。
你可以做的是：
- 參加速成班。讓自己進入一個 B2B 或 B2C 的團隊裡，學習配合對方節奏、語言，你需要其他人來豐富你的觀點，正確地建構程式系統。
- 向產品管理經理學習如何與其他團隊建立好的關係，並對產品的生命週期有足夠的了解，進一步幫助進度停滯、或歪掉的產品設計團隊。
3. Sociotechnical systems engineering
SRE/DevOps 越來越需要設計出有效且高效率的社會技術系統回饋（sociotechnical feedback），找出方法協助團隊達成目標。
- 學習如何部署人力。
- 設計並優化輪調系統，讓人力可以公平且可以不間斷地工作，同時不使員工感到精疲力盡。此外，設計出一個好的回報系統，讓發現問題的人有權力、也願意去解決問題。
- 培養一個好的公司氛圍及員工的責任感，使人感受到歸屬感，並協助他們在工作上的問題。
4. 管理技術性投資的投資組合
- 可執行性（Operability）是最長期、也是最主要的技術性投資，沒有人比維運工程師更適合這個項目的管理了。
- 在交接的時候，把問題提出來。
- 不要寫非必要的程式碼， 或是增加多餘的工具。面對這種要求的時候，你就回對方：「這個工具的維運計畫是什麼？」
- Operability 至上，讓整個團隊接受這件事。（可以應用在升遷制度上）
產業的趨勢不斷轉變，工程師的職責也會隨之移動。面對未知的新事物，找出適合的協助、方式與工具，就努力去 Debug 吧——這是你身為工程師的天命啊！
參考資料
（本文提供合作夥伴轉載。）