پیکربندی کنترل نسخه

1) چرا تنظیمات نسخه

پیکربندی یک سیاست اجرایی است: مسیریابی، محدودیت ها، پرچم های ویژگی، دسترسی ها، طرح های داده را تعریف می کند. کنترل نسخه باعث تغییرات قابل تکرار، قابل مشاهده و برگشت پذیر می شود: MTTR و میزان تغییر شکست را کاهش می دهد، «سحر و جادو در فروش» را از بین می برد، ممیزی هایی را برای امنیت و انطباق می دهد.

2) طبقه بندی پیکربندی

زیرساخت (IaC): خوشه ها، شبکه ها، LB، DB، صف ها.
سرویس: پارامترهای برنامه، منابع، محدودیت ها، زمان بندی ها، بازپرداخت ها.
منطق محصول/کسب و کار: تعرفه ها، آزمایش های AB، قوانین محتوا.
Data/DataOps: طرح های قرارداد، طراوت SLA، تحول.
امنیت: دسترسی به سیاست ها، نقش ها، کلید ها/گواهی ها (اسرار خود را در خارج از مخزن).
قابلیت مشاهده: SLI/SLO، هشدارها، داشبورد.

قانون: هر چیزی که بر رفتار سیستم تأثیر میگذارد پیکربندی است و باید تحت نسخهبندی زندگی کند.

3) اصول نسخه

1. GitOps: تنها منبع حقیقت مخزن است ؛ تغییرات از طریق روابط عمومی و خطوط لوله اتوماتیک.
2. Declarative: توصیف وضعیت هدف، نه اسکریپت های مرحله.
3. تغییرناپذیری مصنوعات: پیکربندی → بدون ابهام تصویر لحظهای تحقق یافته.
4. طرحواره ها و اعتبارسنجی: JSON/YAML-schema، نوع ریخته گری سخت، فیلدهای مورد نیاز.
5. محیط هایی مانند کد: 'env' - پوشه ها/پوشش ها (dev/stage/prod)، تفاوت ها حداقل و واضح هستند.
6. Idempotence و rollbacks: بازگشت/بازگرداندن هر نسخه پیکربندی.
7. ممیزی و ردیابی: نویسنده، دلیل، بلیط/RFC، امضای تغییر.

4) استراتژی های نسخه

• MAJOR - تغییرات طرح/سیاست ناسازگار.
• MINOR - زمینه های جدید/قوانین، سازگاری عقب مانده.
• PATCH - مقادیر را بدون تغییر طرح ها اصلاح می کند.
• انتشار برچسب و انتشار یادداشت ها: چه چیزی تغییر کرده است، چگونه به رول، بازرسی.
• پینینگ/قفل فایل: رفع نسخه های وابستگی (ماژول ها، نمودار).
• نسخه های ماتریکس: مصنوع برنامه X با پیکربندی Y (ماتریس در کاتالوگ خدمات) سازگار است.

5) سازمان مخزن

config-repo/
policies/     # общие политики (RBAC, SLO, алерты)
services/
checkout/
schema/    # JSON/YAML схемы конфигов base/     # дефолтные значения overlays/
dev/
stage/
prod/
data-contracts/  # схемы данных, SLA свежести releases/     # теги, changelog, артефакты валидации tools/      # линтеры, генераторы, тесты

شعبه: شاخه های مبتنی بر تنه (اصلی) + ویژگی های کوتاه. ادغام - از طریق PR تنها با CI اجباری.

6) اعتبار سنجی و تست

Schema: هر تغییر اعتبار سنجی طرح (مورد نیاز، enum، محدوده) را منتقل می کند.
لاینترهای استاتیک: فرمت، کلید، تکراری، زمینه های ممنوع.
تست سازگاری: نسخه پیکربندی + سرویس/نمودار در sandbox بالا می رود.
تست اجرا می شود: برنامه های خشک اجرا، «چه اگر» حالت هدف تفاوت.
Policies-as-code: قوانین پذیرش (Rego/CEL) - چه کسی می تواند چه چیزی را تغییر دهد.

