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

السلام عليكم يا جماعة، معكم أخوكم أبو عمر.

بتذكر هذيك الأيام زي كأنها مبارح. كنا شغالين على مشروع جديد، والحماس “واصل للسما”. انتقلنا للحوسبة السحابية، وصرنا نحكي بلغة الـ “Scale on demand” والـ “Agility”. يا زلمة، الشعور كان خرافي، بكبسة زر بتجيب سيرفر بمواصفات “طيارة”، وبكبسة ثانية بتشغّل قاعدة بيانات موزعة على ثلاث قارات. كنا حاسين حالنا “ملوك العالم الرقمي”.

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

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

ما هي الـ FinOps بالضبط؟ وليش مش مجرد “توفير مصاري”؟

في البداية، فكرنا إنها مجرد كلمة “فخمة” معناها “طَفّي اللي ما بتستخدمه”. لكن الموضوع أعمق من هيك بكثير. الـ FinOps هي ثقافة وممارسة بتهدف لجلب المسؤولية المالية لعالم الحوسبة السحابية. هي الجسر اللي بيربط بين فريق المالية (Finance)، وفريق العمليات (Operations)، وفريق المطورين (Developers).

الفكرة بسيطة: لازم كل دولار بنصرفه على السحابة يكون له قيمة مقابلة. بطل ينفع المطور يرمي الكود على السيرفر ويحكي “مش شغلي قديش بكلف”، وبطل ينفع رجل المالية يشوف الفاتورة آخر الشهر وينصدم. الـ FinOps بتخلي التكلفة مقياس أساسي للنجاح، تمامًا مثل الأداء (Performance) والأمان (Security).

مراحل رحلتنا العملية مع الـ FinOps

رحلتنا ما كانت سهلة، وكانت فيها تخبيص كثير بالبداية. عشان أسهل عليكم الطريق، رح ألخص لكم إياها في ثلاث مراحل أساسية، وهي نفس المراحل اللي بتمر فيها أي منظمة بتبني هاي الثقافة.

المرحلة الأولى: الفهم والشفافية (Inform) – “وين بتروح المصاري؟”

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

  • الوسوم (Tagging)، ثم الوسوم، ثم الوسوم: هاي أهم نصيحة ممكن أعطيكم إياها. اتفقنا على سياسة واضحة لوضع وسوم (Tags) على كل مورد (Resource) بنشغّله على السحابة. الوسوم الأساسية كانت:
    • Project: اسم المشروع (e.g., project-alpha)
    • Environment: بيئة العمل (e.g., production, staging, dev)
    • Owner: اسم الشخص أو الفريق المسؤول (e.g., abu-omar, backend-team)
  • استخدام أدوات تحليل التكاليف: كل مزود خدمة سحابية عنده أدوات ممتازة. احنا استخدمنا AWS Cost Explorer. بعد ما طبقنا سياسة الوسوم، صرنا نقدر نفلتر التكاليف ونشوف بالضبط:
    • كم تكلفة بيئة التطوير (Staging Environment)؟
    • كم صرف فريق الـ Backend هالشهر؟
    • شو أكثر خدمة بتكلفنا في المشروع الفلاني؟

فجأة، الصورة صارت واضحة. الرقم الكبير المخيف تحول لمجموعة أرقام صغيرة مفهومة وممكن نتعامل معها.

المرحلة الثانية: التحسين والترشيد (Optimize) – “كيف نوفر بدون ما نأثر على الشغل؟”

بعد ما عرفنا وين بتروح المصاري، إجا وقت “الشغل الجد”. هون بدأنا نبحث عن فرص التوفير الحقيقية. وهذه بعض الإجراءات اللي عملناها وكان تأثيرها فوري:

1. تقليص حجم الموارد (Right-Sizing)

اكتشفنا إننا “مبذرين”. كنا حاجزين سيرفرات بمواصفات عالية (e.g., 16 vCPU, 64GB RAM) عشان تشغل خدمة بسيطة استهلاكها ما بيوصل 5%. ببساطة، كنا جايبين باص لنوصل فيه راكب واحد. بدأنا نراقب استهلاك الـ CPU والـ Memory بشكل فعلي، ونقلص حجم الـ Instances للمواصفات اللي بتحتاجها فعلًا. هاي لحالها وفرت لنا حوالي 30% من الفاتورة.

2. إطفاء الموارد غير المستخدمة

بيئة التطوير والاختبار (Dev/Test Environments) ما في داعي تضل شغالة 24/7، خصوصًا في الويكند. عملنا سكريبت بسيط (Lambda function على AWS) بيشتغل بشكل مجدول (Cron Job) وبيطفي كل السيرفرات اللي عليها وسم Environment: dev الساعة 7 المسا، وبرجع بشغلها الساعة 8 الصبح. هاي حركة بسيطة لكن وفرت علينا أكثر من 60% من تكلفة بيئات التطوير.

نصيحة من أبو عمر: لا تخاف تطفّي! السحابة مرنة، واللي بتطفيه اليوم بتقدر تشغله بكرة بكبسة زر.

3. استخدام نماذج التسعير الذكية

