ثقافة DevOps وأساسياتها

مقاييس DORA

18 دقيقة الدرس 5 من 28

مقاييس DORA

في عام 2014، أطلق برنامج البحث والتقييم للـ DevOps (DORA) أكبر دراسة طولية لأداء تسليم البرمجيات على الإطلاق. بحلول عام 2023، غطت قاعدة البيانات أكثر من 36,000 محترف من آلاف المنظمات حول العالم. النتيجة المحورية للدراسة: أربعة مقاييس تُميّز بشكل موثوق الفرق عالية الأداء عن الفرق ضعيفة الأداء، وهذه المقاييس تتنبأ بسرعة تسليم البرمجيات وكذلك بربحية المنظمة.

هذه المقاييس الأربعة — تكرار النشر، ووقت الانتقال للتغييرات، ومتوسط وقت الاستعادة (MTTR)، ومعدل فشل التغييرات — باتت المعجم القياسي في الصناعة لقياس قدرة فريق هندسي على التسليم. كل مزود سحابة رئيسي (Google وAWS وAzure) يتتبعها داخلياً. إذا انضممت إلى فريق DevOps ناضج، فسيُسأل عنها في أسبوعك الأول.

فكرة جوهرية: مقاييس DORA هي مقاييس نتائج، وليست مقاييس نشاط. تقيس نتائج عمليتك، لا مدى انشغال فريقك. الفريق الذي ينشر مرة شهرياً ويستغرق ثلاثة أيام للتعافي من انقطاع ليس من أصحاب الأداء العالي — حتى لو عمل 70 ساعة أسبوعياً.

المقياس الأول — تكرار النشر

التعريف: كم مرة ينشر فريقك إلى الإنتاج؟

تكرار النشر هو مؤشر لحجم الدُفعة. الفرق التي تنشر مرة كل ثلاثة أشهر تجمع شهوراً من العمل في إصدار واحد محفوف بالمخاطر. الفرق التي تنشر عدة مرات يومياً تُرسل تحسينات صغيرة جداً — كل عملية نشر صغيرة لدرجة أن التراجع عنها أمر بسيط.

نطاقات أداء DORA (تقرير 2023):

نخبوي: عند الطلب (عدة مرات في اليوم)
عالٍ: بين مرة يومياً ومرة أسبوعياً
متوسط: بين مرة أسبوعياً ومرة شهرياً
منخفض: أقل من مرة شهرياً

فرق Google تنشر إلى الإنتاج مئات المرات يومياً. Amazon تنشر إلى الإنتاج كل 11.7 ثانية في المتوسط. هذا ممكن فقط لأن عمليات النشر آلية ومختبرة ومحدودة نطاق التأثير بواسطة مفاتيح الميزات (feature flags) وإصدارات القناري (canary releases).

كيفية القياس: احسب عدد عمليات النشر الناجحة إلى الإنتاج يومياً (أو أسبوعياً). استخدم تقارير منصة CI/CD المدمجة، أو استعلم مباشرة من سجل النشر.

# استعلام تكرار النشر من اتفاقية تسمية git-tag
# الاتفاقية: كل نشر إنتاجي يُنشئ tag مثل "deploy/2025-06-10-1423"

git tag --list 'deploy/*' --sort=-version:refname \
  | awk -F/ '{print $2}' \
  | cut -c1-10 \
  | sort | uniq -c | sort -rn \
  | head -30
# الناتج: "  14 2025-06-10" يعني 14 نشر في ذلك اليوم

# GitHub Actions: إرسال حدث deployment عند كل push إلى main
# .github/workflows/deploy.yml (مقتطف)
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        run: ./scripts/deploy.sh
      - name: Record deployment
        uses: chrnorm/deployment-action@v2
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          environment: production

المقياس الثاني — وقت الانتقال للتغييرات

التعريف: كم يستغرق الوقت من دمج commit حتى يعمل ذلك الكود في الإنتاج؟

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

نطاقات أداء DORA (2023):

