Debug sự cố production và viết postmortem không đổ lỗi Trung cấp

Cụm này trả lời: production lỗi thì xử lý theo thứ tự nào, debug bằng công cụ gì, và rút kinh nghiệm thế nào để không lặp lại.

Vấn đề

14:05, alert báo p99 của API checkout vượt 2 giây. Ba kỹ sư cùng nhảy vào: một người đọc log, một người restart Pod, một người sửa config pool. 40 phút sau hệ thống tự hồi phục, và không ai chắc vì sao.

Tuần sau, buổi “rút kinh nghiệm” biến thành truy xem ai merge PR gây lỗi. Lần sự cố kế tiếp, người biết chuyện chọn im lặng. Hai thất bại đó là hai nửa của cụm này: ứng cứu có quy trình và học từ sự cố mà không đổ lỗi.

Các phần nối với nhau thế nào

Đang tải diagram…

Trong cụm này

Phần	Trả lời câu hỏi
Ứng cứu sự cố	Khi nào declare? Triệu chứng nào nhìn gì trước? Vì sao mitigate trước root cause?
Debug theo giả thuyết	Debug có phương pháp ra sao? Dùng công cụ Node.js và PostgreSQL nào, có demo chạy thật?
Giao tiếp khi ứng cứu	Ai làm vai gì? Cập nhật stakeholder thế nào cho đủ thông tin?
Postmortem blameless	Viết postmortem thế nào để không đổ lỗi mà vẫn có trách nhiệm? Mẫu và ví dụ?
Lỗi hay gặp	Dev hay làm sai gì khi log, debug, ứng cứu và viết postmortem?

🎮 Thử tay

• Sự cố 3 giờ sáng: mitigate trước, root cause có bằng chứng, postmortem.
• Thứ tự ứng cứu: sắp xếp các bước từ lúc nhận page.

Tóm tắt quyết định

Tình huống	Mặc định nên làm	Vì sao
Có dấu hiệu sự cố, chưa chắc	Declare sớm, hạ mức sau nếu không nghiêm trọng	Huỷ một incident rẻ hơn ứng cứu hỗn loạn
Biết cách giảm thiệt hại, chưa biết nguyên nhân	Mitigate trước (rollback, tắt flag, drain), root cause sau	Mỗi phút điều tra là một phút người dùng còn chịu lỗi
Vừa có deploy hoặc đổi config	Nghi thay đổi gần nhất trước, rollback nếu rẻ	Thay đổi gần đây là nơi bắt đầu hiệu quả nhất
Nhiều người cùng xử lý	Một Incident Commander, chỉ nhóm Ops được thay đổi hệ thống	Tránh hai người sửa cùng lúc làm nhiễu kết quả
Debug	Một giả thuyết, một thay đổi, một lần đo	Đổi nhiều thứ cùng lúc thì không biết cái nào có tác dụng
Sự cố đã qua	Postmortem blameless có action item, owner, hạn chót	Không có action item thì postmortem chỉ là một văn bản

Tóm tắt

Tóm tắt

• Declare sớm, có một Incident Commander, chỉ nhóm Ops được thay đổi hệ thống.
• Mitigate trước (rollback, kill switch, drain, shed load), root cause sau; giữ bằng chứng nếu tốn dưới một phút.
• Debug theo vòng giả thuyết, đổi một thứ mỗi lần, bắt đầu từ “cái gì vừa thay đổi”.
• Event loop delay cho biết có chặn; CPU profile cho biết hàm nào; diagnostic report cho biết trạng thái process.
• Blameless là tìm điều kiện hệ thống, không phải bỏ trách nhiệm; action item cần owner, hạn và ticket.

Tiếp theo: Ứng cứu sự cố.