Feature Flags და fick- ის გამოშვება

Feature Flag (FF) არის კონტროლირებადი პირობა, რომელიც მოიცავს/გამორთავს სისტემის ქცევას კოდის გამოშვების გარეშე. დროშები საშუალებას გაძლევთ: უსაფრთხოდ გადაიტანოთ ფიჩები, მოაწყოთ მომხმარებელთა/ბაზრების/ტენანტების ჯგუფები, სწრაფად გამორთოთ პრობლემური კომპონენტები, ჩაატაროთ ექსპერიმენტები და კონფიგურაცია პარამეტრების ranthim- ში.

• blast radius- ის შემცირება გამოშვებების დროს.
• განლაგებისა და გააქტიურების გაყოფა.
• მიეცით გამჭვირვალე აუდიტის კონტროლი, SLO და ერთი დაწკაპუნებით დაბრუნება.

1) დროშების ტიპები და როდის გამოიყენება ისინი

Release flags არის ახალი ფიშის ეტაპობრივი ჩართვა (dark-canary ramp-up - 100%).
Ops/kill-switch - დამოკიდებულების მყისიერი გათიშვა (პროვაიდერი, ქვესისტემა, მძიმე გამოთვლები).
Experiment (A/B, multi-variant) - ტრაფიკის დაყოფა ვარიანტებად (weights, sticky bucketing).
Permission/Entitlement - fiches წვდომა როლების/გეგმების/იურისდიქციების მიხედვით.
Remote Config - ქცევის პარამეტრები (ბარიერი, ტაიმუთი, ფორმულა) დროშა/კონფისკაციიდან.
Migration flags - მონაცემთა სქემების/გზების შეცვლა (გადასვლა ახალ ინდექსზე/BD/endpoint).

ანტი-პატრონი: ერთი და იგივე დროშა „ყველაფრის შესახებ“ - ფრაგმენტი ფიჩზე, კომპლექსის სვიტჩზე და პარამეტრებზე.

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) შეფასება და მიზნები

Ключи таргетинга: `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: დროშის შენახვა საცავში, CI შესაბამისობა, rollout CD- ით.

• Startup bootstrap + streaming განახლებები (SSE/gRPC) + ბოლო Snapshot fallback.
• SLA „freshness“ დროშები: p95-5.

5) გამოშვების სტრატეგიები

5. 1 Dark Launch

Fich შედის, მაგრამ მომხმარებლისთვის უხილავია; აგროვებს მეტრიკებს და შეცდომებს.

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 და მზადყოფნის „ჯანმრთელობის დროშები“: ინდექსი აშენდა, მიგრაცია დასრულებულია.
კოორდინაცია მოვლენების საშუალებით: 'flag _ key, scope, new _ state) ".

1. ჩართეთ read ბილიკი (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 ბარიერები ავტოკატოფისთვის.

Logs/tracing: დაამატეთ 'flag _ key', 'variant', 'decision _ source' (სერვერი/edge/client), 'context _ hash'.

Dashboards: rollout- ის „კიბე“ ბარიერებით, heatmap შეცდომები სეგმენტებში.

8) უსაფრთხოება და შესაბამისობა

PII მინიმალიზაცია კონტექსტში.
RLS/ACL: ვის შეუძლია შეცვალოს რომელი დროშები (დომენების/ბაზრების მიხედვით).
შეცვლის 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-switchi გამორთულია მძიმე გზები და მოიცავს დეგრადაციას.
კატალოგი/პერსონალიზაცია: დროშები ცვლის წონას/რანგის წესებს (Remote Config- ის საშუალებით).
DD მიგრაცია: დროშები ეტაპობრივად თარგმნიან კითხვას/ჩანაწერებს ახალ სქემაში (read-replica - ორმაგი-write - write-primary).

12) Playbooks (runbooks)

1. ინციდენტი 25% ჩართვის შემდეგ

ავტოკატოფი მუშაობდა OFF დროშაზე ყველა/სეგმენტისთვის, პიკეტი on-call- ში, სტატუსების შეგროვება, RCA.
დროებით ჩართეთ დეგრადაცია/ძველი ფილიალი ციფრული დროშის საშუალებით.

2. ზრდა p95 კატალოგის მიხედვით

ბარიერი 'p95 _ ms> 200' - ავტოკატოფი; დაფიქსირდეს ლოგოების ჭურვი s 'flag _ key = catalog. new_ranker`.
ჩართეთ გამარტივებული რანგის სიგნალები.

