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

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

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

ظلّينا طايرين لحد ما خبطنا في الحيط. وصلني إيميل من المدير المالي، عنوانه بس “اجتماع عاجل”، وبالعادة هاي العناوين ما بتبشر بالخير. دخلت الاجتماع، وكان وجهه ما بتفسر. فتح الـ Excel Sheet على الشاشة الكبيرة، وإذا برقم ضخم، أكبر من فاتورتنا المتوقعة بثلاث أضعاف! سألني سؤال واحد بسيط ومباشر: “أبو عمر، شو هاد؟”.

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

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

لماذا كانت فاتورتنا السحابية صندوقاً أسود؟

مشكلتنا ما كانت فريدة من نوعها، هي مشكلة بتواجهها أغلب الشركات اللي بتنتقل للسحابة بدون تخطيط مالي. نموذج الدفع حسب الاستخدام (Pay-as-you-go) هو سيف ذو حدين. بيعطيك مرونة هائلة، لكنه كمان بيفتح الباب على مصراعيه للإنفاق غير المنضبط. الأسباب الرئيسية اللي حولت فاتورتنا لصندوق أسود كانت:

• غياب الرؤية (Lack of Visibility): ما كنا بنعرف مين بيستخدم إيش ولأي غرض. الفاتورة كانت مجرد أرقام بدون سياق.
• الإنفاق اللامركزي: أي مطور عنده صلاحيات كان بيقدر يشغّل أي خدمة بأي حجم، بدون أي موافقة مالية أو رقابة.
• انعدام المسؤولية: عقلية “هاي مش مصاري أبوي” كانت منتشرة. المطور بيركز على إنجاز مهمته التقنية، والتكلفة هي آخر همّه.
• التعقيد الهائل: خدمات السحابة متنوعة ومعقدة، وطرق حساب تكلفتها مختلفة ومحيرة أحياناً.

المنقذ الذي لم نكن نعلم أننا بحاجته: ثقافة الـ FinOps

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

ما هو الـ FinOps بالضبط؟

من الآخر، الـ FinOps هو مش أداة، هو ثقافة وممارسة تنظيمية. هو عبارة عن جسر بين أقسام التكنولوجيا (Dev/Ops) وقسم المالية (Finance)، عشان الكل يحكي نفس اللغة ويتعاونوا مع بعض لإدارة الإنفاق السحابي. الهدف مش إنك “تشد الحزام” وتمنع الصرف، لأ، الهدف هو تحقيق أقصى قيمة ممكنة من كل دولار بتصرفه على السحابة. يعني، بدل ما نركز على تقليل التكلفة وبس، صرنا نركز على كفاءة الإنفاق.

الـ FinOps بيقوم على مبدأ بسيط: الفريق اللي بيستهلك الموارد السحابية لازم يكون مسؤول عن تكلفتها، ولازم يكون عنده البيانات والأدوات اللي بتخليه ياخد قرارات ذكية.

الأركان الثلاثة لدورة حياة الـ FinOps

عشان نفهم الموضوع بشكل عملي، الـ FinOps بيمر بدورة حياة مستمرة من ثلاث مراحل:

1. الإعلام (Inform): مرحلة كشف المستور. هون هدفنا نحقق رؤية كاملة وواضحة على الإنفاق. مين بيصرف، على شو، ومتى، وليش.
2. التحسين (Optimize): بعد ما فهمنا وين بتروح المصاري، بنبدأ ندور على فرص للتوفير والتحسين. مثل إغلاق الموارد غير المستخدمة، أو اختيار الحجم المناسب للسيرفرات.
3. التشغيل (Operate): هاي مرحلة الأتمتة وبناء العادات. هون بنحول الإجراءات اللي تعلمناها في المرحلتين السابقتين إلى عمليات مستمرة وتلقائية.

كيف طبقنا ثقافة الـ FinOps خطوة بخطوة؟ (من أرض المعركة)

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

المرحلة الأولى: الإعلام (Inform) – أهمية الوسوم (Tags)

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

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

اعتمدنا استراتيجية وسوم بسيطة وموحدة للجميع، كبداية:

• owner: إيميل الشخص المسؤول عن المورد.
• project: اسم المشروع اللي بيستخدم المورد.
• environment: بيئة العمل (e.g., production, staging, development).
• cost-center: مركز التكلفة التابع له المشروع.

للتأكد من الالتزام، استخدمنا سياسات تلقائية (Policies) بتمنع إنشاء أي مورد جديد بدون هاي الوسوم الأساسية. مثلاً في AWS، يمكن استخدام Service Control Policies (SCPs)، وفي Terraform يمكن فرضها مباشرة في الكود.

