Production monitoring

QA không dừng ở ngày release

Mọi thứ trước release đều là phỏng đoán về hành vi thật: test trên một tập device, một tập dữ liệu, một tập kịch bản mà đội nghĩ ra được. Production là nơi duy nhất có đủ device, đủ mạng, đủ kiểu dữ liệu bẩn và đủ hành vi kỳ lạ của user thật.

Nói cách khác, production monitoring là stage cuối của QA, không phải công việc của một bộ phận khác.

Dashboard kỹ thuật

Chỉ số	Nguồn	Ngưỡng báo động
Crash-free sessions	Crash reporting	< 99,0%
ANR rate (Android)	Android vitals	> 0,35%
Hang / freeze (iOS)	Xcode Organizer, App Store Connect	Tăng so với release trước
Tỷ lệ lỗi API theo endpoint	Log phía server	> 1% trong 15 phút
API P95 theo endpoint	Log phía server	Vượt ngân sách của endpoint đó
Cold start	Android vitals, Xcode Organizer	Chậm hơn 10% so với release trước
Lỗi mạng phía client	Analytics	Tăng bất thường theo version
Tỷ lệ gửi push thất bại	Nhà cung cấp push	Tăng bất thường

Apple cung cấp dữ liệu crash và performance qua Xcode Organizer và App Store Connect; Google cung cấp qua Android vitals trong Play Console. Cả hai đều tách được theo app version và OS version — và đó chính là cách phải đọc.

Dashboard nghiệp vụ

Đây là phần hay bị bỏ, và là phần bắt được loại hỏng nguy hiểm nhất: app không crash, API không lỗi, nhưng user không làm được việc của họ.

Luồng	Chỉ số	Vì sao quan trọng
Đăng ký	Tỷ lệ hoàn tất	Bắt được lỗi OTP, lỗi validate quá chặt
Đăng nhập	Tỷ lệ thành công	Bắt được lỗi token, lỗi thời gian hệ thống
Chat	Tỷ lệ tin nhắn gửi thành công lần đầu	Bắt được lỗi socket, lỗi thứ tự
Task	Tỷ lệ tạo việc thành công	Bắt được lỗi phân quyền
Bán hàng	Tỷ lệ tạo đơn hoàn tất	Bắt được lỗi luồng, lỗi validate
Bán hàng	Tỷ lệ thanh toán thành công	Chỉ số quan trọng nhất của cả app

Ví dụ một release có dashboard kỹ thuật hoàn toàn bình thường:

Crash-free:     99,6%   bình thường
API error:      0,3%    bình thường
Payment success: 82% → 55%

Đây vẫn là một incident nghiêm trọng, và nếu chỉ nhìn dashboard kỹ thuật thì không ai biết cho tới khi bộ phận hỗ trợ bắt đầu nhận khiếu nại — thường là vài ngày sau.

Luôn nhìn theo version, đừng nhìn số tổng

Đây là sai lầm phổ biến nhất khi đọc dashboard. Sau khi rollout 10%, con số tổng gần như không nhúc nhích dù bản mới hỏng nặng, vì 90% user còn lại vẫn ổn.

Quy tắc: mọi chỉ số ở trên đều phải cắt được theo app version, và so sánh version mới với version liền trước trên cùng một khung thời gian. Chỉ số tổng dùng để báo cáo, không dùng để ra quyết định rollout.

24 giờ đầu sau mỗi lần mở rộng

Mỗi lần tăng tỷ lệ rollout, người trực nhìn đúng bốn thứ này, không nhìn tất cả:

1. Crash-free của version mới so với version trước.
2. Tỷ lệ lỗi của các API thuộc luồng vừa thay đổi.
3. Hai chỉ số nghiệp vụ quan trọng nhất: đăng nhập và thanh toán.
4. Đánh giá mới trên store và ticket mới của bộ phận hỗ trợ.

Xấu hơn version trước thì dừng mở rộng trước, tìm nguyên nhân sau. Dừng mở rộng là hành động rẻ và đảo ngược được; để chạy tiếp rồi mới điều tra thì không.

Ai nhìn và nhìn lúc nào

Nhịp	Ai	Làm gì
Hằng ngày, 10 phút	Người trực	Soát ngưỡng báo động, mở hạng mục nếu có gì vượt
Sau mỗi lần mở rộng rollout	Người cắt bản	Bốn thứ ở mục trên
Hằng tuần	Cả đội, trong buổi soát sức khoẻ hệ thống	Xu hướng, không nhìn từng điểm dữ liệu
Hằng tháng	Chủ kỹ thuật và chủ sản phẩm	API chậm dần, crash lặp lại, nợ tích tụ

Giới hạn

• Cảnh báo quá nhiều thì không ai đọc. Mỗi cảnh báo tự động phải kèm một hành động cụ thể cho người nhận. Không viết ra được hành động đó thì đừng dựng cảnh báo — đưa chỉ số vào bảng theo dõi hằng tuần là đủ.
• Dashboard không thay được việc đọc log khi điều tra. Nó cho biết có chuyện gì đó xảy ra, không cho biết vì sao.
• Chỉ số nghiệp vụ phụ thuộc vào analytics event được gắn đúng — xem Analytics event là một phần của yêu cầu. Event sai thì dashboard đẹp mà vô nghĩa.