Feature Flags-ը և fich արտադրությունը

Feature Flag (FF) կառավարվող պայման է, որը ներառում է/անջատում համակարգի վարքագիծը առանց կոդի։ Դրոշները թույլ են տալիս, որ ֆիչիները ապահով, օգտագործողների/շուկաների/տենանտների խմբերը, արագ անջատեն խնդրահարույց բաղադրիչները, փորձարկումներ կատարեն և լուծեն պարամետրերը rantaime-ում։

Հիմնական նպատակները

Նվազեցնել blast radius-ը թողարկումների ժամանակ։

Կիսել ակտիվությունը։

Տալ թափանցիկ կառավարում աուդիտի, SLO-ի և «մեկ կլիկի» հետ։

1) Դրոշների տեսակները և երբ դրանք կիրառվեն

Release flags-ը նոր ֆիչիի (dark canary deframp-up-up-up - 100%) հիբրիդային պաշտպանություն է։

Ops/kill-switch-ը կախվածության ակնթարթային անջատումն է (պրովայդեր, ենթահամակարգ, ծանր հաշվարկներ)։

Experiment (A/B, multi-variant) - տարբերակների բաժանումը (weights, sticky bucketing)։

Permission/Entitlect-ը հասանելիությունն է դերերի/պլանների/պլանների։

Remote Express-ը վարքի պարամետրերն են (շեմն, թայմաուտը, բանաձևը) դրոշից/եզրից։

Migration flags-ը տվյալների սխեմաների/ուղիների կոդն է (տեղափոխումը նոր ինդեքսին/BD/endpoint)։

Anti-pattern: Նույն դրոշը «ամեն ինչի մասին» 'ջարդեք ֆիչին, նախկին սվիտչը և պարամետրերը։

2) Դրոշի տվյալների մոդելը (նվազագույն)

yaml flag:
key: "catalog. new_ranker"
type: "release"    # release      ops      kill      experiment      permission      config     migration description: "New Directory Ranking"
owner: "search-team@company"
created_at: "2025-10-01T10:00:00Z"
ttl: "2026-01-31" # delete deadline after 100% enable rules:
- when:
tenant_id: ["brand_eu","brand_latam"]
region: ["EE","BR"]
user_pct: 10 # progressive percentage then: "on"
- when:
kyc_tier: ["unverified"]
then: "off"
variants: # for experiments
- name: "control"; weight: 50
- name: "v1"; weight: 30
- name: "v2"; weight: 20 payload:
v1:
boost_freshness: 0. 3 boost_jackpot:  0. 2 v2:
boost_freshness: 0. 2 boost_jackpot:  0. 4 prerequisites: # dependent flags/schema versions
- key: "catalog. index_v2_ready"
must_be: "on"
audit:
require_ticket: true change_window: "09:00-19:00 Europe/Kyiv"
safeguards:
max_rollout_pct: 50 # stop threshold auto_rollback_on:
p95_ms: ">200"
error_rate: ">2%"

3) Գնահատումը և թարթեգինգը (evaluation)

Ключи таргетинга: `tenant_id, region/licence, currency, channel, locale, role, plan, device, user_id, cohort, kyc_tier, experiment_bucket`.

Գնահատման կարգը 'prerequisites deny կանոնները wwww.allow-defolt։

Sticky bucketing: Փորձարկումների համար քաշեք կայուն շարժիչ (օրինակ ՝ «hash (user _ id, flag _ key)», որպեսզի օգտագործողը միշտ մեկ տարբերակ ստանա։

Prindocod

ts result = evaluate(flag, context)  // pure function if (!prereqs_ok(result)) return OFF if (deny_match(result, ctx)) return OFF if (allow_match(result, ctx)) return resolve_variant_or_on(result, ctx)
return flag. default

4) FF-ի բաշխումը և ճարտարապետությունը

Տարբերակները

Server-side MSK (Explano) 'ճշմարտության և քեշի աղբյուրները backend- ում։ տրամաբանության միավորում։

Edge/CDN evaluation: Արագ targeting պարագծի վրա (որտեղ չկա PII/գաղտնիքներ)։

Client-side CPK-ը 'երբ անհրաժեշտ է UI-ի կերպարը, բայց միայն նվազագույն ենթատեքստով և առանց զգայուն կանոնների։

Directions-as-Code-ը 'դրոշների պահպանումը, CI, rollout-ի միջոցով։

Ռազմավարության Քեշը

Startup bootstrap + streaming corates (SSE/gRPC) + fallback դեպի վերջին։

SLA «freshness» դրոշները ՝ p95 245

5) Արտադրության ռազմավարությունը

5. 1 Dark Launch

Ֆիչը միացված է, բայց անտեսանելի է օգտագործողին։ հավաքում ենք փոխաբերություններ և սխալներ։

