150 Checklist trước và sau Vibe Coding, trước khi Go-live Website

Có một cảm giác rất dễ khiến người làm phần mềm vui quá sớm.

Website đã chạy. Giao diện đẹp. Đăng nhập được. Nút đặt hàng bấm cũng ra kết quả. AI Coding Agent thông báo các nhiệm vụ đã hoàn thành, những bài kiểm thử được chạy đều xanh.

Vậy là Go-live?

Chưa chắc.

Hơn 10 năm làm việc với lập trình và các hệ thống phần mềm khiến tôi ngày càng quan tâm đến một câu hỏi khác: Điều gì có thể xảy ra sau khi người dùng thật bắt đầu sử dụng sản phẩm?

Không chỉ là một nút bấm bị lỗi. Đó còn có thể là dữ liệu khách hàng bị lộ, một người dùng nhìn thấy đơn hàng của người khác, giao dịch thanh toán bị ghi nhận hai lần, bản sao lưu không thể phục hồi hoặc website thiếu những chính sách bắt buộc.

Với Vibe Coding, những vấn đề ấy càng đáng được quan tâm.

AI giúp chúng ta tạo phần mềm nhanh hơn. Nhưng AI viết xong mã nguồn không đồng nghĩa với việc sản phẩm đã đáp ứng đầy đủ yêu cầu về bảo mật, dữ liệu, vận hành và pháp luật.

Chú Nha 27 tuổi không muốn biến bài viết này thành một danh sách dài để mọi người đọc xong rồi quên. Tôi muốn chia sẻ một bộ checklist có thể đem vào dự án, giao người phụ trách, kiểm tra kết quả và sử dụng trước mỗi lần triển khai.

Bài viết được chia thành ba thời điểm: trước khi Vibe Coding, sau khi AI hoàn thành lập trình và trước khi Go-live website.

Tổng cộng có 150 hạng mục, được chia thành 10 nhóm. Mỗi nhóm gồm 15 việc cần kiểm tra, từ yêu cầu nghiệp vụ đến bảo mật, chính sách, pháp luật, SEO, dữ liệu và vận hành.

Tôi cũng đã chuẩn bị một file Google Sheets để mọi người có thể tạo bản sao miễn phí, sử dụng cho dự án của mình mà không phải nhập lại từng checklist.

1. Tải miễn phí bộ 150 checklist Vibe Coding và Go-live Website

Để mọi người có thể áp dụng ngay những nội dung trong bài viết này, tôi đã tổng hợp toàn bộ 150 hạng mục thành một file Google Sheets mẫu.

File được chia thành 10 nhóm, theo ba thời điểm: trước khi Vibe Coding, sau khi AI hoàn thành lập trình và trước khi đưa website vào vận hành chính thức.

Bạn không cần tạo tài khoản trên blog, không cần cung cấp email và cũng không phải tải một tài liệu PDF rồi ngồi đánh dấu thủ công.

Chỉ cần mở liên kết bên dưới, tạo một bản sao vào Google Drive của mình và bắt đầu sử dụng.

Tạo bản sao miễn phí - 150 Checklist Vibe Coding và Website Go-live (Google Sheets)

File Google Sheets bao gồm những gì?

• CHECKLIST_150: Danh sách 150 hạng mục, có mã kiểm tra, mức độ ưu tiên, trạng thái, người phụ trách, bằng chứng, rủi ro và hướng khắc phục.
• DASHBOARD: Theo dõi số lượng checklist đã hoàn thành, chưa kiểm tra, không đạt và các vấn đề cần xử lý.
• HUONG_DAN: Hướng dẫn sử dụng file và cập nhật kết quả.
• GO_NO_GO: Hỗ trợ tổng hợp những vấn đề cần xem xét trước khi quyết định triển khai.
• NGUON_THAM_KHAO: Các nguồn tham khảo về bảo mật, phát triển phần mềm, dữ liệu và SEO.

Hướng dẫn tạo bản sao và sử dụng

1. Bước 1: Nhấn vào liên kết Google Sheets phía trên.
2. Bước 2: Đăng nhập tài khoản Google nếu được yêu cầu, sau đó chọn "Make a copy" hoặc "Tạo bản sao".
3. Bước 3: Đặt tên file theo dự án của bạn, ví dụ "Website ABC - Checklist Go-live".
4. Bước 4: Mở trang CHECKLIST_150 và lọc những nhóm kiểm tra phù hợp với dự án.
5. Bước 5: Phân công người chịu trách nhiệm cho từng hạng mục.
6. Bước 6: Cập nhật trạng thái, bổ sung bằng chứng kiểm tra, những vấn đề phát hiện và thời hạn khắc phục.
7. Bước 7: Theo dõi tiến độ tại DASHBOARD và xem xét các vấn đề tại GO_NO_GO trước khi triển khai.

Hiểu đúng các trạng thái kiểm tra

• CHƯA KIỂM TRA: Chưa bắt đầu thực hiện.
• ĐANG KIỂM TRA: Đang thực hiện và thu thập bằng chứng.
• PASS: Đã kiểm tra và đạt yêu cầu, có bằng chứng phù hợp.
• FAIL: Đã kiểm tra nhưng phát hiện không đạt.
• PENDING: Đang chờ thông tin, kết quả hoặc xác nhận.
• N/A: Không áp dụng cho dự án, cần ghi rõ lý do.

Một lưu ý nhỏ: Đừng đánh dấu PASS chỉ vì AI nói chức năng đã hoàn thành. Hãy kiểm tra kết quả thực tế và lưu lại bằng chứng.

Với các hạng mục liên quan đến pháp luật, bộ checklist chỉ giúp nhận diện những vấn đề cần xem xét, không thay thế đánh giá của người phụ trách pháp lý hoặc tư vấn chuyên môn.

Có cần hoàn thành đủ 150 checklist không?

Không nhất thiết.

Một website giới thiệu đơn giản có thể không cần kiểm tra nghiệp vụ thanh toán, đối soát tài chính hoặc phân tách dữ liệu nhiều doanh nghiệp.

Ngược lại, một nền tảng thương mại điện tử có thanh toán, quản lý đơn hàng và dữ liệu khách hàng cần kiểm tra rất kỹ những nhóm này.

