ما الذي يجب أتمتته أولًا عندما تبدأ عمليات النشر بالتعطل

عملية النشر التي كانت تعمل مع 5 مهندسين تنهار مع 15

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

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

السؤال الذي نتلقاه ليس «هل يجب أن نؤتمت؟» فالجميع متفق على ذلك بالفعل. السؤال هو ما الذي يجب أتمتته أولًا، لأن الفرق التي تحاول إصلاح كل شيء في سبرنت واحد عادة ما تتعثر ولا تُنجز شيئًا. إليك الترتيب الذي ينجح فعليًا، بناءً على النمط الذي نراه لدى الفرق في مرحلة النمو.

أصلح مسار النشر قبل أن تلمس البنية التحتية

الدافع الغريزي عندما تبدو الأمور هشة هو التوجه أولًا نحو البنية التحتية ككود (infrastructure-as-code) — أتمتة كل شيء عبر Terraform والسيطرة على الخوادم. هذه هي الخطوة الأولى الخاطئة. إذا كانت عملية النشر لديك لا تزال «الدخول عبر SSH وتشغيل سكربت»، فإن تحويل الجهاز الذي يعمل عليه هذا السكربت إلى Terraform لا يُصلح سبب الفشل الحقيقي: إنسان يقوم بمهمة متكررة يدويًا، تحت ضغط الوقت، ومن دون خطة للتراجع.

يجب أن يذهب أول دولار للأتمتة إلى CI/CD: خط أنابيب (pipeline) يعمل مع كل عملية push، ويشغّل الاختبارات نفسها في كل مرة، وينشر بالطريقة نفسها في كل مرة. وعمليًا، هذا يعني:

• كل عملية دمج (merge) إلى الفرع الرئيسي (main) تُطلق بناءً (build) ومجموعة اختبارات — من دون استثناءات، ومن دون عمليات push يدوية «لهذه المرة فقط».
• خطوة النشر هي مهمة ضمن خط الأنابيب، وليست عملية تُنفَّذ من طرفية (terminal) شخص ما. تتولى GitHub Actions أو GitLab CI أو CircleCI هذا الأمر جميعها؛ والأداة أقل أهمية من الانضباط في استخدامها في كل مرة.
• التراجع (rollback) هو زر، وليس شخصًا يحاول تذكّر آخر commit سليم في الساعة 11 مساءً.

الفرق التي تبدأ بهذه الخطوة عادة ما ترى انخفاضًا ملحوظًا في الحوادث المرتبطة بالنشر خلال الشهر الأول، من دون لمس ملف Terraform واحد. السبب: معظم حوادث «البنية التحتية» في هذه المرحلة ليست مشكلات بنية تحتية أصلًا. إنها مشكلات في العملية ترتدي زي البنية التحتية — قيمة إعداد (config) موجودة فقط في ذهن مهندس واحد، خطوة ترحيل (migration) نسي أحدهم تنفيذها، أو عملية نشر حدثت بترتيب خاطئ بالنسبة لعملية نشر أخرى.

ثم اجعل البيئات قابلة لإعادة الإنتاج

بمجرد أتمتة عمليات النشر، يظهر نمط الفشل التالي: «تعمل في staging لكن ليس في الإنتاج»، أو الأسوأ، «لا نتذكر كيف تم إعداد staging». هنا تكتسب البنية التحتية ككود (infrastructure-as-code) مكانتها — ليس كإصلاح أول، بل كإصلاح ثانٍ.

وحدات Terraform أو OpenTofu التي تصف بيئة AWS أو GCP أو Azure لديك ككود خاضع للتحكم بالإصدارات تحل مشكلة محددة: انحراف البيئة (environment drift). من دون IaC، تتراكم في كل بيئة اختلافات صغيرة وغير موثقة — حجم instance تم رفعه يدويًا هنا، قاعدة في security group أُضيفت أثناء حادثة هناك — إلى أن تتوقف staging عن كونها مؤشرًا موثوقًا لسلوك الإنتاج.

الهدف العملي ليس «أتمتة 100% من البنية التحتية» في اليوم الأول. بل: هل يمكنك تدمير بيئة staging وإعادة بنائها من الكود في أقل من ساعة، من دون الحاجة إلى معرفة ضمنية يحتفظ بها فرد بعينه؟ إذا كانت الإجابة لا، فهذا هو الشيء التالي الذي يجب إصلاحه — قبل Kubernetes، وقبل تعدد المناطق (multi-region)، وقبل أي شيء أكثر طموحًا.

بيئات المعاينة تُغلق الحلقة التي يفتحها CI/CD

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

