---
title: "Mệt mỏi vì cảnh báo là có thật: Lập trình viên khôn ngoan khắc phục thế nào"
description: "Khi cảnh báo nào cũng khẩn như nhau thì chẳng cái nào còn khẩn nữa. Đây là cách chỉnh lại hệ thống giám sát bằng thông báo phân tầng — và những công cụ hợp với Echobell."
date: 2026-04-17
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - mệt mỏi vì cảnh báo
  - giám sát
  - Sentry
  - Prometheus
  - CloudWatch
  - DevOps
---

# Mệt mỏi vì cảnh báo là có thật: Lập trình viên khôn ngoan khắc phục thế nào

Hiện tượng này có hẳn một cái tên: mệt mỏi vì cảnh báo (alert fatigue). Nó xảy ra khi công cụ giám sát gửi quá nhiều thông báo đến mức não bạn tự động lọc bỏ chúng — kể cả những cái quan trọng.

Chuyện thường bắt đầu rất nhỏ. Bạn bật cảnh báo email cho mọi lỗi 5xx. Rồi thông báo Slack cho mọi lần build thất bại. Rồi Datadog ping, Sentry gửi mail, UptimeRobot nhắn tin. Chưa đầy một tháng, điện thoại bạn rung 50 lần mỗi ngày và chẳng cái nào có vẻ khẩn cả. Phần tệ nhất là gì? Khi có chuyện thật, bạn đã tự luyện cho mình thói quen phớt lờ nó rồi.

Mệt mỏi vì cảnh báo giết chết thời gian phản hồi. Và phản hồi chậm thì giết chết sản phẩm.

## Vì sao phần lớn hệ thống giám sát tạo ra nhiều nhiễu hơn tín hiệu

Vấn đề gốc là đa số công cụ cảnh báo đối xử với mọi sự kiện như nhau. Một bài test chập chờn thất bại 10% số lần nhận được đúng định dạng thông báo giống hệt "API thanh toán trả về lỗi 500 cho mọi người dùng". Một trong hai cái đó cần một cuộc gọi lúc 2 giờ sáng. Cái còn lại có lẽ chỉ nên xuất hiện trong bản tổng hợp hằng tuần.

Khi mọi thứ được đối xử như nhau, con người bắt đầu phớt lờ tất cả.

Cách khắc phục không phải là ít cảnh báo hơn — mà là gửi cảnh báo thông minh hơn. Cùng một sự kiện ở mức nghiêm trọng khác nhau, hoặc với tần suất khác nhau, phải tạo ra mức khẩn khác nhau trên điện thoại bạn.

## Cách tiếp cận ba tầng

Echobell cho bạn ba kiểu gửi, và dùng tốt cả ba chính là toàn bộ vấn đề:

- **Thông thường (Active):** Thông báo đẩy tiêu chuẩn. Ổn cho các sự kiện mang tính thông tin, không cần hành động ngay.
- **Khẩn cấp:** Xuyên qua chế độ Tập trung của iOS. Hợp cho những việc cần được chú ý trong một hai giờ tới.
- **Cuộc gọi:** Đổ chuông như một cuộc gọi đến. Hãy để dành cho tình huống "sửa ngay không thì hậu quả có thật".

Mục tiêu là giữ mức cuộc gọi cho những sự kiện mà phản hồi chậm gây hậu quả thật — mất doanh thu, lỗi lan dây chuyền, dữ liệu người dùng bị đe dọa. Mọi thứ khác hạ xuống mức khẩn cấp hoặc thấp hơn.

## Sentry: Đừng để mọi exception Python đều gọi bạn dậy

Sentry là ví dụ kinh điển của mệt mỏi vì cảnh báo. Mặc định nó gửi email cho bạn với mỗi loại issue mới. Trên một codebase đang hoạt động, trong một tuần bình thường, đó là cả một vòi rồng.

Đây là cách thiết lập khôn ngoan hơn:

1. Trong Sentry, vào **Alerts → Create Alert → Issue Alert**
2. Thêm điều kiện: `The issue is seen more than 10 times in 1 hour`
3. Thêm hành động: **Send a notification via webhook** → dán URL kênh Echobell của bạn
4. Đặt kiểu thông báo của kênh là `time-sensitive`

Với những đường thật sự nguy cấp — exception không được xử lý trong luồng thanh toán, lỗi xác thực, hỏng dữ liệu — hãy tạo một cảnh báo riêng với ngưỡng thấp hơn và một kênh Echobell ở mức `calling`. Kênh đó chỉ reo khi có gì đó hỏng đúng trên đường đi cụ thể ấy.

Kết quả: những issue thường ngày tích tụ lặng lẽ trong dashboard Sentry. Còn những vấn đề làm sập production thì làm điện thoại bạn reo lên.

## Prometheus và AlertManager: Định tuyến theo mức nghiêm trọng

Nếu bạn đang chạy Prometheus, bạn đã có sẵn AlertManager lo phần định tuyến. Bạn có thể gửi cảnh báo thẳng tới Echobell bằng cách thêm nó làm webhook receiver.

Trong `alertmanager.yml` của bạn:

```yaml
receivers:
  - name: echobell-critical
    webhook_configs:
      - url: https://hook.echobell.one/t/<channel-token>
        send_resolved: true

  - name: slack-warnings
    slack_configs:
      - api_url: YOUR_SLACK_WEBHOOK

route:
  group_by: ['alertname', 'job']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: slack-warnings
  routes:
    - match:
        severity: critical
      receiver: echobell-critical
```

