Mục lục
API của bạn sập lúc 3 giờ sáng không phải là vấn đề. Vấn đề là 9 giờ sáng bạn mới biết, khi người dùng đã làm ngập hộp thư hỗ trợ.
Phần lớn công cụ giám sát rất giỏi phát hiện sự cố. Nhưng chúng lại rất tệ trong việc bảo đảm có ai đó thực sự nhìn thấy cảnh báo đúng lúc. Một thông báo đẩy thông thường nằm im trên màn hình khóa cho tới khi tình cờ có người cầm điện thoại lên. Một tin nhắn Slack bị chôn trong kênh chẳng ai theo dõi ban đêm. Một email nằm chưa đọc tới sáng thứ Hai.
Cảnh báo bằng cuộc gọi thay đổi phương trình đó. Khi bài kiểm tra sức khỏe API thất bại, điện thoại bạn thực sự đổ chuông — y như cách nó reo cho bất kỳ việc gấp nào khác. Bạn nghe máy, biết chuyện gì đang xảy ra, và bắt tay sửa ngay thay vì vài tiếng sau.
Vì sao thông báo đẩy thất bại với dịch vụ trọng yếu
Một chiếc smartphone trung bình nhận 50 đến 100 thông báo đẩy mỗi ngày. Cảnh báo lỗi API của bạn đang phải cạnh tranh với cập nhật ứng dụng, thông báo mạng xã hội, tin tức và mọi ứng dụng khác trên máy. Khi mọi thứ đều khẩn thì chẳng cái nào có vẻ khẩn cả.
Điều đó tạo ra một chuỗi nguy hiểm:
- Công cụ giám sát phát hiện API trả về lỗi 500
- Nó gửi một thông báo đẩy tới điện thoại bạn
- Điện thoại của bạn nằm úp mặt trên bàn, đang bật chế độ Tập trung
- Cảnh báo nằm im lặng cho tới khi có người để ý — vài tiếng sau
Với một microservice không trọng yếu, độ trễ đó chỉ gây khó chịu. Với API thanh toán, dịch vụ xác thực hay backend của sản phẩm chính, độ trễ đó khiến bạn mất tiền thật và mất niềm tin thật.
Cảnh báo bằng cuộc gọi hoạt động thế nào với Echobell
Echobell gửi thông báo ở ba mức khẩn:
- Thông thường (Active): Thông báo đẩy tiêu chuẩn
- Khẩn cấp: Xuyên qua chế độ Tập trung của iOS nhưng không đổ chuông
- Cuộc gọi: Làm điện thoại reo như một cuộc gọi bình thường
Với những lỗi API ảnh hưởng tới người dùng, mức cuộc gọi là phù hợp. Nó phản chiếu đúng cách bạn xử lý mọi cuộc gọi khẩn khác — bạn nghe máy vì điện thoại đang reo.
Việc thiết lập rất đơn giản:
- Tạo một kênh trong Echobell
- Đặt kiểu thông báo là Cuộc gọi
- Nối công cụ giám sát của bạn qua webhook
- Khi bài kiểm tra sức khỏe thất bại, Echobell gọi vào điện thoại bạn
Thiết lập cảnh báo cuộc gọi từ công cụ giám sát
Đa số nền tảng giám sát đều gửi được webhook khi một phép kiểm tra thất bại. Đây là cách nối chúng lại.
Dùng chính health check sẵn có của bạn
Nếu bạn đã có một endpoint kiểm tra sức khỏe (như /health hay /status), hãy cấu hình công cụ giám sát kiểm tra nó theo chu kỳ. Khi phản hồi không phải 200, hãy kích hoạt webhook.
Echobell nhận payload webhook có tiêu đề và nội dung:
curl -X POST https://hook.echobell.one/t/<channel-token> \
-H "Content-Type: application/json" \
-d '{
"title": "API DOWN: payment-service",
"body": "Health check failed - 500 error at 03:42 UTC",
"notificationType": "calling",
"externalLink": "https://your-dashboard.example.com/incidents/123"
}'Trường notificationType: calling chính là thứ khiến điện thoại đổ chuông.
Nên đưa gì vào cảnh báo
Hãy giữ nội dung cảnh báo đọc lướt được. Khi nghe máy lúc 3 giờ sáng, bạn cần hiểu vấn đề ngay lập tức:
- Tên dịch vụ — API hay microservice nào hỏng
- Loại lỗi — timeout, 5xx, connection refused
- Dấu thời gian — sự cố bắt đầu lúc nào
- Liên kết — chỗ để vào điều tra ngay
Đây không phải chỗ cho những đoạn văn dài dòng. Mục tiêu là có bối cảnh tức thì để bạn quyết định nên tỉnh hẳn hay chỉ cần xác nhận rồi ngủ tiếp.
Chọn đúng mức độ khẩn
Không phải lỗi API nào cũng cần một cuộc gọi. Hãy dùng cảnh báo cuộc gọi cho:
- Dịch vụ thanh toán và tính phí
- Endpoint xác thực và đăng nhập
- API sản phẩm chính mà người dùng tương tác trực tiếp
- Những dịch vụ mà các hệ thống trọng yếu khác phụ thuộc vào
Hãy dùng thông báo khẩn cấp cho:
- Dịch vụ phụ trợ quan trọng nhưng không ảnh hưởng trực tiếp tới doanh thu
- Môi trường phát triển hoặc staging
- Dấu hiệu cảnh báo (tỷ lệ lỗi cao nhưng chưa thành sự cố toàn phần)
Hãy dùng thông báo thông thường cho:
- Tác vụ nền không trọng yếu
- Chỉ số mang tính thông tin, không đòi hỏi hành động
Cách phân bậc này giúp bạn luôn được cảnh báo mà không rơi vào mệt mỏi vì cảnh báo.
Mở rộng cho nhiều dịch vụ
Nếu bạn vận hành nhiều hơn một API, hãy tạo kênh riêng cho từng dịch vụ hoặc từng nhóm dịch vụ:
production-payment-api— mức cuộc gọiproduction-user-api— mức cuộc gọiproduction-analytics-api— khẩn cấpstaging-all— khẩn cấp
Nhờ vậy bạn tinh chỉnh được mức khẩn cho từng dịch vụ. API thanh toán của bạn xứng đáng có một cuộc gọi; còn pipeline phân tích thì chắc là không.
Lợi ích thật sự
Giá trị của cảnh báo bằng cuộc gọi không nằm ở tiếng chuông. Nó nằm ở thay đổi hành vi mà tiếng chuông đó tạo ra:
- Bạn sửa vấn đề nhanh hơn vì biết chuyện ngay lập tức
- Bạn ngủ ngon hơn vì biết rằng nếu có gì hỏng thì mình sẽ thực sự được đánh thức
- Người dùng của bạn chịu thời gian gián đoạn ngắn hơn vì bạn phản ứng trong vài phút thay vì vài giờ
Với dịch vụ trọng yếu, khác biệt đó chính là toàn bộ mục đích.