7) تنظیمات را باز کنید و رول کنید

تحویل پیشرفته: قناری 1٪ → 5٪ → 25٪ → با SLO-gardrails.
Deploy gate: هیچ SEV-1 فعال نیست، هشدارها سبز هستند، امضاها معتبر هستند، بازپرداخت آماده است.
برگشت: 'بازگشت برچسب vX. Y.Z 'یا تغییر به عکس فوری قبلی ؛ دستورات برگشت در کتاب اجرا مستند شده است.
حاشیه نویسی انتشار: نسخه پیکربندی در metrics/logs منتشر می شود تا به سرعت با حوادث مرتبط شود.

8) پیکربندی پویا و از راه دور

پیکربندی از راه دور/پرچم ویژگی: تغییر پارامترها بدون راه اندازی مجدد ؛ تمام پرچم ها نیز تحت GitOps هستند.
Borders: کدام پارامترها مجاز به تغییر به صورت پویا هستند (لیست لیست های سفید).
حافظه پنهان و سازگاری: TTL، نسخه ها، جایگزینی مجموعه اتمی (انتشار دو فاز).
نرده های ایمن: محدودیت ها و محدوده ها برای تغییرات در زمان اجرا، بازگشت خودکار هنگام خروج از SLO.

9) اسرار و اطلاعات حساس

هرگز اسرار را در یک مخزن نگه ندارید. در تنظیمات - فقط لینک ها/متغیرهایی.
رمزگذاری فایل های پیکربندی، در صورت لزوم: ادغام با مدیر مخفی/کلید.
چرخش و JIT: دسترسی برای مدت زمان عملیات صادر می شود ؛ مسير حرکت تغيير ناپذيره.
Field masking: اعتبارسنجی PII/secrets را از ورود به config منع می کند.

10) مدیریت محیط زیست

پایه + پوشش: تفاوت بین dev/stage/prod حداقل و شفاف است.
ارتقاء در مصنوعات: همان عکس فوری که از مرحله گذشت، در prod تبلیغ می شود.
پنجره های زمان: تغییرات در تنظیمات در زمان تغییر وظیفه رخ نمی دهد ؛ برای ریسک بالا - RFC و پنجره تعمیر و نگهداری.

11) تشخیص و حذف رانش

کنترل کننده وضعیت هدف را با وضعیت واقعی مقایسه می کند و تفاوت را گزارش می دهد.
هشدار رانش: صفحه فقط برای اختلافات بحرانی ؛ بقیه بلیط هستند.
اصلاح خودکار: با وضوح - بازگشت به حالت هدف.
ویرایش کتابچه راهنمای حسابرسی: هر «kubectl edit/ssh» → حادثه فرآیند و CAPA.

12) کاتالوگ پیکربندی و مالکیت

کاتالوگ خدمات: مالک، SLO، سیاست های مرتبط، طرح ها، نسخه ها، سازگاری.

RACI: چه کسی ارائه می دهد، چه کسی بررسی می کند، چه کسی تایید می کند ؛ CAB برای ریسک بالا

شفافیت: هر ورودی دارای تاریخچه نسخه و پیوندهایی به PR/tickets/AAR است.

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

پوشش:٪ از خدمات/سیاست برای GitOps (≥ هدف 95٪).
زمان سرب پیکربندی تغییرات: متوسط از روابط عمومی به تولید.
نرخ شکست تغییر: نسبت انتشار پیکربندی با rollback/incident.
میزان رانش: تعداد اختلافات/هفته و زمان حذف.
زمان بازگشت: بهبود متوسط به نسخه قبلی.
کامل بودن حسابرسی: نسبت تغییرات با شواهد کامل (اعتبار سنج، خشک اجرا، بررسی).

14) چک لیست

قبل از تغییر پیکربندی