Bạn có thể đánh dấu N/A cho những mục không áp dụng, nhưng cần ghi lại lý do. Đối với các mục thuộc nhóm BLOCKER hoặc có rủi ro nghiêm trọng, không nên bỏ qua nếu chưa được đánh giá đầy đủ.

Có thể sử dụng lại và chia sẻ cho người khác không?

Có. Tôi chia sẻ bộ checklist này để mọi người có thể tạo bản sao, sử dụng cho dự án cá nhân, nhóm phát triển hoặc hoạt động nghiệm thu nội bộ.

Bạn cũng có thể bổ sung những hạng mục riêng phù hợp với lĩnh vực đang triển khai.

Nếu thấy hữu ích, bạn có thể chia sẻ liên kết bài viết này để đồng nghiệp và bạn bè cùng tham khảo phiên bản được cập nhật.

Chỉ xin một điều nhỏ: Nếu chia sẻ lại nguyên bộ tài liệu ra cộng đồng, hãy ghi nguồn Mãnh Tử Nha - manhtunha.com để người đọc biết nơi tham khảo và cập nhật.

2. Trước khi bắt đầu: Hiểu cách sử dụng checklist

Đầu tiên, chúng ta cần thống nhất một số nguyên tắc.

Thứ nhất: Checklist không thay thế việc đánh giá chuyên môn. Một mục được đánh dấu hoàn thành cần có bằng chứng phù hợp.

Thứ hai: Không phải mọi mục đều bắt buộc với mọi loại website. Website giới thiệu cá nhân sẽ khác website thương mại điện tử, nền tảng nhiều người bán hoặc hệ thống xử lý dữ liệu tài chính.

Thứ ba: Nên phân loại từng hạng mục theo mức độ rủi ro.

• BLOCKER: Vấn đề có thể khiến dự án không được phép Go-live, như lỗ hổng nghiêm trọng chưa được xử lý, sai lệch tài chính, không bảo đảm toàn vẹn dữ liệu hoặc thiếu điều kiện pháp lý bắt buộc.
• HIGH: Rủi ro cao cần xử lý trước Go-live, trừ khi có đánh giá, biện pháp giảm thiểu và phê duyệt ngoại lệ hợp lệ.
• MEDIUM: Vấn đề cần khắc phục theo thời hạn, dựa trên mức độ ảnh hưởng.
• LOW: Cải tiến có thể đưa vào kế hoạch sau triển khai nếu không ảnh hưởng điều kiện nghiệm thu.

Thứ tư: Với những hạng mục không áp dụng, cần ghi rõ N/A cùng lý do. Không nên đánh dấu Passed chỉ để hoàn thành đủ số lượng.

Đối với mỗi mục kiểm tra, nên ghi nhận:

ID: Checklist Item: Priority: Status: PASS / FAIL / N/A / PENDING Owner: Evidence: Risk: Remediation: Due Date: Approved By: Verified At:

Để dễ sử dụng, tôi chia thành ba giai đoạn lớn.

PHẦN I - CHECKLIST TRƯỚC KHI VIBE CODING

Đây là giai đoạn thường bị bỏ qua nhất.

Chúng ta có ý tưởng, mở công cụ AI rồi yêu cầu lập trình ngay. Nhưng nếu đầu vào chưa rõ, AI có thể tạo ra một phần mềm rất chỉn chu dựa trên những giả định không đúng.

Trong phương pháp Human-Directed AI Coding, con người quyết định WHY, WHAT, RULES. AI có thể hỗ trợ nghiên cứu và chuẩn hóa thành BRD, SRS, business rules trước khi thực thi HOW.

Nhóm 1. Mục tiêu, nghiệp vụ và yêu cầu sản phẩm - 15 checklist

1. Đã xác định mục tiêu kinh doanh. Có tài liệu giải thích phần mềm được xây dựng để giải quyết vấn đề gì và vì sao vấn đề đó đáng giải quyết.
2. Đã xác định người sử dụng. Có danh sách vai trò, nhóm người dùng và nhu cầu chính của từng nhóm.
3. Đã xác định phạm vi MVP. Phân biệt chức năng bắt buộc của phiên bản đầu và chức năng sẽ phát triển sau.
4. Đã có BRD được xem xét. Tài liệu mô tả nhu cầu nghiệp vụ, mục tiêu và các bên liên quan.
5. Đã có SRS hoặc đặc tả chức năng. Các chức năng quan trọng có đầu vào, đầu ra, luồng xử lý và trường hợp ngoại lệ.
6. Đã định nghĩa business rules. Những quy tắc về trạng thái, tiền, quyền, thời gian và xử lý nghiệp vụ được ghi nhận rõ ràng.
7. Đã xây dựng ma trận phân quyền. Vai trò nào được tạo, xem, sửa, xóa, phê duyệt hoặc xuất dữ liệu nào.
8. Đã mô tả các luồng nghiệp vụ chính. Có sơ đồ hoặc mô tả những hành trình như đăng ký, đăng nhập, đặt hàng, thanh toán và hủy giao dịch nếu áp dụng.
9. Đã mô tả trường hợp ngoại lệ. Xử lý khi hết hàng, lỗi API, mất kết nối, thanh toán thất bại hoặc người dùng thao tác đồng thời.
10. Đã xác định tiêu chí nghiệm thu. Mỗi yêu cầu quan trọng có acceptance criteria có thể kiểm tra được.
11. Đã xác định yêu cầu phi chức năng. Bao gồm hiệu năng, khả dụng, bảo mật, khả năng mở rộng và thời gian phục hồi.
12. Đã kiểm tra yêu cầu mâu thuẫn. AI Research hoặc Business Analyst rà soát những điểm không nhất quán giữa các tài liệu.
13. Đã đánh dấu giả định chưa xác nhận. Không để AI biến một đề xuất thành quy tắc nghiệp vụ chính thức.
14. Đã chỉ định người phê duyệt. Mỗi nhóm yêu cầu có người chịu trách nhiệm xác nhận và quyết định thay đổi.
15. Đã lưu baseline tài liệu. Phiên bản BRD/SRS được phê duyệt có mã phiên bản và được lưu trong Git hoặc hệ thống quản lý tài liệu.

Bằng chứng nghiệm thu: BRD, SRS, business-rules.md, ma trận phân quyền, acceptance criteria và thông tin phê duyệt.

Nhóm 2. Dữ liệu, pháp lý và chính sách ngay từ thiết kế - 15 checklist

