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

ليلة الشاي بالنعنع التي تحولت إلى كابوس

كنت قاعد في ليلة هادئة، ماسك كاسة الشاي بالنعنع اللي ما بستغني عنها، وبراجع شوية Pull Requests لفريقي. فجأة، بدأت التنبيهات توصل على Slack زي المطر. “High CPU Usage on Web-Server-03”, “API Latency Spikes”, “5xx Errors Increasing”. قلبي بلش يدق بسرعة، وتركت كاسة الشاي اللي بردت على المكتب.

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

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

في تلك اللحظة، أدركت أن مشكلتنا ليست في الكود، بل في “التكوينات الشبحية” (Ghost Configurations). تغييرات يدوية، غير موثقة، تتم على عجل وتُنسى، لتتحول إلى كوابيس تطاردنا في أوقات غير متوقعة. هذه الليلة كانت القشة التي قصمت ظهر البعير، واللحظة التي قررت فيها أن هذا الوضع لا يمكن أن يستمر. هنا بدأت رحلتي الحقيقية مع “البنية التحتية كشفرة” أو Infrastructure as Code (IaC).

ما هي “التكوينات الشبحية” أو الـ Configuration Drift؟

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

أسباب ظهور هذه الأشباح:

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

هذه الفوضى لا تضيع الوقت والجهد فقط، بل تزيد من مخاطر الأمان وتجعل عملية التعافي من الكوارث (Disaster Recovery) شبه مستحيلة.

المنقذ: البنية التحتية كشفرة (Infrastructure as Code – IaC)

البنية التحتية كشفرة (IaC) هي منهجية لإدارة وتوفير البنية التحتية (خوادم، شبكات، قواعد بيانات، إلخ) من خلال ملفات تكوين قابلة للقراءة آلياً (كود)، بدلاً من الاعتماد على الإعدادات اليدوية.

ببساطة، بدل ما تدخل على واجهة AWS أو Azure وتكبس “Create Server”، أنت بتكتب كود بسيط يصف الخادم الذي تريده. هذا الكود يصبح هو “العقد” أو “مصدر الحقيقة” الذي يصف بنيتك التحتية بشكل دقيق.

ليش هالقد مهمة؟ (لماذا هي بهذه الأهمية؟)

• النسخ والتحكم (Version Control): يمكنك تخزين كود البنية التحتية في نظام مثل Git. هذا يعني أنك تستطيع تتبع كل تغيير: من قام به، متى، ولماذا. وداعاً للتغييرات المجهولة.
• التكرار والاتساق (Repeatability & Consistency): يمكنك استخدام نفس الكود لإنشاء بيئة تطوير مطابقة 100% لبيئة الإنتاج. هذا يقضي على مشكلة “شغالة على جهازي”.
• الأتمتة والسرعة (Automation & Speed): يمكنك إنشاء بنية تحتية معقدة تتكون من عشرات الخوادم والخدمات في دقائق، بضغطة زر واحدة، بدلاً من ساعات أو أيام من العمل اليدوي المليء بالأخطاء.
• التعافي من الكوارث (Disaster Recovery): لو انهار خادم أو حتى مركز بيانات كامل، يمكنك إعادة بنائه من الصفر في مكان آخر خلال دقائق باستخدام الكود.

Terraform: المطرقة السحرية في عالم الـ IaC

هناك العديد من الأدوات لتطبيق IaC (مثل AWS CloudFormation, Ansible, Pulumi)، ولكن الأداة التي أعتبرها “سكين الجيش السويسري” في هذا المجال هي Terraform من شركة HashiCorp.

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

مثال عملي: إنشاء خادم ويب بسيط باستخدام Terraform

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

# 1. تحديد مزود الخدمة السحابية (AWS) والمنطقة
provider "aws" {
  region = "eu-central-1" # فرانكفورت كمثال
}

# 2. تحديد مصدر بيانات للحصول على آخر نسخة من نظام التشغيل
data "aws_ami" "latest_amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# 3. تعريف المورد (الخادم) الذي نريد إنشاءه
resource "aws_instance" "web_server" {
  ami           = data.aws_ami.latest_amazon_linux.id
  instance_type = "t2.micro" # نوع الخادم (صغير ومناسب للتجارب)

  # الوسوم تساعدنا في تنظيم مواردنا
  tags = {
    Name        = "WebServer-From-IaC"
    Project     = "MyAwesomeApp"
    ManagedBy   = "Terraform"
  }
}

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

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

في غضون دقيقة أو دقيقتين، سيكون لديك خادم ويب جديد يعمل في السحابة، تم إنشاؤه بالكامل من خلال الكود!

كيف قضت الـ IaC على الأشباح في أنظمتي؟

بعد تلك الليلة المشؤومة، اعتمدنا Terraform كجزء أساسي من عملنا. والنتيجة؟

أصبح كود Terraform المخزن في Git هو مصدر الحقيقة الأوحد. لا يُسمح بأي تغيير يدوي على بيئة الإنتاج. أي تعديل يجب أن يتم عبر تحديث الكود ومراجعته من قبل الفريق (Pull Request) ثم تطبيقه بشكل مؤتمت.

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

نصائح من قلب الميدان (من خبرة أبو عمر)

الانتقال إلى IaC رحلة، وهذه بعض النصائح لتجعل رحلتك أسهل:

• ابدأ صغيراً (Start Small): لا تحاول تحويل كل بنيتك التحتية إلى كود دفعة واحدة. ابدأ بمشروع جديد أو مكون صغير ومنعزل. أكسب الثقة والخبرة ثم توسع تدريجياً.
• خزّن “ملف الحالة” عن بعد (Use Remote State): هاي أهم نصيحة، اسمع مني! بشكل افتراضي، يحفظ Terraform ملف اسمه terraform.tfstate على جهازك، وهو يحتوي على حالة البنية التحتية الحالية. هذا كابوس عند العمل ضمن فريق. استخدم “الخلفية البعيدة” (Remote Backend) مثل AWS S3 لتخزين هذا الملف مركزيًا.
• لا تضع الأسرار في الكود (Don’t Hardcode Secrets): إياك ثم إياك أن تضع كلمات المرور أو مفاتيح الـ API مباشرة في الكود. استخدم متغيرات البيئة (Environment Variables) أو أدوات إدارة الأسرار مثل HashiCorp Vault أو AWS Secrets Manager.
• اجعلها جزءاً من الـ CI/CD: قم بأتمتة عملية الـ `plan` و `apply` ضمن مسار التكامل والنشر المستمر (CI/CD Pipeline). مثلاً، عند عمل Pull Request، يتم تشغيل `terraform plan` تلقائياً وعرض النتيجة ليراجعها الفريق.
• استخدم الوحدات (Modules): عندما يكبر الكود، قم بتقسيمه إلى “وحدات” قابلة لإعادة الاستخدام. مثلاً، يمكنك عمل وحدة لإنشاء خادم ويب بكل إعداداته، ثم تستدعي هذه الوحدة كلما احتجت خادماً جديداً.

الخلاصة: من الفوضى إلى النظام

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

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