الموافقة على النشر لا تعني التباطؤ

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

بعض الفرق تجيب بإدراج كل شخص قد يتأثر. المدير يجب أن يوقع. المهندس الرئيسي يحتاج إلى النظر فيه. رئيس فريق ضمان الجودة يجب أن يؤكد. مسؤول الأمن يريد مراجعة. وقبل أن تدرك ذلك، لديك خمسة أشخاص يحتاجون إلى الموافقة على نشر واحد، وكل واحد منهم يستغرق من ساعة إلى يومين للرد.

النتيجة متوقعة. الفريق ينتظر. النشر يتعطل. وعندما يحدث خطأ في النهاية، كل تلك الموافقات لم تمنع المشكلة على أي حال. العملية أضافت تأخيراً دون إضافة أمان.

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

الحوكمة القائمة على المخاطر: مطابقة الفحوصات مع التأثير

النهج الأفضل هو مطابقة مستوى التدقيق مع المخاطر الفعلية للتغيير. هذا يسمى الحوكمة القائمة على المخاطر، لكن الفكرة أبسط مما يوحي الاسم.

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

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

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

فيما يلي مقتطف من YAML pipeline يطبق هذه الفكرة بتخطي الموافقة اليدوية للتغييرات منخفضة المخاطر وطلبها للتغييرات عالية المخاطر:

# .github/workflows/deploy.yml (excerpt)
name: Deploy
on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Determine risk level
        id: risk
        run: |
          changed=$(git diff --name-only ${{ github.event.before }} ${{ github.sha }})
          if echo "$changed" | grep -qE "^(db/|src/payments/)"; then
            echo "level=high" >> $GITHUB_OUTPUT
          else
            echo "level=low" >> $GITHUB_OUTPUT
          fi
      - name: Manual approval for high-risk changes
        if: steps.risk.outputs.level == 'high'
        uses: trstringer/manual-approval@v1
        with:
          secret: ${{ secrets.APPROVAL_TOKEN }}
          approvers: team-leads
      - name: Deploy
        run: ./deploy.sh

نفس الفريق، نفس خط أنابيب النشر، ولكن مستويات مختلفة من التدقيق. هذه هي الحوكمة القائمة على المخاطر في الممارسة.

كيفية تحديد مستوى المخاطرة

تحتاج الفرق إلى طريقة عملية لتقرير ما إذا كان التغيير منخفض المخاطر أم عالي المخاطر. إليك أربعة عوامل مساعدة:

فيما يلي مخطط انسيابي يربط تقييم المخاطر بمسار النشر المناسب:

ما مدى اتساع التأثير؟ هل يؤثر التغيير على ميزة صغيرة واحدة أم على النظام بأكمله؟ تغيير في صفحة إدارية نادراً ما تستخدم له تأثير أقل من تغيير في تدفق تسجيل الدخول.

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

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

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

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

معايير الجاهزية، وليس قوائم الموافقة

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

لتغيير منخفض المخاطر، قد تكون معايير الجاهزية بسيطة: جميع الاختبارات الآلية تمر، ولا توجد أخطاء جديدة ظهرت في بيئة الاختبار.

لتغيير عالي المخاطر، قد تشمل معايير الجاهزية: اكتمال اختبار التحميل، التحقق من سكربت الترحيل من قبل شخص ثانٍ، توثيق واختبار خطة الاسترجاع، وتأكيد عمل لوحات المراقبة.

المعايير موضوعية. لا تعتمد على من لديه الصوت الأعلى أو الرتبة الأعلى. تعتمد على ما يحتاجه التغيير ليكون آمناً.

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

قائمة مراجعة عملية لفريقك

إذا كنت تريد البدء في تطبيق هذا اليوم، إليك إطار عمل بسيط:

• لكل تغيير، اسأل: ما هو أسوأ ما يمكن أن يحدث؟
• إذا كانت أسوأ حالة طفيفة، انشر دون انتظار.
• إذا كانت أسوأ حالة خطيرة، حدد الفحوصات المطلوبة قبل النشر.
• اجعل تلك الفحوصات جزءاً من العملية، وليس خطوة موافقة منفصلة.
• راجع المعايير بانتظام. ما كان يبدو محفوفاً بالمخاطر قبل ستة أشهر قد يكون روتينياً الآن.

الخلاصة

السرعة والأمان ليسا متناقضين. أسرع الفرق ليست تلك التي لديها أقل عدد من الموافقات. إنها تلك التي تطابق عملياتها مع المخاطر الفعلية لكل تغيير. عندما تتوقف عن السؤال عن من يحتاج إلى الموافقة وتبدأ في السؤال عن ما يحتاجه التغيير ليكون آمناً، فإنك تزيل الاحتكاك غير الضروري دون إزالة الحماية الضرورية. فريقك يتحرك بشكل أسرع، ويظل إنتاجك مستقراً.