Sắp xếp: thứ tự ứng cứu sự cố Cơ bản
Thời gian đọc ước tính: 1 phút
Lúc sự cố, ai cũng biết phải rollback, báo cáo và viết postmortem. Cái hay sai là thứ tự: điều tra trước khi mitigate, restart trước khi lưu bằng chứng, hay báo “đã fix” trước khi đo SLI.
Sắp xếp 8 bước dưới đây. Bấm Kiểm tra để biết bước nào sai chỗ và sai thì hỏng gì.
Thứ tự ứng cứu: từ lúc pager kêu tới action item
20:07 UTC, alert burn rate SLO checkout kêu. Lỗi 5xx tăng, p99 lên 4 giây; 40 phút trước có deploy api v3.14 (không kèm migration).
Sắp xếp 8 việc dưới đây theo đúng thứ tự một on-call nên làm.
Dùng ▲▼ để đổi chỗ từng bước, hoặc chạm ⠿ của một bước rồi chạm vào vị trí mới. Trên máy tính có thể kéo thả.
- Ack alert, mở incident doc, declare SEV và chỉ định IC
ghi giờ UTC; đủ người thì tách vai Ops, Comms - Gửi status update đầu tiên: ảnh hưởng, đang làm gì, giờ cập nhật kế tiếp
- Mitigate bằng cách rẻ nhất có thể hoàn tác: rollback v3.14 → v3.13
- Postmortem blameless, mỗi action item một owner, hạn và ticket
- Giữ bằng chứng trong dưới một phút
snapshot pg_stat_activity + pg_blocking_pids, diagnostic report, version đang chạy - Xác nhận hồi phục bằng SLI, theo dõi thêm 15 phút rồi mới resolve
- Đánh giá tác động và hỏi "cái gì vừa thay đổi?"
SLI nào, bao nhiêu % request, từ lúc nào; deploy, config, flag, traffic - Tìm root cause từ bằng chứng đã lưu, theo giả thuyết
Vòng đời đầy đủ và các ngoại lệ của “mitigate trước”: Ứng cứu sự cố.