기능 플래그 및 릴리스 관리

기능 플래그 및 릴리스 관리

1) 릴리스가있는 이유는 무엇입니까?

• 출시 속도 및 보안: 작은 증분 + 인스턴트 롤백.
• 반경 제어: 프로그레시브 롤아웃, 링, SLO 스토퍼.
• 실험 및 A/B: 다변량 플래그, 효과 통계.
• 운영 시나리오: 위험한 지불/게임 경로에 대한 킬 스위치.

주요 원칙: "선박 어둡고 밝게 가능" -미리 전달하고 의식적으로 포함하십시오.

2) 플래그 유형

부울: 온/오프 기능, 비상 정지 플래그 (킬 스위치).
다변량: 동작 (A/B/C 알고리즘, 한계, 계수).
설정/원격 설정: 매개 변수 (타임 아웃, 베팅 제한, 보너스 금액).
권한/권한: 역할/계층별 기능/제한에 대한 액세스.
운영: 트래픽 라우팅 (섀도우 요청, 새 서비스 포함).

3) 아키텍처 및 데이터 흐름

제어 비행기: 콘솔/플래그 서버, 규칙/세그먼트 저장, 감사.
데이터 평면 (SDK/Proxy/Edge): 플래그 획득 및 캐싱, 로컬 규칙 평가 (최소 대기 시간), 사용할 수없는 경우 폴백.

• 풀: SDK는 정기적으로 설정 (ETag/stream) 을 동기화합니다.
• 푸시/스트리밍: 서버 보낸 이벤트/웹 소켓.
• Edge Cache/Proxy: 사용자와 더 가까워지면 p99가 낮아집니다.

• 규칙의 로컬 평가 (핫 경로에서 네트워크 홉없이).
• 타임 아웃 및 포크백 ("차단" 플래그 판독 없음).
• 설정 스냅 샷의 서명/버전 지정.

4) 타겟팅 및 세그먼트

속성: 국가/지역, 언어, 플랫폼, KYC 수준, VIP 수준, 위험률, 계정 연령, 지불 방법, 책임있는 게임 제한.
세그먼트: 버전으로 규칙을 저장했습니다 "소프트" (마케팅) 및 "하드" (규정 준수).
우선 순위/충돌: 명시 적 규칙 순서, 테스트 없이는 "마지막 일치" 가 허용되지 않습니다.
지리/규제: 관할권 별 제품 가용성 플래그; 일 변수 술어 (예: 국가 별 리베이트 금지).

json
{
"flag": "new_withdrawal_flow",
"default": false,
"rules": [
{"when": {"country": "CA", "kyc_level": "FULL"}, "rollout": 25},
{"when": {"segment": "vip_tier_3_plus"}, "rollout": 100},
{"when": {"country": "DE"}, "force": false}
],
"expiresAt": "2026-03-31T00:00:00Z"
}

5) 프로그레시브 롤아웃: 전략

카나리아:%: SLO 자동 정지로 1% → 5% → 25% → 50% → 100%.
반지: 내부 팀 → 베타 사용자 → 한 지역 → 전 세계.
장치/클라이언트 별 샘플링: 끈적 끈적함 (해시 ID) 을 고려하십시오.
그림자 트래픽: 사용자에게 영향을 미치지 않으면 서 새 경로에 대한 요청을 복제합니다.
어두운 발사: 활성화되었지만 보이지 않음 (메트릭 수집, 캐시 예열).

• p95 API 대기 시간 '철회'> 10 분 이내에 + 15% 감소.
• 오류 5xx> 0. 5% 또는 결제 제공 업체의 오류 증가> + 0. 오후 3시
• 세그먼트의 임계 값을 초과하는 사기/위험 점수 경고.

6) 킬 스위치

