الموافقة المبنية على المخاطر: متى يحتاج التغيير حقًا إلى موافقة؟

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

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

مشكلة الموافقة على كل تغيير

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

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

مبدأ الموافقة المبنية على المخاطر

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

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

تحديد عتبات الموافقة

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

تشمل المعايير المفيدة:

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

يوضح مقتطف GitLab CI التالي كيف يمكن للـ pipeline اكتشاف المخاطر تلقائيًا وطلب موافقة يدوية بشكل مشروط:

stages:
  - test
  - deploy
  - approval
  - production

risk-check:
  stage: test
  script:
    - if git diff --name-only $CI_MERGE_REQUEST_DIFF_BASE_SHA...$CI_SHA | grep -E "^(migrations/|payment/)"; then
    -   echo "HIGH_RISK=true" >> risk.env
    - else
    -   echo "HIGH_RISK=false" >> risk.env
    - fi
  artifacts:
    reports:
      dotenv: risk.env

approval-job:
  stage: approval
  needs: [risk-check]
  rules:
    - if: $HIGH_RISK == "true"
      when: manual
      allow_failure: false
  script:
    - echo "Change requires manual approval before production deployment"

deploy-production:
  stage: production
  needs: [approval-job]
  script:
    - echo "Deploying to production"
flowchart TD A[Change Submitted] --> B{Risk Assessment} B -->|Low Risk| C[Standard Change] C --> D[No Formal Approval] D --> E[Deploy] B -->|Medium Risk| F[Normal Change] F --> G[Peer Review] G --> H{Approved?} H -->|Yes| E H -->|No| I[Revise & Resubmit] I --> A B -->|High Risk| J[Emergency Change] J --> K[Fast Path Approval] K --> L{Approved?} L -->|Yes| E L -->|No| I
  • هل يمس التغيير بيانات المستخدم؟
  • هل يعدل مخطط قاعدة بيانات أو مسار ترحيل؟
  • هل يمكن أن يؤثر على توفر الخدمة؟
  • هل يتعلق بالدفع، المصادقة، الأمان، أو تدفقات حرجة أخرى؟
  • هل يغير بنية تحتية تعتمد عليها أنظمة عديدة؟
  • هل يؤثر على مكون لديه تاريخ من السلوك الهش؟

أفضل العتبات يمكن اكتشافها تلقائيًا. يمكن للـ pipeline أن يرى أن طلب السحب (pull request) يحتوي على ملفات ترحيل قاعدة بيانات، تغييرات Terraform، تكوين توقيع تطبيق الجوال، أو تغييرات في سياسات الأسرار الخاصة بالإنتاج. يمكنه بعد ذلك توجيه النشر عبر مسار الموافقة الصحيح دون الاعتماد على التخمين.

ثلاث فئات عملية للتغييرات

يمكن للعديد من الفرق البدء بثلاث فئات.

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

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

التغييرات الطارئة (Emergency changes) تُجرى لحل حادث أو منع ضرر فوري. تحتاج إلى مسار سريع بأقل قدر من الاحتكاك، متبوعًا بتوثيق بعد ذلك. الهدف ليس إبطاء التعافي. الهدف هو التأكد من أن المؤسسة تعرف ما تم تغييره، ولماذا تم تغييره، وما يجب تحسينه بعد الحادث.

ما يغيره هذا في سلوك الفريق

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

هذا يدعم ثقافة الملكية بدلاً من ثقافة التسليم. لا يمكن للمطورين الاختباء خلف الموافقة. لا يتم دفن المراجعين تحت الطلبات التافهة. تنفق المؤسسة انتباهها حيث يهم الانتباه حقًا.

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

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

حوكمة تساعد في تسريع التسليم

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

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

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