FinOps وتحسين تكاليف السحابة

خصومات الالتزام

18 دقيقة الدرس 5 من 26

خصومات الالتزام

التسعير عند الطلب هو السعر الكامل للسحابة — ما تدفعه حين تستخدم الموارد دون أي حجز مسبق. يقدم كل مزود سحابي رئيسي نظام شراء موازياً يتبادل فيه مرونة الجدول الزمني مقابل أسعار أقل بشكل ملحوظ: خطط التوفير والحالات المحجوزة من AWS، وخصومات الاستخدام الملتزم من GCP، والحالات الاحتياطية لأجهزة الافتراضية وخطط التوفير من Azure. على نطاق واسع، هذه ليست ميزات اختيارية؛ إنها الرافعة الأعلى تأثيراً في FinOps. يمكن لبرنامج ناضج يحقق تغطية 70–80% أن يخفض تكاليف الحوسبة بنسبة 30–45% دون أي تغيير معماري. الانضباط يكمن في الاستراتيجية: معرفة متى تلتزم، وكم تلتزم، وكيف تضع الأدوات في طبقات بشكل صحيح.

الأدوات الثلاث

الحالات المحجوزة (RIs) هي منتج الالتزام الأصلي. في AWS تشتري سعة لعائلة نوع محددة من الحالات، وحجمها، ومنطقتها (أو منطقة التوفر)، ونظام تشغيلها لمدة سنة أو ثلاث سنوات. تقدم الحالات المحجوزة القياسية أعمق الخصومات — تصل إلى 72% من الطلب العادي — لكنها صارمة: لا يمكنك تغيير عائلة نوع الحالة. تتيح الحالات القابلة للتحويل التبديل مقابل خصم أقل عمقاً (نحو 54–66%). الحالات المحجوزة مناسبة لأكثر لخوادم قواعد البيانات، والخوادم الدائمة، وتجمعات عُقد Kubernetes الأساسية.

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

خصومات الاستخدام الملتزم من GCP تأتي في صيغتين: تلتزم خصومات الموارد بكميات vCPU وذاكرة لمدة سنة أو ثلاث سنوات بخصم يصل إلى 57%؛ وتلتزم خصومات التوفير المرنة (القائمة على الإنفاق، متاحة لبعض الخدمات) بمبلغ دولاري في الساعة مشابه لخطط التوفير من AWS. تمنح GCP أيضاً خصومات الاستخدام المستدام التلقائية لأي حالة تعمل أكثر من 25% من الشهر — دون أي إجراء مطلوب — وهو ما يمثل حداً أدنى للأمان قبل إضافة طبقات خصومات الاستخدام الملتزم.

طبقات خصومات الالتزام: ابدأ من الأسفل — الحالات المحجوزة للأحمال الثابتة، وخطط التوفير لكل شيء آخر.

استراتيجية التغطية: التدرج (Laddering)

النهج الساذج يشتري حالات محجوزة لكل ما يعمل حالياً بالتزام كامل. النهج الصحيح هو التدرج: توزيع شروط الالتزام وأحجامه عبر الزمن بحيث لا تكون ملتزماً بالكامل بتوقع يمتد أكثر من 12 شهراً في المستقبل.

يعمل نموذج التدرج على النحو التالي. انظر إلى الحد الأدنى لإنفاقك خلال 90 يوماً الماضية — أقل إنفاق ساعي على الحوسبة خلال تلك الفترة، مستثنياً ارتفاعات الحوادث. هذا الحد الأدنى يمثل أفضل مرشح للالتزام لمدة 3 سنوات لأن الحمل لم ينخفض أبداً دونه. الطبقة التالية — متوسط 90 يوماً الماضية ناقص الحد الأدنى — هي التزام معقول لمدة سنة. أي شيء فوق المتوسط يبقى عند الطلب (أو على Spot، تناولنا ذلك في الدرس 6). كل ربع سنة، أعد تشغيل التحليل وأضف طبقات التزامات جديدة مع نضج الأحمال.

قرار 3 سنوات مقابل سنة واحدة: تقدم الشروط لثلاث سنوات خصماً أكبر بنحو 10–15 نقطة مئوية من الشروط لسنة واحدة، لكنها تربطك بالالتزام لمدة 36 شهراً. في شركة سحابية حيث تتغير عائلات الحالات كل 18 شهراً وتتطور المعمارية بسرعة، غالباً ما يكون محفظة من الشروط لسنة واحدة المتجددة باستمرار أفضل عائداً معدلاً بالمخاطر من الالتزامات لثلاث سنوات. احتفظ بالشروط لثلاث سنوات للأحمال الثابتة حقاً وذات الطبيعة السلعية: قواعد بيانات RDS، ومجموعات Elasticsearch، وسعة تجمع العُقد الأساسية. استخدم سنة واحدة لكل شيء آخر.

