فناوری و زیرساخت → معماری ابر و SLAs

معماری ابر و SLA ها

1) چرا SLA ها و نحوه مدیریت آنها

SLA (توافقنامه سطح خدمات) - وعده خارجی به کسب و کار/شرکا در مورد در دسترس بودن، سرعت و صحت خدمات.
SLO (هدف سطح خدمات) - سطح هدف داخلی برای دستورات.
SLI (شاخص سطح خدمات) - معیارهای قابل اندازه گیری بر اساس SLO ارزیابی می شود.

iGaming/fintech با پنجره های اوج سفت و سخت (مسابقات، شرط بندی زنده، دوره های گزارش، روزهای «حقوق و دستمزد»)، وابستگی شدید به ارائه دهندگان PSP/KYC و جغرافیا مشخص می شود. SLA ها باید این رفتار را در نظر بگیرند و معماری باید نه تنها متوسط، بلکه درصد را نیز تضمین کند.

2) اصطلاحات عمومی

در دسترس بودن - درصد درخواست های موفق در هر دوره.

Latency: P50/P95/P99 برای عملیات کلیدی

خطا - تعیین دقیقا (5xx، timeout، خطای کسب و کار ؟).
RTO (Recovery Time Objective): مقدار زمان مجاز برای بازیابی.
Recovery Point Objective (RPO): چه مقدار اطلاعات را می توان در یک فاجعه از دست داد.
بودجه خطا - 1 − SLO، «ذخیره» برای تغییرات و حوادث.

3) چارچوب معماری ابر برای SLA

3. 1 چند منطقه (چند AZ)

تکرار دولت (DB، کش، صف) به حداقل 2-3 AZ.
standbys سرد/گرم، failover خودکار.
متعادل کننده های محلی (L4/L7) با چک های بهداشتی در هر AZ.

3. 2 چند ضلعی

دارایی به دارایی: RTO/RPO کم، سازگاری سخت تر و هزینه.
دارایی بدهی (گرم/گرم): ارزان تر، RTO بیشتر، اما کنترل داده ها آسان تر است.
مسیریابی جغرافیایی (GeoDNS/Anycast)، انزوای «شعاع انفجار».

3. 3 ذخیره سازی و داده ها

پایگاه داده های عملیاتی: تکرار همزمان در منطقه، بین منطقه ای ناهمزمان.
Cache: کپی های بین منطقه ای، حالت «خواندن محلی + async warmup».
ذخیره سازی شی: نسخه، چرخه زندگی، تکرار متقابل منطقه.
صف/جریان: خوشه آینه/جریان چند منطقه.

3. 4 عایق حلقه

تفکیک خدمات مهم (پرداخت/کیف پول) و وظایف تحلیلی «سنگین».
محدودیت های نرخ/سهمیه بین خطوط، به طوری که گزارش ها «تحریک» را نمی خورند.

4) الگوهای دسترسی بالا

جداسازی Bulkhead & Pool - استخرهای اتصال و منابع را جدا کنید.
Circuit Breaker + Timeouts - حفاظت در برابر انجماد ادغام خارجی.
Idempotency - تکرار درخواست بدون دو نوشتن.
تخریب برازنده - هنگامی که تنزل، غیر فعال کردن ویژگی های غیر اساسی (آواتار، فیلترهای پیشرفته).
Backpressure - کنترل جریان ورودی، صف اجازه نمی دهد «به افق».
هرج و مرج/تزریق شکست - «شکست» برنامه ریزی شده برای تست فرضیه های قابلیت اطمینان.

5) DR (بازیابی فاجعه) استراتژی

انتخاب: پرداخت/کیف پول - حداقل آماده به کار داغ ؛ محتوا/دایرکتوری - گرم ؛ گزارش ها - پشتیبان گیری و بازیابی با پنجره های روشن.

6) درباره SLI/SLO: نحوه اندازه گیری صحیح

6. 1 SLI بر اساس سطح

