كانت بيئاتنا تتغير من وراء ظهورنا: كيف أنقذتنا ‘البنية التحتية كشيفرة’ (IaC) من جحيم الانحراف التكويني؟

السلام عليكم يا جماعة الخير،

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

اجتمعنا كلنا على عجل في مكالمة طارئة. أنا وفريقي من المطورين، وفريق العمليات (Ops). السؤال الأول الذي يطرح نفسه دائمًا في هذه المواقف: “هل قمنا بنشر أي تحديث جديد؟” الجواب كان “لا”. آخر تحديث كان قبل أسبوع وكل شيء كان يعمل “زي الحلاوة”.

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

بعد ثلاث ساعات من التحقيق المضني، صرخ أحد الزملاء من فريق العمليات: “لقيتها!”. تبين أن أحد المهندسين، قبل أسبوعين، قام بتحديث يدوي لإحدى الحزم (packages) على أحد الخوادم مباشرة في بيئة الإنتاج لحل مشكلة أداء صغيرة. كان تحديثًا بسيطًا، لم يخبر به أحدًا، ونسيه تمامًا. هذا التحديث “البسيط” تسبب في عدم توافق مع مكتبة أخرى استخدمناها في الميزة التي تعطلت.

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

ما هو “الانحراف التكويني” (Configuration Drift)؟ ولماذا هو كابوس المطورين؟

ببساطة، الانحراف التكويني هو عندما تصبح إعدادات بيئة ما (مثل بيئة الإنتاج) مختلفة مع مرور الوقت عن الحالة الأصلية الموثقة أو عن البيئات الأخرى (مثل التطوير والاختبار). تخيل أنك تبدأ بوصفة كيك موحدة، ولكن في كل مرة يخبزها شخص مختلف، يضيف “رشة” ملح إضافية أو يقلل من السكر قليلًا. بعد فترة، ستحصل على كيك مختلف تمامًا عن الوصفة الأصلية.

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

من أين يأتي هذا الانحراف اللعين؟

• الإصلاحات السريعة (Hotfixes): الحاجة لإصلاح مشكلة حرجة في بيئة الإنتاج تدفع المهندسين لإجراء تغييرات يدوية مباشرة على الخادم.
• الوصول اليدوي: منح المطورين أو مهندسي العمليات صلاحية الوصول عبر SSH إلى الخوادم “بس عشان أجرب إشي”. هذه الجملة هي بداية العديد من الكوارث.
• تحديثات غير متزامنة: تحديث حزمة أو نظام تشغيل في بيئة دون الأخرى.
• غياب التوثيق: عندما يتم التغيير ولا يتم توثيقه، يصبح جزءًا من “المعرفة القبلية” التي تضيع بمجرد أن يغادر الموظف الشركة.

النتيجة؟ كابوس “It works on my machine” الشهير، فشل عمليات النشر، ثغرات أمنية غير متوقعة، وساعات طويلة من تصحيح الأخطاء في منتصف الليل.

البنية التحتية كشيفرة (IaC): طوق النجاة

بعد تلك الليلة المشؤومة، عقدنا العزم على أن هذا الوضع لا يمكن أن يستمر. وهنا كان دخولنا إلى عالم “البنية التحتية كشيفرة” أو Infrastructure as Code (IaC). الفكرة عبقرية في بساطتها: عامل بنيتك التحتية (خوادم، شبكات، قواعد بيانات، إلخ) كما تعامل كود التطبيق الخاص بك.

بدلًا من النقر على الأزرار في واجهة المستخدم الخاصة بمزود الخدمة السحابية أو كتابة أوامر يدوية على الخوادم، أنت تكتب ملفات نصية (شيفرة) تصف شكل البنية التحتية التي تريدها بالضبط. هذه الملفات تصبح “المصدر الوحيد للحقيقة” (Single Source of Truth).

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

هذه المنهجية غيرت قواعد اللعبة تمامًا، ومنحتنا قوى خارقة:

• التكرار والموثوقية: يمكنك إنشاء نفس البيئة عشرات المرات، وفي كل مرة ستحصل على نفس النتيجة طبق الأصل، مما يقضي على متلازمة “تعمل عندي ولا تعمل عندك”.
• الأتمتة: بناء بيئة تطوير كاملة أو تدميرها أصبح يتم بأمر واحد، مما يوفر وقتًا وجهدًا لا يصدقان.
• التحكم في الإصدارات (Versioning): تمامًا مثل كود التطبيق، يتم حفظ شيفرة البنية التحتية في نظام مثل Git. يمكنك أن ترى تاريخ كل تغيير، من قام به، ولماذا، ويمكنك العودة لإصدار سابق بسهولة.
• الشفافية والمراجعة: أصبحت تغييرات البنية التحتية تمر عبر عملية مراجعة (Code Review) مثل أي كود آخر. يمكن للفريق بأكمله مناقشة التغييرات والموافقة عليها قبل تطبيقها.

أشهر الأدوات في عالم الـ IaC: نظرة على Terraform

هناك العديد من الأدوات الرائعة في هذا المجال مثل AWS CloudFormation, Azure Resource Manager, Pulumi, و Ansible. ولكن الأداة التي تبنيناها والتي أعتبرها نقطة بداية ممتازة للكثيرين هي Terraform من شركة HashiCorp.

