Recovery cho business flow

Database đã restore nhưng đơn hàng vẫn có thể lỗi. Access, restart order và transaction thiếu hoặc trùng có thể ngăn business recovery.

Xác định kết quả

Chọn một critical flow. Với ordering flow minh họa, thành công gồm nhận đơn mới, restore đơn đã nhận, reconciliation payment và fulfilment không trùng.

Thống nhất recovery time và mức mất dữ liệu chấp nhận được với business owner. Ghi mục tiêu chưa rõ, không thay bằng khả năng hiện tại của infrastructure.

Theo dấu dependency

Lập bản đồ infrastructure, application, data, access và external dependency. Xem hướng dẫn có giả định identity, administrative access, DNS hoặc secrets vốn cũng có thể không khả dụng hay không.

Recovery order rất quan trọng: khởi động producer quá sớm có thể tăng backlog; replay queue với transaction boundary chưa rõ có thể tạo lỗi. Ghi điều đã thử và điều còn là giả định.

Đo transaction correctness

Ghi start/end condition, elapsed time, data loss hoặc divergence và exception. Có response chưa chứng minh transaction đúng. Kiểm tra:

• Flow có hoàn tất qua các dependency không?
• Transaction đã nhận có đủ và được reconciliation không?
• Operator có phát hiện và xử lý exception không?
• Recovery và rollback có hoạt động với access hiện có không?

Quyết định trong giới hạn

Giữ evidence, scenario, environment và giới hạn cùng nhau. Staging chưa chứng minh hành vi production. Giao owner và acceptance condition cho dependency còn thiếu.

Không đạt mục tiêu nghiệp vụ cần engineering change hoặc risk acceptance rõ ràng. Evidence chưa đủ cần verification bổ sung.

Bắt đầu từ evidence hiện có và điều kiện non-production đại diện. Thử nghiệm gây gián đoạn trên production cần phê duyệt rõ ràng, blast radius có giới hạn, monitoring, abort conditions và rollback. Đây là phương pháp, không phải kết quả đo từ khách hàng. Xem recovery readiness và assessment scope.