ref: https://medium.com/sailpointtechblog/improving-on-call-engineering-at-sailpoint-35213090c35c
本篇是一個經驗分享文，Sailpoint 想要探討疫情後整個團隊是如何重建並且改善 On-Call 的整個運作模式。
因應 COVID 帶來的職缺變化，愈來愈多的遠端工作者加入到 SailPoint 的團隊中，整個 DevOps Team 的人數也因此整整翻了一倍。
過往的 on-call 流程基本上沒有什麼受到太多重視與關注，並且一直以來都運作的很好，但是隨者團隊人數與專案數量的提升，當前的運作方式只能用堪用來說
因此需要重新審思如何改善，加強整體效率。
SailPoint 之前的 On-Call 是使用 PageDuty 這套服務來處理的，因此團隊想要看看是否這中間還可以有改善的空間
不論是新的流程或是 PageDuty 有什麼功能是團隊還沒有妥善使用的。
Baby Steps with PagerDuty
PageDuty 有個名為 PagerDuty Virtual Summit 的年度盛會，作者團隊決定參加盛會來聽看看有什麼功能是目前沒有好好使用的。
除了 Digital Operations Tier 這個更加智慧甚至提供基於 machine learning 的相關控制功能外，作者團隊還學到了關於 Slack
的新整合功能，有鑒於整個團隊愈來愈趨向遠端協作， Slack 的使用也就變得愈加重要，因此團隊優先的將 Slack 整合該新功能。
Feature Rich Proof of Concept, A Short Story
1. 作者團隊於會後積極的聯繫 PageDuty 的團隊，想要針對各項新功能進行更多的探討與使用，這方面 PageDuty 也很積極的幫忙建立 PoC 環境與回答各種問題，讓團隊可以試用這些新功能
2. 第一個嘗試的功能是針對團隊的 RDS Alert 的智慧處理功能。過往當 DB 出現問題時 Cloud Watch 就會出現高達 60 多個相關 Alert，透過新的智慧功能這些 alerts 會被辨識為一個單一意外，就不會遇到 Alert 洗版的現象
3. 過往 RDS Alert 出現時，每次都要針對那些 Alert 一個一個的去 acknowledge，現在因為全部都統一辨識為單一 Alert，因此 acknowledge 也只需要執行一次，整個效率大幅度上升， on-call 的工程師可以花更多時間去專注解決問題。
4. 下一個嘗試的功能就是全新的儀表板，該儀表板顯示了 alerts 的趨勢變化與相關參數，這些資料讓該團隊每週的 on-call 會議有更多的資料去檢視過去一週的情況，藉此可以找到團隊中比較脆弱容易出事情的服務。
文章中還有兩個章節探討剩下的改善，對於 On-Call 有經驗也有興趣的人別錯過全文。
devops工程師是什麼 在 [心得] 初階DevOps/SRE 工程師是如何煉成的- 看板Soft_Job 的推薦與評價
markdown 好讀版：
https://tech-blog.jameshsu.csie.org/post/devops-entry-level-sre-road/
## 前言
背景是學生，大約兩年的 SA/DevOps 學習經驗，剛拿到 ByteDance 的 SRE offer，
所以應該可以算是 Entry-level 的 SRE 了，
會想寫這篇分享是因為看到滿多人對 DevOps/SRE 的印象是很吃經驗，
不太可能讓新鮮人做，對這種印象算一半認同（我就是反例XD），
另一方面也想讓有興趣的人知道該如何入門這個領域
詳細的背景在前一篇 SRE 面試文（#1WFpX6V3）寫得比較多
### 什麼是 DevOps/SRE?
我無意在這篇談 DevOps 的商業或管理價值，
也無意細分 DevOps Engineer 和 SRE 的區別，
很概括且從技術角度來說，DevOps 的重點是
1. 減少從設計、開發（需求、程式碼）到測試、部署（程式）的時間
2. 加強回饋機制（包括但不限於監控、告警）
3. 過程中持續快速的疊代、學習
（改寫 DevOps 三步工作法）
文末會附 DevOps 相關的書單
## 技能樹
這一部份會以 https://roadmap.sh/devops 搭配講解
以下的順序以我個人學習、接觸的時間軸做排列
### 語言
建議 Python、Go、JavaScript 三者至少要一個精通、一個熟練，第三個可以作為輔助。
會推薦這三個語言是因為這三個語言要寫自動化的小工具時都很方便；
其次這三個語言各自有強項：
- Python：易於和其他人協作、精於 ML（對，SRE 有可能會需要 ML 輔助）
- Go：很多 DevOps 的工具包含 Prometheus, Kubernetes, Docker, Drone
都是 Go 寫成的，要寫網頁後端也很輕鬆
- JavaScript：要寫簡單的網頁前端一定要會 JS，
像 aws cdk 也是 TypeScript 的支援比較豐富
但也不是說一定要學這三個語言，例如學 java 就可以結合 jenkins 生態系，
所以就看怎麼運用自己的優勢
### Linux/Shell Script
如果一開始接觸的是 Windows 環境，可以去裝 WSL 體驗 Linux，
不管如何，走這一行一定要學習 Live in terminal，
基本的 cd, ls 就不用說了，跟字串處理有關的 grep, sed, awk, cut 也都要很熟
還有像 wget, curl 等等，要列出所有會用到的指令和工具實在是列不完
有好的 google 搜尋能力的話，stackoverflow 會是你很好的朋友
對 git 也應該至少要會基本的並可以用在專案上
Linux 除了主流的 Ubuntu 以外也可以多嘗試其他 OS，例如 CentOS、Alpine 等等
這部份可以在挑選雲端的虛擬機器 或是 run container 的時候去多多嘗試
另外對 Linux 的觀念包含檔案系統、process management, DNS, DHCP 等等
也應該要有基本認知
### 架站 / SA 相關
會一門程式語言，而且對 Linux 夠熟之後，就可以嘗試架站了。
克難一點是可以用自己的機器架，
不過建議還是去租雲端的機器（例如 aws, gcp, azure）
雖然有可能要花錢（免費的方案不是速度很慢就是不能用太久），
但有 public IP 和 24 小時不停機就是方便，也能學到更多東西
我個人很推用架站來學習，因為在過程中可以學到：
1. 處理網址要了解 DNS, IP, 域名的概念
2. (如果是雲端環境) 學習如何 ssh, live in terminal
3. 設定 Web Server (nginx, apache, etc.)
4. 寫網站前端（http, css, js）、後端（python, go, etc.)
5. 想要一個域名、一台機器但對應到多個網站時，
如何設定 Reverse Proxy 和 VM/Docker
6. 跟第三方簽 certificate 設定 HTTPS
7. (如果要寄註冊認證信) 裝 Email Server (SMTP, Reverse DNS, DNS Server)
8. 在 Server 上 Debug
9. 監控網站流量、機器狀態
至於網站要寫什麼，如果沒有想法可以往購物車或需要註冊登入的網站去發想
新手建議先從前後端混合的框架開始寫（例如 Python 的 Django），
比較不需要太多 JavaScript 的知識
也可以偷懶不寫程式碼，架 WordPress 或跟會寫網站的朋友合作，
但學到的東西就會少很多，也容易淪為純 Ops
### CI/CD
網站有雛型之後，慢慢的會開始覺得本機開發到要更新 Server 的程式的流程很麻煩，
特別是在頻繁更新和 Debug 的時候，
這正是 DevOps 要解決的主要問題：縮短 Developers 和 Operation 的距離
具體的解決方式便是引入 CI/CD 的 Pipeline
CI/CD 簡單來說即是讓程式碼的 build, test, deploy 自動化，
使得 developers 只要 push 到版控工具（github/gitlab, etc.），
後面就有機器自動的更新 server 的程式
有滿多工具可以做到 CI/CD，
新手若無頭緒我會建議使用 GitLab 內建的 CI/CD，
結合他們自家的版控功能做一條龍
也可以看自己擅長的語言決定用 jenkins 或 drone 或其他工具，大同小異
如果用 GitLab，推薦自己架一個 GitLab 和 Runner (跑 CI 的環境) ，
有人寫了很方便的 docker-compose 可以一行架起來
### 容器（Containers）
隨著網站規模愈來愈大，可能會在這台機器上架好幾個網站，
gitlab, blog, prometheus 等等，
這些服務都建議盡量容器化用 Docker/Docker-compose 跑，
過程中會對 Containers 比較熟
如果有興趣也可以玩 Kubernetes 或類似的容器管理平台，但 k8s 水很深，慎入
### 寫小工具 / 接觸開源
如果前面的部份都摸得差不多了，可以加強 Develop 的程度，
去多摸一門語言，或是深入研究本來會的語言的特性、OOP
也可以嘗試寫一些小工具，例如爬蟲、middleware、metrics exporter 等等
同時在這個階段儘可能的去接觸開源，一開始會覺得挫折、看不懂是難免的
對規模較大的 repo 欣賞它的架構、規模小的 repo 嘗試去看懂裡面的 code
廣泛閱讀 open-source 的專案、技術文章，是這個階段進步最快的方式
### 以專案為本
大量閱讀 open-source 的程式碼和技術文章的過程中，可能會讀到很多沒用過的技術，
但也比較能區分 Clean/Dirty Code，
這時候可以嘗試做比較大型的專案，套用想學習的技術
如果有資源，可以做一個純雲端的專案，畢竟會徵 SRE 的公司很少有不上雲的，
而且雲端服務會提供很多服務，例如 Load Balancer、Auto Scaling 等等
又例如 SQL 要架在 EC2 還是用 Aurora 這些取捨都挺值得玩味的
（個人對 aws 比較熟，所以例子都舉 a 家的）
實習也是做專案的方式之一，如果沒辦法實習，看能不能儘量接觸多人開發的專案，
會對於軟體開發的流程更熟悉，
例如切 staging/production 環境、開發如何切 branch, 開 issue 等等
這裡節錄部份我以前做過的 project 和用到的技術
- LeetCode 爬蟲 (Go)
- Dcard 後端面試作業 (Go/Gin, Redis, Travis CI)
- 做 LineBot CI/CD Pipeline (aws: Route53, EKS (k8s), DynamoDB, S3; Vault)
- PTT 爬蟲 (Go, Goroutine, Channel)
- Blackbox Monitoring (Prometheus, Grafana, AlertManager)
- RESTful API Server (Go/Gin, jwt, ELK,
MySQL, Unit/Integration Tests, Redis, Prometheus,
Vue/TypeScript, azure: AKS, VM)
### 補足 OS、Networking 知識
說得直白一點就是為了面試做準備啦，但這些知識或多或少也會在實戰中用到
## 結論
在面試的 Q&A 環節，我問 ByteDance 的面試官「一個 SRE 應該具備哪些特質」，
他回答我要能臨危不亂、Reactive、Think out of the Box，
後者直翻是跳脫框架，但從面試官的解釋比較像是全局思考，
我個人會解讀出兩種層次，第一個層次是不能僅僅只在意 config 怎麼設定，
而要考慮整個架構的邏輯，包含前面提到的取捨，這才是體現一個 SRE 價值之所在
第二個層次是不要被工具綁架了，DevOps 注重的是流程和文化，
最近體驗到的一個例子是已經有 Python 的自動化的 script，
就沒必要引入其他的 CI/CD 工具，目的有達成最重要，這也是最近小的在努力的方向
除了技術以外，如果想要研究 DevOps 方法論的可以讀 鳳凰專案、DevOps Handbook
上面這兩本是直接與 DevOps 相關，
另外也可以讀一些管理學的書包含高德拉特的目標、第五項修煉，或是精實相關的書
SRE 一生都在和複雜系統打交道，也可以看看反脆弱和黑天鵝這一系列的書，
會對於一些神奇的方法論（例如 Chaos Engineering）比較理解緣由
不確定以上的內容對看的人有沒有幫助，畢竟還很菜，
如果有什麼問題或指點請不吝提出
個人其他地方常用 ID 是 jameshwc，歡迎大家找我交流
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 192.198.168.41 (美國)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1615535884.A.7C7.html
敏捷/DevOps 的精神就是不斷的回應環境的變化呀～
臨危不亂是講像是服務中斷時，你能不能頂住壓力，找出問題的癥結點
Reactive 講的是敏捷，能不能隨時因應環境的變化而行動，而不是僵固的維持本來的計
畫，同義詞是 responsive
※ 編輯: IcecreamHsu (49.216.170.213 臺灣), 03/13/2021 10:35:01
... <看更多>