Tối thứ Sáu, một tính năng tính phí mới được triển khai cùng phiên bản backend. Kiểm thử nội bộ đã đạt, nhưng khi mở cho toàn bộ tài khoản, một nhóm khách hàng dùng cấu hình cũ không thể hoàn tất đơn hàng. Đội tắt giao diện mới, song dữ liệu do luồng mới tạo ra vẫn nằm trong hệ thống và cần xử lý riêng.
Lỗi code chỉ là một phần. Đội đã gộp việc triển khai, mở quyền sử dụng và chuyển dữ liệu thành một lần phát hành duy nhất.
Một lần phát hành thiếu điểm kiểm soát
Trước khi mở tính năng
Product biết nhóm mục tiêu nhưng chưa có danh sách tài khoản. Engineering có feature flag, tuy nhiên quyền bật tắt chưa rõ.
Khi xuất hiện lỗi
Support nhận phản ánh qua Zalo, dev xem log, còn product kiểm tra tỷ lệ hoàn tất đơn. Đội chưa có điều kiện chung để tiếp tục hay quay lui.
Feature flag giải quyết phần nào của việc phát hành?
Feature flag cho phép code mới tồn tại trên production nhưng chỉ chạy với nhóm đã chọn. Đội có thể mở cho nhân sự nội bộ, vài tài khoản thử nghiệm hoặc một phân khúc có cấu hình phù hợp. Khi cần, tính năng được tắt mà không phải triển khai lại toàn bộ phiên bản.
Cơ chế này không tự bảo đảm an toàn. Nếu luồng mới đã thay đổi dữ liệu, tạo hóa đơn hoặc gọi hệ thống ngoài, việc tắt flag không hoàn tác tác động đã xảy ra. Flag cũng cần được xóa sau khi tính năng ổn định để giảm số nhánh phải kiểm thử.
Chốt phạm vi người dùng trước khi mở
Nhóm đầu tiên nên đủ nhỏ để giới hạn ảnh hưởng nhưng đủ gần hành vi thật để phát hiện vấn đề. Với sản phẩm B2B, có thể chọn tài khoản nội bộ hoặc khách hàng đã đồng ý thử. Không chọn ngẫu nhiên nếu cấu hình giữa khách hàng khác nhau đáng kể.
Danh sách cần ghi bằng định danh trong hệ thống thay vì chỉ dùng tên công ty trong Google Sheet. Product đặt tiêu chí chọn, engineering xác nhận cách áp dụng, còn support biết tài khoản nào đang dùng luồng mới.
Quy trình phát hành theo từng phạm vi
1. Chốt hành vi và điều kiện nghiệm thu
Product liên kết tính năng với yêu cầu đã duyệt. QA xác nhận dữ liệu thử và kết quả mong đợi.
2. Tạo flag có người phụ trách
Engineering giới hạn môi trường, đặt giá trị mặc định và cấp quyền bật tắt cho vai trò đã thống nhất.
3. Mở cho nhóm nội bộ
Đội kiểm tra bằng dữ liệu được phép sử dụng, không tạo giao dịch nếu chưa có cách hủy.
4. Mở cho nhóm người dùng đầu tiên
Product cung cấp danh sách tài khoản. Engineering ghi điều kiện và thời điểm mở. Support nhận cách chuyển phản hồi.
5. Đọc tín hiệu trong khoảng theo dõi
Đội so sánh lỗi, tỷ lệ hoàn tất và phản hồi với ngưỡng đã chốt. Tín hiệu bất thường phải có người xác minh.
6. Mở rộng hoặc quay lui
Người có quyền quyết định mở phạm vi kế tiếp hoặc tắt flag và xử lý dữ liệu đã phát sinh.
Theo dõi cả tín hiệu kỹ thuật và nghiệp vụ
Tỷ lệ lỗi API thấp chưa chứng minh người dùng hoàn thành tác vụ. Màn hình có thể tải bình thường nhưng trạng thái vẫn bị kẹt hoặc báo giá không chuyển sang bước duyệt.
Engineering theo dõi lỗi, độ trễ, hàng đợi và kết nối phụ thuộc. Product theo dõi số người bắt đầu, hoàn tất, bỏ dở và chuyển trạng thái sai. Support ghi phản ánh theo tài khoản, phiên bản và bước gặp vấn đề.
Nếu luồng phụ thuộc API bên ngoài, các tình huống timeout, gửi lại và yêu cầu trùng phải được chốt từ trước. Bài cách chốt đặc tả API trước khi hai hệ thống tích hợp trình bày phần hợp đồng cần có giữa hai hệ thống.
Kế hoạch quay lui phải bao gồm dữ liệu
Quay lui giao diện thường nhanh hơn quay lui dữ liệu. Trước khi mở tính năng, đội cần biết luồng mới có tạo trạng thái hoặc giao dịch mà phiên bản cũ không hiểu hay không. Nếu có, phải chọn cách giữ, chuyển đổi hoặc đưa bản ghi vào hàng chờ xử lý thủ công.
Việc quay lui cũng cần thứ tự. Có trường hợp phải dừng yêu cầu mới, chờ hàng đợi xử lý hết rồi mới tắt flag. Tắt khi tác vụ đang chạy có thể để lại trạng thái trung gian khó đối soát.
Trách nhiệm khi phát hành và quay lui
Hệ thống và engineering xử lý
- Áp dụng flag đúng tài khoản, môi trường và giá trị mặc định.
- Ghi nhận lỗi, độ trễ, trạng thái hàng đợi và thay đổi cấu hình.
- Dừng luồng mới theo thứ tự kỹ thuật đã chuẩn bị.
- Cung cấp danh sách bản ghi cần kiểm tra sau khi tắt flag.
Con người xác nhận
- Product chốt nhóm người dùng, ngưỡng tiếp tục và ngưỡng dừng.
- Người phụ trách nghiệp vụ quyết định cách xử lý giao dịch đã phát sinh.
- Support liên hệ tài khoản bị ảnh hưởng theo nội dung đã duyệt.
- Người có thẩm quyền xác nhận mở rộng hoặc quay lại luồng cũ.
Khi nào chưa nên dùng feature flag?
Không cần tạo flag cho thay đổi nội dung hoặc tài nguyên tĩnh không ảnh hưởng logic. Flag phù hợp khi đội cần tách thời điểm triển khai khỏi thời điểm sử dụng, giới hạn nhóm người dùng hoặc cần nút tắt nhanh.
Chưa nên mở nếu dữ liệu kiểm thử không đại diện, chưa có người theo dõi hoặc không biết ai được quyền tắt. Quy trình chuẩn bị dữ liệu và tiêu chí nghiệm thu giúp đội xử lý phần kiểm tra trước bước này.
Feature flag điều khiển phạm vi, nhưng không thay thế quyết định sản phẩm. Nếu yêu cầu đổi trong lúc xây, đội cần cập nhật kế hoạch phát hành theo quy trình quản lý thay đổi phạm vi.
Dịch vụ Product Development của Auranium có thể hỗ trợ đội làm rõ yêu cầu, xây cơ chế phát hành và chuẩn bị tiêu chí nghiệm thu cho từng phiên bản sản phẩm.