السحابة مش بس “Pay-as-you-go”. في نماذج تسعير بتوفر كثير لو عرفت تستخدمها صح:

  • Reserved Instances / Savings Plans: للسيرفرات وقواعد البيانات اللي بنعرف إنها رح تضل شغالة لمدة سنة أو ثلاث سنوات (زي بيئة الإنتاج). حجزنا هاي الموارد مسبقًا وحصلنا على خصم وصل لـ 60% مقارنة بالسعر العادي.
  • Spot Instances: للمهام اللي ما بتتأثر لو توقفت فجأة ورجعت اشتغلت (Batch processing, data analysis). هاي السيرفرات هي عبارة عن طاقة حوسبية فائضة عند مزود الخدمة، وسعرها أرخص بنسبة تصل لـ 90%! نعم، 90%. استخدمناها بكثافة في عمليات تدريب نماذج الذكاء الاصطناعي ووفرنا آلاف الدولارات.

# مثال بسيط على طلب Spot Instance باستخدام AWS CLI
# لاحظ كيف نحدد أقصى سعر مستعدين ندفعه
aws ec2 request-spot-instances 
    --spot-price "0.05" 
    --instance-count 1 
    --type "one-time" 
    --launch-specification file://specification.json

المرحلة الثالثة: التشغيل والأتمتة (Operate) – “خلينا نحول التوفير لعادة”

بعد فترة، صار التحسين اليدوي متعب. كان لازم نحول هاي الممارسات لعمليات مؤتمتة وجزء من ثقافتنا اليومية. هون انتقلنا للمرحلة الثالثة والأهم:

  • وضع الميزانيات والتنبيهات (Budgets and Alerts): في كل منصة سحابية، بتقدر تحدد ميزانية لكل مشروع أو فريق. عملنا تنبيهات بتوصلنا على Slack لما نوصل لـ 50%، 80%، و 100% من الميزانية الشهرية. هيك صرنا نتصرف قبل ما المصيبة تصير، مش بعدها.
  • فرض السياسات (Policy Enforcement): عشان نضمن إنه ما حدا يرجع “يخبص”، عملنا سياسات مؤتمتة. مثلًا، عملنا سياسة بتمنع تشغيل أي سيرفر جديد بدون ما يكون عليه الوسوم (Tags) الإجبارية اللي اتفقنا عليها.
  • دمج التكلفة في دورة حياة التطوير (CI/CD): هاي كانت خطوة متقدمة بس “إشي مرتب”. صرنا نستخدم أدوات مثل Infracost اللي بتعطيك تقدير لتكلفة التغييرات في البنية التحتية (Infrastructure as Code) قبل ما تعملها deploy. يعني المطور وهو بيكتب الكود، بيشوف رسالة في الـ Pull Request بتحكيله: “انتبه، هذا التغيير رح يرفع الفاتورة الشهرية بمقدار 200$”. هذا غيّر طريقة تفكير المطورين تمامًا.

خلاصة رحلتنا ونصيحة أخيرة 🧭

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

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

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

تذكر دائمًا، السحابة أداة جبارة، والـ FinOps هي كتالوج الاستخدام اللي بيضمن لك إنك تستخدمها بأفضل طريقة ممكنة بدون ما “تحرق جيبتك”.

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

التوظيف وبناء الهوية التقنية

كانت مهاراتي سجينة السيرة الذاتية: كيف أنقذني ‘ملف الإثبات’ من جحيم المشاريع التجريبية

بصفتي أبو عمر، مبرمج فلسطيني، أشارككم قصتي مع المشاريع التجريبية التي لا تعود، وكيف أن بناء "ملف إثبات" (Portfolio of Proof) حقيقي كان طوق النجاة...

7 مايو، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

كانت خوادمنا تغرق تحت الضغط: كيف أنقذتنا ‘موازنة الأحمال’ (Load Balancing) من جحيم النقاط الساخنة؟

في ليلة إطلاق حاسمة، كادت خوادمنا أن تنهار تحت ضغط المستخدمين. أشارككم قصة كيف أنقذتنا تقنية "موازنة الأحمال" من كارثة محققة، وأغوص معكم في تفاصيلها...

7 مايو، 2026 قراءة المزيد
التكنلوجيا المالية Fintech

كانت بياناتنا المالية سجينة: كيف حررتنا واجهات ‘الصيرفة المفتوحة’ من جحيم الصوامع المنعزلة؟

بصفتي أبو عمر، مبرمج فلسطيني، أروي لكم كيف عانينا من سجون البيانات البنكية المنعزلة. سنغوص في عالم "الصيرفة المفتوحة" (Open Banking) لنكتشف كيف حررت واجهات...

7 مايو، 2026 قراءة المزيد
البنية التحتية وإدارة السيرفرات

كانت بنيتنا التحتية قصراً من رمال: كيف أنقذتنا ‘الشيفرة كبنية تحتية’ (IaC) من جحيم التضارب بين البيئات؟

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

7 مايو، 2026 قراءة المزيد
ادارة الفرق والتنمية البشرية

كانت الأخطاء تُدفن حية: كيف أنقذتنا “السلامة النفسية” من جحيم الفشل الصامت؟

في عالم البرمجة، ليست الأخطاء البرمجية هي ما يقتل المشاريع، بل الأخطاء التي نخشى الاعتراف بها. من خلال قصة حقيقية، نغوص في مفهوم "السلامة النفسية"...

7 مايو، 2026 قراءة المزيد
البودكاست