نخبوي: أقل من ساعة
عالٍ: بين يوم وأسبوع
متوسط: بين أسبوع وشهر
منخفض: أكثر من ستة أشهر

وقت الانتقال ليس مجرد مقياس سرعة — بل هو مقياس مخاطر. وقت انتقال مدته ستة أشهر يعني أن عملية نشرك تحتوي على ستة أشهر من التفاعلات غير المُختبرة بين التغييرات. وقت انتقال مدته ساعة يعني أنك تُرسل تغييراً واحداً صغيراً مفهوماً جيداً في كل مرة.

وقت الانتقال يُقاس من لحظة رفع commit حتى يعمل في الإنتاج — تحقق الفرق النخبوية هذا في أقل من ساعة.

المقياس الثالث — متوسط وقت الاستعادة (MTTR)

التعريف: عند وقوع حادث في الخدمة، كم يستغرق الوقت لاستعادة الخدمة للمستخدمين؟

MTTR هو أكثر مقاييس مرونة التشغيل العملية مباشرةً. يلتقط قدرتك على اكتشاف مشكلة، وفهمها، وإصلاحها أو التخفيف منها بسرعة. لا يشترط أن يكون الإصلاح تغيير كود — قد يكون تراجعاً عن نشر، أو تفعيل مفتاح ميزة، أو تغيير إعدادات، أو إعادة توجيه حركة مرور.

نطاقات أداء DORA (2023):

نخبوي: أقل من ساعة
عالٍ: أقل من يوم
متوسط: بين يوم وأسبوع
منخفض: أكثر من ستة أشهر

خطأ إنتاجي شائع: كثير من الفرق تقيس وقت الإصلاح (رقعة الكود) بدلاً من وقت الاستعادة (حل أثر المستخدم). إذا تدهورت خدمتك في 14:00 ونشرت الإصلاح في 16:00 لكن التراجع اكتمل في 14:12، فإن MTTR لديك هو 12 دقيقة — وليس ساعتين. اقس دائماً من بداية التأثير حتى استعادة الخدمة، وليس حتى إصلاح السبب الجذري.

تحقق الفرق النخبوية MTTR أقل من ساعة بالحفاظ على ثلاث قدرات تشغيلية:

اكتشاف سريع: تنبيهات تُطلق في غضون ثوانٍ من التأثير المرئي للمستخدم (لا حين يلاحظها إنسان).
تراجع سريع: القدرة على عكس نشر في أقل من 5 دقائق بأمر CLI واحد أو زر في لوحة التحكم.
مفاتيح الميزات: القدرة على تعطيل ميزة معطوبة لـ0% من المستخدمين دون نشر جديد على الإطلاق.

# Kubernetes rollback — يستعيد ReplicaSet السابق في ~30 ثانية
kubectl rollout undo deployment/api-server -n production

# تحقق من تاريخ النشر أولاً
kubectl rollout history deployment/api-server -n production
# REVISION  CHANGE-CAUSE
# 1         initial deploy
# 2         add payment retry logic      <-- يعمل حالياً
# 3         add promo-code validation    <-- معطوب، نتراجع عنه

# أمر واحد: تراجع لمراجعة محددة
kubectl rollout undo deployment/api-server --to-revision=2 -n production

# التحقق من الاستعادة
kubectl rollout status deployment/api-server -n production
# Waiting for deployment "api-server" rollout to finish: 2 out of 3 new replicas have been updated...
# deployment "api-server" successfully rolled out

المقياس الرابع — معدل فشل التغييرات

التعريف: ما نسبة عمليات النشر إلى الإنتاج التي تُؤدي إلى تدهور الخدمة أو تستلزم إصلاحاً عاجلاً/تراجعاً؟

يقيس معدل فشل التغييرات جودة عملية تسليمك. هو نسبة عمليات النشر الفاشلة إلى إجمالي عمليات النشر. لاحظ أن النشر الفاشل هو ما يُسبب تأثيراً مرئياً للمستخدم — وليس ما يحتوي على خطأ اكتُشف في مراجعة الكود.

نطاقات أداء DORA (2023):

