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

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

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

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

البنية التحتية ككود هي الأساس، وليس الحل

البنية التحتية ككود (IaC) تعني أنك تكتب تكوين البنية التحتية في ملفات، وتخزنها في مستودع، وتطبقها من خلال الأتمتة. أدوات مثل Terraform و Pulumi و AWS CDK تجعل هذا ممكنًا. لكن مجرد وجود ملفات IaC في مستودع ليس كافيًا. الانضباط يأتي من كيفية إدارتك للتغييرات على تلك الملفات.

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

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

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

يوضح المخطط الانسيابي التالي التسلسل الموصى به ونقاط القرار:

flowchart TD A[ابدأ بتغيير الكود] --> B[تشغيل الخطة] B --> C{مراجعة الخطة} C -- موافقة --> D[اختبار في بيئة غير إنتاجية] C -- رفض --> A D --> E{الاختبارات ناجحة؟} E -- نعم --> F[التطبيق عبر خط الأنابيب] E -- لا --> A F --> G[التحقق بعد التطبيق] G --> H{التحقق ناجح؟} H -- نعم --> I[اكتمل التغيير] H -- لا --> J[تنفيذ خطة التراجع] J --> A

ابدأ بتغيير الكود

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

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

قم بتشغيل خطة قبل التطبيق

يمكن لأدوات IaC أن تُظهر لك ما الذي سيتغير دون إجراء التغيير فعليًا. تسمي Terraform هذا "خطة". تسميه Pulumi "معاينة". المفهوم هو نفسه: تقارن الأداة تكوينك بالحالة الحالية وتدرج كل مورد سيتم إنشاؤه أو تعديله أو تدميره.

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

على سبيل المثال، قد تبدو خطة Terraform لتغيير مجموعة أمان كما يلي:

Terraform will perform the following actions:

  # aws_security_group_rule.app_ingress will be updated in-place
  ~ resource "aws_security_group_rule" "app_ingress" {
        id                     = "sgrule-1234567890"
      ~ from_port              = 8080 -> 8443
        protocol               = "tcp"
      ~ to_port                = 8080 -> 8443
        type                   = "ingress"
        # (5 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

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

اختبر في بيئة غير إنتاجية أولاً

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

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

طبق عبر خط أنابيب، وليس من جهاز كمبيوتر محمول

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

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

امتلك خطة تراجع

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

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

تحقق بعد التطبيق

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

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

قائمة تحقق عملية لتغييرات البنية التحتية

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

هذه القائمة ليست بيروقراطية. إنها حماية ضد نوع الانقطاع الذي يبدأ بنقرة واحدة في وحدة التحكم السحابية وينتهي بفريق يتسابق لفهم ما حدث.

الخلاصة

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

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