روند تصویب انتشار

1) هدف و حوزه مسئولیت

فرآیند تأیید انتشار، تغییرات پلت فرم قابل پیش بینی و ایمن را بدون نقض SLO، درآمد و انطباق تضمین می کند. این تمام مسیر را پوشش می دهد: از درخواست کشیدن به ارتقاء کامل به تولید و پس از نظارت.

2) اصول

1. SLO-first: انتشار فقط با SLI سبز/بدون میزان سوختگی مجاز است.
2. تعداد زیادی کوچک و برگشت پذیری: تحویل قناری/مترقی، بازگشت سریع.
3. Policy-as-Code: گیت ها، SoD، پنجره های یخ زده و کلاس های ریسک به طور خودکار تأیید می شوند.
4. یک منبع واحد از حقیقت: artifacts/configs/flags - در Git، محیط زیست توسط GitOps-reconciler داده شده است.
5. حسابرسی و قابلیت اثبات: گزارش های WORM، دنباله تصمیم، صاحبان روشن است.
6. امنیت به طور پیش فرض: اسرار به طور جداگانه، حداقل امتیازات، geo-gates.
7. ارتباطات بدون شگفتی: قالب های آماده برای به روز رسانی داخلی/خارجی.

3) نقش ها و RACI

مدیر انتشار (RM) - صاحب خط لوله، تقویم، دروازه. A/R

صاحب سرویس (SO) - صاحب دامنه، ریسک را می پذیرد، مصنوعات را آماده می کند. A/R

SRE/Platform - دروازه های SLO، رول ها، رول های خودکار. تحقیق و توسعه

QA سرب - استراتژی بازرسی، نتایج آزمون. تحقیق و توسعه

امنیت/انطباق - اسکن، SoD، نظارتی. C/A

CAB (Change Advisory Board) - راه حل کلاس عادی. یک نفر

در تماس با IC/CL - آمادگی برای حادثه و ارتباطات. تحقیق و توسعه

ذینفعان (Biz/Support/Partners) - اطلاع رسانی. من و تو

4) تغییر کلاس ها و مسیرهای تصویب

کلاس ها	نمونه ها	مسیر تایید	شرایط استفاده
استاندارد ها	امن، قالب (اسکله، پیکربندی غیر تهاجمی)	دروازه های خودکار + پس از اطلاع رسانی	ساعت ها
عادی است	ویژگی های جدید، نمودار پایگاه داده با مهاجرت، تغییرات مسیریابی PSP	گیتس + CAB + تحویل پیشرفته	1-3 روز
اضطراری	رفع P1 داغ، ویژگی خطرناک/PII صادرات خاموش	تصمیم IC/RM + CAB پس از واقعیت	دقیقه ساعت

ارتقا - هنگام عبور از مرزهای خطر (پرداخت، RG، PII، محدودیت).

5) خط لوله و دروازه های آزاد (جریان پایان به پایان)

مرحله 0 برنامه ریزی و تقویم

فریز ویندوز (تعطیلات/مسابقات), اسلات بر روی تماس و CL, آمادگی قالب وضعیت.

مرحله 1 روابط عمومی → ساخت

خطوط/مجوز، SBOM، آزمایش واحد/قرارداد، اسکن مخفی.

مرحله 2 ادغام/امنیت

E2E (ارائه دهندگان PSP/KYC مجازی)، SAST/DAST، بررسی وابستگی.

مرحله 3 مرحله بندی/تمرین

برابری با فروش، مهاجرت با برگشت پذیری، فیشلگ های 5-25٪، چک لیست «تمرین انتشار».

دروازه A - کیفیت و ایمنی (مورد نیاز)

+ تمام تست ها/اسکن های سبز

+ طرح ها/پیکربندی ها معتبر هستند، بدون مرحله بندی SLI «قرمز»

+ SoD/4-eyes برای تغییرات پرخطر

مرحله 4 پیش تولید (تحویل قناری)

1-5٪ ترافیک توسط بخش (مستاجر/جغرافیایی/بانک)، اعتبار سنج زمان اجرا، guardrails.

دروازه B - SLO/دروازه کسب و کار

+ بدون تخریب SLO/KRI (تاخیر/خطا/پرداخت)

+ بدون SRM/ناهنجاری در معیارهای آزمایش

+ Comms آماده: وضعیت پیش نویس/همکاران

مرحله 5. سطح شیب دار → 25٪ → 100٪ (منطقه/مستاجر)

ارتقاء مبتنی بر نوبت با تایمر پس از نظارت.

مرحله 6. پس از نظارت (30-60 دقیقه)

داشبورد انتشار، نرخ سوختگی، شکایات/بلیط، خودکار بستن/لغو در صورت نقض.

6) راه حل های خودکار (سیاست موتور)

شبه قوانین:

SLO- : "انکار ترویج اگر در { ,
PII-صادرات: 'نیاز به dual_control در صورت پیکربندی. تاثیر می گذارد = "PII_EXPORT"'
توقف: 'انکار استقرار اگر تقویم. یخ زدن و اضطراری نیست
بازگشت به عقب: «خودکار اگر auth_success_drop> 10٪ برای 10 متر در جغرافیایی = TRS»

7) مصنوعات را آزاد کنید

مانیفست انتشار (مورد نیاز): هدف، کلاس خطر، مناطق (مستاجر/منطقه)، پرچم ها، مهاجرت ها، برنامه نورد، برنامه برگشت، مالک، مخاطبین در تماس.
Evidence Pack: نتایج آزمایش/اسکن، تصاویری از داشبورد های مرحله بندی، مهاجرت های خشک.
کیت Comms: قالب وضعیت (داخلی/خارجی/شرکا)، ETA/ETR.
Backout Plan - مراحل دقیق برگشت و معیارهایی که تحت آن باعث شده است.

