KPI های زیرساختی و زمان آماده به کار

چرا به آن نیاز دارید ؟

KPI های زیرساختی «احساسات» در مورد ثبات را به اهداف قابل اندازه گیری، مدیریت ریسک و تمرکز کار تبدیل می کنند. معیارهای مناسب SLI های فنی را به نتایج کسب و کار (تبدیل، زمان به کیف پول، LTV) پیوند می دهد و به شما امکان می دهد برای توسعه، بارگذاری و سهم نوآوری در مقابل قابلیت اطمینان برنامه ریزی کنید.

مفاهیم اساسی: SLI، SLO، SLA و بودجه خطا

SLI (شاخص سطح خدمات) - شاخص کیفیت اندازه گیری: نسبت درخواست های موفق، تاخیر p95، آپ تایم در هر فاصله.

SLO (هدف سطح خدمات) - هدف SLI (به عنوان مثال، "موفقیت ≥ 99. 9% در 30 روز)

SLA (توافق نامه) - وعده خارجی با مجازات/اعتبار. همیشه از SLO مشتق شده، اما برابر نیست.
بودجه خطا = «1 − SLO». این حداکثر نرخ شکست مجاز در هر پنجره اندازه گیری است. مورد استفاده برای تصمیم گیری در مورد انتشار خطرناک و آزمایش.

• در دسترس بودن SLO 99. 95% در 30 روز → بودجه خطا 0. 05% ≈ 21. 6 دقیقه «شکست» در یک ماه.

چهار سیگنال طلا و اضافی

1. تأخیر (p50/p90/p95/p99، دم مهمتر از حد متوسط است).
2. خطاها (خطاهای 5xx/timeout/business).
3. ترافیک/توان (RPS/QPS، MBps).
4. اشباع (CPU/RAM/IO/FD/اتصالات/GC/سهمیه).
اضافی: شروع سرد، صف/backlog، زمان استقرار، انطباق SLO.

مدل SLI برای انواع مختلف خدمات

HTTP/API

در دسترس بودن: (موفق 2xx/3xx − خطاهای منطقی )/( همه درخواست ها)

تاخیر: 'p95' برای نمایش داده شد موفق; هدف در مسیرهای داغ

کیفیت: نسبت درخواست ها با «مخاطب/دامنه» صحیح (بدون خطاهای authZ).

صف/ناهمزمان

زمان پردازش پیام: p95 پایان به پایان ≤ N ثانیه

Backlog: میانه <X, tail p99 <Y.
خطای تحویل: ≤ Z ppm.

DB/کش

تاخیر عملیات: p95 دریافت/قرار دادن/ارتکاب.
اشباع: استفاده از استخر اتصال، کش ضربه نسبت.
خطاها: وقفه، بن بست، طوفان اخراج.

CDN/استاتیک

نسبت ضربه: ≥ سطح هدف ؛ تخریب → بار رشد در مبدا.
در دسترس بودن POP: Anycast، شکست ها توسط همسایگان جبران می شود.

پرداخت (SLI کسب و کار)

زمان به کیف پول p95، موفقیت سپرده/خروجی٪، نرخ شکست PSP.

محاسبه در دسترس بودن و آپ تایم

در دسترس بودن خدمات = «درخواست های موفقیت آمیز/تمام درخواست ها» (ترجیحا «دقیقه به موقع»).
یک جایگزین برای گره های زیرساخت «زمان سبز/زمان پنجره» است.
پنجره تقویم: 28-31 روز، پنجره کشویی: آخرین 30/90 روز.
ساعات کار/پنجره های بحرانی: برای backoffice را می توان در نظر گرفته آپ تایم با توجه به برنامه (به عنوان مثال، 08: 00-22: 00 به وقت محلی).

• در دسترس بودن (A) ≈ Av (B) × Av (C) × Av (A 'B، C) - مهم است که SLO ها را در مرزها قرار دهید.

مثال کیت SLO (نمونه)

API دروازه: ≥ 99 در دسترس است. 95 ٪/30d ؛ تاخیر p95 ≤ 120 میلی ثانیه ؛ خطا ≤ 0 2%.
پرداخت/پرداخت: موفقیت سپرده ≥ 98. 5 ٪/30d ؛ زمان به کیف پول p95 ≤ 90 с ؛ خروجی PSP ≤ 0 3%.
پایگاه داده: p95 خواندن ≤ 10 ms ؛ p95 ارسال ≤ 25ms ؛ replica lag p95 ≤ 150 мс.

کش: نسبت ضربه ≥ 85٪ ؛ طوفان تخلیه = 0/30д

پرداخت: پردازش p95 ≤ 5 دقیقه ؛ تقلب-سقوط-مثبت ≤ 0. 3%.

بودجه خطا و مدیریت تغییر

اگر بودجه خطا توسط 50٪ + قبل از وسط پنجره خسته شده باشد، «توقف» ویژگی ها/انتشار ها معرفی شده است، تمرکز بر تثبیت است.
اگر بودجه به آرامی صرف شود، می توانید آزمایش ها/قناری ها را سرعت بخشید.
اتصال مصرف بودجه به انتشار خاص/حوادث از طریق 'release _ id'.

هشدار: چگونه به «تماس در شب» بیهوده

هشدارها فقط برای تخریب SLO و علائم حیاتی، نه برای هر متریک.
چند پنجره، نرخ چند سوختگی: پنجره کوتاه (5-15 دقیقه) + پنجره بلند (1-6 ساعت).
به عنوان مثال: «نرخ سوختن 14 × در 5 دقیقه و 6 × در 1 ساعت» → صفحه تماس بگیرید.
ساعت های آرام برای سیگنال های non-P1 ؛ مسیریابی مالکیت.

داشبورد و شیوه های تجسم

پانل SLO: انطباق خدمات، بودجه باقی مانده، نقشه های وابستگی.
پانل تاخیر: p50/p90/p95/p99، تجزیه توسط مسیرهای/مستاجران/کشورها/ASN.
پانل خطا: کدهای/دلایل، همبستگی با انتشار/پرچم ویژگی.
ظرفیت پانل: CPU/RAM/IO/شبکه/FD/اتصالات، روند و پیش بینی.
پنل کسب و کار: تبدیل، زمان به کیف پول، سپرده/برداشت، تاثیر حفاظت (WAF/ضد رباتها).

حوادث، MTTR و پس از مرگ

• MTTD (تشخیص)، MTTA (قبول)، MTTR/MTTC (بازیابی/مهار)،٪ حوادث بدون RCA در زمان.
• Playbooks: چه کسی تشدید می شود، چگونه پرچم ها/بلوک های ویژگی را روشن کنید، نحوه بازگرداندن انتشار، ارتباط با کسب و کار.
• Postmortem (بی گناه): حقایق، خط زمان، علل ریشه (کسانی که/فرآیندهای)، اقدامات: فوری/بلند مدت، آزمون رگرسیون، اثر بر SLO.

عملکرد، اشباع و تخریب

Headroom: headroom منابع هدف (به عنوان مثال،. پردازنده <70٪ p95، RAM <75٪ p95).
مسیرهای داغ: پروفایل مسیرهای بحرانی ؛ P99 مهمتر از حد متوسط است.
حالت های تخریب: فقط حافظه پنهان، فقط خواندن، قطره سنگ زنی از درخواست های بی اهمیت، «محدودیت نرخ «/سهمیه.

فرمول ها و نمونه هایی از محاسبات

1) در دسترس بودن بر روی تقاضا

availability = (total_requests - error_requests) / total_requests

where 'error _ requests' = 5xx + timeouts + خطاهای کسب و کار (قابل تنظیم).

2) بودجه خطا (دقیقه)