نخبوي / عالٍ: 0–15%
متوسط: 16–30%
منخفض: 16–30% (نفس النطاق، لكنه يرتبط بتكرار أقل)

أهم ما توصلت إليه أبحاث DORA: ارتفاع تكرار النشر لا يُسبب ارتفاع معدل الفشل. الأداء النخبوي يتميز بأعلى تكرار نشر وأدنى معدل فشل في آنٍ واحد. الآلية مجدداً هي حجم الدُفعة — التغييرات الصغيرة المتكررة أسهل في الاختبار والمراجعة والتفكير فيها من الإصدارات الكبيرة الفصلية.

المقاييس الأربعة لـ DORA موزعة على بُعدين — إنتاجية النشر (السرعة) والاستقرار التشغيلي (الموثوقية).

جمع مقاييس DORA عملياً

تُجمع مقاييس DORA عادةً بدمج ثلاثة مصادر بيانات: منصة CI/CD (تكرار النشر ووقت الانتقال)، وأداة إدارة الحوادث (MTTR)، وسجل النشر أو نظام إدارة التغييرات (معدل فشل التغييرات). المهم هو أتمتة الجمع — العدّ اليدوي للحوادث في نهاية الربع ينتج أرقاماً مضللة.

# مثال: حساب مقاييس DORA من سجل حوادث منظّم
# تنسيق incidents.csv:
# deployment_id,deploy_ts,incident_start_ts,incident_end_ts,caused_by_deploy
# d1001,2025-06-01T09:00:00Z,,, false
# d1002,2025-06-01T14:00:00Z,2025-06-01T14:05:00Z,2025-06-01T14:52:00Z,true
# d1003,2025-06-02T10:30:00Z,,,false

python3 - <<'EOF'
import csv, datetime

deployments = []
incidents   = []

with open('incidents.csv') as f:
    for row in csv.DictReader(f):
        deployments.append(row)
        if row['caused_by_deploy'] == 'true':
            start = datetime.datetime.fromisoformat(row['incident_start_ts'])
            end   = datetime.datetime.fromisoformat(row['incident_end_ts'])
            incidents.append((end - start).total_seconds() / 60)

total = len(deployments)
failures = len(incidents)
cfr  = (failures / total) * 100 if total else 0
mttr = sum(incidents) / len(incidents) if incidents else 0

print(f"Total deployments : {total}")
print(f"Failed deployments: {failures}")
print(f"Change Failure Rate: {cfr:.1f}%")
print(f"Mean MTTR          : {mttr:.1f} min")
EOF

خرافة المقايضة بين السرعة والاستقرار

اعتراض شائع على استهداف تكرار نشر عالٍ هو "لا يمكننا التحرك بشكل أسرع لأن الاستقرار سيتأثر." بيانات DORA تدحض هذا باستمرار. الإنتاجية (تكرار النشر، ووقت الانتقال) والاستقرار (MTTR، ومعدل فشل التغييرات) مترابطان إيجابياً — الفرق التي تُسجّل عالياً في أحدهما تميل للتسجيل عالياً في الآخر. الآلية مجدداً هي حجم الدُفعة: التغييرات الصغيرة أقل خطورة بطبيعتها.

نقطة بداية عملية: إذا كان فريقك في النطاق المتوسط أو المنخفض، لا تحاول تحسين المقاييس الأربعة دفعة واحدة. حدد أكبر عنق الزجاجة. لدى معظم الفرق يكون ذلك وقت الانتقال — خط CI/CD بطيء (أكثر من 20 دقيقة) أو بوابة موافقة يدوية تنتظر مجلس استشارات التغييرات الأسبوعي. تقليص وقت الانتقال من 5 أيام إلى 4 ساعات يحسّن تكرار النشر و MTTR ومعدل فشل التغييرات في آنٍ واحد.

في الدرس 6 ستتعرف على كيفية ارتباط هذه المقاييس بالقصة الأشمل لتطور البنية التحتية — فهم أين يعمل نظامك لا يقل أهمية عن فهم مدى جودة تسليم التغييرات إليه.