عملیات و هشدار → مدیریت توسط ظرفیت سیستم

هشدار ظرفیت سیستم

1) چرا شما به آن نیاز دارید

هشدارهای خازنی از نزدیک شدن به محدودیت های فنی طولانی قبل از حادثه هشدار می دهند: "ما 80٪ از سقف است - زمان مقیاس است. "برای کسب و کارهای مواد غذایی، این به طور مستقیم در مورد پول است: شرط های از دست رفته/سپرده، قطره جلسه، تاخیر در بازی زنده و شکست ارائه دهنده = درآمد از دست رفته، شهرت، جریمه و بازپرداخت.

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

2) مفاهیم اساسی

ظرفیت: حداکثر توان پایدار (RPS/TPS، اتصالات، IOPS، توان).
Headroom: حاشیه بین بار فعلی و محدودیت ها.
SLO/SLA: سطح هدف در دسترس بودن/زمان پاسخ ؛ هشدارها باید «SLO آگاه» باشند.
Burn-rate: سرعت «سوزاندن» بودجه SLO خطاها/تأخیر.
علامت بالا/پایین: سطوح بالا/پایین برای فعالیت و بازیابی خودکار.

3) معماری سیگنال و منابع داده

تله متری: معیارهای (Prometheus/OTel)، سیاهههای مربوط (ELK/ClickHouse)، ردیابی (OTel/Jaeger).
رویکرد لایه: هشدار توسط لایه ها (لبه → API → خدمات کسب و کار → صف/جریان → پایگاه داده ها/کش → فایل/فروشگاه شیء → ارائه دهندگان خارجی).
زمینه: پرچم های ویژگی، انتشار، کمپین های بازاریابی، مسابقات، هماهنگی جغرافیایی.
تایر حادثه: Alertmanager/PagerDuty/Opsgenie/Slack ؛ اتصال به runbook و ماتریس تشدید.

4) معیارهای کلیدی توسط لایه (چه برای نظارت و چرا)

لبه/L7

RPS، تاخیر 95-/99 درصد، میزان خطا (5xx/4xx)، اتصالات باز.
محدودیت نرخ/سهمیه، قطره на CDN/WAF/فایروال.

API- шлюз/Backend-for-Frontend

اشباع توسط کارگر/استخر کار، درخواست صف، timeouts به downstreams.
کسر تخریب (سقوط، قطع کننده مدار).

صف/جریان (کافکا/خرگوش/پولسار)

تاخیر/مصرف کننده تاخیر، نرخ رشد انباشته، توان (msg/s، MB/s).
انحراف پارتیشن، تعادل مجدد تعادل، ISR (برای کافکا)، retray/پدربزرگ-بعد.

کارگران ناهمزمان

اتمام کار، طول صف، درصد وظایف SLA منقضی شده.
اشباع CPU/حافظه/FD در استخر.

حافظه های پنهان (Redis/Memcached)

نسبت ضربه، تاخیر، اخراج، حافظه استفاده شده، مشتریان متصل/ops/s.
خوشه ها: اسلات/کپی، رویدادهای شکست خورده.

БД (PostgreSQL/MySQL/ClickHouse)

اتصالات فعال در مقابل حداکثر، انتظار قفل، تاخیر تکرار، ضربه بافر/کش.
IOPS، خواندن/نوشتن تاخیر، ایست بازرسی/خیط و پیت کردن، نفخ/تکه تکه شدن.

ذخیره سازی شیء/فایل

PUT/GET تاخیر، 4xx/5xx، خروج، درخواست/ثانیه، محدودیت ارائه دهنده.

ارائه دهندگان خارجی (پرداخت/LCC/ارائه دهندگان بازی)

محدودیت TPS, پنجره های QPS, نرخ خطا/اتمام وقت, retray صف, «هزینه هر تماس».

زیرساخت

CPU/حافظه/FD/IOPS/اشباع شبکه در گره/غلاف/ASG.
رویدادهای HPA/VPA، غلاف های در حال انتظار، OOM/Throttling کانتینر.

5) انواع هشدارهای خازنی

1. آستانه های استاتیک

ساده و سرراست: 'db _ connections> 80% max'. به عنوان يه سيگنال خوبه

2. آستانه تطبیقی (پویا)

بر اساس فصلی و روند (پنجره های نورد، تجزیه STL). اجازه دهید گرفتن «غیر معمول بالا برای این ساعت/روز هفته».

3. SLO گرا (نرخ سوختن)

آنها زمانی ایجاد می شوند که نرخ خوردن بودجه خطا SLO را در افق ساعت X به خطر می اندازد.

4. پیش بینی (پیش بینی هشدار)

«پس از 20 دقیقه در روند فعلی، صف به 90٪ خواهد رسید». پیش بینی خطی/مقاوم/پیامبر مانند در پنجره های کوتاه استفاده می شود.

