ویژگی پرچم ها و مدیریت انتشار

ویژگی پرچم ها و مدیریت انتشار

1) چرا پرچم ها در صورت انتشار وجود دارد ؟

• سرعت و امنیت انتشار: افزایش های کوچک + بازگشت فوری.
• کنترل شعاع: گسترش پیشرفته، حلقه ها، متوقف کننده های SLO.
• آزمایشات و A/B: پرچم های چند متغیره، آمار اثر.
• سناریوهای عملیاتی: سوئیچ کشتن برای مسیرهای پرداخت/بازی خطرناک.

اصل کلیدی: «کشتی تاریک، فعال روشن» - ارائه در پیش، شامل آگاهانه.

2) انواع پرچم

Boolean: ویژگی های روشن/خاموش، پرچم های توقف اضطراری (kill-switch).
چند متغیره: رفتارها (الگوریتم A/B/C، محدودیت ها، ضرایب).
پیکربندی/پیکربندی از راه دور: پارامترها (مدت زمان، محدودیت شرط بندی، مبلغ پاداش).
مجوز/حق: دسترسی به توابع/محدودیت ها توسط نقش ها/سطوح.
عملیاتی: مسیریابی ترافیک (درخواست سایه، گنجاندن یک سرویس جدید).

3) معماری و جریان داده

کنترل هواپیما: کنسول/پرچم سرور، ذخیره سازی قوانین/بخش، حسابرسی.
Data Plane (SDK/Proxy/Edge): به دست آوردن و ذخیره پرچم ها، ارزیابی قوانین به صورت محلی (حداقل تاخیر)، folback زمانی که در دسترس نیست.

• کشیدن: SDK به صورت دوره ای پیکربندی (ETag/stream) را هماهنگ می کند.
• فشار/جریان: رویدادهای سرور ارسال شده/WebSocket.
• Edge Cache/Proxy: نزدیک به کاربر، p99 را کاهش می دهد.

• ارزیابی محلی قوانین (بدون شبکه هاپ در مسیر داغ).
• زمانبندی و folkbacks (بدون خواندن پرچم «مسدود کردن»).
• امضا/نسخهبندی عکسهای فوری پیکربندی.

4) هدف گذاری و بخش بندی

ویژگی ها: کشور/منطقه، زبان، پلت فرم، سطح KYC، سطح VIP، میزان خطر، سن حساب، روش پرداخت، محدودیت های بازی مسئول.
بخش ها: قوانین ذخیره شده با نسخه ها ؛ «نرم» (بازاریابی) و «سخت» (انطباق).
اولویت ها/درگیری ها: دستورات صریح قانون، «آخرین بازی» بدون آزمون مجاز نیست.
Geo/regulatory: پرچم های دسترسی به محصول توسط صلاحیت ؛ پیش بینی های غیر قابل تغییر (به عنوان مثال، ممنوعیت تخفیف خاص کشور).

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) برنامه ریزی پیشرفته: استراتژی ها

قناری توسط٪: 1٪ → 5٪ → 25٪ → 50٪ → 100٪ با توقف خودکار SLO.
Rings: تیم داخلی → کاربران بتا → یک منطقه → در سطح جهانی.
نمونه برداری توسط دستگاه/مشتری: چسبندگی (شناسه هش) را در نظر بگیرید.
ترافیک سایه: تکرار یک درخواست به یک مسیر جدید بدون تاثیر بر کاربر.
راه اندازی تاریک: فعال، اما قابل مشاهده نیست (جمع آوری معیارها، گرم کردن انبارها).

• خرابی p95 تاخیر API 'withdraw> + 15٪ در عرض 10 دقیقه.
• خطای 5xx> 0 5٪ یا افزایش شکست ارائه دهنده پرداخت> + 0. 3 پی پی
• هشدار تقلب/ریسک بالاتر از آستانه در بخش.

6) کشتن سوئیچ

یک کلاس پرچم جداگانه که توسط SRE/On-Call قابل مشاهده است.
تضمین نمره محلی با کش TTL (میلی ثانیه).
قطع ارتباط غیر قابل استرداد: نیاز به دلیل + بلیط پس از مرگ.
خودکار عمل ادغام: غیرفعال کردن پاداش، انتقال پرداخت به حالت دستی، ممنوعیت سپرده برای ارائه دهنده X.

7) ادغام با CI/CD و GitOps

CI: اعتبار سنجی از طرح های پرچم، قوانین پرز، هدف قرار دادن اجرای خشک در برابر نمونه های ناشناس.
CD: ارتقاء تنظیمات پرچم به عنوان مصنوعات (semver)، «دروازه های تایید» برای پرچم های حساس (پرداخت/انطباق).
GitOps: پرچم ها در یک مخزن پیکربندی جداگانه، درخواست ادغام = تغییر رویداد، ممیزی از جعبه.

8) ایمنی و انطباق

RBAC/ABAC: چه کسی می تواند ایجاد/شامل/افزایش علاقه ؛ تفکیک وظایف (توسعه دهنده ≠ تولید کننده ≠ صاحب محصول)

