Hotfix
Bản sửa gấp đưa thẳng lên môi trường thật để chặn một sự cố đang gây thiệt hại, bỏ qua phần lớn lịch phát hành thông thường nhưng vẫn phải test và ghi lại đầy đủ.
Định nghĩa
22h30, tổng đài báo khách không đặt được hàng. Truy ra một dòng cấu hình sai sau bản deploy chiều nay. Không ai đợi tới sprint sau. Sửa, test nhanh, đẩy lên PROD trong đêm — đó là hotfix.
Hotfix là bản sửa gấp trên môi trường thật, đánh đổi quy trình lấy tốc độ, và phải trả lại phần quy trình đó ngay sau khi hết cháy.
Hotfix, patch và release thường
| Hotfix | Patch | Release thường | |
|---|---|---|---|
| Lý do | Sự cố đang gây thiệt hại | Gom vài lỗi nhỏ | Tính năng mới theo kế hoạch |
| Phạm vi thay đổi | Rất hẹp, một chỗ | Vài chỗ liên quan | Rộng |
| Thời gian | Vài giờ | Vài ngày | Theo lịch sprint hoặc quý |
| Mức test | Sanity chỗ sửa, regression bộ rút gọn cho các chức năng dùng chung, smoke trên PROD | Regression rút gọn | Regression đầy đủ |
| Ai duyệt | Người có thẩm quyền trực, quyết nhanh | Quy trình thường | Quy trình thường |
Ranh giới hotfix và patch mỗi công ty vạch một kiểu, có nơi gọi chung là emergency release. Cái đáng thống nhất là ngưỡng: tình huống nào thì được phép đi đường tắt.
Quy trình rút gọn nhưng đừng bỏ trắng
Cắt bớt được nhiều thứ, nhưng năm bước sau nên giữ kể cả lúc gấp nhất:
- Xác định phạm vi tối thiểu. Chỉ sửa đúng chỗ gây sự cố. Đây là lúc tệ nhất để tiện tay dọn code hoặc nhét thêm một chỉnh sửa nhỏ.
- Có người thứ hai nhìn qua. Năm phút đọc diff, kể cả lúc 1h sáng, kể cả khi người kia chỉ kịp mở laptop trên giường.
- Đừng deploy thẳng từ máy mình. Có staging thì chạy staging; không có thì UAT với dữ liệu tương tự — miễn là đã có một lần chạy ở đâu đó không phải PROD.
- Smoke test trên PROD ngay sau khi deploy, rồi theo dõi log và số liệu ít nhất 30 phút.
- Chạy bộ regression rút gọn quanh vùng ảnh hưởng. Chỗ vừa sửa hiếm khi đứng một mình: một hàm dùng chung, một cấu hình dùng chung là đủ kéo theo chức năng khác. Gấp quá thì chạy ngay sau khi deploy, nhưng bỏ hẳn thì đừng — bỏ regression vì vội là cách quen thuộc nhất để một sự cố đẻ ra sự cố thứ hai.
Và một bước hay bị bỏ nữa: đưa bản sửa đó ngược lại nhánh phát triển chính. Rất nhiều đội vá nóng trên nhánh release rồi quên merge về, tháng sau bản mới lên là lỗi cũ quay lại y nguyên.
Ví dụ thực tế
Mười lăm phút sau giờ mở bán, khách thanh toán thành công nhưng vé không được giữ chỗ: hàng đợi xử lý nghẽn. Đêm mở bán của một hệ thống bán vé sự kiện, khoảng 4.300 người vào cùng lúc. Đội quyết hotfix ngay trong đêm — nâng số worker xử lý hàng đợi và thêm cơ chế thử lại.
Toàn bộ mất 70 phút, gồm 20 phút sửa, 15 phút test trên staging, 10 phút deploy, còn lại là theo dõi. Bộ smoke chạy trên PROD gồm 6 bước, trong đó có mua thật một vé giá thấp nhất rồi hủy. Sáng hôm sau, đội viết một release note ngắn cho bộ phận chăm sóc khách hàng, kèm danh sách 87 giao dịch bị treo cần đối soát thủ công.
Chính cái danh sách 87 giao dịch mới là phần việc nặng nhất. Hotfix chặn được máu chảy tiếp, nhưng phần dữ liệu đã sai trong khoảng thời gian sự cố thì phải xử riêng — và đó thường là việc của BA.
Việc của BA khi có sự cố
- Xác định tác động nghiệp vụ: bao nhiêu giao dịch, khách nào, tiền bạc ra sao. Đội kỹ thuật lo phần hệ thống, phần thiệt hại nghiệp vụ ít ai nhìn.
- Chuẩn bị nội dung thông báo cho khách hàng và cho bộ phận chăm sóc khách hàng. Viết bằng tiếng người, không dùng chữ nghẽn queue.
- Lên phương án xử lý dữ liệu tồn: hoàn tiền, tạo lại đơn, hay đối soát tay.
Việc cuối cùng làm sau khi mọi thứ đã yên: truy nguyên nhân gốc rồi ghi lại. Đây là chỗ dễ trôi nhất, vì lúc đó ai cũng mệt và câu "do tải cao" nghe đủ hợp lý để không ai hỏi thêm.
Một quy ước nhỏ đáng có trong mọi dự án: mỗi hotfix phải sinh ra ít nhất một test case mới. Nếu lỗi đó đã lọt được xuống PROD một lần, nó cần một tấm lưới để không lọt lần thứ hai.
