Production Readiness Review #28

Trả lời ngắn: Production Readiness Review là review có cấu trúc trước khi mở AI capability cho production, dựa trên evidence về problem, design, quality, safety, security, reliability, operations, people và rollback. Kết quả không chỉ là go/no-go; đó là PASS, HOLD hoặc BLOCKED kèm owner, exception, mitigation và thời hạn.

Đọc xong, bạn sẽ hiểu:

• Readiness review khác checklist launch hoặc dashboard xanh ở đâu.
• Các dimension và evidence packet nào cần nối với nhau.
• Cách xử lý open risk, exception, rehearsal, rollback và freshness.
• Cách thực hành một scorecard 15 phút có decision rõ.

Lưu ý giáo dục: Case, IDs, metrics và evidence trong bài là synthetic. Không đưa credential, customer data, private prompt hoặc live secret vào bài tập. Readiness thật cần reviewer độc lập phù hợp với risk, privacy, security, legal và policy của tổ chức.

1. Production readiness review hỏi gì?

Một prototype trả lời tốt chưa phải production-ready. Readiness review là review có cấu trúc trước khi mở capability cho production. Nó hỏi: problem còn đúng không, boundary có rõ không, quality/safety có evidence không, owner/on-call đã nhận chưa, incident/rollback có diễn tập chưa, và evidence có fresh đúng scope/version không?

Evidence packet là gói tài liệu, report, trace, risk record, runbook và sign-off liên quan đến một decision. Gate là điều kiện quyết định PASS, HOLD hoặc BLOCKED. PASS không có nghĩa zero risk; nó nói gate hiện tại có đủ evidence và owner. HOLD nghĩa còn việc cần làm hoặc evidence chưa đủ. BLOCKED nghĩa một requirement bắt buộc fail, như safety floor hoặc rollback không tồn tại.

Hình 1 — Readiness gate không nhìn một metric; nhiều dimension phải hội tụ vào quyết định có owner.

Reviewer nên đọc evidence theo scope và freshness. Report của bundle B-28 không chứng minh bundle B-29; eval tuần trước không tự chứng minh policy hôm nay. Mỗi evidence có source, version, timestamp, owner và limitation.

2. Readiness dimensions và evidence

Một review nên dùng dimension đủ rộng nhưng có thể truy ra artifact. Với support copilot READY-28, sáu dimension sau tạo packet:

Freshness là mức evidence còn phản ánh trạng thái hiện tại. Evidence stale cần re-run hoặc ghi limitation. Operational readiness là mức owner, runbook, alert, support và on-call đã sẵn sàng; có service endpoint không đồng nghĩa có người biết xử lý khi nó đỏ.

Hình 2 — Evidence packet tốt nối artifact và live signal; reviewer nhìn thấy gap thay vì nhận một folder rời.

Review cũng cần độc lập vừa đủ. Người build có thể giải thích implementation nhưng không nên một mình ký high-impact safety hoặc rollback readiness. Separation không cần cứng cho mọi low-risk change; nó cần theo risk và decision right.

3. Walkthrough case support copilot

Case READY-28 route support request, retrieve policy, suggest queue và handoff high-impact. Packet có design DOC-28, harness report EVAL-28, risk register RISK-28, runbook RB-28, trace sample TRC-28 và canary plan CAN-28.

Điểm quan trọng: quality và safety pass không tự xóa operations gap. Reviewer không “trung bình hóa” các dimension để ra 87%. Readiness là conjunction có constraint: một số floor không được bù bởi điểm khác. HOLD ở rollback có thể nhỏ hơn BLOCKED ở privacy, nhưng cả hai đều ngăn go-live theo rule đã định.

Evidence graph và open risk

Reviewer nối từng claim với evidence: “high-impact handoff hoạt động” → case IDs, policy, trace, human decision; “rollback được” → bundle, config, runbook, rehearsal result; “owner trực” → acknowledgement và escalation path. Nếu node thiếu, ghi EVIDENCE_GAP-28-01, owner và next action.

Dependency cũng phải hiện: retrieval index freshness, provider behavior, quota, data retention, human capacity và alert route. Exception không được biến dependency thành chữ nhỏ ở cuối document.

4. Gate, exception và go/no-go decision

Gate decision cần rule trước khi xem candidate:

1. PASS: bắt buộc evidence đủ, quality/safety floor đạt, owner nhận, rollback/recovery có proof.
2. HOLD: gap có thể sửa trước mốc, owner và deadline rõ, không mở traffic rộng.
3. BLOCKED: requirement critical fail, risk không có control, privacy/security/safety breach hoặc rollback không tồn tại.

