AllianceProject Handbook
← Knowledge

Vận hành

Quy tắc cảnh báo

Dashboard là thứ ta chủ động mở ra xem; cảnh báo là thứ tự đánh thức ta. Bài này là loại thứ hai: ngưỡng nào thì kêu, kêu với ai, và làm sao để cảnh báo không bị bỏ qua.

Cập nhật 12/09/2026vận hànhgiám sátcảnh báo
Nội dung bài
  1. Chỗ đứng của bài này
  2. Thước đo duy nhất
  3. Bốn tầng tín hiệu
  4. Ngưỡng phải đọc ra số người
  5. Chỉ số bắt buộc theo module
  6. Toàn app
  7. Chat
  8. Task
  9. Bán hàng
  10. Cảnh báo viết thế nào
  11. Ba mức cảnh báo
  12. Chống mệt mỏi vì cảnh báo
  13. Ai nhận cảnh báo
  14. Nhật ký và truy vết
Thuật ngữ trong bài (8)

Chỗ đứng của bài này

Production monitoring nói về dashboard — thứ ta chủ động mở ra nhìn theo nhịp cố định. Bài này nói về cảnh báo — thứ tự tìm tới ta, kể cả lúc 3 giờ sáng.

Hai thứ này cần tách vì chúng hỏng theo hai kiểu khác nhau. Dashboard hỏng khi không ai mở. Cảnh báo hỏng khi kêu quá nhiều tới mức người ta tắt thông báo.

Thước đo duy nhất

Một hệ thống giám sát tốt được đo bằng một câu: ta biết trước hay người dùng biết trước?

Nếu sự cố đầu tiên được phát hiện qua một phiếu hỗ trợ hoặc một đánh giá 1 sao, hệ thống giám sát đang hỏng — bất kể có bao nhiêu biểu đồ đẹp trên bảng điều khiển.

Đây là shift left áp dụng cho chặng vận hành: kéo thời điểm phát hiện về trước thời điểm người dùng cảm nhận được.

Bốn tầng tín hiệu

TầngTrả lời câu hỏiVí dụ
Có sống khôngApp có chạy được khôngTỷ lệ phiên không crash, tỷ lệ lỗi API
Có nhanh khôngNgười dùng chờ bao lâuThời gian khởi động, thời gian phản hồi
Có đúng khôngNghiệp vụ có ra kết quả đúng khôngĐơn lệch, tin nhắn không tới, thông báo trùng
Có ai dùng khôngHành vi có bất thường khôngSố tin nhắn, số task, số đơn theo giờ

Tầng ba và tầng bốn là hai tầng hay bị bỏ. Nhưng nhiều sự cố nghiêm trọng nhất không làm app crash — app vẫn chạy mượt, chỉ là tính sai tiền hoặc không gửi được tin. Chỉ có tầng ba và bốn bắt được loại đó.

Ngưỡng phải đọc ra số người

Alliance App hướng tới 500.000 người dùng. Ở quy mô đó, một ngưỡng phần trăm che mất mức độ nghiêm trọng thật:

NgưỡngSố người đứng sau nó
1% lỗi API5.000 người
0,5% nâng cấp thất bại2.500 người
0,1% đơn trùng500 đơn sai

Luật: mọi cảnh báo hiển thị cả tỷ lệ và số người bị ảnh hưởng. Người trực đêm cần con số tuyệt đối để quyết định gọi ai, chứ không cần tự nhân nhẩm lúc 3 giờ sáng.

Chỉ số bắt buộc theo module

Toàn app

Chỉ sốNgưỡng cảnh báo
Tỷ lệ phiên không crashDưới 99,7%
Tỷ lệ lỗi API (5xx)Trên 0,5% trong 5 phút
Thời gian phản hồi nhóm 95%Vượt ngân sách đã đặt 50%
Thời gian khởi động nguội nhóm 95%Trên 3 giây
Tỷ lệ nâng cấp thất bạiTrên 0,5%
Ngân sách lỗi tháng đã tiêuTrên 75% khi chưa hết tháng

Chat

Chỉ sốNgưỡng cảnh báo
Độ trễ gửi tới nhận nhóm 95%Trên 2 giây
Tỷ lệ tin nhắn phải gửi lạiTrên 3%
Tin nhắn trùng phát hiện đượcBất kỳ, cảnh báo ngay
Số tin nhắn gửi mỗi giờGiảm quá 30% so với cùng giờ tuần trước

Task

Chỉ sốNgưỡng cảnh báo
Tỷ lệ lỗi khi chuyển trạng tháiTrên 1%
Thông báo trùngBất kỳ, cảnh báo ngay
Thông báo trễ quá 5 phútTrên 2%
Lỗi phân quyền bị từ chối bất thườngTăng đột biến

