Vì sao metric nền tảng dễ đo sai
PM sản phẩm cuối có DAU, doanh thu, retention rõ ràng. Platform PM dễ rơi vào bẫy đo 'số API call' hay 'uptime' rồi tưởng mình khỏe. Nhưng nền tảng có thể uptime 99.9% mà vẫn đang chết dần vì các đội âm thầm bỏ đi tự làm. Bạn phải đo sức khỏe adoption lẫn sức khỏe kỹ thuật.
Bốn nhóm chỉ số sức khỏe nền tảng
1. Adoption (nền tảng có được dùng không)
- Số đội đang tích hợp / tổng số đội đủ điều kiện.
- Tỷ lệ 'build-your-own' — bao nhiêu đội chọn tự làm thay vì dùng bạn. Đây là chỉ số phân mảnh quan trọng nhất.
- Time-to-integrate: từ lúc đội quyết định dùng đến lúc chạy production. Đo bằng ngày.
- Độ trễ p50/p95/p99 của inference.
- Tỷ lệ lỗi (error rate) theo đội.
- Tuân thủ SLA — % thời gian đạt cam kết.
- Điểm eval của mỗi model version qua thời gian.
- Drift: chênh lệch phân phối dữ liệu thực so với lúc huấn luyện.
- % traffic còn chạy trên version cũ (chỉ số nợ migration).
- Chi phí mỗi 1.000 request, tách theo đội.
- Tỷ lệ tận dụng hạ tầng (GPU utilization).
Khung tư duy: North Star + hàng rào
Chọn một North Star phản ánh giá trị nền tảng, ví dụ 'số đội chạy production trên nền tảng và ở lại sau 90 ngày'. Quanh nó đặt các chỉ số hàng rào (guardrail): p99 latency, error rate, chi phí/request — để việc chạy theo adoption không vô tình phá vỡ độ tin cậy hay đội chi phí lên.
Ví dụ cụ thể
Nền tảng báo cáo 2 triệu request/ngày, sếp hài lòng. Nhưng bạn xẻ nhỏ: 90% traffic đến từ một đội, ba đội mới đã lặng lẽ dựng embedding riêng vì time-to-integrate của bạn là 6 tuần. North Star 'số đội ở lại' của bạn thực chất đang giảm. Con số tổng lớn che giấu bệnh phân mảnh.
Sai lầm thường gặp
- Đo tổng volume thay vì phân bố theo đội → che giấu việc phụ thuộc một đội và sự rời bỏ của các đội khác.
- Chỉ đo kỹ thuật (uptime, latency), bỏ qua adoption → nền tảng 'khỏe' nhưng đang mất khách nội bộ.
- Không đo % traffic trên version cũ → nợ migration lớn dần vô hình.
- Không tách chi phí theo đội → không ai chịu trách nhiệm chi phí, hạ tầng phình ra.
Checklist bảng chỉ số
- [ ] Có đúng một North Star phản ánh giá trị nền tảng (không phải volume thuần).
- [ ] Adoption được xẻ theo đội, có theo dõi tỷ lệ 'build-your-own'.
- [ ] Có guardrail cho latency, error rate và chi phí/request.
- [ ] Có chỉ số % traffic trên version deprecated (nợ migration).
- [ ] Chi phí được phân bổ về từng đội tiêu thụ.
Nhịp báo cáo và ngưỡng cảnh báo
Metric chỉ có giá trị khi gắn với hành động. Với mỗi chỉ số hàng rào, đặt một ngưỡng cảnh báo và một chủ sở hữu: ví dụ p99 vượt 200ms trong 10 phút thì báo đội serving; error rate của một đội vượt 1% thì mở điều tra; % traffic trên version deprecated không giảm sau 30 ngày thì kích hoạt chương trình migrate chủ động. Duy trì một nhịp báo cáo đều đặn (hằng tuần cho vận hành, hằng quý cho lãnh đạo) và luôn xẻ số liệu theo đội, không chỉ nhìn tổng. Cách này biến bảng chỉ số từ một tấm bảng trang trí thành hệ thần kinh của nền tảng: bạn cảm nhận được vấn đề sớm và biết chính xác ai cần hành động.
Một bảng chỉ số tốt giúp bạn phát hiện bệnh phân mảnh trước khi nó thành khủng hoảng, và kể câu chuyện sức khỏe nền tảng bằng dữ liệu khi xin nguồn lực.