كانت فاتورة السحابة تلتهم ميزانيتنا: كيف أنقذتنا ‘ممارسات FinOps’ من جحيم الإنفاق غير المراقب؟

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

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

في تلك اللحظة، أدركت أن حماسنا التقني غير المراقب كان يقودنا إلى حافة الهاوية المالية. لم يكن الحل هو التوقف عن استخدام السحابة، فهي عصب شغلنا، بل كان علينا أن نتعلم كيف “نترجم” كل نقرة وكل سطر كود إلى تكلفة بالدولار. من رحم تلك الأزمة، بدأت رحلتي، ورحلة فريقي، مع عالم الـ FinOps. وهذه هي قصتنا وخلاصة تجربتنا.

ما هي الـ FinOps؟ ليست مجرد “تخفيض تكاليف”

للوهلة الأولى، قد تظن أن FinOps (وهي اختصار لـ Financial Operations) هي مجرد مصطلح جديد لـ “إدارة التكاليف”. لكنها أعمق من ذلك بكثير. إنها ثقافة، ومنهجية عمل تجمع بين أقسام المالية (Finance)، والعمليات التقنية (Operations)، والمطورين (Engineering) تحت سقف واحد. الهدف ليس فقط خفض الفاتورة، بل تحقيق أقصى قيمة ممكنة من كل دولار يُصرف على السحابة.

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

نصيحة أبو عمر: لا تنظر للـ FinOps على أنها قيد، بل انظر إليها على أنها أداة تمكين. عندما تفهم تكاليفك، يمكنك اتخاذ قرارات هندسية أفضل، وتبرير الاستثمارات التقنية للإدارة العليا بلغة الأرقام التي يفهمونها.

المرحلة الأولى: “الإنارة” (Inform) – افهم أين تذهب أموالك

كانت خطوتنا الأولى هي الخروج من الظلام. لا يمكنك إصلاح ما لا تراه. كانت فاتورتنا مجرد رقم ضخم وغامض. كان علينا تشريح هذا الرقم لنعرف بالضبط أين يذهب كل قرش.

أهمية التصنيف والتوسيم (Tagging and Labeling)

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

وضعنا سياسة صارمة وفورية للتوسيم. أي مورد جديد يجب أن يحمل الوسوم التالية على الأقل:

• project: اسم المشروع الذي يخدمه المورد (e.g., project-alpha, project-beta).
• environment: بيئة العمل (e.g., production, staging, development).
• team: الفريق المسؤول عن المورد (e.g., backend-team, data-science-team).
• cost-center: مركز التكلفة المالي المرتبط به.

بعد تطبيق هذه السياسة، تغيرت الصورة تماماً. باستخدام أدوات إدارة التكاليف المدمجة في المنصات السحابية (مثل AWS Cost Explorer أو Azure Cost Management)، استطعنا أخيراً الإجابة على أسئلة حيوية:

• كم يكلفنا تشغيل بيئة التطوير (Development Environment) شهرياً؟
• ما هو المشروع الأكثر استهلاكاً للموارد؟
• من هو الفريق الذي تسبب في الارتفاع المفاجئ للفاتورة هذا الشهر؟

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

المرحلة الثانية: “التحسين” (Optimize) – اعصر كل قرش

بعد أن فهمنا أين تذهب أموالنا، حان وقت العمل الجاد. مرحلة التحسين هي المكان الذي تحدث فيه السحر الحقيقي وتظهر الوفورات الكبيرة.

تحديد الموارد المهملة واليتيمة (Orphaned & Idle Resources)

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

• وحدات التخزين غير المرفقة (Unattached EBS Volumes): أقراص صلبة افتراضية لا تستخدمها أي آلة.
• عناوين IP المرنة غير المستخدمة (Unused Elastic IPs): تدفع عليها رسوماً طالما أنها غير مرتبطة بمورد قيد التشغيل.
• اللقطات القديمة (Old Snapshots): نسخ احتياطية من قواعد بيانات أو أقراص لم تعد هناك حاجة لها.

يمكنك استخدام سكربتات بسيطة للعثور على هذه الموارد. على سبيل المثال، هذا الأمر البسيط باستخدام AWS CLI يمكن أن يجد لك كل وحدات التخزين غير المرفقة:

# مثال بسيط باستخدام AWS CLI للعثور على وحدات تخزين EBS "المتاحة" (أي غير مرفقة)
aws ec2 describe-volumes --filters Name=status,Values=available --query "Volumes[].VolumeId"

بمجرد العثور عليها، تحقق منها ثم احذفها بلا رحمة. لقد وفرنا مئات الدولارات شهرياً من هذه الخطوة وحدها.

الحجم المناسب (Right-Sizing)

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

بدأنا نستخدم أدوات المراقبة (like CloudWatch) لتحليل استخدام وحدة المعالجة المركزية (CPU) والذاكرة (Memory) للسيرفرات على مدار أسبوعين. النتائج كانت صادمة. وجدنا سيرفرات ضخمة تعمل بمعدل استخدام 5-10% فقط! قمنا بتقليص حجمها (Downsizing) من `m5.2xlarge` إلى `m5.large` على سبيل المثال، وحققنا وفراً فورياً بنسبة 75% من تكلفة ذلك السيرفر.

