كيف تخفض فاتورة الحوسبة السحابية: 10 ممارسات مجربة

المدير المالي أرسل رسالة قصيرة: «فاتورة السحابة زادت 40% عن الربع الماضي، والمبيعات لم تزد بالنسبة نفسها. ما الذي يحدث؟». الفريق التقني يعرف أن هناك خوادم تجريبية لم تُطفأ، لكن أحداً لا يعرف كم تكلف تحديداً ولا من المسؤول عنها.

هذا المشهد شائع جداً، والخبر الجيد أن خفض تكاليف السحابة لا يحتاج غالباً إلى إعادة بناء النظام. معظم الهدر يأتي من موارد منسية، ومواصفات أكبر من الحاجة، وغياب الالتزام بالخصومات المتاحة. في هذا المقال عشر ممارسات عملية تنطبق على AWS وAzure وGoogle Cloud، مرتبة من الأسهل إلى الأعمق.

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

لماذا ترتفع فاتورة السحابة دون أن تلاحظ؟

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

• بيئات تطوير واختبار تعمل على مدار الساعة رغم أن الفريق يعمل ثماني ساعات يومياً.
• خوادم وقواعد بيانات اختيرت بمواصفات كبيرة «احتياطاً» ولم تُراجع.
• أقراص ولقطات (Snapshots) وعناوين IP بقيت بعد حذف الخادم المرتبط بها.
• سجلات (Logs) تُحفظ بلا حد زمني، وبيانات قديمة على أغلى فئة تخزين.
• رسوم نقل البيانات الخارجة التي لا يفكر فيها أحد عند التصميم.

الممارستان 1 و2: الرؤية قبل التوفير

1. وسم كل مورد بمالكه ومشروعه

لن تستطيع خفض ما لا تستطيع نسبته لأحد. اعتمد وسوماً (Tags أو Labels) إلزامية لكل مورد: المشروع، والبيئة (إنتاج، اختبار، تطوير)، والفريق المسؤول. بعدها تصبح الفاتورة مقروءة: «مشروع X يكلف كذا، وثلثه بيئة اختبار».

2. ميزانيات وتنبيهات من اليوم الأول

كل مزود يوفر أداة مجانية لذلك: AWS Budgets وCost Explorer، وMicrosoft Cost Management في Azure، والميزانيات والتنبيهات في Google Cloud Billing. ضع ميزانية شهرية لكل مشروع، وتنبيهاً عند 50% و80% و100%، واجعل التنبيه يصل إلى شخص يملك صلاحية التصرف، لا إلى صندوق بريد عام.

من يملك التكلفة؟ مبدأ FinOps باختصار

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

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

الممارستان 3 و4: تخلص من الهدر الواضح

3. احذف الموارد اليتيمة

راجع شهرياً: الأقراص غير المرتبطة بأي خادم، واللقطات القديمة، وعناوين IP العامة المحجوزة دون استخدام، وموازنات الأحمال التي لا تخدم شيئاً. بعض المزودين، ومنهم AWS، يحتسبون رسوماً على عناوين IPv4 العامة، فعنوان منسي واحد لا يكلف كثيراً، لكن العشرات منها تظهر في الفاتورة.

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

4. أطفئ بيئات التطوير خارج ساعات العمل

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

الممارستان 5 و6: الحجم المناسب والمعالج المناسب

5. اضبط الحجم حسب الاستخدام الفعلي (Rightsizing)

خادم يعمل بمتوسط استخدام معالج 10% على مدى شهر هو غالباً أكبر من الحاجة. أدوات التوصية المجانية مثل AWS Compute Optimizer وAzure Advisor وRecommender في Google Cloud تقترح أحجاماً أصغر بناءً على بيانات الاستخدام. نفّذ التوصيات تدريجياً على بيئات غير حرجة أولاً، وراقب الأداء أسبوعاً قبل التعميم.

6. جرّب معالجات ARM

المزودون الثلاثة يقدمون خوادم بمعالجات ARM من تصميمهم: Graviton في AWS، وCobalt في Azure، وAxion في Google Cloud. كثير من التطبيقات المكتوبة بلغات مثل Node.js وPython وJava وGo تعمل عليها دون تعديل يذكر، وغالباً بسعر أقل للأداء نفسه. اختبر تطبيقك أولاً، خصوصاً إن كان يعتمد على مكتبات مترجمة.