من دون بيئات المعاينة، تتم الإجابة عن سؤال «هل يعمل هذا فعليًا» داخل staging المشتركة، ما يعني أن تغييرات كل مهندس تتصادم مع تغييرات البقية. يتحول ضمان الجودة (QA) إلى طابور انتظار. تُكتشف الأخطاء متأخرًا، بعد تراكم عدة تغييرات فوق بعضها، ما يجعل عزلها مكلفًا. بيئات المعاينة — التي تُنشأ لكل طلب سحب وتُحذف عند الدمج — تعيد ذلك الطابور إلى اختبار متوازٍ ومستقل. الفرق التي تضيف هذه الخطوة بعد إصلاح خط أنابيب النشر تجد عادة أن الوقت بين المراجعة والدمج يتحسن، لأن المراجعين يمكنهم النقر على رابط ورؤية التغيير الفعلي قيد التشغيل بدلًا من قراءة diff والوثوق به.

ما يجب أتمتته أخيرًا، لا أولًا

التسليم التدريجي (progressive delivery) — إصدارات canary، وأعلام الميزات (feature flags)، والتراجع التلقائي عند ارتفاع معدل الأخطاء — أمر حقيقي وقيّم، لكنه استثمار لمرحلة لاحقة. إنه يحل مشكلة «كيف ننشر بأمان إلى حركة مرور الإنتاج»، وهذه لا تهم إلا بعد أن يصبح النشر إلى الإنتاج نفسه موثوقًا ومملًا بالفعل. الفرق التي تبني بنية canary قبل أن يكون لديها CI/CD يعمل، تُؤتمت المخاطرة الخاطئة؛ فمنطق توجيه حركة المرور لا يفيد إذا كان النشر الأساسي لا يزال يعتمد على شخص يُشغّل الأوامر الصحيحة بالترتيب الصحيح.

يقع Kubernetes في الفئة اللاحقة نفسها بالنسبة لمعظم الفرق النامية. إنه يحل مشكلات حقيقية — التوسع التلقائي (autoscaling)، وعزل الموارد، والخدمات ذاتية الإصلاح — لكنه يضيف مساحة تشغيلية حقيقية: ملفات manifests، وHelm charts، وترقيات الكلاستر (cluster)، وRBAC. الفرق التي يقل عدد مهندسيها عن نحو 20 وتُشغّل عددًا محدودًا من الخدمات عادة ما تكون خدمتها أفضل مع منصة أبسط (ECS، Cloud Run، أو منصة PaaS مُدارة) مع CI/CD قوي أمامها. انتقل إلى Kubernetes عندما يكون لديك ما يكفي من الخدمات ليصبح تحدي orchestration حقيقيًا، لا لأنه الخطوة التالية المتوقعة.

تسلسل واقعي، وتكلفته

بالنسبة لفريق من 15 إلى 25 مهندسًا قادم من نشر يدوي أو شبه يدوي، عادة ما ينجح تسلسل كهذا: خط أنابيب CI/CD مع اختبارات آلية وتراجع بنقرة واحدة أولًا (عادة 2 إلى 4 أسابيع)، ثم البنية التحتية ككود للبيئات الأساسية ثانيًا (3 إلى 5 أسابيع إضافية، بحسب مقدار الانحراف المتراكم بالفعل)، ثم تُضاف بيئات المعاينة والمراقبة/التنبيهات فوق ذلك. يبدأ إعداد CI/CD وحده عادة من $8,000؛ ويبدأ التسلسل الكامل — CI/CD إضافة إلى البنية التحتية ككود إضافة إلى بيئات المعاينة — عادة من $25,000+ بحسب عدد الخدمات والبيئات ضمن النطاق — وهو طرح تدريجي يحدد فريق السحابة وDevOps لدينا نطاقه مرحلة تلو أخرى، بدلًا من إعادة بناء منصة مفتوحة النهاية دفعة واحدة.

الخطأ الذي يجب تجنبه هو التعامل مع هذا كمشروع بنية تحتية ضخم واحد بتاريخ إطلاق واحد. يجب أن تُطلق كل مرحلة بشكل مستقل وأن تبدأ في تحقيق عائد فوري — فخط أنابيب CI/CD العامل له قيمة بحد ذاته، حتى قبل أن يكون Terraform موجودًا لدعمه.

خلاصة القول

عندما تبدأ عمليات النشر اليدوية بالانهيار، الحل ليس «الحصول على المزيد من أدوات DevOps». الحل هو الترتيب: خط الأنابيب أولًا، ثم البنية التحتية القابلة لإعادة الإنتاج ثانيًا، ثم بيئات المعاينة ثالثًا، ولا يأتي التسليم التدريجي والتنسيق (orchestration) إلا بعد أن تصبح الأساسيات مملة. الفرق التي تؤتمت بهذا الترتيب تُصلح أسوأ حوادثها في الشهر الأول. أما الفرق التي تبدأ بأكثر الأدوات تطورًا في القائمة، فعادة ما تقضي ربع سنة في بناء بنية تحتية لعملية نشر لا تزال يدوية في جوهرها.