Open Sourcing Iris and Oncall

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

Bối cảnh

Trước 2015, kỹ sư NOC escalate sự cố bằng tay: không rõ ai là người liên hệ thứ hai và liên hệ bằng gì; số alert tăng nhanh hơn nhiều so với số người ở NOC. Đường escalate cũ lấy theo quản lý trong LDAP nên sự cố của kỹ sư cấp cao nhảy thẳng lên director, VP.

Iris (hè 2015): hệ escalation tự động. Ứng dụng tạo incident qua REST API; Iris gửi tin theo escalation plan gồm nhiều bước (gửi song song cho team và người trực, lặp lại có giãn cách, sang bước sau nếu không ai nhận) cho tới khi có người claim.
Plan chỉ ghi mức ưu tiên, mỗi người tự map ưu tiên sang kênh (Slack, SMS, gọi). Gửi qua nhà cung cấp (Twilio, Slack). Role (team, on-call, manager) tra động từ nguồn khác.
Oncall: lịch trực tách riêng (xoay ca, follow-the-sun, đổi ca), là nguồn sự thật cho role on-call của Iris; nhiều team IT chỉ dùng Oncall mà không cần escalation.
Bão alert: escalate tay vô tình gộp alert (NOC chỉ gọi một cuộc); tự động hoá làm mất lớp gộp đó. Họ thêm batching và tự hạ ưu tiên khi một người nhận quá nhiều tin, nhưng theo bài cách thật sự là gom và chỉnh lại alert: Iris chỉ làm lộ vấn đề đã có.
Giữ Iris đơn giản: chỉ lo việc incident được nhận; gửi tin và sinh alert nằm ngoài. Lần thử đầu gắn chặt vào pipeline metric quá giòn. Trong khoảng 1,5 năm chỉ có một sự cố lớn; xử lý hàng trăm incident mỗi ngày.

Escalation phải mở rộng theo số alert chứ không theo số người NOC; tách lịch trực khỏi escalation cho phép mỗi phần có người dùng riêng.

Hệ báo động càng ít phụ thuộc càng tin được, vì nó phải chạy đúng lúc mọi thứ khác hỏng.
Tự động hoá một quy trình tay có thể bỏ mất một chức năng ngầm (gộp alert); kiểm tra trước khi thay.