Alerting on Service-Level Objectives (SLOs)

SoundCloud · 2019 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Theo SoundCloud, alert dựa trên SLO gần như là "viên đạn bạc" cho alert có ý nghĩa: đạt SLO là định nghĩa của việc đáp ứng kỳ vọng của user, còn một mức lỗi nằm trong SLO (error budget) là chấp nhận được. Họ áp dụng chương "Alerting on SLOs" của SRE Workbook.
• Triệu chứng hay nguyên nhân: thời một server LAMP, server chết là site chết. Nay hàng trăm, hàng nghìn server, luôn có vài cái chết mà hệ vẫn chịu được. Alert gọi người dậy (page) phải dựa trên triệu chứng ảnh hưởng user, khẩn và làm được gì đó; còn lại là ticket xử lý trong giờ làm việc.

Thay đổi chính

• White-box là chính, black-box là phụ. Probe Catchpoint mô phỏng cách dùng điển hình chỉ dùng để tính mục tiêu khả dụng tháng/quý/năm, không để page: probe không phải traffic thật (bài test có thể chạy được trong khi bài đang viral thì không), cần rất nhiều probe và thời gian mới thấy được tỉ lệ lỗi thấp và latency đuôi, và không thấy được vấn đề sắp xảy ra.
• "Triệu chứng của người này là nguyên nhân của người kia": đo ở tầng gọi (white-box của frontend) để biết backend có giữ SLO nội bộ hay không. Chỗ đáng làm nhất là tầng terminator HAProxy ở biên: tỉ lệ 5xx theo từng backend.
• Multiwindow, multi-burn-rate: recording rule tính tỉ lệ lỗi theo 5m, 30m, 1h, 2h, 6h, 1d, 3d; SLO mỗi backend là một recording rule hằng số (đa số 0,1%, có cái 0,2%). Bốn alert:
  • Page: cửa sổ 1h + 5m, burn rate 14,4 (đã tiêu 2% ngân sách tháng), for 2 phút.
  • Page: 6h + 30m, burn rate 6 (5%), for 15 phút.
  • Ticket: 1d + 2h, burn rate 3 (10%); 3d + 6h, burn rate 1 (10%), for 1 giờ.
  • Ví dụ: SLO 0,1% thì page khi hơn 1,44% 5xx trong cả 1 giờ và 5 phút gần nhất. Backend lỗi 100% đột ngột thì sau khoảng 52 giây đã vượt ngưỡng giờ. Cửa sổ ngắn giúp alert tắt nhanh sau khi sửa (và bắn lại được nếu tái phát).
• Khác SRE Workbook: thêm for ngắn (Workbook khuyên không dùng vì làm chậm phát hiện) để tránh nhiễu từ dao động rất ngắn.
• Định tuyến theo nhãn system: một registry ghi team nào sở hữu system nào; cấu hình Alertmanager được sinh tự động từ đó để alert tới đúng lịch trực; mọi thứ gắn nhãn được (pod Kubernetes...) đều có nhãn system. Mỗi alert có link runbook.

Vì sao

• Burn rate cho page nhanh khi ngân sách cháy nhanh, ticket khi cháy chậm: không bỏ sót, không đánh thức người vì chuyện chờ được (Xử lý sự cố và on-call, Observability và monitoring).

Bài học cho SWE

• Page theo triệu chứng (vi phạm SLO), ticket theo nguyên nhân; probe black-box để báo cáo khả dụng chứ không để page.
• Đo ở tầng biên (load balancer) cho tỉ lệ lỗi theo từng backend mà không cần mọi service tự instrument.
• Sinh cấu hình định tuyến alert từ registry sở hữu, đừng viết tay.

Liên quan

• SoundCloud 2016 · Loveholidays 2021 · Monzo 2019 · Salesforce 2019
• Xử lý sự cố và on-call · Observability và monitoring