5. 2 Canary

Մենք միացնում ենք 1-5 տոկոսը մեկ իրավասության/տենանտեի մեջ։ դիտարկենք p95/p99, սխալներ, ծրարներ։

Stop conditions-ը փոխաբերությունների շեմի ձգումներ են։

5. 3 Progressive Rollout

10 տոկոսը 25 տոկոսն է: 50 տոկոսը 100 տոկոսն է 'ձեռքով/avto-veriation ժամանակացույցով։

5. 4 Shadow / Mirroring

Մենք կրկնօրինակում ենք հարցումները նոր ճանապարհին (առանց տեսանելի էֆեկտի) և համեմատում ենք արդյունքները/լատենտությունը։

5. 5 Blue/Green + FF

Մենք շրջում ենք երկու տարբերակ, դրոշը պտտվում է գլանափաթեթով և փոխում կախվածությունը հատվածներով։

6) Կախվածություն և քրոս-ծառայողական խորհրդատվություն

Օգտագործեք prerequisites և «health դրոշներ» պատրաստակամության համար 'ինդեքսը կառուցված է, միգրացիան։

Համակարգումը իրադարձությունների միջոցով '«FlagChanged (flag _ key, scope, new _ state)»։

Կրիտիկական պարամետրերի համար օգտագործեք երկտեղանոց կոդեր

1. միացրեք read-ուղին No. 2) ստուգել մետրերը թիվ 3) միացրեք write/side-effects-ը։

Ծառայողական պայմանագրեր 'դեֆոլտը պետք է ապահով լինի (fail-safe OFF)։

7) Դիտարկումը և SLO-ն

Դրոշի/տարբերակը/սեգմենտը

`flag_eval_p95_ms`, `errors_rate`, `config_freshness_ms`.

Բիզնես մետրիկները ՝ «ctr», «conversion», «ARPU», «retention», guardrails (օրինակ, RG-միջադեպեր)։

Ավտոմատ SLO շեմերը ավտոկատոֆի համար։

Լոգա/թրեյսինգ 'ավելացրեք «flag _ key», «variance», «decision _ source» (server/edge/client), «prodext _ hash»։

Dashbords: «սանդուղք» rollout-ը 'շեմերով, heatmap սխալներով հատվածներով։

8) Անվտանգությունն ու համադրումը

PII նվազեցումը կոնտեքստում։

RFC/ACL: Ո՞ վ կարող է փոխել որ դրոշները (բյուջեներով/շուկաներով)։

Ժամանակի պատուհանները (change windows) և «կրկնակի ապացույց» զգայուն դրոշների համար։

Անփոփոխ աուդիտ 'ով/երբ/որ/ինչու (ticket/incident link)։

Իրավասություններ ՝ դրոշները չպետք է շրջանցեն կարգավորող արգելքները (օրինակ, միացնեն խաղը արգելված երկրում)։

9) Երկար գոյատևող դրոշների կառավարումը

Յուրաքանչյուր դրոշը ունի TTL/մրցույթի ամսաթիվը։

100 տոկոսից հետո, տեղադրեք task-ը կոդի ճյուղերի հեռացման վրա, հակառակ դեպքում կաճի «դրոշը պարտքը»։

Նշեք դրոշները որպես «migration »/« one-time», դրանք առանձնացրեք մշտական «permission/wwww.ru»։

10) API/MSK պայմանագրի օրինակ

Evaluation API (server-side)

http
POST /v1/flags/evaluate
Headers: X-Tenant: brand_eu
Body: { "keys":["catalog. new_ranker","rgs. killswitch"], "context": { "user_id":"u42", "region":"EE" } }
→ 200
{
"catalog. new_ranker": { "on": true, "variant":"v1", "as_of":"2025-10-31T12:10:02Z" },
"rgs. killswitch":  { "on": false, "variant":null, "as_of":"2025-10-31T12:10:02Z" }
}

Client SDK (кэш, fallback)

ts const ff = await sdk. getSnapshot()     // bootstrap const on = ff. isOn("catalog. new_ranker", ctx)
const payload = ff. payload("catalog. new_ranker", "v1")

11) Փոխազդեցությունը այլ կոնտուրների հետ

Rate limits/քվոտաներ. Դրոշները կարող են նվազեցնել RPS/ներառել տրոտլինգը ժամանակի ընթացքում։

Circuit breaker/degradation: kill-switchi անջատում են ծանր ճանապարհները և ներառում են քայքայումը։

Կատալոգ/կերպարացում 'դրոշները փոխում են քաշը/դասակարգման կանոնները (Remote Express-ի միջոցով)։

NoBD: Դրոշները կանոնավոր կերպով թարգմանում են ընթերցումներ/գրառումներ նոր սխեմայի վրա (read-replica no drite-write no write-primary)։

