Incidents, fixes, and the day after

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

Bối cảnh

Kỹ sư Booking.com được tự deploy thẳng lên production 24/7. Năm 2012 bộ phận còn nhỏ, vài trang wiki là đủ; đến 2017 bộ phận có gần 2.000 người trên toàn cầu, nên làm lại hướng dẫn xử lý sự cố.

Nguyên tắc dẫn đường: "Escalations are cheap": ai không chắc vấn đề đã được kiểm soát thì cứ escalate để gọi nhóm phản ứng nhanh (firefighters). Chống quá tải bằng giao tiếp và "tự do rời đi": ai thấy mình không giúp được hoặc tình hình đã ổn thì rời.
Vòng đời: bắt đầu escalate → tập hợp → khôi phục cho khách trước → đóng escalation → làm giải pháp lâu dài → postmortem.
Vai trò: Incident Leader chỉ điều phối và giao mọi việc, kể cả việc nhỏ nhất; Comms lo cập nhật bên liên quan và mang phản hồi bên ngoài vào, để người xử lý không phải viết email.
Cạm bẫy lớn nhất (theo Booking): lao vào tìm nguyên nhân gốc ngay. Ổn định bệnh nhân trước, chữa vết thương sau.
Sự cố chỉ xong khi hệ "về bình thường": giải pháp tạm phải được thay bằng bản sửa ổn định; nếu lâu thì team sở hữu làm như việc ưu tiên rồi mới đóng.
Postmortem giao cho team sở hữu vùng nghi là nguyên nhân (coi là ghi nhận chuyên môn, không phải phạt). Văn bản RFO (Reason For Outage): không đổ lỗi, không tên người, không cả tên team; người ít bối cảnh đọc hiểu được; follow-up đã có người nhận; timeline vừa đủ; nêu rõ ảnh hưởng.

Khi tổ chức lớn, hạ chi phí của việc báo động quan trọng hơn tránh báo động thừa; cân lại bằng quyền rời đi (Sự cố và postmortem).
Tách người chỉ huy, người liên lạc và người sửa là mẫu chung (so với IMOC/TLOC/BMOC của Dropbox).