SRE
SRE 的工作內容
SRE 是一位將 DevOps 概念實現的工程師，以下是我之前擔任 SRE 工程師的工作內容和職責。SRE 工作內容如下：
環境規劃與統整
- 根據現在的組別現有的環境做規劃
- 曾經待過的組別只有 dev 和 prod 兩個環境而已。在測試上和與其他組別對接上有問題
- 環境不一致，會導致組與組之間沒有辦法對焦
- 環境名稱不一致會出現的雞同鴨講
- 統整各組別的環境，並提出一個各組都可以接受的環境分類和統一環境名稱
- 環境需要使用 GCP 專案做切分或是統一使用單一專案做控管（這個會有成本上的考量）
- 以下是我之前做過的環境定義和建置
| 環境名稱 | 環境定義 | 環境的使用人員 |
|---|---|---|
| Dev | 工程師開發，單元測試 | 工程師，QA 線上測試 |
| QA | 功能測試、元件測試、整合測試和 UI/UX 檢查 | UI/UX、QA 或 QC Team 測試 |
| Staging | 需求方測試，壓力測試 | GM、主管或需求方 |
| Production | 正式環境 | 客戶或終端使用者 |
規劃 Stage
-
Deployment 的 Repo 會有 lint, unit test, integration test, build, deploy
-
IaC terraform 的 Repo 會有 validate, plan, plan&apply
- 每次做調整前需要先做 terraform import
- 在 push 前會先建議 RD 修改後在 local 檢查是否有誤
- 檢查只能在 dev 環境做檢查，會有獨立的 GCP 專案用於做檢查
- plan&apply 會是 manual trigger，這樣可以確保在 apply 前可以到 plan 的 stage 確認要 plan 的內容是否有誤
-
Helm chart template 的 Repo 會有 lint, package, push
- lint 是檢查 template 是否有語法錯誤
- package 是封裝 chart 成 .tgz 檔案
- push 是將 tgz 檔案推倒 registry 上
管理 CI/CD pipeline
- 使用一個獨立的 repo 來管理組內所有專案的 .gitlab-ci.yml
- 統一管理可以避免有 RD 誤觸 stages 內容
- gitlab 有調整可以由 SRE 工程師統一調整，RD 可以專心在開發工作上
Helm chart template 管理
- Helm chart 的版本會有分成 deployment, cronjob, redis proxy 和 ingress controller
- 做切分的原因是為了可擴容性，避免 helm charts template 互相影響
Logging 監控
- 與 RD 討論，簡單易懂的 Logger，工程師們有共識的
- 與 UI/UX 和 F2E RD 討論可以讓使用者了解的系統問題。當有問題時使用事件等級做區分
Monitoring 監控
- 確保系統穩定
- 監控系統效能
- 故障排除
- 緊急應對
Kubernetes 資源/異常監控
- ImagePullBackOff
- CrashLoopBackOff
- GKE Image 更新異常
- GKE Pod 優化方式