Nếu website xử lý dữ liệu cá nhân hoặc giao dịch, hãy bắt đầu đánh giá nghĩa vụ pháp lý từ trước khi viết code.

Tại Việt Nam, từ ngày 01/01/2026, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và Nghị định 356/2025/NĐ-CP đã có hiệu lực. Từ ngày 01/07/2026, Luật Thương mại điện tử số 122/2025/QH15 và Luật An ninh mạng số 116/2025/QH15 cũng đã có hiệu lực.

Phạm vi nghĩa vụ cụ thể cần được xác định theo loại hình website và hoạt động thực tế.

1. Đã xác định chủ thể vận hành website. Tổ chức, cá nhân, thông tin pháp lý và trách nhiệm đối với dịch vụ được làm rõ.
2. Đã xác định loại hình website. Website giới thiệu, bán hàng, cung cấp dịch vụ thương mại điện tử, nền tảng trung gian hay hệ thống nội bộ.
3. Đã lập danh mục dữ liệu cá nhân. Liệt kê những loại dữ liệu được thu thập, tạo lập, lưu trữ hoặc chia sẻ.
4. Đã phân loại mức độ nhạy cảm của dữ liệu. Xác định dữ liệu cần biện pháp bảo vệ đặc biệt và hạn chế quyền truy cập.
5. Đã xác định mục đích xử lý dữ liệu. Mỗi loại dữ liệu có mục đích thu thập và sử dụng rõ ràng.
6. Đã xác định căn cứ pháp lý xử lý dữ liệu. Kiểm tra trường hợp cần sự đồng ý và trường hợp được xử lý trên căn cứ khác theo pháp luật.
7. Đã thiết kế cơ chế đồng ý phù hợp. Người dùng được cung cấp thông tin cần thiết và có cách thể hiện lựa chọn hợp lệ khi pháp luật yêu cầu.
8. Đã thiết kế cơ chế thực hiện quyền dữ liệu. Có quy trình tiếp nhận và xử lý yêu cầu truy cập, chỉnh sửa, xóa, hạn chế xử lý, rút lại đồng ý và các quyền áp dụng khác.
9. Đã xác định thời hạn lưu trữ và xóa dữ liệu. Phù hợp mục đích xử lý, nghĩa vụ lưu trữ và yêu cầu pháp luật.
10. Đã xác định các bên nhận dữ liệu. Bao gồm nhà cung cấp hạ tầng, email, thanh toán, phân tích, AI và các đối tác khác.
11. Đã đánh giá việc chuyển dữ liệu ra nước ngoài. Xác định có phát sinh chuyển dữ liệu xuyên biên giới và các nghĩa vụ liên quan hay không.
12. Đã rà soát nghĩa vụ hồ sơ đánh giá tác động. Xác định những hồ sơ, thời hạn và thủ tục áp dụng cho hoạt động xử lý dữ liệu cá nhân.
13. Đã xác định chính sách cần công bố. Chính sách bảo mật, điều khoản sử dụng, mua bán, giao hàng, hoàn tiền hoặc chính sách chuyên ngành tùy dịch vụ.
14. Đã kiểm tra nghĩa vụ thương mại điện tử. Xác định yêu cầu thông báo, đăng ký, công bố thông tin hoặc trách nhiệm nền tảng theo quy định hiện hành.
15. Đã đánh giá quyền sở hữu và giấy phép. Kiểm tra tên miền, nội dung, hình ảnh, font, thư viện mã nguồn, dữ liệu bên thứ ba và quyền sử dụng kết quả do AI tạo.

Bằng chứng nghiệm thu: Data Inventory, sơ đồ luồng dữ liệu, hồ sơ đánh giá pháp lý, bản dự thảo chính sách, danh sách nhà cung cấp và tài liệu giấy phép.

Lưu ý: Không phải website nào cũng phải thực hiện cùng một loại thủ tục. Cần đối chiếu trực tiếp quy định hiện hành và có đánh giá pháp lý phù hợp trước khi kết luận.

Nhóm 3. Kiến trúc, bảo mật thiết kế và quản trị AI - 15 checklist

1. Đã lựa chọn kiến trúc phù hợp. Có tài liệu giải thích frontend, backend, database, tích hợp và lý do chọn phương án.
2. Đã có sơ đồ hệ thống. Thể hiện ứng dụng, máy chủ, dịch vụ bên ngoài, khu vực mạng và các luồng dữ liệu chính.
3. Đã xác định ranh giới tin cậy. Phân biệt dữ liệu từ trình duyệt, backend, database, đối tác và nguồn bên ngoài.
4. Đã thực hiện threat modeling phù hợp. Xác định những tình huống có thể làm lộ dữ liệu, chiếm quyền hoặc phá vỡ nghiệp vụ.
5. Đã thiết kế authentication. Chọn cơ chế đăng nhập, quản lý phiên và xác thực đa yếu tố cho những vai trò cần thiết.
6. Đã thiết kế authorization. Kiểm tra quyền ở phía máy chủ, giới hạn quyền theo tài nguyên và người sở hữu dữ liệu.
7. Đã thiết kế bảo vệ dữ liệu. Xác định cách mã hóa khi truyền, khi lưu nếu cần, quản lý khóa và bảo vệ bản sao lưu.
8. Đã có chiến lược quản lý secrets. API key, token và mật khẩu được quản lý ngoài mã nguồn, có cơ chế phân quyền và thay đổi khóa.
9. Đã có quy tắc database migration. Mọi thay đổi cấu trúc dữ liệu cần được kiểm tra, phê duyệt và có phương án khôi phục.
10. Đã xác định chiến lược backup. Thiết lập RPO, RTO và yêu cầu phục hồi phù hợp với mức độ quan trọng của dữ liệu.
11. Đã xác định logging và audit trail. Những hành động nhạy cảm được ghi nhận đủ để truy vết, không để lộ dữ liệu bí mật.
12. Đã thiết lập repository và quy tắc Git. Có branch protection, review, quyền truy cập và quy trình merge phù hợp.
13. Đã tạo project instructions cho AI. AGENTS.md hoặc cơ chế tương đương mô tả nguồn tài liệu, quy tắc và giới hạn thay đổi.
14. Đã giới hạn quyền AI Coding Agent. Agent không được tự ý truy cập production, xóa dữ liệu hoặc thực hiện hành động nguy hiểm nếu chưa được cho phép.
15. Đã có Definition of Done. Một task chỉ hoàn thành khi đạt yêu cầu, kiểm thử, review và có báo cáo rõ ràng.