نصيحة أبو عمر: اجعل مراجعة حجم الموارد عملية دورية (كل 3 أشهر مثلاً). احتياجات التطبيق تتغير، وما كان مناسباً اليوم قد يكون مبالغاً فيه غداً.

استغلال نماذج التسعير الذكية

لا تدفع السعر الكامل (On-Demand) لكل شيء. مقدمو الخدمات السحابية يقدمون خصومات هائلة لمن يخطط مسبقاً:

• الحالات المحجوزة (Reserved Instances – RIs) وخطط التوفير (Savings Plans): إذا كنت تعلم أنك ستحتاج إلى سيرفر أو قاعدة بيانات معينة لمدة سنة أو ثلاث سنوات، يمكنك حجزها مسبقاً مقابل خصم يصل إلى 70%. استخدمنا هذا لخوادم الإنتاج (Production) التي نعرف أنها ستعمل 24/7.
• الحالات الفورية (Spot Instances): هذه هي الجوهرة الخفية. يمكنك الحصول على السعة الحاسوبية الفائضة لدى مزود السحابة بخصم يصل إلى 90%! لكن هناك شرط: يمكن للمزود أن يسحب منك هذه السعة في أي وقت. هي مثالية للمهام التي يمكن مقاطعتها وإعادتها لاحقاً، مثل أعمال المعالجة الدفعية (Batch processing)، أو مهام الـ CI/CD، أو حتى تشغيل بيئات الاختبار.

المرحلة الثالثة: “التشغيل” (Operate) – اجعلها ثقافة مستدامة

الـ FinOps ليست مشروعاً له بداية ونهاية، بل هي عملية مستمرة ودورة حياة متكررة. بعد أن نظفنا بيئتنا وحسنّاها، كان التحدي هو الحفاظ على هذا المستوى من الكفاءة.

الأتمتة هي المفتاح (Automation is Key)

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

• إيقاف وتشغيل بيئات التطوير: أنشأنا وظيفة مؤتمتة (Lambda function) تعمل كل يوم في الساعة 7 مساءً لتقوم بإيقاف جميع الموارد التي تحمل وسم `environment: dev`، ووظيفة أخرى تعيد تشغيلها في الساعة 8 صباحاً. هذا وحده خفض تكاليف بيئة التطوير بنسبة تزيد عن 60%.

هذا مثال بسيط جداً لكود بايثون لوظيفة Lambda يمكنها القيام بذلك:

# مثال مبسط بلغة بايثون (باستخدام مكتبة Boto3 لـ AWS) لإيقاف الأجهزة
import boto3

# حدد المنطقة التي تعمل بها
REGION = 'eu-west-1' 

def lambda_handler(event, context):
    ec2 = boto3.client('ec2', region_name=REGION)
    
    # ابحث عن كل الأجهزة التي تحمل الوسم المطلوب وحالتها "قيد التشغيل"
    instances = ec2.describe_instances(
        Filters=[
            {'Name': 'tag:environment', 'Values': ['development', 'staging']},
            {'Name': 'instance-state-name', 'Values': ['running']}
        ]
    )
    
    instance_ids_to_stop = []
    # استخراج معرفات الأجهزة من الرد
    for reservation in instances['Reservations']:
        for instance in reservation['Instances']:
            instance_ids_to_stop.append(instance['InstanceId'])
            
    if instance_ids_to_stop:
        print(f"Found instances to stop: {instance_ids_to_stop}")
        ec2.stop_instances(InstanceIds=instance_ids_to_stop)
        print("Successfully sent stop command.")
    else:
        print("No running instances with specified tags found.")
        
    return {'statusCode': 200, 'body': 'Process finished.'}

تمكين الفرق وخلق المسؤولية

التغيير الأكبر حدث عندما توقفنا عن إرسال فاتورة واحدة ضخمة للجميع، وبدأنا بتزويد كل فريق بلوحة تحكم (Dashboard) خاصة به تُظهر تكاليفه بشكل واضح ومباشر.

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

الخلاصة: من الفوضى إلى السيطرة 👍

رحلتنا مع الـ FinOps لم تكن سهلة، تطلبت تغييرات في الأدوات، العمليات، والأهم من ذلك، العقلية. لكن النتائج كانت مذهلة. لم نوفر آلاف الدولارات شهرياً فحسب، بل أصبحنا فريقاً أكثر نضجاً وكفاءة. أصبحنا نتحدث لغة مشتركة مع الإدارة المالية، ونبني منتجات أفضل وأكثر استدامة.

إذا كنت تشعر أن فاتورة السحابة تخرج عن السيطرة، لا تيأس. أنت لست وحدك. الحل موجود ويتلخص في ثلاث كلمات: Inform, Optimize, Operate.

نصيحتي الأخيرة لك: ابدأ بالشيء البسيط. ابدأ اليوم. لا تنتظر الفاتورة الكارثية القادمة. اذهب الآن واجتمع مع فريقك، واتفقوا على سياسة توسيم (Tagging) موحدة. هذه هي الخطوة الأولى والأهم في رحلتكم نحو السيطرة على سحابتكم. خطوة خطوة، يا جماعة. وبالتوفيق!