12) Պլեյբուկի (runbooks)

1. Դեպքը 25 տոկոսը ներառելուց հետո

Autokatof-ը աշխատում էր OFF-ի ռուսական դրոշը բոլորի համար/2019, tiket on-call-ում, կարգավիճակների հավաքումը, RCA-ն։

Ժամանակավորապես միացրեք քայքայումը/հին ճյուղը migration-դրոշի միջոցով։

2. P95-ի աճը։

Շեմը 'p95 _ 07> 200' - ավտոկատոֆը; ամրագրել «flag _ key = catalog» -ի կոճակը։ new_ranker`.

Միացրեք ռենգիայի պարզեցված ազդանշանները (payload no)։

3. Իրավասության անհամապատասխանությունը

Permission-ի դրոշը սխալմամբ բացեց խաղը '"NL' - OFF + Opp-փաստով, ավելացնելով" region deny "գուարդ կանոնները։

4. Ցրումը A/B

Կանգնեցնել փորձը, կատարել CUPED/stratified վերլուծություն, վերագտնել նորացված քաշներով։

13) Թեստավորում

Unit: Կանոնների/գերակայությունների դետերմինացված գնահատական։

Disract: Դրոշների սխեման (JSON/YAML), վալիդատորները, CI-ստուգումը մարջիի առջև։

Property-based: «deny> allow», «most specific ents», կայուն bucketing։

Replay 'իրական ենթատեքստերի վերարտադրումը նոր կազմաձևի վրա։

E2E: Կանարական ջութակները (step-up/step-down), ավտոկատոֆի և աուդիտի իրադարձությունների ստուգումը։

Chaos 'սթրիմինգի կոտրվածք, հնացած կեղև, դրոշների զանգվածային նորարարություն։

14) Տիպիկ սխալներ

Հաճախորդների դրոշներում գաղտնի տրամաբանությունը (արտահոսք/փոխարինում)։

TTL-ի բացակայությունը նկարագրում է դրոշների «գերեզմանատուն» կոդում։

«Համընդհանուր» դրոշները առանց պարամետրերի սեգմենտացիայի անհնար է տեղայնացնել խնդիրը։

Չկա guardrails/ավտոկատոֆներ 'ձեռքով։

Անհամատեղելի կախվածություն ռուսական ցիկլայի/ռասինխրոնի միջև։

Դրոշների գնահատումը յուրաքանչյուր պահանջով առանց քեշի բացատրվում է լատենտության աճով։

Փոխարինման/պատուհանի բացակայությունը կոմպլանսի ռիսկերն են։

15) Չեկ թուղթ մինչև վաճառելը

• Դրոշը ստեղծվել է տիպ, owner, նկարագրություն, TTL և հյուսելու պահանջով։
• Targeging կանոնները որոշվում են, «deny» -ը անցանկալի տարածքների/դերի վրա։
• Sticky bucketing դետերմինացված է; ընտրվում է կայուն։
• Preexizits և health դրոշները պատրաստ են. դեֆոլտը անվտանգ է։
• Dashbords և alerts p95/p99, error _ rate, բիզնես guardrails։
• Ավտոկատոֆը տրամադրված է; rollout-ի հոսքը և արձագանքման պայմանները։
• Կանարյան պլան ՝ տոկոսներ/փուլեր/փոփոխությունների պատուհան/պատասխանատու։
• Ջորջը վալիդացվում է CI-ում; կեղևը բաշխվում է կլաստերներով/տարածաշրջաններով։
• Աջակցություն/ապրանք; պլեյբուսները պատրաստված են։
• Կոդի և դրոշի ճյուղերի պլանը 100% -ից հետո։

16) «Միգրացիայի» դրոշի օրինակը (BD/ինդեքս)

yaml flag:
key: "search. use_index_v2"
type: "migration"
description: "Switching reads to index v2"
prerequisites:
- key: "search. index_v2_built"
must_be: "on"
rules:
- when: { tenant_id: ["brand_eu"], user_pct: 5 } then: "on"
- when: { tenant_id: ["brand_eu"], user_pct: 25 } then: "on"
safeguards:
auto_rollback_on:
search_p95_ms: ">180"
error_rate: ">1%"
ttl: "2026-02-01"

Եզրակացություն

Feature Flags-ը ոչ միայն «համեղ/արտանետումն» է, այլ փոփոխության ռիսկերի կառավարման կարգապահությունը։ Դրոշների հստակ տեսակները, դետերմինացված թարթինգը, guardrails, autokatof, աուդիտ և պլանը կանխատեսելի են դարձնում, իսկ միջադեպերը կարճ և վերահսկվող են։ Դրոշները կառուցեք որպես քաղաքացիների առաջին դասարան, և դուք կարող եք ավելի շատ արժեքներ բերել, ավելի ապահով և իմաստալից։