Bằng chứng nghiệm thu: Architecture Diagram, Threat Model, Security Design, AGENTS.md, chính sách Git, phương án backup và Definition of Done.

PHẦN II - CHECKLIST SAU KHI VIBE CODING

AI thông báo hoàn thành không phải là bằng chứng cuối cùng.

Chúng ta cần xác nhận mã nguồn tạo ra có đáp ứng yêu cầu, không gây ảnh hưởng ngoài phạm vi và không tạo thêm rủi ro.

Nhóm 4. Chất lượng mã nguồn và kiểm thử - 15 checklist

1. Đã đối chiếu code với SRS. Các yêu cầu đã phê duyệt đều có kết quả triển khai hoặc ghi nhận chưa hoàn thành.
2. Đã đối chiếu acceptance criteria. Mỗi tiêu chí nghiệm thu có test hoặc bằng chứng xác minh phù hợp.
3. Đã review thay đổi mã nguồn. Có người có chuyên môn kiểm tra pull request, không chỉ dựa vào phản hồi tự đánh giá của AI.
4. Đã kiểm tra thay đổi ngoài phạm vi. Diff không chứa những thay đổi không có lý do hoặc chưa được phê duyệt.
5. Đã chạy build và type checking. Kết quả thực tế được lưu, không chỉ ghi nhận lời thông báo từ agent.
6. Đã chạy lint và static analysis. Các phát hiện được phân loại, xử lý hoặc đánh giá rủi ro.
7. Đã chạy unit tests. Kiểm tra những đơn vị logic quan trọng và các quy tắc nghiệp vụ liên quan.
8. Đã chạy integration tests. Kiểm tra API, database và các dịch vụ tích hợp trong môi trường phù hợp.
9. Đã chạy end-to-end tests. Kiểm tra hành trình thực tế của người dùng từ đầu đến cuối.
10. Đã kiểm tra dữ liệu đầu vào không hợp lệ. Bao gồm trường rỗng, dữ liệu sai định dạng, độ dài vượt giới hạn và giá trị bất thường.
11. Đã kiểm tra các tình huống biên. Dữ liệu lớn, ngày tháng đặc biệt, giá trị bằng không, trạng thái hết hạn và các trường hợp nghiệp vụ tương ứng.
12. Đã kiểm tra xử lý lỗi. API timeout, database lỗi, dịch vụ bên ngoài thất bại và khả năng phục hồi được đánh giá.
13. Đã kiểm tra tương thích ngược. Những API và chức năng hiện tại không bị phá vỡ ngoài phạm vi đã phê duyệt.
14. Đã kiểm tra dependency. Thư viện mới có lý do sử dụng, phiên bản phù hợp, giấy phép và tình trạng bảo mật được rà soát.
15. Đã lưu báo cáo kiểm thử. Có danh sách test đã chạy, kết quả, thời điểm, môi trường và những vấn đề chưa xác minh.

Bằng chứng nghiệm thu: Pull Request, Code Review, CI Report, Unit Test Report, Integration Test Report và danh sách lỗi còn tồn đọng.

Nhóm 5. Kiểm tra bảo mật ứng dụng và AI-generated code - 15 checklist

Đối với bảo mật ứng dụng web, có thể sử dụng OWASP Application Security Verification Standard (ASVS) làm cơ sở xây dựng yêu cầu và kiểm thử. Phiên bản ASVS 5.0.0 được công bố năm 2025.

1. Đã kiểm tra SQL Injection. Các truy vấn sử dụng cơ chế tham số hóa hoặc phương pháp truy cập dữ liệu an toàn.
2. Đã kiểm tra XSS. Dữ liệu không tin cậy được xử lý và mã hóa đầu ra phù hợp với từng ngữ cảnh hiển thị.
3. Đã kiểm tra CSRF. Các hành động thay đổi trạng thái có biện pháp bảo vệ tương ứng với cơ chế xác thực đang dùng.
4. Đã kiểm tra IDOR/BOLA. Người dùng không thể thay đổi ID để truy cập tài nguyên không thuộc quyền.
5. Đã kiểm tra authentication. Không có cơ chế đăng nhập mặc định, bỏ qua xác thực hoặc tiết lộ thông tin tài khoản không cần thiết.
6. Đã kiểm tra session management. Cookie, thời gian hết hạn, đăng xuất, thu hồi phiên và thuộc tính bảo mật được cấu hình phù hợp.
7. Đã kiểm tra authorization. Quyền được kiểm tra tại backend cho từng hành động và tài nguyên nhạy cảm.
8. Đã kiểm tra chức năng tải file. Giới hạn loại file, dung lượng, tên file, quyền truy cập và xử lý nội dung không an toàn.
9. Đã kiểm tra SSRF. Những chức năng gọi URL hoặc tài nguyên bên ngoài có giới hạn và xác thực đích phù hợp.
10. Đã kiểm tra CORS. Không sử dụng cấu hình cho phép nguồn không tin cậy khi không cần thiết.
11. Đã kiểm tra HTTP security headers. Thiết lập CSP, HSTS, chống nhúng trang và các header phù hợp với ứng dụng.
12. Đã kiểm tra secrets. Repository, lịch sử commit, cấu hình và log không chứa thông tin bí mật bị lộ.
13. Đã kiểm tra dependency vulnerabilities. Thực hiện software composition analysis và đánh giá những cảnh báo theo mức độ ảnh hưởng thực tế.
14. Đã kiểm tra chức năng quản trị. Admin API, debug endpoint, công cụ hỗ trợ và tài khoản đặc quyền không bị mở công khai ngoài yêu cầu.
15. Đã rà soát kết quả kiểm thử bảo mật. Những lỗ hổng Critical/High được xác minh, khắc phục hoặc xử lý theo chính sách chấp nhận rủi ro trước khi triển khai.

Bằng chứng nghiệm thu: SAST, DAST, SCA, kết quả kiểm tra phân quyền, Security Review và hồ sơ xử lý lỗ hổng.

Lưu ý: Không nên sử dụng một công cụ quét duy nhất để tuyên bố website hoàn toàn an toàn. Những lỗi về logic nghiệp vụ và phân quyền thường cần thêm kiểm thử theo tình huống thực tế.

