整理一段關於 SRE 問題的訪談紀錄，歡迎大家提供不一樣的經驗與想法。

Q1. 企業內部的 SRE 與 DevOps 工作內容與分工？

這要看企業規模，而且大部分企業對於 DevOps / SRE 的理解與定義可能都有差異。

個人經歷過大多是這樣分：

• Feature Team / DevOps: 負責業務邏輯的開發團隊 (Scrum Team)，團隊裡可能有一個或多個專屬的 DevOps Engineer 負責處理所有的 CI / CD 工作。
• Infra Team / SRE: 負責處理 App 以外的東西，包含 Cloud / Network / Cost / Provisioning / Observability / Monitoring / Architecture / Artifact Repos / CI/CD 平台 / Security …. Etc.

其實很多企業，對於怎麼定義 SRE or DevOps 是沒有想法的，或者是有自己的解讀 … 所以討論這樣的題目時，通常我都會先反問對方的期待與認知，確認彼此 On the same page.

實務上，少於 500 人的企業，這兩個角色 (DevOps / SRE) 對老闆來講，是沒差的；大於 500 人的企業，這兩個角色對老闆來講，還是沒差。。。

所以有時候工作上，不要太糾結自己的範圍，而是要思考，現在處在的環境，自己要怎麼做才會有貢獻 (亮點)。

換個角度想：

你花了 5 萬塊，一個月請一個人，希望得到什麼？

聽起來像是幹話，但很現實，因為勞雇就是一種買賣。

Q2. SRE 工程師，需要具備的基礎技能有哪些？

依照 SRE 原文的定義，我認為的 SRE 本質是：

用軟體工程，解決維運任務

這句話我這樣拆解：

• 專業職能：軟體工程，包含程式設計&開發&測試 / 系統工程＆架構
  • 軟體工程就是作出可以 Reusable / Scalable 的東西，可以從 1 變成 10 的概念
• 領域知識：系統維運，包含異常處理, 事件管理, 自動化工程 … 很多，可以參閱我以前整理的 R&R 分布圖

專業技能：

• Programming: Python/Golang, Web, RDB, Cache, Queue.
• Networking: Protocol (TCP / UDP / HTTP / DNS / BGP …), Network Devices (Switch / Router / AP … etc)
• System: Public Cloud, OS (Linux, OS), Storage
• Observability & Monitoring

專業技能很粗略地寫，因為這些內容的技術過幾年就會翻一輪，實務上用人不會找 100% 符合的 (也找不到)，更多是找基礎好、可以栽培、個性積極的，當然要解釋成成本考量也是可以的。

相關用人的邏輯，可以參閱 人力招募 - 二、見面談：招募第一關 面試

Q3. 在建置 SRE 團隊中，過程有遇到哪些痛點？

所謂「痛點」要看用什麼角度來看，其中「政治問題」是避免不了的。

大多在業務上站上位置的角色，都是強勢的一方，也就是上位。這在任何企業都一樣，不管什麼產業都一樣，因為企業本質就是賺錢，開源單位講話大聲，成本單位大多能做的是滿足他們，這樣的供需關係，在很多企業裡都差不多，能改變關係的是少數。

所以大部分的現象 (不是問題) 都是組織結構上任務與資源不對等，更多的是 R&R 不分，執行任務過程勞心、勞力、傷神又傷心，衍生的感覺就是「痛點」。(上述現象，把 SRE 換成 QA 一樣適用)

用人與人才培養也是問題，但是不能算是痛點，這方面需要耐心與信心，創造機會與耐心教導，還是可以做得好。

再來是怎麼讓 Feature Team 與 Infra / SRE Team 能夠有效協作的「共識」，也就是制度。當遇到一件事情的時候，該怎麼區分這件事情的 ownership？官大說了算？該怎麼理性溝通？例如線上炸鍋，炸鍋解決了，因為系統資源不足，所以 Responsiblity 就是在 SRE / Infra？大多是，實務上很多就是「政治」角力，讓這件事情正確的 R&R 歪掉。