حسابرسی: چه کسی/چه زمانی/چه چیزی/چرا ؛ توجیه (بلیط/JIRA)، مقایسه با حوادث.
به حداقل رساندن PII: ویژگی های برای هدف قرار دادن عبور از طریق ناشناس/هش.
بررسی یکپارچگی امضا Snapshot در SDK/پروکسی.
SLA برای تحویل پیکربندی: تنزل به «پیش فرض امن».

9) قابلیت مشاهده و معیارها

• زمان انتشار پرچم (p50/p95), نرخ ضربه از حافظه پنهان محلی, فرکانس به روز رسانی.
• تعداد پرچم های فعال/منسوخ/حلق آویز (توسط تاریخ حذف نشده است).
• نگهبانان SLO: تاخیر، خطا، تبدیل، ثبات ارائه دهنده.

• DORA: میزان تخلیه، زمان روشن شدن، میزان شکست پس از روشن شدن، MTTR.
• A/B شاخص: CR، ARPPU، سیگنال LTV، تاثیر بر نمره تقلب.

10) چرخه عمر پرچم

1. طراحی: هدف/متریک/مالک/تاریخ انقضا ('expires' At ')، سناریوهای بازپرداخت.
2. پیاده سازی: تماس SDK، folbacks، تله متری «قرار گرفتن در معرض «/» تصمیم «.
3. Rollout: سرویس پیشرفته + دروازه SLO.
4. تثبیت: اثر را ثابت کنید، مستندات/ریشه را به روز کنید.
5. پاکسازی: شاخه های کد را حذف کنید، پرچم را ببندید، «باقی مانده ها» را بررسی کنید.

11) نمونه های پیاده سازی

11. 1 وب/گره. جی اس

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 کاتلین/جی وی ام

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٪ اتحادیه اروپا → 100٪ به جز DE (تنظیم کننده).
محدود کننده ها: حداکثر 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) کنترل دسترسی و مصوبات

انواع تغییر: استاندارد (امن) در مقابل حساس (پرداخت/پرداخت/محدودیت).
مصوبات: صاحب محصول + فناوری. شخص مسئول + انطباق (برای حوزه های قضایی).
پنجره زمان (یخ): ممنوعیت گنجاندن/پسوند در دوره های پر خطر (زمان نخست، مسابقات بزرگ).

14) آزمایش و آمار

رویدادهای قرار گرفتن در معرض: تصمیم گیری پرچم را با ویژگی ها وارد کنید.
تجزیه و تحلیل: ارزش برنامه ریزی فعلی، بخش ها، تاثیر بر تبدیل/خطاها.
بررسی های آماری: تقسیم صحیح، کنترل کوواریته ها (دستگاه ها/جغرافیایی).
اخلاق و مقررات: اجتناب از تقسیم بندی محدود شده توسط قانون محلی.

15) ضد الگوهای

پرچمهای با عمر طولانی بدون 'expires' At ',' branch graveyard 'در کد.
مسدود کردن تماس شبکه SDK در مسیر داغ.
هدف قرار دادن بیش از حد توسط PII، عدم شناسایی ویژگی ها.
فعال کردن بدون محافظ SLO/توقف خودکار.
بدون سوئیچ کشتن برای جریان های با خطر بالا (سپرده/برداشت/پاداش).
«مخفی» ویرایش پرچم دستی بدون حسابرسی و توجیه.

16) چک لیست پیاده سازی (0-60-90)

0-30 روز

یک پلت فرم پرچم را انتخاب کنید/یک میزبان خود را آماده کنید (SDK، پروکسی، کش).
طرحواره («پرچم»، «مالک»، «هدف»، «انقضا»، «سطح _ ریسک») را وارد کنید.
معیارهای SLO را به پلت فرم وصل کنید (خطاهای تاخیر/کلید API).

31-60 روز

اضافه کردن مصوبات توسط پرچم های حساس، نگهبانان OPA.
پیکربندی استراتژی های مترقی (درصد/حلقه)، کشتن سوئیچ پانل.
قراردادن طرح پرچم در CI ؛ شروع به لخت کردن اولین «حلق آویز».

61-90 روز

ادغام کامل با GitOps (ویرایش پرچم MR، حسابرسی).
داشبورد بصری: SDK پوشش، زمان توزیع،٪ از بازدید کش.
«روز بدهی پرچم»: حذف کد و بستن پرچم ها.

17) معیارهای بلوغ

تکنیک: پذیرش پیکربندی p95 <5 ثانیه ؛ حافظه نهان نرخ ضربه SDK> 95%;% پرچم با 'expiresAt'> 90%.
فرآیندها: پرچم های حساس 100٪ با مصوبات ؛ متوسط «زمان بازگشت» <3 دقیقه.
بهداشت کد: نسبت پرچم بسته در 30 روز از ورود جهانی> 80٪.
اثر کسب و کار: بهبود DORA (فرکانس انتشار ↑، MTTR ↓)، کاهش حوادث در طول انتشار.

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) نتیجه گیری

پرچم ویژگی «دکمه حجم» برای تغییرات است. ترکیب اجزاء مترقی، نگهبانان SLO، حسابرسی سخت و مرتب کردن منظم، و پرچم ها را به CI/CD و GitOps متصل کنید. در نتیجه، انتشار مکرر، قابل کنترل و امن خواهد بود و خطر حوادث قابل پیش بینی و کنترل می شود.