Nhóm 6. Toàn vẹn dữ liệu, giao dịch và tích hợp hệ thống - 15 checklist

Đây là nhóm đặc biệt quan trọng với website bán hàng, đặt dịch vụ, quản lý tài chính và hệ thống xử lý nhiều giao dịch đồng thời.

1. Đã kiểm tra ràng buộc dữ liệu. Primary key, foreign key, unique constraint và các điều kiện dữ liệu quan trọng được thiết lập phù hợp.
2. Đã kiểm tra transaction. Những nghiệp vụ yêu cầu tính nguyên tử không để lại trạng thái ghi dữ liệu dở dang khi thất bại.
3. Đã kiểm tra xử lý đồng thời. Hai hoặc nhiều người cập nhật cùng tài nguyên không gây mất dữ liệu hoặc trạng thái không nhất quán.
4. Đã kiểm tra idempotency. Những thao tác có thể được gửi lại, đặc biệt là thanh toán và tạo đơn hàng, có cơ chế tránh xử lý trùng phù hợp.
5. Đã kiểm tra tính toán tài chính. Giá, giảm giá, thuế, phí, tiền cọc, công nợ và làm tròn số được đối chiếu với business rules.
6. Đã kiểm tra trạng thái nghiệp vụ. Không thể chuyển trạng thái trái quy tắc, chẳng hạn hoàn tiền cho giao dịch chưa thanh toán.
7. Đã kiểm tra webhook. Có xác thực nguồn, xử lý trùng lặp, thứ tự sự kiện và cơ chế retry phù hợp.
8. Đã kiểm tra timeout và retry. Không tạo giao dịch trùng hoặc mất trạng thái khi kết nối bên ngoài bị gián đoạn.
9. Đã kiểm tra đối soát. Dữ liệu giao dịch giữa hệ thống nội bộ và bên thứ ba có cơ chế phát hiện chênh lệch.
10. Đã kiểm tra database migration. Migration chạy thành công trên dữ liệu thử nghiệm đại diện và được đánh giá tương thích.
11. Đã kiểm tra khả năng khôi phục dữ liệu. Thực hiện restore thử, không chỉ kiểm tra file backup có tồn tại.
12. Đã kiểm tra tính toàn vẹn lịch sử. Những thay đổi quan trọng có dấu vết và không bị xóa hoặc sửa trái phép.
13. Đã kiểm tra đồng bộ bất đồng bộ. Queue, background job và cơ chế xử lý lỗi không làm thất lạc nghiệp vụ.
14. Đã kiểm tra phân tách dữ liệu khách hàng. Nếu hệ thống multi-tenant, dữ liệu các tenant được cách ly trong cả truy vấn, cache, file và báo cáo.
15. Đã kiểm tra dữ liệu thử nghiệm. Không sử dụng dữ liệu cá nhân thật trái phép và không để dữ liệu test lẫn vào production.

Bằng chứng nghiệm thu: Data Integrity Test, Transaction Test, Concurrency Test, Restore Test, Reconciliation Report và Migration Report.

PHẦN III - CHECKLIST TRƯỚC KHI GO-LIVE WEBSITE

Đến đây, phần mềm đã được xây dựng và kiểm thử. Nhưng môi trường production là một câu chuyện khác.

Server, DNS, chứng chỉ, chính sách, thông báo pháp lý, SEO, giám sát và quy trình xử lý sự cố cần được chuẩn bị đồng bộ.

Tôi thường xem Go-live là một quyết định vận hành, không phải chỉ là thao tác nhấn nút Deploy.

Nhóm 7. Hạ tầng, cấu hình production và khả năng phục hồi - 15 checklist

1. Đã kiểm tra DNS và domain. Bản ghi DNS chính xác, tên miền còn hiệu lực và quyền quản lý được bảo vệ.
2. Đã kiểm tra HTTPS/TLS. Chứng chỉ hợp lệ, cấu hình giao thức an toàn và cơ chế gia hạn được theo dõi.
3. Đã tách môi trường production. Production không dùng chung secrets, dữ liệu và quyền quản trị không cần thiết với development.
4. Đã kiểm tra cấu hình môi trường. Connection string, API endpoint, feature flags và biến môi trường trỏ đúng dịch vụ.
5. Đã tắt debug công khai. Không hiển thị stack trace, thông tin cấu hình hoặc dữ liệu nhạy cảm cho người dùng.
6. Đã kiểm tra firewall và network access. Database, Redis và các dịch vụ nội bộ không bị mở ra Internet nếu không cần.
7. Đã kiểm tra phân quyền hạ tầng. Tài khoản triển khai, vận hành và nhà cung cấp có quyền tối thiểu cần thiết.
8. Đã cấu hình backup production. Có lịch sao lưu, lưu trữ an toàn, thời hạn giữ bản sao và cảnh báo thất bại.
9. Đã thử phục hồi backup. Có kết quả restore thực tế và đánh giá khả năng đáp ứng RPO/RTO.
10. Đã kiểm tra log và monitoring. Theo dõi lỗi ứng dụng, hiệu năng API, cơ sở dữ liệu và các sự kiện bảo mật quan trọng.
11. Đã cấu hình cảnh báo. Có cảnh báo khi website không truy cập được, lỗi tăng cao, CPU hoặc dung lượng vượt ngưỡng.
12. Đã kiểm tra tải hệ thống. Thực hiện load test theo lưu lượng kỳ vọng và kiểm tra các điểm nghẽn quan trọng.
13. Đã kiểm tra cache và CDN. Không cache nhầm dữ liệu cá nhân, trang quản trị hoặc nội dung riêng của người dùng.
14. Đã có quy trình rollback. Có kế hoạch khôi phục ứng dụng, cấu hình và xử lý các thay đổi database khi cần.
15. Đã diễn tập triển khai. Có release checklist, người phụ trách, phương án xác minh và kế hoạch xử lý khi triển khai thất bại.

Bằng chứng nghiệm thu: Production Configuration Review, TLS Check, Load Test, Restore Report, Monitoring Dashboard và Rollback Plan.

Nhóm 8. Pháp luật, bảo vệ dữ liệu cá nhân và chính sách website - 15 checklist