SRE/On-Call에서 볼 수있는 별도의 플래그 클래스.
TTL 캐시 (밀리 초) 로 로컬 점수를 보장합니다.
환불 불가능한 단점: 이유 + 사후 티켓이 필요합니다.
통합 자동 조치: 보너스 비활성화, 지불을 수동 모드로 이전, 공급자 X의 예금 금지.

7) CI/CD 및 GitOps와의 통합

CI: 플래그 구성표, 보푸라기 규칙, 익명화 된 샘플에 대한 드라이 런 타겟팅 검증.
CD: 아티팩트 (semver), 민감한 플래그에 대한 "승인 게이트" (지불/준수) 로 플래그를 구성합니다.
GitOps: 별도의 구성 저장소에있는 플래그, 병합 요청 = 이벤트 변경, 상자 밖으로 감사.

8) 안전 및 준수

RBAC/ABAC: 관심을 창출/포함/제기 할 수있는 사람; 업무 분리 (개발자

감사: 누가/언제/무엇/왜; 사건과 비교하여 정당화 (티켓/JIRA).
PII 최소화: 익명화/해싱을 통한 타겟팅 속성.
SDK/프록시에서 스냅 샷 시그니처 무결성 점검.
구성 요소 전달을위한 SLA: "안전한 불이행" 으로 분해됩니다.

9) 관찰 가능성 및 지표

• 플래그 전파 시간 (p50/p95), 로컬 캐시의 적중률, 업데이트 빈도.
• 활성 플래그 수/폐기/매달림 수 (날짜별로 제거되지 않음).
• SLO 가드: 대기 시간, 오류, 변환, 공급자 안정성.

• DORA: 고갈 속도, 스위치 켜기 시간, 스위치 켜기 후 고장률, MTTR.
• A/B 지표: CR, ARPPU, LTV 신호, 사기 점수에 미치는 영향.

10) 플래그 수명주기

1. 설계: 대상/메트릭/소유자/만료 날짜 ('만료'), 롤백 시나리오.

2. 구현: SDK 통화, 폴백, 원격 측정 "노출 "/" 결정"

3. 롤아웃: 프로그레시브 서브 + SLO 게이트.
4. 안정화: 효과를 수정하고 문서/뿌리를 업데이트하십시오.
5. 정리: 코드 분기를 제거하고 깃발을 닫고 "잔차" 감사.

11) 구현 예

11. 웹/노드 1 개. js

ts
// Инициализация SDK (псевдо)
const flags = await sdk.init({ sdkKey: process.env.FLAGS_KEY, user: { id: userIdHash, country, vipTier } });

// Не блокировать рендер:
const showNewCashout = flags.bool("new_withdrawal_flow", false);

if (showNewCashout) {
renderNewFlow();
} else {
renderClassic();
}

11. 2 코 틀린/JVM

kotlin val client = FlagsClient(sdkKey = System.getenv("FLAGS_KEY"))
val context = UserContext(id = userHash, country = country, kycLevel = kyc)
val enabled = client.getBoolean("risk_guard_withdrawals", default = true, context = context)
if (!enabled) {
// аварийный режим: все выводы в manual review routeToManual()
}

11. 3 NGINX (맵을 통한 외부 토글)

nginx map $http_x_feature $cashout_new {
default 0;
"~enabled" 1;
}

location /withdraw {
if ($cashout_new) { proxy_pass http://new_flow; }
if (!$cashout_new) { proxy_pass http://classic_flow; }
}

12) 위험 관리 및 점진적 단계

포함 단계: 직원의 1% → 5% "베타" → 10% RU → 25% EU → 100% DE (규제 기관).
제한자: max. 1 단계/30 분; 15 분 창당 메트릭의 안정성 요구 사항.
자동 정지: 플랫폼 수준 정책 (아래 OPA 참조).

rego package flags.guard

deny[msg] {
input.flag == "new_withdrawal_flow"
input.metrics["withdraw_5xx_rate"] > 0.5 msg:= "Stop rollout: withdraw 5xx too high"
}

13) 액세스 제어 및 승인

