Bài 22: Quy trình troubleshooting production
Bài này chi tiết hóa troubleshooting production theo hướng dễ hiểu, có lệnh thực hành, tình huống production, checklist và bài tập.
- Hiểu troubleshooting production dùng để giải quyết vấn đề gì trong production.
- Nắm các lệnh/cấu hình quan trọng.
- Biết quy trình thực hành từng bước trong lab.
- Có checklist kiểm tra trước khi áp dụng production.
Chốt ý nhanh
| Chủ đề | Điểm cần nhớ |
|---|---|
| Troubleshooting | Không phải đoán mò; phải đi theo trình tự và loại trừ từng lớp. |
| Mục tiêu | Khôi phục dịch vụ an toàn trước, rồi mới đào sâu nguyên nhân gốc. |
| Kỷ luật | Ghi lại giả thuyết, bằng chứng và thay đổi đã thử để tránh làm tình hình rối thêm. |
1. Bối cảnh thực tế
Troubleshooting production không phải kiến thức lý thuyết riêng lẻ. Trong vận hành production, nó giúp giảm downtime, giảm rủi ro bảo mật và giúp hệ thống dễ khôi phục hơn khi có sự cố.
2. Các khái niệm cần nắm
- Trạng thái hiện tại: trước khi sửa phải biết hệ thống đang chạy thế nào.
- Thay đổi nhỏ: thay đổi từng bước để dễ rollback.
- Log/metric: dùng để xác nhận thay đổi đúng hay sai.
- Rollback: luôn có đường quay lại khi cấu hình lỗi.
3. Lab thực hành
date hostname uptime free -h df -h systemctl --failed ss -tulpn journalctl -p err --since "30 minutes ago" curl -I https://example.com
Khi thực hành, anh nên ghi lại output trước và sau. Đây là thói quen rất quan trọng của SysAdmin/DevOps.
4. Tình huống thực tế
Website báo 502 sau deploy. Anh không restart bừa mà kiểm tra theo lớp: HTTP status, Nginx log, backend service, port, deploy gần nhất, tài nguyên và rollback nếu cần.
5. Quy trình triển khai an toàn
- Xác định mục tiêu thay đổi.
- Backup file cấu hình hoặc tạo snapshot nếu thay đổi rủi ro.
- Kiểm tra trạng thái hiện tại bằng lệnh phù hợp.
- Thay đổi trên lab/staging trước nếu có.
- Áp dụng production trong khung giờ phù hợp.
- Kiểm tra log, service, port, endpoint sau thay đổi.
- Ghi lại thay đổi và phương án rollback.
6. Lỗi thường gặp
- Làm trực tiếp production mà không backup.
- Sửa nhiều thứ cùng lúc nên không biết lỗi do đâu.
- Không đọc log sau khi reload/restart service.
- Không ghi lại command đã chạy.
7. Checklist
- Đã kiểm tra trạng thái hiện tại.
- Đã backup cấu hình/dữ liệu liên quan.
- Đã test syntax/config nếu có.
- Đã xác nhận service hoạt động sau thay đổi.
- Đã ghi lại thay đổi vào tài liệu vận hành.
8. Bài tập
- Dựng lab nhỏ cho chủ đề này.
- Chạy toàn bộ lệnh kiểm tra.
- Tạo một lỗi nhỏ có kiểm soát và sửa lại.
- Viết checklist 5 bước dùng cho production.
Phần thực hành mở rộng: troubleshooting production theo một khung có thể lặp lại
Khả năng xử lý sự cố không đến từ nhớ thật nhiều lệnh, mà từ việc giữ đầu lạnh và đi đúng thứ tự. Bài này nên biến quy trình xử lý lỗi thành thói quen, không để người học nhảy cóc giữa các giả thuyết.
Lab 1: Dùng khung 5 câu hỏi trước khi chạm vào hệ thống
- cái gì đang hỏng?
- ảnh hưởng tới ai, phạm vi nào?
- bắt đầu từ khi nào?
- có thay đổi nào vừa diễn ra không?
- ưu tiên khôi phục nhanh hay điều tra sâu ngay?
Đây là phần “thực hành bằng tư duy”, nhưng cực kỳ thực tế vì nó định hướng toàn bộ bước sau.
Lab 2: Checklist chẩn đoán nhanh cho web service
uptime
free -h
df -h
systemctl --failed
ss -tulpn | head -30
curl -I http://127.0.0.1
curl -I https://example.com
journalctl -p err --since "1 hour ago" --no-pagerĐây là bộ lệnh đủ tốt để chụp nhanh sức khỏe máy trước khi đào sâu từng service.
Lab 3: Mô phỏng sự cố 502 và lần theo từng lớp
- kiểm tra Nginx có up không
- kiểm tra backend app có chạy không
- kiểm tra port backend có listen không
- kiểm tra log lỗi của Nginx và app
systemctl status nginx
ss -tulpn | grep 3000
curl -I http://127.0.0.1:3000
sudo tail -50 /var/log/nginx/error.logLab 4: Viết timeline sự cố ngắn
Sau mỗi lần lab, tự ghi:
- triệu chứng ban đầu
- giả thuyết đầu tiên
- bằng chứng xác nhận/bác bỏ
- hành động khôi phục
- bài học phòng ngừa
Thói quen này biến kinh nghiệm ngắn hạn thành runbook dùng lại được.
Lab 5: Phân biệt “khắc phục tạm” và “root cause fix”
Ví dụ:
- restart app để dịch vụ lên lại là khắc phục tạm
- sửa memory leak, query lỗi hoặc config sai mới là xử lý nguyên nhân gốc
Production cần cả hai, nhưng phải biết mình đang làm loại nào.
Tình huống thực tế
Khi website down, áp lực lớn nhất thường không phải kỹ thuật mà là sự hỗn loạn: nhiều người hỏi cùng lúc, nhiều giả thuyết chồng chéo và ai cũng muốn sửa thật nhanh. Một quy trình troubleshooting tốt giúp anh giữ hệ thống và cả đầu óc ở trạng thái có kiểm soát.
Lỗi phổ biến
- Restart liên tục mà không ghi nhận bằng chứng.
- Sửa nhiều thứ cùng lúc khiến mất dấu nguyên nhân.
- Chỉ nhìn symptom bề mặt, không xác định phạm vi ảnh hưởng.
- Khôi phục xong rồi bỏ qua bước ghi lại bài học.
Kết bài
Nếu bài này chắc, anh sẽ có một khung xử lý sự cố đủ trưởng thành để bước vào production thật mà không hoảng loạn quá nhanh. Sau đó, bài High Availability sẽ mở rộng câu chuyện: làm sao giảm khả năng một lỗi đơn lẻ kéo sập cả dịch vụ.