الممارستان 7 و8: استفد من الخصومات بذكاء

7. التزم بالحد الأدنى الثابت فقط

Savings Plans وReserved Instances في AWS، والحجوزات وخطط التوفير في Azure، وCommitted Use Discounts في Google Cloud، كلها تمنحك خصماً مقابل الالتزام بإنفاق أو استخدام محدد لسنة أو ثلاث. القاعدة الذهبية: التزم فقط بـالحد الأدنى الذي تستخدمه دائماً، واترك الزيادات الموسمية على الدفع حسب الاستخدام. الالتزام المبالغ فيه يتحول إلى هدر مدفوع مقدماً.

8. استخدم الخوادم القابلة للاسترجاع للأحمال المرنة

خوادم Spot سعة فائضة يبيعها المزود بخصم كبير، وتذكر AWS أن الخصم قد يصل إلى 90% مقارنة بسعر الطلب، لكن المزود يستطيع استرجاعها بإشعار قصير. هي ممتازة لمعالجة الدفعات، وتحويل الفيديو، وبيئات الاختبار، وخطوط التكامل المستمر، وغير مناسبة لقاعدة بيانات الإنتاج الوحيدة.

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

الممارستان 9 و10: التخزين ونقل البيانات

9. انقل البيانات الباردة إلى فئات أرخص

لكل مزود فئات تخزين حسب تكرار الوصول: S3 Intelligent-Tiering وGlacier في AWS، وفئات Cool وCold وArchive في Azure، وNearline وColdline وArchive في Google Cloud. اضبط سياسات دورة الحياة لتنقل الملفات تلقائياً بعد 30 أو 90 يوماً، وحدد مدة احتفاظ للسجلات بدلاً من الاحتفاظ بها للأبد. انتبه إلى رسوم الاسترجاع والحد الأدنى لمدة التخزين في الفئات الأرشيفية.

السجلات تحديداً تستحق وقفة. خدمات المراقبة تحتسب رسوماً على كمية البيانات المستقبَلة وعلى مدة الاحتفاظ بها، وسجلات التصحيح المفصلة (Debug) التي تُركت مفعلة في الإنتاج قد تضاعف هذا البند. حدد مستوى التسجيل المناسب لكل بيئة، واحتفظ بالسجلات التفصيلية أياماً قليلة، وانقل ما تحتاجه للتدقيق إلى تخزين أرشيفي أرخص. وتذكّر أن متطلبات النسخ الاحتياطي تختلف عن الأرشفة، كما نشرح في دليل النسخ الاحتياطي السحابي للشركات.

10. راقب نقل البيانات الخارجة

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

ملخص الممارسات العشر: الجهد مقابل الأثر

خطة 30 يوماً لخفض تكاليف السحابة

1. الأسبوع الأول: فعّل الميزانيات والتنبيهات، وحدد مالكاً لكل حساب أو اشتراك سحابي.
2. الأسبوع الثاني: طبّق الوسوم الإلزامية، واستخرج قائمة بالموارد اليتيمة واحذفها بعد التأكد.
3. الأسبوع الثالث: جدولة إيقاف بيئات التطوير، وتنفيذ توصيات ضبط الحجم على البيئات غير الحرجة.
4. الأسبوع الرابع: راجع الحد الأدنى الثابت للاستخدام، وقرر حجم الالتزام، واضبط سياسات دورة حياة التخزين.
5. بعد ذلك: مراجعة شهرية مدتها ساعة بين التقنية والمالية، مع مقارنة التكلفة بمؤشر عمل مثل التكلفة لكل عميل أو لكل طلب.

الخطوة التالية

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

وإذا كنت ما زلت تختار مزودك، فراجع مقارنة AWS وAzure وGoogle Cloud من زاوية التسعير. وللأحمال المتقطعة، قد يكون نموذج الحوسبة بدون خوادم أوفر من خادم يعمل طوال الوقت. ولا تنس أن موقع المنطقة يؤثر في السعر أيضاً كما شرحنا في مقال مراكز البيانات في الخليج. وللصورة الكاملة ارجع إلى دليل الحوسبة السحابية للشركات العربية.

أسئلة شائعة

ما أسرع طريقة لخفض تكاليف السحابة؟

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

هل أشتري Reserved Instances أم Savings Plans؟

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

هل خوادم Spot آمنة للاستخدام؟

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

كم مرة يجب مراجعة فاتورة السحابة؟

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