3. იურისდიქციის შეუსაბამობა

Permission- ის დროშამ შეცდომით გახსნა თამაში 'NL' - OFF + აუდიტის პოსტ-ფაქტი, დამატებული guard წესები „region deny“.

4. დისპერსია A/B

შეაჩერეთ ექსპერიმენტი, შეასრულეთ CUPED/stratified ანალიზი, გადააკეთეთ განახლებული წონა.

13) ტესტირება

Unit: დეტერმინისტული შეფასების წესები/პრიორიტეტები/prereccvisites.
Contract: დროშის სქემა (JSON/YAML), მიმღები, CI ტესტირება მერჯამდე.
Property-based: „deny> allow“, „most specific wins“, სტაბილური bucketing.
Replay: რეალური კონტექსტების რეპროდუქცია ახალ კონფიგურაციაზე.
E2E: კანარის სკრიპტები (step-up/step-down), ავტოკატოფის შემოწმება და აუდიტის მოვლენები.
ქაოსი: ნაკადის დაშლა, მოძველებული სნაიპშოტი, დროშების მასიური განახლება.

14) ტიპიური შეცდომები

საიდუმლო ლოგიკა კლიენტის დროშებში (გაჟონვა/ჩანაცვლება).
TTL- ის არარსებობა არის დროშების „სასაფლაო“ კოდით.
უნივერსალური დროშები სეგმენტის გარეშე შეუძლებელია პრობლემის ლოკალიზაცია.
არ არსებობს guardrails/ავტოკატოფონები - სახელმძღვანელო ინციდენტები.
დროშებს შორის შეუთავსებელი დამოკიდებულებაა ციკლები/რასინქრონი.
დროშების შეფასება თითოეულ თხოვნაში ქეშის გარეშე არის ლატენტობის ვარდნა.
აუდიტის/ცვლილების ფანჯრის არარსებობა შესაბამისობის რისკია.

15) ჩეკის სია გაყიდვამდე

• დროშა შეიქმნა ტიპით, owner, აღწერით, TTL და თიკეტის მოთხოვნით.
• მიზნობრივი წესები განისაზღვრება; „დენი“ არასასურველი რეგიონებისთვის/როლებისთვის.
• Sticky bucketing დეტერმინირებულია; იდენტიფიკატორი შეირჩა სტაბილურად.
• Prerecvisites და Health დროშები მზად არიან; ნაგულისხმევი უსაფრთხოა.
• დაშბორდები და ალერტები p95/p99, error _ rate, ბიზნეს guardrails.
• ავტოკატოფი მორგებულია; გაჩერდა rollout- ის ბარიერი და უკან დახევის პირობები.
• კანარის გეგმა: პროცენტი/ეტაპები/ცვლილებების ფანჯარა/პასუხისმგებელი.
• ჩამორთმევა ხდება CI- ში; Snapshot ნაწილდება მტევნების/რეგიონების მიხედვით.
• დოკუმენტაცია მხარდაჭერის/პროდუქტის შესახებ; ინციდენტების ფლეიბუკები.
• კოდის ფილიალებისა და დროშის მოხსნის გეგმა 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- ით, ავტოკატოფებით, აუდიტით და მოცილების გეგმით, განთავისუფლებულია პროგნოზირებადი, ხოლო ინციდენტები მოკლე და კონტროლდება. დროშები შეიტანეთ არქიტექტურაში, როგორც მოქალაქეების პირველი კლასი - და შეგიძლიათ უფრო ხშირად, უფრო უსაფრთხო და უფრო მნიშვნელოვანი.