لماذا يجب إدارة الحالة والبيئة قبل أن تتعطل بنيتك التحتية

تخيل أنك وأحد زملائك تديران نفس الخادم. أنت تقوم بتحديث إعدادات جدار الحماية لفتح المنفذ 443. زميلك، دون علمه، يغير نفس الإعدادات لفتح المنفذ 80 بدلاً من ذلك. كلاكما ينفذ تغييراته في غضون دقائق من بعضكما البعض. الآن الخادم لديه قواعد متضاربة. أي تغيير هو الساري؟ لا أحد يعرف.

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

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

مشكلة عدم وضوح البيئة

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

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

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

لماذا تخفي الإدارة اليدوية هذه المشكلات

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

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

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

المفاهيم الأساسية التي تحتاج إلى فهمها

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

البيئة (Environment) هي السياق الذي يعمل فيه تطبيقك. على الأقل، تحتاج معظم الفرق إلى ثلاث بيئات:

• التطوير (Development): حيث تجرب وتكسر الأشياء. يجب أن تكون هذه البيئة رخيصة وسريعة إعادة الإنشاء ومعزولة عن كل شيء آخر.
• الاختبار (Staging): حيث تتحقق من صحة التغييرات قبل الإنتاج. يجب أن تعكس بيئة الإنتاج بأكبر قدر ممكن دون نفس المخاطر.
• الإنتاج (Production): حيث يتفاعل المستخدمون الحقيقيون مع تطبيقك. هذه البيئة لديها أعلى متطلبات الاستقرار.

ماذا يحدث عندما تتجاهل إدارة الحالة والبيئة

الفرق التي تتخطى هذا الأساس تواجه أنماطاً متوقعة من الألم:

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

نهج عملي للبدء

لا تحتاج إلى فريق منصة معقد لحل هذه المشكلات. ابدأ بالأساسيات:

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

2. استخدم تخزين الحالة عن بُعد مع القفل (Remote State with Locking). خزّن ملفات الحالة الخاصة بك في موقع مشترك مثل S3 أو GCS أو Azure Blob Storage. فعّل قفل الحالة بحيث لا يمكن لخطي أنابيب تعديل نفس الحالة في وقت واحد.

3. سمِّ مواردك باستمرار. قم بتضمين اسم البيئة في كل اسم مورد أو علامة (Tag). هذا يمنع الارتباك عند النظر إلى قائمة الخوادم.

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

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

قائمة مراجعة سريعة لتقييم إعدادك الحالي

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

إذا أجبت بـ "لا" على أي من هذه الأسئلة، فلديك عمل يجب القيام به.

الخلاصة

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

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