عملياً، تستهدف معظم فرق AWS تغطية 70–80% من خطهم الأساسي الثابت بخطط توفير الحوسبة (سنة واحدة، بدون دفع مسبق أو دفع مسبق جزئي)، وتضيف طبقات خطط توفير حالة EC2 أو حالات محجوزة قياسية أو منطقة-محددة فوق أعلى تجمعات العُقد استخداماً حيث لم يتغير نوع الحالة منذ 18 شهراً أو أكثر. تتبع فرق GCP نمطاً مشابهاً: خصومات موارد للخط الأساسي المثبت، وخصومات مرنة لخدمات مثل Cloud Run أو GKE Autopilot.

الشراء عملياً — AWS CLI

قبل الشراء، تحقق من التوصية باستخدام محرك التوصية البرمجي في Cost Explorer. راجع دائماً حقول UpfrontCost وEstimatedMonthlySavings وEstimatedROI قبل أي التزام.

# 1. سحب توصية خطة توفير الحوسبة من AWS (سنة واحدة، دفع مسبق جزئي، نظرة 7 أيام للخلف)
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option PARTIAL_UPFRONT \
  --lookback-period-in-days SEVEN_DAYS \
  --query 'SavingsPlansPurchaseRecommendation.{
      EstimatedROI:SavingsPlansPurchaseRecommendationSummary.EstimatedROI,
      MonthlySavings:SavingsPlansPurchaseRecommendationSummary.EstimatedMonthlySavingsAmount,
      HourlyCommitment:SavingsPlansPurchaseRecommendationSummary.HourlyCommitmentToPurchase
    }' \
  --output json

# 2. التحقق من تغطية خطة التوفير الحالية (آخر 30 يوماً)
aws ce get-savings-plans-coverage \
  --time-period Start=2025-05-12,End=2025-06-11 \
  --granularity MONTHLY \
  --metrics CoverageHours \
  --query 'SavingsPlansCoverages[*].Coverage' \
  --output table

# 3. التحقق من معدل استخدام خطط التوفير الحالية (تنبيه إذا كان أقل من 90%)
aws ce get-savings-plans-utilization \
  --time-period Start=2025-05-12,End=2025-06-11 \
  --granularity MONTHLY \
  --query 'SavingsPlansUtilizationsByTime[*].Utilization.UtilizationPercentage' \
  --output text

أتمتة تنبيهات الاستخدام: أنشئ إنذار CloudWatch أو Lambda يومية تستدعي get-savings-plans-utilization وتنبه قناة FinOps إذا انخفض الاستخدام دون 85%. خطة التوفير غير المستخدمة التي لا يلاحظها أحد هي أموال مهدرة — أنت تدفع السعر الملتزم دون استهلاك ذلك القدر من الحوسبة. يحدث هذا عادةً بعد إيقاف تشغيل حمل أو تصغيره في منتصف المدة.

خيارات الدفع والتدفق النقدي

تقدم AWS وAzure ثلاثة أوضاع دفع للحالات المحجوزة وخطط التوفير: كل الدفع مسبقاً، ودفع مسبق جزئي، وبدون دفع مسبق. يحقق الدفع الكامل مسبقاً أعمق الخصومات (عادةً 3–5% أكثر من بدون دفع مسبق) لكنه يحتجز رأس المال العامل. عند مليون دولار سنوياً من تكاليف الحوسبة، الوفر من الدفع الكامل مسبقاً مقارنة ببدون دفع مسبق هو نحو 30–50 ألف دولار — قدر ذو معنى، لكن وازنه مع احتياجات التدفق النقدي وتكلفة رأس مال الشركة. تعتمد معظم شركات مرحلة النمو افتراضياً على بدون دفع مسبق أو دفع مسبق جزئي وتقبل الخصم الأقل عمقاً مقابل التدفق النقدي الشهري المتوقع.

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

التعامل مع تغييرات المعمارية في منتصف المدة

