Yêu cầu báo cáo và điều kiện kỹ thuật đi kèm

Chỗ đứng của bài này

Ba bài đã có mô tả cái gì phải nhìn. Bài này mô tả thứ đội phải dựng để nhìn được.

Bài	Trả lời câu hỏi nào
Production monitoring	Dashboard gồm chỉ số nào, ai mở, mở lúc nào
Quy tắc cảnh báo	Ngưỡng nào thì tự đánh thức người
Mẫu báo cáo tuần	Báo cáo trình bày ra sao
Bài này	Phải gắn sẵn thứ gì để ba bài trên có số thật, và ai chuẩn bị

Một luật lọc trước khi đọc danh sách

Số phải tự chảy ra. Mẫu báo cáo tuần đặt luật: một trường phải hỏi người mới có số thì thứ cần sửa là thiếu dashboard, không phải bỏ trường đó khỏi báo cáo.

Công cụ đo đã gắn
crash reporting, analytics, CI, log gom về một chỗ
Dashboard cắt được theo app version
kỹ thuật và nghiệp vụ, hai cái tách nhau
Báo cáo lấy số từ dashboard
người chỉ viết phần nhận định
Quyết định
mở tiếp rollout, dừng, hay cắt phạm vi
Đứt ở mắt xích đầu
báo cáo thành bảng điền tay, và số điền tay thì không ai dám dùng để dừng một bản release

Luật thứ hai, từ Quality metrics: một chỉ số chỉ được vào báo cáo khi trả lời được khi nó đi sai hướng, ai làm gì. Không trả lời được thì bỏ. Dashboard năm mươi chỉ số là dashboard không ai mở.

Sáu nhịp báo cáo

Ai đọc

Quyết định nó phục vụ

Hằng ngày, 10 phút

Người trực

Có mở hạng mục sự cố không

Sau mỗi nấc rollout

Người cắt bản, quản lý dự án

Mở tiếp hay dừng

Hằng tuần, chiều thứ Sáu

Quản lý dự án, lãnh đạo

Có cần can thiệp từ ngoài đội không

Mỗi release

Quản lý dự án, chủ kỹ thuật

Có phải siết quality gate không

Hằng tháng

Quản lý dự án, chủ kỹ thuật

Có dừng làm tính năng để trả nợ không

Hằng quý

Quản lý dự án, chủ sản phẩm

Mua máy nào, cắt OS nào, chỉnh mục tiêu gì

Nhịp hằng ngày để ở đây cho đủ vòng, nhưng quản lý dự án không đọc nó. Đó là việc của người trực theo lịch on-call. Cảnh báo phải trỏ tới một người cụ thể đang trực, không trỏ vào nhóm chat.

1. Hằng ngày — người trực soát ngưỡng

Mục	Số lấy từ đâu	Cần dựng gì
Crash-free sessions, ANR	Play Console, App Store Connect	Đã có sẵn, chỉ cần cấp quyền xem
Tỷ lệ lỗi API theo endpoint	Log server	Log gom về một chỗ, cắt được theo endpoint
Đăng nhập và thanh toán thành công	Analytics	Event của hai luồng này bắn đúng
Cảnh báo đã kêu trong 24h	Hệ cảnh báo	Ngưỡng đã cấu hình, có nơi xem lại lịch sử

2. Sau mỗi nấc rollout — báo cáo đắt nhất

Đúng bốn thứ, theo Production monitoring. Không nhiều hơn, vì đây là lúc phải quyết trong vài giờ.

Crash-free của version mới so với version liền trước
So trên cùng khung thời gian. Số tổng dùng để báo cáo, không dùng để quyết định rollout
Tỷ lệ lỗi của các API thuộc luồng vừa thay đổi
Chỉ những endpoint đã đụng, không phải cả hệ thống
Hai chỉ số nghiệp vụ, đăng nhập và thanh toán
Loại hỏng nguy hiểm nhất không làm app crash
Đánh giá mới trên store và ticket hỗ trợ mới
Kênh duy nhất bắt được thứ chưa ai gắn đo