Exception là lệch chuẩn được phê duyệt có mitigation và expiry. Ví dụ low-risk dashboard cosmetic chưa mobile-perfect có thể exception bởi owner đến ngày cụ thể; high-impact handoff thiếu test không nên exception chỉ vì deadline. Exception record cần reason, scope, risk, mitigation, approver, expiry, monitoring và revoke condition.

Hình 3 — Dimension matrix buộc reviewer ghi evidence, freshness, owner và status thay vì chỉ tô màu.

Rehearsal là diễn tập rollback, incident, human handoff hoặc recovery trước live. Một runbook chưa chạy là kế hoạch, không phải evidence. Rollback rehearsal cần biết artifact nào, thao tác nào, data/cache nào bị ảnh hưởng và metric nào verify. Nếu rehearsal fail, gate BLOCKED hoặc HOLD tùy risk rule.

Cách reviewer đi từ claim đến quyết định

Reviewer có thể đi theo một vòng ngắn, lặp lại được thay vì đọc một deck dài rồi bỏ phiếu theo cảm giác:

1. Chốt scope: ghi bundle/version, traffic slice, user type, environment và thời điểm review. Nếu capability đã đổi sau khi packet được đóng, đó là change cần re-review.
2. Đọc claim trước artifact: với mỗi claim như “handoff high-impact an toàn”, hỏi pass condition là gì và case nào đại diện cho claim đó. Một link đến dashboard không đủ nếu không có filter, thời gian và sample.
3. Kiểm tra đường nối: mở từ claim sang test case, report, trace, owner và runbook. Nếu phải đoán artifact nào chứng minh claim, ghi evidence gap thay vì tự điền vào khoảng trống.
4. Tách floor khỏi điểm cộng: quality average, latency đẹp hoặc một canary xanh không bù cho privacy breach, safety control thiếu hoặc rollback chưa từng thử. Những floor này phải có rule riêng trong decision matrix.
5. Ghi trạng thái và hành động: PASS cần evidence và owner; HOLD cần next action, deadline và điều kiện mở lại; BLOCKED cần nêu requirement fail, risk và người có quyền gỡ block.

Ví dụ, packet có 98% answer quality nhưng chỉ có test redaction ở staging. Reviewer không biến 98% thành READY; họ ghi quality PASS, privacy HOLD hoặc BLOCKED tùy policy, owner là người phụ trách data control, và yêu cầu thêm evidence trước khi mở traffic. Cách ghi theo dimension giúp team sửa đúng gap, đồng thời giữ được bằng chứng rằng quyết định không dựa trên một con số tổng hợp.

Sign-off là xác nhận của người có quyền sau khi đã xem decision packet; nó không phải chữ ký thay thế evidence. Sign-off nên chỉ rõ decision, scope, version, exception đang chấp nhận, expiry và trigger thu hồi. Khi một finding hết hạn hoặc bundle đổi, sign-off cũ không được tự động kéo sang release mới.

Canary cho phép mở traffic nhỏ trong thời gian/segment giới hạn. High-impact slice phải monitor riêng. Recovery gate kiểm quality, safety, latency, trace completeness, alert, owner acknowledgement và communication. Chỉ sau gate mới mở rộng.

Hình 4 — Exception và rehearsal chỉ có giá trị khi có expiry, mitigation, approver và recovery evidence.

5. Sai lầm, giới hạn và fallback

• Checklist theater: tick hết nhưng link evidence trống. Fallback: claim-to-evidence map và reviewer sampling.
• Green dashboard: latency xanh che safety/quality slice. Fallback: dimension floors, high-impact cases và freshness.
• Stale evidence: report cũ dùng cho bundle/policy mới. Fallback: version/date check và re-run.
• Deadline override: “ship hôm nay” làm mất gate. Fallback: decision owner, explicit exception hoặc block.
• No owner: open risk có nhưng không ai nhận. Fallback: assign owner/escalation trước gate.
• Missing rehearsal: runbook đẹp nhưng chưa thử rollback. Fallback: bounded rehearsal và recovery proof.
• Scope drift: review thêm feature ngoài design. Fallback: change request và scope freeze.
• Score averaging: critical fail bị điểm dimension khác bù. Fallback: non-compensatory safety/rollback floors.

