متى تظل الموافقة اليدوية مهمة في خط أنابيب النشر لديك

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

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

هذه هي اللحظة التي تصل فيها الأتمتة إلى حدودها.

ما لا تستطيع البوابات الآلية رؤيته

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

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

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

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

تغييرات كبيرة في كود التطبيق

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

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

يحتاج شخص يفهم السياق التجاري إلى مراجعة التغيير والقول: "هذا يتوافق مع ما خططنا له."

تغييرات قاعدة البيانات

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

يوضح مقتطف سير عمل GitHub Actions التالي كيف يمكنك طلب موافقة يدوية لتغييرات ترحيل قاعدة البيانات:

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    # طلب موافقة يدوية للتغييرات ضمن مجلد migrations/
    if: contains(github.event.head_commit.modified, 'migrations/')
    steps:
      - uses: actions/checkout@v4
      - name: Run database migration
        run: |
          echo "Applying migration..."
          # نص الترحيل هنا

في هذا المثال، يؤدي إعداد environment: production إلى تشغيل خطوة موافقة يدوية في GitHub Actions. يتوقف خط الأنابيب حتى يوافق مراجع معين على النشر، مما يضمن تقييم بشري للترحيل قبل وصوله إلى الإنتاج.

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

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

تغييرات البنية التحتية

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

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

تحتاج فرق البنية التحتية إلى مراجعة التغيير، والتحقق من التبعيات، والتأكيد على أنه آمن للتطبيق.

أي تغيير في الإنتاج

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

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

كيفية تحديد ما يحتاج إلى موافقة

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

النمط الشائع هو تصنيف التغييرات حسب مستوى المخاطرة:

يلخص مخطط التدفق التالي عملية اتخاذ القرار:

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

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

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

قائمة مراجعة عملية لإعداد الموافقة اليدوية

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

الغرض الحقيقي من الموافقة اليدوية

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

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