مثال (فشار YAML):

yaml release:
id: "2025. 11. 01-payments-v42"
owner: "Payments SO"
risk_class: "normal"
scope: { tenants: ["brandA","brandB"], regions: ["EU"] }
rollout:
steps:
- { coverage: "5%", duration: "20m" }
- { coverage: "25%", duration: "40m" }
- { coverage: "100%" }
migrations:
- id: "ledger_ddl_0042"
reversible: true flags:
- id: "deposit. flow. v3"
guardrails: ["api_error_rate<1. 5%","latency_p99<2s"]
rollback:
autoIf:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"

8) قناری/آبی سبز/ویژگی پرچم نورد

Canary - پیش فرض امن: پوشش کوچک، تقسیم بندی توسط GEO/مستاجر/BIN.
آبی سبز - برای تغییرات سنگین: تغییر مسیر، بازگشت سریع.
پرچم ها - برای ویژگی های رفتاری: TTL، kill-switch، guardrails، SoD.

9) مدیریت پیکربندی و اسرار

پیکربندی به عنوان داده ها، مدارها و اعتبار سنج ها ؛ ارتقاء GitOps با آشکارساز رانش.
اسرار - در KMS/مدیر مخفی، دسترسی JIT، حسابرسی و پوشش.

10) ارتباطات و صفحات وضعیت

داخلی: var-room/chat، اطلاع رسانی در تماس، قالب های به روز رسانی.
خارجی: نشریات تنها از طریق CL، پیش نویس از پیش آماده شده است.
Partners (PSP/KYC/studios): اطلاعیه های هدفمند زمانی که یکپارچگی تحت تاثیر قرار می گیرد.
وضعیت: انتشار یک حادثه نیست، اما دارای یک پنجره نظارت با معیارها است.

11) انتشار اضطراری (اضطراری)

محرک ها: تخریب P1، آسیب پذیری، خطرات PII/RG.
مسیر: راه حل IC + RM → حداقل مجموعه ای از دروازه (linter/assembly) → canary 1-2٪ → نظارت → ارتقاء.
اجباری: CAB پس از حادثه، ≤ D + 5 پس از مرگ، مستندات سازش.

12) حسابرسی، SoD و انطباق

SoD/4-eyes: تغییرات در مسیریابی PSP، محدودیت پاداش، صادرات داده ها.
WORM-journal: چه کسی/چه چیزی/چه زمانی/چرا ؛ نسخه های سیاست ؛ diff release/flags/configs را انتخاب کنید.
Geo/Privacy: داده ها و سیاهههای مربوط در حوزه قضایی مورد نظر ؛ عدم وجود PII در مصنوعات.

13) قابلیت مشاهده و پس از کنترل

داشبورد انتشار: SLI (auth-success, bet → settle p99)، نرخ خطا، شکایات، تبدیل، تأخیر صف.
هشدارها: نرخ سوختن، SRM، رشد 5xx، تخریب PSP توسط بانک ها/GEO.
گزارش ها: CFR، حوادث انتشار MTTR، میانگین زمان پس از نظارت، نرخ بازگشت خودکار.

14) KPI فرآیند/KRI

زمان سرب برای تغییر (PR → prod)، تغییر نرخ شکست، حوادث انتشار MTTR.
SLO دروازه نرخ عبور، نرخ بازگشت خودکار، انطباق یخ.
پوشش تمرین انتشار (تمرینات مرحله بندی)، نقض SoD (هدف - 0).
Comms SLA (در دسترس بودن پیش نویس ها، پیروی از زمان بندی).

15) نقشه راه پیاده سازی (6-10 هفته)

«ند». ۱-۲: تعریف کلاس های تغییر، دروازه ها و مصنوعات ؛ فعال کردن linters، SBOM، اسکن مخفی ؛ تقویم را آزاد کنید و یخ بزنید.
«ند». 3-4: GitOps برای تنظیمات، canary/blue-green، دروازه های SLO، قالب های Comms و اتاق var.
«ند». 5-6: policy-engine (SoD/4-eyes, risk-rules), auto-rollback by metrics; انتشار داشبورد.
«ند». 7-8: تمرین (تمرین صحنه)، ادغام با phicheflags/incident-bot، گزارش KPI/KRI.
«ند». 9-10: ممیزی WORM، انتشار دریل DR، بهینه سازی CFR، آموزش نقش (RM/SO/CL/IC).

16) ضد گلوله

انتشار بدون برگشت پذیری و حوادث قناری → توده.
نادیده گرفتن دروازه های SLO «به خاطر مهلت».

Configs/flags without circuits و TTL حالتهای «یخزده»

کلیک های دستی در فروش بدون Git/Audit.
به روز رسانی عمومی بدون نقش CL و قالب.
اسرار موجود در مخزن ؛ دسترسی بدون JIT و ورود به سیستم.
CAB به عنوان یک ترمز بدون داده: تصمیمات باید توسط معیارهای انتشار پشتیبانی شوند.

مجموع

فرایند تصویب انتشار یک چارچوب مهندسی و مدیریتی است که کیفیت، ایمنی و سرعت را به هم متصل می کند: سیاست هایی مانند کد، دروازه های SLO، تحویل مترقی، ارتباطات شفاف و حسابرسی قابل اثبات. این رویکرد CFR و MTTR را کاهش می دهد، از درآمد و انطباق محافظت می کند و به تیم ها اجازه می دهد تا ارزش را اغلب و با خیال راحت آزاد کنند.