أكثر حوادث FinOps شيوعاً هو شراء حالة محجوزة لمدة 3 سنوات لنوع حالة يصبح قديماً أو يُستبدل بجيل جديد خلال 18 شهراً. تقدم AWS ثلاثة منافذ هروب: تبادلات الحالات المحجوزة القابلة للتحويل (التبديل إلى عائلة حالة مختلفة بقيمة مكافئة أو أكبر)، وسوق الحالات المحجوزة (بيع الحالات المحجوزة القياسية غير المستخدمة لعملاء AWS آخرين)، وخطط التوفير التي تتبع حملك تلقائياً. المكافئ في GCP هو أن خصومات الموارد مرنة عبر معظم أنواع الحالات ضمن عائلة؛ إذا اختفى الحمل كلياً، لا تقدم GCP سوقاً ثانوية وأنت ملتزم بالمدة المتبقية.

لا تلتزم أبداً بما يتجاوز أفق تخطيطك. إذا كان خارطة طريق 12 شهراً تتضمن هجرة محتملة من EC2 إلى Fargate، أو من Kubernetes المدار ذاتياً إلى GKE Autopilot، فلا تشتري حالات محجوزة تغطي الحمل الذي تخطط لتقاعده. استخدم خطط توفير الحوسبة (التي تغطي Fargate وLambda تلقائياً) أو ابق هذه الأحمال عند الطلب حتى يُتخذ قرار الهجرة. الحالة المحجوزة لمدة 3 سنوات على نوع حالة ستوقفه في 14 شهراً هي التزام خسارة، لا أصل.

الحالات المحجوزة المُدارة بـ Terraform

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

# terraform/finops/savings_plans.tf
# خطة توفير الحوسبة — سنة واحدة، بدون دفع مسبق، التزام 10 دولار/ساعة كخط أساسي
resource "aws_savingsplans_savings_plan" "compute_baseline" {
  savings_plan_type   = "COMPUTE"
  commitment          = "10.00"          # USD per hour
  savings_plan_offer_id = data.aws_savingsplans_savings_plan_offerings.compute_1yr.offerings[0].offering_id
  tags = {
    environment = "production"
    team        = "platform"
    FinOps      = "committed-baseline"
  }
}

data "aws_savingsplans_savings_plan_offerings" "compute_1yr" {
  currency          = "USD"
  payment_option    = "NO_UPFRONT"
  plan_type         = "COMPUTE"
  duration_seconds  = 31536000   # 1 year
}

# حالة RDS المحجوزة لمجموعة قاعدة البيانات الرئيسية (3 سنوات، دفع مسبق جزئي)
resource "aws_db_reserved_instances" "primary_db" {
  reserved_instances_offering_id = data.aws_db_reserved_instances_offerings.mysql_r6g_4xl.id
  instance_count                 = 2
  tags = {
    team   = "data-platform"
    FinOps = "3yr-ri"
  }
}

data "aws_db_reserved_instances_offerings" "mysql_r6g_4xl" {
  db_instance_class       = "db.r6g.4xlarge"
  engine                  = "mysql"
  multi_az                = true
  offering_type           = "Partial Upfront"
  duration                = 94608000   # 3 years
}

دورة مراجعة FinOps

محافظ الالتزام ليست من النوع الذي تضبطه وتنساه. يُجري برنامج جيد التنظيم مراجعة FinOps شهرية بثلاثة بنود رئيسية في جدول الأعمال: معدل التغطية (الهدف 70–80% من الخط الأساسي الثابت)، ومعدل الاستخدام (الهدف أعلى من 90%)، وتقويم انتهاء الصلاحية القادم (ما الحالات المحجوزة التي تنتهي خلال 90 يوماً القادمة وهل يجب تجديدها أو استبدالها أو تركها تنتهي). أضف إلى ذلك تحليلاً ربع سنوي لتحديد ما إذا كانت الالتزامات الجديدة مبررة مع نضج الأحمال. عيّن مسؤولاً مباشراً — عادةً مهندس منصة أول أو محلل FinOps متخصص — يمتلك تقويم الالتزام بنفس الطريقة التي يمتلك بها مهندس SRE ميزانية مؤشر مستوى الخدمة.

خطة التوفير مقابل الحالة المحجوزة — الافتراض العملي: ابدأ بخطط توفير الحوسبة لـ EC2 وLambda وFargate. أضف خطط توفير حالة EC2 فقط عندما تكون عائلة حالة معينة ثابتة منذ 12 شهراً أو أكثر وتريد الخصم الأعمق. استخدم الحالات المحجوزة أساساً لـ RDS وElastiCache وRedshift وOpenSearch — الخدمات غير المشمولة بخطط التوفير — حيث يكون نوع الحالة ثابتاً حقاً على مدى سنوات متعددة.