المهارات slo-implementation
📊

slo-implementation

آمن

تطبيق SLOs وميزانيات الأخطاء لـ SRE

متاح أيضًا من: wshobson

وازِن بين الموثوقية وسرعة تطوير الميزات باستخدام أهداف SLO قابلة للقياس وميزانيات الأخطاء. توقف عن الجدل حول الموثوقية وابدأ في قياسها باستخدام ممارسات SRE المعيارية في الصناعة.

يدعم: Claude Codex Code(CC)
📊 71 كافٍ
1

تنزيل ZIP المهارة

2

رفع في Claude

اذهب إلى Settings → Capabilities → Skills → Upload skill

3

فعّل وابدأ الاستخدام

اختبرها

استخدام "slo-implementation". ساعدني في تحديد SLIs و SLOs لخدمة API الخاصة بي. أحتاج إلى أهداف التوافر وزمن الاستجابة.

النتيجة المتوقعة:

إليك SLIs الموصى بها لـ API الخاص بك:

SLI التوافر:
- الطلبات الناجحة / إجمالي الطلبات
- الهدف: 99.9% (يسمح بـ 43.2 دقيقة توقف شهريًا)
- PromQL: sum(rate(http_requests_total{status!~'5..'}[28d])) / sum(rate(http_requests_total[28d]))

SLI زمن الاستجابة (p95 < 500ms):
- الطلبات تحت العتبة / إجمالي الطلبات
- الهدف: 99% (1% من الطلبات يمكن أن تكون بطيئة)
- PromQL: sum(rate(http_request_duration_seconds_bucket{le='0.5'}[28d])) / sum(rate(http_request_duration_seconds_count[28d]))

ميزانية الأخطاء:
- ميزانية 0.1% = 43.2 دقيقة/شهر
- نفذ تنبيهات معدل الحرق للكشف عند استهلاك الميزانية بسرعة كبيرة

استخدام "slo-implementation". أنشئ قواعد تنبيه Prometheus للكشف عن معدل الحرق متعدد النوافذ.

النتيجة المتوقعة:

قواعد تنبيه معدل الحرق متعدد النوافذ:

تنبيه الحرق السريع (حرج):
- النافذة: ساعة واحدة وتأكيد 5 دقائق
- العتبة: معدل حرق 14.4x
- يتم التشغيل عند: استهلاك 2% من ميزانية الأخطاء في ساعة واحدة
- الإجراء: تنبيه المهندس في نوبة العمل فورًا

تنبيه الحرق البطيء (تحذير):
- النافذة: 6 ساعات وتأكيد 30 دقيقة
- العتبة: معدل حرق 6x
- يتم التشغيل عند: استهلاك 5% من ميزانية الأخطاء في 6 ساعات
- الإجراء: إنشاء تذكرة لليوم العمل التالي

نفاد ميزانية الأخطاء (حرج):
- التشغيل: ميزانية الأخطاء المتبقية < 0%
- المدة: مستمر لمدة 5 دقائق
- الإجراء: تجميد الميزات، اجتماع عام للموثوقية

استخدام "slo-implementation". صمم سياسة ميزانية أخطاء لهدف SLO بنسبة 99.9%.

النتيجة المتوقعة:

سياسة ميزانية الأخطاء لـ SLO بنسبة 99.9%:

الميزانية: 0.1% = 43.2 دقيقة شهريًا

عند 100% من الميزانية المتبقية:
- سرعة التطوير طبيعية
- جميع الميزات مسموح بنشرها

عند 50% من الميزانية المتبقية:
- تأجيل التغييرات غير الأساسية
- تتطلب اختبارات إضافية للإصدارات
- زيادة تغطية المراقبة

عند 10% من الميزانية المتبقية:
- تجميد الميزات غير الحرجة
- إصدارات الأمان والإصلاحات العاجلة فقط
- اجتماعات وقوف يومية للموثوقية

