How we do On-Call Rotations

Nubank · 2019 · 3. Quy mô lớn · Độ khó: Dễ — bài gốc

Bài khuyến nghị dựa trên kinh nghiệm của tác giả ở Nubank; không có số liệu MTTA/MTTR cụ thể.

Bối cảnh

• Đo chất lượng trực bằng MTTA (sức khoẻ của lịch trực) và MTTR (chất lượng công cụ và tài liệu). Tự nhiên nhất là team xây hệ nào trực hệ đó, nhưng team chỉ 2–8 người nên mỗi người trực nhiều ngày mỗi tháng, mà trực thì mệt.

Thay đổi chính

• Gộp nhiều team vào một lịch trực chung cho cả nhóm hệ thống, nên người trực không nhất thiết là người làm hệ đó. Điều kiện bắt buộc:
  • Dashboard và công cụ điều tra dễ hiểu.
  • Không alert nào thiếu runbook; runbook viết và thử với người ngoài team (người đọc đang căng thẳng; "connect vào server production" có thể vô nghĩa với họ); mở đầu bằng link dashboard chứa dữ liệu đã kích alert.
  • Tuyệt đối không có alert chập chờn: team tự trực quen bỏ qua alert "tự hết sau 3 phút", người team khác thì bị đánh thức vô ích.
• Chia ca: 5 ca/tuần (T2–T3, T4–T5, T6, T7, CN) vì người ta quý cuối tuần hơn ngày thường; ca bắt đầu 10h sáng.
• Hai lớp: lớp chính gồm cả pool, bắt buộc, một người; lớp hai là cả team sở hữu alert, best-effort, cùng bị gọi một lúc khi leo thang. Qua hàng chục lần leo thang, chưa lần nào lớp hai không ai trả lời.
• Cách triển khai: bắt đầu gộp hai team có ngữ cảnh gần nhau; lấy thống kê alert (bao nhiêu, ngoài giờ bao nhiêu, bao nhiêu tự hết), dọn alert và viết runbook trước. Theo bài, phần lớn team chỉ có 4–5 alert đủ quan trọng để đánh thức người lúc nửa đêm, và alert nghiêm trọng nên chỉ vào triệu chứng ảnh hưởng user. Retrospective hằng tháng có thống kê alert; kênh chung để đòi runbook và đổi ca. Pool 20 người thì mỗi người một ca mỗi tháng.
• Vấn đề thường gặp: alert trong giờ làm việc (công cụ không có lịch nghỉ lễ địa phương); team gây quá nhiều alert làm người khác bực (có thể đặt hạn mức, vượt thì team quay về tự trực); OpsGenie xáo lịch khi thêm/bớt người; team quá đặc thù không viết nổi runbook thì tự trực tiếp.

Vì sao

• Giảm số ngày trực mỗi người cần pool lớn hơn team; muốn người ngoài trực được thì tri thức phải nằm trong runbook và alert phải đáng tin (Xử lý sự cố và on-call).

Bài học cho SWE

• Trước khi gộp lịch trực, dọn alert: bỏ alert chập chờn, viết runbook cho mọi alert còn lại.
• Mục tiêu của người trực là khôi phục dịch vụ theo runbook rồi leo thang, không phải sửa bug gốc.
• Có cơ chế trả team về tự trực nếu team đó gây quá nhiều alert.

Liên quan

• Monzo 2019 · Monzo 2022 · Zalando 2023
• Xử lý sự cố và on-call