سير عمل تحسين تكلفة السحابة (Cloud Cost Optimization / FinOps) — من تفكيك الفاتورة ورصد الهدر إلى ترتيب الفرص حسب التوفير والجهد والمخاطرة، وتطبيق آمن على دفعات مع التحقق من عدم تراجع الأداء وضبط حواجز الميزانية والتنبيهات

سير عمل تنفيذي (runbook) يدير خفض فاتورة السحابة من أولها إلى آخرها بأمان: من تفكيك التكلفة الحالية وتحديد هدف التوفير، مرورًا برصد الهدر وترتيب فرص التوفير حسب أثرها وجهدها ومخاطرتها، ثم تطبيق التحسينات على دفعات صغيرة قابلة للتراجع مع التحقق من عدم تراجع الأداء بعد كل دفعة، وصولًا إلى تثبيت حواجز تمنع عودة الهدر (وسم إلزامي، ميزانيات، تنبيهات، مراجعة دورية للالتزامات). الهدف تحويل قرار «الفاتورة مرتفعة، لِنقلّصها» من قصٍّ عشوائي (إطفاء موارد عشوائيًا أو شراء خصومات دون جرد) إلى عملية مقيسة تُخفّض التكلفة دون كسر الإنتاج، وتُبقي الحكم على كل تغيير مبنيًا على الأرقام لا الحدس. يعالج هذا السير مشكلة شائعة ومكلفة: فاتورة السحابة تتضخّم بصمت عبر موارد نُسيت قيد التشغيل، وأحجام أُفرِط فيها «للاحتياط»، وأقراص ولقطات يتيمة لم تُحذف، وبيانات باردة في فئة تخزين غالية، ونقل بيانات غير مرئي بين المناطق. القصّ الأعمى لهذا التضخّم خطر بدوره: إطفاء مورد يبدو خاملًا قد يكسر خدمة تعمل على فترات، وشراء خصومات التزام على حِمل غير مستقر قد يقفل إنفاقًا زائدًا لسنة. لذلك يفرض السير منهجًا يوازن بين التوفير والموثوقية. يختلف هذا السير جوهريًا عن الأصول القريبة في السوق ولا يكرّرها. هو ليس «سير اختبار الحمل والأداء قبل الإطلاق» الذي يتحقق من قدرة النظام على تحمّل الحِمل المستهدف قبل الإطلاق؛ ذاك يقيس السعة مقابل هدف أداء، بينما هذا يقلّل تكلفة سعة قائمة دون الإضرار بالأداء (وقد يستعين بنتائج اختبار الحمل ليعرف الحدّ الآمن للتصغير). وهو ليس «سير ترقية التبعيات» ولا «سير ترحيل قاعدة البيانات» ولا «سير تدوير الأسرار» ولا «سير النشر بإطلاق تدريجي (Canary)»؛ فتلك تدير تغييرًا في الكود أو المخطط أو الأسرار أو نشر إصدار، بينما هدف هذا السير المحدّد: خفض الإنفاق على البنية التحتية مع الحفاظ على الموثوقية. وهو ليس أمرًا ماليًا محاسبيًا مثل «تحليل انحرافات الموازنة» أو «تقييم جدوى الاستثمار الرأسمالي (NPV/IRR)»؛ تلك تعمل على قوائم مالية وقرارات استثمار عامة، بينما هذا سير تشغيلي تقني على فاتورة سحابة فعلية بخدماتها ومواردها. يميّز السير تصنيف الهدر إلى عائلات لأن علاج كلٍّ يختلف: (1) موارد خاملة تمامًا (خوادم/قواعد بيانات تعمل بلا استخدام)؛ (2) موارد مفرطة الحجم (over-provisioned) تعمل بأقل بكثير من طاقتها فتُصغّر (rightsizing)؛ (3) موارد يتيمة غير مرتبطة (أقراص، عناوين IP، موازِنات حمل، لقطات قديمة) تُحذف؛ (4) تخزين في فئة غالية لبيانات باردة يُنقل إلى فئة أرخص (S3 IA/Glacier وما يماثلها)؛ (5) نقل بيانات (egress) مكلف بين المناطق أو للإنترنت يُعاد تصميمه؛ (6) غياب خصومات الالتزام (Savings Plans / Reserved / Committed Use) على حِمل ثابت مؤكَّد؛ (7) بيئات غير إنتاجية (تطوير/اختبار) تعمل ليلًا وعطلات بلا حاجة فتُجدوَل. ولكل عائلة يختار السير الإجراء الآمن المناسب وترتيبها في سِجِلّ الفرص. يعمل السير عبر سبع مراحل: (1) الجرد والتفكيك: اجمع الفاتورة وفكّكها حسب الخدمة والحساب والبيئة والوسم (tags)، وحدّد أكبر بنود الإنفاق و«ما الذي يدفع الفاتورة». (2) رصد الهدر: صنّف كل بند في عائلة الهدر المناسبة اعتمادًا على قياسات الاستخدام الفعلية (CPU/الذاكرة/الشبكة/معدل الطلبات على نافذة كافية)، لا على الانطباع. (3) ترتيب الفرص: أنشئ سِجِلّ فرص وقدّر لكل فرصة التوفير الشهري والجهد والمخاطرة، ورتّبها لتبدأ بالأعلى توفيرًا والأقل مخاطرةً وجهدًا. (4) التطبيق الآمن على دفعات: طبّق التحسينات في دفعات صغيرة قابلة للتراجع (فرصة أو مجموعة متجانسة لكل دفعة)، وثبّت التغيير في البنية-ككود (IaC) حين أمكن بدل تعديل يدوي يُنسى. (5) التحقق: بعد كل دفعة راقب الموثوقية والأداء (الأخطاء، زمن الاستجابة p95، معدل النجاح، سلوك الخدمات المتأثرة) وقِس الفاتورة قبل/بعد لتأكيد التوفير الفعلي؛ لا تُحتسب الفرصة ناجحة إلا بدليل توفير دون تدهور. (6) خصومات الالتزام: بعد أن يستقر الحِمل على مستواه المحسَّن، اشترِ خصومات الالتزام على الحِمل الأساسي المؤكَّد فقط (لا على ذروة مؤقتة)، لأن الالتزام على حِمل سيُصغَّر لاحقًا يقفل إنفاقًا زائدًا. (7) الحواجز والحوكمة: ثبّت ما يمنع عودة الهدر — وسم إلزامي للموارد (owner/env/service) لعزو التكلفة، وميزانيات وتنبيهات عند تجاوز عتبة، وكشف دوري للموارد الخاملة واليتيمة، ومراجعة ربع سنوية للالتزامات. تحكمه قواعد صارمة: لا تحذف أو تُطفئ موردًا قبل إثبات أنه غير مستخدم فعلًا عبر قياس على نافذة رصد كافية؛ لا تُصغّر مورد إنتاج على مسار حرِج دون التحقق من ذروته الحقيقية (ويفضَّل اختبار حِمل)؛ لا تشترِ خصم التزام قبل استقرار الحِمل بعد التحسين؛ طبّق على دفعات قابلة للتراجع ولا تُغيّر كل شيء دفعة واحدة؛ قِس التوفير بمقارنة الفاتورة قبل/بعد لا بالتقدير وحده؛ لا تُضحِّ بالموثوقية أو الأداء مقابل التوفير؛ ولا تخترع رقم فاتورة أو نسبة استخدام أو توفيرًا غير محقَّق. مناسب لمهندسي البنية وDevOps وفِرَق FinOps وأصحاب المنتجات الذين يديرون إنفاق السحابة ويريدون خفضه دون كسر الإنتاج، ويعمل مع AWS وAzure وGoogle Cloud وغيرها، وقابل للتحويل إلى runbook أو checklist داخل Claude Code وCursor وCodex.

تقرير تحسين تكلفة سحابة عربي منظّم وقابل للتطبيق: خريطة تكلفة تفكّك أكبر بنود الإنفاق حسب الخدمة والبيئة والوسم، وسِجِلّ هدر مصنَّف في سبع عائلات (خامل، مفرط الحجم، يتيم، تخزين بارد، نقل بيانات، غياب التزام، بيئات غير إنتاجية) مبني على قياسات الاستخدام، وسِجِلّ فرص مرتّب حسب التوفير الشهري والجهد والمخاطرة مع قرار لكل فرصة، وخطة تطبيق على دفعات قابلة للتراجع مثبّتة في IaC، وبوابة تحقق تراقب الأداء (أخطاء، p95، معدل نجاح) وتقيس الفاتورة قبل/بعد مع شرط تراجع فوري عند التدهور، وخطة خصومات التزام على الحِمل المستقر فقط، ثم حواجز حوكمة (وسم إلزامي، ميزانيات، تنبيهات، كشف دوري) — كله مبني على إثبات عدم استخدام المورد قبل حذفه، وقياس التوفير لا تقديره، ودون التضحية بالموثوقية أو اختراع أرقام غير محقَّقة.