• یک بلیط/RFC و یک صاحب تغییر وجود دارد.
• طرح ها و لاینترها تأیید شده اند.
• یک طرح بازگشت و دستورات در runbook وجود دارد.
• دروازه: تست سبز، امضا معتبر، بدون SEV-1 فعال.
• برای ریسک بالا، یک پنجره نگهداری اختصاص داده شده است.

در طول باز کردن

• قناری و SLO-gardrails فعال هستند.
• منتشر شده است.
• پیام های اکو به کانال وجود دارد ؛ سر و صدا هشدار سرکوب شده توسط قوانین MW.

بعد از آن

• پنجره مشاهده گذشت، SLO سبز.
• مجموع و شواهد (قبل/بعد از نمودار، گزارش خشک اجرا) به بلیط متصل شده است.
• به روز رسانی شماتیک/اسناد و مدارک به عنوان مورد نیاز است.

15) قالب های کوچک

15. 1 نمودار پیکربندی (YAML-schema، قطعه)

yaml type: object required: [service, timeouts, retries]
properties:
service: { type: string, pattern: "^[a-z0-9-]+$" }
timeouts:
type: object properties:
connect_ms: { type: integer, minimum: 50, maximum: 5000 }
request_ms: { type: integer, minimum: 100, maximum: 20000 }
retries:
type: object properties:
attempts: { type: integer, minimum: 0, maximum: 10 }
backoff_ms: { type: integer, minimum: 0, maximum: 5000 }

15. 2 پیکربندی پایه + تولید پوشش

yaml services/checkout/base/config.yaml service: checkout timeouts: { connect_ms: 200, request_ms: 1500 }
retries: { attempts: 2, backoff_ms: 200 }
limits:  { rps: 500 }
features:
degrade_search: false psp_a_weight: 80 psp_b_weight: 20

yaml services/checkout/overlays/prod/config.yaml limits:  { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 30

15. 3 سیاست پذیرش (ایده)

yaml allow_change_when:
tests: passed schema_validation: passed active_incidents: none_of [SEV-0, SEV-1]
rollback_plan: present signed_by: ["owner:team-checkout","platform-sre"]

15. 4 کارت انتشار پیکربندی

Release: checkout-config v2.3.1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (маршрутизация платежей)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2.3.0

16) ضد الگوهای

ویرایش در prod گذشته GitOps («به سرعت پیچ خورده»).
اسرار/PII در مخزن پیکربندی.
عدم وجود نمودارها و چک های استاتیک.
واگرایی قوی محیط (base≠prod).
«زنده» ویژگی های پرچم بدون نسخه و تاریخ.
نادیده گرفتن رانش و ویرایش دستی در سرورها.
برچسب ها بدون یادداشت انتشار و طرح بازگشت.

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

1. «ند». 1: موجودی پیکربندی ؛ کاتالوگ های جداگانه، طرح هایی برای خدمات برتر 10.

2. «ند». 2: شامل linters/validation و خشک اجرا در CI ؛ ممنوعیت ادغام بدون چک سبز

3. «ند». 3: رول GitOps + قناری ها ؛ حاشیه نویسی نسخه در تله متری.

4. «ند». 4 - الگوهای سیاست به عنوان کد و رول بک را وارد کنید. هشدار برای رانندگی

5. «ند». 5-6: پوشش 90٪ از خدمات ؛ کاهش تفاوت های ENV به پوشش ؛ اضافه کردن معیارهای بلوغ و بررسی هفتگی تغییرات پیکربندی.

18) خط پایین

کنترل نسخه پیکربندی یک سیستم است، نه فقط Git. نقشه ها و اعتبار سنجی، GitOps و سیاست های دسترسی، canaries و rollbacks، تشخیص رانش و حسابرسی کامل تبدیل پیکربندی به یک مصنوع مدیریت شده است. نتیجه تغییرات سریع و امن، پیش بینی SLO و اعتماد به نفس تیم در هر نسخه است.