Một lỗi cạnh tranh tiềm ẩn trong hệ thống quản lý DNS của DynamoDB đã xoá toàn bộ địa chỉ của điểm cuối dịch vụ tại vùng US-EAST-1, kéo theo EC2, bộ cân bằng tải NLB và nhiều dịch vụ khác; sự cố kéo dài khoảng 14,5 giờ. Bài học cho PM: phụ thuộc dây chuyền, quyết định "một vùng hay nhiều vùng", và cách đọc bài hậu kiểm của nhà cung cấp để cập nhật sổ rủi ro của mình.
Quyết định không triển khai đa vùng thường dựa trên chi phí, nhưng thiếu so sánh với tổn thất kinh doanh mỗi giờ ngừng. Không có con số này, nhà tài trợ không thể quyết định dựa trên dữ liệu.
Sau khi nguyên nhân gốc được sửa, hệ thống vẫn nghẽn vì hàng đợi, thử lại và kiểm tra sức khoẻ dồn dập. Kế hoạch phục hồi cần có bước khôi phục dần và cơ chế giới hạn lưu lượng, không chỉ "bật lại".
Không phải dịch vụ nào cũng cần đa vùng; quyết định nên dựa trên tổn thất ước tính:
Chạy ở nhiều vùng, có kiểm tra chuyển đổi định kỳ và không phụ thuộc vào dịch vụ điều khiển của một vùng duy nhất.
Có vùng dự phòng ở chế độ chờ, chấp nhận thời gian chuyển đổi tính theo giờ.
Một vùng, ghi rõ chấp nhận rủi ro và có thông báo cho người dùng khi gián đoạn.
Liệt kê dịch vụ nền (cơ sở dữ liệu, DNS, đăng nhập, hàng đợi) mà từng chức năng nghiệp vụ dựa vào, kể cả những thứ nhà cung cấp tự dùng ngầm; cập nhật khi kiến trúc thay đổi.
Mỗi báo cáo sự cố công khai là dữ liệu miễn phí: đối chiếu với kiến trúc của mình, cập nhật sổ rủi ro, và chuẩn bị mẫu thông báo cho khách hàng nội bộ và bên ngoài.
Một nhà cung cấp lớn không đồng nghĩa với không có điểm lỗi đơn lẻ. Hãy định lượng thiệt hại mỗi giờ ngừng, đối chiếu với chi phí đa vùng, và ghi rõ rủi ro nào bạn chọn chấp nhận để nhà tài trợ quyết định có chủ đích.
Bạn chọn phương án nào?