Debug Production Cho Bình Tĩnh: 5 Bước Giúp Developer Xử Lý Sự Cố Nhanh Mà Không Hoảng

Production issue hiếm khi đáng sợ nhất ở bản thân lỗi. Thứ làm mọi việc tệ hơn thường là tâm lý hoảng, thay đổi liên tục không có ghi chép, và quá nhiều người cùng sửa nhưng không ai điều phối. Bình tĩnh không phải tính cách bẩm sinh; đó là một quy trình có thể luyện được.

1. Xác nhận phạm vi ảnh hưởng trước khi chạm vào code

Trước khi restart service hay sửa nóng, hãy trả lời bốn câu hỏi: lỗi xảy ra từ khi nào, ảnh hưởng tới ai, có tái hiện được không, và hệ thống nào liên quan trực tiếp. Phạm vi ảnh hưởng quyết định mức ưu tiên và cách phối hợp. Nhiều sự cố bị kéo dài chỉ vì team nhảy ngay vào fix khi bức tranh còn mờ.

2. Fix nhanh không đồng nghĩa với sửa bừa

Trong nhiều tình huống, rollback là giải pháp tốt hơn hotfix. Mục tiêu đầu tiên của incident response là khôi phục dịch vụ ổn định, không phải chứng minh bạn có thể nghĩ ra patch “siêu nhanh”. Khi buộc phải fix nóng, hãy chọn thay đổi nhỏ nhất có thể kiểm soát, rồi theo dõi sát sau khi release.

3. Phân vai rõ ràng giúp giảm nhiễu

Nếu có từ ba người tham gia trở lên, hãy phân vai tối thiểu: một người lái kỹ thuật, một người cập nhật trạng thái, một người xác minh sau khi đổi. Điều này nghe có vẻ hình thức, nhưng nó giảm đáng kể cảnh “ba người cùng gõ, không ai chắc hệ thống vừa đổi gì”.

4. Sau sự cố, đừng dừng ở câu “do bất cẩn”

Postmortem tốt không tìm người để trách. Nó tìm lỗ hổng hệ thống: cảnh báo thiếu, test chưa đủ, review chưa chạm đúng điểm rủi ro, runbook còn mơ hồ, hoặc knowledge tập trung vào một người. Một team trưởng thành sẽ biến mỗi lần sự cố thành một lần nâng chuẩn vận hành.

• Thêm monitor hoặc alert dễ hiểu hơn.
• Viết runbook cho những lỗi có khả năng lặp lại.
• Bổ sung regression test hoặc contract test đúng chỗ.
• Rút gọn các bước recovery để người trực sau bớt áp lực.

Bình tĩnh trong production không phải vì bạn ít sợ hơn người khác. Thường là vì bạn đã có sẵn một khung xử lý đủ rõ để nỗi sợ không lái tay mình.