유형 변경: 표준 (보안) vs 민감성 (지불/지급/제한).
승인: 제품 소유자 + 기술. 책임있는 사람 + 규정 준수 (관할 구역).
시간 창 (동결): 고위험 기간 (프라임 타임, 주요 토너먼트) 에 포함/확장 금지.

14) 실험 및 통계

노출 이벤트: 플래그의 결정을 속성으로 기록하십시오.
분석: 현재 롤아웃 값, 세그먼트, 변환/오류에 미치는 영향.
통계 점검: 올바른 분할, 제어 공변량 (장치/지리).
윤리 및 규제: 현지 법률에 의해 제한되는 세분화를 피하십시오.

15) 반 패턴

핫 패스에서 SDK 네트워크 호출 차단

SLO 가드/자동 정지없이 활성화

코드에서 '만료', '지점 묘지' 가없는 수명이 긴 깃발.
PII의 과도한 타겟팅, 속성의 익명화 부족.
고위험 흐름에 대한 킬 스위치가 없습니다 (예금/인출/보너스).
"비밀" 수동 플래그는 감사 및 정당화없이 편집됩니다.

16) 구현 점검표 (0-60-90)

0-30 일

플래그 플랫폼 선택/셀프 호스트 준비 (SDK, 프록시, 캐시).
스키마 ('플래그', '소유자', '목적', '만료', '위험 _ 레벨') 를 입력하십시오.
SLO 메트릭을 플랫폼에 연결합니다 (대기 시간/키 API 오류).

31-60 일

민감한 플래그, OPA 가드의 승인을 추가하십시오.
프로그레시브 전략 (%/ring), 킬 스위치 패널을 설정합니다.

CI에 플래그 구성표 린터가 포함되어 있습니다. 첫 번째 "매달림" 을 제거하기 시작합니다

61-90 일

GitOps와의 완전한 통합 (MR 플래그 편집, 감사).
비주얼 대시 보드: 커버리지 SDK, 배포 시간, 캐시 적중%.
정기적 인 "Flag Debt Day": 코드 삭제 및 플래그 종료.

17) 성숙도 지표

기술: p95 구성 수락 <5 초; 캐시 적중률 SDK> 95%; '만료'> 90% 의 플래그.

프로세스: 승인을받은 100% 민감한 플래그; 평균 "롤백 시간" <3 분

코드 위생: 플래그의 비율은 전 세계적으로 포함 된 후 30 일 이내에 종료됩니다> 80%.

비즈니스 효과: 개선 된 DORA

18) 응용 프로그램: 템플릿 및 정책

플래그 구성표 (YAML)

yaml flag: new_withdrawal_flow owner: payments-team risk_level: high purpose: "Новый поток вывода средств"
expiresAt: "2026-03-31T00:00:00Z"
sla:
propagation_p95_ms: 3000 slo_guards:
withdraw_p95_ms_increase_pct: 15 withdraw_5xx_rate_pct: 0.5 approvals:
required: ["product_owner","tech_lead","compliance"]

영원한 플래그 정책 없음 (린터의 조건부)

yaml rules:
- check: expiresAt max_days_from_now: 180 action: error

SDK 이벤트 계약 (노출)

json
{
"event": "flag_exposure",
"flag": "new_withdrawal_flow",
"variant": "on",
"userKey": "hash_abcdef",
"context": {"country":"CA","vipTier":"3"},
"traceId": "9f1c...a2",
"ts": 1730623200000
}

19) 결론

Feature Flags는 변경을위한 "볼륨 노브" 입니다. 프로그레시브 포함, SLO 가드, 하드 감사 및 정기적 인 걸레질을 결합하고 플래그를 CI/CD 및 GitOps에 바인딩하십시오. 결과적으로 릴리스는 빈번하고 관리 가능하며 안전하며 사고의 위험을 예측하고 통제 할 수 있습니다.