Bài 31: Incident response cho SysAdmin

Chốt ý nhanh

Chủ đề	Điểm cần nhớ
Incident response	Là cách đội vận hành phản ứng có tổ chức khi sự cố xảy ra.
Mục tiêu đầu tiên	Giảm ảnh hưởng và khôi phục dịch vụ an toàn, không phải chứng minh ai đúng ai sai.
Kỷ luật	Phải có vai trò, có timeline, có cập nhật trạng thái và có ghi nhận quyết định đã làm.

Phần thực hành mở rộng: incident response như một quy trình phối hợp con người và hệ thống

Nhiều bài troubleshooting chỉ tập trung kỹ thuật. Nhưng incident response ngoài đời còn là việc phối hợp: ai làm gì, báo cho ai, khi nào escalte và khi nào chuyển từ chữa cháy sang điều tra nguyên nhân gốc.

Lab 1: Phân loại mức độ sự cố

P1: dịch vụ chính down diện rộng
P2: lỗi nặng nhưng có workaround
P3: ảnh hưởng giới hạn hoặc không khẩn cấp

Không cần bộ tiêu chuẩn hoàn hảo từ đầu, nhưng phải có cách phân mức để tránh phản ứng cảm tính.

Lab 2: Viết timeline sự cố ngắn

18:00 - Alert website 5xx tăng cao
18:03 - On-call xác nhận lỗi thật
18:07 - Kiểm tra Nginx/backend
18:12 - Restart backend, dịch vụ hồi phục
18:25 - Mở điều tra root cause

Tập ghi timeline ngắn gọn, theo phút, là thói quen rất đáng giá cho postmortem sau này.

Lab 3: Xác định vai trò trong một incident nhỏ

incident commander
người trực tiếp xử lý kỹ thuật
người cập nhật trạng thái cho stakeholder

Khi một người phải ôm hết mọi vai trò, hệ thống rất dễ rối.

Lab 4: Viết status update 3 dòng

Mẫu tối thiểu:

sự cố gì đang xảy ra
phạm vi ảnh hưởng
đội đang làm gì tiếp theo

Đây là kỹ năng mềm nhưng cực kỳ thực chiến trong production.

Lab 5: Phân biệt mitigation và root cause fix

mitigation: rollback, restart, tắt tính năng lỗi
root cause fix: sửa code, sửa config, tăng capacity, thêm guardrail

Nếu lẫn hai thứ này, đội rất dễ báo “đã xử lý xong” trong khi vấn đề thật chỉ đang tạm lắng.

Tình huống thực tế

Một alert 5xx tăng cao không chỉ là lỗi web. Nó còn là lúc nhiều người cùng nhảy vào, nhiều giả thuyết chồng nhau và áp lực từ người dùng hoặc sếp tăng lên. Incident response tốt giúp cả hệ thống kỹ thuật lẫn đội ngũ bớt hỗn loạn.

Lỗi phổ biến

Không có một người điều phối chính.
Cập nhật nội bộ và bên ngoài mâu thuẫn nhau.
Sửa nhiều thứ cùng lúc nhưng không ghi lại.
Khôi phục xong rồi bỏ qua postmortem/hành động phòng ngừa.

Kết bài

Sau bài này, anh sẽ thấy incident response không chỉ là “fix lỗi thật nhanh”, mà là năng lực giữ hệ thống và con người trong trạng thái có tổ chức khi có sự cố. Sang bài capacity planning, góc nhìn sẽ chuyển từ phản ứng sang chủ động: làm sao thấy trước giới hạn tài nguyên trước khi nó thành incident.