SRE 面試相關問題
因為最近正準備找新的工作，開始複習之前找到的 SRE 面試問題(忘記出處在哪了)，答案都是憑筆者這兩年的工作實際經驗所回答，若有不詳盡或錯誤的地方，也歡迎大家指正討論
你之前的 SRE 部門有哪些監控？
服務端:
- 內部(機房內)與外部對服務的 health check endpoint 做監控，確保服務基本穩定性
- 對容器化的服務還會監控重啟、OOM 的次數
- 對伺服器則做最基本的連線監控(SSH port)，並監控各機器的 CPU/memory/網路 IO 使用量
- 監控 configuration management 運行的狀態，確保所有伺服器維持一致的設定
- 透過 bot 回報各大雲平台的 incident page RSS
網路端:
- 監控各大雲平台與機房間網路穩定性與延遲狀況(smokeing)
- 監控機房內防火牆、 switch 的 SNMP trap
- 監控 VPN 連線與 routing 的狀態
資料庫端:
- 監控 DB 的連線數、slow-log 數量、同步的狀態等
你怎麼做業務監控？
較細部(HTTP response content)的監控由開發團隊來設計，SRE 會透過各種 exporter 來收集各組工作機上的 php-fpm active process、連線數量與流量，以及 load balancer 上的 request count, response code, response time 等數據(RED met)
對於服務本身，我們會在不同時間長度下計算不同微服務平均的使用者數量，request 數量
最後，我們會監控跟服務相關的各個節點(如 storage, DB, message queue, cache system 等)的健康狀況
你如何判斷服務出問題？
除了最基本的 health check fail，我們同時使用外部平台來監控服務，確認連線正常。從 HTTP error response, php-fpm active process 的數量也能觀察出服務是否穩定
我們同時會觀察網路與 DB 的狀態，確認是否有網路問題、連線數過多、或是 DB slow log 數量上升
如何判斷一個服務具有高穩定性？
- 確認服務各個區塊的 SLO，一個服務的穩定性會受到最小 SLO 的中繼服務給影響
- 觀察歷史數據觀察與伺服器的 loading/memory usage，確認服務在高 QPS 時能仍保持正常服務
- 確認服務留有足夠的資源容量可以做擴展，並對 DB 或甚至整個 site 的層級都做了 HA
- 服務上線前做穩定性與壓力測試
如何從服務獲取及統計 HTTP 狀態碼？
RD 會對 HTTP response content 之結果做監控，SRE 則會透過 load balancer log 來觀察後面每個 endpoint 的回應狀態，並 exporter 輸出，由 Prometheus 來統一收集，做後續的分析與觀測圖表的建置
若只監控 5XX 的 HTTP 狀態碼是否足夠？
我們同時會統計(但不設定告警)4XX 及其他狀態碼的數量，方便在出問題的時間點，回頭查找是否有設定改變，或新的程式碼上線等變化
同時開發人員也會對服務做更細部的測試，包含 HTTP response content，透過模擬使用者的行為，確認服務中每個端點的回應都是符合預期的
若服務回覆 2XX，但其實回覆內容有錯誤，有什麼解決方法？
可以對 HTTP response content 做分析，模擬使用者的行為，使用不同的測試資料(header, request body)，來確認服務中每個端點的回應都是符合預期的，也可以將測試實作在 CI/CD pipeline 中
你怎麼理解微服務，它有什麼優缺點？
相較於單一大服務，微服務代表將各個功能模組(甚至是資料庫)切分出來，個別獨立管理，並透過 service mesh 等技術相互通訊
好處是每個功能可以解耦，使用不同的語言開發，並依照不同部門的開發進度來迭代
壞處是若缺乏良好的監控與日誌機制，會很難除錯，難以找到真正出問題的服務。服務間的通訊成本，資料的同步成本，都會使整體架構變得更複雜 ，增加維運難度
什麼是 SLA, SLO？你之前的部門是如何實現，監控這個指標？
SLO 為服務等級目標，訂定對服務穩定度的期望狀態，通常是用 service uptime 來計算。而 SLA，則是公司與客戶簽訂的服務穩定性合約，一旦未達成，就會有相對應的懲罰
我們並非對企業(B2B)的服務，所以對 SLO 的要求沒有這麼嚴謹，但仍會設定重要服務(登入、操作與交易等)的 SLO 達到一定的水準
請求的回覆延遲突然大幅提高時，你會怎麼排除問題？
- 觀察服務的 traffic 量與其 php-fpm(若為 php 框架) active process 是否上升，同時觀察伺服器本身的 loading/network IO 是否上升(判斷是否受到攻擊)
- 觀察其連接的 DB/cache 系統的狀態，是否有 slow query
- 觀察監控端與伺服器端的網路連線是否有異常
- 觀察使用的雲端服務是否有異常狀態
