Feature Flags жана Fich чыгаруу
Feature Flag (FF) - кодду чыгарбастан системанын жүрүм-турумун камтыган/өчүрүүчү башкарылуучу шарт. желектер мүмкүнчүлүк берет: коопсуз Ficking, максаттуу колдонуучулар/базарлар/тенанттар топтору, тез эле көйгөйлүү компоненттерин өчүрүү, эксперименттерди жүргүзүү жана рантим параметрлерди конфигурациялоо.
Негизги максаттары:- бошотуу учурунда blast radius азайтуу.
- Бөлүштүрүү жана жандандыруу.
- Аудит, SLO жана бир чыкылдатуу менен өзгөрүүлөрдү ачык-айкын башкарууну берүү.
1) желек түрлөрү жана аларды колдонуу
Release flags - этап-этабы менен (dark → canary → ramp-up → 100%).
Ops/kill-switch - көз карандылыкты дароо өчүрүү (провайдер, подсистема, оор эсептөөлөр).
Experiment (A/B, multi-variant) - трафикти варианттарга бөлүү (weights, sticky bucketing).
Permission/Entitlement - ролдорго/пландарга/юрисдикцияларга жетүү.
Remote Config - туудан/конфигадан жүрүм-турум параметрлери (босого, таймаут, формула).
Migration flags - схемаларды/маалымат жолдорун которуу (жаңы индекске/DD/end-point өтүү).
Анти-үлгү: бир эле желек "баары жөнүндө" - Fichu, Comp-Switch жана параметрлерин бөлүү.
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-эрежелер → allow-эрежелер → дефолт.
Sticky bucketing: эксперименттер үчүн туруктуу идентификаторду хештегиле (мисалы, 'hash (user_id, flag_key)') - колдонуучу дайыма бир вариантты алат.
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 SDK (сунушталат): чындык булактары жана кэш бэкенд; логиканы унификациялоо.
- Edge/CDN evaluation: периметри боюнча тез максаттуу (PII/сыр жок жерде).
- Client-side SDK: UI жекелештирүү керек болгондо, бирок - бир гана минималдуу контекстте жана сезимтал эрежелери жок.
- Config-as-Code: репозиторийде желектерди сактоо, CD аркылуу CI, rollout валидациясы.
- Startup bootstrap + streaming updates (SSE/gRPC) + акыркы snapshot үчүн fallback.
- SLA "freshness" желектери: p95 ≤ 5 б.
5) чыгаруу стратегиялары
5. 1 Dark Launch
Ficha киргизилген, бирок колдонуучуга көрүнбөйт; көрсөткүчтөрдү жана каталарды чогултабыз.
5. 2 Canary
Бир юрисдикция/тенантта 1-5% трафикти кошуу; p95/p99 мониторинг, каталар, конверсия.
Stop conditions - автокатофтун босого триггерлери.
5. 3 Progressive Rollout
10% → 25% → 50% → 100% кол менен/авто текшерүү менен.
5. 4 Shadow / Mirroring
Биз жаңы жолго суроо-талаптарды кайталап (көрүнгөн таасири жок) жана натыйжаларды/жашыруун салыштырып.
5. 5 Blue/Green + FF
Биз эки нускасын жайылтуу; желек трафикти башкарат жана сегменттер боюнча көз карандылыкты өзгөртөт.
6) Көз карандылык жана кросс-сервистик консистенттүүлүк
prerequisites жана "ден соолук желектери" даяр колдонуңуз: индекс курулган, миграция аяктады.
Окуялар аркылуу координациялоо: 'FlagChanged (flag_key, scope, new_state)'.
1. включить read-way → 2) текшерүү метрика → 3) включить write/side-effects.
- Тейлөө келишимдери: дефолт коопсуз болушу керек (fail-safe OFF).
7) Байкоо жана SLO
желек/параметр/сегмент боюнча Metrics:- `flag_eval_p95_ms`, `errors_rate`, `config_freshness_ms`.
- Бизнес-метрика: 'ctr', 'conversion', 'ARPU', 'retention', guardrails (мисалы, RG инциденттери).
- Automatic SLO босоголору autocatophe үчүн.
Логи/трейсинг: 'flag _ key', 'variant', 'decision _ source' (server/edge/client), 'context _ hash'.
Dashbord: босоголору менен "тепкич" rollout, heatmap каталар сегменттеринде.
8) Коопсуздук жана комплаенс
контекстинде PII-минималдаштыруу.
RLS/ACL: ким желектерди өзгөртө алат (домендер/базарлар боюнча).
Өзгөртүү саат терезелери (change windows) жана сезгич желектер үчүн "кош ырастоо".
Өзгөрүлбөгөн аудит: ким/качан/эмне/эмне үчүн (ticket/incident link).
Юрисдикциялар: желектер жөнгө салуучу тыюу салууларды кыйгап өтпөшү керек (мисалы, тыюу салынган өлкөдө оюнду камтыйт).
9) "Узак мөөнөттүү" желектерди башкаруу
Ар бир желек TTL/өчүрүү датасы бар.
100% кошулгандан кийин - код бутактарын алып салуу үчүн task түзүңүз, антпесе "желек-карыз" өсөт.
желектерди 'migration '/' one-time' деп белгилеңиз, аларды туруктуу 'permission/config' дегенден бөлүңүз.
10) Мисалы API/SDK келишим
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/Trottling камтышы мүмкүн.
Circuit breaker/degradation: kill-switchy оор жолдорду өчүрүп, деградацияны камтыйт.
Каталог/жекелештирүү: желектер салмагын/ранжирлөө эрежелерин өзгөртүү (Remote Config аркылуу).
DD миграциялары: желектер этап-этабы менен окууларды/жазууларды жаңы схемага которушат (read-replica → dual-write → write-primary).
12) Playbooks (runbooks)
1. 25% күйгүзүлгөндөн кийин окуя
Autocatophe бардык/сегмент үчүн → OFF желеги, on-call билети, статустарды чогултуу, RCA.
Миграциялык желек аркылуу деградацияны/эски бутакты убактылуу иштетиңиз.
2. Каталогдун өсүшү p95
Порог 'p95 _ ms> 200' - автокатофт; 'flag _ key = catalog. new_ranker`.
Жөнөкөйлөтүлгөн ранжирлөө сигналдарын күйгүзүү (payload config).
3. Юрисдикциянын дал келбегендиги
Permission желеги жаңылыштык "NL" оюнун ачты - OFF + пост-факт аудит, "region deny" guard эрежесин кошуу.
4. A/B дисперсиясы
Экспериментти токтотуу, CUPED/stratified анализин жүргүзүү, жаңыланган таразалар менен кайра иштетүү.
13) сыноо
Unit: эрежелерди/артыкчылыктарды/пререквизиттерди аныктоо.
Contract: желек схемасы (JSON/YAML), валидаторлор, Мердж алдында CI-текшерүү.
Property-based: "deny> allow", "most specific wins", туруктуу bucketing.
Replay: жаңы конфигурацияда реалдуу контексттерди ойнотуу.
E2E: Канар скрипттери (step-up/step-down), autocatophe текшерүү жана аудит-окуялар.
Chaos: стриминг үзүлүшү, эскирген снапшот, желектерди массалык жаңыртуу.
14) типтүү каталар
Кардарлардын желектеринде жашыруун логика (агып чыгуу/алмаштыруу).
Жок TTL → "көрүстөн" желектер коду.
сегменттөө жок "жалпы" желектер → маселени локалдаштыруу мүмкүн эмес.
Эч кандай guardrails/автокатофтор - кол менен болгон окуялар.
Бири-бирине шайкеш келбеген көз карандылыктар → циклдер/рассинхрон.
Ар бир суроо-талапта желектерди кэшсиз баалоо → жашыруун жарылуу.
Аудит/өзгөртүү терезесинин жоктугу комплаенс тобокелдиктери болуп саналат.
15) Азык-түлүктүн алдындагы чек-тизме
- желеги түрү менен түзүлгөн, ички, сүрөттөлүшү, TTL жана текшерүү талабы.
- Максаттуу эрежелери аныкталган; 'deny' боюнча жагымсыз аймактар/ролдор.
- Sticky bucketing аныкталат; ID туруктуу тандалып алынган.
- Prerekwizits жана ден соолук желектери даяр; дефолт коопсуз.
- p95/p99, error_rate, бизнес-guardrails боюнча Dashboard жана Алерт.
- Autocatophe орнотулган; rollout токтоо босогосу жана кайтаруу шарттары.
- Канар планы: пайыздык/этаптары/өзгөртүү терезе/жоопкерчиликтүү.
- Конфиги CI тастыкталган; снапшот кластерлерге/аймактарга бөлүштүрүлгөн.
- колдоо/продукт үчүн документтер; инциденттердин плейбуктары.
- 100% кийин коддун бутактарын жана желектин өзүн алып салуу планы.
16) "Миграциялык" желектин мисалы (БД/индекс)
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 менен прогрессивдүү эсептөөлөр, автокатофтор, аудит жана алып салуу планы релиздерди алдын ала айтууга болот, ал эми окуялар кыска жана көзөмөлгө алынат. Жарандардын биринчи классы катары архитектурага желектерди киргизиңиз - ошондо сиз баалуулукту тез-тез, коопсуз жана маңыздуу жеткире аласыз.