2 posts tagged with "SRE"

判斷邏輯​

網路服務會發生問題狀況有很多,以下會用樹狀圖去做個判斷邏輯,當然這是建立在我目前遇到過的各種各樣情況上,同時也會加上判斷中會使用的方法！

HTTP status 介紹​

• 1xx - 資訊性狀態碼（Informational Status Codes）：表示請求已收到，並且伺服器仍在處理中.
• 2xx - 成功狀態碼（Success Status Codes）：表示請求成功被伺服器接受和處理.
• 3xx - 重新導向狀態碼（Redirection Status Codes）：表示需要進行進一步的操作以完成請求.
• 4xx - 用戶端錯誤 : 常見有 400 請求無效,server 無法理解,404 資源不存在
• 5xx（Server Error Status Codes）- 伺服器在處理請求時發生錯誤.

4xx 判斷過程及工具​

出現 4xx 不一定全是 client 問題,因為這與你 server 端 code 可能有關係,可能今天問題是 RD 的靜態資源放錯路徑,前端拿不到,也有可能是客戶端編碼跟 API 串接方式錯誤等等.

在排查此類問題,客戶端提供的報錯節圖,url,跟網路速度都是重要判斷依據.如果明確知道問題原因,那可以直接跳階段測試,不知道原因的話建議可以以下判斷:

1. 靜態資源未拿到: 請客戶端檢查網路環境,提供網路速度,ping 跟 traceroute 結果,是否有清 cache,server 端確認是否有此資源,跟有無 purge.
2. 編碼問題: 這要看 server log,並請開發人員溝通.

順序問題,4xx 的問題可以從 client 端開始查到 server 端.

5xx 判斷過程跟工具​

主要跟 code,hardware, app's condition,internet 都有關係,且可能彼此混雜,就 RD 覺得是 IT 設定 waf,IT 覺得是ＲＤ的程式問題. 也因此,建立判斷的過程很重要.

1. hardware 問題,基本上有裝監控項可以看到性能就沒問題

2. internet 問題,這邊就很複雜了,如果基本的 server 端互相 telnet 都有過,那接下來就要乖乖重投檢查了,這邊先不考慮 ICP 或雲服務商掛掉,這兩個掛掉應該很多網站都會掛,那剩下就是排查 waf.排查 waf 工具有以下

   • /etc/hosts: 綁定 DNS
   • web server 端的 curl.

排查流程​

網路發出的流程會是:client請求 -> CDN -> web server轉導-> 後端程式處理

所以排查順序也可以是由外到內,client 端開始查,但通常都是並行的,就是 client 端那邊查網路連線品質,server 端也同時看服務情況跟 log.

• 情境一: 客戶反應說他的 request 被攔截了,原因是 xxx cors.

  檢查流程：

  1. 先去 CDN 看是否被 WAF 阻擋.
  2. web server 看是否有設定 WAF 或者有設定跨域設定,及其阻擋紀錄.
  3. 後端程式規範的跨域跟安全套件.

• 情境二: 客戶反應說他的 request 被攔截了,原因是 xxx header 的 sameorigin problem.

  檢查流程：

  1. 先去 CDN 看是否被 WAF 阻擋,如無,就綁定/etc/hosts 不走 CDN 直接到 web server ip 做測試
  2. web server 檢查是否有限定 header.
  3. 從 web server 那邊直接 curl 目標 server ip:port,ex.以下指令示範

curl -v http://10.0.0.1:92

去看請求後端時是否就有強迫帶該 header,如有就代表程式端有帶套件去加 header

4. code 端可能用的套件,例如 js 的helmet套件.

在測試流程中發現限制,也不代表你一定要開放,例如,iframe 的內嵌就會牽涉到點擊劫持,跨站腳本攻擊（Cross-Site Scripting, XSS),內容竊取,會限制就會有他的原因.

非 4xx 或 5xx​

這個判斷基本上就是看 F12 報錯項目了,看完之後的判斷,也是依據 4xx 或 5xx 類別去判斷.

小結​

基本上,排查流程一定要有個順序,由外到內或內到外(看習慣),客戶端到 server 中間的所有事情都要一個一個查,剛開始可能因為經驗不足,到一半就會放棄了,像我就是ＸＤ,但隨著時間增加,看得問題也變多了,就要去紀錄不足之處,以及中間固定要做的事情!

如果排查一遍還是找不到問題,就要去想你過程可能漏掉哪些細項,哪些測試是可以做但你還沒做或不知道怎麼做的！

SRE​

使用過的 IaC 工具​

使用過的域名、證書管理工具​

基本上這邊就看個人回答,工具部分有 certbot 可以做定期 renew 憑證!

DevOps​

雲端平台理解​

• IAM:

• VPC:

• peering connection

• cloudwatch

• cloudtrail

請問心目中理想 pipeline!​

理想的 CI/CD pipeline 應該具有自動化、快速、可靠且能快速反饋.

• 自動化:基本上滿直觀得,跑 CI/CD 就是希望減少手動,所以盡量要讓所有過程自動
• 快速部分:各家 CI 會有不同配置,主要是透過檢視流程,讓沒有相依性的 jobs 可以平行處理,並適當使用 cache,減小使用的 image size 等等.
• 可靠: pipline 流程設計要有一致性,部署的環境跟資料源穩定
• 快速反饋: 將過程成功或失敗,透過 webhook 或其他方式發送到通訊平台

ps: pipline 過程

• code management: 程式碼依規定建立分支,tag,commit 放入版本控制系統,
• Build: 將檔案進行編譯
• 自動測試：包含單元測試,整合測試,確定新開發的 function 功能不會破壞既有功能
• (optional)建 image 並推到 registry: 這適用於用 container 部署的項目
• 部署到測試環境: 環境可能有很多個,如果用 ec2 之類是用 ssh 做部署(可以配合 ansible 腳本),如果是 image 就有需要並執行的過程！
• 驗證: 對於新開發功能進行驗證,確認功能正常,符合需求
• 部署到 production
• 監控:這牽涉到硬體跟服務的日誌監控跟分析
• Rollback: ㄧ旦發現要能進行 rollback

如何提升系統穩定性（ex 證券業）,降低伺服器意外故障風險？​

雲端部分,的確是會遇到某個 AZ 機器突然掛掉的問題,畢竟他對機器保障的 down time 本來就不是 100%,如果是用 VM 之類起服務,可以在將服務部署在同一 Region 的各 AZ 中,即使一個 VM 掛了,其他的也可以提供服務！ 地端機器也是同樣概念！

運維​

基本上,他就是全包所有東東(除了開發),著重維護底層,或許會碰到部署,所以基本上要有以下觀念

• 監控系統建立跟操作: 一般硬體,process 監控,port 監控,常用資源:Zabbix,Grafana,Prometheus
• 日誌系統: 日誌系統收集跟傳輸資訊:filebeat,日誌系統分析:ELK,Graylog.
• 資料庫管理: 設計，管理和維護資料庫，包括備份和恢復，性能優化，安全管理等。
• 網路管理: 維護和管理網絡設備，如交換機，路由器和防火牆。包括設置網絡拓撲，網絡設置和配置，網絡性能優化和維護,包含雲端跟地端.
• 安全性管理: 確保系統和數據得到妥善保護，防止未經授權的訪問和數據洩漏,包含防毒安裝.
• 軟體管理: 軟體部署,跟版本管理等
• 資料備份和災難恢復: 確保所有資料都能夠備份和恢復,並建立計畫並測試.