Chất lượng sản phẩm ở mức người dùng tin tưởng được
Đang thực hiệnAlliance App hiếm khi crash, hiếm khi chậm, và mỗi bản release không làm hỏng thứ đang chạy tốt — đúng ở mức quy mô 500.000 người dùng.
Kết quả cần đạt
- Tỷ lệ người dùng không gặp crash đạt từ 99,7% trở lên
- Thời gian khởi động nguội dưới 2 giây trên máy tầm trung
- Không có lỗi nghiêm trọng nào lọt ra bản release hai kỳ liên tiếp
- Không có sai lệch tiền nào trong module Bán hàng, dù chỉ một đồng
Vì sao mục tiêu này đứng đầu
Trên di động, người dùng không gửi báo lỗi — họ gỡ ứng dụng. Một lần crash lúc chốt đơn hay một màn hình trắng lúc mở app gây thiệt hại lớn hơn nhiều so với việc chậm ra mắt một tính năng. Vì vậy chất lượng được đặt làm ràng buộc: khi quỹ thời gian eo hẹp, ta cắt phạm vi tính năng, không cắt test.
Ở quy mô 500.000 người dùng, mọi tỷ lệ đều phải đọc ra số người. Crash-free 99,5% nghe có vẻ tốt cho tới lúc nhận ra nó là 2.500 người gặp crash. Đó là lý do ngưỡng ở đây là 99,7%, và vì sao con số này không được nới ra để một bản release kịp hạn. Xem quy mô 500.000 người dùng.
Cách đo
| Chỉ số | Ngưỡng đạt | Ngưỡng báo động | Đọc ra số người | Nguồn dữ liệu |
|---|---|---|---|---|
| Tỷ lệ người dùng không crash | ≥ 99,7% | < 99,5% | Báo động = 2.500 người | Công cụ giám sát crash |
| Tỷ lệ phiên bị ANR | ≤ 0,3% | > 0,47% | Ngưỡng xấu của cửa hàng | Bảng điều khiển cửa hàng |
| Thời gian khởi động nguội | ≤ 2,0 giây | > 3,0 giây | — | Máy thật, máy tầm trung |
| Tỷ lệ API trả lỗi 5xx | ≤ 0,5% | > 1% | — | Giám sát hạ tầng |
| Lỗi nghiêm trọng lọt ra bản release | 0 | ≥ 1 | — | Sổ theo dõi lỗi |
| Sai lệch đối soát tiền | 0 đồng | > 0 đồng | Luôn là sự cố P0 | Đối soát hằng ngày |
| Tỷ lệ luồng quan trọng có test tự động | ≥ 70% | < 50% | — | Báo cáo coverage |
Ngưỡng báo động không phải để phạt ai. Chạm ngưỡng thì việc sửa chất lượng được ưu tiên trước tính năng mới, cho tới khi chỉ số trở lại vùng an toàn. Chi tiết ngưỡng và cách đặt cảnh báo nằm ở quy tắc cảnh báo.
Dòng đối soát tiền là dòng duy nhất có dung sai bằng không. Một đồng lệch có thể là lỗi làm tròn vô hại, cũng có thể là dấu hiệu ghi nhận trùng đơn trên 500.000 người dùng — không phân biệt được từ xa, nên luôn xử lý như trường hợp xấu.
Việc cần làm để đạt
- Gắn công cụ giám sát crash và hiệu năng vào cả bản thử nghiệm lẫn bản release, tách số liệu theo từng phiên bản chứ không nhìn tổng.
- Lập đường cơ sở cho các chỉ số trên, biết hiện tại đang ở đâu trước khi đặt kỳ vọng.
- Áp dụng Definition of Done cho mọi hạng mục, không có ngoại lệ.
- Dựng test tự động cho các luồng quan trọng của cả ba module: gửi và nhận tin nhắn khi mạng chập chờn, giao việc và đổi trạng thái, tạo đơn và thanh toán.
- Dựng đối soát tự động hằng ngày cho Bán hàng, chạy độc lập với code tạo đơn.
- Đặt performance budget và để quality gate chặn khi vượt.
Điều dễ làm hỏng mục tiêu này
- Nhận thêm phạm vi vào giữa sprint mà không bỏ bớt thứ khác.
- Bỏ qua review vì "sửa có một dòng".
- Đo hiệu năng trên máy cao cấp của lập trình viên rồi kết luận là nhanh.
- Nới ngưỡng để một phép đo chuyển từ đỏ sang xanh. Ngưỡng chỉ đổi khi có lý do sản phẩm, ghi thành quyết định, không đổi vì một bản release đang gấp.
- Nhìn tỷ lệ mà không quy ra số người.