5. چند سیگنال

Trigger with the combination: 'queue _ lag' ↑ + 'consumer _ cpu 85%' + 'autoscaling at max' → 'manual intervention is needed'.

6) سیاست های آستانه و ضد سر و صدا

• بالا: هشدار 70-75٪، کرت 85-90٪. پایین: هیسترزیس 5-10 pp به منظور «دید در آستانه».

• "برای: 5m" برای معیار، برای: 10-15m "برای هشدار. حالت شب: مسیر غیر بحرانی برای چت بدون صفحه بندی.

• گروه خدمات/خوشه/جغرافیایی به طوری که برای تولید کارت های حادثه.

• اگر ارائه دهنده KYC خارج شده باشد و خطاهای API به دلیل صفحه بندی مالک ادغام باشد، نه همه مصرف کنندگان.

• در طول دوره سهام، آستانه سر و صدا را برای «رشد مورد انتظار» افزایش دهید، اما هشدارهای SLO را دست نخورده بگذارید.

7) مثال قانون (شبه پرومتئوس)

ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8) رویکرد SLO و اولویت کسب و کار

از سیگنال به تاثیر کسب و کار: هشدار ظرفیت باید خطر را به SLO (بازی های خاص/معیارهای جغرافیایی/GGR، تبدیل سپرده) ارجاع دهد.
چند سطحی: هشدار برای سرویس در تماس ؛ کرت - صفحه مالک دامنه ؛ SLO-drop - حادثه بزرگ و کانال «خلاصه» تیم.
ویژگی های تخریب: کاهش بار اتوماتیک (فقط خواندن جزئی، کاهش ویژگی های سنگین، کاهش فرکانس پخش جکپات، خاموش کردن انیمیشن های «سنگین» در بازی های زنده).

9) خودکار مقیاس بندی و «درست» باعث می شود

HPA/VPA: هدف نه تنها توسط CPU/حافظه، بلکه با معیارهای کسب و کار (RPS، تاخیر صف، تاخیر P99).
زمان های گرم شدن: محدودیت های شروع سرد و ارائه دهنده را در نظر بگیرید (اسپین آپ ASG، سازندگان کانتینر، انبارهای گرم).

Guardrails: شرایط توقف در رشد بهمن مانند اشتباهات ؛ حفاظت در برابر «مشکل اسکالیم»

Capacity-playbooks: کجا و چگونه یک shard/party/replica اضافه کنید، نحوه توزیع مجدد ترافیک بر اساس منطقه.

10) فرآیند: از طراحی تا عملیات

1. نقشه برداری محدود: جمع آوری محدودیت های تنگنا «واقعی» برای هر لایه (حداکثر اتصال، IOPS، TPS، ارائه دهندگان سهمیه).
2. انتخاب معیارهای پیش بینی کننده: کدام سیگنال ها ابتدا «استراحت در N دقیقه» را نشان می دهند.
3. طراحی آستانه: بالا/پایین + SLO-burn + ترکیب.
4. Runbook برای هر کرت: مراحل تشخیصی («چه چیزی برای باز کردن»، «چه دستورات»، «جایی که برای تشدید»)، سه گزینه برای عمل: پیمایش سریع، پوسته پوسته شدن، تخریب.
5. تست: شبیه سازی بار (هرج و مرج/روز بازی)، شروع خشک هشدار، چک کردن ضد سر و صدا.
6. بررسی و تصویب: صاحب سیگنال = صاحب سرویس. بدون صاحب - بدون صفحه.
7. بازنگری و تنظیم: تجزیه و تحلیل هفتگی نادرست/از دست رفته ؛ متریک «MTTA (ack)، MTTD، MTTR، نسبت نویز/سیگنال».

11) ضد الگوهای

CPU> 90٪ وحشت ⇒: بدون ارتباط با تأخیر/صف، این ممکن است طبیعی باشد.
«یک آستانه برای همه»: مناطق مختلف/مناطق زمانی - پروفایل های مختلف ترافیک.
Alert without runbook: صفحه بدون عمل روشن بر روی تماس تخلیه می شود.
نابینایی به ارائه دهندگان: سهمیه/محدودیت های خارجی اغلب برای اولین بار به «شکستن» اسکریپت (PSP، KYC، ضد تقلب، ارائه دهندگان بازی).
بدون هیسترزیس: «اره» در مرز 80 ٪/79٪.

12) ویژگی های iGaming/سیستم عامل های مالی

