Go-live xong phát hiện lỗi tính sai tiền: quay lui về hệ thống cũ hay sửa nóng trên production?

Gợi ý của Ban biên tập:

1. Hai giờ đầu – ưu tiên ngăn thiệt hại, không phải tìm người có lỗi.

• Xác định phạm vi ảnh hưởng: bao nhiêu khách hàng, bao nhiêu giao dịch, lỗi còn đang tiếp diễn không.
• Nếu có thể, chặn nguồn gây lỗi ngay (tạm dừng áp dụng gói khuyến mãi bị lỗi, tạm hoãn phát hành hoá đơn) — đôi khi đây là lựa chọn thứ ba tốt hơn cả quay lui lẫn sửa nóng.
• Lập nhóm xử lý sự cố với một người chỉ huy duy nhất, kênh liên lạc chung, cập nhật định kỳ cho các bên.
• Chuẩn bị thông điệp cho bộ phận chăm sóc khách hàng.

2. Tiêu chí quyết định quay lui hay sửa tiếp:

• Mức độ nghiêm trọng: lỗi tính tiền ảnh hưởng trực tiếp đến khách hàng và có thể cả tuân thủ quy định — mức nghiêm trọng cao.
• Độ chắc chắn của bản sửa: "4–6 tiếng" đã tính kiểm thử chưa? Bản sửa vội trên production có thể gây lỗi thứ hai.
• Chi phí quay lui: 3 tiếng + đối soát thủ công là cái giá biết trước; sửa nóng thất bại là cái giá chưa biết.
• Thời gian khách hàng tiếp tục bị ảnh hưởng ở mỗi phương án. "Không mất mặt" không phải tiêu chí — uy tín mất nhiều hơn khi để lỗi tính tiền kéo dài.

3. Chuẩn bị từ trước go-live:

• Tiêu chí quay lui viết sẵn và được sponsor duyệt (ví dụ "lỗi ảnh hưởng tiền của khách hàng mà không chặn được trong X giờ → quay lui"). Khi luật đã có, quyết định trong khủng hoảng nhanh và ít cảm tính hơn.
• Diễn tập quay lui trước ngày go-live.
• Tách triển khai khỏi phát hành: dùng công tắc tính năng (feature toggle) để có thể tắt nhanh một chức năng mà không phải quay lui cả hệ thống. Martin Fowler mô tả release toggle là cách đưa mã chưa hoàn thiện lên production ở trạng thái ẩn và chỉ bật khi sẵn sàng.
• Triển khai từng phần (một nhóm khách hàng trước) để giới hạn phạm vi ảnh hưởng.

4. Sau sự cố: hoàn trả cho khách hàng bị tính sai, họp rút kinh nghiệm không đổ lỗi (blameless), cập nhật kế hoạch kiểm thử cho các kịch bản khuyến mãi.

Theo PMBOK 7, đây là lĩnh vực Delivery và Uncertainty, cùng nguyên tắc thích ứng và phục hồi: hệ thống tốt không phải là không bao giờ lỗi, mà là phục hồi nhanh khi lỗi.

Nguồn:

• Feature Toggles (aka Feature Flags) — Martin Fowler