أذكرها جيداً تلك الليلة، كانت الساعة قد تجاوزت الثانية صباحاً، وفنجان القهوة الثالث بجانبي لم يعد له أي تأثير. كنا على وشك إطلاق ميزة جديدة انتظرها العملاء بفارغ الصبر. البيئة التجريبية (Staging) كانت تعمل “زي الحلاوة”، كل الاختبارات ناجحة، والفريق كله متفائل. ضغطنا زر النشر على البيئة الإنتاجية (Production)… وإذا بالكارثة تحل.
الموقع انهار بالكامل. رسائل خطأ غريبة لم نرها من قبل بدأت تظهر في كل مكان. العرق البارد بدأ يتصبب مني، وهواتف الفريق لم تتوقف عن الرنين. السؤال الذي كان يتردد في ذهني كالمطرقة: “كيف؟! كل شيء كان يعمل قبل دقائق!”.
قضينا الساعات الثلاث التالية في جحيم حقيقي. ندخل عبر SSH إلى خادم الإنتاج، ثم إلى الخادم التجريبي، ونقارن ملفات الإعدادات سطراً بسطر. إلى أن اكتشفنا المشكلة: أحد المطورين الجدد، بحسن نية، كان قد حدّث مكتبة صغيرة على الخادم التجريبي يدوياً لحل مشكلة بسيطة، ونسي أن يوثق هذا التغيير أو يطلبه للبيئة الإنتاجية. تغيير بسيط، لا يتجاوز بضعة كيلوبايتات، كان كفيلاً بإيقاف عمل بملايين الدولارات.
في تلك الليلة، ونحن نعيد الموقع للعمل بعد تراجع مرهق، أقسمت أن هذه الفوضى يجب أن تنتهي. كانت بيئاتنا عبارة عن نسخ مشوهة ومختلفة عن بعضها، وهذا ما يُعرف بـ “الانحراف التكويني” (Configuration Drift)، وهو وحش صامت يلتهم الإنتاجية ويدمر الأعصاب. ومن هنا، بدأت رحلتنا الحقيقية مع “البنية التحتية كشيفرة” (IaC).
ما هو “الانحراف التكويني” وليش هو شغلة بتجلط؟
ببساطة، الانحراف التكويني هو عندما تصبح إعدادات البنية التحتية لبيئة ما (مثل الإنتاج) مختلفة عن بيئة أخرى (مثل التجريب) مع مرور الوقت. هذا يحدث بسبب التغييرات اليدوية، التحديثات الطارئة غير الموثقة، أو حتى الأخطاء البشرية البسيطة.
تخيل أنك تبني بيتين بنفس المخطط الهندسي تماماً. لكن في البيت الأول، قرر عامل الكهرباء تمديد سلك من مكان مختلف قليلاً، وفي البيت الثاني، قرر السباك استخدام نوع مختلف من الأنابيب. في النها стран، قد يبدو البيتان متطابقين، لكن في الحقيقة هما قنبلتان موقوتتان من المشاكل المستقبلية. هذا بالضبط ما يحدث في خوادمنا.
المشكلة الحقيقية تكمن في أن هذا الانحراف صامت وغير مرئي، ولا تكتشفه إلا في أسوأ الأوقات: وقت النشر، أو عند حدوث عطل مفاجئ.
البنية التحتية كشيفرة (IaC): طوق النجاة
هنا يأتي دور المنقذ: Infrastructure as Code (IaC). الفكرة عبقرية في بساطتها: بدلاً من إعداد الخوادم والشبكات وقواعد البيانات يدوياً عبر واجهات رسومية أو أوامر متفرقة، نقوم بكتابة “وصف” لهذه البنية التحتية على شكل شيفرة (كود).
هذه الشيفرة تصبح هي “مصدر الحقيقة الأوحد” (Single Source of Truth). هل تريد إنشاء خادم جديد؟ عدّل الشيفرة. هل تريد فتح منفذ (port) في الجدار الناري؟ عدّل الشيفرة. هل تريد إنشاء ثلاث بيئات متطابقة 100%؟ قم بتشغيل نفس الشيفرة ثلاث مرات.
الفوائد اللي شفناها بعينينا
- وداعاً للانحراف التكويني: بما أن الشيفرة هي المصدر الوحيد، نضمن أن بيئة التطوير والتجريب والإنتاج متطابقة تماماً. جملة “على جهازي شغال!” أصبحت من الماضي.
- السرعة الخارقة: بدلاً من قضاء ساعات أو أيام في إعداد بيئة جديدة، أصبحنا نستطيع إنشاء بنية تحتية معقدة في دقائق معدودة بتنفيذ أمر واحد.
- التكرار والموثوقية: يمكننا تدمير وإعادة بناء أي بيئة بثقة تامة، مع العلم أنها ستعود بنفس الإعدادات بالضبط في كل مرة.
- التوثيق الذاتي: الشيفرة نفسها هي أفضل توثيق للبنية التحتية. أي شخص جديد في الفريق يمكنه قراءة الكود وفهم مكونات النظام.
- التحكم في الإصدارات (Version Control): يمكننا تخزين شيفرة البنية التحتية في Git تماماً مثل كود التطبيق. هذا يعني أننا نستطيع تتبع كل تغيير، معرفة من قام به ومتى، ومراجعة التغييرات (Code Review)، وحتى العودة لإصدار سابق إذا حدث خطأ. هذه نقطة تحول حقيقية!
كيف يعمل السحر؟ Terraform كمثال
توجد أدوات كثيرة لتطبيق IaC مثل AWS CloudFormation, Azure Resource Manager, Ansible وغيرها. لكن الأداة التي غيرت قواعد اللعبة بالنسبة لنا، والتي أعتبرها “السكين السويسري” لمهندس DevOps، هي Terraform.
Terraform تتميز بأنها “Cloud-Agnostic”، أي أنها لا تنتمي لشركة سحابية معينة، ويمكنها التعامل مع AWS, Azure, Google Cloud, وغيرها الكثير بنفس الطريقة.
مثال عملي بسيط جداً
لنفترض أننا نريد إنشاء خادم (EC2 Instance) بسيط على AWS. بدلاً من الدخول للموقع والنقر على عشرات الأزرار، نكتب ملفاً بسيطاً بلغة HCL (HashiCorp Configuration Language) كالتالي:
# provider.tf
provider "aws" {
region = "us-east-1"
}
# main.tf
resource "aws_instance" "web_server" {
ami = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 AMI
instance_type = "t2.micro"
tags = {
Name = "WebServer-Example"
}
}
هذا كل شيء! الآن، كل ما علينا فعله هو تنفيذ أمرين في الطرفية (Terminal):
terraform plan: يقوم Terraform بقراءة الكود ومقارنته بالبنية التحتية الحقيقية، ثم يخبرك بالضبط بما سيقوم بفعله (مثلاً: “سأقوم بإنشاء خادم واحد بالمواصفات كذا وكذا”).terraform apply: إذا أعجبتك الخطة، تنفذ هذا الأمر، فيقوم Terraform بتحويل الكود إلى بنية تحتية حقيقية على AWS.
الجمال هنا هو أن هذا الكود يمكن إعادة استخدامه، وضعه في Git، وتطبيقه على حسابات مختلفة لإنشاء نسخ متطابقة تماماً من الخادم.
نصائح “أبو عمر” العملية للبدء
بعد سنوات من العمل مع IaC، تعلمت بعض الدروس بالطريقة الصعبة. إليكم خلاصة خبرتي “من الآخر”:
- ابدأ صغيراً: لا تحاول تحويل كل بنيتك التحتية إلى كود في يوم واحد. اختر مكوناً صغيراً غير حرج، مثل خادم تطوير، وحاول أتمتته. ثم توسع تدريجياً.
- لا تلمس الواجهة الرسومية أبداً!: بعد أن تبدأ بإدارة مورد ما عبر IaC (مثل خادم)، عاهد نفسك ألا تقوم بأي تغيير يدوي عليه من خلال واجهة AWS أو Azure. أي تغيير يجب أن يتم عبر تعديل الكود. هذا هو القانون الأول والأهم.
- احفظ ملف الحالة (State File) جيداً: تيرافورم يستخدم ملفاً يسمى “state file” ليتابع حالة الموارد التي يديرها. هذا الملف ثمين جداً. استخدم حلولاً مثل S3 Backend مع DynamoDB locking لتخزينه بشكل آمن ومشاركته مع الفريق.
- استخدم الوحدات (Modules): لا تكرر كتابة الكود. إذا كنت تنشئ نفس نوع الخادم في أماكن مختلفة، قم بتحويله إلى “وحدة” (Module) قابلة لإعادة الاستخدام. هذا يجعل الكود أنظف وأسهل في الصيانة.
- IaC هي ثقافة، وليست مجرد أداة: شجع فريقك على تبني هذه العقلية. مراجعة كود البنية التحتية يجب أن تكون بنفس أهمية مراجعة كود التطبيق.
الخلاصة 🚀
التحول إلى “البنية التحتية كشيفرة” لم يكن مجرد تغيير تقني، بل كان تحولاً في العقلية والثقافة داخل الفريق. انتقلنا من حالة الفوضى والخوف الدائم من النشر، إلى حالة من الثقة والنظام والسرعة. تخلصنا من لعنة “الانحراف التكويني” ومن ليالي الرعب الطويلة التي نقضيها في مقارنة ملفات الإعدادات.
قد يبدو الأمر معقداً في البداية، ولكنه استثمار سيعود عليك وعلى فريقك بفوائد لا تقدر بثمن على المدى الطويل. لن تعود للنظر إلى الوراء أبداً.
يلا يا جماعة، شدوا حيلكم، المستقبل يُكتب بالشيفرة، حتى البنية التحتية.
