Ứng cứu sự cố: declare sớm, mitigate trước, root cause sau Trung cấp
Thời gian đọc ước tính: 5 phút
Trang này trả lời: khi alert kêu, làm gì trước, nhìn số liệu nào, và chọn cách giảm thiệt hại nào.
Vòng đời một sự cố
Phần tiêu đề “Vòng đời một sự cố”Đang tải diagram…
Ba điểm trong sơ đồ hay bị làm sai:
- Triage cần tiêu chí sẵn. SRE book coi một sự kiện là incident nếu có một trong ba điều: cần team thứ hai cùng xử lý; người dùng nhìn thấy lỗi; chưa giải quyết được sau một giờ tập trung phân tích.
- Mitigate và investigate là vòng lặp. Rollback xong mà SLI chưa về nghĩa là giả thuyết “do deploy” sai, quay lại điều tra.
- Resolve chưa phải kết thúc. Postmortem và action item mới là phần làm hệ thống tốt lên.
Phản ứng đầu tiên: triệu chứng → nhìn gì
Phần tiêu đề “Phản ứng đầu tiên: triệu chứng → nhìn gì”Dùng hai khung để không bỏ sót:
- Service → RED (Tom Wilkie): Rate, Errors, Duration.
- Tài nguyên → USE (Brendan Gregg): CPU, memory, connection pool, disk — “với mọi tài nguyên, kiểm tra utilization, saturation và errors”.
| Triệu chứng | Nhìn gì đầu tiên | Mitigate nhanh thường dùng |
|---|---|---|
| 5xx hoặc latency tăng ngay sau deploy | Diff của deploy, thời điểm lỗi bắt đầu so với rollout | Rollback |
| Latency tăng ở mọi endpoint, CPU cao | Event loop delay p99/max, rồi CPU profile | Rollback; tắt tính năng nặng bằng flag |
| Latency tăng, CPU thấp | Đang chờ I/O: pool.waitingCount, trace span DB/downstream, pg_stat_activity |
Giảm tải, tắt tính năng gọi downstream chậm |
| “timeout acquiring connection” từ pool | pg_stat_activity: nhiều idle in transaction, xact_start cũ |
pg_terminate_backend session treo (xem ghi chú dưới), rồi sửa code giữ transaction và đặt idle_in_transaction_session_timeout |
| Request ghi bị treo | pg_blocking_pids + pg_locks |
Huỷ transaction đang chặn, nếu chắc an toàn |
| Một endpoint chậm, còn lại bình thường | Slow query log / pg_stat_statements, rồi EXPLAIN (ANALYZE, BUFFERS) |
Tắt tính năng đó, thêm index sau khi review |
| Memory tăng dần, Pod bị OOMKilled | Đồ thị heap used theo thời gian, so sánh hai heap snapshot | Restart theo lịch để câu giờ, giới hạn kích thước payload |
| Lỗi chỉ ở một Pod / một zone | Breakdown metric theo instance | Drain instance hoặc zone đó |
| Consumer lag tăng | Lag theo partition | Scale consumer (trong giới hạn số partition) |
Ghi chú về session idle in transaction: pg_terminate_backend ngắt cả session và rollback transaction. pg_cancel_backend chỉ huỷ câu đang chạy, nên không gỡ được session đang idle.
Đi từ alert xuống request cụ thể:
- Drill-down alert → exemplar → trace → log.
- Correlation ID để nối log của một request qua nhiều service.
- Mức nghiêm trọng gắn với SLO và error budget, không phải cảm giác.
Mitigate trước, root cause sau
Phần tiêu đề “Mitigate trước, root cause sau”SRE book viết thẳng: phản xạ đầu tiên khi outage lớn là lao vào tìm root cause — “hãy bỏ qua bản năng đó”. Ưu tiên số một là dừng chảy máu: làm hệ thống chạy tốt nhất có thể trong hoàn cảnh hiện tại.
| Cách mitigate | Dùng khi | Giá phải trả |
|---|---|---|
| Rollback bản deploy | Lỗi bắt đầu cùng lúc với rollout | Mất tính năng mới; migration DB phải tương thích ngược (expand/contract) |
| Kill switch (feature flag) | Lỗi khoanh được vào một tính năng | Cần flag có sẵn từ trước; không áp dụng cho lỗi ở code dùng chung |
| Scale out | Saturation thật (CPU, worker) và downstream còn chịu được | Có thể dồn tải lên DB, làm sự cố lan rộng |
| Shed load / rate limit | Quá tải, cần giữ phần quan trọng sống | Một phần người dùng nhận 429/503 có chủ đích |
| Drain instance / zone | Lỗi khu trú ở một nơi | Phần còn lại phải gánh thêm tải |
Vì sao ưu tiên mitigate:
- Người dùng không quan tâm root cause. Họ chỉ thấy lỗi kéo dài bao lâu.
- Rollback là một thí nghiệm rẻ. SLI về bình thường thì bạn vừa thu hẹp nguyên nhân về bản deploy đó.
- Điều tra dưới áp lực tạo sai lầm mới. Hệ thống ổn định rồi mới đào sâu bình tĩnh được.
Trước khi rollback hay restart, giữ bằng chứng nếu tốn dưới một phút: lưu diagnostic report, chụp pg_stat_activity, ghi lại phiên bản đang chạy. Restart xoá sạch trạng thái bạn cần cho postmortem.
Khi nào áp dụng / ngoại lệ
Phần tiêu đề “Khi nào áp dụng / ngoại lệ”| Áp dụng đầy đủ | Rút gọn được |
|---|---|
| Sự cố người dùng thấy, mất dữ liệu, cần rollback hoặc can thiệp tay | Lỗi chỉ ở staging, không ảnh hưởng ai |
| Monitoring không phát hiện, người dùng báo trước | Sự cố nhỏ đã có postmortem cùng nguyên nhân: cập nhật postmortem cũ, đẩy action item |
| Near-miss suýt thành sự cố lớn | Team 2-3 người: một người kiêm IC và Ops, nhưng vẫn có incident doc và postmortem |
Ngoại lệ của “mitigate trước”: khi mitigate có thể làm mất dữ liệu — ví dụ restore backup đè lên dữ liệu mới, hoặc failover khi replica đang trễ. Lúc đó dừng lại, đánh giá, và để IC quyết định.
Checklist on-call
Phần tiêu đề “Checklist on-call”- Nhận alert → acknowledge trong thời gian cam kết, mở incident doc, ghi giờ UTC.
- Đối chiếu tiêu chí declare; nghi ngờ thì declare, chỉ định IC rõ ràng.
- Hỏi “cái gì vừa thay đổi?”: deploy, config, flag, traffic, dependency.
- Giữ bằng chứng trong dưới một phút (diagnostic report,
pg_stat_activity, version), rồi mitigate. - Mitigate bằng cách rẻ nhất có thể hoàn tác: rollback, kill switch, drain, shed load.
- Debug theo giả thuyết, một thay đổi một lần, ghi cả kết quả âm vào incident doc.
- Cập nhật stakeholder đều đặn, luôn ghi giờ cập nhật kế tiếp.
- Resolve khi SLI về bình thường; Planning liệt kê mọi thay đổi tạm cần hoàn tác; mở postmortem.
Tiếp theo: Debug theo giả thuyết.