Cần dựng gì: mọi chỉ số trên phải cắt được theo app version. Sau khi rollout 10%, số tổng gần như không nhúc nhích dù bản mới hỏng nặng, vì 90% người dùng còn lại vẫn ổn. Đây là sai lầm phổ biến nhất khi đọc dashboard.

Kèm theo là bảng trạng thái feature flag: cờ nào đang bật, bật cho bao nhiêu phần trăm, ai bật, lúc mấy giờ. Không có bảng đó thì khi số xấu đi, không ai nối được nguyên nhân với thời điểm — xem Release từng phần và feature flag.

3. Hằng tuần — một trang, chiều thứ Sáu

Mẫu đã có sẵn ở Mẫu báo cáo tuần, không thiết kế lại. Phần cần đội chuẩn bị là nguồn số cho ba mục:

Mục trong mẫu	Số lấy từ đâu	Cần dựng gì
Đã xong tuần này	Bảng công việc, lọc theo Definition of Done	Trạng thái "xong" trên bảng công việc phải đúng nghĩa DoD, không phải "đã merge"
Đã release, phần trăm đang bật	Bảng feature flag	Bảng trạng thái cờ ở mục trên
Năm dòng chỉ số chất lượng	Dashboard	Dashboard kỹ thuật và nghiệp vụ, cắt theo version

Thêm một mục không có trong mẫu, chỉ áp dụng cho tuần đầu sau khi release một luồng mới: funnel của luồng đó. Năm event tối thiểu tạo ra một bảng đọc được ngay người dùng rớt ở bước nào — xem Analytics event là một phần của yêu cầu.

4. Mỗi release — chất lượng bản vừa ra

Mục	Số lấy từ đâu	Cần dựng gì
Số bug production của bản này	Sổ bug	Trường "phát hiện trước hay sau release" và trường "version" trong phiếu lỗi
Tỷ lệ pass của bộ regression	CI	CI xuất được kết quả theo lần chạy, không chỉ hiện xanh đỏ
Cold start P95 trên máy Tier 1	Automation trên máy thật	Máy Tier 1 có thật, và có bài đo chạy định kỳ trên nó
Kích thước bản tải về	Bảng điều khiển store	Đã có sẵn
Waiver đã ký trong bản này	Checklist trước release	Chỗ lưu waiver có tên người ký

5. Hằng tháng — xu hướng, không phải điểm dữ liệu

Mục	Vì sao đáng đọc
Defect leakage	Chỉ số tổng hợp tốt nhất cho shift left. Giá trị tuyệt đối vô nghĩa, xu hướng mới có nghĩa
Flaky test rate và khu cách ly	Tác hại không nằm ở bài test hỏng, nó nằm ở chỗ dạy cả đội thói quen bỏ qua tín hiệu đỏ
Thời gian phản hồi của CI	Pipeline chạy bốn mươi phút không phải quality gate, nó là thứ người ta học cách né
Ngân sách lỗi đã tiêu	Tiêu hết trước khi hết tháng là tín hiệu dừng nhận tính năng mới
Danh sách cờ còn sống	Trên mười lăm cờ cùng lúc là dấu hiệu mất kiểm soát
Soát lại danh sách cảnh báo	Cái nào chưa bao giờ kêu, cái nào kêu suốt
Root cause analysis của sự cố trong tháng	Mỗi sự cố phải kết thúc bằng một thay đổi cơ chế

6. Hằng quý — chỉnh chính sách theo số thật

Mục	Cần dựng gì
Đối chiếu mục tiêu quý	Số của các báo cáo tuần, không viết lại từ đầu
Phân bố thiết bị và OS của người dùng thật	Kết xuất từ Play Console và App Store Connect
Cập nhật device matrix và ngưỡng cắt OS	Trừ phân bố người dùng thật cho danh sách máy đội đang có
Soát lại danh sách mười hai chỉ số	Chỉ số nào ba quý liền không dẫn tới hành động nào thì bỏ