Đây là phần cần được người phụ trách pháp lý hoặc bộ phận tuân thủ xem xét, đặc biệt với website có đăng ký tài khoản, thu thập thông tin khách hàng, bán hàng hoặc cung cấp nền tảng giao dịch.

1. Đã công bố thông tin chủ thể vận hành. Tên, địa chỉ, thông tin liên hệ và thông tin kinh doanh được hiển thị theo nghĩa vụ áp dụng.
2. Đã có chính sách bảo vệ dữ liệu cá nhân. Nội dung phản ánh đúng hoạt động xử lý dữ liệu thực tế, không chỉ sử dụng mẫu chung.
3. Đã có điều khoản sử dụng hoặc điều kiện giao dịch. Quyền, trách nhiệm và giới hạn dịch vụ được mô tả rõ khi áp dụng.
4. Đã công bố chính sách giá và thanh toán. Giá bán, phí, thuế và các khoản thu quan trọng được thể hiện minh bạch theo quy định.
5. Đã công bố chính sách giao hàng hoặc cung cấp dịch vụ. Thời gian, phương thức và điều kiện thực hiện được làm rõ nếu có giao dịch.
6. Đã công bố chính sách đổi, trả, hủy và hoàn tiền. Điều kiện, quy trình và thời hạn được mô tả phù hợp pháp luật và tính chất dịch vụ.
7. Đã có cơ chế tiếp nhận khiếu nại. Có kênh liên hệ, người phụ trách và quy trình xử lý yêu cầu của khách hàng.
8. Đã kiểm tra nghĩa vụ thông báo hoặc đăng ký thương mại điện tử. Xác định thủ tục và trạng thái hoàn thành tương ứng với loại hình hoạt động theo pháp luật hiện hành.
9. Đã kiểm tra biểu mẫu thu thập dữ liệu. Chỉ thu thập dữ liệu cần thiết, cung cấp thông tin xử lý và cơ chế đồng ý hợp lệ nếu cần.
10. Đã kiểm tra lựa chọn cookie và tracking. Xác định mục đích, nhà cung cấp và yêu cầu đồng ý hoặc thông báo phù hợp với hoạt động theo dõi thực tế.
11. Đã có quy trình thực hiện quyền của chủ thể dữ liệu. Có cách tiếp nhận, xác minh và xử lý yêu cầu theo quy định áp dụng.
12. Đã rà soát hồ sơ đánh giá tác động và chuyển dữ liệu xuyên biên giới. Hoàn thành các nghĩa vụ áp dụng, bao gồm yêu cầu về hồ sơ và thủ tục khi phát sinh.
13. Đã kiểm tra hợp đồng với đơn vị xử lý dữ liệu. Trách nhiệm bảo mật, xử lý sự cố, sử dụng dữ liệu và các nghĩa vụ cần thiết được làm rõ.
14. Đã có quy trình xử lý sự cố dữ liệu và an ninh mạng. Xác định đầu mối, cách đánh giá, lưu bằng chứng, thông báo và báo cáo theo thời hạn pháp luật áp dụng.
15. Đã kiểm tra quyền sử dụng nội dung và nghĩa vụ chuyên ngành. Hình ảnh, phần mềm, nội dung, quảng cáo, bảo vệ người tiêu dùng và các điều kiện kinh doanh đặc thù được rà soát.

Bằng chứng nghiệm thu: Legal Compliance Review, chính sách đã công bố, hồ sơ thủ tục thương mại điện tử nếu thuộc diện áp dụng, tài liệu bảo vệ dữ liệu và quy trình xử lý khiếu nại.

Quan trọng: Checklist này là khung kiểm tra, không phải kết luận pháp lý cho một website cụ thể. Khi kinh doanh dịch vụ có điều kiện hoặc vận hành nền tảng thương mại điện tử, cần đánh giá thêm những nghĩa vụ chuyên ngành.

Nhóm 9. Trải nghiệm người dùng, SEO, AEO, GEO và accessibility - 15 checklist

Một website đã sẵn sàng về hạ tầng nhưng người dùng không tìm thấy nội dung, không sử dụng được trên điện thoại hoặc không hoàn thành giao dịch cũng chưa phải một sản phẩm đạt yêu cầu.

1. Đã kiểm tra giao diện responsive. Trang hoạt động trên những kích thước màn hình và thiết bị đại diện cho người dùng mục tiêu.
2. Đã kiểm tra các trình duyệt chính. Những chức năng quan trọng được thử trên trình duyệt được hỗ trợ.
3. Đã kiểm tra Core Web Vitals. Đo LCP, INP, CLS và xác định những vấn đề ảnh hưởng trải nghiệm thực tế.
4. Đã kiểm tra khả năng truy cập bằng bàn phím. Các thành phần tương tác quan trọng có thể sử dụng mà không cần chuột.
5. Đã kiểm tra nhãn và thông báo lỗi. Form có label phù hợp, lỗi dễ hiểu và không chỉ sử dụng màu sắc để truyền đạt thông tin.
6. Đã kiểm tra tương phản và hình ảnh thay thế. Nội dung quan trọng có độ tương phản phù hợp và hình ảnh có alt text khi cần.
7. Đã kiểm tra robots.txt. Production không vô tình chặn các trang quan trọng; không dùng robots.txt để bảo vệ nội dung bí mật.
8. Đã kiểm tra noindex. Những trang cần được lập chỉ mục không bị chặn bởi meta robots hoặc X-Robots-Tag.
9. Đã kiểm tra canonical URL. Các trang có URL chuẩn hợp lý, tránh tạo tín hiệu mâu thuẫn và trùng lặp không cần thiết.
10. Đã kiểm tra sitemap.xml. Chỉ đưa những URL phù hợp, có thể truy cập và dự kiến được lập chỉ mục.
11. Đã kiểm tra status code và redirect. Không có lỗi 404/500 bất thường, redirect loop hoặc chuyển hướng sai các URL quan trọng.
12. Đã kiểm tra title, description và heading. Nội dung có tiêu đề rõ ràng, cấu trúc H1-H2 hợp lý và mô tả đúng trang.
13. Đã kiểm tra structured data. JSON-LD phản ánh đúng nội dung, sử dụng loại schema phù hợp và không tạo dữ liệu gây hiểu nhầm.
14. Đã kiểm tra khả năng truy cập nội dung bằng crawler. Nội dung quan trọng có liên kết HTML có thể theo, không phụ thuộc hoàn toàn vào thao tác hoặc JavaScript khó truy xuất.
15. Đã kiểm tra tính nhất quán của thông tin thực thể và nội dung. Tên tổ chức, tác giả, thông tin liên hệ, dịch vụ, giá và nội dung quan trọng thống nhất, có nguồn xác minh khi cần.

