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

مشروع: رسم خريطة مسار التسليم

25 دقيقة الدرس 10 من 28

مشروع: رسم خريطة مسار التسليم

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

خريطة مسار التسليم ليست شريحة عرض جميلة. إنها وثيقة حيّة تُجيب على: أين تتدفق القيمة، وأين تتباطأ، وأين تختبئ الإخفاقات؟ بعد هذا المشروع ستكون قادرًا على إجراء نفس التحليل لأي منظمة تنضم إليها.

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

سيناريو ShopFast

تُشغّل ShopFast واجهة برمجية أحادية (Rails API) وتطبيق React SPA وخمس خدمات مصغرة (المخزون والمدفوعات والإشعارات والبحث والتوصيات). يضم الفريق 40 مهندسًا في ثلاث فرق. مسار تسليمهم الحالي، المُعاد بناؤه من المقابلات، يبدو هكذا:

يدفع المطورون إلى فروع الميزات ويفتحون طلبات سحب (PRs). تستغرق المراجعات 1-3 أيام.
تُشغّل عمليات الدمج في main مسار Jenkins. يستغرق البناء 22 دقيقة.
يُشترط موافقة يدوية من فريق QA قبل الترقية إلى Staging. يمتلك QA بيئة واحدة مشتركة. وقت الانتظار في الطابور عادةً 4 ساعات.
يعمل Staging لمدة 48 ساعة كحد أدنى ("وقت النقع"، مُفرض بالسياسة).
تجتمع لجنة الإصدار كل ثلاثاء للموافقة على عمليات النشر في الإنتاج.
تحدث عمليات نشر الإنتاج كل أسبوعين مساء كل جمعة. عمليات الرجوع للخلف يدوية وتستغرق 45 دقيقة.
المراقبة عبر Datadog. تذهب التنبيهات إلى قناة Slack مشتركة. يوجد دوران للمناوبة لكن دفاتر التشغيل قديمة.

قبل رسم أي مربع، يحسب المهندس الأقدم لقطة DORA من البيانات أعلاه. تكرار النشر: حوالي مرتين شهريًا. زمن الانتظار للتغييرات: أسبوعان + 4 ساعات قائمة انتظار QA + 3 أيام مراجعة = حوالي 17 يومًا في أسوأ الأحوال. هذه الأرقام وحدها تُخبرك أن المسار لديه مشكلة هيكلية — تقع في النطاق المنخفض لـ DORA.

الخطوة الأولى — تحديد المراحل والفاعلين

كل مسار تسليم له نفس المراحل الخمس الكبيرة بغض النظر عن الأدوات. رتّب ShopFast عليها أولاً، ثم أضف أدواتها الفعلية فوقها:

خريطة مسار ShopFast الحالية — المراحل والفاعلون وتفصيل زمن الانتظار. الأصفر = عنق الزجاجة؛ الأحمر = هدر تقويمي.

الخطوة الثانية — تسمية كل انتقال

مخطط المراحل الخام لا يكفي. خريطة المسار الاحترافية تُسمّي كل انتقال بين المراحل: ما يُشغّله، وما البوابة التي يجب اجتيازها، وكم يستغرق الانتظار عادةً. استخدم جدولًا بسيطًا بجانب المخطط:

# جرد انتقالات مسار ShopFast
# التنسيق: من → إلى | المشغّل | البوابة | متوسط الانتظار

feature branch → main        | PR merged    | 2 approvals (no automation)  | ~2 days
main → Jenkins build         | git push     | automatic (webhook)          | <1 min (queue)
Jenkins → QA environment     | build passes | manual QA team action        | ~4 hours
QA environment → staging     | QA sign-off  | QA lead approves ticket      | same-day
staging → release committee  | 48h elapsed  | Tuesday meeting slot         | up to 6 days
release committee → prod     | vote passes  | ops manual deploy script     | same Friday

الملاحظة الفورية: خمسة من ستة انتقالات لها بوابة بشرية. فقط webhook إلى Jenkins تلقائي. هذا هو التوقيع المميز لـمسار بيروقراطي — احتفال عالٍ، إنتاجية منخفضة. من منظور CALMS (الدرس الثاني)، يحصل على درجة سيئة في Lean وSharing.

الخطوة الثالثة — تطبيق تفكير تدفق القيمة

رسم خريطة تدفق القيمة، المستعار من التصنيع الرشيق، يُقسّم كل نشاط إلى وقت ذي قيمة مضافة (الحاسوب يعمل فعليًا) مقابل وقت الانتظار (بشر أو طوابير أو سياسات). بالنسبة لـ ShopFast:

الوقت ذو القيمة المضافة: حوالي 22 دقيقة (بناء Jenkins) + حوالي ساعتين (اختبار QA الفعلي) + حوالي 5 دقائق (سكريبت النشر). المجموع: ~2.5 ساعة.
وقت الانتظار: ~17 يومًا في أسوأ الأحوال. كفاءة دورة العملية (الوقت ذو القيمة / إجمالي زمن الانتظار) هي تقريبًا 0.7% — منظمة ضعيفة الأداء وفق الكتاب المدرسي.

أبطال DORA النخبة يستهدفون كفاءة دورة العملية فوق 10%. فرق التقنية الكبرى كثيرًا ما تتجاوز 50%. الفجوة لا تكمن أبدًا في وقت بناء CI؛ بل دائمًا في طوابير تسليم المهام البشرية.

