Outage post-mortem

Dropbox · 2014 · 3. Quy mô lớn · Độ khó: Cơ bản — bài gốc

Bối cảnh

• Dropbox chạy hàng nghìn database, mỗi DB một master và hai replica, cộng backup full và incremental ở môi trường riêng. Các DB này giữ metadata cho tính năng (chia sẻ album, camera upload, một số API), không giữ nội dung file.

Thay đổi chính (diễn biến)

• Tối thứ Sáu, bảo trì nâng cấp OS: script phải kiểm máy không còn dữ liệu đang dùng trước khi cài lại. Một bug nhỏ làm script cài lại cả vài máy đang phục vụ, trúng cả cặp master-replica, site sập.
• Phục hồi bằng backup vì cả replica cũng mất: phần lớn chức năng trở lại sau khoảng 3 giờ, nhưng vài DB lớn khôi phục chậm nên tới 16:40 Chủ nhật mới đầy đủ.

Vì sao (bài học Dropbox rút ra)

• Script kiểm trạng thái từ xa đã sai; Dropbox thêm lớp kiểm trên chính máy đích: máy tự nhận biết đang chạy process quan trọng thì từ chối lệnh có tính phá huỷ.
• Công cụ chuẩn khôi phục MySQL từ backup chậm với dữ liệu lớn; họ viết công cụ replay binlog song song (hẹn mở mã nguồn).

Bài học cho SWE

• Replica bảo vệ khỏi hỏng phần cứng, không bảo vệ khỏi automation chạy nhầm lên cả master lẫn replica; thời gian khôi phục từ backup mới là RTO thật.
• Lệnh phá huỷ nên bị chặn ở đích (máy tự biết vai trò của nó), không chỉ dựa vào kiểm tra phía công cụ gọi.

Liên quan

• Sự cố và postmortem · Failover, replica và dự phòng dữ liệu · Tự động hoá vận hành và auto-remediation
• Dropbox về sau loại kịch bản phục hồi lâu hơn 20 phút: Dropbox 2021