Bán hàng

Chỉ sốNgưỡng cảnh báo
Tỷ lệ thanh toán thất bạiTrên 2%
Đơn trùng phát hiện đượcBất kỳ, báo ngay lập tức
Lệch giữa tổng đơn và báo cáo doanh sốBất kỳ, báo ngay lập tức
Số đơn chốt mỗi giờGiảm quá 30% so với cùng giờ tuần trước
Đơn treo ở trạng thái chờ quá 15 phútTrên 1%

Hai dòng in đậm không có ngưỡng chịu đựng. Một đơn trùng hoặc một đồng lệch là tín hiệu mô hình đang sai, và nó sẽ lớn lên theo khối lượng.

Cảnh báo viết thế nào

Cảnh báo tốt phải trả lời đủ bốn câu ngay trong nội dung:

[NGHIÊM TRỌNG] Tỷ lệ thanh toán thất bại 7,2% (ngưỡng 2%)

Cái gì:   Thanh toán thất bại tăng từ 1,1% lên 7,2% trong 10 phút qua.
Ai dính:  Khoảng 340 người dùng trong 10 phút, toàn bộ trên Android.
Từ khi:   14:32, trùng thời điểm bật cờ cong-thanh-toan-moi lên 20%.
Làm gì:   Tắt cờ cong-thanh-toan-moi. Hướng dẫn: <liên kết>
          Bảng số liệu: <liên kết>   Log liên quan: <liên kết>

Cảnh báo chỉ ghi "lỗi tăng" mà không kèm ngữ cảnh và bước xử lý là cảnh báo bắt người trực phải tự điều tra từ số không, lúc 3 giờ sáng.

Ba mức cảnh báo

MứcGửi đi đâuYêu cầu phản hồi
Nghiêm trọngGọi điện, đánh thức người trựcTrong 15 phút, mọi lúc
Cảnh báoKênh chat của độiTrong giờ làm việc
Thông tinBảng điều khiển, không gửi điXem khi soát hằng tuần

Chỉ được đặt mức nghiêm trọng khi có việc cụ thể phải làm ngay. Cảnh báo đánh thức người ta dậy mà câu trả lời đúng là "sáng mai xem" thì phải hạ mức.

Chống mệt mỏi vì cảnh báo

Đây là cách một hệ thống giám sát chết: quá nhiều cảnh báo nhiễu, đội quen bỏ qua, rồi bỏ qua luôn cảnh báo thật.

Luật giữ cho hệ thống sống:

  1. Mỗi cảnh báo phải có việc để làm. Không có việc thì đó là biểu đồ, không phải cảnh báo.
  2. Cảnh báo sai quá 3 lần trong tháng thì phải chỉnh ngưỡng hoặc xoá, trong tuần đó.
  3. Không quá 2 cảnh báo nghiêm trọng mỗi tuần ở trạng thái bình thường. Nhiều hơn nghĩa là hoặc hệ thống đang thật sự tệ, hoặc ngưỡng đang sai — cả hai đều phải xử lý.
  4. Soát toàn bộ danh sách cảnh báo hằng tháng: cái nào chưa bao giờ kêu, cái nào kêu suốt.
  5. Cảnh báo dựa trên triệu chứng người dùng cảm nhận được, không dựa trên nguyên nhân kỹ thuật. Báo "người dùng không gửi được tin nhắn" hữu ích hơn "CPU 90%" — CPU cao mà người dùng không bị gì thì không cần ai thức dậy.

Ai nhận cảnh báo

Lịch trực, quyền của người trực và cách bàn giao nằm ở Bug severity, on-call và root cause analysis. Điểm cần nhắc ở đây: mỗi cảnh báo phải trỏ tới một người cụ thể đang trực, không trỏ vào một nhóm chat. Cảnh báo gửi vào nhóm là cảnh báo không ai thấy mình có trách nhiệm.

Nhật ký và truy vết

  • Mỗi yêu cầu mang một mã tương quan đi xuyên suốt từ app tới các dịch vụ, để ghép được toàn bộ hành trình khi điều tra.
  • Log giữ tối thiểu 30 ngày, log liên quan tới giao dịch giữ theo yêu cầu kế toán.
  • Không bao giờ log nội dung tin nhắn, dữ liệu thẻ, hay thông tin cá nhân — xem bảo mật và quyền riêng tư.
  • Bảng điều khiển chính phải mở được từ điện thoại. Sự cố không chờ ai về tới bàn làm việc.