Với thiết lập này, cảnh báo `severity: critical` đi tới Echobell và làm điện thoại bạn reo; cảnh báo mức warning đi vào Slack, nơi chúng có thể đợi tới sáng. Bạn không phải sửa một quy tắc Prometheus nào — chỉ thêm lớp định tuyến trong AlertManager.

Hãy đặt chính kênh Echobell đó ở chế độ **Cuộc gọi**. Nếu AlertManager gắn nhãn critical thì nó xứng đáng có một hồi chuông thật.

## AWS CloudWatch: SNS → Lambda → Echobell

CloudWatch không có đầu ra webhook gốc, nhưng bạn có thể làm được trong vài phút với SNS và một hàm Lambda nhỏ.

1. Tạo một SNS topic và gắn nó vào CloudWatch alarm của bạn
2. Tạo một hàm Lambda đăng ký nhận từ topic đó:

```python
import json
import urllib.request

def lambda_handler(event, context):
    message = json.loads(event['Records'][0]['Sns']['Message'])
    alarm_state = message.get('NewStateValue', 'UNKNOWN')

    payload = {
        "title": f"AWS: {message['AlarmName']}",
        "body": message.get('NewStateReason', 'No details'),
        "notificationType": "calling" if alarm_state == "ALARM" else "active"
    }

    req = urllib.request.Request(
        'https://hook.echobell.one/t/<channel-token>',
        data=json.dumps(payload).encode(),
        headers={'Content-Type': 'application/json'},
        method='POST'
    )
    urllib.request.urlopen(req)
```

Cách này áp dụng được cho mọi dịch vụ AWS hỗ trợ SNS: sự kiện RDS, lỗi dịch vụ ECS, cảnh báo ngưỡng chi phí, thay đổi trạng thái EC2 instance. Thêm một Lambda, nối vào SNS, và mọi CloudWatch alarm sẽ thành một cuộc gọi khi nó thực sự kích hoạt.

## Biến việc định tuyến cảnh báo thành quyết định của cả nhóm

Đòn bẩy thật sự của cảnh báo phân tầng là làm cho quyết định định tuyến trở nên rõ ràng — chứ không phải thứ một người cấu hình một lần rồi chẳng ai tìm ra.

Một cấu trúc thực dụng cho nhóm kỹ thuật nhỏ:

| Kênh | Loại | Ai đăng ký |
|---|---|---|
| `production-api-critical` | Cuộc gọi | Kỹ sư đang trực |
| `production-api-warnings` | Khẩn cấp | Cả nhóm phát triển |
| `staging-all` | Thông thường | Nhóm phát triển (tùy chọn) |
| `background-jobs` | Thông thường | Ai quan tâm thì đăng ký |

Khi đổi ca trực, người hết ca hủy đăng ký kênh nguy cấp và người vào ca đăng ký. Toàn bộ việc bàn giao ca chỉ có vậy — không file cấu hình, không bảng quản trị.

Kênh Echobell chia sẻ được qua liên kết, nên mỗi thành viên mới chỉ mất khoảng 10 giây để đăng ký.

## Phép thử tín hiệu trên nhiễu

Trước khi thêm bất kỳ cảnh báo mới nào, hãy tự hỏi một câu: nếu nó bắn lúc 3 giờ sáng thứ Sáu, tôi sẽ thực sự làm gì?

- "Bật dậy sửa ngay" → Cuộc gọi
- "Xử lý ngay sáng hôm sau" → Khẩn cấp hoặc Thông thường
- "Chắc chẳng làm gì, tôi ngủ tiếp" → hãy cân nhắc lại xem cảnh báo đó có nên tồn tại không

Phần lớn hệ thống giám sát có quá nhiều thứ ở nhóm đầu và quá ít ở nhóm thứ hai. Câu trả lời đúng cho đa số sự kiện là "để mai xử lý", và một thông báo khẩn cấp hiện trên màn hình khóa mà không đổ chuông chính là công cụ phù hợp cho việc đó.

## Mỗi lần một thay đổi

Nếu thiết lập hiện tại của bạn đang gây mệt mỏi vì cảnh báo, cách sửa nhanh nhất không phải là đại tu toàn bộ. Hãy chọn nguồn ồn ào nhất — có lẽ là email Sentry hoặc một kênh Slack mà ai cũng đã tắt tiếng — và phân loại từng kiểu sự kiện vào cuộc gọi, khẩn cấp hoặc thông thường.

Một nguồn. Một tuần. Xem thử tiếng ồn có giảm mà tín hiệu vẫn còn không.

Rồi làm tiếp nguồn kế tiếp.

Một hệ thống cảnh báo được tinh chỉnh tốt là thứ âm thầm cải thiện đời sống công việc hằng ngày mà chẳng cần ồn ào. Bạn thôi sợ chiếc điện thoại của mình. Và bạn bắt đầu tin rằng khi nó reo thì đúng là có chuyện thật.

---

## Bài liên quan

- [Nhận cảnh báo bằng cuộc gọi khi API của bạn sập](/vi/blog/phone-call-alerts-api-downtime)
- [Thông báo cuộc gọi từ Grafana với Echobell](/vi/blog/grafana-call-notification)
- [Vượt qua chế độ Tập trung của iOS cho cảnh báo nguy cấp](/vi/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [Điều kiện theo khung giờ để gửi cảnh báo thông minh hơn](/vi/blog/time-window-notifications-using-utc-conditions)
- [Dựng trung tâm tự động hóa với n8n và Echobell](/vi/blog/n8n-echobell-automation-hub)
- [Thông báo webhook cho iPhone](/vi/features/webhooks)