Bằng chứng nghiệm thu: Lighthouse Report, Accessibility Review, Crawl Report, kiểm tra URL thực tế, Rich Results Test và báo cáo kiểm tra metadata.

Lưu ý: AEO và GEO không phải lý do để tạo hàng loạt FAQ hoặc schema không cần thiết. Hãy ưu tiên nội dung hữu ích, dữ liệu nhất quán, khả năng truy cập và các tín hiệu kỹ thuật cơ bản.

Nhóm 10. Go-live, giám sát, trách nhiệm vận hành và xử lý sự cố - 15 checklist

1. Đã có Go-live Owner. Một người có thẩm quyền chịu trách nhiệm quyết định triển khai hoặc dừng triển khai.
2. Đã có danh sách người phụ trách. Xác định đầu mối frontend, backend, database, hạ tầng, bảo mật, nghiệp vụ và hỗ trợ khách hàng.
3. Đã có Go-live Timeline. Các mốc backup, deployment, smoke test, xác nhận tích hợp và mở dịch vụ được lập rõ ràng.
4. Đã có Release Notes. Ghi nhận chức năng mới, thay đổi, giới hạn và những điểm cần theo dõi.
5. Đã kiểm tra production secrets và tài khoản quản trị. Không dùng tài khoản mặc định, tài khoản thử nghiệm hoặc khóa truy cập không được quản lý.
6. Đã kiểm tra các tích hợp production. Email, SMS, thanh toán, API đối tác và webhook dùng đúng cấu hình và thông tin xác thực.
7. Đã chạy smoke test sau triển khai. Đăng nhập, chức năng chính, lưu dữ liệu và các API quan trọng hoạt động thực tế.
8. Đã kiểm tra giao dịch thực tế có kiểm soát. Nếu có thanh toán, thực hiện giao dịch được phép theo kịch bản và phương án đối soát phù hợp.
9. Đã xác nhận dữ liệu sau triển khai. Kiểm tra số lượng bản ghi, ràng buộc, số dư hoặc trạng thái quan trọng không bị sai lệch.
10. Đã thiết lập monitoring dashboard. Có thể theo dõi availability, error rate, latency, tài nguyên và các chỉ số nghiệp vụ cần thiết.
11. Đã thiết lập cảnh báo và người nhận. Cảnh báo có ngưỡng phù hợp, kênh nhận rõ ràng và người chịu trách nhiệm phản hồi.
12. Đã có Incident Response Plan. Mô tả quy trình phân loại, xử lý, báo cáo và khôi phục khi phát sinh sự cố.
13. Đã xác định tiêu chí rollback. Những điều kiện buộc phải dừng hoặc quay lại phiên bản cũ được định nghĩa trước.
14. Đã có kế hoạch theo dõi sau Go-live. Xác định khoảng thời gian tăng cường giám sát, người trực và cơ chế tổng hợp vấn đề.
15. Đã có biên bản Go/No-Go. Những người có thẩm quyền xác nhận các hạng mục bắt buộc, ngoại lệ được chấp thuận và quyết định triển khai.

Bằng chứng nghiệm thu: Go-live Plan, Release Notes, Smoke Test Report, Monitoring Dashboard, Incident Plan và Go/No-Go Approval.

4. Những lỗi nào phải dừng Go-live?

Không phải tất cả các lỗi đều có mức độ như nhau.

Ví dụ, một hình ảnh chưa tối ưu dung lượng có thể được lên kế hoạch cải thiện sau triển khai nếu không ảnh hưởng đáng kể đến người dùng.

Nhưng có những tình huống cần dừng để xử lý.

• Lỗ hổng cho phép truy cập dữ liệu người dùng khác mà không có quyền.
• Phát hiện mật khẩu, private key hoặc secrets đang bị lộ và chưa được xử lý.
• Hệ thống tính sai tiền, ghi nhận thanh toán trùng hoặc mất toàn vẹn đơn hàng.
• Không có khả năng phục hồi dữ liệu phù hợp với mức rủi ro của hệ thống.
• Phát hiện vấn đề nghiêm trọng trong phân tách dữ liệu giữa các tenant.
• Website chưa đáp ứng điều kiện pháp lý bắt buộc để bắt đầu hoạt động.
• Những thay đổi database quan trọng chưa được đánh giá và chưa có phương án khôi phục.
• Không xác định được người chịu trách nhiệm xử lý sự cố nghiêm trọng sau triển khai.

Những vấn đề này cần được đánh giá theo tác động thực tế. Với lỗi nghiêm trọng chưa có biện pháp kiểm soát phù hợp, quyết định hợp lý là No-Go.

Không nên dùng một chữ ký chấp nhận rủi ro để hợp thức hóa việc triển khai trái quy định pháp luật hoặc những rủi ro không thể chấp nhận.

5. Cách tổ chức checklist thành tài liệu để AI hỗ trợ kiểm tra

Vì đây là một dự án có AI tham gia, chúng ta có thể tận dụng AI ngay trong bước nghiệm thu.

Tôi đề xuất lưu checklist thành những file Markdown để có thể quản lý phiên bản và sử dụng lại giữa các đợt triển khai.

docs/
|
+-- checklists/
|
+-- README.md |   |
|
+-- pre-coding/ |
|
+-- business.md |
|
+-- data-legal.md |
|
+-- architecture.md |   |
|
+-- post-coding/ |
|
+-- code-quality.md |
|
+-- security.md |
|
+-- data-integrity.md |   |
|
+-- pre-golive/
|
+-- infrastructure.md
|
+-- legal-policies.md
|
+-- ux-seo.md
|
+-- operations.md
|
+-- releases/
+-- release-001/
+-- checklist-results.md
+-- security-report.md
+-- test-report.md
+-- golive-decision.md

AI có thể hỗ trợ đọc repository, kiểm tra cấu hình, đối chiếu tài liệu, chạy lệnh kiểm thử được cho phép và thu thập bằng chứng.

