--- title: 'إتقان ممارسات SRE: دليل كامل لعام' description: دليل شامل وعملي لممارسات هندسة موثوقية الموقع (SRE) — من SLIs و SLOs إلى استجابة الحوادث، والأتمتة، والقابلية للمراقبة — مصمم لفرق الهندسة الحديثة. url: https://nerdleveltech.com/ar/mastering-sre-practices-a-complete-2025-guide language: ar date: '2026-01-04' category: cloud-devops tags: - SRE - DevOps - Reliability Engineering - Monitoring - Automation - Incident Management - Scalability markdown_url: https://nerdleveltech.com/ar/mastering-sre-practices-a-complete-2025-guide.md attribution: 'Source: NerdLevelTech — https://nerdleveltech.com/ar/mastering-sre-practices-a-complete-2025-guide' terms: https://nerdleveltech.com/llms.txt --- # إتقان ممارسات SRE: دليل كامل لعام ## ملخص - **SRE (Site Reliability Engineering)** يدمج هندسة البرمجيات والعمليات لضمان أن الأنظمة موثوقة وقابلة للتوسع وفعالة. - الممارسات الأساسية تشمل **SLIs/SLOs/SLAs**, **ميزانية الأخطاء**, **إدارة الحوادث**, **المراقبة**, و**الأتمتة**. - قم بتبني SRE عندما تكون الموثوقية أولوية أعمالية رئيسية وعندما يكون للتعطل تكلفة حقيقية. - تجنب الهندسة المفرطة مبكرًا — ابدأ صغيرًا، قِس، ثم كرر. - النجاح يعتمد على الثقافة: تقارير ما بعد الحادث دون إلقاء اللوم، ملكية مشتركة، وتحسين مستمر. --- ## ما ستتعلمه - **المبادئ الأساسية** وتاريخ SRE. - كيفية تحديد وقياس **مؤشرات مستوى الخدمة (SLIs)** و**أهداف مستوى الخدمة (SLOs)**. - كيفية استخدام **ميزانية الأخطاء** لموازنة الموثوقية مع الابتكار. - كيفية إعداد سير عمل **المراقبة، التنبيهات، واستجابة الحوادث**. - كيفية **أتمتة العمليات** باستخدام الكود وتقليل العمل الروتيني. - كيفية بناء ثقافة تدعم **موثوقية مستمرة**. --- ## المتطلبات الأساسية ستحصل على أكبر قيمة من هذه المقالة إذا: - لديك معرفة أساسية بـ **DevOps** أو **إدارة الأنظمة**. - تفهم أساسيات **الأنظمة الموزعة**. - تَعْرِف أدوات مثل **Prometheus**، **Grafana**، أو **PagerDuty** (اختياري لكن مفيد). --- ## مقدمة: ما هي هندسة موثوقية الموقع؟ **Site Reliability Engineering (SRE)** نشأت في جوجل في أوائل عام 2000 كرد فعل لتعقيد تشغيل خدمات الويب الكبيرة[^1]. تم تشكيل المفهوم في كتاب جوجل *Site Reliability Engineering*، الذي عرّف SRE بأنه "ما يحدث عندما تطلب من مهندس برمجيات تصميم وظيفة عمليات." في جوهرها، تطبق SRE **مبادئ هندسة البرمجيات** على **مشاكل العمليات** — أتمتة العمل اليدوي، وتعزيز الموثوقية من خلال المقاييس، وضمان قدرة الأنظمة على التوسع بسلاسة. ### لماذا تهم SRE في عام 2025 مع انتشار **microservices**، **cloud-native deployments**، و**AI-driven workloads**، أصبحت الموثوقية أكثر أهمية وتعقيدًا. التوقف ليس مجرد إزعاج — بل له تكلفة. وفقًا لتحليلات الصناعة، يمكن أن يصل متوسط تكلفة التوقف للخدمات الإلكترونية الكبيرة إلى مئات الآلاف من الدولارات في الساعة[^2]. SRE تقدم **إطار عمل منظم قائم على البيانات** لإدارة هذا التعقيد. --- ## المبادئ الأساسية لـ SRE لنستعرض الأفكار الأساسية التي تجعل SRE تعمل. ### 1. مؤشرات مستوى الخدمة (SLIs) **SLI** هو قياس كمي لموثوقية الخدمة. تشمل مؤشرات مستوى الخدمة الشائعة: - **التوافر**: نسبة الطلبات الناجحة. - **التأخير**: الوقت المستغرق لخدمة طلب. - **معدل الأخطاء**: نسبة الطلبات الفاشلة. - **الإنتاجية**: عدد الطلبات المُعالجة في الثانية. مثال استعلام SLI باستخدام Prometheus: ```bash sum(rate(http_requests_total{status=~"2.."}[5m])) / sum(rate(http_requests_total[5m])) ``` هذا يعيد نسبة الطلبات الناجحة (2xx) إلى إجمالي الطلبات. ### 2. أهداف مستوى الخدمة (SLOs) **SLO** هو قيمة مستهدفة لـ SLI. على سبيل المثال: > يجب أن تنجح 99.9% من الطلبات خلال 200 مللي ثانية على مدار نافذة 30 يومًا متداولة. SLOs تساعد الفرق على موازنة الموثوقية والسرعة. إذا كانت صارمة جدًا، يتباطأ الابتكار؛ وإذا كانت مرخية جدًا، يعاني المستخدمون. ### 3. اتفاقيات مستوى الخدمة (SLAs) **SLA** هو عقد رسمي مع العملاء يتضمن عقوبات لعدم تحقيق بعض SLOs. عادةً ما تركز فرق SRE على SLOs الداخلية، بينما تدير الفرق التجارية SLAs. | المفهوم | التعريف | الجمهور | مثال | | ------- | ---------------------- | ---------------- | ------------------------------------------ | | **SLI** | قياس أداء الخدمة | المهندسين | 99.9% توافر | | **SLO** | هدف الموثوقية المستهدف | الهندسة + المنتج | 99.9% وقت تشغيل شهريًا | | **SLA** | اتفاقية قانونية/تجارية | العملاء | استرداد المبلغ إذا كان وقت التشغيل < 99.5% | ### 4. ميزانية الأخطاء **ميزانية الأخطاء** هي مستوى عدم الموثوقية المقبول. إذا كان SLO الخاص بك 99.9% وقت تشغيل، فإن ميزانية الأخطاء هي 0.1% وقت توقف شهريًا. ميزانيات الأخطاء تخلق **توترًا صحيًا** بين الموثوقية والابتكار: عندما تتجاوز الميزانية، تتوقف عن إصدار الميزات وتركز على الاستقرار. --- ## متى تستخدم SRE ومتى لا تستخدمها | السيناريو | استخدم SRE | تجنب SRE | | ----------------------------------------------------- | ---------- | ------------------------------------ | | تدير أنظمة كبيرة الحجم موجهة للعملاء | ✅ | | | تحتاج إلى أهداف موثوقية قابلة للقياس | ✅ | | | فريقك يواجه صعوبة في مواجهة الحرائق والعمليات اليدوية | ✅ | | | أنت شركة ناشئة صغيرة ذات موارد محدودة | | ⚠️ ابدأ صغيرًا بممارسات DevOps أولًا | | وقت توقف نظامك له تأثير أعمال ضئيل | | ⚠️ تكلفة SRE قد لا تبرر التكلفة | قاعدة عامة: ابدأ في تطبيق ممارسات SRE عندما تؤثر موثوقية نظامك مباشرة على الإيرادات أو ثقة العملاء. --- ## بناء ممارسة SRE: خطوة بخطوة ### الخطوة 1: تحديد SLIs وSLOs ابدأ بما يهم المستخدمين. حدد **رحلات المستخدم** (مثل تدفق الدفع، تشغيل الفيديو) وحدد المقاييس التي تعكس تجربتهم. مثال تعريف SLO في YAML: ```yaml service: checkout-API slo: availability: 99.9% latency_p95: 300ms error_rate: <0.1% window: 30d ``` ### الخطوة 2: القياس والمراقبة استخدم نظام مقاييس مثل **Prometheus** أو **Datadog** لجمع SLIs. ```bash # Example Prometheus rule record: api_availability_ratio expr: sum(rate(http_requests_total{status=~"2.."}[5m])) / sum(rate(http_requests_total[5m])) ``` عرض المقاييس في لوحات **Grafana** وقم بإعداد تنبيهات لانتهاكات SLO. ### الخطوة 3: أتمتة Toil يُشير مصطلح "Toil" إلى العمل اليدوي المتكرر الذي لا يتوسع[^3]. أمثلة تشمل إعادة تشغيل الخدمات المتعطلة أو تدوير السجلات. أتمتة Toil باستخدام السكربتات، أو خطوط أنابيب CI/CD، أو أدوات Infrastructure as Code مثل **Terraform**. مثال سكربت الأتمتة: ```python import subprocess import logging logging.basicConfig(level=logging.INFO) SERVICES = ["auth", "payments", "checkout"] for service in SERVICES: result = subprocess.run(["systemctl", "is-active", service], capture_output=True, text=True) if result.stdout.strip() != "active": logging.info(f"Restarting {service}...") subprocess.run(["systemctl", "restart", service]) ``` هذا السكربت يعيد تشغيل الخدمات غير النشطة تلقائيًا — أتمتة صغيرة لكنها ذات معنى. ### الخطوة 4: الاستجابة للحوادث عندما تتعطل الأشياء (وستتعطل بالتأكيد)، يحدد SRE عمليات منظمة للاستجابة بسرعة والتعلم من الأعطال. **دورة حياة الحادث:** ```mermaid flowchart TD A[Incident Detected] --> B[Alert Triggered] B --> C[On-call Engineer Responds] C --> D[Mitigation Applied] D --> E[Postmortem Written] E --> F[Action Items Tracked] ``` الممارسات الرئيسية: - **تقارير ما بعد الحادث دون إلقاء اللوم:** التركيز على التعلم وليس العقاب. - **Runbooks:** توثيق أنماط الأعطال المعروفة وخطوات الاسترداد. - **تناوب الورديات:** توزيع المسؤولية بشكل عادل. --- ## دراسة حالة واقعية: SRE على نطاق واسع تقوم الشركات الكبيرة غالبًا بنشر ممارسات SRE الخاصة بها. وفقًا لمدونة **Netflix Tech Blog**، تركز منهجية Netflix في الموثوقية على **الأتمتة، هندسة الفوضى، والقابلية للمراقبة** لضمان المرونة[^4]. وبالمثل، **Google**، حيث نشأ SRE، تستخدم **ميزانية الأخطاء** لتحقيق التوازن بين الموثوقية والابتكار[^1]. تُظهر هذه الأمثلة أن SRE لا يتعلق بالكمال — بل يتعلق بـ **الموثوقية المقاسة**. --- ## الأخطاء الشائعة والحلول | المزالق | الوصف | الحل | | ----------------------- | ------------------------------------------ | ------------------------------------------------- | | **كثرة المقاييس** | الفِرق تجمع كل شيء وتغرق في البيانات | ركز على عدد قليل من SLIs التي تعكس تجربة المستخدم | | **تجاهل error budgets** | الفِرق تستمر في النشر رغم انخفاض الموثوقية | فرض تجميد عندما يتم استنفاد budget | | **blame culture** | المهندسون يخشون الإبلاغ عن incidents | اتباع blameless postmortems | | **manual toil** | مهام ops المتكررة تضيّع الوقت | أتمتة باستخدام scripts أو CI/CD | | **alert fatigue** | كثرة alerts ضوضائية | ضبط عتبات التنبيهات واستخدام alerts مبنية على SLO | --- ## اعتبارات الأداء وقابلية التوسع والأمان ### الأداء SRE emphasizes **latency and throughput** as key SLIs. Monitoring these helps detect regressions early. Performance metrics to track: - **p95 and p99 latency** (tail performance) - **Request rate (RPS)** - **CPU/memory utilization** ### القابلية للتوسع SRE teams often design for **horizontal scalability** — adding more instances instead of vertically scaling a single server. Use **load testing** (e.g., k6, Locust) to validate scaling behavior. ### الأمان Reliability and security are intertwined. SREs collaborate with security teams to ensure: - **least privilege** for automation scripts. - **Secure secrets management**. - **Incident response integration** with security events. Adhering to **OWASP guidelines** for secure configuration and monitoring is standard[^5]. --- ## اختبارات ومعالجة الأخطاء في SRE ### استراتيجيات الاختبار SREs use multiple layers of testing: - **Unit tests** for logic correctness. - **Integration tests** for service dependencies. - **Load tests** for performance under stress. - **Chaos tests** for resilience. Example chaos test using Python: ```python import random import time import requests SERVERS = ["https://api1.example.com", "https://api2.example.com"] while True: target = random.choice(SERVERS) print(f"Simulating failure on {target}") # Simulate outage by blocking traffic or injecting delay time.sleep(random.randint(1, 10)) try: requests.get(target, timeout=1) except requests.exceptions.RequestException: print(f"{target} failed as expected") ``` ### أنماط معالجة الأخطاء - **graceful degradation:** Serve cached or partial results when dependencies fail. - **circuit breakers:** Temporarily stop sending requests to failing services. - **Retries with backoff:** Retry transient errors with exponential delay. --- ## المراقبة والقابلية على الملاحظة **Monitoring** tells you when something is wrong; **observability** helps you understand why. ### الأعمدة الثلاثة للقابلية على الملاحظة 1. **Metrics** – Quantitative data (e.g., latency, errors). 2. **Logs** – Detailed event data for debugging. 3. **Traces** – End-to-end request flow visualization. Example alert configuration in Prometheus: ```yaml - alert: HighErrorRate expr: rate(http_requests_total{status!~"2.."}[5m]) > 0.05 for: 10m labels: severity: critical annotations: summary: "High error rate detected" ``` ### هندسة القابلية على الملاحظة ```mermaid graph LR A[Application] --> B[Metrics Exporter] A --> C[Log Aggregator] A --> D[Tracing Agent] B --> E[Prometheus] C --> F[Elasticsearch] D --> G[Jaeger] E --> H[Grafana Dashboard] F --> H G --> H ``` --- ## الأخطاء الشائعة التي يرتكبها الجميع - **التعامل مع SRE كعنوان وليس كممارسة.** إنه عقلية، وليس وصف وظيفي. - **تخطي error budgets.** بدونها، تفقد أهداف الموثوقية معناها. - **الإفراط في التنبيهات.** كل تنبيه يجب أن يكون قابلًا للتنفيذ. - **تجاهل postmortems.** تفقد فرصًا تعليمية قيمة. - **التقليل من أهمية التغيير الثقافي.** نجاح SRE يعتمد على التعاون بين الفرق. --- ## دليل استكشاف الأخطاء وإصلاحها | المشكلة | السبب المحتمل | الحل | | ----------------------------- | -------------------------- | ------------------------------------------- | | تنبيهات متكررة جدًا | عتبات حساسة جدًا | تعديل قواعد التنبيهات وفقًا لـ SLOs | | لوحة SLO تظهر فجوات | مقاييس مفقودة | فحص إعدادات exporter | | تأخيرات في استجابة الحوادث | مشكلات في on-call rotation | تطبيق سياسة تصعيد واضحة | | فشل automation scripts | permission errors | استخدام service accounts مع least privilege | | postmortems لا تحسن الموثوقية | عدم متابعة action items | المتابعة والمراجعة بشكل دوري | --- ## النقاط الرئيسية > **SRE يتعلق بتوازن الموثوقية والسرعة.** > > - قياس ما يهم: SLIs و SLOs. > - استخدام error budgets لتوجيه القرارات. > - أتمتة toil وتبني التعلم بدون لوم. > - دمج قابلية المراقبة في كل شيء. > - ابدأ صغيرًا، كرر، وتطور. --- ## الأسئلة الشائعة **س1: هل SRE هو نفسه DevOps؟**\ لا. DevOps هو حركة ثقافية تركز على التعاون بين التطوير والتشغيل. SRE هو تطبيق ملموس لمبادئ DevOps مع مقاييس وممارسات محددة[^1]. **س2: ما حجم فريقي المطلوب قبل اعتماد SRE؟**\ ممارسات SRE مفيدة بمجرد أن تصبح الموثوقية قضية حرجة للأعمال — عادةً عندما يكون لديك عدة خدمات أو فرق تدير الإنتاج. **س3: ما الأدوات المستخدمة بشكل شائع في SRE؟**\ يتم استخدام Prometheus، Grafana، Kubernetes، Terraform، PagerDuty، وأدوات إدارة الحوادث بشكل واسع[^6]. **س4: كيف أقيس النجاح في SRE؟**\ تتبع انخفاض الحوادث، وتحسين الامتثال لـ SLOs، وانخفاض متوسط وقت التعافي (MTTR). **س5: هل يمكن لـ SRE العمل في الشركات الناشئة الصغيرة؟**\ نعم، لكن ابدأ بشكل مختصر — ركز على الأتمتة والرصد الأساسي قبل SLOs الرسمية. --- ## الخطوات التالية إذا كنت مستعدًا لإدخال SRE إلى مؤسستك: 1. ابدأ بتحديد SLO واحد لخدمتك الأكثر أهمية. 2. قم بإعداد الرصد والتنبيهات بناءً على هذا SLO. 3. أتمتة مهمة تشغيلية متكررة واحدة. 4. أجرِ أول blameless postmortem. 5. كرر العملية ووسع النطاق تدريجيًا. للتعلم المستمر، يمكنك قراءة كتاب Google *Site Reliability Engineering* و*The Site Reliability Workbook*. --- [^1]: Google SRE Book – *Site Reliability Engineering* [^2]: Uptime Institute, *Annual Outage Analysis* (2023) [^3]: Google SRE Book – *Eliminating Toil* [^4]: Netflix Tech Blog – *Automated Failure Injection at Netflix* [^5]: OWASP Foundation – *Top 10 Security Risks* [^6]: CNCF Landscape – *Observability and Analysis Tools*