فاتورة AWS تلتهم ميزانيتك؟ دليلك العملي لاصطياد وإيقاف “الزومبيز” السحابية المنسية

يا جماعة الخير، خلّوني أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس قاسي عن الحوسبة السحابية. كنت وقتها شغال على مشروع ذكاء اصطناعي شخصي، مشروع بحتاج قوة معالجة “محترمة” لتدريب نموذج لغوي. زي أي مطور متحمس، دخلت على حسابي في AWS وشغّلت أقوى سيرفر (EC2 instance) فيه كرت شاشة (GPU) من اللي بحبه قلبك. قضيت ليلة الخميس وأنا أعمل تجارب وأضبط الإعدادات، والأمور كانت “عال العال”.

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

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

ما هي “الزومبيز” السحابية ولماذا هي خطيرة؟

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

من أين تأتي هذه “الزومبيز”؟

• بيئات التطوير والاختبار (Dev/Test Environments): المطورون (وأنا أولهم) ينشئون سيرفرات وقواعد بيانات وموارد أخرى لاختبار فكرة جديدة أو إصلاح خطأ برمجي، وبعد الانتهاء، ينسون حذفها.
• مشاريع مؤقتة وإثبات المفاهيم (PoCs): تبدأ الشركة مشروعاً تجريبياً، تخصص له موارد، ثم تقرر إلغاء المشروع. لكن لا أحد يتذكر أن يعود ويحذف تلك الموارد.
• دوران الموظفين (Employee Turnover): عندما يغادر موظف الشركة، قد تظل الموارد التي أنشأها تعمل في حسابه دون أن يعرف أحد لمن تتبع أو ما هو الغرض منها.
• مرفقات منسية (Orphaned Resources): من أشهر الأمثلة هي أقراص التخزين (EBS Volumes) التي تبقى موجودة بعد حذف السيرفر (EC2 instance) المرتبطة بها، أو عناوين IP المرنة (Elastic IPs) غير المربوطة بأي سيرفر.

دليلك العملي للصيد: كيف نكتشف هذه الموارد؟

طيب يا أبو عمر، حكيتلنا المشكلة، أعطينا الحل. الصيد يحتاج لأدوات واستراتيجية. خلونا نبدأ خطوة بخطوة.

الخطوة الأولى: الفحص اليدوي باستخدام AWS Console

هذه هي البداية، مثل المشي في الغابة للبحث عن الآثار. يجب أن تعرف أين تبحث. ركز على هذه الخدمات بشكل خاص:

• EC2 Instances: هل هناك أي سيرفرات تعمل دون أن تعرف ما هو دورها؟ انظر إلى استخدام الـ CPU. إذا كان أقل من 5% لأسابيع، فهذا مرشح قوي ليكون “زومبي”.
• EBS Volumes: هذه من أشهر المخابئ. اذهب إلى قسم EBS في لوحة تحكم EC2، وقم بفلترة الأقراص حسب الحالة “Available”. أي قرص في هذه الحالة يعني أنه غير مربوط بأي سيرفر، وأنت تدفع ثمنه شهرياً بلا فائدة.
• Elastic IPs: هل تعلم أن AWS تفرض عليك رسوماً على عناوين IP المرنة إذا لم تكن مربوطة بسيرفر قيد التشغيل؟ اذهب إلى قسم Elastic IPs وتأكد من أن جميعها مرتبط.
• RDS Databases: قواعد البيانات، خاصة في بيئات التطوير، غالباً ما تُنسى. تحقق من وجود أي قواعد بيانات لا يتم استخدامها.
• Load Balancers (ELB): موازنات التحميل التي لا توزع التركة على أي سيرفر هي هدر خالص للمال.
• S3 Buckets: قد لا تكون “زومبي” بالمعنى الحرفي، ولكن تحقق من وجود بيانات قديمة يمكنك أرشفتها (باستخدام S3 Glacier) أو حذفها.

نصيحة من أبو عمر: ابدأ بالأسهل والأكثر شيوعاً: أقراص EBS غير المرفقة. ستتفاجأ من عددها في الحسابات الكبيرة. هذا انتصار سريع وسهل يرفع معنوياتك.

الخطوة الثانية: استخدام أدوات AWS المدمجة

الفحص اليدوي جيد، لكنه غير كافٍ للحسابات الكبيرة. هنا يأتي دور الأدوات الذكية التي توفرها AWS.

أداة AWS Cost Explorer

هذه الأداة هي المحقق المالي الخاص بك. تسمح لك بتحليل فواتيرك بشكل تفصيلي. استخدمها لـ:

• تجميع التكاليف حسب الخدمة: ستكتشف بسرعة أي الخدمات تستهلك معظم ميزانيتك (هل هي EC2؟ أم RDS؟).
• تصفية التكاليف حسب الوسوم (Tags): سنتحدث عن الوسوم لاحقاً، ولكن إذا كنت تستخدمها، يمكنك معرفة تكلفة كل مشروع أو كل فريق على حدة.
• تتبع التكاليف مع مرور الوقت: يمكنك اكتشاف الارتفاعات المفاجئة في التكلفة، والتي قد تشير إلى مورد “زومبي” تم إنشاؤه حديثاً.