error_budget_minutes = window_minutes (1 - SLO)

مثال: 30 روز (43200 دقیقه)، SLO 99. 95% → 21. 6 دقیقه

3) میزان سوختگی

burn_rate = observed_error_ratio / (1 - SLO)

اگر SLO 99 باشد. 9% (بودجه 0) 1%) و خطای 1% → burn_rate = 10 ×.

4) در دسترس بودن ترکیب

A_total ≈ A_gw × A_auth × A_db × A_psp

سقوط کوچک ضرب ضربه کلی A.

سیاست های اندازه گیری و استثنا

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

نمونه هایی از مصنوعات

KQL/PromQL (ایده ها)

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (SLI کسب و کار پرداخت)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

مدیریت وابستگی ها و آبشارها

قرارداد SLO بین تیم ها: gateway↔auth↔wallet↔PSP.
سیاست های تخریب: هنگامی که وابستگی کاهش می یابد، سرویس به «حالت ساده» می رود.
پرچم های ویژگی: غیرفعال کردن توابع غیر بحرانی، «انتشار خاکستری» برای کاهش دم تاخیر.

برنامه ریزی و پیش بینی ظرفیت

«شومز». RPS/MBps پیش بینی شده توسط روند و رویدادها (مسابقات، مسابقات، تبلیغات).
تست بار توسط «مسیرهای طلایی»، آزمایش های جداگانه برای PSP/پرداخت.
سهام در اوج: عامل هدف 1. 3 × -2 0 × از بار مورد انتظار.