SLI مشتری: پایان دادن به پایان (از جمله دروازه و ارائه دهندگان خارجی).
SLI سرویس: «خالص» تاخیر خدمات/خطاها.
SLI کسب و کار: CR (registratsiya → depozit)، T2W (زمان به کیف پول)، نرخ کاهش PSP.

6. 2 نمونه های SLO

دسترسی به هسته API: ≥ 99. 95 درصد در 30 روز

تاخیر پرداخت: P95 ≤ 350 میلی ثانیه، P99 ≤ 700 میلی ثانیه.
تحویل وب سایت PSP: ≥ 99. 9٪ برای 60 ثانیه (با retras).
گزارش تازگی داده: ≤ 10 دقیقه تاخیر در 95٪ از زمان.

6. 3 خطا در سیاست بودجه

50٪ از بودجه - برای تغییرات (انتشار/آزمایش)، 50٪ - برای حوادث.
احتراق بودجه → ویژگی فریز، تنها ثبات.

7) عملکرد و مقیاس گذاری

HPA/VPA با سیگنال های SLO گرا (نه تنها CPU، بلکه صف/تاخیر).
مقیاس بندی پیش بینی بر اساس برنامه ها و قله های تاریخی.
استخرهای گرم/اتصالات پیش گرم کردن به DB/PSP قبل از مسابقات.
ذخیره سازی و لبه - کاهش RTT، به ویژه برای کاتالوگ های بازی و دارایی های استاتیک.

8) لایه شبکه و ترافیک جهانی

Anycast/GeoDNS برای به حداقل رساندن تاخیر و محلی کردن تصادفات.
سیاست های شکست خورده: آزمایش های بهداشتی منطقه، آستانه، «چسبندگی» با TTL.
mTLS/WAF/Rate Limit در لبه، حفاظت در برابر ترافیک ربات.
کنترل خروج به PSP/KYC توسط اجازه لیست و SLA آگاه عقب نشینی.

9) اطلاعات و سازگاری

سطح سازگاری را انتخاب کنید: سخت (پرداخت) در مقابل نهایی (کاتالوگ/رتبه بندی).
CQRS برای بارگیری خواندن و عمودی دستورات بحرانی.
صندوق خروجی/صندوق ورودی برای تحویل رویداد «دقیقا یک بار».
مهاجرت بدون downtime: گسترش-مهاجرت-قرارداد، ورود دو برابر در طول تغییرات عمده.

10) قابلیت مشاهده تحت SLA

ردیابی از طریق دروازه: ارتباط «trace _ id» با نسخه شریک/منطقه/API.
داشبورد SLO با نرخ سوختگی، «آب و هوا» بر اساس منطقه و ارائه دهنده.
هشدار توسط علائم، نه توسط علائم پروکسی (نه CPU، اما P99/خطاها).
Synthetics: چک های خارجی از کشورهای هدف (TR، BR، EU...).
حسابرسی و گزارش دهی: صادرات SLI/SLO به پورتال شریک.

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

تقسیم بندی شبکه و مدیریت مخفی (KMS/Vault)

رمزگذاری در پرواز/استراحت، نشانه گذاری PAN/PII.
سیاست های دسترسی نقش برای مدیران/اپراتورها.
گزارش های غیر قابل تغییر (WORM) و نگهداری برای حسابرسی.
تنظیم مقررات: ذخیره سازی در منطقه، گزارش ها، قابلیت اجرای SLA.

12) FinOps: SLA به عنوان یک راننده هزینه

قیمت ها را بر روی انحراف SLO قرار دهید: چقدر + 0 است. 01% در دسترس بودن

پنجره های اوج مشخصات، قدرت ثابت را باد نکنید.
اندازه راست و «نقطه که در آن شما می توانید» برای وظایف پس زمینه.
سهمیه ها و بودجه ها برای خطوط، اجازه تخریب «آزاد» را نمی دهند.

13) تست قابلیت اطمینان

