Skip to content

postmortem

SRE: How Google Runs Production Systems 讀書筆記(四)

  • Ops

on-call

關鍵是「數量」跟「品質」的平衡:

  • 數量:不超過 25% 時間 on-call
  • 品質:須要有充足的時間處理(含分析、debug、事後檢討,一個事件約須花 6 小時完成)

幾分鐘內要回應?

回應時間與服務水準、可靠性有關,例如面向使用者的服務須在 5 分鐘內回應,非敏感業務通常是 30 分鐘

維運負擔過大怎麼辦?

事件 / 警報比例應接近 1:1,避免重複警報導致維運壓力、調派有經驗的 SRE 協助、與研發團隊一起分擔維運

系統太穩定怎麼辦?

維運壓力不夠會導致自信過度或自信不足,每個工程師每季應至少參與一次 on-call,公司可定期舉辦災害演練

故障排除技巧

故障排除是一連串的「假設」+「排除」,這個技能是可以教學相長的,如果能做好事後檢討、紀錄負面結果(negative result),故障排除會是學習一套系統很有效的方法

小心避免以下陷阱:不理解現象(方向錯誤)、假設是對的,但測試假設的方法錯誤、過早下結論、被巧合/偽相關誤導

「緊急情況下,飛行員的首要任務是保持飛機飛行及安全登陸,故障定位和排除只是次要目標。」

Google 用什麼追蹤工具?

每個系統用的工具可能不同,文中提到的 Dapper 是 Google 內部很廣泛應用的工具,特別看了一下文獻整理幾個重點

在分散式系統,跨服務請求很常見,例如發出一個 requestX,在下游會發出額外數個請求 —— 攤開看就是一個 Tree(巢狀的 RPCs)

這個請求/響應歷程的樹狀結構稱為一個 Trace,當中的節點就是單一請求/響應,稱為 Span,裡面會紀錄時間戳、traceID、parentID、host 等詳細資訊。Span 是以本地文檔的方式建立和寫入的,再透過 Dapper daemon 去拉取並儲存到後端 —— BigTable, Trace 存成 row,Span 存到其對應的 sparse column

可以把 Span 視為是一種 Log,除了運行在伺服器上的 Dapper daemon,應用程式也可以透過函式庫發送 Span、加標籤或自訂的額外訊息等,這個重要功能稱為 annotation

Dapper 設計上很重視的理念是「低成本」,包含本地檔案的讀寫、後端儲存、網路頻寬(只佔小部份),因此採用取樣 (sampling) ,經驗上顯示取樣不只可以大幅降低延遲,也能讓資料得以保存更久,Dapper 的預設取樣率是 1/1024——對數據密集型系統而言,不會造成分析上的盲點

Dapper 原本只是一個追蹤工具(黑箱的),但後來演化成一個大型的監控平台,有強大的界面可以幫助分析,甚至到後來,發現可以應用的層面更廣:系統的依賴關係(dependency)分析、網路狀態分析、在共享儲存的基礎上區分服務、長尾延遲的分析、錯誤報告分析等

Read More »SRE: How Google Runs Production Systems 讀書筆記(四)