Điều kiện kỹ thuật — danh sách đi làm việc với đội

Đây là phần chủ kỹ thuật chia việc. Mỗi mục trả lời: đã có chưa, ai làm, bao giờ xong.

A. Analytics event theo chuẩn

Mỗi luồng tối thiểu năm event, và trạng thái thất bại phải tách khỏi trạng thái người dùng tự huỷ — gộp lại thì không phân biệt được app hỏng với người dùng đổi ý. Mọi event gửi kèm app version, platform, OS version, device model, lớp RAM, session id.

Chặn báo cáo nhịp 2, 3, 5
Kiểm chứng trên build thật, không chỉ đúng trong code
Cấm gửi nội dung tin nhắn, thông tin cá nhân, số thẻ, token

B. Hai dashboard tách nhau

Dashboard kỹ thuật gần như có sẵn từ Play Console và App Store Connect. Phần thiếu là dashboard nghiệp vụ — tỷ lệ hoàn tất của các luồng chính. Đây là phần hay bị bỏ, và là phần bắt được loại hỏng app không crash mà người dùng vẫn không làm được việc.

Chặn báo cáo nhịp 1, 2, 3
Mọi chỉ số cắt được theo app version
Mở được từ điện thoại, sự cố không chờ ai về tới bàn

C. Cảnh báo có ngưỡng và có người nhận

Ngưỡng theo từng module đã liệt kê ở quy tắc cảnh báo. Mỗi cảnh báo hiển thị cả tỷ lệ và số người bị ảnh hưởng — người trực lúc ba giờ sáng không nên phải tự nhân nhẩm.

Chặn báo cáo nhịp 1, 5
Ba mức, chỉ mức nghiêm trọng mới đánh thức người
Trỏ tới một người đang trực, không trỏ vào nhóm chat

D. Bảng trạng thái feature flag

Cờ nào đang bật, bao nhiêu phần trăm, ai bật, lúc nào. Đây là thứ nối số liệu xấu với nguyên nhân.

Chặn báo cáo nhịp 2, 3, 5
Mỗi cờ có chủ và ngày hết hạn ghi ngay lúc tạo
Tắt được trong ba mươi giây, người trực biết cách tắt

E. Kiểm kê thiết bị test

Danh sách máy đang rỗng. Mười hai trường bắt buộc, mỗi máy khoảng hai phút — chi tiết ở bản yêu cầu kiểm kê.

Chặn báo cáo nhịp 4, 6
Không có máy Tier 1 chỉ đích danh thì mốc cold start là con số trên giấy
Không có device model trong event thì crash 0,3% không đọc ra hành động

F. Automation đo hiệu năng trên máy thật

Chạy định kỳ trên máy Tier 1, build release, lấy P95, đo lặp lại — bốn quy tắc ở performance budget, vi phạm một cái là số đo mất giá trị.

Chặn báo cáo nhịp 4, 5
Đo baseline trước, đừng bịa ngưỡng
Cảnh báo khi chậm hơn bản trước quá mười phần trăm, kể cả khi vẫn trong ngân sách

G. CI xuất được số

Pass rate, flaky rate, thời gian phản hồi, coverage trên code mới. CI hiện chặn được build, nhưng chặn được và báo cáo được là hai việc khác nhau.

Chặn báo cáo nhịp 4, 5
Các cổng chặn đã mô tả ở quality gate tự động
Số phải xuất được theo từng lần chạy, không chỉ hiện xanh đỏ

H. Sổ bug và sổ sự cố có trường phân loại

Phiếu lỗi cần trường version, severity, và phát hiện trước hay sau release. Thiếu trường cuối thì không tính được defect leakage.

Chặn báo cáo nhịp 4, 5
Mẫu phiếu đã có ở bug report template
Mã máy trong phiếu lỗi lấy từ kiểm kê thiết bị ở mục E

