ميزانيات الخطأ وإدارة SLO

1) لماذا ميزانية SLO والخطأ

SLO (هدف مستوى الخدمة) - مستوى الجودة المستهدف الذي يراه المستخدم ؛ SLI - مقياس ؛ ميزانية الخطأ - تحمل الانحرافات لكل نافذة (عادة 30/90 يومًا).
تحول ميزانية الخطأ الموثوقية من «التجريد» إلى مورد مُدار: عندما تحترق الميزانية بسرعة، نقوم بتجميد الميزات والشينيم ؛ عندما تكون الميزانية صحية - يمكنك تسريع الإصدارات.

2) اختيار SLI: ما يعتبر «جيدًا»

المعيار: «ناجح من وجهة نظر المستخدم».

2. 1 SLIs كلاسيكية

التوافر هو النسبة المئوية للطلبات الناجحة (باستثناء تلك التي ألغاها العميل).
"success = http_status ∈ {2xx, 3xx, 404} and no timeout' (404 يمكن اعتباره نجاح API للقراءة إذا كان من المتوقع دلالات).
الكمون: نسبة الطلبات أسرع من العتبة (على سبيل المثال، p95 ≤ 300 ms).
«good _ latency = duration_ms ≤ 300».
النضارة/الصلابة: «بيانات لا تزيد عن X دقيقة» (مخبأ، أدلة، معاملات).
الجودة: صحة النتيجة (تمرير المصدقين على الأعمال/الثوابت الخلفية).

2. 2 الحدود والقطاعات

يجب احتساب SLI حسب الشرائح المهمة: «الطريق»، «المستأجر/العلامة التجارية»، «المنطقة/الولاية القضائية»، «الدفع _ المزود». لذلك لن «تشوه» فشل مقبض نقدي واحد في جميع أنحاء النظام.

3) الصيغ والميزانية

3. 1 على أساس الطلب (المفضل لواجهة برمجة التطبيقات)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 قائمة على الوقت (لخدمات المعلومات الأساسية/البث)

SLO_uptime = good_minutes / total_minutes

3. 3 مثال على الأهداف

API العام: 99. 9٪ توافر في 30 يومًا → الميزانية = 0. 1%.
أقلام الدفع الحرجة: 99. 95%; الكتالوجات/البحث: 99. 5%.
زمن الوصول: p95 ≤ 300 ms on'/v1/payments'، p99 ≤ 800 ms.

4) أجهزة SLI

4. 1 المبادئ

سجلات/مسارات → مقاييس RED (معدل/أخطاء/مدة) مع دلاء صريحة.
تأكد من وضع «مستأجر» و «منطقة» و «مسار _ فئة» (بدون PII).
عد اثنين من المقاييس: «النجاح» و «المجموع» و «الكمون» و «السريع» و «الكلي».

4. 2 مثال بروميثيوس (معدل لكل 5 ملايين)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) التنبيهات حسب معدل الحرق (متعدد النوافذ ومتعدد الحروق)

5. 1 فكرة

نحن ننظر إلى مدى سرعة احتراق الميزانية بالنسبة للهدف. إذا كانت السرعة عالية على نافذة قصيرة وطويلة، فإننا نشير.

5. 2 ملفات تعريف العتبة (لـ SLO 99. 9%)

النداء: معدل الحرق ≥ 14. 4 × (10% الميزانية لمدة 1 ساعة و 5 في المائة لساعات 6).
التذكرة: معدل الحرق ≥ 6 × (2٪ في 6 ساعات و 1٪ في 24 ساعة).

5. 3 قواعد المثال (بروميثيوس، زائف)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

وبالمثل 6 ساعات/24 ساعة للتذكرة.

6) مكتب الميزانية: العمليات

6. 1 بوابات الإصدار

إذا كان رصيد الميزانية أقل من 25٪ وكان الاتجاه سلبيًا - «تجميد الرمز» على الميزات، فإن الأولوية هي SRE/الاستقرار.
يجب أن تحتوي إصدارات الكناري على شريحة SLO منفصلة ('نشر. البيئة =» الكناري»).

6. 2 تحديد أولويات الأعمال المتراكمة

توزيع قدرة القيادة بما يتناسب مع معدل الاحتراق وتأثير الإيرادات.
تبرير الديون الفنية بالمقاييس: «الإصلاح سيقلل معدل الحرق بنسبة Y٪».

6. 3 بعد الحادث

كل حادثة - RCA و «إصلاح لا يمكن التراجع عنه» (قابل للتنفيذ)، السيطرة «عادت إلى SLO».

7) SLO كرمز

