تغييرات البنية التحتية تحتاج مراجعة كود مثل تغييرات كود التطبيق تمامًا
لديك خادم يعمل في بيئة الإنتاج. أحد أعضاء فريقك يحتاج إلى فتح منفذ جديد لأداة مراقبة. يقوم بتسجيل الدخول إلى وحدة التحكم السحابية، ويجد مجموعة الأمان، ويضيف القاعدة، ويحفظ. لا أحد آخر يعلم بهذا التغيير. بعد ثلاثة أيام، يقوم فريق الأمان بتدقيق ويكتشف منفذًا مفتوحًا لا ينبغي أن يكون موجودًا. لا أحد يتذكر من فتحه أو لماذا.
هذا السيناريو يحدث في الفرق التي تتعامل مع تغييرات البنية التحتية بشكل مختلف عن تغييرات كود التطبيق. نفس الفريق الذي يطلب طلبات سحب (Pull Requests) ومراجعات الأقران وموافقات لإصلاح خطأ في سطر واحد في تطبيقهم، قد يسمح لشخص ما بالاتصال عبر SSH بخادم وتغيير ملفات الإعدادات مباشرة. هذا التناقض يخلق مخاطر وارتباكًا وجهدًا غير ضروري لإخماد الحرائق.
لماذا تستحق تغييرات البنية التحتية نفس الدقة
عندما تكتب البنية التحتية ككود (Infrastructure as Code)، فإنك تخزن إعدادات الخادم وقواعد الشبكة وإعدادات قاعدة البيانات وتعريفات النشر في Git. هذه الملفات تصف بالضبط كيف يجب أن تبدو البنية التحتية الخاصة بك. التغيير في هذه الملفات يمكن أن يكون له عواقب خطيرة تمامًا مثل التغيير في كود التطبيق.
تأمل ما يحدث عندما يقوم شخص ما بتعديل قاعدة جدار حماية. منفذ واحد تم تكوينه بشكل خاطئ يمكن أن يعرض بيانات العملاء للإنترنت. حجم مثيل قاعدة بيانات خاطئ يمكن أن يسبب تدهورًا في الأداء أو زيادات غير متوقعة في التكاليف. إعداد موازن تحميل غير صحيح يمكن أن يعطل تطبيقك بالكامل. هذه ليست مخاطر افتراضية. إنها تحدث بانتظام في الفرق التي تتخطى عمليات المراجعة لتغييرات البنية التحتية.
المشكلة ليست في أن الناس يخطئون. الجميع يخطئ. المشكلة هي أنه عندما تحدث تغييرات البنية التحتية دون مراجعة، فإن الأخطاء تمر دون أن يلاحظها أحد حتى يحدث عطل. وعندما يحدث عطل، لا يوجد سجل لما تغير، أو من غيره، أو لماذا.
كيف تعمل طلبات السحب (Pull Requests) للبنية التحتية
إذا كانت البنية التحتية الخاصة بك محددة ككود في Git، فإن عملية المراجعة تعمل تمامًا كما هو الحال مع كود التطبيق. يقوم شخص ما بإنشاء فرع (Branch)، ويجري تغييراته على ملفات البنية التحتية، ويفتح طلب سحب (Pull Request). يقوم أعضاء الفريق الآخرون بمراجعة التغييرات، وترك تعليقات، وطلب تحسينات، أو الموافقة على التغيير. بمجرد الموافقة، يتم دمج التغيير في الفرع الرئيسي (Main Branch)، ويقوم خط الأنابيب (Pipeline) بتطبيقه.
هذه العملية ليست جديدة أو معقدة. إنها نفس سير العمل الذي تستخدمه فرق التطوير لسنوات. الاختلاف الوحيد هو ما يتم مراجعته. بدلاً من مراجعة منطق التطبيق، أنت تراجع تعريفات الإعدادات.
ما الذي يجب التحقق منه أثناء مراجعة البنية التحتية
عند مراجعة طلب سحب للبنية التحتية، فإنك تبحث عن عدة أشياء.
أولاً، هل التغيير منطقي بالنسبة للمتطلب؟ إذا كان شخص ما يفتح منفذًا، هل يحتاج حقًا إلى هذا المنفذ؟ هل هناك بديل أكثر أمانًا؟ هل التغيير يتوافق مع ما اتفق عليه الفريق؟
ثانيًا، هل الإعداد صحيح؟ تحقق من الصياغة (Syntax). تأكد من أن أرقام المنافذ وأحجام المثيلات وكتل CIDR للشبكة دقيقة. ابحث عن قواعد الأمان المتساهلة جدًا. القاعدة التي تسمح بحركة المرور من 0.0.0.0/0 إلى المنفذ 22 هي دائمًا تقريبًا علامة حمراء.
ثالثًا، هل التغيير متسق مع البيئات الأخرى؟ إذا كانت بيئة الاختبار (Staging) تستخدم نوع مثيل معين أو حجم قاعدة بيانات معين، فلا ينبغي لبيئة الإنتاج أن تستخدم فجأة شيئًا مختلفًا تمامًا دون سبب موثق. التناقضات بين البيئات هي مصدر شائع لمشكلات النشر.
رابعًا، هل يتبع التغيير اصطلاحات التسمية ومعايير الوسوم (Tags) لفريقك؟ التسمية المتسقة تجعل من السهل فهم ما هي الموارد ولمن هي. تساعد الوسوم في تخصيص التكاليف وإدارة الموارد.
السجل التاريخي
كل طلب سحب تمت الموافقة عليه ودمجه يصبح سجلاً دائماً لما تغير ومن غيره ومتى. هذا الأثر التاريخي لا يقدر بثمن عندما تسوء الأمور.
تخيل أن تستيقظ لتجد أن تطبيق الإنتاج الخاص بك غير قابل للوصول. تتحقق من التغييرات الأخيرة في مستودع البنية التحتية الخاص بك وترى طلب سحب قام بتعديل إعداد موازن التحميل قبل ساعتين. يمكنك أن ترى فورًا ما الذي تغير، وتناقشه مع الشخص الذي أجرى التغيير، وتقرر ما إذا كنت ستعود إلى الإصدار السابق (Rollback) أو ستصلح للأمام (Fix Forward).
بدون هذا السجل، ستكون في حالة تخمين. ستسأل أعضاء الفريق، وتتفقد سجلات الدردشة، وتبحث في سجلات نشاط وحدة التحكم السحابية. تستغرق العملية وقتًا أطول وهي أقل موثوقية. تاريخ طلبات السحب يعطيك إجابة مباشرة.
معالجة مخاوف السرعة
تقاوم بعض الفرق مراجعات البنية التحتية لأنهم يعتقدون أنها تبطئ الأمور. يجادلون بأن تغييرات البنية التحتية تحتاج إلى أن تحدث بسرعة، خاصة أثناء الحوادث أو التحديثات العاجلة.
الواقع هو أن الوقت المستغرق في المراجعة دائمًا ما يكون أقل من الوقت المستغرق في التعافي من تغيير غير مراجع تسبب في تعطيل الإنتاج. مراجعة مدتها خمس دقائق يمكن أن تمنع انقطاعًا لمدة ساعتين. الحساب واضح ومباشر.
بالنسبة للتغييرات العاجلة أثناء الحوادث، يمكنك تكييف العملية. تستخدم بعض الفرق نموذج مراجعة ما بعد الحادث حيث يتم تطبيق التغيير أولاً لاستعادة الخدمة، ويتم إنشاء طلب السحب ومراجعته بعد ذلك. المفتاح هو أن المراجعة لا تزال تحدث، والتغيير لا يزال موثقًا. العملية تنحني لحالات الطوارئ ولكنها لا تختفي.
ماذا بعد المراجعة
بمجرد أن يجتاز تغيير البنية التحتية المراجعة ويتم دمجه، فإن العمل لم ينته بعد. يحتاج خط الأنابيب (Pipeline) إلى إظهار ما سيتغير فعليًا قبل تطبيقه. هذه هي خطوة الخطة (Plan). يقارن خط الأنابيب الحالة المرغوبة المحددة في الكود الخاص بك مع الحالة الحالية للبنية التحتية الخاصة بك ويظهر الاختلافات. فقط بعد مراجعة الخطة والتأكد من أنها تبدو صحيحة، يتابع خط الأنابيب لتطبيق التغييرات.
خطوة الخطة هذه حاسمة. حتى مع مراجعة الكود الشاملة، يمكن للخطة أن تكشف عن تأثيرات غير متوقعة. التغيير الذي يبدو صحيحًا في الكود قد ينتج خطة تحذف وتعيد إنشاء الموارد، مما قد يسبب توقفًا عن العمل. الخطة تمنحك فرصة أخيرة لالتقاط المشكلات قبل أن تصل إلى الإنتاج.
قائمة تحقق عملية لطلبات سحب البنية التحتية
- هل التغيير يطابق المتطلب أو الطلب الفعلي؟
- هل جميع القيم صحيحة (المنافذ، أحجام المثيلات، نطاقات CIDR)؟
- هل قواعد الأمان مقيدة قدر الإمكان مع السماح بحركة المرور الضرورية؟
- هل التغيير متسق مع البيئات الأخرى؟
- هل يتبع اصطلاحات التسمية والوسوم؟
- هل هناك مخرجات خطة (Plan Output) تظهر ما سيتغير قبل التطبيق؟
الخلاصة
تستحق تغييرات البنية التحتية نفس عملية المراجعة مثل تغييرات كود التطبيق. عواقب تغيير البنية التحتية السيئ غالبًا ما تكون أكثر خطورة ويصعب تشخيصها من تغيير الكود السيئ. توفر طلبات السحب طريقة منظمة لالتقاط الأخطاء، وفرض المعايير، والحفاظ على سجل تاريخي. الوقت الذي تستثمره في مراجعة تغييرات البنية التحتية هو وقت لن تقضيه في تصحيح أعطال الإنتاج الناتجة عن تغييرات الإعدادات غير المراجعة. تعامل مع كود البنية التحتية الخاص بك بنفس العناية التي تتعامل بها مع كود التطبيق الخاص بك، وستشكرك بيئة الإنتاج الخاصة بك.