這個案例，大概是實務上的痛點，因為資源不足，更多時候是程式改善可以解決，但有時候「用錢能解決的問題不是問題」，就蓋過真正的問題了，那個問題幾年後通常會再爆出來，但已經沒人知道為什麼了 (省略一本書的故事 ….

可能的解法：建立一個可以跟 Feature Team 協作的制度，概念類似 AWS 的 Shared Responsibility。但建立這個「雙方」的智度，要有「自己」的制度，讓自己的制度動起來，站穩腳步。然後再去跟 Feature team 討論雙方的制度。大概的概念可以參閱我在 SRE Conf 2022 分享 的 P58.

Q4. 過去是怎麼進行內部 SRE 人才培訓？

針對傳統 OP (管系統, 管設備, 不寫 Code) 的訓練，務實面的方式以及過程摘要如下：

1. 手把手教，以 Python / Cloud 為主，像是 Python runs on Lambda (AWS)，Export as API。
   • 從他們本來就熟悉的領域切入，不要弄太難或者太多觀念 (ex: OOP, Framework)，重心擺在領域問題能用簡單的 Code & Cloud 解決
   • 從簡單的日常維運開始，像是備份、檢查 DNS / SSL 過期 / Health Check，可以玩 Cloud + Programming，不會太難，又有成就感。
2. 訓練開發 API 封裝 Public Cloud / SaaS 的功能，提供給 CI / CD 整合時、維運時使用
   • 減少 Feature Team 接觸 Cloud 的面積，因為大部分的 Public Cloud 的功能只能用到 20%，很容易讓人有選擇困難，透過 API 封裝，簡化 Feature team 的使用難度，又可以讓 SRE 設計 API / Coding，雙贏。
   • 更多參閱 SRE Conf 2022 分享 的 P47.
3. 資深一點的：透過 GitOps 的方法，設計較複雜的架構，像是非同步排程任務，只要 commit 就可以發動任務.
   • 這是長期策略，也就是未來雙方協作都是透過 GitOps 驅動
   • Policy as Code 的第一步。
   • 看到 Code 一翻兩瞪眼，雙方容易聚焦，減少爭議
4. 訓練處理異常：從異常中學習架構是怎麼一回事，系統是怎麼運作的
   • 一個 Request 第一次跟第二次 Latency 不一樣，這是怎麼一回事？
   • 就像醫生看到症狀，就可以大概知道問題在哪。但前提是醫生是了解人體結構與運作原理的，SRE 了解架構，才有辦法隔空抓藥。

管理角度，可以參閱我寫的 人才發展策略地圖 (草稿)，這份草稿不止 SRE，只要是軟體開發團隊都適用。

Q5. 在 SRE 人才的培育上，應該要上哪些課程？

如果我有機會規劃學程，快速摘要一些想法，不見得可行，但是要先有一版出來 (先有再求好)。

3 + 3 代表三學分，兩個學期，如果是專職課程，3 = 6 個月

• API 開發 (3 + 3): Python / Golang, Cache, Queue, OpenAPI
• 網路基礎 (3 + 3)
• 軟體交付實務 (3 + 3)
• 監控 實務 (3 + 3)
• 架構 (3 + 3 + 3): Public Cloud / K8s
• 分散式系統 (3 + 3): 可以參閱最近 Google 出的課程

CS 有以下:

• OS / Compute Architecture
• Networking
• Database
• Programming (3+3) / Data structure / Algorithm

是否一定要 CS (計算機科學 / 資工 / 資管) 背景？我個人希望要有，最好是數學相關背景的。當然，這是我個人的偏好而已。我也用過不是這樣背景，但表現也非常優秀的人。

聽歌

聽著 李玟 (Coco) 的精選，寫文章。

延伸閱讀

站內文章

• 個人著作《SRE 實踐與開發平台指南》 (2023/08 上市)
• 推薦：Site Reliability Engineering (SRE, 網站可靠性工程)
• 演講：SRE Conference 2022 - 91APP 在 AWS 上的 SRE 實踐之路
• 演講：Serverless All-Star - Ops as Code using Serverless
• 演講：淺談系統監控與 CloudWatch 的應用
• 演講：Monitoring Tools 大亂鬥 - AWS CloudWatch
• 緊急應變 (Emergency Response)

其它參考

• SRE Classroom: Distributed ImageServer
• 人才發展策略 (draft, 2022/10/26)