Release plan và rollout theo nấc
Mẫu & ví dụ Launch TemplatesKế hoạch bật tính năng từng nấc sau feature flag: ai thấy trước, ở lại bao lâu, điều kiện lên nấc, tiêu chí rollback bằng số và người được quyền tắt.
Mẫu này giúp bạn
Hiểu deploy, release và launch là ba việc khác nhau, và feature flag cho phép bật tính năng cho từng phần người dùng rồi tắt lại trong vài giây.
Viết release plan có mục tiêu và chỉ số bảo vệ, chọn đúng đơn vị flag và danh sách loại trừ, đặt điều kiện lên nấc và tiêu chí rollback bằng số có tên người được tắt, xử lý riêng phần không đảo ngược được, và ghi nhật ký mỗi lần lên hay lùi nấc.
Mẫu, ví dụ đã điền và cách dùng
Release plan và rollout theo nấc dùng để làm gì?
Release plan trả lời một câu hỏi mà checklist không trả lời: khi code đã nằm trên production, ai được thấy tính năng, theo thứ tự nào, và điều gì khiến chúng ta dừng lại? Với feature flag, deploy và release là hai việc tách rời — code có thể lên production từ hai tuần trước, và người dùng chỉ thấy khi đội bật cho họ.
Mẫu chia release thành các nấc: nội bộ, beta, vài phần trăm, một phần tư, một nửa, toàn bộ. Mỗi nấc có một mục đích riêng (tìm loại lỗi nào, học điều gì), một thời gian ở lại tối thiểu, và một điều kiện bằng số để lên nấc tiếp. Bên cạnh là tiêu chí rollback — cũng bằng số — và tên người được quyền tắt flag mà không cần họp.
Phần hay bị bỏ qua nhất là những gì không đảo ngược được. Tắt flag ẩn được giao diện, nhưng không rút lại được email đã gửi, dữ liệu đã chuyển đổi hay khoản phí đã thu. Một release plan tốt liệt kê những phần đó và xử lý chúng bằng cách khác.
Dành cho: PM · Tech lead · Product Owner · Growth PM (khi một nấc là thí nghiệm A/B)
Dùng khi: Viết khi thiết kế kỹ thuật đã ổn định — thường giữa quá trình xây — vì cách gắn flag ảnh hưởng tới kiến trúc. Chốt cùng checklist ở buổi go/no-go, và cập nhật mỗi lần lên hoặc lùi nấc.
Release plan khác gì với kế hoạch deploy và kế hoạch truyền thông?
| Trả lời | Ai giữ | |
|---|---|---|
| Kế hoạch deploy | Code lên production thế nào, migration dữ liệu chạy lúc nào, rollback code ra sao | Engineering |
| Release plan | Ai thấy tính năng khi nào, lên nấc khi nào, dừng khi nào | PM + Tech lead |
| Kế hoạch truyền thông (launch) | Ai được báo, bằng kênh nào, khi nào | PM + Marketing + Sales |
Ba kế hoạch có ba nhịp. Deploy có thể xong từ tuần trước; release chạy hai đến bốn tuần qua các nấc; truyền thông ra ngoài thường chỉ bắt đầu khi release đã ổn ở nấc lớn. Gộp cả ba vào một ngày là dồn mọi rủi ro vào một đêm.
Bản trắng — copy và dán vào tài liệu của bạn
Một trang, mỗi nấc một khối. Phần rollback và phần không đảo ngược được viết trước khi bật nấc đầu tiên, không phải trong lúc sự cố.
RELEASE PLAN — [Tên tính năng] — Tier [1/2] PM: ...... Tech lead: ...... Ngày viết: ...... Mục tiêu (chỉ số, mức, thời hạn): ...... Chỉ số bảo vệ (không được xấu đi): ...... Flag: ...... Bật theo: [người dùng / tài khoản / vùng / thiết bị] Danh sách loại trừ (ai không bao giờ nằm trong nấc sớm): ...... NẤC 0 — NỘI BỘ Ai: ...... (bao nhiêu người) Mục đích: ...... Ở lại tối thiểu: ...... ngày Lên nấc khi: ...... NẤC 1 — BETA / EARLY ACCESS Ai: ...... Cách chọn: ...... Đã đồng ý dùng bản sớm: có / không Mục đích: ...... Ở lại tối thiểu: ...... Lên nấc khi: ...... Thu phản hồi bằng: ...... NẤC 2 — ......% Ở lại tối thiểu: ...... Lên nấc khi: ...... NẤC 3 — ......% Ở lại tối thiểu: ...... Lên nấc khi: ...... NẤC 4 — ......% Thí nghiệm A/B: có / không Đọc kết quả ngày: ...... NẤC 5 — 100% Điều kiện: ...... ROLLBACK — TẮT FLAG NGAY, KHÔNG CẦN HỌP, NẾU: Kỹ thuật: ...... Sản phẩm: ...... Vận hành: ...... Người được quyền tắt: ...... (một trong ......) Tắt xong thì báo: ...... qua kênh ...... KHÔNG ĐẢO NGƯỢC ĐƯỢC BẰNG FLAG Phần ...... xử lý bằng ...... Phần ...... xử lý bằng ...... NHẬT KÝ NẤC Ngày | Từ nấc | Sang nấc | Số liệu lúc quyết | Người quyết | Ghi chú DỌN FLAG Ngày xoá flag và nhánh code cũ: ...... Người làm: ......
Từng ô điền gì, và vì sao ô đó tồn tại
| Ô | Điền gì | Bỏ trống thì hỏng ở đâu |
|---|---|---|
| Mục tiêu và chỉ số bảo vệ | Chỉ số lần ra mắt muốn đẩy lên, và một đến hai chỉ số không được phép xấu đi. | Không có chỉ số bảo vệ thì không có tiêu chí rollback sản phẩm; đội chỉ biết dừng khi hệ thống lỗi, không biết dừng khi tính năng làm khách bỏ đi. |
| Bật theo | Đơn vị của flag: người dùng, tài khoản doanh nghiệp, vùng, thiết bị. | Bật theo người dùng cho sản phẩm B2B khiến hai nhân viên cùng công ty thấy hai giao diện khác nhau — một nguồn ticket hoàn toàn tự tạo. |
| Danh sách loại trừ | Nhóm không bao giờ nằm trong nấc sớm: khách lớn đang gia hạn hợp đồng, tài khoản có điều khoản đặc biệt. | Một khách chiến lược gặp lỗi ở nấc 5% có thể tốn nhiều hơn toàn bộ giá trị của tính năng. |
| Mục đích mỗi nấc | Nấc đó để tìm loại lỗi gì, hoặc học điều gì. | Không có mục đích thì các nấc thành thủ tục chờ, và đội lên nấc theo lịch chứ không theo bằng chứng. |
| Ở lại tối thiểu | Số ngày hoặc số giao dịch trước khi được lên nấc. | Lên nấc sau một buổi sáng là chưa qua giờ cao điểm, chưa qua chu kỳ đối soát, chưa thấy lỗi chỉ xuất hiện cuối tuần. |
| Lên nấc khi | Điều kiện bằng số, ví dụ tỉ lệ lỗi dưới 0,5% và ticket không tăng quá 10%. | "Khi thấy ổn" nghĩa là lên nấc khi PM muốn lên nấc. |
| Tiêu chí rollback | Ngưỡng kỹ thuật, sản phẩm, vận hành. | Không viết trước thì lúc sự cố là một cuộc họp, và cuộc họp đó diễn ra trong khi lỗi vẫn đang tăng. |
| Người được quyền tắt | Một hoặc hai người có tên; ai trực thì người đó. | Ai cũng có quyền tắt nghĩa là không ai tắt; người trực đêm sẽ ngồi chờ xin phép. |
| Không đảo ngược được | Phần nào flag không cứu được, và cách xử lý riêng cho từng phần. | Đây là nơi những sự cố tồi tệ nhất nằm, chính vì đội tin rằng "có flag rồi, tắt là xong". |
| Nhật ký nấc | Mỗi lần lên hoặc lùi nấc: số liệu lúc đó và người quyết. | Khi readout hay retro, đội cần biết đã lên nấc dựa trên số nào; trí nhớ sau ba tuần không đáng tin. |
Cách viết và chạy release plan
- Viết mục tiêu và chỉ số bảo vệ trước tiên. Chép mục tiêu từ PRD. Chọn chỉ số bảo vệ gần với tiền hoặc với hành động cốt lõi của sản phẩm — tỉ lệ thanh toán thành công, tỉ lệ hoàn thành bài học, tỉ lệ đơn giao thành công.
- Chọn đơn vị flag cùng tech lead. Hỏi: người dùng có chia sẻ màn hình, tài khoản hay dữ liệu với nhau không? Nếu có, bật theo đơn vị lớn hơn.
- Viết từng nấc từ trên xuống, bắt đầu bằng mục đích. Nội bộ để bắt lỗi rõ ràng; beta để học định tính; 1–5% để thấy lỗi ở quy mô; 25% để chỉ số bắt đầu có hình; 50% để đọc thí nghiệm nếu có.
- Viết tiêu chí rollback rồi hỏi người trực một câu: "Nếu chạm ngưỡng này lúc 11 giờ đêm, anh có tắt không?" Nếu câu trả lời là "còn tuỳ", sửa ngưỡng cho tới khi câu trả lời là "có".
- Liệt kê phần không đảo ngược được. Đi qua lần lượt: dữ liệu, tiền, thông báo, giá, tích hợp với đối tác. Mỗi phần cần một cách xử lý — sao lưu, giai đoạn chuyển tiếp, hoặc chỉ gửi thông báo sau nấc lớn.
- Đưa release plan vào buổi go/no-go cùng checklist. Người quyết duyệt cả hai.
- Mỗi lần lên hoặc lùi nấc, ghi nhật ký trong ngày. Một dòng: số liệu, người quyết, lý do. Lùi nấc không phải thất bại; không ghi lại mới là thất bại.
Ví dụ đã điền đầy đủ
HọcVui (giả định) là ứng dụng học tiếng Anh có khoảng 1,2 triệu người học hoạt động mỗi tháng, thu phí gói năm. Tính năng mới: lộ trình học cá nhân hoá — một bài kiểm tra đầu vào 8 phút, sau đó ứng dụng sắp lại thứ tự bài học thay cho lộ trình cố định. Tier 2: không đổi giá, nhưng đổi luồng chính của mọi người học mới.
RELEASE PLAN — Lộ trình cá nhân hoá — Tier 2
PM: Khoa Tech lead: Nhung Ngày viết: 12/05
Mục tiêu: tỉ lệ người học mới hoàn thành 5 bài trong 14 ngày đầu
tăng từ 31% lên 36%, đo 6 tuần sau khi lên 100%.
Chỉ số bảo vệ:
(1) tỉ lệ hoàn thành bài kiểm tra đầu vào không dưới 70%;
(2) tỉ lệ mua gói năm trong 14 ngày không giảm quá 0,5 điểm so với
nhóm chưa bật.
Flag: personalized_path Bật theo: người dùng, CHỈ người học mới
(người học cũ giữ lộ trình đang học để không mất tiến độ)
Loại trừ: tài khoản thuộc 14 trường đối tác — giáo viên giao bài theo
lộ trình cố định; đổi thứ tự bài làm hỏng giáo án của họ.
NẤC 0 — NỘI BỘ: 60 nhân viên tạo tài khoản mới, 4 ngày
Mục đích: bắt lỗi sắp bài sai trình độ, lỗi hiển thị
Lên nấc khi: không còn lỗi chặn; 3 giáo viên nội bộ duyệt 20 lộ trình
mẫu là "hợp lý"
NẤC 1 — BETA: 3.000 người trong danh sách chờ, 10 ngày
Mục đích: học xem bài kiểm tra 8 phút có quá dài không
Lên nấc khi: hoàn thành bài kiểm tra ≥ 70%; không có phàn nàn lặp lại
về độ khó sai
Thu phản hồi: một câu hỏi sau bài thứ 3; 12 cuộc gọi 15 phút
NẤC 2 — 5% người học mới (khoảng 2.800 người), 4 ngày
Lên nấc khi: lỗi API sắp bài dưới 0,3%; tải lộ trình dưới 2 giây ở
phân vị 90
NẤC 3 — 25%, 7 ngày
Lên nấc khi: hai chỉ số bảo vệ trong ngưỡng
NẤC 4 — 50%, thí nghiệm A/B 21 ngày, đọc kết quả 30/06
NẤC 5 — 100% nếu tỉ lệ hoàn thành 5 bài cao hơn nhóm đối chứng ít nhất
2 điểm và hai chỉ số bảo vệ trong ngưỡng
ROLLBACK — TẮT NGAY, KHÔNG CẦN HỌP:
Kỹ thuật: lỗi API sắp bài trên 1% trong 30 phút; mất tiến độ học của
BẤT KỲ người học nào
Sản phẩm: hoàn thành bài kiểm tra đầu vào dưới 60% trong 2 ngày liền,
ở bất kỳ nhóm thiết bị nào
Vận hành: ticket "bài quá khó / quá dễ" trên 40/ngày
Người được quyền tắt: Nhung, hoặc kỹ sư trực
Tắt xong báo: Khoa và support lead qua kênh #release-hocvui
KHÔNG ĐẢO NGƯỢC ĐƯỢC
Người học đã làm bài kiểm tra: tắt flag thì họ quay về lộ trình cố
định nhưng giữ điểm đầu vào, để khỏi bắt làm lại khi bật lại.
Email "lộ trình riêng của bạn đã sẵn sàng": chỉ gửi từ nấc 4.
NHẬT KÝ NẤC
20/05 | 0 sang 1 | 0 lỗi chặn, giáo viên duyệt 20/20 | Khoa
02/06 | 1 sang 2 | hoàn thành kiểm tra 74% | Khoa
06/06 | 2 sang 3 | lỗi 0,1%, tải 1,4 giây | Khoa + Nhung
10/06 | 3 lùi 2 | hoàn thành kiểm tra 58% trên Android cũ | Nhung tắt theo
(bài nghe tải chậm) tiêu chí, 21:00
17/06 | 2 sang 3 | rút bài kiểm tra còn 5 phút: 76% | Khoa
24/06 | 3 sang 4 | chỉ số bảo vệ trong ngưỡng | Khoa
DỌN FLAG: xoá flag và lộ trình cố định cho người mới — sprint 30, NhungDòng 10/06 là lý do release plan tồn tại. Ở nấc 25%, tỉ lệ hoàn thành bài kiểm tra trên điện thoại Android cũ tụt xuống 58% vì bài nghe tải chậm. Nhung tắt flag lúc 21 giờ theo đúng tiêu chí đã viết, không cần gọi ai. Không có tiêu chí, đội rất có thể đã chờ "thêm một ngày cho chắc" và để thêm vài nghìn người học mới có trải nghiệm đầu tiên tồi. Để ý thêm chữ "ở bất kỳ nhóm thiết bị nào" trong tiêu chí sản phẩm — nếu chỉ nhìn con số chung, mức tụt đã bị nhóm iPhone che mất. Và danh sách loại trừ: 14 trường đối tác không bao giờ thấy nấc sớm — một quyết định chỉ người từng nói chuyện với CS mới nghĩ tới.
Hiccups thường gặp và cách xử lý
| Hiccup | Vì sao xảy ra | Xử lý |
|---|---|---|
| Lên nấc theo lịch | Release plan có ngày cho từng nấc nhưng không có điều kiện | Ngày chỉ là thời gian ở lại tối thiểu; chỉ lên nấc khi điều kiện bằng số đạt. |
| Bật theo người dùng cho sản phẩm B2B | Mặc định của công cụ flag | Bật theo tài khoản doanh nghiệp; nếu không làm được, chọn nhóm khách và báo họ trước. |
| Không ai dám tắt flag | Tiêu chí mơ hồ, quyền tắt không rõ | Ngưỡng bằng số và tên người được tắt; tắt theo tiêu chí là thực thi, không phải quyết định. |
| Tưởng tắt flag là xong | Quên phần không đảo ngược được | Liệt kê dữ liệu, tiền, thông báo, giá; xử lý từng phần bằng cách khác. |
| Chỉ nhìn số trung bình | Dashboard mặc định gộp mọi thiết bị, mọi vùng | Tiêu chí lên nấc và rollback xét theo từng nhóm thiết bị hoặc vùng chính. |
| Nấc beta toàn nhân viên và người quen | Dễ tuyển | Beta là khách thật đã đồng ý, đủ đa dạng thiết bị và trình độ. |
| Flag không bao giờ được gỡ | Lên 100% rồi chuyển sang việc khác | Ghi ngày xoá flag và nhánh code cũ vào kế hoạch sprint ngay khi lên 100%. |
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| PM | Quyết lên nấc dựa trên số, và giải thích được với lãnh đạo vì sao 25% hôm nay tốt hơn 100% ngay lập tức |
| Tech lead | Thiết kế flag đúng đơn vị, và có quyền tắt rõ ràng mà không phải xin phép lúc nửa đêm |
| Product Owner | Đưa việc gắn flag, việc dọn flag và các điều kiện lên nấc vào backlog như việc thật |
| BA | Chỉ ra nhóm người dùng nào cần loại trừ khỏi nấc sớm, từ hiểu biết về quy trình và hợp đồng của khách |
| Growth PM | Dùng nấc 50% làm thí nghiệm A/B có nhóm đối chứng, để readout có con số đáng tin |
Definition of done
- Mục tiêu và một đến hai chỉ số bảo vệ được viết ở đầu trang.
- Đơn vị flag và danh sách loại trừ đã được tech lead và CS xác nhận.
- Mỗi nấc có mục đích, thời gian ở lại tối thiểu và điều kiện lên nấc bằng số.
- Tiêu chí rollback bằng số, có tên người được quyền tắt, và người trực đã đồng ý sẽ tắt khi chạm ngưỡng.
- Phần không đảo ngược được đã liệt kê kèm cách xử lý.
- Nhật ký nấc được ghi trong ngày, kể cả các lần lùi nấc; ngày dọn flag đã có trong kế hoạch.
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.