7. 1 SLO مثال واضح (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 توليد القواعد

استخدم المولدات (المولد البطيء، البيرا، الكسلان) لإنشاء القواعد ولوحات القيادة والتقارير تلقائيًا.

8) تدهور SLO وحمايته

تساقط الأحمال: أعط إجابات سريعة دون اعتمادات «باهظة الثمن» في الذروة.
Cache & stale: قراءة «قديمة بينما تعيد المصادقة» для.
السعر/حدود التوافق: يحمي الخلف ؛ طرق هامة - أولوية.
الدائرة/المهلة: المهلة السريعة والفروع «الاحتياطية».
أعلام الميزة: تعطيل الميزات الثقيلة بزر واحد.

9) إمكانية رصد SLO

لوحات القيادة: SLO الفعلية مقابل الهدف، رصيد الميزانية، معدل الحرق، المساهمة حسب الطرق/مقدمي الخدمة.
الارتباط: من «ثقب» → SLO إلى مثال → تتبع محدد → السجلات/الملامح.
التقارير: أسبوعية - اتجاهات، استهلاك الميزانية، أهم أسباب التدهور.

10) أنتيباترن

واحد SLO «عالمي» لكل → يخفي المشاكل. الجزء.
«99. 99٪ على كل شيء" باستثناء التكلفة والواقع. اختر الأهداف من تجربة المستخدم.
تنبيهات وحدة المعالجة المركزية/الأكوام بدلاً من معدل الحرق/SLO.
تجاهل عمليات إعادة التوجيه 4xx/الطويلة التي تفسد UX.
نافذة غير شفافة (رولينج مقابل تقويم) - مقارنات بين «التفاح والبرتقال».

11) تفاصيل iGaming/Finance

المسارات النقدية (الودائع/عمليات السحب): فرادى المنظمات غير الحكومية التي تتجاوز المستوى العام (مثلاً) 99. توافر 95 في المائة ؛ p95 ≤ 250 ms).
مزودو PSP/KYC: SLO لكل مزود + تنبيهات لمساهمتهم في الحرق ؛ التبديل التلقائي للطريق (التوجيه الذكي).
الولايات القضائية/المستأجرين: المنظمات غير الحكومية والميزانيات حسب «المنطقة/الولاية/العلامة التجارية» بحيث لا «تغمر» المشكلة المحلية المقياس العالمي.
اللعبة المسؤولة: SLO لفترة تطبيق الحدود/الاستبعاد الذاتي (صيغ الامتثال).
مراجعة الحسابات/التنظيم: الاحتفاظ بتقارير مكتب الإحالة والحوادث ؛ الشفافية في عمليات المراجعة الداخلية للحسابات.

12) قائمة التحقق من الاستعداد

• يتم تحديد مؤشرات الاستدامة المستدامة (التوافر/زمن الكمون/الجودة/النضارة) والقطاعات (المسار/المستأجر/المنطقة).
• الأهداف (SLOs) واقعية ومتوافقة مع الأعمال التجارية ؛ هناك نوافذ متدحرجة 30/90 يومًا.
• التنبيهات حسب معدل الحرق مع النوافذ المتعددة (paging/ticket).
• SLO كرمز (قاعدة/مولد لوحة القيادة) ؛ تقارير الميزانية.
• ترتبط بوابات الإفراج ببقية الميزانية ؛ أقسام الكناري.
• يتم تنفيذ واختبار آليات التحلل (سقيفة، مخبأ قديم، دائرة، حدود).
• المقاييس ↔ ترابط المسارات، دفاتر تشغيل واضحة.
• المسارات المالية/القضائية - منظمات/تنبيهات منفصلة ؛ PSP/KYC مفصلة.
• استثمارات الموثوقية المنتظمة في الحوادث القديمة والقائمة على الحرق.

13) TL ؛ د

حدد SLIs حسب قيمة المستخدم، وضبط SLOs الواقعية، وإدارة عبر ميزانية الخطأ ومعدل الحرق باستخدام نوافذ متعددة. تمكين SLO-as-code وإطلاق البوابات والتدهور كما هو مخطط. الجزء حسب المسار/المستأجر/المنطقة ؛ للمسارات المالية الحفاظ على أهداف أكثر إحكامًا وتنبيهات منفصلة.