Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là BA của một sàn thương mại điện tử. 9 giờ sáng thứ Hai, bộ phận chăm sóc khách hàng báo lên: "Nhiều khách phản ánh không đặt được hàng, bấm thanh toán xong thì màn hình quay vòng vòng rồi báo lỗi." Câu hỏi đầu tiên ban lãnh đạo hỏi bạn không phải là "ai làm hỏng?" mà là: "Đang hỏng cái gì, ảnh hưởng bao nhiêu người, và từ lúc nào?"
Nếu hệ thống của bạn không có logging và monitoring tử tế, câu trả lời sẽ là: "Em chưa biết, để em hỏi dev." Và dev cũng sẽ trả lời: "Để em mở máy lên xem." Trong khoảng thời gian mò mẫm đó, doanh thu đang chảy ra ngoài từng phút.
Đây chính là lý do observability (khả năng quan sát) trở thành một kỹ năng nền tảng mà BA cần hiểu, dù bạn không phải là người trực tiếp viết log hay dựng dashboard. BA là cầu nối giữa nghiệp vụ và kỹ thuật. Khi bạn viết spec cho một tính năng API mới, nếu bạn biết đặt câu hỏi "tính năng này sẽ được log như thế nào?", "chúng ta đo lường thành công bằng metric gì?", "khi nó hỏng thì ai được cảnh báo?", bạn đã nâng chất lượng sản phẩm lên một bậc. Ngược lại, một BA mù mờ về quan sát hệ thống thường viết ra những spec đẹp về mặt chức năng nhưng "câm điếc" khi vận hành thực tế.
Bài này không biến bạn thành kỹ sư DevOps. Mục tiêu là giúp bạn nói chung ngôn ngữ với đội kỹ thuật, đọc được dashboard, hiểu các chỉ số sức khỏe của API, và quan trọng nhất: biết đưa yêu cầu về quan sát vào ngay từ giai đoạn thiết kế.
Khái niệm cốt lõi
Phân biệt Monitoring và Observability
Hai khái niệm này thường bị dùng lẫn lộn nhưng khác nhau về bản chất.
Monitoring (giám sát) là việc theo dõi những thứ ta đã biết trước là cần quan tâm. Ví dụ: tỷ lệ lỗi của API có vượt 1% không? CPU server có quá 80% không? Thời gian phản hồi trung bình có chậm hơn 500ms không? Monitoring trả lời cho những câu hỏi bạn đã chuẩn bị sẵn — gọi là "known unknowns" (những điều ta biết là mình cần theo dõi).
Observability (khả năng quan sát) rộng hơn. Đó là khả năng của hệ thống cho phép bạn đặt ra những câu hỏi mới mà bạn chưa từng nghĩ tới và vẫn trả lời được mà không cần đi sửa code thêm. Đây là "unknown unknowns". Ví dụ: "Tại sao chỉ những khách hàng dùng app trên Android phiên bản 12, đặt hàng vào khung 9-10h sáng, thanh toán qua MoMo lại bị lỗi?" Một hệ thống quan sát tốt cho phép bạn lọc và đào sâu để tìm ra mẫu hình bất ngờ như vậy.
Nói ngắn gọn: monitoring cho bạn biết có gì đó sai, observability giúp bạn hiểu tại sao nó sai.
Ba trụ cột của Observability
Toàn bộ thế giới quan sát hệ thống xoay quanh ba loại dữ liệu, thường gọi là "three pillars".
1. Logs (Nhật ký) — "Chuyện gì đã xảy ra?"
Log là những bản ghi sự kiện dạng văn bản, có dấu thời gian, mô tả một việc cụ thể vừa diễn ra. Ví dụ một dòng log:
2026-06-27 09:14:32 ERROR [order-service] Thanh toán thất bại, orderId=88213, userId=4471, gateway=MoMo, reason="timeout sau 30s", traceId=a1b2c3
Log hiện đại thường ở dạng structured log (JSON) thay vì text thuần, để máy có thể tìm kiếm và lọc dễ dàng:
{
"timestamp": "2026-06-27T09:14:32Z",
"level": "ERROR",
"service": "order-service",
"message": "Thanh toán thất bại",
"orderId": 88213,
"gateway": "MoMo",
"traceId": "a1b2c3"
}
Có các mức độ (log level) mà BA nên biết: DEBUG (chi tiết phục vụ gỡ lỗi), INFO (sự kiện bình thường), WARN (cảnh báo, chưa hỏng nhưng đáng chú ý), ERROR (có lỗi), FATAL/CRITICAL (hỏng nghiêm trọng, hệ thống có thể sập). Log mạnh ở chỗ chi tiết và giàu ngữ cảnh, nhưng yếu ở chỗ khối lượng khổng lồ và tốn chi phí lưu trữ.
2. Metrics (Chỉ số) — "Đo lường được bao nhiêu?"
Metric là dữ liệu dạng số, theo chuỗi thời gian (time-series). Thay vì ghi từng sự kiện, metric tổng hợp lại thành con số đo được theo thời gian. Ví dụ: "số request mỗi giây", "tỷ lệ lỗi 5%", "p95 latency = 420ms".
BA cần thuộc nằm lòng nhóm metric kinh điển cho API gọi là RED:
- Rate — số request mỗi giây (lưu lượng).
- Errors — tỷ lệ request bị lỗi.
- Duration — thời gian xử lý request (thường nhìn p50, p95, p99 thay vì trung bình).
3. Traces (Dấu vết) — "Hành trình của một request đi qua đâu?"
Trong hệ thống nhiều dịch vụ, một request của khách có thể đi qua hàng chục service. Trace ghi lại toàn bộ hành trình đó: request đến API Gateway, qua order-service, gọi sang payment-service, payment-service gọi sang MoMo, rồi quay về. Mỗi chặng gọi là một span, và toàn bộ chuỗi span chia sẻ chung một traceId.
Trace giúp trả lời câu hỏi "request chậm 8 giây, nhưng nó chậm ở khúc nào?" — ở khâu gọi database, hay ở khâu gọi cổng thanh toán bên thứ ba? (Phần trace xuyên service sẽ được đào sâu ở Bài 52 về distributed tracing; ở đây bạn chỉ cần nắm vai trò của nó trong bức tranh ba trụ cột.)
Alerting — biến quan sát thành hành động
Quan sát mà không có cảnh báo thì giống như lắp camera an ninh nhưng không ai ngồi xem màn hình. Alerting là cơ chế tự động phát hiện điều kiện bất thường (ví dụ: tỷ lệ lỗi vượt 5% trong 3 phút liên tục) và báo cho đúng người qua email, Slack, Telegram hay gọi điện. BA nên hiểu khái niệm này vì các yêu cầu về ngưỡng cảnh báo thường xuất phát từ nghiệp vụ, không phải từ kỹ thuật.
Hai chỉ số sống còn: MTTD và MTTR
- MTTD (Mean Time To Detect) — thời gian trung bình từ lúc sự cố xảy ra đến lúc phát hiện ra.
- MTTR (Mean Time To Recovery) — thời gian trung bình từ lúc phát hiện đến lúc khắc phục xong.
Tình huống thực tế
Tình huống 1: Sàn TMĐT và sự cố thanh toán "vô hình"
Một sàn thương mại điện tử tại TP.HCM (gọi là ShopViet) tích hợp ba cổng thanh toán: MoMo, VNPay và thẻ quốc tế. Một sáng, tổng đài nhận hơn 200 cuộc gọi phàn nàn không đặt được hàng trong vòng 1 giờ. Đội kỹ thuật vào kiểm tra thì thấy tỷ lệ lỗi tổng (overall error rate) của API đặt hàng chỉ tăng nhẹ từ 0,8% lên 1,3% — nhìn qua tưởng không có gì.
Nhờ structured log có trường gateway, một kỹ sư lọc log theo gateway=MoMo và phát hiện: riêng các đơn qua MoMo có tỷ lệ timeout tăng vọt lên 40%. Trace cho thấy span gọi sang MoMo mất trung bình 28 giây trước khi timeout. Hóa ra phía MoMo đang gặp sự cố hạ tầng, nhưng vì MoMo chỉ chiếm khoảng 12% lượng giao dịch nên lỗi bị "pha loãng" trong con số tổng.
Bài học: Metric tổng hợp dễ che giấu vấn đề cục bộ. Nếu spec ban đầu của BA yêu cầu log và metric phải tách theo từng cổng thanh toán (dimension/label theo gateway), đội ngũ đã phát hiện và chủ động ngắt MoMo, chuyển hướng khách sang VNPay chỉ trong vài phút thay vì để khách tự bỏ giỏ hàng. BA chính là người nên đặt câu hỏi "ta có cần nhìn chỉ số tách theo từng đối tác không?" ngay từ lúc viết spec.
Tình huống 2: Ngân hàng số và cái bẫy "log mọi thứ"
Một ngân hàng số tại Đông Nam Á (giả định là DigiBank) ra mắt API chuyển khoản. Đội phát triển, vì lo lắng, đã bật log ở mức DEBUG cho toàn bộ hệ thống production và log lại cả nội dung request body. Hai vấn đề lập tức xảy ra.
Thứ nhất, chi phí lưu trữ log nổ tung: từ vài chục GB mỗi ngày lên hơn 2 TB, kéo theo hóa đơn nền tảng log tăng hàng nghìn USD mỗi tháng. Thứ hai, nghiêm trọng hơn, log vô tình ghi cả số CMND, số tài khoản đầy đủ và OTP của khách — một vi phạm nghiêm trọng về dữ liệu cá nhân, vướng cả quy định bảo mật ngành ngân hàng.
Khi rà soát lại, BA phụ trách đã làm việc với đội kỹ thuật để đặt ra quy tắc: production chạy ở mức INFO, các trường nhạy cảm phải được masking (che bớt, ví dụ chỉ hiện 4 số cuối tài khoản), và OTP/mật khẩu tuyệt đối không được log.
Bài học: "Quan sát nhiều hơn" không phải lúc nào cũng tốt. BA cần cân bằng giữa độ chi tiết, chi phí và tuân thủ bảo mật. Một mục bắt buộc trong checklist spec nên là: "Trường dữ liệu nào được phép log, trường nào phải mask, trường nào cấm log?"
Tình huống 3: Startup giao đồ ăn và SLO cứu giờ cao điểm
Một startup giao đồ ăn (giả định FoodNow) phục vụ cao điểm bữa trưa 11h-13h. Trước đây họ chỉ giám sát "API có sống không" (up/down). Nhưng khách vẫn than app chậm dù hệ thống báo "xanh". Đội BA và kỹ thuật cùng định nghĩa một SLO (Service Level Objective): "95% request tìm quán phải trả về dưới 1 giây."
Họ dựng dashboard theo dõi p95 latency theo thời gian thực và đặt alert khi p95 vượt 1 giây kéo dài quá 2 phút. Một ngày, đúng 11h15, alert kêu: p95 nhảy lên 2,3 giây. Đội kịp thời phát hiện một truy vấn database thiếu index khi lượng tìm kiếm tăng đột biến, và bổ sung cache trước khi đỉnh điểm 12h ập đến.
Bài học: "Hệ thống còn sống" không đồng nghĩa với "khách hàng đang hài lòng". Định nghĩa SLO dựa trên trải nghiệm thực của khách (như tốc độ phản hồi p95) cho phép phát hiện vấn đề trước khi nó thành thảm họa. BA là người hiểu nghiệp vụ nhất để đề xuất con số SLO hợp lý — "1 giây" ở đây xuất phát từ hiểu biết về hành vi người dùng giờ cao điểm, không phải con số kỹ thuật tùy tiện.
Hướng dẫn từng bước
Khi bạn là BA tham gia thiết kế hoặc rà soát một tính năng có API, đây là quy trình đưa observability vào ngay từ đầu.
Bước 1 — Xác định "câu hỏi vận hành" cần trả lời. Trước khi nghĩ tới công cụ, hãy liệt kê những câu hỏi mà đội vận hành sẽ hỏi khi tính năng chạy thật: "Bao nhiêu đơn thành công mỗi giờ?", "Khi thanh toán lỗi, ta biết lỗi ở đâu không?", "Khách nào bị ảnh hưởng?". Mỗi câu hỏi sẽ dẫn tới một yêu cầu về log, metric hoặc trace cụ thể.
Bước 2 — Định nghĩa metric nghiệp vụ và metric kỹ thuật. Metric kỹ thuật là RED (rate, errors, duration). Nhưng BA có lợi thế đề xuất thêm metric nghiệp vụ: số đơn đặt thành công, tỷ lệ chuyển đổi từ giỏ hàng sang thanh toán, doanh thu theo cổng thanh toán. Đây là thứ kỹ sư thuần túy hay bỏ sót.
Bước 3 — Quy định nội dung log và mức độ. Ghi rõ trong spec: sự kiện nào cần log, ở mức nào, kèm những trường ngữ cảnh gì (orderId, userId, traceId). Đừng quên đánh dấu trường nhạy cảm cần mask.
Bước 4 — Thiết lập correlation ID. Yêu cầu mỗi request có một mã định danh xuyên suốt (traceId/correlationId) để khi cần điều tra, ta lần được toàn bộ hành trình của một đơn hàng cụ thể qua tất cả các service và dòng log.
Bước 5 — Định nghĩa ngưỡng cảnh báo (alert) và người nhận. Viết rõ: điều kiện nào kích hoạt alert (ví dụ error rate > 5% trong 3 phút), mức độ nghiêm trọng, và ai nhận — đội trực hay tổng đài. Cẩn thận với alert quá nhạy (xem phần lỗi thường gặp).
Bước 6 — Thiết kế dashboard cho từng đối tượng. Dashboard cho kỹ sư khác dashboard cho ban lãnh đạo. Sếp muốn nhìn "doanh thu, đơn thành công, sự cố lớn"; kỹ sư muốn nhìn "latency p99, queue depth, error theo endpoint". BA giúp xác định mỗi bên cần nhìn gì.
Bước 7 — Định nghĩa SLI/SLO. Chọn vài chỉ số phản ánh trải nghiệm khách (SLI — Service Level Indicator) và đặt mục tiêu cụ thể cho chúng (SLO). Đây là kim chỉ nam để biết hệ thống "đủ tốt" hay chưa. (Chủ đề SLA với đối tác sẽ được bàn riêng ở Bài 55.)
Bước 8 — Đưa các yêu cầu trên thành acceptance criteria. Cuối cùng, biến tất cả thành tiêu chí nghiệm thu để đảm bảo đội phát triển thực sự triển khai, chứ không chỉ nằm trên giấy.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi observability là việc "để sau khi launch". Rất nhiều dự án xem log/monitoring là thứ bổ sung sau cùng. Hậu quả: khi sự cố đầu tiên xảy ra trong tuần ra mắt, đội ngũ mù tịt. Mẹo: đưa yêu cầu quan sát vào Definition of Done của mọi tính năng.
Lỗi 2 — Alert fatigue (mệt mỏi vì cảnh báo). Đặt quá nhiều alert, hoặc ngưỡng quá nhạy, khiến đội trực nhận hàng trăm cảnh báo mỗi ngày. Dần dần họ phớt lờ tất cả — và bỏ sót cảnh báo thật sự quan trọng. Mẹo: mỗi alert phải "actionable" (có thể hành động). Nếu nhận alert mà không biết phải làm gì, alert đó nên bị xóa hoặc gộp lại.
Lỗi 3 — Chỉ nhìn giá trị trung bình. Như đã nói, average che giấu nỗi đau ở phần đuôi. Mẹo: luôn yêu cầu dashboard hiển thị p95 và p99, không chỉ average.
Lỗi 4 — Log không có ngữ cảnh. Dòng log ghi "Lỗi xảy ra" mà không có orderId, userId hay traceId thì vô dụng khi điều tra. Mẹo: yêu cầu mọi log lỗi phải đính kèm đủ định danh để truy ngược.
Lỗi 5 — Log dữ liệu nhạy cảm. Như tình huống ngân hàng, vô tình log mật khẩu/OTP/thông tin cá nhân là rủi ro pháp lý lớn. Mẹo: lập danh sách trường cấm log và trường phải mask ngay từ spec.
Lỗi 6 — Giám sát hạ tầng mà quên trải nghiệm khách. Server xanh hết nhưng khách vẫn khổ. Mẹo: luôn có ít nhất một SLO phản ánh trực tiếp trải nghiệm người dùng cuối.
Mẹo bonus cho BA: Khi đọc dashboard, hãy tập thói quen hỏi "con số này so với hôm qua/tuần trước thế nào?" Một tỷ lệ lỗi 2% có thể bình thường, hoặc có thể là gấp đôi mức nền của ngày thường. Bối cảnh và xu hướng quan trọng hơn con số tuyệt đối.
Bài tập thực hành
Bài 1 — Phân loại ba trụ cột. Cho các nhu cầu sau, hãy xác định nên dùng Log, Metric hay Trace: (a) "Tôi muốn biết tỷ lệ lỗi của API thanh toán trong 24h qua"; (b) "Đơn hàng số 88213 bị lỗi, tôi cần biết chính xác nó hỏng ở khâu nào"; (c) "Một request cụ thể đi qua những service nào và mỗi chặng mất bao lâu".
Bài 2 — Thiết kế metric. Bạn là BA cho tính năng "đăng ký tài khoản qua API" của một fintech. Hãy liệt kê 3 metric kỹ thuật (gợi ý: RED) và 3 metric nghiệp vụ mà bạn muốn theo dõi.
Bài 3 — Viết quy tắc alert. Đề xuất một điều kiện cảnh báo cụ thể (có ngưỡng và khoảng thời gian) cho API đăng nhập, và xác định ai nên nhận cảnh báo này. Giải thích vì sao bạn chọn ngưỡng đó.
Bài 4 — Rà soát bảo mật log. Cho dòng log sau, hãy chỉ ra trường nào cần mask hoặc cấm log: {"event":"login","username":"an.nguyen","password":"abc123","otp":"884213","ip":"123.45.6.7"}.
Bài 5 — Định nghĩa SLO. Cho một app gọi xe, hãy đề xuất một SLO dựa trên trải nghiệm khách (gợi ý: thời gian tìm tài xế), kèm con số cụ thể và lý do nghiệp vụ đằng sau con số đó.
Tóm tắt
Observability là khả năng hiểu được hệ thống đang làm gì từ dữ liệu nó phát ra, và đó là kỹ năng nền tảng giúp BA viết spec "biết nói" khi vận hành thực tế. Hãy ghi nhớ:
- Monitoring theo dõi những điều đã biết cần quan tâm; observability giúp trả lời cả những câu hỏi bất ngờ chưa lường trước.
- Ba trụ cột: Logs (chuyện gì đã xảy ra), Metrics (đo lường bằng số, nhớ bộ RED: Rate-Errors-Duration), Traces (hành trình request qua các service).
- Luôn nhìn percentile (p95, p99) thay vì chỉ trung bình, vì trung bình che giấu nỗi đau ở phần đuôi.
- Alert phải actionable; cẩn thận alert fatigue.
- Cân bằng giữa độ chi tiết, chi phí lưu trữ và tuân thủ bảo mật — không log dữ liệu nhạy cảm.
- Định nghĩa SLO dựa trên trải nghiệm khách hàng, không chỉ giám sát hạ tầng "sống/chết".
- Mục tiêu cuối cùng là kéo MTTD và MTTR xuống thấp nhất — đây cũng là ngôn ngữ để bạn thuyết phục lãnh đạo đầu tư.