Checklist xử lí sự cố máy chủ Linux: Phục hồi sau thảm họa

Giới thiệu: Bình tĩnh trước thảm họa hệ thống

Một ngày đẹp trời, bạn nhận được cảnh báo liên tục trên Telegram hoặc điện thoại từ khách hàng: Website không thể truy cập, API phản hồi lỗi 502 Bad Gateway hoặc máy chủ hoàn toàn không thể kết nối qua SSH..

Trong khoảnh khắc áp lực cao đó, điều nguy hiểm nhất là hoảng loạn và gõ bừa bãi các lệnh xóa dữ liệu hoặc restart máy chủ Ubuntu mà chưa kịp ghi nhận nguyên nhân chính xác..

Bài viết này cung cấp một Qui trình phản ứng sự cố chuẩn mực (Incident Response Checklist) gồm 6 giai đoạn rõ ràng, giúp bạn từng bước chẩn đoán chính xác nguyên nhân gốc rễ (root cause) và khôi phục dịch vụ nhanh nhất có thể..

Giai đoạn 1: Đánh giá sơ bộ và giữ bình tĩnh (triage)

Trước khi thực hiện bất kì thao tác thay đổi nào:

1. Ghi lại mốc thời gian: Ghi nhận thời điểm nhận cảnh báo và thời điểm bắt đầu xử lí.
2. Kiểm tra kênh liên lạc: Thông báo cho các bên liên quan (Product Manager, Khách hàng) rằng đội ngũ kĩ thuật đã tiếp nhận sự cố và đang điều tra.
3. Mở tài liệu ghi chép sự cố (Incident Log): Ghi lại từng lệnh bạn chuẩn bị chạy và kết quả output tương ứng.

Giai đoạn 2: Chuẩn đoán nhanh tình trạng phần cứng (Quick healthcheck)

Nếu bạn vẫn có thể SSH vào máy chủ, hãy chạy ngay các lệnh kiểm tra 4 tài nguyên cốt lõi (USE Method - Utilization, Saturation, Errors):

1. Kiểm tra Tải CPU và Tiến trình (CPU Load)

uptime
# Xem Load Average 1m, 5m, 15m. Nếu Load Average > Số lượng nhân CPU thì máy chủ đang bị nghẽn CPU.

top -b -n 1 | head -n 20
# Xác định xem tiến trình nào đang chiếm 100% CPU.

2. Kiểm tra Bộ nhớ RAM & Swap (Memory Exhaustion)

free -h
# Xem dung lượng RAM trống và Swap trống.

Nếu available RAM gần bằng 0 và Swap bị sử dụng hết, máy chủ đang bị tràn RAM nghiêm trọng.

Kiểm tra xem hệ điều hành có vừa kích hoạt OOM Killer để tiêu diệt tiến trình của bạn không:

sudo dmesg -T | grep -i -E 'oom|out of memory|killed process'

3. Kiểm tra Dung lượng Ổ đĩa (Disk Space & Inodes)

df -h
# Kiểm tra xem có phân vùng nào đạt mức 100% không.

df -i
# Kiểm tra số lượng file (Inodes). Đôi khi dung lượng ổ cứng còn trống nhưng Inodes bị đầy 100% do hàng triệu file session/cache nhỏ.

4. Kiểm tra Kết nối Mạng và Cổng dịch vụ (Network & Ports)

# Kiểm tra các cổng đang lắng nghe và số lượng kết nối
sudo ss -tulpn

# Đếm số lượng kết nối đang mở theo từng IP
sudo ss -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 15

Giai đoạn 3: Phân tích Log Dịch vụ (Root Cause Analysis)

Tùy theo dịch vụ bị lỗi, hãy kiểm tra log tương ứng:

Đối với Nginx / Web Server:

sudo tail -n 100 /var/log/nginx/error.log

