اختبار تغييرات البنية التحتية دون تعطيل الإنتاج
يقوم مطور بتغيير بسيط في قاعدة جدار الحماية. "مجرد تعديل بسيط في الإعدادات"، كما يعتقد. بعد دقائق، لا يمكن لأحد الوصول إلى التطبيق. يبدأ المستخدمون في الإبلاغ عن أخطاء. يندفع الفريق لمعرفة ما حدث.
هذا السيناريو يتكرر أكثر مما ترغب معظم الفرق في الاعتراف به. تحمل تغييرات البنية التحتية مخاطر خفية. خطأ في إعداد قاعدة البيانات يمكن أن يفسد البيانات. تغيير في سياسة الشبكة يمكن أن يعزل خدمات بأكملها. وعلى عكس كود التطبيق، غالبًا ما تؤثر مشاكل البنية التحتية على كل شيء في وقت واحد.
السؤال الذي يحتاج كل فريق إلى الإجابة عليه: أين تختبر تغييرات البنية التحتية قبل أن تصل إلى الإنتاج؟
مشكلة البيئة للبنية التحتية
عندما كانت الفرق تدير الخوادم يدويًا، كانت الإجابة غالبًا غامضة. كان لدى البعض خادم اختبار. وآخرون كانوا يغيرون الإنتاج مباشرة لأن "هذا مجرد تغيير بسيط في الإعدادات". نادرًا ما تبقى التغييرات الصغيرة في البنية التحتية صغيرة التأثير.
التطبيقات لديها إجابة طبيعية لهذه المشكلة: بيئات التدريج (Staging). تختبر الميزة الجديدة في بيئة التدريج، وتتحقق من عملها، ثم تنشرها إلى الإنتاج. تحتاج البنية التحتية إلى نفس النهج، ولكن مع اختلاف.
لا يمكنك دائمًا نسخ البنية التحتية تمامًا. إنشاء خوادم وشبكات وقواعد بيانات مكررة يكلف أموالًا حقيقية. بيئة تدريج تعكس إعداد الإنتاج مع عشرات الخوادم وموازنات الأحمال ومجموعات قواعد البيانات يمكن أن تضاعف فاتورة البنية التحتية. التحدي هو إيجاد التوازن بين الاختبار الشامل وإدارة التكاليف.
المبدأ الأساسي: اعزل قبل أن تختبر
يجب أن يمر كل تغيير في البنية التحتية عبر بيئة معزولة قبل لمس الإنتاج. العزل هنا صارم: يجب ألا تشارك بيئة التدريج أي موارد مع الإنتاج. لا قاعدة بيانات مشتركة. لا شبكة مشتركة. لا وصول إلى بيانات المستخدم الحقيقية.
إذا كانت بيئة التدريج والإنتاج لا تزالان تشاركان خادمًا أو تقعان في نفس VPC، فهذا ليس عزلًا. خطأ في التدريج يمكن أن يتسرب إلى الإنتاج. قاعدة بيانات تم تكوينها بشكل خاطئ في التدريج يمكنها الكتابة فوق بيانات الإنتاج. قواعد الشبكة المشتركة يمكن أن تعرض خدمات التدريج لحركة مرور الإنتاج.
العزل وحده ليس كافيًا. يجب أن تعكس بيئة التدريج تكوين الإنتاج بأكبر قدر ممكن. إذا كان الإنتاج يدير ثلاثة خوادم خلف موازن أحمال، يجب أن يكون للتدريج نفس الإعداد. إذا كان الإنتاج يستخدم إصدارًا محددًا من قاعدة البيانات، يجب أن يتطابق التدريج معه.
الهدف ليس جعل التدريج بقوة الإنتاج. الهدف هو اكتشاف المشاكل التي تظهر فقط مع تكوينات محددة. استعلام قاعدة بيانات يعمل بشكل جيد على مثيل تدريج صغير قد ينتهي مهلة التنفيذ على الإنتاج تحت الحمل. قاعدة شبكة تمر في إعداد مبسط قد تمنع حركة المرور المشروعة في الهيكل الحقيقي.
طبقات البيئة العملية
ينتهي الأمر بمعظم الفرق إلى طبقات متعددة من بيئات البنية التحتية. كل طبقة تخدم غرضًا مختلفًا ولها مقايضات مختلفة بين التكلفة والدقة.
بيئة التطوير (Development) هي للمطورين الذين يختبرون تغييرات صغيرة. يمكنها استخدام موارد ضئيلة وتكوينات مبسطة. خادم صغير واحد بدلاً من مجموعة. قاعدة بيانات محلية بدلاً من إعداد مكرر. الشرط الأساسي هو العزل عن التدريج والإنتاج. يجب ألا تلمس بيئات التطوير موارد الإنتاج أبدًا، حتى عن طريق الخطأ.
بيئة التدريج (Staging) هي للاختبار المتكامل. يجب أن تعكس تكوين الإنتاج بأكبر قدر ممكن، حتى لو كان النطاق أصغر. نفس إصدار نظام التشغيل. نفس إصدارات وقت التشغيل. نفس هيكل الشبكة. الفرق عادة في السعة: خوادم أقل، مثيلات أصغر، تخزين أقل. لكن أنماط التكوين يجب أن تتطابق.
بيئة الإنتاج (Production) تدير الخدمة الفعلية. التغييرات تصل إلى هنا فقط بعد اجتياز التطوير والتدريج بنجاح.
يوضح الرسم البياني أدناه كيفية تدفق التغييرات عبر كل طبقة بيئة، مع بوابات تحقق تمنع التغييرات غير الموثقة من الوصول إلى الإنتاج.
فخ التكوين
تفصيل واحد يتعثر فيه العديد من الفرق: التكوين الخاص بالبيئة. كلمات مرور قاعدة البيانات، ومفاتيح API، وعناوين الخوادم تختلف بوضوح بين البيئات. لكن يجب أن يظل التكوين الآخر متسقًا.
يجب أن تكون إصدارات نظام التشغيل متماثلة عبر البيئات. يجب أن تتطابق إصدارات وقت التشغيل. يجب أن تكون قواعد التسجيل متطابقة. عندما تختلف هذه العناصر بين البيئات، فإنك تخلق فجوة يمكن أن تختبئ فيها المشاكل. خطأ يظهر فقط على إصدار معين من نظام التشغيل قد لا يظهر أبدًا في التدريج إذا كان التدريج يستخدم إصدارًا مختلفًا.
الحل هو فصل التكوين حسب النوع. القيم الخاصة بالبيئة تذهب إلى ملفات منفصلة لكل بيئة. التكوين المشترك يُكتب مرة واحدة ويُطبق في كل مكان. عند ترقية إصدار نظام التشغيل، تقوم بتغييره في مكان واحد، وليس في ثلاثة ملفات مختلفة.
كيف يدير CI/CD بيئات البنية التحتية
يتبع خط أنابيب تغييرات البنية التحتية تسلسلًا واضحًا:
- مراجعة التغيير من خلال مراجعة الكود أو أدوات التخطيط
- تطبيق التغيير على التدريج تلقائيًا
- تشغيل الاختبارات للتحقق من إنشاء الموارد بشكل صحيح
- التحقق من أن الموارد الحالية لم تتأثر
- تطبيق نفس التغيير على الإنتاج
كل خطوة تتم من خلال نفس أدوات البنية التحتية ككود. نفس خطة Terraform، نفس قائمة تشغيل Ansible، نفس برنامج Pulumi يتم تشغيله على التدريج أولاً. إذا نجح، يتم تشغيله على الإنتاج.
تضمن هذه العملية أن كل تغيير في البنية التحتية يمر عبر بيئة تعكس الإنتاج قبل أن يؤثر على المستخدمين الحقيقيين. يفرض خط الأنابيب الانضباط الذي غالبًا ما تتجاهله العمليات اليدوية.
قائمة التحقق العملية لبيئات البنية التحتية
- التدريج في VPC أو حساب منفصل عن الإنتاج
- التدريج ليس لديه وصول إلى قواعد بيانات أو تخزين الإنتاج
- التدريج يستخدم نفس إصدار نظام التشغيل وإصدارات وقت التشغيل مثل الإنتاج
- التكوين المشترك يُعرف مرة واحدة ويُشارك عبر البيئات
- القيم الخاصة بالبيئة معزولة في ملفات منفصلة
- خط الأنابيب يطبق التغييرات على التدريج أولاً، ثم الإنتاج
- يتم تشغيل الاختبارات بعد تطبيق التدريج للتحقق من الصحة
ما التالي
اختبار تغييرات البنية التحتية في بيئات معزولة يكتشف معظم المشاكل قبل وصولها إلى الإنتاج. لكنه لا يكتشف كل شيء. التغيير الذي يعمل بشكل مثالي في التدريج قد لا يزال يسبب مشاكل عند تطبيقه على الإنتاج على نطاق واسع أو تحت أنماط حركة مرور حقيقية.
هنا يأتي دور السياسات والحوكمة. الخطوة التالية هي تحديد قواعد حول التغييرات المسموح بها، ومن يمكنه الموافقة عليها، وما هي الشروط التي يجب استيفاؤها قبل النشر في الإنتاج. لكن هذا موضوع لمقال آخر.
في الوقت الحالي، الخلاصة الملموسة هي: إذا كانت تغييرات البنية التحتية الخاصة بك تذهب مباشرة إلى الإنتاج دون المرور عبر بيئة تدريج معزولة، فأنت على بُعد تعديل بسيط في الإعدادات من انقطاع في الإنتاج. قم بإعداد البيئات أولاً. دع خط الأنابيب يفرض الانضباط. سيشكرك مستخدموك.