Cronbell & Dead Man's Switch: Giám Sát Background Job Và Chặn Đứng Lỗi Thầm Lặng

Trong mọi hệ thống vận hành, các tác vụ chạy ngầm định kỳ (Cronjob, Scheduled Tasks) đóng vai trò sống còn: Sao lưu dữ liệu database lúc nửa đêm, xuất hóa đơn điện tử hàng tháng, đồng bộ dữ liệu kho hàng, hay dọn dẹp các session rác.

Thảm họa lớn nhất của Cronjob là: Nó âm thầm thất bại (Silent Failure) mà không ai hay biết! Cho đến một ngày server hỏng, bạn mở kho backup ra mới tá hỏa phát hiện script backup đã chết từ 6 tháng trước vì lỗi hết dung lượng đĩa!

---

1. Nguyên lý Dead Man's Switch (Công Tắc Người Chết)

Thông thường, hệ thống giám sát hoạt động theo cơ chế Chủ động thăm dò (Active Probing): Prometheus hoặc Uptime Robot ping vào server xem server có sống không.
Nhưng với một Cronjob chỉ chạy 5 phút một lần hoặc 1 lần mỗi tuần, Active Probing hoàn toàn vô dụng!

Cơ chế Dead Man's Switch:

1. Bạn tạo một kênh giám sát trên dịch vụ theo dõi (như Cronbell hoặc Healthchecks.io) với chu kỳ quy định: Ví dụ 1 giờ chạy 1 lần.
2. Ở cuối script cronjob, bạn thêm một lệnh gửi tín hiệu "nhịp tim" (Heartbeat Ping) về hệ thống giám sát.
3. Nếu quá 1 giờ mà hệ thống KHÔNG NHẬN ĐƯỢC NHỊP TIM (do script bị crash, server treo, cron daemon bị tắt, timeout):
   ➔ Hệ thống lập tức gửi chuông báo động khẩn cấp tới Telegram, Slack, PagerDuty cho đội ngũ trực chiến!

[Cronjob chạy trên Server]
       │
       ├─ Bắt đầu chạy backup...
       ├─ Nén dữ liệu database...
       ├─ Tải file lên Amazon S3...
       │
       ▼ (Nếu thành công)
Gửi HTTP GET Ping tới Cronbell:
https://api.cronbell.com/ping/abc-123-xyz
       │
       ▼
[Cronbell Dashboard: Reset đồng hồ đếm ngược]
(Nếu sau 65 phút không thấy Ping ➔ BẮN ALERT TELEGRAM NGAY!)

---

2. Cách bọc Cronjob an toàn tuyệt đối với Bash Trap

Rất nhiều kỹ sư viết lệnh cronjob như sau:

# CÁCH VIẾT SAI NGUY HIỂM:
0 2 * * * /scripts/backup.sh && curl -fsS https://api.cronbell.com/ping/TOKEN

Nếu lệnh backup bị lỗi ở giữa chừng, lệnh curl sẽ không chạy, nhưng bạn sẽ không biết lỗi tại sao và mã lỗi là gì!

Cách viết chuẩn Production với Bash Trap:

#!/usr/bin/env bash
set -Eeuo pipefail

PING_URL="https://api.cronbell.com/ping/YOUR_TOKEN"

# 1. Báo hiệu bắt đầu chạy (để đo thời gian thực thi)
curl -fsS --retry 3 "${PING_URL}/start" || true

# 2. Đặt bẫy bắt lỗi nếu script thất bại ở bất kỳ dòng nào
cleanup_on_error() {
    local exit_code=$?
    echo "[ERROR] Job failed with exit code: ${exit_code}"
    # Báo ngay cho Cronbell biết job đã thất bại kèm mã lỗi
    curl -fsS --retry 3 --data "Exit code: ${exit_code}" "${PING_URL}/fail" || true
    exit "${exit_code}"
}
trap cleanup_on_error ERR

# --- NỘI DUNG TÁC VỤ CHÍNH ---
echo "Starting database dump..."
pg_dump -U postgres mydatabase > /backup/db.sql
gzip -f /backup/db.sql
aws s3 cp /backup/db.sql.gz s3://my-backup-bucket/

# 3. Báo hiệu hoàn thành mỹ mãn
curl -fsS --retry 3 "${PING_URL}"
echo "Job finished successfully!"

---

3. Checklist bảo vệ Cronjob không thể bỏ qua

1. Luôn đo thời gian chạy (Execution Duration): Nếu một tác vụ thường ngày chỉ chạy mất 2 phút, bỗng dưng hôm nay chạy mất 45 phút, đó là dấu hiệu của Database lock hoặc nghẽn mạng.
2. Không ghi đè file backup: Luôn thêm timestamp vào tên file backup (db_$(date +%Y%m%d_%H%M%S).sql.gz).
3. Định kỳ thực hành phục hồi (Drill Test): Một bản sao lưu chưa từng được thử khôi phục thành công là một bản sao lưu vô giá trị!