Feature flag thực chiến: Phát hành tính năng an toàn không cần deploy lại

Feature flag tách thời điểm deploy code khỏi thời điểm phát hành tính năng. Nhóm phát triển có thể đưa code lên production ở trạng thái tắt, mở cho nhân viên, tăng dần tỷ lệ người dùng và tắt nhanh khi có sự cố mà không cần build lại. Nhưng nếu thiếu vòng đời, flag sẽ trở thành cấu hình sống vĩnh viễn và làm mọi nhánh code khó hiểu hơn.

Deployment không phải release

Deployment đưa artifact đến môi trường. Release quyết định ai được dùng hành vi mới. Feature flag nằm tại điểm quyết định runtime:

const enabled = flags.getBooleanValue(
  'checkout-v2',
  false,
  { targetingKey: user.id, plan: user.plan }
);

return enabled ? checkoutV2(order) : checkoutV1(order);

Giá trị mặc định là một phần của thiết kế an toàn. Với tính năng mới chưa được kiểm chứng, fallback thường là false. Với kill switch bảo vệ hệ thống, tên và ngữ nghĩa nên rõ để lúc khẩn cấp không bật nhầm.

Bốn loại flag phổ biến

Không dùng release flag như hệ thống phân quyền. Quyền truy cập phải được kiểm tra phía server, có audit và mặc định từ chối.

Rollout theo phần trăm phải ổn định

Không gọi random cho mỗi request. Cùng một người có thể lúc thấy giao diện cũ, lúc thấy giao diện mới, làm hỏng trải nghiệm và dữ liệu thử nghiệm. Hãy hash ổn định:

bucket = hash(flagKey + ':' + targetingKey) % 10000
enabled = bucket < rolloutBasisPoints

targetingKey có thể là user, account hoặc tenant tùy đơn vị cần nhất quán. Với B2B, rollout theo tenant thường an toàn hơn rollout từng user vì mọi thành viên dùng cùng workflow.

Evaluation context: đủ dùng, không gom PII tùy tiện

OpenFeature chuẩn hóa evaluation API, provider, context và hook. Context có thể chứa application, region, tenant, plan hoặc targeting key. Chỉ đưa thuộc tính thực sự cần cho rule; tránh email, tên và dữ liệu nhạy cảm khi một ID giả danh đã đủ.

Quy tắc cần có thứ tự dễ đọc: override khẩn cấp, allowlist nội bộ, điều kiện tương thích, rollout phần trăm, cuối cùng là default. Ghi lại reason/variant thay vì copy toàn bộ context vào log.

Client-side hay server-side?

• Server-side: phù hợp logic nghiệp vụ, thuật toán, tích hợp và kiểm soát dữ liệu. Giá trị flag không bị người dùng sửa trực tiếp.
• Client-side: phù hợp trình bày giao diện, nhưng mọi flag tải xuống đều có thể bị quan sát. Không dùng để bảo vệ secret hoặc authorization.

Nếu cả frontend và backend cùng phụ thuộc một rollout, backend vẫn phải là nguồn quyết định cho hành vi có ảnh hưởng dữ liệu. Tránh để hai phía evaluate theo context khác nhau.

Điều gì xảy ra khi hệ thống flag lỗi?

SDK nên cache cấu hình cục bộ và evaluation không nên gọi HTTP đồng bộ trên từng request. Xác định rõ:

• Giá trị mặc định theo từng flag.
• Thời gian cho phép dùng cache cũ.
• Hành vi khi provider chưa sẵn sàng hoặc sai kiểu dữ liệu.
• Cảnh báo khi đang dùng default vì lỗi, không phải vì rule.

Không có một quy tắc fail-open cho mọi flag. Tính năng trang trí có thể bật theo mặc định; thanh toán mới nên quay về luồng cũ; quyền truy cập phải fail closed.

Quan sát rollout theo variant

Dashboard tổng có thể che lỗi vì chỉ 5% traffic dùng code mới. Mọi golden signal cần tách theo variant: request count, error rate, latency, conversion và business invariant. Log evaluation nên chứa flag key, variant, reason, provider và version ruleset; hạn chế giá trị/context nhạy cảm.

Đặt ngưỡng dừng trước khi rollout: ví dụ error rate tăng quá mức cho phép hoặc p95 vượt SLO. Kill switch phải được thử trước sự cố và chỉ người có quyền mới thay đổi được.

Quy trình rollout gợi ý

1. Deploy với flag tắt và kiểm tra đường cũ.
2. Bật cho developer/nhân viên nội bộ.
3. Mở canary 1%, quan sát đủ một chu kỳ tải.
4. Tăng 5%, 25%, 50%, 100% theo checkpoint.
5. Dừng hoặc rollback flag nếu vượt guardrail.
6. Sau khi ổn định, xóa đường cũ và xóa flag.

Thời gian quan sát phải phù hợp lưu lượng và chu kỳ nghiệp vụ; năm phút không đại diện cho job cuối ngày hay hóa đơn cuối tháng.

Kiểm thử mà không nhân đôi mọi tổ hợp

• Unit test đường bật và tắt ở điểm quyết định chính.
• Contract test kiểu dữ liệu, default và context bắt buộc.
• Integration test provider lỗi, timeout và cache cũ.
• E2E tập trung vào luồng quan trọng thay vì mọi tổ hợp flag.
• Production smoke test cho cohort nội bộ trước rollout công khai.

Nhiều flag tương tác tạo số tổ hợp tăng theo cấp số nhân. Giảm số flag sống đồng thời và tránh nhánh lồng nhau quan trọng hơn cố test mọi tổ hợp.

Dọn flag là một phần của Definition of Done

Mỗi flag cần owner, mục đích, ngày tạo, ngày hết hạn, default và ticket xóa. Khi rollout đạt 100% và ổn định, tạo PR xóa nhánh cũ, rule, dashboard tạm và flag trên control plane. Có thể dùng lint hoặc báo cáo để cảnh báo flag quá hạn.

Checklist production

• Key ổn định, tên phản ánh hành vi, không phản ánh implementation tạm thời.
• Default an toàn và được test khi provider không hoạt động.
• Rollout hash theo user/account/tenant nhất quán.
• Không dùng client flag thay authorization.
• Metrics và log phân tách theo variant nhưng không lộ PII.
• Thay đổi rule có RBAC, audit log và quy trình khẩn cấp.
• Mỗi release flag có owner và ngày xóa.

Kết luận

Feature flag là công cụ kiểm soát rủi ro phát hành, không phải nơi cất code dở dang vô thời hạn. Khi có default an toàn, rollout ổn định, telemetry theo variant, kill switch đã thử và kỷ luật xóa flag, đội ngũ có thể phát hành nhỏ hơn, học nhanh hơn và phục hồi mà không phụ thuộc một lần deploy mới.

Tài liệu tham khảo

• OpenFeature: Introduction
• OpenFeature: Evaluation Context
• OpenTelemetry: Feature flag semantic conventions