Mở đầu — vì sao bài này quan trọng
Hãy hình dung thế này: bạn vừa ship một tính năng mới sau ba tháng làm việc cật lực. Đêm hôm đó bạn ngủ ngon. Nhưng đến 2 giờ sáng, một bug âm thầm khiến 30% giao dịch thanh toán bị fail. Không ai biết. Đến 8 giờ sáng khi support nhận hàng trăm ticket phẫn nộ, bạn mới phát hiện ra. Sáu tiếng đó đã làm công ty mất hàng trăm triệu đồng doanh thu và một lượng lớn niềm tin của khách hàng.
Câu chuyện này lặp đi lặp lại ở mọi công ty, và nguyên nhân gần như luôn giống nhau: không ai định nghĩa trước cần theo dõi (monitor) cái gì và khi nào thì hệ thống phải báo động (alert). Là PM, bạn có thể nghĩ "đó là việc của engineer". Sai. Engineer biết cách dựng dashboard và cấu hình alert, nhưng họ không phải lúc nào cũng biết chỉ số nào quan trọng với business, ngưỡng nào là chấp nhận được, hay bao nhiêu phút downtime thì khách hàng bắt đầu rời bỏ. Đó chính là phần của bạn.
Một PRD hoàn chỉnh không kết thúc ở dòng "tính năng hoạt động". Nó phải trả lời câu hỏi: "Sau khi ship, làm sao chúng ta biết tính năng này đang khỏe hay đang bệnh?" Phần Monitoring & Alerting Plan trong spec chính là câu trả lời đó. Nó là hợp đồng giữa bạn, engineering và on-call team về việc điều gì đáng để đánh thức ai đó dậy lúc nửa đêm — và điều gì thì không.
Khái niệm cốt lõi
Monitoring và Alerting là hai khái niệm liên quan nhưng khác nhau, và lẫn lộn chúng là lỗi phổ biến nhất.
Monitoring (giám sát) là việc thu thập và hiển thị dữ liệu liên tục về trạng thái hệ thống — thường qua dashboard. Monitoring trả lời câu hỏi "chuyện gì đang xảy ra?". Bạn nhìn vào nó một cách chủ động.
Alerting (báo động) là việc tự động thông báo cho con người khi một chỉ số vượt ngưỡng nguy hiểm. Alerting trả lời câu hỏi "có cần ai đó hành động ngay không?". Nó tìm đến bạn một cách bị động.
Quy tắc vàng: Mọi alert đều phải actionable. Nếu một alert nổ lên mà người nhận không thể làm gì để xử lý, đó không phải alert — đó là tiếng ồn. Tiếng ồn nhiều sẽ dẫn đến "alert fatigue" (mệt mỏi vì báo động), và khi đó người ta bắt đầu phớt lờ cả những alert thật sự quan trọng.
Ba nhóm metrics cần theo dõi
Trong spec, hãy phân loại các chỉ số cần giám sát thành ba nhóm rõ ràng. Cách phân loại này giúp cả team không bỏ sót và không nhầm lẫn vai trò của từng chỉ số.
1. Health metrics (chỉ số sức khỏe kỹ thuật) — Đây là mạch đập của hệ thống. Chúng cho biết phần mềm có đang chạy đúng về mặt kỹ thuật hay không.
- Error rate: tỷ lệ request bị lỗi (ví dụ HTTP 5xx). Thường tính theo phần trăm tổng request.
- Latency: thời gian phản hồi. Đừng chỉ nhìn trung bình — hãy nhìn percentile như p95, p99 (95% và 99% request nhanh hơn con số này). Trung bình che giấu trải nghiệm tệ của nhóm người dùng đuôi.
- Crash rate / availability: tỷ lệ app crash hoặc tỷ lệ uptime (ví dụ 99.9%).
- Throughput: số request mỗi giây — để phát hiện khi traffic tăng đột biến hoặc rớt bất thường.
- Conversion rate: tỷ lệ chuyển đổi qua các bước phễu (ví dụ: thêm vào giỏ → thanh toán thành công).
- Signups / activations: số đăng ký mới, số kích hoạt.
- DAU / MAU: người dùng hoạt động hằng ngày/tháng.
- Revenue / GMV: doanh thu hoặc tổng giá trị giao dịch.
3. Resource metrics (chỉ số tài nguyên) — Đây là sức khỏe của hạ tầng bên dưới. Chúng thường là tín hiệu cảnh báo sớm trước khi health metrics xấu đi.
- CPU / Memory: mức sử dụng vi xử lý và bộ nhớ của server.
- Disk usage: dung lượng ổ đĩa còn lại (database đầy đĩa là một trong những nguyên nhân downtime phổ biến nhất).
- Database connections: số kết nối đang mở so với giới hạn.
- Queue depth: số việc đang xếp hàng chờ xử lý.
Bốn cấp độ ưu tiên của alert
Không phải alert nào cũng như nhau. Hãy định nghĩa cấp độ (severity) trong spec:
- P0 / SEV1 — Critical: hệ thống chết, mất tiền, mất dữ liệu. Gọi điện đánh thức on-call ngay, bất kể giờ giấc.
- P1 / SEV2 — High: chức năng quan trọng suy giảm nhưng chưa chết hẳn. Báo qua Slack/PagerDuty, xử lý trong giờ làm việc hoặc trong vài giờ.
- P2 / SEV3 — Medium: vấn đề cần chú ý nhưng không khẩn cấp. Tạo ticket, xử lý trong tuần.
- P3 — Info / Warning: tín hiệu cần ghi nhận, theo dõi xu hướng, không cần hành động ngay.
Tình huống thực tế
Ví dụ 1 — Tiki và alert thiếu business metric trong mùa sale
Hãy tưởng tượng một sàn thương mại điện tử lớn của Việt Nam (gọi là sàn X, lấy cảm hứng từ các đợt sale 11.11). Đội kỹ thuật đã dựng monitoring rất tốt cho health metrics: error rate, latency, CPU đều có dashboard và alert đầy đủ.
Trong đợt sale 11.11, đúng 0h00 traffic tăng gấp 8 lần. Mọi health metric đều xanh: error rate dưới 0.1%, latency p99 ổn định. Đội on-call yên tâm. Nhưng đến 0h45, một PM tình cờ nhìn dashboard business và phát hiện conversion rate ở bước áp mã giảm giá đã rớt từ 12% xuống 3%. Hóa ra service tính mã giảm giá bị quá tải, trả về "mã không hợp lệ" thay vì báo lỗi — nên về kỹ thuật nó vẫn là response 200, không kích hoạt alert nào.
Diễn giải: Trong 45 phút, hàng chục nghìn khách hàng bỏ giỏ hàng vì tưởng mã của họ hết hạn. Health metric hoàn hảo, nhưng business đang chảy máu.
Bài học: PM phải yêu cầu đặt alert trên các business metric quan trọng, đặc biệt là các bước trong phễu chuyển đổi. Một alert kiểu "conversion ở bước áp mã giảm dưới 50% so với baseline 30 phút trước" sẽ đã cứu được tình huống này. Đừng để engineer tự quyết định nên alert cái gì — họ không nhìn thấy phễu doanh thu như bạn.
Ví dụ 2 — Một fintech ví điện tử và bài toán alert fatigue
Một ví điện tử ở Đông Nam Á (gọi là ví Y) gặp vấn đề ngược lại: alert quá nhiều. Họ đặt ngưỡng error rate quá nhạy — cứ vượt 0.5% là gọi điện on-call. Vấn đề là hệ thống thanh toán phụ thuộc vào nhiều ngân hàng đối tác, và việc một ngân hàng nhỏ rớt vài phút khiến error rate nhảy lên 0.6% là chuyện thường ngày, tự hồi phục sau 2 phút.
Kết quả: on-call engineer bị gọi 4-5 lần mỗi đêm cho những sự cố tự khỏi. Sau hai tuần, họ bắt đầu tắt thông báo. Rồi một đêm, một sự cố thật — service xác thực OTP chết hoàn toàn — alert nổ lên nhưng bị phớt lờ vì "chắc lại tự khỏi". Phải mất 90 phút mới có người phản hồi.
Diễn giải: Alert quá nhạy đã huấn luyện con người phớt lờ chúng. Đây là nghịch lý: monitoring quá mức làm giảm độ an toàn.
Bài học: Ngưỡng alert phải dựa trên tác động thực tế đến người dùng, không phải con số tuyệt đối. Áp dụng kỹ thuật "duration window" — chỉ alert khi error rate vượt 2% liên tục trong 5 phút, chứ không phải mỗi khi có một spike tức thời. Phân biệt rõ giữa lỗi do đối tác (cần dashboard theo dõi) và lỗi nội bộ (cần alert ngay). Mỗi alert phải vượt qua bài kiểm tra: "Nếu cái này nổ lúc 3 giờ sáng, người nhận có việc gì để làm không?"
Ví dụ 3 — Startup SaaS và disk full lúc nửa đêm
Một startup SaaS B2B (gọi là công ty Z) phục vụ khoảng 200 doanh nghiệp. Họ chỉ monitor health metrics ở tầng ứng dụng và bỏ qua resource metrics vì "server mới mua, còn rộng rãi". Sau sáu tháng, log và dữ liệu tích tụ làm ổ đĩa database đầy dần — mỗi ngày tăng khoảng 2%.
Một đêm Chủ Nhật, ổ đĩa đạt 100%. Database ngừng ghi. Toàn bộ khách hàng không thể lưu dữ liệu. Vì không có resource alert, không ai biết cho đến sáng Thứ Hai khi khách hàng gọi điện. Downtime kéo dài 9 tiếng.
Diễn giải: Resource metric (disk usage) là tín hiệu dẫn trước (leading indicator). Xu hướng tăng đều đặn của nó hoàn toàn có thể dự báo được từ nhiều ngày trước.
Bài học: Một alert đơn giản "disk usage vượt 80%" sẽ tạo ra 10 ngày cảnh báo trước khi thảm họa xảy ra — đủ thời gian để xử lý trong giờ hành chính. Resource metric rẻ để monitor nhưng cực kỳ giá trị vì nó cho bạn thời gian. Trong spec, luôn yêu cầu ngưỡng cảnh báo trước khi cạn kiệt, không phải lúc đã cạn.
Hướng dẫn từng bước
Đây là quy trình để viết phần Monitoring & Alerting Plan trong spec của bạn.
Bước 1 — Liệt kê các "khoảnh khắc thành công" của tính năng. Trước khi nghĩ về metric, hãy tự hỏi: tính năng này thành công nghĩa là gì? Ví dụ với tính năng thanh toán: "người dùng nhập thông tin → giao dịch được xử lý dưới 3 giây → tiền vào tài khoản đúng". Mỗi khoảnh khắc này là một điểm cần đo.
Bước 2 — Ánh xạ mỗi khoảnh khắc thành metric trong ba nhóm. Với mỗi điểm thành công, hỏi: chỉ số health nào phản ánh nó? chỉ số business nào? cần resource nào hỗ trợ? Lập một bảng ba cột.
Bước 3 — Định nghĩa baseline và ngưỡng (threshold). Với mỗi metric, ghi rõ: giá trị bình thường (baseline) là bao nhiêu, và ngưỡng nào thì đáng lo. Ví dụ: "Latency p95 baseline 200ms; warning khi >500ms; critical khi >1000ms trong 5 phút liên tục". Nếu chưa có dữ liệu lịch sử, hãy ghi "cần đo baseline trong tuần đầu" và đặt ngưỡng tạm.
Bước 4 — Gán severity, owner và kênh thông báo. Mỗi alert cần: cấp độ (P0–P3), người/đội chịu trách nhiệm, và gửi qua đâu (gọi điện PagerDuty cho P0, Slack cho P1, ticket cho P2). Ghi rõ trong bảng.
Bước 5 — Viết runbook cho mỗi alert critical. Runbook là hướng dẫn từng bước: khi alert này nổ, kiểm tra cái gì trước, làm gì để khắc phục, leo thang lên ai nếu không xử lý được. Một alert P0 không có runbook là một alert nửa vời. Bạn không cần viết chi tiết kỹ thuật, nhưng cần đảm bảo engineer đã chuẩn bị nó.
Bước 6 — Định nghĩa dashboard. Liệt kê dashboard nào cần tồn tại, ai sẽ xem, và xem khi nào (ví dụ: dashboard launch-day mà cả team theo dõi 48 giờ đầu sau khi ship).
Bước 7 — Lên kế hoạch giám sát giai đoạn launch. 48 giờ đầu sau khi ship là rủi ro nhất. Ghi rõ ai trực, theo dõi metric nào sát sao, và tiêu chí rollback (hủy phát hành) là gì. Ví dụ: "Nếu error rate >5% trong 10 phút, rollback ngay."
Một mẫu bảng gọn để đưa vào spec:
| Metric | Nhóm | Baseline | Ngưỡng alert | Severity | Owner | Kênh |
|---|---|---|---|---|---|---|
| Payment error rate | Health | <0.2% | >2% trong 5 phút | P0 | Payments team | PagerDuty |
| Checkout conversion | Business | ~12% | giảm >40% so với baseline 30 phút | P1 | Growth + on-call | Slack |
| DB disk usage | Resource | <60% | >80% | P2 | Infra | Ticket |
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ monitor health, bỏ quên business. Đây là lỗi phổ biến nhất và nguy hiểm nhất (xem ví dụ Tiki). Hệ thống xanh lè trên dashboard nhưng doanh thu đang rơi. Mẹo: với mỗi tính năng có tác động doanh thu, bắt buộc có ít nhất một business metric được alert.
Lỗi 2 — Đặt ngưỡng quá nhạy gây alert fatigue. Quá nhiều alert giả khiến người ta phớt lờ alert thật (xem ví dụ ví Y). Mẹo: dùng duration window (alert khi vượt ngưỡng liên tục trong X phút), và định kỳ review tỷ lệ "alert nổ nhưng không cần hành động" — nếu trên 20%, ngưỡng đang quá nhạy.
Lỗi 3 — Alert không actionable. Alert kiểu "có gì đó lạ" mà không nói rõ làm gì là vô dụng. Mẹo: mỗi alert phải kèm link tới runbook và mô tả rõ tác động đến người dùng.
Lỗi 4 — Không có owner. Alert gửi vào một channel mà "mọi người" chịu trách nhiệm tức là không ai chịu trách nhiệm. Mẹo: mỗi alert có đúng một owner team được chỉ định.
Lỗi 5 — Chỉ nhìn giá trị trung bình. Trung bình che giấu nỗi đau của nhóm người dùng đuôi. Mẹo: luôn dùng percentile (p95, p99) cho latency, không dùng mean.
Lỗi 6 — Quên resource metrics. Vì chúng "ít khi có vấn đề" nên bị bỏ qua — cho đến khi disk full lúc nửa đêm (xem ví dụ công ty Z). Mẹo: luôn đặt alert dự báo (ví dụ disk >80%) cho các tài nguyên có thể cạn kiệt.
Mẹo bổ sung — Phân biệt SLI, SLO, SLA. Nếu spec của bạn cần mức độ chính thức cao: SLI (Service Level Indicator) là metric bạn đo, SLO (Objective) là mục tiêu nội bộ (ví dụ uptime 99.9%), SLA (Agreement) là cam kết hợp đồng với khách hàng. Alert nên nổ trước khi vi phạm SLO, để bạn còn thời gian xử lý trước khi vi phạm SLA.
Bài tập thực hành
Hãy chọn một tính năng bạn đang làm hoặc quen thuộc (ví dụ: tính năng "đặt món" trên một app giao đồ ăn). Sau đó:
- Liệt kê 3 khoảnh khắc thành công của tính năng đó (ví dụ: chọn món xong, đặt đơn thành công, tài xế nhận đơn).
- Lập bảng monitoring với ít nhất 6 metric, phân bổ vào ba nhóm: 2 health, 2 business, 2 resource. Với mỗi metric ghi rõ baseline (ước lượng cũng được) và ngưỡng alert.
- Gán severity và owner cho từng alert. Tự hỏi với mỗi cái: "Nếu nó nổ lúc 3 giờ sáng, có đáng đánh thức ai không?" Nếu không, hạ severity xuống.
- Viết runbook ngắn (3-4 dòng) cho alert P0 quan trọng nhất: kiểm tra gì trước, làm gì, leo thang lên ai.
- Định nghĩa tiêu chí rollback cho 48 giờ đầu sau khi ship: con số nào khiến bạn quyết định hủy phát hành ngay?
Tóm tắt
Monitoring & Alerting Plan là phần trả lời câu hỏi "sau khi ship, làm sao biết tính năng khỏe hay bệnh?" — và nó là trách nhiệm chung mà PM phải chủ động đóng góp, đặc biệt ở khía cạnh business.
Những điều cần nhớ:
- Phân biệt monitoring (giám sát chủ động qua dashboard) và alerting (báo động bị động khi vượt ngưỡng). Mọi alert phải actionable.
- Theo dõi ba nhóm metrics: Health (error rate, latency, crash), Business (conversion, signups, DAU, revenue), và Resource (CPU, memory, disk, connections). Đừng để health xanh đánh lừa khi business đang chảy máu.
- Mỗi alert cần ngưỡng dựa trên tác động thực, một severity, một owner, một kênh, và một runbook. Dùng duration window để tránh alert fatigue.
- Resource metrics là tín hiệu dẫn trước — đặt ngưỡng cảnh báo trước khi cạn kiệt để có thời gian xử lý.
- 48 giờ đầu sau khi ship là rủi ro nhất — lên kế hoạch trực và tiêu chí rollback rõ ràng.