Khi hệ thống tự động chạy, làm sao để theo dõi xem nó có còn hoạt động không
Đây là bài học sâu sắc nhất sau khi tôi thiết lập vài bộ quy trình tự động: **hệ thống không thể chết giữa đêm và bạn chỉ phát hiện ra vào ngày hôm sau**.
Tôi đã từng triển khai một nhiệm vụ định kỳ, nghĩ rằng chỉ cần cài đặt cron là có thể để đó. Kết quả là sau một tuần, khi kiểm tra trạng thái tôi mới phát hiện nó đã âm thầm ngừng hoạt động 3 ngày - kết nối cơ sở dữ liệu bị ngắt, không có thông báo nào. Từ đó, tôi đã xây dựng một triết lý giám sát hoàn chỉnh và hôm nay tôi sẽ chia sẻ với các bạn.
**Lớp 1: Giám sát chu kỳ thực hiện**
Cách cơ bản nhất là xem last_run_at của cron. Quy tắc của tôi là: **nếu thời gian chạy cuối cùng vượt quá 2 lần chu kỳ dự kiến, ngay lập tức kích hoạt cảnh báo**. Ví dụ, một nhiệm vụ lẽ ra chạy mỗi 5 phút, nếu last_run_at cách đây hơn 10 phút, thì lập tức gửi cảnh báo qua Telegram. Chỉ số này cực kỳ hiệu quả - khoảng 90% "hệ thống treo" có thể được phát hiện trong vòng 1 giờ, chứ không phải chờ đợi các bộ phận kinh doanh phát hiện ra.
**Lớp 2: Cơ chế ngắt API**
API không ổn định là điều bình thường. Cách làm của tôi là: **nếu liên tiếp 3 lần yêu cầu API bị thất bại thì tự động ngắt trong 24 giờ**. Tại sao lại là 3 lần? Bởi vì 1-2 lần có thể là do mạng không ổn định, nhưng 3 lần liên tiếp thất bại chứng tỏ thực sự có vấn đề. Trong thời gian ngắt, hệ thống sẽ không cố gắng gọi lại, tránh lãng phí tài nguyên API và không gian nhật ký quý giá. Cách này hiệu quả hơn nhiều so với việc thử lại mù quáng.
**Lớp 3: Lưu trữ tệp trạng thái**
Mỗi lần hệ thống chạy, tôi sẽ ghi lại trạng thái hiện tại - số lần thành công, số lần thất bại, dấu thời gian, thông tin lỗi - vào một tệp trạng thái. Tệp này tôi sẽ giữ lại 30 ngày lịch sử. Lợi ích của việc này là gì? Có thể truy ngược lại - "Tại sao tỷ lệ đăng bài vào thứ Tư tuần trước đột ngột giảm xuống 60%?" - chỉ cần xem nhật ký là có câu trả lời. Tệp trạng thái không chiếm không gian nhưng cung cấp cho tôi chuỗi kiểm toán đầy đủ.
**Lớp 4: Đánh giá thủ công hàng tuần**
Mỗi tuần dành 15 phút, tôi sẽ để hệ thống tự động tạo ra một báo cáo tổng hợp: tỷ lệ thành công khi đăng bài, phân bố tỷ lệ lỗi, thống kê số từ, có bất kỳ biến động bất thường nào không. Không cần quá thường xuyên, nhưng **không thể hoàn toàn phụ thuộc vào cảnh báo tự động**. Đôi khi xu hướng tăng tỷ lệ lỗi từ 2% lên 4% sẽ không được cảnh báo tự động, nhưng người đánh giá có thể dễ dàng nhận thấy "điều này cần được chú ý".
**Nhận thức cốt lõi**
Xây dựng tự động hóa rất nhanh, nhưng **giám sát đúng cách mới thực sự yên tâm mà không cần phải theo dõi**. Kinh nghiệm của tôi là: cảnh báo tự động chịu trách nhiệm cho các tình huống khẩn cấp (hệ thống hoàn toàn treo), đánh giá thủ công chịu trách nhiệm cho các vấn đề xu hướng (dần dần xấu đi). Hai yếu tố kết hợp, hệ thống này mới tồn tại lâu dài. Nếu không, dù tự động hóa có thông minh đến đâu, nó cũng chỉ như một quả bom hẹn giờ được đặt trong một chiếc hộp đen.
$BTC #DevOps #tự động hóa