خليني أحكيلكم قصة صارت معي ومع فريقي قبل كم سنة، قصة علّمتنا درس ما بننساه. كنا شغالين على مشروع كبير، “مشروع الفينيق” سمّيناه، وكان كل شغلنا على السحابة (Cloud). الأمور كانت ماشية تمام، والتطبيق شغال زي الساعة. ليلة خميس، وأنا قاعد مع العيلة ومبسوط على الآخر، وإلا التلفون برن… والمصيبة إنه رقم مدير المشروع.
قلبي بلش يدق بسرعة، وعرفت إنه في مصيبة. “أبو عمر، الموقع واقع! كل اشي داون!”. يا جماعة الخير، شعور لا أحسد عليه عدو ولا حبيب. طيران على اللابتوب، وبفتح أنظمة المراقبة… كله أحمر. السيرفرات مش عم بترد، وقواعد البيانات مش لاقيينها، وكأن عفريت أخد كل البنية التحتية تبعتنا وطار فيها.
قضينا ليلتها، أنا والفريق، في اجتماع طوارئ على الإنترنت، والكل بسأل السؤال المشهور: “مين آخر واحد لمس إشي؟ مين غيّر إشي؟”. طبعاً، الجواب دايماً “أنا ما عملت إشي!”. بعد ساعات من الحفر والنبش في سجلات التغيير اليدوية (logs) ومقارنة الإعدادات بين البيئات المختلفة، اكتشفنا الكارثة. زميل النا، بحسن نية، عمل “تعديل بسيط” على إعدادات الشبكة (Security Group) عشان يحل مشكلة مؤقتة، بس نسي يرجّعه. هذا التعديل البسيط عمل تأثير الدومينو، وخلال ساعات، كل النظام انهار.
في تلك الليلة، وإحنا بنرجع كل إشي يدويًا، قطعة قطعة، أدركت حقيقة مرّة: بنيتنا التحتية اللي كنا فخورين فيها، كانت مجرد قصور من رمال. أي نسمة هواء، أي تغيير بسيط غير موثّق، كان كفيل بإنه يهدم كل اشي بنيناه. ومن هنا، بدأت رحلتنا الحقيقية مع مفهوم “البنية التحتية كشيفرة” أو Infrastructure as Code.
ما هو “انحراف الإعدادات” (Configuration Drift)؟ وليش هو كابوس كل مطور؟
المشكلة اللي واجهناها في قصة “مشروع الفينيق” الها اسم تقني فخم: انحراف الإعدادات (Configuration Drift).
ببساطة، هو لما تصير البيئة الحقيقية (Production Environment) مختلفة عن الإعدادات اللي أنت مخطط إلها أو اللي موثقها. تخيل إنك عندك مخطط معماري لبناية، بس كل يوم بيجي عامل بغير شباك، وعامل تاني بزيد حيط صغير، والتالت بغير مكان باب… بعد فترة، البناية اللي على أرض الواقع ما إلها أي علاقة بالمخطط الأصلي! هذا بالضبط اللي بصير مع البنية التحتية للسيرفرات والخدمات السحابية.
أسباب الانحراف في الإعدادات:
- الإصلاحات العاجلة (Hotfixes): زي ما صار معنا، تغيير سريع ومباشر على البيئة الحية لحل مشكلة طارئة.
- التعديلات اليدوية: مطور أو مسؤول نظام (SysAdmin) يدخل على السيرفر مباشرة عبر SSH ويغير إعدادات معينة بدون توثيق.
- عدم توحيد البيئات: بيئة التطوير (Dev) تختلف عن بيئة الاختبار (Staging)، وكلاهما يختلف عن بيئة الإنتاج (Production). وهذا هو أصل المقولة الشهيرة “بس كانت شغالة على جهازي!”.
- غياب التوثيق المركزي: كل واحد بوثّق على طريقته، أو الأسوأ، ما بوثّق بالمرة.
هذا الانحراف بخلي نظامك غير متوقع، صعب الصيانة، ومستحيل إعادة بنائه بسرعة في حالة الكوارث. يعني باختصار، “بلاوي”.
البطل المنقذ: البنية التحتية كشيفرة (Infrastructure as Code – IaC)
هنا يأتي دور الـ IaC لينقذ الموقف. الفكرة عبقرية وبسيطة في نفس الوقت: عامل البنية التحتية تبعتك (سيرفرات، شبكات، قواعد بيانات، …) بنفس الطريقة اللي بتعامل فيها كود التطبيق تبعك.
بدل ما تدخل على واجهة أمازون (AWS Console) أو أزور (Azure Portal) وتكبّس وتغيّر بالإعدادات، بتكتب “شيفرة” أو “كود” يوصف شكل البنية التحتية اللي بدك إياها. هذا الكود بصير هو “مصدر الحقيقة الوحيد” (Single Source of Truth).
ليش الـ IaC هو الحل السحري؟
- التوثيق الذاتي: الكود نفسه هو التوثيق. أي حدا بده يعرف كيف البنية التحتية شغالة، بس بقرأ الكود.
- التحكم في الإصدارات (Version Control): بتقدر تحفظ كود البنية التحتية على Git. بتقدر تشوف مين غيّر إيش ومتى، ترجع لإصدار قديم لو صار مشكلة، وتعمل مراجعة للكود (Code Review) قبل ما تطبّق أي تغيير. وداعاً لسؤال “مين آخر واحد لمس إشي؟”.
- التكرار والاتساق: نفس الكود رح يبني نفس البنية التحتية كل مرة، سواء لبيئة التطوير، الاختبار، أو الإنتاج. خلص ما في “كانت شغالة عندي”.
- الأتمتة: بكبسة زر، بتقدر تبني بنية تحتية كاملة من الصفر، أو تهدمها عشان توفر مصاريف لما ما تكون مستخدمة.
Terraform في الميدان: مثال عملي
من أشهر الأدوات في عالم الـ IaC هي أداة Terraform من شركة HashiCorp. اللي بميزها إنها “سحابية-محايدة” (Cloud-Agnostic)، يعني بتقدر تستخدمها مع AWS, Azure, Google Cloud وغيرهم بنفس المنطق ونفس الأوامر.
خلينا نشوف مثال بسيط جداً. تخيل بدنا ننشئ S3 Bucket على AWS (مكان لتخزين الملفات).
بدل ما ندخل على واجهة AWS ونعمل 10 كبسات، بنكتب ملف بسيط اسمه main.tf:
# تحديد مزود الخدمة السحابية (في حالتنا AWS)
provider "aws" {
region = "eu-west-1" # المنطقة اللي رح نشتغل فيها
}
# تعريف المورد اللي بدنا ننشئه (S3 Bucket)
resource "aws_s3_bucket" "project_phoenix_backups" {
bucket = "abu-omar-project-phoenix-backups-12345" # اسم الـ Bucket (لازم يكون فريد عالمياً)
tags = {
Name = "Project Phoenix Backups"
ManagedBy = "Terraform"
Owner = "Abu Omar"
}
}
هذا الكود بسيط وواضح ومقروء. أي حدا بشوفه بفهم إنه إحنا بدنا نعمل S3 Bucket في منطقة eu-west-1 وهي الخصائص تبعته.
كيف بنستخدمه؟
سحر Terraform يكمن في ثلاث أوامر رئيسية:
terraform init: تجهيز بيئة العمل وتنزيل الإضافات اللازمة للمزود السحابي (AWS في مثالنا). بتعملها مرة واحدة في البداية.terraform plan: هذا هو الأمر السحري! Terraform بقارن الكود اللي أنت كاتبه مع الوضع الحالي على السحابة، وبعطيك “خطة” بالتغييرات اللي رح يعملها. بقلك رح أضيف كذا، وأعدل كذا، وأحذف كذا. هيك ما في مفاجآت.terraform apply: إذا عجبتك الخطة اللي عرضها عليك في الـplan، بتكتب هاد الأمر عشان يطبقها على أرض الواقع.
والله يا جماعة، لما تشوف كيف terraform plan بعرضلك بالضبط شو رح يتغير قبل ما يتغير، بتحس براحة نفسية ما إلها مثيل.
نصيحة أبو عمر 💡
دائماً، دائماً، دائماً، شغل
terraform planوادرسه كويس قبل ما تعملapply. هاد الأمر هو شبكة الأمان تبعتك. كمان نصيحة، لا تخزن ملفات الحالة (state files) على جهازك. استخدم “الواجهة الخلفية البعيدة” (Remote Backend) مثل S3 Bucket عشان فريقك كله يشتغل على نفس ملف الحالة وتمنعوا المشاكل.
الخلاصة: لا تبنوا قصوركم على الرمال 🚀
التحول إلى “البنية التحتية كشيفرة” ما كان مجرد تغيير تقني لفريقنا، بل كان تغيير في العقلية والثقافة. انتقلنا من حالة الخوف والفوضى والبحث عن “المذنب” عند كل مشكلة، إلى حالة من الثقة والسرعة والتعاون. صرنا نعمل تغييرات على البنية التحتية بنفس الثقة اللي بنعمل فيها تغييرات على كود التطبيق، لأنه كل اشي موثق، ومُراجع، ومُؤتمت.
صحيح، في البداية رح تحتاج وقت لتتعلم وتطبّق، ورح تحس إنه الشغل اليدوي أسرع. لكن صدقني، هاي مجرد نظرة قصيرة المدى. على المدى الطويل، الاستثمار في IaC هو أفضل قرار ممكن تاخده عشان تحمي نظامك، وفريقك، وراحة بالك.
نصيحتي الأخيرة لكل فريق تطوير أو شركة: ابدأوا اليوم، ولو بخطوة صغيرة. اختاروا جزء بسيط من بنيتكم التحتية وحاولوا إدارته عن طريق Terraform. رح تشوفوا الفائدة بسرعة، ورح تتساءلوا كيف كنتم عايشين في جحيم التعديلات اليدوية من قبل. تذكروا دائمًا: القصور المتينة تُبنى على أساسات من الشيفرة الصلبة، وليس على الرمال المتحركة. بالتوفيق يا جماعة!