عند 0% من الميزانية المتبقية:
- تجميد كامل للميزات
- التركيز 100% على تحسينات الموثوقية
- لا إصدارات دون موافقة SRE
- تحليل السبب الجذري مطلوب

التدقيق الأمني

آمن
v1 • 2/25/2026

Static analysis detected 35 potential security issues, all of which are false positives. The flagged 'Ruby/shell backtick execution' patterns are Markdown code formatting (backticks) used for PromQL queries and YAML examples. The 'weak cryptographic algorithm' flags are documentation text and annotations, not actual encryption code. This skill contains only documentation with no executable code, network operations, or security vulnerabilities.

1
الملفات التي تم فحصها
344
الأسطر التي تم تحليلها
2
النتائج
1
إجمالي عمليات التدقيق
مشكلات منخفضة المخاطر (2)
False Positive: Code Block Formatting
Static analyzer flagged Markdown code blocks (using backticks) as 'Ruby/shell backtick execution'. These are documentation code examples for PromQL queries and YAML configurations, not executable shell commands.
False Positive: Documentation Text
Static analyzer flagged 'weak cryptographic algorithm' at lines 3, 215, 229, 239. These are plain text descriptions and YAML comments in documentation, not actual cryptographic implementations.
تم تدقيقه بواسطة: claude

درجة الجودة

38
الهندسة المعمارية
100
قابلية الصيانة
87
المحتوى
21
المجتمع
100
الأمان
100
الامتثال للمواصفات

ماذا يمكنك بناءه

إنشاء خط أساس للموثوقية

تحديد SLIs و SLOs الأولية لخدمة مصغرة جديدة لوضع أهداف موثوقية قابلة للقياس وإنشاء تنبيهات تلتقط المشاكل الفعلية دون إرهاق الإنذارات الكاذبة.

تنفيذ حوكمة ميزانية الأخطاء

إنشاء سياسات ميزانية الأخطاء التي تجمد تلقائيًا عمليات النشر الخطرة عند تدهور الموثوقية، مما يساعد على الموازنة بين سرعة الميزات ومتطلبات الاستقرار.

تقليل إرهاق التنبيهات

استبدال تنبيهات العتبة الهشة بتنبيهات معدل الحرق متعددة النوافذ التي يتم تشغيلها فقط عند تدهور الموثوقية بشكل كبير، مما يقلل ضوضاء الإشعارات بنسبة 80%.

جرّب هذه الموجهات

تحديد SLOs الأساسية
ساعدني في تحديد SLIs و SLOs لخدمة API الخاصة بي. أحتاج إلى أهداف التوافر وزمن الاستجابة.
إنشاء سياسة ميزانية الأخطاء
صمم سياسة ميزانية أخطاء لهدف SLO بنسبة 99.9%. حدد الإجراءات عند 100% و50% و10% و0% من الميزانية المتبقية.
بناء تنبيهات SLO
أنشئ قواعد تنبيه Prometheus للكشف عن معدل الحرق متعدد النوافذ. استخدم نوافذ الحرق السريع (1 ساعة/5 دقائق) والحرق البطيء (6 ساعات/30 دقيقة).
مراجعة امتثال SLO
حلل بيانات امتثال SLO الحالية لدي. اعرض ميزانية الأخطاء المتبقية واتجاهات معدل الحرق وأوصِ بما إذا كان يجب تجميد إصدارات الميزات.

أفضل الممارسات

  • ابدأ بـ SLIs المواجهة للمستخدم التي تقيس تجربة العميل مباشرة بدلاً من مقاييس الخلفية
  • حدد أهداف SLO قابلة للتحقيق أقل قليلاً من الأداء الحالي للسماح بالتباين الطبيعي ومنع التنبيه المستمر
  • استخدم تنبيهات معدل الحرق متعددة النوافذ (اجمع النوافذ القصيرة والطويلة) للقضاء على الإيجابيات الكاذبة من الارتفاعات العابرة
  • راجع SLOs ربع سنويًا للتأكد من أنها لا تزال تعكس أولويات الأعمال واحتياجات المستخدمين الفعلية