Tuy nhiên, không nên yêu cầu AI tự đánh dấu tất cả PASS nếu chưa có dữ liệu xác minh.

Mỗi mục nên có trạng thái:

• PASS: Đã kiểm tra và có bằng chứng phù hợp.
• FAIL: Đã kiểm tra và phát hiện không đạt.
• PENDING: Chưa kiểm tra hoặc chưa đủ bằng chứng.
• N/A: Không áp dụng, có giải thích.

Prompt mẫu để AI hỗ trợ audit trước Go-live

Bạn đóng vai:
- Senior Software Architect
- Application Security Reviewer
- QA Lead
- DevOps Reviewer

Mục tiêu: Hỗ trợ rà soát dự án trước Go-live.

Nguồn kiểm tra:
- Approved BRD / SRS
- Business Rules
- Architecture Documents
- Source Code
- Automated Test Reports
- Deployment Configuration
- Release Checklists

Quy tắc:
1. Không tự suy đoán thành PASS.
2. Không tự thay đổi production.
3. Không đọc hoặc tiết lộ secrets.
4. Không thực hiện kiểm thử phá hoại

khi chưa được cho phép.
5. Không tự kết luận tuân thủ pháp luật

chỉ dựa trên sự tồn tại của chính sách.
6. Phân biệt phát hiện thực tế,

rủi ro tiềm năng và thông tin còn thiếu.

Với từng checklist:
- ID
- Checklist Item
- Status
- Evidence
- Finding
- Risk Level
- Suggested Remediation
- Owner Recommendation

Chỉ được đánh dấu PASS nếu có bằng chứng xác minh.

Nếu không thể kiểm tra: Đánh dấu PENDING và giải thích.

Cuối báo cáo:
- Critical Findings
- High Risk Findings
- Pending Verifications
- Required Human Approvals
- Recommended Go/No-Go Decision

Quyết định Go-live cuối cùng thuộc người có thẩm quyền.

6. Checklist không chỉ dùng cho ngày Go-live

Một website đã đưa vào vận hành vẫn tiếp tục thay đổi.

Chúng ta có thể cập nhật mã nguồn, thêm chức năng, thay đổi chính sách, tích hợp nhà cung cấp mới hoặc điều chỉnh cách xử lý dữ liệu.

Những thay đổi ấy có thể làm xuất hiện rủi ro mới.

Vì vậy, checklist nên trở thành một phần của quy trình phát triển phần mềm, thay vì chỉ được sử dụng một lần trước khi khai trương website.

Ví dụ:

• Mỗi pull request: chạy code quality và security checks phù hợp.
• Mỗi release: kiểm tra regression, database migration và cấu hình triển khai.
• Khi bổ sung nhà cung cấp dữ liệu: rà soát quyền truy cập, bảo vệ dữ liệu và nghĩa vụ pháp lý.
• Khi thay đổi thanh toán: kiểm thử lại đối soát, trạng thái và idempotency.
• Khi thay đổi công nghệ hoặc kiến trúc: cập nhật threat model, tài liệu và kế hoạch khôi phục.
• Định kỳ: kiểm tra backup, vulnerability, tài khoản có quyền cao và khả năng phục hồi sự cố.

Như vậy, bộ checklist sẽ lớn lên cùng hệ thống nhưng vẫn giữ được cấu trúc thống nhất.

7. Kết luận: Đừng đợi đến ngày Go-live mới bắt đầu kiểm tra

Hơn 10 năm làm việc với phần mềm cho tôi một góc nhìn khá đơn giản: Làm cho một website chạy được là một việc. Đưa nó vào vận hành để nhiều người sử dụng an toàn, ổn định và đáng tin cậy lại là một việc khác.

Với Vibe Coding, khoảng cách giữa ý tưởng và sản phẩm có thể được rút ngắn đáng kể. Nhưng điều đó không có nghĩa chúng ta được phép bỏ qua những bước cần thiết để kiểm tra chất lượng.

Tôi thích sử dụng checklist vì nó giúp biến những điều dễ quên thành những công việc cụ thể, có người phụ trách và có kết quả xác minh.

Trước khi lập trình, hãy kiểm tra yêu cầu, dữ liệu, quy tắc và kiến trúc.

Sau khi AI hoàn thành, hãy kiểm tra mã nguồn, bảo mật, giao dịch và khả năng xử lý lỗi.

Trước khi Go-live, hãy kiểm tra hạ tầng, chính sách, pháp luật, trải nghiệm người dùng và phương án vận hành.

Không có bộ checklist nào bảo đảm phần mềm sẽ không bao giờ xảy ra lỗi. Nhưng một quy trình kiểm tra có trách nhiệm sẽ giúp chúng ta phát hiện sớm nhiều vấn đề và chuẩn bị tốt hơn khi có sự cố.

Tôi đã chia sẻ file Google Sheets gồm 150 checklist để bạn tạo bản sao và sử dụng miễn phí. Hy vọng tài liệu này giúp ích cho những người đang học Vibe Coding, các lập trình viên, nhóm phát triển và cả những người đang chuẩn bị triển khai website đầu tiên của mình.

Nếu trong quá trình sử dụng, bạn nhận thấy một hạng mục quan trọng còn thiếu, đó cũng là cơ hội để chúng ta tiếp tục hoàn thiện bộ checklist.

Với chú Nha 27 tuổi, chia sẻ kiến thức lập trình không chỉ là giải thích một công nghệ hoạt động ra sao. Tôi còn muốn những người đọc bài có thể mang về một thứ gì đó thực sự sử dụng được.

Và biết đâu, một mục kiểm tra nhỏ hôm nay lại giúp cả nhóm tránh được một đêm phải thức trắng sửa lỗi ngày mai.

Như vậy cũng đáng để dành chút thời gian kiểm tra rồi, phải không?

Nguồn tham khảo

• OWASP - Application Security Verification Standard
• NIST - Secure Software Development Framework
• Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15
• Nghị định 356/2025/NĐ-CP về bảo vệ dữ liệu cá nhân
• Luật An ninh mạng số 116/2025/QH15
• Luật Thương mại điện tử số 122/2025/QH15
• Nghị định 248/2026/NĐ-CP về thương mại điện tử
• Luật Giao dịch điện tử số 20/2023/QH15
• Google Search Central - Crawling and Indexing
• W3C - Web Content Accessibility Guidelines