Vào mỗi sáng thứ Hai, rất nhiều bạn kỹ thuật viên có thói quen mở trang quản trị VPS, chụp vội 4–5 tấm ảnh màn hình biểu đồ CPU, RAM và dung lượng đĩa rồi gửi vào nhóm chat kèm một câu ngắn ngủn: "Hệ thống tuần qua chạy ổn định nhé anh chị".
Cách làm này diễn ra tuần này qua tuần khác cho đến khi một sự cố ập đến: khách hàng gọi điện báo website bị sập suốt đêm Chủ Nhật vì ổ đĩa đầy, hoặc một câu truy vấn chậm khiến website bị đơ vào đúng đợt sale. Mở lại đống ảnh chụp biểu đồ tuần trước, chẳng ai nhận ra bất kỳ dấu hiệu cảnh báo nào.
Một báo cáo vận hành tuần thực tế không phải là nơi lưu trữ ảnh chụp màn hình biểu đồ để đối phó. Người quản lý hoặc chủ doanh nghiệp khi đọc báo cáo chỉ cần biết 3 câu trả lời rõ ràng:
- Tuần qua website có thực sự phục vụ khách hàng thông suốt không?
- Có rủi ro ngầm nào đang lớn dần cần chuẩn bị tiền hoặc tài nguyên để nâng cấp không?
- Tuần này ai phải làm việc gì để hệ thống an toàn hơn?
Nếu một bản báo cáo không giúp bạn đưa ra được quyết định nào cho tuần tiếp theo, bản báo cáo đó hoàn toàn vô giá trị.
5 phần cốt lõi của một báo cáo vận hành hàng tuần
Để bản báo cáo súc tích và có giá trị hành động, bạn nên chia cấu trúc làm 5 phần ngắn gọn:
1. Tóm tắt điều hành (Executive Summary)
Đây là phần dành riêng cho người quản lý chỉ có 1–2 phút để lướt qua. Hãy tóm gọn tình hình bằng 1 câu kết luận rõ ràng:
- Hệ thống Xanh (Ổn định): Không có sự cố gián đoạn nào, các chỉ số đều nằm trong ngưỡng an toàn.
- Hệ thống Vàng (Cần lưu ý): Website vẫn chạy nhưng có xu hướng tiêu hao tài nguyên nhanh (ví dụ: ổ cứng tăng nhanh đột biến hoặc có 1 đợt lỗi ngắn sau khi deploy).
- Hệ thống Đỏ (Nguy cấp): Đã xảy ra sự cố ảnh hưởng đến đơn hàng của khách, cần họp bàn giải pháp dứt điểm.
Kèm theo câu kết luận là tóm tắt ngắn về tác động tới người dùng (nếu có): "Website hoạt động ổn định 99.8%. Có 1 lần gián đoạn 8 phút vào tối thứ Tư do lỗi cập nhật phiên bản, đã rollback thành công và không mất dữ liệu."
2. Sức khỏe trải nghiệm người dùng (Availability & Performance)
Thay vì báo cáo máy chủ bật bao nhiêu giờ, hãy báo cáo những chỉ số gắn liền với khách hàng:
- Độ sẵn sàng bên ngoài (Uptime %): Được đo từ công cụ giám sát độc lập bên ngoài Internet, không lấy từ thời gian bật nguồn của VPS (xem bài Uptime monitoring: Kiểm tra HTTP 200 hay nội dung trang?).
- Thời gian phản hồi trang (Latency): Thời gian tải trang trung bình và phân vị P95 (95% khách hàng mở web dưới bao nhiêu giây).
- Tỷ lệ lỗi (Error Rate): Tổng số lượt gặp lỗi 5xx trong tuần là bao nhiêu, chiếm bao nhiêu % tổng lượng truy cập.
3. Nhật ký sự cố và các thay đổi trong tuần
Bất kỳ sự cố nào dù nhỏ cũng cần được ghi nhận lại để rút kinh nghiệm:
- Sự cố phát sinh: Thời gian xảy ra, nguyên nhân sơ bộ, ai đã xử lý và xử lý bằng cách nào. Nếu sự cố kéo dài trên 15 phút, cần dẫn đường link tới biên bản hậu sự cố chi tiết (tham khảo bài Biên bản hậu sự cố (Postmortem) cho doanh nghiệp nhỏ).
- Các đợt cập nhật (Changes/Deployments): Trong tuần có đợt cập nhật mã nguồn nào lớn không, có chạy migration database không, hay có thay đổi cấu hình Nginx/Cloudflare nào không.
4. Dự báo tài nguyên và điểm nghẽn (Capacity & Resource Trend)
Đừng chỉ nhìn con số của ngày hôm nay. Hãy so sánh với tuần trước để thấy tốc độ tiêu hao:
- Dung lượng Ổ đĩa: Hiện tại còn trống bao nhiêu GB? Quan trọng hơn: tuần qua dữ liệu tăng thêm bao nhiêu GB và dự kiến bao nhiêu tuần nữa thì ổ cứng sẽ chạm mức báo động 85%?
- Bộ nhớ RAM và CPU: Mức sử dụng cao điểm (Peak) trong tuần là bao nhiêu %? Có đợt nào Swap bị lôi ra đọc ghi liên tục hay OOM Killer bị kích hoạt không?
- Cơ sở dữ liệu: Số lượng kết nối tối đa trong tuần chạm mốc bao nhiêu, có câu truy vấn chậm (Slow Query) nào mới xuất hiện sau đợt cập nhật tính năng không? (xem thêm bài Monitoring Database: Những chỉ số quan trọng nhất).
Quy tắc đặt các mốc cảnh báo theo dõi tài nguyên được phân tích chi tiết tại bài Ngưỡng cảnh báo CPU, RAM và Disk cho VPS.
5. Tình trạng Sao lưu (Backup) và Bảo mật
Một dòng xác nhận ngắn nhưng cực kỳ quan trọng:
- Tình trạng backup: Trong 7 ngày qua có đủ 7 bản sao lưu không? Có bản nào bị lỗi hoặc tụt dung lượng bất thường không? Bản backup đã được đẩy lên dịch vụ lưu trữ đám mây an toàn chưa?
- Lần thử khôi phục gần nhất: Ngày gần nhất đội ngũ thực sự lấy file backup ra giải nén thử nghiệm trên môi trường test là ngày nào? (nhắc nhở định kỳ theo bài Chiến lược backup VPS cho doanh nghiệp nhỏ).
- Thời hạn chứng chỉ SSL và Tên miền: Còn bao nhiêu ngày nữa thì hết hạn, có cần gia hạn trong tháng tới không?
Mẫu báo cáo vận hành tuần thực tế (Mẫu 1 trang A4)
Dưới đây là một bảng mẫu rút gọn, dễ đọc mà bạn có thể áp dụng ngay vào bảng tính Google Sheets hoặc gửi trực tiếp qua email nội bộ:
BÁO CÁO VẬN HÀNH HỆ THỐNG - TUẦN 42 (05/10 - 11/10/2026)
Hệ thống: Website Bán Hàng Chính (VPS Production)
Người phụ trách: Nguyễn Văn A (Đội Vận hành)
1. TỔNG QUAN ĐIỀU HÀNH: [TRẠNG THÁI: VÀNG - CẦN LƯU Ý]
- Website hoạt động 99.7%. Có 1 sự cố lỗi 502 trong 12 phút vào tối 08/10 sau đợt deploy.
- Cảnh báo: Tốc độ tăng ổ đĩa nhanh bất thường, dự kiến đầy trong 3 tuần tới nếu không dọn log.
2. CHỈ SỐ HOẠT ĐỘNG CHÍNH:
• Uptime bên ngoài: 99.7% (Đạt mục tiêu > 99.5%)
• Tốc độ tải trang P95: 1.4 giây (Ổn định, tuần trước 1.3s)
• Tỷ lệ lỗi 5xx: 0.08% tổng truy cập
• Ổ cứng khả dụng: Còn 6.5 GB / 50 GB (Đã dùng 87% - Tăng thêm 2.1 GB so với tuần trước)
• RAM khả dụng (MemAvailable): Duy trì ở mức 35% - Không bị kích hoạt Swap
3. SỰ CỐ & THAY ĐỔI TRONG TUẦN:
• Ngày 08/10 (21:15 - 21:27): Lỗi 502 sau khi deploy bản v2.4. Nguyên nhân do thiếu biến môi trường mới trong file .env. Đã bổ sung biến và khởi động lại container thành công.
• Hành động sau sự cố: Bổ sung checklist kiểm tra file .env trước khi bấm deploy (Hoàn thành).
4. SAO LƯU & BẢO MẬT:
• Backup hàng ngày: 7/7 bản sao lưu thành công và đã đồng bộ lên Cloud Storage.
• Thử khôi phục gần nhất: Ngày 28/09 (Thành công).
• Chứng chỉ SSL: Còn hạn 65 ngày.
• Tên miền chính: Còn hạn 140 ngày.
5. VIỆC CẦN XỬ LÝ TRONG TUẦN TỚI (ACTION ITEMS):
[ ] Việc 1: Kiểm tra và cấu hình xoay vòng log Nginx để giải phóng 4 GB ổ đĩa (Phụ trách: Nam - Hạn: Thứ Tư 14/10).
[ ] Việc 2: Tối ưu 2 câu slow query trong trang danh mục sản phẩm (Phụ trách: Tuấn - Hạn: Thứ Sáu 16/10).3 sai lầm khiến báo cáo tuần trở thành gánh nặng vô ích
- Dùng con số trung bình để che giấu sự cố: Nếu bạn báo cáo "Thời gian tải trang trung bình là 300 ms", con số đó trông rất đẹp nhưng hoàn toàn có thể che giấu sự thật là 10% khách hàng đang phải chờ tới 8 giây để tải giỏ hàng. Hãy luôn báo cáo phân vị P95 hoặc P99.
- Không theo dõi việc đã hứa từ tuần trước: Nếu tuần trước bạn ghi "Ổ đĩa sắp đầy, cần dọn dẹp" nhưng sang tuần này ổ đĩa vẫn tiếp tục tăng và không có ai nhận việc, báo cáo đã mất đi tính cam kết. Mục Action Items bắt buộc phải có tên người chịu trách nhiệm và ngày hoàn thành cụ thể.
- Thay đổi cấu trúc báo cáo liên tục: Mỗi tuần đổi một định dạng hoặc chọn các chỉ số khác nhau sẽ làm mất khả năng so sánh xu hướng dài hạn. Hãy giữ một khung chỉ số cố định trong ít nhất 3 đến 6 tháng.
Checklist chuẩn bị trước khi gửi báo cáo tuần
- ☐ Chỉ số Uptime và thời gian phản hồi được lấy từ công cụ kiểm tra bên ngoài độc lập.
- ☐ Báo cáo có dòng kết luận trạng thái tổng quan rõ ràng (Xanh/Vàng/Đỏ) kèm lý do cụ thể.
- ☐ Các sự cố trong tuần đều được tóm tắt mốc thời gian, nguyên nhân và bài học khắc phục.
- ☐ Dung lượng ổ đĩa có kèm số liệu tăng trưởng so với tuần trước và thời gian dự kiến còn lại.
- ☐ Đã xác nhận trạng thái của các bản backup hàng ngày và ngày thử khôi phục gần nhất.
- ☐ Danh sách việc cần làm (Action Items) có ghi rõ người chịu trách nhiệm và hạn hoàn thành dứt điểm.
- ☐ Báo cáo được gửi đúng lịch cố định (ví dụ: trước 10h sáng thứ Hai hàng tuần). Để lựa chọn các số liệu theo dõi phù hợp đưa vào báo cáo mà không tốn công thu thập thủ công, hãy tham khảo bài trụ cột Nên monitoring những gì trên một VPS chạy website?.