تجنب

  • تحديد أهداف SLO عند توافر 100% مما يلغي كل ميزانية الأخطاء ويمنع أي تطوير للميزات
  • إنشاء تنبيهات على عتبات المقاييس الخام بدلاً من معدلات الحرق، مما يسبب إرهاق التنبيهات من التقلبات الطبيعية
  • تحديد الكثير من SLIs مما يخفف التركيز ويجعل من المستحيل تحديد أولويات تحسينات الموثوقية
  • تطبيق SLOs دون دعم تنفيذي لسياسات ميزانية الأخطاء، مما يجعل الحوكمة غير قابلة للتنفيذ

الأسئلة المتكررة

ما الفرق بين SLI و SLO و SLA؟
SLI (مؤشر مستوى الخدمة) هو مقياس مُقاس مثل نسبة التوافر. SLO (هدف مستوى الخدمة) هو هدفك الداخلي لهذا المقياس، مثل 99.9% توافر. SLA (اتفاقية مستوى الخدمة) هو الالتزام الخارجي الذي تقدمه للعملاء، والذي يجب أن يكون أقل من SLO الداخلي الخاص بك لتوفير مساحة أمان.
لماذا يجب ألا أستهدف موثوقية 100%؟
موثوقية 100% تترك صفر ميزانية أخطاء، مما يعني أن أي حادث ينتهك SLO الخاص بك فورًا. هذا يمنع كل تطوير الميزات因为你 لا يمكن أن تأخذ أي مخاطرة. هدف 99.9% يسمح بـ 43 دقيقة من التوقف شهريًا للصيانة والتجارب مع الحفاظ على تجربة مستخدم ممتازة.
كيف أختار نسبة SLO الصحيحة؟
حلل أداءك الحالي على مدار 30 يومًا، وحدد SLO أقل قليلاً من خط الأساس ذلك. ضع في اعتبارك توقعات المستخدم ومعايير المنافسين وتأثير الأعمال. ابدأ بشكل متحفظ (99%) وشدد مع بناء الثقة. الهدف هو أهداف قابلة للتحقيق تلتقط المشاكل الحقيقية، وليست الكمال.
ما هو تنبيه معدل الحرق متعدد النوافذ؟
تنبيهات متعددة النوافذ تتطلب كلًا من نافذة قصيرة (مثل ساعة واحدة) ونافذة طويلة (مثل 6 ساعات) لتتجاوز عتبات معدل الحرق في نفس الوقت. هذا يلغي الإيجابيات الكاذبة من الارتفاعات الموجزة مع catching التدهور المستمر. على سبيل المثال، قم بالتنبيه فقط إذا تجاوز معدل الحرق 14.4x في نافذتي الساعة الواحدة و5 دقائق.
كيف تعمل حوكمة ميزانية الأخطاء؟
ميزانيات الأخطاء تترجم SLOs إلى سياسات تطوير قابلة للتنفيذ. عندما تكون لديك ميزانية متبقية، انشر الميزات بشكل طبيعي. مع استنزاف الميزانية، جمّد التغييرات الخطرة. عند 0% ميزانية، أوقف جميع الميزات حتى تتحسن الموثوقية. هذا ينشئ حلقة تغذية مرتدة تلقائية توازن بين الابتكار والاستقرار.
ما الأدوات التي أحتاجها لتطبيق SLOs؟
تحتاج إلى نظام مقاييس (Prometheus موصى به)، وتصور (Grafana)، وتنبيه (Alertmanager). توفر هذه المهارة استعلامات PromQL وقواعد التسجيل وتكوينات التنبيه. انشر هذه إلى بنية المراقبة الحالية لديك، ثم ابنِ لوحات معلومات لتتبع الامتثال.

تفاصيل المطور

المؤلف

sickn33

الترخيص

MIT

مرجع

main

بنية الملفات

📄 SKILL.md