Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn là một Site Reliability Engineer tại một fintech ở TP.HCM. Team sản phẩm vừa xây xong một service mới — "payment-orchestrator" — chịu trách nhiệm điều phối các giao dịch chuyển tiền. Code đã chạy tốt trên môi trường staging suốt hai tuần, demo mượt mà, sếp gật gù. Đội dev háo hức muốn đẩy lên production ngay trong sprint này.
Nhưng khoan. Service này có được cấu hình alert chưa? Nếu nó chết lúc 2 giờ sáng, ai được đánh thức và họ sẽ làm gì? Có runbook không? Nếu database quá tải, service có degrade một cách có kiểm soát hay sập luôn kéo theo cả hệ thống? Backup đã được kiểm chứng khôi phục được chưa? Ai là service owner khi có sự cố?
Nếu không ai trả lời được những câu hỏi này, việc lên production giống như cho một chiếc xe chưa có phanh, chưa có đèn, chưa đăng kiểm chạy ra cao tốc. Nó có thể chạy tốt trong 90% thời gian, nhưng 10% còn lại sẽ là thảm họa — và với fintech, thảm họa nghĩa là mất tiền thật của khách hàng và mất giấy phép.
Production Readiness Review (PRR) chính là cái "cửa đăng kiểm" đó. Nó là một quy trình review có cấu trúc, diễn ra trước khi một service mới (hoặc một service có thay đổi lớn) được đưa vào production, nhằm đảm bảo service đó có đủ năng lực vận hành (ops capability) để tồn tại và được vận hành bền vững trong môi trường thật. PRR là nơi ranh giới giữa "code chạy được" và "hệ thống vận hành được" được vẽ ra rõ ràng.
Trong bài này, chúng ta sẽ đi sâu vào bản chất của PRR, một checklist tiêu biểu, và cách bạn tự tổ chức một buổi PRR thực tế cho team của mình.
Khái niệm cốt lõi
PRR là một cái "gate", không phải một tờ giấy
Nhiều người hiểu nhầm PRR chỉ là một biểu mẫu để tick vào ô. Sai. PRR là một quality gate — một điểm chốt trong vòng đời của service, nơi một nhóm người có kinh nghiệm (thường là SRE hoặc Platform team) ngồi lại cùng đội dev để đánh giá một cách nghiêm túc: "Service này đã sẵn sàng gánh tải thật, tiền thật, khách hàng thật chưa?".
Kết quả của PRR không phải là "pass/fail" khô khan mà thường là một trong ba trạng thái:
- Go: đủ điều kiện, lên production.
- Go with conditions: được lên nhưng phải khắc phục một số điểm trong thời hạn cam kết (ví dụ trong 30 ngày).
- No-go: chưa đủ, phải làm lại các phần thiết yếu trước khi review lại.
PRR khác gì với code review và testing?
Đây là điểm học viên hay lẫn lộn. Code review kiểm tra chất lượng mã nguồn. Testing (bài 14 nói về load testing) kiểm tra service có chạy đúng chức năng và chịu tải không. Còn PRR kiểm tra một tầng khác hẳn: khả năng vận hành khi có sự cố.
Một service có thể có code sạch tinh, test coverage 95%, load test đạt 10.000 RPS — nhưng vẫn trượt PRR vì: không có dashboard để nhìn thấy nó đang sống hay chết, không có ai được assign làm owner, và khi nó chết thì logs bị nuốt mất không ai truy được. PRR nhìn service qua con mắt của người phải vận hành nó lúc 3 giờ sáng, không phải con mắt của người viết ra nó.
Checklist tiêu biểu của một PRR
Một PRR tốt xoay quanh các trụ cột sau. Đây không phải danh sách cứng, mỗi tổ chức sẽ điều chỉnh, nhưng đây là khung chuẩn.
1. Observability (Khả năng quan sát)
- Service có expose metrics theo 4 Golden Signals (latency, traffic, errors, saturation) chưa?
- Có dashboard tổng quan để người on-call nhìn một cái là biết tình trạng?
- Logs có được structured (JSON) và đẩy về hệ thống aggregation tập trung chưa?
- Có trace ID lan truyền qua các service để debug các luồng phân tán?
- Có alert dựa trên SLO (không phải alert nhiễu dựa trên CPU đơn thuần)?
- Mỗi alert có runbook đi kèm và có "actionable" — tức người nhận biết phải làm gì?
- Đã cấu hình routing đúng người, đúng kênh (PagerDuty, Opsgenie, Telegram)?
- Ai là service owner? Có một team chịu trách nhiệm rõ ràng, không mồ côi?
- Đã có rotation on-call và những người trực đã được onboard chưa?
- Escalation path rõ ràng: nếu người trực cấp 1 không xử lý được thì gọi ai?
- Có runbook cho các sự cố phổ biến (service không phản hồi, database đầy, dependency chết)?
- Có sơ đồ kiến trúc và danh sách dependency (upstream/downstream)?
- SLO đã được định nghĩa và các bên đồng thuận chưa?
- Service xử lý thế nào khi dependency chết? Có circuit breaker, retry với backoff, timeout hợp lý không?
- Khi quá tải, service degrade có kiểm soát (graceful degradation) hay sập cứng?
- Đã ước lượng tải kỳ vọng và có headroom chưa?
- Auto-scaling đã cấu hình và test chưa? Giới hạn trên (max) là bao nhiêu để không "cháy" hóa đơn?
- Backup đã được thiết lập và đã test khôi phục thật (không chỉ giả định là chạy được)?
- RTO/RPO đã xác định chưa? Có kế hoạch DR nếu mất cả một region?
- Secret được quản lý qua Vault/KMS chứ không hard-code?
- Đã scan lỗ hổng (vulnerability) cho image và dependency?
- Có tuân thủ yêu cầu tuân thủ pháp lý nếu là fintech/healthcare (audit log, mã hóa dữ liệu)?
- Có chiến lược deploy an toàn (canary/blue-green)?
- Rollback có được test chưa? Nếu bản mới hỏng, mất bao lâu để quay về bản cũ?
Tình huống thực tế
Tình huống 1: Sàn TMĐT Đông Nam Á và cái service "mồ côi"
Một sàn thương mại điện tử lớn ở khu vực (giả định tên "ShopSEA") có một service tính phí vận chuyển được một dev senior viết trong lúc gấp rút chuẩn bị cho campaign 11.11. Service lên thẳng production, không qua PRR vì "deadline gấp quá". Ba tháng sau, dev đó nghỉ việc.
Đêm 12.12, service này bắt đầu trả về phí ship sai (âm tiền) do một dependency đổi format response. Alert... không có, vì chưa từng ai cấu hình. Khách hàng đặt hàng với phí ship âm suốt 40 phút trước khi bộ phận CSKH báo lên. Không ai biết service này của team nào, không có runbook, log thì không structured nên grep mãi không ra. Tổng thiệt hại ước tính hơn 600 triệu đồng đơn hàng lỗi phải hủy và hoàn.
Bài học: Nếu ShopSEA có PRR, hai câu hỏi đơn giản — "Ai là owner?" và "Có alert khi phí bất thường không?" — đã ngăn được toàn bộ sự cố. PRR không phải bàn giấy quan liêu; nó là bảo hiểm rẻ tiền cho những đêm đắt giá.
Tình huống 2: Fintech Việt Nam và cái "Go with conditions" đúng đắn
Một ví điện tử tại Hà Nội (giả định "VíNhanh") chuẩn bị ra mắt tính năng "trả góp". Team SRE tổ chức PRR. Service đạt phần lớn tiêu chí: có dashboard, có SLO 99.9%, có canary deploy. Nhưng hai điểm chưa ổn: backup của bảng lịch trả góp chưa từng được test restore, và runbook mới có 2/5 kịch bản sự cố.
Thay vì cứng nhắc "no-go" (làm trễ ra mắt cả tháng) hay dễ dãi "go" luôn (rủi ro), SRE lead ra quyết định Go with conditions: được lên production với tải giới hạn ở 10% người dùng qua feature flag, kèm cam kết trong 14 ngày phải hoàn thành test restore và đủ 5 runbook. Có người được assign cụ thể và deadline được track trên Jira.
Kết quả: ra mắt đúng hạn cho nhóm nhỏ, không sự cố. Đến ngày thứ 11, đội test restore thì phát hiện backup thiếu một bảng liên kết — may mà phát hiện lúc chỉ có 10% user chứ không phải toàn bộ.
Bài học: PRR không phải để chặn tiến độ, mà để quản trị rủi ro có kiểm soát. "Go with conditions" kết hợp feature flag (bài 17) là công cụ cực mạnh để cân bằng giữa tốc độ kinh doanh và an toàn vận hành.
Tình huống 3: Startup SaaS và cái PRR "nhẹ" (lightweight)
Một startup SaaS 8 người ở Đà Nẵng nghe nói về PRR của Google và định bê nguyên checklist 60 mục về áp dụng. Kết quả: mỗi lần ra service mới mất 2 tuần điền form, cả team phát bực, và họ bỏ luôn PRR sau lần thứ hai.
Họ làm lại theo hướng đúng: một PRR nhẹ gồm đúng 12 câu hỏi thiết yếu trên một trang Notion, tổ chức trong buổi họp 45 phút. Với service rủi ro thấp (ví dụ một internal tool), họ dùng self-review; chỉ service chạm tiền hoặc dữ liệu khách hàng mới cần review đầy đủ với đủ team.
Bài học: PRR phải tương xứng với rủi ro và quy mô. Một checklist khổng lồ mà không ai dùng thì vô giá trị. Hãy bắt đầu nhẹ, phân tầng theo mức rủi ro (risk tier — liên hệ bài 15), rồi mở rộng dần.
Hướng dẫn từng bước
Đây là cách bạn tổ chức một buổi PRR thực tế cho một service.
Bước 1 — Kích hoạt sớm, không phải phút chót. PRR nên bắt đầu khoảng 2–4 tuần trước ngày dự kiến go-live, không phải chiều thứ Sáu trước khi deploy sáng thứ Hai. Đội dev tạo một PRR document và điền các thông tin cơ bản: mô tả service, sơ đồ kiến trúc, danh sách dependency, tải kỳ vọng.
Bước 2 — Đội dev tự đánh giá (self-assessment) theo checklist. Trước khi họp, đội sở hữu service tự đi qua checklist và đánh dấu từng mục: đã có / chưa có / không áp dụng. Điều này giúp buổi họp chỉ tập trung vào phần rủi ro thay vì đọc lại từ đầu.
Bước 3 — Reviewer nghiên cứu trước. Người review (thường là một SRE hoặc engineer giàu kinh nghiệm không thuộc đội dev) đọc trước document, xem qua dashboard, thử đọc runbook. Vai trò reviewer độc lập rất quan trọng — người viết code khó tự thấy điểm mù của mình.
Bước 4 — Họp PRR. Buổi họp 45–90 phút, đi qua từng trụ cột. Trọng tâm không phải "đọc checklist" mà là đặt câu hỏi phản biện: "Nếu database chính chết thì điều gì xảy ra? Cho tôi xem alert đó bắn ra sao. Runbook này ai chưa từng đọc thử làm theo được không?". Một mẹo hay: yêu cầu demo thật — bắn thử một alert, thử rollback thật trên staging.
Bước 5 — Ghi nhận các gap và quyết định. Sau khi review, tổng hợp danh sách các điểm thiếu. Phân loại mỗi điểm thành blocker (phải sửa trước go-live) hoặc non-blocker (sửa sau, có deadline). Ra quyết định Go / Go-with-conditions / No-go.
Bước 6 — Theo dõi các điều kiện. Nếu là "go with conditions", mỗi điều kiện phải có owner cụ thể và deadline, được track như một ticket bình thường. PRR mà quyết xong rồi không ai theo dõi các action item thì cũng vô nghĩa.
Bước 7 — Đóng vòng và lưu hồ sơ. Lưu PRR document lại. Nó trở thành tài liệu sống về service, và là tham chiếu quý giá cho postmortem sau này ("lúc PRR ta có lường trước rủi ro này không?").
Lỗi thường gặp & mẹo
Lỗi 1 — Biến PRR thành thủ tục quan liêu. Đây là cái chết phổ biến nhất. Checklist phình to, họp lê thê, ai cũng ghét. Mẹo: giữ checklist tối giản, phân tầng theo risk tier, ưu tiên demo thật hơn là điền form.
Lỗi 2 — Làm PRR quá muộn. Nếu bạn review vào ngày trước go-live, mọi phát hiện đều thành "quá trễ để sửa" và PRR chỉ còn là con dấu cao su. Mẹo: đưa PRR vào timeline dự án ngay từ khi bắt đầu, như một milestone bắt buộc.
Lỗi 3 — Tin vào "trên giấy" mà không kiểm chứng. "Có backup" trên giấy không có nghĩa là backup restore được. "Có alert" không có nghĩa alert bắn đúng. Mẹo: với các mục sống-còn (backup, rollback, alert), luôn yêu cầu bằng chứng thực thi, không chấp nhận lời khai.
Lỗi 4 — Không có ai làm reviewer độc lập. Đội tự review đội mình thường bỏ qua điểm mù. Mẹo: luôn có ít nhất một reviewer ngoài đội, tốt nhất là người sẽ phải on-call cho service đó.
Lỗi 5 — PRR một lần rồi quên. Service tiến hóa; một service qua PRR năm ngoái giờ đã khác hẳn. Mẹo: làm PRR lại (re-review) khi có thay đổi kiến trúc lớn, hoặc định kỳ với các service quan trọng.
Lỗi 6 — Coi "no-go" là thất bại của đội dev. Điều này tạo văn hóa che giấu, giống văn hóa đổ lỗi mà postmortem blameless (bài 11) cố tránh. Mẹo: đóng khung PRR là công cụ hợp tác để cùng làm service tốt hơn, không phải bài kiểm tra để đánh trượt ai.
Bài tập thực hành
Bài 1 — Xây checklist PRR tối giản. Dựa trên 9 trụ cột trong bài, hãy viết một checklist PRR gồm đúng 12–15 câu hỏi thiết yếu nhất cho bối cảnh công ty bạn. Với mỗi câu, ghi rõ nó thuộc "blocker" hay "non-blocker" mặc định.
Bài 2 — Phân tầng theo rủi ro. Định nghĩa 3 tier rủi ro (ví dụ: internal tool / customer-facing / chạm tiền hoặc dữ liệu nhạy cảm) và quyết định mỗi tier cần mức PRR nào (self-review nhẹ hay full review với đủ team).
Bài 3 — Chạy thử một PRR mô phỏng. Chọn một service thật đang chạy trong hệ thống của bạn (hoặc một service giả định). Đóng vai reviewer và trả lời trung thực từng mục checklist. Bạn sẽ ngạc nhiên vì số lượng "chưa có" xuất hiện.
Bài 4 — Viết một quyết định "Go with conditions". Với service ở bài 3, giả sử nó thiếu 3 điểm. Hãy viết một quyết định go-with-conditions hoàn chỉnh: được lên với điều kiện gì, owner mỗi điều kiện là ai, deadline bao lâu, và cơ chế giới hạn rủi ro (feature flag, tải giới hạn) ra sao.
Tóm tắt
Production Readiness Review là cửa đăng kiểm trước khi một service ra production — nơi ta kiểm tra không phải "code có chạy không" mà "hệ thống có vận hành được không khi có sự cố lúc 3 giờ sáng". Nó khác biệt hoàn toàn với code review và testing ở chỗ nó nhìn qua con mắt của người phải vận hành service.
Một PRR tốt xoay quanh các trụ cột: observability, alerting, on-call & ownership, runbook, reliability, capacity, data & recovery, security, và deployment/rollback. Kết quả review là Go, Go-with-conditions, hoặc No-go — với các điều kiện được track như ticket thật.
Ba nguyên tắc cốt lõi cần nhớ: (1) PRR phải tương xứng với rủi ro, đừng quan liêu hóa; (2) luôn kiểm chứng bằng bằng chứng thực thi, đừng tin lời khai trên giấy; (3) PRR là công cụ hợp tác, không phải bài thi để đánh trượt. Làm đúng, PRR là khoản bảo hiểm rẻ nhất bạn có thể mua cho những đêm on-call của chính mình.