Thứ tự dựng

Yêu cầu cả tám mục cùng lúc thì sẽ nhận về một bảng gõ tay. Ba đợt, xếp theo chi phí chia cho thứ nó mở khoá.

Đợt một, gần như miễn phí và mở khoá nhiều nhất
Mục E kiểm kê thiết bị, mục D bảng trạng thái cờ, mục H thêm trường phân loại vào sổ bug. Ba thứ này không cần viết code sản phẩm, làm xong trong tuần, và mở khoá được nhịp báo cáo 4 với 6
Đợt hai, chặn nhiều nhất nên phải làm sớm
Mục A analytics event và mục B dashboard nghiệp vụ. Đây là thứ tốn công thật, nhưng không có nó thì nhịp 2 và nhịp 3 không có số nghiệp vụ nào — mà nhịp 2 là quyết định đắt nhất của quản lý dự án
Đợt ba, sau khi đã có dữ liệu chạy vài tuần
Mục C cảnh báo, mục F automation hiệu năng, mục G số từ CI. Ba thứ này cần baseline mới đặt ngưỡng được. Đặt ngưỡng trước khi có baseline thì hoặc quá lỏng nên vô dụng, hoặc quá chặt nên bị tắt sau hai tuần

Trong lúc chờ ba đợt, báo cáo tuần vẫn gửi đủ mỗi tuần, phần chỉ số để trống rồi điền dần. Ô trống trong báo cáo cũng là một thông tin — nó cho thấy đội đang mù chỗ nào.

Bốn thứ không yêu cầu

Thêm một luật từ Quality metrics: chỉ số không gắn lên đầu người. Khi một con số thành thước đo đánh giá cá nhân, nó ngừng đo cái nó định đo — đội sẽ tối ưu con số chứ không tối ưu chất lượng. Ví dụ dễ thấy nhất là ép code coverage, kết quả là hàng loạt bài test không kiểm tra gì.

Luật viết số ở quy mô này

5.000 người

đứng sau con số "1% lỗi API"

2.500 người

đứng sau "0,5% nâng cấp thất bại"

500 đơn sai

đứng sau "0,1% đơn trùng"

Mọi lỗi báo kèm số người, không chỉ báo tỷ lệ — luật này áp cho cả cảnh báo, báo cáo tuần và báo cáo sự cố. Chi tiết ở Chất lượng ở quy mô 500.000 người dùng.

Cách trả lời bản yêu cầu này

Mỗi mục từ A tới H trả lời đúng một dòng:

B. Dashboard nghiệp vụ — CHƯA CÓ — chủ module Bán hàng — xong 30/09
E. Kiểm kê thiết bị — ĐÃ CÓ — <đường dẫn mở được>

Dòng ghi "đã có" mà không kèm đường dẫn mở được thì tính là chưa có. Đây không phải sự nghi ngờ — Mẫu báo cáo tuần đã đặt luật rằng số phải tự chảy ra; một dashboard chỉ một người mở được thì mỗi tuần vẫn phải đi hỏi người đó, và tới tuần người đó nghỉ thì báo cáo đứt.

Giới hạn

Danh sách này giả định mục tiêu là quan sát được app, không phải đánh giá đội. Hai mục đích đó dẫn tới hai bộ chỉ số khác nhau, và trộn chúng lại thì bộ thứ nhất hỏng.
Vài chỉ số cần vài tháng dữ liệu mới đọc được xu hướng. Đừng ra quyết định lớn dựa trên bốn tuần đầu.
Analytics luôn có sai số: chặn quảng cáo, mất mạng, app bị tắt trước khi kịp gửi. Dùng để so sánh tương đối giữa các version, đừng dùng làm con số tuyệt đối đối chiếu với kế toán.
Bài này không thay Production monitoring và Quy tắc cảnh báo. Ngưỡng cụ thể nằm ở hai bài đó, không lặp lại ở đây để tránh có hai bản chân lý.