SRE: How Google Runs Production Systems 讀書筆記（四）
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)分析、網路狀態分析、在共享儲存的基礎上區分服務、長尾延遲的分析、錯誤報告分析等
