מאפיין דגלים ושחרור תכונהName

Feature Flag (בראשי תיבות: FF) הוא מצב מנוהל המאפשר/מבטל את התנהגות המערכת ללא שחרור קוד. דגלים מאפשרים לכם: לגלגל תכונות בצורה בטוחה, קבוצות מטרה של משתמשים/שווקים/דיירים, לנטרל במהירות רכיבים בעייתיים, לערוך ניסויים ולהגדיר פרמטרים בזמן ריצה.

• להפחית את רדיוס הפיצוץ עבור שחרור.
• פריסה והפעלה נפרדת.
• אפשר ניהול שינויים שקוף עם ביקורת, SLO וגלגול של קליק אחד.

1) סוגי דגלים ומתי להחיל אותם

שחרר דגלים - הכללה שלבית של תכונה חדשה (dark # canary ach ramp-up = 100%).
Ops/kill-switch - ניתוק מיידי של תלויות (ספק, תת-מערכת, חישובים כבדים).
ניסוי (A/B, multi-variant) - חלוקת התנועה לגוונים (משקולות, דביקות).
הרשאה/זכאות - גישה לתכונות לפי תפקיד/תוכנית/תחום שיפוט.
הגדרות מרוחקות - פרמטרים של התנהגות (סף, פסק זמן, נוסחה) מהדגל/הגדרה.
דגלי נדידה - החלפת תרשימים/נתיבי נתונים (מעבר לאינדקס/DB/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) הערכה ומיקוד

Catalid: 'דייר _ id, אזור/רישיון, מטבע, ערוץ, מקום, תפקיד, תכנית, מכשיר, user_id, קוהורטה, kyc_tier, experiment_bucket'.
פקודת הערכה: תנאים מוקדמים * מכחישים כללים * לאפשר חוקים * ברירת מחדל.
דביק דביק: לניסויים, חשיש מזהה יציב (לדוגמה, 'חשיש (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 וארכיטקטורה

• SDK (מומלץ): מקורות של אמת ומטמון בגב; איחוד ההיגיון.
• הערכה של Edge/CDN: מיקוד מהיר על המתחם (שבו אין סודות PII/PII).
• בצד הלקוח SDK: כאשר אתה צריך התאמה אישית של UI, אבל רק עם הקשר מינימלי וללא כללים רגישים.
• הגדרות כקוד: אחסון דגלים במאגר, אימות CI, rollout באמצעות תקליטור.

• עדכוני הזרמה (SSE/gRPC) + נופלים לתמונה האחרונה.
• דגלי ”רעננות”: p95 5.

5) אסטרטגיות שחרור

5. שיגור כהה 1

התכונה מופעלת אך בלתי נראית למשתמש; לאסוף מדדים וטעויות.

5. 2 קנרית

אנחנו כוללים 1-5% מהתנועה בתחום שיפוט/דייר אחד; צג p95/p99, שגיאות, המרה.
תנאי עצירה - סף אוטומטיות מפעיל על ידי מדדים.

5. 3 Rollout מתקדם

10% -25% -50% -100% מתוכננים עם אימות ידני/אוטומטי.

5. 4 צל/שיקוף

אנו לשכפל בקשות למסלול החדש (ללא השפעה נראית לעין) ולהשוות את התוצאות/latency.

5. 5 כחול/ירוק + FF

אנו לפרוס שתי גרסאות; הדגל מנווט תנועה ומתחלף תלות בחלק.

6) תלות ועקביות השירות הצולב

השתמש בתנאים מוקדמים ו ”דגלי בריאות” של מוכנות: האינדקס נבנה, הנדידה הושלמה.
תיאום באמצעות אירועים: ”FlagChange (flag_key, היקף, new_state)”.

1. אפשר cread-path _ 2) בדיקת מדדים * 3) מאפשרת כתיבה/תופעות לוואי.

• חוזי שירות: ברירת המחדל חייבת להיות אל-כשל.

7) יכולת תצפית ו ־ SLO

• 'flag _ eval _ p95 _ ms',' שגיאות _ rate ',' config _ treeness _ ms'.
• מדדים עסקיים: ctr, 'המרה', 'ARPU', 'שימור', מעקות בטיחות (למשל. תקריות ר "ג).
• סף SLO אוטומטי לאוטוקטופה.

לוגים/איתור: הוספת "flag _ key", "variant'," decision _ source "(שרת/אדג '/לקוח)," context _ hash ".

לוחות מחוונים: לגלגל ”סולם” עם מפתן, שגיאות מפת חום על ידי מקטעים.

8) בטיחות וציות

PII-מזעור בהקשר.
RLS/ACL: מי יכול לשנות את הדגלים (לפי תחום/שוק).
חלונות שעה של שינויים (שינוי חלונות) ו ”אישור כפול” לדגלים רגישים.
ביקורת אינסופית: מי/מתי/מה/למה (כרטיס/קישור תקרית).
תחום השיפוט: אסור לדגלים לעקוף את האיסורים הרגולטוריים (למשל, לשחק במדינה אסורה).