• Connection refused: Ứng dụng backend (Node.js/Python/Go) đã bị tắt hoặc đang chết.
• Connection timed out: Backend phản hồi quá chậm hoặc bị khóa cơ sở dữ liệu (Database Deadlock).

Đối với Dịch vụ Systemd (Node.js/Go/Python):

sudo journalctl -u my-app -n 100 --no-pager

Đối với Docker Containers:

docker ps -a
# Tìm container nào có trạng thái Exited (1) hoặc CrashLoopBackOff

docker logs --tail 100 <container_name>

Đối với Cơ sở dữ liệu PostgreSQL / MySQL:

# Kiểm tra dung lượng bảng và kết nối đang active
docker exec -it production_postgres psql -U pgadmin -d core_production -c "SELECT count(*) FROM pg_stat_activity;"

Giai đoạn 4: Kế hoạch Khôi phục dịch vụ (mitigation)

Tùy thuộc vào nguyên nhân đã xác định ở Giai đoạn 3:

Trường hợp A: Ổ đĩa bị đầy 100% (Disk Full)

# 1. Dọn dẹp cache gói phần mềm APT
sudo apt-get clean

# 2. Xóa các log journal cũ hơn 2 ngày
sudo journalctl --vacuum-time=2d

# 3. Dọn dẹp các Docker image và container rác
docker system prune -af

# 4. Tìm kiếm các file log khổng lồ (>500MB)
sudo find /var/log -type f -size +500M

Trường hợp B: Tiến trình bị treo hoặc tràn RAM (High Memory / CPU)

# Khởi động lại dịch vụ mượt mà
sudo systemctl restart my-app

# Hoặc khởi động lại Docker compose
docker compose restart

Trường hợp C: Bị tấn công DoS/DDoS từ một dải IP độc hại

# Chặn tức thời IP đang spam hàng chục nghìn kết nối
sudo ufw insert 1 deny from 203.0.113.50 to any

Giai đoạn 5: Dấu hiệu máy chủ bị xâm nhập (compromise / hacked)

Nếu bạn phát hiện các tiến trình lạ có tên ngẫu nhiên (dạng kdevtmpfsi, xmrig...) chiếm 100% CPU:

1. Kiểm tra Crontab của toàn bộ user:
   bash

   Sao chép

   for user in $(cut -f1 -d: /etc/passwd); do echo "=== $user ==="; crontab -u $user -l 2>/dev/null; done
   

2. Kiểm tra các file trong thư mục tạm /tmp và /dev/shm:
   bash

   Sao chép

   ls -la /tmp /var/tmp /dev/shm
   

3. Kiểm tra lịch sử đăng nhập SSH:
   bash

   Sao chép

   last -n 20
   sudo grep "Accepted" /var/log/auth.log
   

Giai đoạn 6: Đánh giá hậu sự cố (Post-Mortem Review)

Sau khi dịch vụ đã hoạt động ổn định trở lại, hãy tiến hành cuộc họp rút kinh nghiệm và trả lời 4 câu hỏi:

1. Chuyện gì đã xảy ra? (Mô tả chi tiết diễn biến sự cố).
2. Nguyên nhân gốc rễ là gì? (Do thiếu RAM, do câu lệnh SQL chậm, hay do file log không được xoay vòng?).
3. Tại sao hệ thống cảnh báo không phát hiện sớm hơn? (Cần bổ sung ngưỡng cảnh báo nào vào Uptime Kuma?).
4. Hành động khắc phục lâu dài (Action Items): Các việc cần làm để lỗi này KHÔNG BAO GIỜ lặp lại lần thứ hai.

Tổng kết

Sự cố hệ thống là điều không thể tránh khỏi trong quá trình vận hành phần mềm. Sự khác biệt giữa một đội ngũ nghiệp dư và chuyên nghiệp nằm ở sự chuẩn bị sẵn sàng, quy trình chuẩn đoán mạch lạc và các bước xử lý bình tĩnh, chính xác. Hãy lưu lại checklist này vào sổ tay kỹ thuật của bạn!