أداة AWS Trusted Advisor

هذه الأداة هي صديقك الناصح. تقدم لك توصيات في خمسة مجالات، أهمها بالنسبة لنا هو “تحسين التكلفة” (Cost Optimization). ستخبرك بشكل مباشر عن:

• سيرفرات EC2 الخاملة (Idle EC2 Instances).
• أقراص EBS غير المرفقة (Unattached EBS Volumes).
• موازنات تحميل خاملة (Idle Load Balancers).
• وغيرها الكثير من التوصيات الذهبية.

تفقد هذه الأداة أسبوعياً على الأقل. إنها منجم ذهب لتوفير التكاليف.

الخطوة الثالثة: الأتمتة والبرمجة (صيد احترافي)

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

هنا مثال بسيط باستخدام Python ومكتبة boto3 للبحث عن أقراص EBS غير المرفقة في منطقة معينة:

import boto3

# اختر المنطقة التي تريد البحث فيها
# You can loop through all regions to make it comprehensive
REGION = 'us-east-1'

def find_unattached_ebs_volumes(region):
    """
    Finds and lists all EBS volumes with the state 'available' (unattached).
    """
    ec2 = boto3.client('ec2', region_name=region)
    
    # استخدم الفلتر للبحث عن الأقراص المتاحة (غير المرفقة)
    volumes = ec2.describe_volumes(
        Filters=[
            {
                'Name': 'status',
                'Values': ['available']
            }
        ]
    )
    
    if not volumes['Volumes']:
        print(f"[{region}] لا يوجد أقراص منسية (EBS Zombies). عمل رائع!")
        return

    print(f"--- [{region}] تم العثور على أقراص منسية! ---")
    for vol in volumes['Volumes']:
        print(
            f"  - ID: {vol['VolumeId']}, "
            f"Size: {vol['Size']}GB, "
            f"Created: {vol['CreateTime'].strftime('%Y-%m-%d')}"
        )

if __name__ == '__main__':
    print("بدء عملية البحث عن أقراص EBS المنسية...")
    find_unattached_ebs_volumes(REGION)

يمكنك تطوير هذا السكربت ليبحث عن سيرفرات ذات استخدام منخفض للمعالج، أو تشغيله بشكل دوري باستخدام AWS Lambda وإرسال النتائج عبر البريد الإلكتروني.

القضاء على الزومبيز: استراتيجيات المنع والتنظيف

الاكتشاف نصف المعركة، لكن النصف الآخر هو المنع والتنظيف المستمر. لا فائدة من تنظيف البيت إذا كان الجميع يرمي الأوساخ في كل مكان.

سياسة “التاج” (Tagging Policy) هي الأساس

زي ما بنحكي، “المال السايب بعلّم السرقة”. والموارد بدون “تاج” بتعلم النسيان. الـ Tag أو الوسم هو مجرد ملصق تضعه على أي مورد تقوم بإنشائه. هذا الملصق يجب أن يحتوي على معلومات أساسية. أنصح باستخدام هذه الوسوم كحد أدنى:

• Owner: من هو الشخص المسؤول عن هذا المورد؟ (مثال: abu.omar@example.com)
• Project: لأي مشروع يتبع هذا المورد؟ (مثال: ai-chatbot-poc)
• Environment: هل هو للإنتاج أم للتطوير؟ (مثال: dev, staging, prod)
• ExpiryDate: متى يجب مراجعة أو حذف هذا المورد؟ (مثال: 2024-12-31)

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

بناء ثقافة الـ FinOps (المسؤولية المالية التقنية)

التكنولوجيا وحدها لا تكفي. يجب بناء ثقافة داخل الفريق أو الشركة حيث يكون الجميع مسؤولاً عن التكاليف. هذا ما يسمى بـ FinOps (Financial Operations).

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

خلاصة أبو عمر ونصيحة أخيرة 💡

التعامل مع “الزومبيز” السحابية ليس مهمة تقوم بها مرة واحدة وتنتهي، بل هي عملية مستمرة من اليقظة والتنظيم. تذكر هذه الخطوات:

1. اكتشف: استخدم لوحة التحكم، و Trusted Advisor، والسكربتات للعثور على الموارد المنسية.
2. وّسم (Tag): طبق سياسة وسوم صارمة على كل مورد جديد. لا تتهاون في هذا الأمر أبداً.
3. أتمِت: استخدم سكربتات وخدمات Lambda لإيقاف موارد التطوير ليلاً وحذف الموارد منتهية الصلاحية تلقائياً.
4. ثقّف: انشر ثقافة المسؤولية المالية (FinOps) في فريقك. الشفافية هي مفتاح النجاح.

لا تدع فاتورة السحابة تفاجئك مرة أخرى. كن أنت الصياد، لا الفريسة. بقليل من التنظيم والأتمتة، يمكنك تحويل حساب AWS الخاص بك من غابة موحشة مليئة بالزومبيز إلى حديقة منظمة وموفرة. بالتوفيق يا جماعة الخير!