9) ניהול דגלים ”ארוכי ימים”

לכל דגל יש תאריך TTL/מחיקה.
לאחר הכללה של 100% - ליצור משימה למחיקת סניפי קוד, אחרת ”חובות הדגל” יגדלו.
סמן את הדגלים כ ”הגירה ”/” חד פעמית”, הפרד אותם מהקבוע ”אישור/הגדרה”.

10) חוזה מדגם API/SDK

API הערכה (צד שרת)

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" }
}

לקוח SDK (cultule, 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) אינטראקציה עם מעגלים אחרים

מגבלות קצב/מכסות: דגלים יכולים להוריד RPS/לאפשר חפירה למשך האירוע.
מפסק מעגל/הידרדרות: להרוג-החלפה לנטרל שבילים כבדים ולאפשר הידרדרות.
Directory/Personalization: דגלים משנים משקולות/כללי דירוג (באמצעות תצורה מרוחקת).
נדידת מסד נתונים: דגלים מתרגמים בהדרגה קריאה/כתיבה לסכימה חדשה (read-replica # double-write # write-primary).

12) ספרי משחק (ספרי הפעלה)

1. תקרית לאחר הכללה של 25%

Autocatoff מופעל = Off Flag עבור כל/פלח, כרטיס לכוננות, אוסף סטטיסטיקות, RCA.
אפשר באופן זמני הידרדרות/ענף ישן דרך דגל הנדידה.

2. צמיחה בקטלוג p95

סף 'p95 _ ms> 200' - אוטוקטופ; לתקן תצלום של יומנים עם 'flag _ key = קטלוג. new_ranker'.
אפשר הגדרת מטען.

3. חוסר סמכות שיפוטית

דגל ההרשאה פתח בטעות את המשחק בביקורת ”NL-OFF + פוסט-עובדה”, והוסיף את כלל השמירה ”אזור מכחיש”.

4. שונות ב A/B

לעצור את הניסוי, לבצע ניתוח CUPED/stratied, לגלגל מחדש עם מאזניים מעודכנים.

13) בדיקה

יחידה: הערכה דטרמיניסטית של כללים/סדרי עדיפויות/תנאים מוקדמים.
חוזה: סכימת דגל (JSON/YAML), אימות, בדיקת CI לפני המיזוג.
מבוסס רכוש: ”למנוע> לאפשר”, ”הניצחונות הספציפיים ביותר”, דלי יציב.
משחק חוזר-מנגן אמיתי על התצורה החדשה.
E2E: תסריטים קנריים (שלב למעלה/שלב למטה), בדיקה אוטומטית ואירועי ביקורת.
זרימת צוק, צילום מורשת, עדכון דגל מסיבי.

14) שגיאות אופייניות

היגיון סודי בדגלי הלקוח (הדלפות/זיוף).
העדר TTL = ”בית הקברות” של דגלים בקוד.
דגלים ”אוניברסליים” ללא מקטע של מספר לא יכול לאתר את הבעיה.
אין מעקות בטיחות/אוטוקטופונים - תקריות ידניות.
תלות בלתי תואמת בין דגלים * לולאות/מתוך סינכרון.
הערכה של דגלים בכל בקשה ללא מטמון = latency spikes.
אין ביקורת/שינוי חלון - סיכוני ציות.

15) רשימת בדיקות לפני המכירה

[ דגל ] נוצר עם סוג, בעלים, תיאור, TTL ודרישות כרטיס.

[ ] כללי מיקוד מוגדרים; Deny 'על אזורים/תפקידים לא רצויים.

[ ] דביקות דטרמיניסטיות; תעודת הזהות יציבה.

[ ] דרישות מראש ודגלי בריאות מוכנים; ברירת מחדל.

[ ] לוחות מחוונים והתראות על p95/p99, error_rate, מעקות בטיחות עסקיים.

[ ] Autocatoff מוגדר; תעצור את סף העצירה ותנאי הריצה.

[ ] הקנרית - אחוזי אבני דרך/החלונות/בעלים

[ ] קונפיג 'ים מותאמים ב-CI; תצלום שמופץ על פני אשכולות/אזורים.

[ ] תמיכה/תיעוד מוצר; חוברות משחקים תקריות.

[ ] מתכנן להסיר ענפי קוד והדגל עצמו לאחר 100%.

16) דוגמה לדגל ”הגירה” (DB/Index)

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 הוא לא רק ”on/off”, אלא גם המשמעת של שינוי ניהול סיכונים. סוגי דגל ברורים, מטרות דטרמיניסטיות, תצוגות מתקדמות עם מעקות בטיחות, אוטוקאטה, ביקורת חשבונות ותוכנית מחיקה לבנות דגלים לארכיטקטורה כמחלקה ראשונה של אזרחים - ואתה יכול לספק ערך לעתים קרובות יותר, בטוח יותר ומשמעותי יותר.