Readiness review có giới hạn. Không thể mô phỏng mọi traffic, provider drift hoặc human behavior; evidence có sample bias; reviewer có thể bỏ qua rare failure; “ready” chỉ đúng tại scope/time/version đã ghi. Vì vậy packet cần last-reviewed, limitation, monitor plan và trigger mở lại review.

Azure AI architecture và observability đặt reliability, security, performance và operational feedback trong design/runtime; OpenAI Agents guide cung cấp context về tools, guardrails, state và tracing. Các nguồn định hướng câu hỏi, không thay thế test/live evidence của capability. Azure AI architecture, Azure AI observability và OpenAI Agents guide

6. Practice Bridge 15 phút

Mở Notes hoặc Google Sheets miễn phí. Tạo cột dimension, claim, evidence, version, freshness, owner, status, gap, next_action, expiry. Dùng capability synthetic.

Mẫu đối chiếu đã điền

Trong 15 phút, thêm một claim, evidence version, owner, freshness và expiry. Stop condition: nếu không biết evidence nào đủ để go/no-go hoặc ai có quyền sign-off, giữ HOLD và mở gap record.

Một cách chấm nhanh là dùng ba cột riêng thay vì một điểm tổng: evidence completeness, risk control và operational ownership. Với mỗi dimension, đánh dấu đủ, thiếu hoặc không áp dụng rồi ghi lý do. “Không áp dụng” cũng cần người xác nhận; nếu không, đó chỉ là cách né một câu hỏi khó. Sau đó chọn một finding có tác động lớn nhất và viết lại thành câu có thể kiểm: “Ai sẽ làm gì, trên bundle nào, trước thời điểm nào, và bằng report nào chứng minh?”

Ví dụ scorecard của READY-28 có thể ghi: quality đủ evidence ở EVAL-28, safety đủ evidence nhưng vẫn giữ human gate, operations thiếu rehearsal, live thiếu acknowledgement. Decision là HOLD, không mở rộng traffic; next action là chạy rollback rehearsal trong môi trường cô lập và lấy acknowledgement của on-call. Khi hai artifact đó được cập nhật, reviewer kiểm lại freshness và quyết định lại. Bài tập như vậy biến Practice Bridge thành một bản ghi hành động nhỏ, không phải danh sách thuật ngữ để học thuộc.

7. Tổng kết: readiness là quyết định có điều kiện

a. Năm ý chính

• Readiness review là decision dựa trên evidence, không phải checklist hoặc dashboard đơn lẻ.
• Dimensions gồm design/product, quality/eval, safety/security, reliability, operations/people và data/legal.
• Evidence packet phải có source, version, timestamp, freshness, owner, limitation và claim link.
• PASS/HOLD/BLOCKED, exception, rehearsal, canary và rollback cần rule, approver, expiry hoặc recovery proof.
• Capability chỉ ready trong scope/time/version đã kiểm; evidence stale hoặc critical gap phải mở lại review.

b. Câu hỏi tự kiểm tra

• Vì sao quality pass không tự xóa operations gap?
• Evidence packet cần metadata nào?
• Exception khác bỏ qua requirement thế nào?
• Khi nào readiness phải BLOCKED?

c. Gợi ý đáp án

Xem gợi ý câu 1

Operations có owner, alert, runbook và rollback riêng; quality pass không chứng minh những thứ đó. Xem lại mục 2 và mục 3.

Xem gợi ý câu 2

Source, version, timestamp, freshness, owner, scope và limitation giúp reviewer biết evidence còn đúng không. Xem lại mục 2 và mục 3.

Xem gợi ý câu 3

Exception là lệch chuẩn được phê duyệt, có mitigation, expiry, approver và revoke condition; không phải xóa requirement. Xem lại mục 4.

Xem gợi ý câu 4

Block khi safety/privacy/security critical fail, control/rollback thiếu hoặc evidence không đủ theo rule bắt buộc. Xem lại mục 4 và mục 5.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• Azure AI architecture patterns — reliability, security, performance và operations.
• Azure AI observability — signals, monitoring và feedback.
• OpenAI Agents guide — tools, guardrails, state và tracing.
• NIST AI RMF Core — risk management theo vòng đời.

Bài trước là Xây Safety và Failure-mode Register #27. Bài tiếp theo là AI Governance và Responsible Deployment #29.

Lưu ý giáo dục: Không dùng deadline hoặc dashboard để lấp critical evidence gap. Nếu rollback, safety owner, freshness hoặc live recovery chưa đủ, quyết định chuyên nghiệp là HOLD/BLOCKED.