چک لیست اجرای SLO/KPI

1. شناسایی مسیرهای مهم کاربر و مذاکره SLI «از دیدگاه مشتری».

2. انتخاب اهداف SLO و پنجره (30/90 روز) ؛ بودجه خطا را محاسبه کنید

3. ساخت مجموعه متریک به دروازه/خدمات، عادی کد/دلایل.
4. پیکربندی هشدار سوختگی نرخ (کوتاه + پنجره طولانی)، مسیریابی و در تماس.
5. انطباق SLO را تجسم کنید، با انتشار/پرچم های ویژگی ارتباط برقرار کنید.
6. ایجاد یک بودجه در برابر سیاست تغییر و یک فرایند توقف.
7. بازنگری و RCA در هر بیش از حد، آزمون رگرسیون.
8. SLO ها را به صورت سه ماهه برای استفاده واقعی از بودجه و اهداف تجاری بررسی کنید.

اشتباهات رایج

اندازه گیری «uptime by ping»، نادیده گرفتن خطاهای برنامه.
SLO ها «ذخیره» تنظیم شده اند (99. 999٪)، اما غیر قابل دستیابی و حل هیچ چیز.
هشدارها در مورد معیارهای سطح پایین به جای علائم کاربر.
هیچ نقشۀ وابستگی وجود ندارد روشن نیست که در کجا میسوزد.
هیچ ارتباطی بین SLO و انتشار وجود ندارد و مشخص نیست که چه کسی «بودجه» را خورده است.
چشم پوشی از دم p99 → متوسط خوب اما کاربران VIP UX بد است.

iGaming/fintech خاص

قله های برنامه ریزی شده: مسابقات/رویدادها/تبلیغات - افزایش ظرفیت در پیشبرد، گرم کردن کش/CDN، شامل پروفایل های محدود خاص است.
SLI کسب و کار: زمان به کیف پول, موفقیت سپرده/برداشت, «سرعت پرداخت» p95; در ریشه داشبورد.
PSP/شرکا: SLO/داشبورد فردی توسط ارائه دهنده، سوئیچینگ مسیر خودکار.
Antibot/anti-fraud: نباید هیچ بودجه ای برای خطاها وجود داشته باشد - «بلوک های قانونی» را از «خطاهای فنی» جدا کنید.
مقررات: ذخیره سازی ورود، تکرارپذیری محاسبات SLO/SLA، گزارش های حادثه.

سوالات متداول

آیا باید کار برنامه ریزی شده را از SLO حذف کنم ؟

معمولا نه: SLO نشان دهنده تجربه کاربر است. شما می توانید استثنائات را برای SLA ها مشخص کنید.

چرا P95 متوسط نیست ؟

نفر وسط دم را میپوشاند ؛ UX تعریف دم (p95/p99).

آیا می توانم یک SLO برای کل محصول داشته باشم ؟

شما نیاز به یک درخت SLO دارید: جمع آوری محصول و کودکان توسط مسیرهای بحرانی/قطعات.

مجموع

یک سیستم KPI زیرساخت قوی SLI های سفارشی، SLO های واقع گرایانه، بودجه خطا به عنوان یک اهرم کنترل تغییر، هشدار هوشمند و نظم حادثه و RCA ها است. شاخص های فنی را با معیارهای کسب و کار متصل کنید، جمع آوری و تجسم را به صورت خودکار انجام دهید - و زیرساخت ها قابل پیش بینی خواهند بود و حتی در سناریوهای اوج نیز کنترل خواهد شد.