قله برنامه: زمان نخست، فینال مسابقات، مسابقات بزرگ ؛ ترویج کپی هدف و پر کردن مخازن در پیشبرد.
جریانهای زنده و جکپات: انفجار رویدادهای پخش → محدودیت در کارگزاران/وب سایت ها.
پرداخت و KYC: پنجره های ارائه دهنده، امتیاز ضد تقلب ؛ مسیرهای یدکی و سپرده های «grace-mode» را نگه دارید.
Geo-balance: شکست های ارائه دهنده محلی - برای هدایت ترافیک به یک منطقه همسایه که در آن یک سر و صدا وجود دارد.
مسئولیت: در معرض خطر از دست دادن شرط/jackpots - صفحه فوری به تیم دامنه + هشدار کسب و کار.

13) داشبورد (حداقل مجموعه)

بررسی اجمالی ظرفیت: headroom توسط لایه، بالا 3 مناطق مخاطره آمیز، سوزاندن نرخ SLO.
جریان و صف: تاخیر، رشد انباشته، اشباع مصرف کننده، حالت HPA.
DB & Cache: اتصالات، repl-lag، تاخیر p95/p99، نسبت ضربه، اخراج.
ارائه دهندگان: TPS/ویندوز/سهمیه بندی، زمان بندی/خطاها، هزینه تماس.
زمینه انتشار/ویژگی: releases/phicheflags در کنار منحنی ها.

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

• فهرست محدودیت ها و صاحبان «واقعی».
• پیش بینی متریک نقشه + بین لایه انجمن.
• آستانه استاتیک + هیسترزیس.
• هشدار سوزاندن SLO در مسیرهای بحرانی (سپرده، شرط، راه اندازی بازی زنده).
• هشدار پیش بینی در صف/جریان/اتصالات.
• سرکوب/نگهداری پنجره ؛ سیاست ضد سر و صدا
• Runbook "و با دستورات، نمودارها، فیلترهای تخریب.
• تجزیه و تحلیل هفتگی مثبت کاذب و تنظیم.
• حساب برای کمپین های بازاریابی و تقویم رویداد.

15) الگوی runbook مثال (به صورت مختصر)

سیگنال: «StreamBacklogAtRisk»

هدف: برای جلوگیری از رشد تاخیر> 10 میلیون و تاخیر درمان> 5 دقیقه.

1. «hpa _ desired/max»، دریچه گاز/کف در چاله ها را بررسی کنید.

2. نمایش 'نرخ (تاخیر)'، پارتیشن بندی (انحراف).

3. بررسی کارگزار (ISR، زیر تکرار، شبکه).

• افزایش کپی مصرف کننده توسط + N، افزایش حداکثر در پرواز.
• استخر اولویت را در «موضوعات مهم» فعال کنید.
• به طور موقت فرکانس درمان های ثانویه/غنی سازی را کاهش می دهد.
• اگر 'ASG در حداکثر' - درخواست ارتقاء موقت از ابر ؛ به طور موازی - امکان تخریب توابع سنگین را فراهم می کند.
• بازگشت: بازگشت به مشخصات ترافیک عادی پس از 'تاخیر <1 میلیون' 15 دقیقه.
• تشدید: مالک خوشه کافکا، سپس پلت فرم SRE.

16) KPI و کیفیت سیگنال

پوشش:٪ از مسیرهای بحرانی بسته شده توسط هشدار خازنی.
سر و صدا/سیگنال: بیش از 1 صفحه نادرست در هر تماس/هفته.
MTTD/MTTR: حوادث خازنی ≤5 دقیقه قبل از حملات SLO شناسایی می شوند.
Proactive saves: تعداد حوادثی که از آنها جلوگیری می شود.

17) شروع سریع (پیش فرض محافظه کار)

DB: هشدار 75٪ اتصالات/IOPS/lat ؛ کرت 85٪، هیسترزیس 8-10 pp

Caches: 'ضربه <0. 9 'و' اخراج> 0 '> 5 دقیقه - هشدار ؛' used _ mem> 85٪ '- کرت.
صف: 'تاخیر' ارتفاع> 3 σ از متوسط برای 30D + 'HPA در حداکثر' - کرت.
API: 'p99> SLO1. 3 '10 دقیقه - هشدار ؛' نرخ سوختن> 4 '15 دقیقه - کرت.
ارائه دهندگان: 'توان> 90٪ سهمیه' - هشدار ؛ 'timeouts> 5%' - کرت.

18) سوالات متداول

س: چرا فقط «CPU> 80٪» نیست ؟

A: بدون تاخیر/زمینه صف، سر و صدا است. CPU به خودی خود برابر با خطر نیست.

س: آیا ما نیاز به آستانه تطبیقی داریم ؟

A: بله، برای فصلی روزانه/هفتگی - مثبت کاذب را کاهش دهید.

س: چگونه بازاریابی/رویدادها را در نظر بگیریم ؟

A: تقویم کمپین → حاشیه نویسی در نمودار + تنظیم موقت ضد سر و صدا، اما هشدارهای SLO را لمس نکنید.