Bài 20. Checklist vận hành Reverse Proxy thực tế

Khi xây dựng xong hệ thống, cũng dành thời gian để thực hiện checklist 1 vòng đã

1. Mục đích của checklist vận hành

Reverse Proxy chỉ thực sự “tốt” khi:

• Không chỉ cấu hình đúng lúc ban đầu,

• Mà còn được vận hành nhất quán, có kiểm soát trong suốt vòng đời hệ thống.

Trong thực tế, nhiều sự cố không xuất phát từ lỗi kỹ thuật phức tạp, mà từ:

• Quên một bước kiểm tra,

• Sửa cấu hình vội vàng,

• Thiếu quy trình khi có sự cố.

Checklist vận hành giúp:

• Giảm phụ thuộc cá nhân,

• Tránh thao tác thiếu sót trong tình huống áp lực,

• Chuẩn hóa cách làm cho cả đội.

2. Checklist kiểm tra hàng ngày (Daily)

2.1. Trạng thái dịch vụ

•  Nginx đang chạy:

   

  systemctl status nginx

•  Không có lỗi mới nghiêm trọng trong error.log.

2.2. Kiểm tra nhanh log truy cập

•  Không có đột biến 5xx:

  grep ' 5[0-9][0-9] ' /var/log/nginx/access.log | tail 

•  Không có IP truy cập bất thường lặp lại nhiều lần.

3. Checklist kiểm tra hàng tuần (Weekly)

3.1. HTTPS & chứng chỉ

•  Chứng chỉ còn hạn:

  certbot certificates

•  Không có lỗi renew trong log Certbot.

3.2. Dung lượng & tài nguyên

•  Dung lượng đĩa:

  df -h

•  RAM/CPU không bị sử dụng bất thường:

  htop

3.3. Log rotation

•  Logrotate chạy bình thường.

•  Không có file log phình to bất thường.

4. Checklist khi thay đổi cấu hình

4.1. Trước khi sửa

•  Xác định rõ mục tiêu thay đổi.

•  Biết file nào sẽ bị ảnh hưởng.

•  Có phương án rollback (file backup).

4.2. Sau khi sửa

•  Test cấu hình:

  nginx -t

•  Reload, không restart:

  systemctl reload nginx

5. Checklist khi thêm website / web app mới

•  Xác định đúng nhóm (website / webapp / ws).

•  Dùng đúng template chuẩn.

•  Không hard-code backend IP.

•  Có ACME challenge hoạt động.

•  Test HTTP → HTTPS redirect.

•  Test domain từ bên ngoài.

6. Checklist khi dùng Cloudflare

•  SSL mode: Full (strict).

•  Real IP Cloudflare đã cấu hình.

•  Domain nào dùng Cloudflare, domain nào không – có ghi chú rõ.

•  Có ít nhất 1 domain bypass (DNS only) để troubleshooting.

7. Checklist khi failover (QMS ↔ AI)

7.1. Trước khi failover

•  Xác minh QMS có sự cố thật.

•  Xác minh AI sẵn sàng.

7.2. Trong khi failover

•  Chỉ switch backend-active.conf.

•  nginx -t trước khi reload.

•  Reload, không restart.

7.3. Sau khi failover

•  Kiểm tra web app trọng điểm.

•  Theo dõi error log.

•  Ghi log sự kiện failover.

8. Checklist xử lý sự cố nhanh (Incident response)

Khi người dùng báo lỗi:

1.  Kiểm tra từ Reverse Proxy trước.

2.  Kiểm tra error.log.

3.  Kiểm tra response từ backend.

4.  Quyết định:

   • Lỗi backend → cân nhắc failover.

   • Lỗi proxy → rollback cấu hình gần nhất.

9. Checklist bảo mật định kỳ

•  SSH không cho đăng nhập root.

•  SSH dùng key, không dùng password.

•  Chỉ mở cổng cần thiết.

•  Không có site test/debug expose Internet.

10. Checklist diễn tập (khuyến nghị hàng tháng)

•  Diễn tập failover QMS → AI.

•  Diễn tập rollback AI → QMS.

•  Kiểm tra lại toàn bộ template và snippet.

11. Checklist bàn giao hệ thống

Khi bàn giao cho người khác:

•  Sơ đồ kiến trúc.

•  Danh sách domain & nhóm.

•  Vị trí file cấu hình quan trọng.

•  Quy trình failover.

•  Checklist vận hành.

Kết luận

Checklist vận hành Reverse Proxy giúp:

• Biến kiến trúc tốt thành hệ thống vận hành tốt.

• Giảm rủi ro do thao tác con người.

• Giữ hệ thống ổn định lâu dài dù số lượng website tăng.

Trong môi trường có hàng trăm website, web app và yêu cầu tính liên tục cao, checklist không phải là hình thức, mà là công cụ bảo hiểm rẻ và hiệu quả nhất cho toàn bộ hệ thống.