Checklist go-live ngắn gọn

By Better Wise

Bạn đã có môi trường tách bạch, secrets được quản lý, smoke test và E2E chạy được, feature flag để tắt tính năng lỗi, và một bản backup trước khi deploy. Giờ là lúc gom tất cả lại thành một tờ giấy A4 mà bạn dám đọc to trước khi bấm nút. Bài này không dạy lại các kỹ thuật đó, nó dạy cách biến chúng thành một danh sách quyết định: deploy hay hoãn.

Sau bài này, bạn phải làm được:

• Viết checklist go-live dưới 10 mục, mỗi mục kiểm chứng được bằng bằng chứng cụ thể.
• Gắn cho mỗi mục một câu trả lời: nếu mục này hỏng thì rollback thế nào.
• Phân biệt ba kết luận: GO, GO có điều kiện, NO-GO.
• Chạy checklist hai lần: T-1 ngày và T-0 (ngay trước khi deploy).

Checklist ngắn để người ta còn đọc

Một checklist 40 mục trông rất chuyên nghiệp và sẽ bị bỏ qua ở mục thứ 12. Checklist 8 đến 10 mục thì người trực đọc hết, và đọc to được trong 5 phút. Đó là toàn bộ lý do nó phải ngắn.

Ba tiêu chuẩn để một mục được giữ lại:

1. Kiểm chứng được. Phải có bằng chứng: link pipeline xanh, output lệnh, ảnh chụp màn hình, tên file backup. "Em nghĩ là ổn" không phải bằng chứng.
2. Trả lời được câu hỏi rollback. Mỗi mục phải kèm: nếu mục này hỏng, ta lùi bằng cách nào và mất bao lâu.
3. Có người chịu trách nhiệm. Một cái tên, không phải "team".

Nếu một mục không thoả cả ba, nó không thuộc checklist go-live. Nó thuộc tài liệu khác.

Bộ 10 mục cho một buổi go-live

Đây là khung tôi dùng. Bạn thay tên công cụ cho khớp project của mình, nhưng đừng thêm mục thứ 11 nếu chưa bỏ mục nào.

Mục 4, 5, 7 là nhóm dữ liệu. Tôi xếp chúng vào diện không thương lượng vì mất dữ liệu thì không rollback nào cứu được.

Nhóm 10 mục này cũng chính là các điểm kiểm tra: _____ chứ không phải cảm giác, và mỗi mục phải trả lời được câu hỏi nếu hỏng thì _____ thế nào. Checklist chạy hai lần: T-1 ngày và _____ ngay trước khi deploy. Riêng mục backup và migration fail thì kết luận bắt buộc là _____, không có ngoại lệ. Còn feature flag đóng vai trò _____, cho phép tắt tính năng lỗi mà không cần deploy lại.

Đọc checklist để ra quyết định GO hay NO-GO

Checklist không phải tờ khai, nó là công cụ ra quyết định. Đọc lần lượt từng mục, mỗi mục chỉ có ba kết quả: đạt, không đạt, hoặc đạt nhưng có điều kiện.

• GO: cả 10 mục đạt.
• GO có điều kiện: chỉ những mục thuộc nhóm vận hành (kill switch, monitoring) chưa đạt, và bạn có cách bù ngay trong 10 phút. Phải ghi rõ ai theo dõi và theo dõi đến khi nào.
• NO-GO: bất kỳ mục nào thuộc nhóm dữ liệu, secrets, CI, hoặc rollback không đạt.

flowchart TD
  Start["📋<br/>Đọc 10 mục"] --> Data{"Nhóm dữ liệu<br/>backup, migration, rollback"}
  Data -- Fail --> NoGo["⛔<br/>NO-GO"]
  Data -- Pass --> Ops{"Nhóm vận hành<br/>kill switch, alert"}
  Ops -- Fail --> Cond["⚠️<br/>GO có điều kiện"]
  Ops -- Pass --> Go["🚀<br/>GO"]

Lưu ý về thời điểm: chạy T-1 để kịp sửa, và chạy T-0 để chắc chắn không có gì thay đổi trong 24 giờ qua. Nếu giữa T-1 và T-0 có commit mới, mục 2 và mục 3 reset về chưa đạt.

Bài tập 1: Viết lại mục tồi

Sáu mục dưới đây được gửi cho tôi tuần trước. Mục nào không dùng được cho go-live, và viết lại thế nào?

1. Code đã được review kỹ.
2. Không có lỗi nghiêm trọng nào.
3. Đã backup database.
4. Feature flag đã bật cho tính năng thanh toán.
5. Team cảm thấy tự tin.
6. Đã test trên máy anh Nam.

Xem đáp án

Cả 6 mục đều không dùng được, vì không mục nào có bằng chứng hoặc điều kiện đạt rõ ràng. Cách viết lại:

1. Pull request đã merge, có ít nhất 1 approval, link PR ghi trong ticket.
2. Không thay bằng "không có lỗi". Thay bằng: "Không còn issue mức blocker hoặc critical đang mở cho milestone này".
3. "Backup mới nhất dưới 24h, tên file: db-YYYYMMDD.sql, đã thử restore trong 30 ngày gần nhất".
4. "Feature flag payment_v2 đã bật trên production và đã tắt thử trên staging, thời gian tắt dưới 1 phút".
5. Bỏ hẳn. Cảm giác không phải bằng chứng.
6. "Đã chạy E2E trên staging lúc 14:00, report: link".

Bài học: mỗi mục phải kết thúc bằng một thứ mở ra xem được.

