ليست كل التغييرات متساوية: التغييرات القياسية والعادية والطارئة

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

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

لماذا تفشل الموافقة الموحدة للجميع

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

النتيجة هي نظام يبطئ التغييرات الآمنة دون جعل التغييرات الخطرة أكثر أمانًا. الحل ليس إزالة الحوكمة. الحل هو جعل الحوكمة متناسبة مع المخاطر.

ثلاث فئات من التغييرات

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

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

flowchart TD A[طلب تغيير] --> B{هل هو طارئ؟} B -->|نعم| C[تغيير طارئ] C --> D[إجراء التغيير فورًا] D --> E[توثيق ومراجعة لاحقة] B -->|لا| F{هل الإجراء موثق ومثبت؟} F -->|نعم| G[تغيير قياسي] G --> H[موافقة تلقائية عبر pipeline] H --> I[نشر] F -->|لا| J[تغيير عادي] J --> K{تقييم مستوى المخاطرة} K -->|منخفضة| L[مراجعة الأقران] K -->|عالية| M[مراجعة CAB أو متعددة الأطراف] L --> N[موافقة ونشر] M --> N

التغييرات القياسية

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

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

التغييرات القياسية هي المكان الذي تتألق فيه الأتمتة. إذا كان الإجراء متوقعًا حقًا، فيجب ترميزه في pipeline CI/CD. يصبح pipeline نفسه آلية الموافقة: إذا اجتازت الفحوصات الآلية، يتم تنفيذ التغيير.

التغييرات العادية

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

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

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

التغييرات الطارئة

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

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

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

كيفية تصنيف التغييرات

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

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

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

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

دمج التصنيف في Pipeline

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

على سبيل المثال، يمكن لسير عمل GitHub Actions تلقائيًا وضع علامة على طلب السحب كـ standard عندما يمس فقط ملفات التوثيق أو التكوين، ثم تخطي خطوة الموافقة اليدوية:

name: Classify Change
on: pull_request

jobs:
  classify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v5
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          configuration-path: .github/labeler.yml

  deploy-standard:
    if: contains(github.event.pull_request.labels.*.name, 'standard')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy without manual approval
        run: echo "Deploying standard change..."

وملف .github/labeler.yml المصاحب يحدد المسارات التي يتم تعيينها إلى التصنيف standard:

standard:
  - changed-files:
      - any-glob-to-any-file: ['docs/**', 'config/**', '*.md']

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

الهدف ليس بناء بيروقراطية. الهدف هو جعل pipeline يعكس فهم الفريق للمخاطر. عندما يتعامل pipeline مع التصنيف تلقائيًا، يقضي الفريق وقتًا أقل في العمليات ووقتًا أكثر في العمل الفعلي.

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

قبل نشرك التالي، اطرح هذه الأسئلة:

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

الخلاصة

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