Ngày 31/01/2017, một kỹ sư GitLab xoá nhầm thư mục dữ liệu của cơ sở dữ liệu chính. Khi cần khôi phục, nhóm phát hiện gần như mọi cơ chế sao lưu đều hỏng hoặc chưa từng được thử. Phân tích sự cố dưới góc nhìn quản lý rủi ro: rủi ro "đã có biện pháp" nhưng chưa bao giờ được kiểm chứng hiệu lực.
Xử lý sự cố replica bằng lệnh thủ công trên môi trường production, vào ban đêm, khi người thao tác đã mệt, là một rủi ro thứ cấp (secondary risk) phát sinh từ chính hoạt động ứng phó. Kế hoạch ứng phó tốt phải tính đến rủi ro do chính nó tạo ra — ví dụ yêu cầu kiểm tra chéo hoặc runbook có xác nhận máy chủ đích trước lệnh huỷ dữ liệu.
Trong Phân tích định tính (Perform Qualitative Risk Analysis), mức độ tin cậy của dữ liệu (data quality assessment) quan trọng ngang xác suất và tác động. Năm lớp sao lưu tạo cảm giác dư thừa, nhưng chúng có cùng nguyên nhân gốc: không ai kiểm thử khôi phục. Các biện pháp phụ thuộc lẫn nhau thì không cộng dồn độ an toàn.
Mỗi rủi ro trọng yếu trong risk register phải có một risk owner chịu trách nhiệm theo dõi trigger và báo cáo hiệu lực biện pháp. Sau sự cố, GitLab cũng xác định cần có người sở hữu độ bền dữ liệu (data durability).
Đưa diễn tập khôi phục vào kế hoạch quản lý rủi ro như một hoạt động định kỳ, có tiêu chí nghiệm thu đo được:
Khôi phục tự động bản sao lưu mới nhất sang môi trường riêng và đối chiếu dữ liệu ít nhất mỗi tuần; thất bại là sự cố mức cao.
Thống nhất với bên liên quan lượng dữ liệu tối đa được mất và thời gian khôi phục tối đa; vượt ngưỡng trong diễn tập thì leo thang.
Không nhận được báo cáo sao lưu thành công trong 24 giờ thì tự động cảnh báo trên kênh trực, không phụ thuộc email.
Dùng runbook có bước xác nhận tên máy chủ, phân quyền tách bạch production/staging, và nguyên tắc "hai người" cho mọi lệnh phá huỷ dữ liệu trên production.
Thêm cơ chế sao lưu khác loại và độc lập về hạ tầng (ví dụ lưu trữ nhật ký giao dịch liên tục — WAL archiving — ở nơi khác), để một lỗi cấu hình không đánh sập mọi lớp cùng lúc.
Thực hiện hậu kiểm không đổ lỗi (blameless postmortem), cập nhật risk register và kho bài học kinh nghiệm (lessons learned register). GitLab đã làm điều này công khai, giúp giữ được niềm tin của cộng đồng người dùng.
Một biện pháp ứng phó rủi ro chưa từng được kiểm thử chỉ là một giả định. PM phải giám sát hiệu lực của biện pháp — "sao lưu chỉ tồn tại khi đã khôi phục được" — chứ không dừng ở việc đánh dấu "đã triển khai" trong risk register.
Bạn chọn phương án nào?