Bài tập 2: Ba tình huống, ba quyết định

Đọc 10 mục ở bảng trên và chọn GO, GO có điều kiện, hay NO-GO.

• A. Tất cả đạt, trừ mục 6: feature flag mới tạo, chưa kịp tắt thử trên staging.
• B. Tất cả đạt, trừ mục 4: backup mới nhất là 3 ngày trước, lần restore thử gần nhất là 2 tháng trước.
• C. Tất cả đạt, trừ mục 9: người trực sẽ đi họp từ 16:00, deploy lúc 15:30.

Xem đáp án

• A. GO có điều kiện. Đây là mục vận hành. Điều kiện: tắt thử flag trên staging ngay, chụp màn hình, hoặc chấp nhận rollback bằng cách deploy lại phiên bản trước nếu flag không hoạt động.
• B. NO-GO. Nhóm dữ liệu, và bằng chứng restore quá cũ. Backup chưa từng được restore thử thì coi như chưa có backup. Làm một bản backup mới và restore thử sang môi trường tạm, rồi mới deploy.
• C. GO có điều kiện, với điều kiện cụ thể: dời deploy lên 14:00, hoặc đổi người trực. Không có ai theo dõi trong 30 phút đầu thì bạn đang deploy mà không có người phát hiện lỗi.

Mấy chỗ checklist tự viết hay hỏng

• Nhồi thêm mục sau mỗi sự cố. Sự cố xảy ra là thêm một mục, sau một năm bạn có 30 mục và không ai đọc. Cách đúng: thêm mục mới thì gộp hoặc bỏ một mục cũ, giữ trần 10.
• Viết mục dạng "đã kiểm tra X". Đổi thành "X đạt khi có Y". Không có Y thì không tính.
• Bỏ qua bước chạy T-0. Rất nhiều lần hỏng nằm trong 24 giờ cuối: một biến env bị đổi, một secret bị rotate, một migration mới được thêm.
• Không ai có quyền nói no-go. Nếu người viết checklist cũng là người duy nhất muốn deploy, bạn không có quy trình, bạn có một lời tự cho phép.
• Deploy ngoài cửa sổ có người trực. Nếu không có ai theo dõi trong 30 phút đầu, hãy dời lại. Lỗi phát hiện sau 6 tiếng đắt hơn nhiều.

Chốt lại trước khi bấm deploy

• Checklist go-live dưới 10 mục, mỗi mục có bằng chứng và có câu trả lời rollback.
• Nhóm dữ liệu (backup, restore, migration, rollback) fail là NO-GO, không thương lượng.
• Chạy T-1 để kịp sửa, chạy T-0 để chắc chắn không có gì đổi.
• Có một người trực sau deploy và một người có quyền nói "hoãn".

Checklist chỉ nói bạn có nên bấm nút hay không. Nó không nói phải làm gì khi mọi thứ đổ xuống sau khi bấm. Bài tiếp theo, Runbook phát hành và xử lý sự cố sau deploy, sẽ dựng đúng phần đó: ai làm gì trong 15 phút đầu tiên khi dashboard chuyển đỏ.

Front: Checklist go-live nên dài bao nhiêu mục? Back: Dưới 10 mục, đủ ngắn để đọc hết và đọc to trong khoảng 5 phút.

Front: Ba tiêu chuẩn để giữ một mục trong checklist go-live là gì? Back: Kiểm chứng được bằng bằng chứng, trả lời được câu hỏi rollback, và có một người chịu trách nhiệm.

Front: Bằng chứng hợp lệ cho một mục checklist là gì? Back: Link pipeline xanh, output lệnh, report E2E, tên file backup. Không phải cảm giác hay lời khẳng định.

Front: Mục backup fail thì kết luận là gì? Back: NO-GO tuyệt đối, vì mất dữ liệu thì không rollback nào cứu được.

Front: Khi nào dùng kết luận GO có điều kiện? Back: Khi chỉ các mục vận hành (kill switch, monitoring) chưa đạt và có cách bù ngay trong khoảng 10 phút.

Front: Checklist go-live được chạy vào những thời điểm nào? Back: T-1 ngày để kịp sửa, và T-0 ngay trước khi deploy để chắc chắn không có gì thay đổi.

Front: Nếu giữa T-1 và T-0 có commit mới thì sao? Back: Mục CI xanh và mục E2E trên staging reset về chưa đạt, phải chạy lại.

Front: Vì sao mục 'team cảm thấy tự tin' bị loại? Back: Vì không kiểm chứng được và không có bằng chứng mở ra xem được.

Front: Nhóm mục nào là không thương lượng trong checklist? Back: Nhóm dữ liệu và an toàn: backup, restore, migration, rollback, secrets.

Front: Feature flag giúp gì trong quyết định go-live? Back: Nó là kill switch: tắt tính năng lỗi mà không cần deploy lại, nên hạ mức rủi ro của mục vận hành.

Front: Vì sao phải có người trực sau deploy? Back: Để phát hiện lỗi trong 30 đến 60 phút đầu, thay vì biết sau vài tiếng khi thiệt hại đã lớn.

Front: Cách xử lý khi muốn thêm mục thứ 11 vào checklist? Back: Gộp hoặc bỏ một mục cũ để giữ trần 10 mục, tránh checklist phình ra và bị bỏ qua.

Front: Ai phải có quyền nói no-go? Back: Một người cụ thể, độc lập với người đang muốn deploy, và quyền đó phải ghi rõ trong mục cuối của checklist.