عند رسم خريطة أي مسار للمرة الأولى، اسأل: "ماذا سيحدث إذا أزلنا كل البوابات البشرية ما عدا مراجعة الأمان؟" الإجابة تُجبر الفريق على توضيح ما إذا كانت كل بوابة تُقلل المخاطر فعلًا أم مجرد عادة تنظيمية. ستجد أن معظم البوابات أُنشئت لإصلاح حادثة ماضية محددة ولم يُعد النظر فيها قط.

الخطوة الرابعة — تحديد نقاط إدخال الإخفاق

خريطة المسار الكاملة تُحدد أيضًا أين من المرجح أن تُفلت الإخفاقات إلى الإنتاج. خريطة ShopFast لها ثلاث مناطق عالية الخطورة:

لا اختبارات تكامل آلية — Jenkins يُشغّل اختبارات الوحدة فقط. تظهر أخطاء التكامل في QA، بعد أيام من كتابة الشيفرة. تكلفة إصلاح الخطأ الموجود في QA تبلغ 5-10 أضعاف تكلفة إصلاحه في مرحلة PR (مبدأ الإزاحة لليسار، الدرس الأول).
بيئة QA مشتركة واحدة — عندما تحتاج فرقتان إلى QA في وقت واحد، تنتظر إحداهما. "التنافس على البيئة" عنق زجاجة خفي لا يظهر في مخطط المسار الاسمي.
رجوع يدوي يستغرق 45 دقيقة — إذا تطلّب حادث إنتاجي الرجوع للخلف، فإن 45 دقيقة من MTTR مقيّدة قبل بدء أي شيء. هدف DORA للـ MTTR لدى أبطال النخبة أقل من ساعة واحدة إجمالًا؛ أما ShopFast فتقضي 45 دقيقة فقط في ميكانيكا الرجوع.

الخطوة الخامسة — رسم خريطة الحالة المستقبلية

كل تدقيق في المسار ينتج وثيقتين: خريطة الحالة الحالية (أعلاه) وخريطة الحالة المستقبلية مع مقترحات تحسين ملموسة. بالنسبة لـ ShopFast، هدف ستة أشهر واقعي:

خريطة الحالة المستقبلية لـ ShopFast — كل عنق زجاجة استُبدل ببوابة آلية؛ أهداف DORA موضحة في الأسفل.

الخطوة السادسة — كتابة تعريف المسار كشيفرة

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

# .github/workflows/delivery.yml — هيكل الحالة المستقبلية لـ ShopFast
name: Delivery Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint-and-unit:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - name: Run linter
        run: bundle exec rubocop --parallel
      - name: Run unit tests
        run: bundle exec rspec spec/unit --format progress

  integration:
    needs: lint-and-unit
    runs-on: ubuntu-24.04
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
    steps:
      - uses: actions/checkout@v4
      - name: Run integration tests
        run: bundle exec rspec spec/integration

  build-image:
    needs: integration
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/shopfast/api:${{ github.sha }}

  deploy-staging:
    needs: build-image
    runs-on: ubuntu-24.04
    environment: staging
    steps:
      - name: Deploy to staging via Helm
        run: |
          helm upgrade --install shopfast-api ./charts/api \
            --set image.tag=${{ github.sha }} \
            --namespace staging --wait --timeout 5m

  smoke-test-staging:
    needs: deploy-staging
    runs-on: ubuntu-24.04
    steps:
      - name: Run smoke tests against staging
        run: npx playwright test --grep @smoke --base-url https://staging.shopfast.io

  deploy-prod-canary:
    needs: smoke-test-staging
    runs-on: ubuntu-24.04
    environment: production
    steps:
      - name: Canary deploy 5%
        run: |
          helm upgrade --install shopfast-api ./charts/api \
            --set image.tag=${{ github.sha }} \
            --set canary.weight=5 \
            --namespace production --wait

لاحظ بوابة environment: production أعلاه. هذه البوابة البشرية الوحيدة التي تنتمي إلى مسار حديث — موافقة خفيفة وقابلة للتدقيق مسجّلة في GitHub، لا اجتماع لجنة. تُلبّي متطلبات تدقيق إدارة التغييرات دون إضافة أيام من الانتظار. لا تُزل جميع البوابات البشرية من مسار النشر في الإنتاج للصناعات المنظّمة — أزل غير الضرورية واحتفظ بـالمساءلة.

المخرج النهائي لرسم الخريطة: ما تُقدّمه

المخرج الاحترافي لخريطة المسار له خمسة أقسام. استخدم هذا كقالب لأي تدقيق:

مخطط الحالة الحالية — المراحل والفاعلون والأدوات وأزمنة الانتظار عند كل انتقال.
تحليل تدفق القيمة — إجمالي زمن الانتظار، الوقت ذو القيمة المضافة، كفاءة دورة العملية.
جرد عنق الزجاجة — قائمة مرتبة بالقيود (طبّق نظرية القيود: أصلح أكبر عنق زجاجة أولًا).
تحليل إفلات الإخفاق — أين يمكن لخطأ أن ينجو حتى الإنتاج؟ في أي مرحلة يكون اكتشافه أرخص؟
مقترح الحالة المستقبلية — أهداف DORA المستهدفة، وتغييرات الأتمتة، وهيكل المسار كشيفرة.

لقد أكملت الآن مرحلة الأساسيات الكاملة من هذه الدورة. الدروس من 2 إلى 50 تبني على كل ما تناولناه هنا: CALMS وDORA والاثنا عشر عاملاً ومشهد الأدوات — والأهم من ذلك كله — العادة التحليلية التي يُظهرها هذا المشروع. عند الشك، عد إلى خريطة المسار. إنها الأداة التشخيصية الأكثر أهمية في صندوق أدوات مهندس DevOps.