جلسات GameDay/Chaos: خاموش کردن AZ/PSP، تاخیر در صف، شکستن BGP.
DR-drili: آموزش منظم مناطق سوئیچینگ با اهداف برای RTO.
Load & Soak: اجرای طولانی با پروفایل های شرط بندی/مسابقات واقعی.
پخش حوادث: یک کتابخانه از فایل های معروف و اسکریپت پخش.

14) طرف فرآیند SLA

دایرکتوری SLO: مالک، فرمول، معیارها، منابع، هشدارها.

تغییرات از طریق RFC/ADR: ارزیابی تاثیر بر بودجه خطا

پست مورتم: بهبود معماری و ranbooks، تنظیم SLO.
ارتباطات با شرکای: پستها، صفحه وضعیت، تعمیر و نگهداری برنامه ریزی شده.

15) نمونه های SLI/SLO/گزارش

15. 1 فرمول ها

SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек

15. 2 هسته API SLO مجموعه مثال

در دسترس بودن (30 روز): 99. 95%

نقطه پایانی P95/v2/پرداخت/ایجاد: ≤ 350ms

خطاهای 5xx (نورد 1 ساعت): <0. 3%

تحویل Webhook ≤ 60 сек (P99): ≥ 99. 9%

RPO برای کیف پول: ≤ 60 ثانیه، RTO ≤ 5 دقیقه

15. 3 گزارش SLA (فشار دادن)

تکمیل شده: 99 97٪ (SLO 99) 95%) +

نقض: قسمت 2 در هر منطقه BR به دلیل وقفه PSP (تجمعی 8 دقیقه).
اقدامات: اضافه هوشمند مسیریابی توسط کدهای شکست، افزایش استخر گرم از اتصالات به PSP-B.

16) چک لیست پیاده سازی

1. مسیرهای بحرانی کاربر و SLI های مربوطه تعریف شده اند.
2. SLO برای 30/90 روز + سیاست بودجه خطا.
3. طرح چند منطقه ای و DR با اهداف RTO/RPO، تمرینات منظم.
4. مصنوعی از هدف جغرافیایی، داشبورد در هر منطقه/در هر PSP.
5. الگوهای پایداری: قطع کننده مدار، فشار پشتی، بی نظمی.
6. سیاست تخریب و ویژگی های پرچم برای ویژگی های غیر فعال.
7. FinOps: بودجه کانتور، پیش بینی اوج، استخرهای گرم.
8. امنیت: تقسیم بندی، رمزگذاری، حسابرسی.
9. مستندات SLA برای شرکا، روند ارتباطات.
10. بازنگری و SLO تجدید نظر هر 1-2 چهارم.

17) ضد الگوهای

وعده SLA بدون SLI قابل اندازه گیری و تکنیک های شمارش شفاف.
شمارش در دسترس بودن «در ورودی سرویس»، نادیده گرفتن دروازه/ارائه دهندگان.
فقط به تأخیر متوسط تکیه کنید و دم P99 را نادیده بگیرید.
DR «بر روی کاغذ»، عدم آموزش واقعی.
منابع «ابدی» بدون محدودیت: یک گزارش انگیزه را پایین می آورد.
تجزیه و تحلیل مواد غذایی و سنگین را در یک خوشه/پایگاه داده ترکیب کنید.

18) خط پایین

معماری ابر برای SLA ها ترکیبی از الگوهای فنی (چند AZ/منطقه، انزوا، داده های مقاوم در برابر خطا)، فرآیندها (SLO، بودجه خطا، DR-دریل) و اقتصاد (FinOps) است. به خودتان حق پیش بینی شکست را بدهید: تحمل خطا را آزمایش کنید، با درصد اندازه گیری کنید، «شعاع انفجاری» را محدود کنید و به طور آشکار ارتباط برقرار کنید. وعده های SLA پس از آن نه بازاریابی بلکه عمل مهندسی مدیریت می شود.