ما يميز Terraform هو أنها “غير مرتبطة بسحابة معينة” (Cloud-Agnostic)، مما يعني أنه يمكنك استخدامها لإدارة بنيتك التحتية على AWS, Google Cloud, Azure, وغيرها الكثير بنفس الطريقة ونفس اللغة. لغتها، HCL، سهلة القراءة والكتابة، وهي لغة تعريفية (Declarative)، أي أنك “تصف” الحالة النهائية التي تريدها، وTerraform تتكفل بالباقي.

مثال عملي: لنبني سيرفر بسيط على السحابة باستخدام Terraform

لنفترض أننا نريد إنشاء خادم افتراضي (EC2 instance) على AWS. بدلًا من الدخول للموقع والنقر على عشرات الأزرار، سنكتب ملفًا بسيطًا اسمه `main.tf`:

# main.tf

# تحديد مزود الخدمة السحابية (AWS) والمنطقة
provider "aws" {
  region = "us-east-1"
}

# تعريف الخادم الافتراضي (المورد)
resource "aws_instance" "my_server" {
  ami           = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 AMI
  instance_type = "t2.micro"             # نوع الخادم (حجمه)

  tags = {
    Name = "MyWebAppServer"
  }
}

هذا كل شيء! هذا الكود البسيط يصف بوضوح ما نريده: خادم من نوع `t2.micro` يستخدم صورة نظام تشغيل محددة في منطقة `us-east-1`.

الآن، كل ما علينا فعله هو فتح الطرفية (Terminal) في نفس المجلد وتنفيذ ثلاثة أوامر سحرية:

1. terraform init: يقوم هذا الأمر بتهيئة بيئة العمل وتنزيل الإضافات اللازمة لمزود الخدمة (AWS في حالتنا). تنفذه مرة واحدة في البداية.
2. terraform plan: هذا هو أمر الأمان الخاص بك. يقوم Terraform بمقارنة الشيفرة التي كتبتها بالبنية التحتية الحالية ويعرض لك “خطة” بما سيقوم بإنشائه أو تغييره أو حذفه. لن يتم تنفيذ أي شيء فعليًا، إنها مجرد معاينة.
3. terraform apply: بعد مراجعة الخطة والتأكد من أنها صحيحة، يقوم هذا الأمر بتنفيذ التغييرات على أرض الواقع.

إذا أراد شخص ما الآن تغيير نوع الخادم من `t2.micro` إلى `t2.small`، فلن يدخل إلى الخادم يدويًا. بل سيقوم بتغيير سطر واحد في الكود، ويخضعه للمراجعة، ثم ينفذ `terraform apply` مرة أخرى. Terraform ذكية بما يكفي لتدرك أن التغيير الوحيد المطلوب هو تعديل نوع الخادم، وستقوم بذلك.

نصائح أبو عمر الذهبية للبدء مع الـ IaC

من خلال رحلتي مع هذه التقنية، تعلمت بعض الدروس التي أود مشاركتها معكم:

• ابدأ صغيرًا: لا تحاول تحويل كل بنيتك التحتية دفعة واحدة. ابدأ بمشروع جديد صغير، أو بجزء غير حرج من نظامك الحالي. ابنِ ثقتك وفهمك للأداة خطوة بخطوة.
• خزّن “ملف الحالة” عن بعد: تنتج Terraform ملفًا مهمًا يسمى `terraform.tfstate` يتتبع حالة بنيتك التحتية. افتراضيًا، يكون هذا الملف محليًا على جهازك، وهذا كارثي للعمل الجماعي. تعلم فورًا كيفية تخزين هذا الملف في مكان مركزي وآمن (مثل AWS S3 مع DynamoDB locking) لضمان أن الفريق بأكمله يعمل على نفس الحالة.
• الأتمتة هي الهدف الأسمى: ادمج أوامر Terraform في مسارات النشر والتكامل المستمر (CI/CD pipelines). اجعل `terraform plan` جزءًا من كل Pull Request، واجعل `terraform apply` يتم تلقائيًا بعد دمج التغييرات في الفرع الرئيسي.
• لا تخلط بين التزويد والإدارة: Terraform ممتازة في “تزويد” البنية التحتية (إنشاء الخوادم، الشبكات). لكن لإدارة “ما بداخل” هذه الخوادم (تثبيت البرامج، تحديث الملفات)، أدوات مثل Ansible أو Chef قد تكون خيارًا أفضل. تعلم كيف تجعل هذه الأدوات تعمل معًا بانسجام.
• الشيفرة هي شيفرة: عامل شيفرة البنية التحتية بنفس الاحترام الذي تعامل به شيفرة تطبيقك. استخدم أسماء واضحة للمتغيرات، أضف تعليقات، قسم الكود إلى وحدات (modules) قابلة لإعادة الاستخدام.

الخلاصة: من الفوضى اليدوية إلى النظام المؤتمت ✨

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

لم نعد نخشى التغيير، بل أصبحنا نرحب به، لأننا نعلم أن كل تغيير موثق، ومُراجَع، وقابل للتراجع. وداعًا لمكالمات الطوارئ في منتصف الليل بسبب “تغيير يدوي بسيط”، ومرحبًا بالثقة والسرعة والاستقرار.

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