# مثال في Terraform لفرض وجود وسم "owner"
variable "owner_tag" {
  type        = string
  description = "The email of the resource owner."
}

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name    = "MyWebServer"
    owner   = var.owner_tag # فرض وجود الوسم عند التنفيذ
    project = "Website-Revamp"
  }
}

بعد تطبيق الوسوم، صارت الفاتورة فجأة مفهومة! صرنا نقدر نعمل فلترة ونشوف تكلفة كل مشروع، وكل مطور، وكل بيئة عمل على حدة. الصندوق الأسود بدأ يتلاشى.

المرحلة الثانية: التحسين (Optimize) – شد الحزام بذكاء

بعد ما صارت عنا رؤية واضحة، بدأنا مرحلة الصيد! البحث عن فرص التوفير.

• الموارد الخاملة (Idle Resources): هاي كانت أسهل وأسرع طريقة للتوفير. كتبنا سكربت بسيط بلغة Python (باستخدام مكتبة Boto3 لـ AWS) بيبحث عن السيرفرات (EC2 instances) اللي استهلاك المعالج (CPU) تبعها أقل من 5% على مدار أسبوعين، والسيرفرات اللي ما حدا بيعمل عليها login. وكمان بيبحث عن أقراص التخزين (EBS volumes) اللي مش مرتبطة بأي سيرفر. كل هاي كانت مصاريف على الفاضي.
• تقليص الحجم (Rightsizing): اكتشفنا إننا بنستخدم “شاحنة لنقل علبة بيتزا”. كثير من السيرفرات كانت أكبر بكثير من حاجتها (Over-provisioned). بدأنا نراقب أداء التطبيقات ونختار حجم السيرفر المناسب بالضبط للحمل اللي عليه. هاي الخطوة وفرت علينا ما يقارب 30% من تكلفة السيرفرات.
• الحجز المسبق (Reservations): للحمل الثابت اللي بنعرف إنه رح يضل شغال سنة أو ثلاث سنوات (زي سيرفرات الـ production الرئيسية)، انتقلنا من نموذج الدفع حسب الاستخدام إلى نموذج الحجز المسبق (Reserved Instances) أو خطط التوفير (Savings Plans). هذا القرار لوحده وفر لنا ما بين 40% إلى 60% من تكلفة هاي الموارد.
• جدولة التشغيل والإيقاف (Scheduling): سيرفرات بيئة التطوير والتجربة ما في داعي تضل شغالة 24/7. عملنا أتمتة بسيطة بتطفي كل هاي السيرفرات الساعة 7 مساءً وبتشغلها الساعة 8 صباحاً، وبتطفيها بالكامل في عطلة نهاية الأسبوع. التوفير كان هائل!

المرحلة الثالثة: التشغيل (Operate) – الأتمتة هي سر الديمومة

عشان ما نرجع لنفس المشكلة، كان لازم نحول هاي الممارسات لعمليات مستمرة ومؤتمتة.

• لوحات معلومات (Dashboards): أنشأنا لوحات معلومات حية (Live Dashboards) باستخدام أدوات مثل Grafana أو أدوات الكلاود نفسها (CloudWatch/Cost Explorer). هاي اللوحات بتعرض التكلفة بشكل مباشر ومقسم حسب المشروع والفريق، وصارت مرئية للجميع، من المطورين للمدراء. الشفافية خلقت وعي بالمسؤولية.
• تنبيهات الميزانية (Budget Alerts): قمنا بإعداد تنبيهات تلقائية. مثلاً، إذا تكلفة مشروع معين تجاوزت 80% من ميزانيته الشهرية، بيوصل إيميل تلقائي لمدير المشروع وفريق العمل.
• دمج التكلفة في الـ CI/CD: هاي كانت خطوة متقدمة. استخدمنا أدوات مثل infracost اللي بتتكامل مع الـ Pull Requests. الآن، لما مطور يعمل تغيير على البنية التحتية (Infrastructure as Code)، بتظهر له تعليق تلقائي بيقول: “هذا التغيير سيزيد التكلفة الشهرية بـ 200 دولار”. هذا أعطى المطورين القدرة على رؤية الأثر المالي لقراراتهم التقنية قبل ما يتم تطبيقها.

أكثر من مجرد أدوات: FinOps هو تغيير في العقلية

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

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

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

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

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

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

تذكر دائماً، الـ FinOps ليست وجهة تصل إليها، بل هي رحلة مستمرة من التحسين والتعاون. بالتوفيق في رحلتكم!