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

مشروع: برنامج تحسين التكاليف

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

مشروع: برنامج تحسين التكاليف

هذا الدرس هو ختام برنامج FinOps. ستعمل خلاله على سيناريو واقعي: فاتورة AWS بقيمة 480,000 دولار شهرياً لمنصة SaaS متوسطة الحجم، وستتتبع كل سطر في تلك الفاتورة باستخدام منهجية تدقيق منظمة، ثم تنتج خارطة توفير ملموسة مع تصنيف الجهود وتقديرات بالدولار وجدول تسليم لمدة 12 شهراً. هذه بالضبط هي التمرين الذي يُجريه ممارس FinOps عند الانضمام إلى مؤسسة جديدة أو حين يبدأ الإنفاق السحابي في تجاوز نمو الإيرادات.

الفاتورة النموذجية — تشريح 480,000 دولار/شهر

المنصة هي منتج SaaS للشركات يخدم 8,000 مستأجر في us-east-1 وeu-west-1. المؤسسة الهندسية تضم 120 مهندساً موزعين على 14 فرقة منتج. لم تُراجَع الفاتورة بشكل منهجي قط. الوضع الراهن:

EC2 وAuto Scaling: 198,000 دولار (41%) — 420 جهازاً في الإنتاج، جميعها بأسعار on-demand. تتراوح الأحجام بين t3.large وc6i.8xlarge. لا Savings Plans ولا RIs. متوسط استهلاك المعالج المُبلَّغ عنه عبر CloudWatch هو 22% على مستوى الأسطول.
RDS وAurora: 87,000 دولار (18%) — 38 مجموعة Aurora (متوافقة مع MySQL). 11 مجموعة تعمل على db.r6g.8xlarge بنظام متعدد نطاقات التوافر. لا Reserved Instances. 6 مجموعات لم تتلقَّ أي استعلام كتابة في آخر 14 يوماً (بيئات تطوير واختبار لا تُوقَف ليلاً وعطل نهاية الأسبوع).
نقل البيانات: 62,000 دولار (13%) — أكبر بند واحد لم يفحصه أحد. 41,000 دولار تكاليف نقل بين نطاقات التوافر. 14,000 دولار نسخ متقاطع بين المناطق إلى eu-west-1 لمستأجرين يقيمون فعلياً بالكامل في us-east-1.
S3: 34,000 دولار (7%) — 1.2 بيتابايت مخزنة. لا Intelligent-Tiering ولا قواعد دورة الحياة. CloudWatch يُظهر أن 85% من الكائنات لم يُصَل إليها منذ أكثر من 90 يوماً.
CloudWatch Logs: 29,000 دولار (6%) — الاحتفاظ الافتراضي اللانهائي على 340 مجموعة سجلات. 60% من الاستيعاب عبارة عن سجلات debug من خدمة Java كان يجب تحويلها إلى مستوى INFO في الإنتاج منذ 18 شهراً.
بوابات NAT: 24,000 دولار (5%) — 12 بوابة NAT عبر 4 شبكات VPC. 19,000 دولار منها رسوم معالجة بيانات من حركة S3 وDynamoDB التي تمر عبر NAT بدلاً من VPC Endpoints.
أخرى (لقطات EBS، ELBs، ECR، Lambda، SQS، SNS): 46,000 دولار (10%)

تفصيل الفاتورة الشهرية حسب فئة الخدمة. نقل البيانات وبوابات NAT مكلفان بشكل غير متناسب مع ما تقدمانه.

المرحلة الأولى — التدقيق: اطرح الأسئلة الصحيحة قبل أن تلمس أي شيء

أسوأ خطأ في تدقيق الفاتورة هو الضغط فوراً على "شراء Reserved Instances" أو حذف موارد دون فهم العلاقات السببية. التدقيق المنظم يتبع هذا التسلسل:

تحقق من تغطية الوسوم. نفّذ aws resourcegroupstaggingapi get-resources --tag-filters Key=team وقِس النسبة المئوية للموارد التي تحمل وسوم team وenv وservice. في الفاتورة النموذجية، تغطية الوسوم 38% — أي 62% من الإنفاق غير مُخصَّص. أصلح الوسوم قبل تحليل أي شيء آخر وإلا ستكون نتائجك بلا معنى.
صدّر بيانات Cost Explorer لمدة 90 يوماً. صدّر بدقة يومية مجمّعاً حسب SERVICE وUSAGE_TYPE ووسم team. حمّلها في جدول بيانات أو Athena. ابحث عن خطوط نمو رتيبة (تكلفة تنمو يومياً دون إطلاق ميزات مقابل)، وارتفاعات مفاجئة (قفزة تكلفة مفاجئة — عادةً حمل عمل جديد أو تهيئة خاطئة)، وخطوط مستقيمة على مبالغ كبيرة (موارد ملتزمة خاملة).
قارن مع مقاييس CloudWatch. لـEC2، استخرج متوسط CPUUtilization وNetworkIn وNetworkOut على مدى 90 يوماً. كل ما يبلغ متوسطه أقل من 10% معالج هو مرشح للتعديل أو الإيقاف. لـRDS، استخرج DatabaseConnections — مجموعة Aurora بصفر اتصال على مدى 14 يوماً هي بيئة تطوير لم تحصل على جدول إيقاف.
رسم تدفقات البيانات. استخدم VPC Flow Logs مجمّعة في Athena لتحديد أكثر 10 أزواج مصدر/وجهة نقلاً للبيانات بالبايت. هذه الطريقة الوحيدة لفهم فاتورة نقل البيانات البالغة 62,000 دولار دون تخمين. حركة البيانات عبر نطاقات التوافر دائماً تأتي من عدد قليل من الخدمات الثرثارة التي نُشرت دون مراعاة تقارب نطاقات التوافر.

# الخطوة 1: قياس تغطية الوسوم لجميع أنواع الموارد
aws resourcegroupstaggingapi get-resources \
  --resource-type-filters ec2:instance rds:db elasticloadbalancing:loadbalancer \
  --query 'ResourceTagMappingList[*].{ARN:ResourceARN, Tags:Tags}' \
  --output json | jq '
    .[] |
    {
      arn: .ARN,
      has_team:    ((.Tags // []) | map(.Key) | contains(["team"])),
      has_env:     ((.Tags // []) | map(.Key) | contains(["env"])),
      has_service: ((.Tags // []) | map(.Key) | contains(["service"]))
    }
  ' | jq -s '
    {
      total: length,
      fully_tagged: (map(select(.has_team and .has_env and .has_service)) | length),
      coverage_pct: ((map(select(.has_team and .has_env and .has_service)) | length) * 100 / length)
    }
  '

# الخطوة 2: استعلام Athena — أكثر أزواج حركة البيانات عبر نطاقات التوافر
SELECT
  srcaddr,
  dstaddr,
  SUM(bytes) / 1073741824.0  AS gigabytes_transferred
FROM vpc_flow_logs
WHERE date_partition >= '2025-03-01'
  AND src_az != dst_az
GROUP BY srcaddr, dstaddr
ORDER BY gigabytes_transferred DESC
LIMIT 20;

خارطة التوفير — مُصنَّفة حسب الجهد والوقت اللازم للقيمة

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

قاعدة 80/20 في توفير السحابة: في كل تدقيق أول تقريباً، أربع فئات تشكّل 80% من التوفير القابل للاسترداد: الموارد الخاملة/اليتيمة، وتعديل حجم الحوسبة، وخصومات الالتزام، ومعمارية نقل البيانات. كل شيء آخر ضجيج حتى تُنجز هذه الأربعة.

الطبقة 0 — حذف بلا مخاطرة (الأسبوع 1-2، صفر جهد هندسي):

إيقاف 6 مجموعات Aurora التطويرية الخاملة: توفير ~14,400 دولار/شهر. صفر اتصال. التقط لقطة أولاً ثم احذف. أضف Lambda + EventBridge لإيقاف مجموعات التطوير تلقائياً الساعة 18:00 وإعادة تشغيلها الساعة 08:00.
تعيين الاحتفاظ في CloudWatch Logs إلى 30 يوماً لجميع مجموعات السجلات، وتحويل مستوى سجلات Java إلى INFO: توفير ~17,400 دولار/شهر مجتمعَين.
حذف وحدات تخزين EBS غير المرتبطة وعناوين Elastic IP غير المستخدمة وموازنات الأحمال الخاملة: تقدير 8,000-12,000 دولار/شهر.

الطبقة 1 — إصلاحات معمارية سريعة (الأسابيع 2-6، مهندس إلى اثنين لكل منها):

VPC Endpoints لـS3 وDynamoDB: 19,000 دولار من رسوم معالجة بيانات NAT Gateway هي أعلى عائد على الاستثمار في الفاتورة. Gateway-type VPC Endpoints مجانية؛ البيانات تتوقف عن المرور عبر NAT. التنفيذ: وحدة Terraform واحدة، وPR واحد. توفير ~19,000 دولار/شهر.
تفعيل S3 Intelligent-Tiering: 1.2 بيتابايت مع 85% من الكائنات باردة. طبقة IT-Flexible تخفض تكلفة التخزين من ~0.023 دولار/جيجابايت إلى ~0.004 دولار/جيجابايت. صافي التوفير: ~18,000 دولار/شهر.
تصحيح نطاق النسخ المتقاطع بين المناطق: 14,000 دولار نقل بين المناطق لمستأجرين أمريكيين فقط. قصر النسخ على المستأجرين المقيمين في أوروبا. توفير ~11,000 دولار/شهر.

الطبقة 2 — تعديل الأحجام (الأسابيع 4-10، 0.5 موظف لمدة 6 أسابيع):

22% متوسط استهلاك المعالج على 420 جهازاً يعني توفيراً مفرطاً كبيراً. AWS Compute Optimizer يُولّد توصيات تعديل الأحجام بدرجات ثقة مبنية على تعلم الآلة. النهج المحافظ: تنفيذ التوصيات ذات الثقة العالية فقط. التخفيض المتوقع: 20-30% من تكاليف الأجهزة. على 198,000 دولار، تخفيض 25% يعني 49,500 دولار/شهر.
يجب تعديل الأحجام قبل شراء Savings Plans — الالتزام بأنواع أجهزة مُفرطة الحجم يُثبّت الهدر بخصم.

الطبقة 3 — خصومات الالتزام (الشهر 2-3، قائد FinOps + موافقة المالية):

بعد تعديل الأحجام، سيكلف أسطول EC2 نحو 148,500 دولار/شهر بأسعار on-demand. احسب الحد الأدنى للإنفاق الساعي خلال آخر 30 يوماً (بعد تعديل الأحجام): هذا هو المرشح الآمن لـ Compute Savings Plan لمدة 3 سنوات. مجموعات Aurora r6g.8xlarge الـ11 مستقرة — اشترِ Reserved Instances RDS لمدة 3 سنوات بدفع جزئي مقدم. التوفير المقدر مجتمعاً بخصم 55-65% عن الأسعار الآنية: 60,000-75,000 دولار/شهر.

# توليد توصيات تعديل الأحجام من AWS Compute Optimizer (تصدير CSV)
aws compute-optimizer export-ec2-instance-recommendations \
  --s3-destination-config bucket=my-finops-exports,keyPrefix=optimizer/ \
  --include-member-accounts \
  --recommendation-preferences EnhancedInfrastructureMetrics=Active

# استعلام Athena على البيانات المُصدَّرة:
SELECT
  instanceid,
  instancetype                                  AS current_type,
  recommendationoptions_1_instancetype          AS recommended_type,
  finding,
  utilizationmetrics_cpu_maximum                AS max_cpu_pct,
  recommendationoptions_1_estimatedmonthlysavings_value AS monthly_saving_usd
FROM compute_optimizer_ec2
WHERE finding = \'OVER_PROVISIONED\'
  AND recommendationoptions_1_performancerisk <= 2
ORDER BY monthly_saving_usd DESC
LIMIT 50;

# إيقاف مجموعات Aurora التطويرية تلقائياً الساعة 18:00 UTC
aws scheduler create-schedule \
  --name "dev-aurora-stop-weekday" \
  --schedule-expression "cron(0 18 ? * MON-FRI *)" \
  --flexible-time-window Mode=OFF \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:rds:stopDBCluster",
    "RoleArn": "arn:aws:iam::123456789012:role/SchedulerRole",
    "Input": "{\"DbClusterIdentifier\": \"dev-aurora-cluster-1\"}"
  }'

تقويم التوفير لـ12 شهراً

التسلسل مهم. إجراء خصومات الالتزام قبل تعديل الأحجام يُهدر المال. إصلاح نقل البيانات قبل فهم أنماط الحركة قد يكسر النسخ. التقويم أدناه هو ترتيب التنفيذ الموصى به:

خارطة FinOps لـ12 شهراً للفاتورة النموذجية. يجب تنفيذ الطبقات بالترتيب — خصومات الالتزام دائماً في النهاية.

اقتصاديات الوحدة: إغلاق الحلقة

خارطة توفير تتوقف عند "خفضنا الفاتورة" تفوّت نصف القيمة. FinOps الناضج يربط التكلفة السحابية بمقاييس الأعمال. لـSaaS للشركات، النسبة الجوهرية هي التكلفة لكل مستأجر شهرياً. عند 480,000 دولار/شهر لـ8,000 مستأجر، التكلفة لكل مستأجر هي 60 دولاراً. بعد برنامج الـ12 شهراً، نفس الـ8,000 مستأجر يكلّفون 34 دولاراً شهرياً — تحسن 43% يعني تحسناً كبيراً في هامش الربح الإجمالي إذا كانت الإيرادات تنمو.

قِس هذا في منظومة الرصد لديك. أرسل مقياساً يومياً cloud.cost_per_tenant إلى لوحة Grafana/Datadog، مرسوماً إلى جانب revenue_per_tenant وgross_margin_pct. حين يبدأ التكلفة لكل مستأجر بالارتفاع دون استثمار ميزات مقابل، شيء ما تغيّر — حمل عمل جديد بلا تعديل حجم، خط بيانات نما حجمه بشكل غير متوقع، خدمة فقدت تغطية Spot. اكتشاف هذه الإشارات على مستوى اقتصاديات الوحدة أسرع من انتظار المراجعة الشهرية للفاتورة.

قدّم التوفير كتحسين في هامش الربح الإجمالي، لا مجرد وفورات بالدولار. مدير تقني ومدير مالي يتفاعلان مع "تحسّن هامشنا الإجمالي السحابي من 58% إلى 67%" أكثر بكثير من "وفّرنا 2.4 مليون دولار سنوياً." ترجم خارطة التوفير إلى المقياس التجاري الذي يتابعه قياداتك قبل تقديمها.

الحوكمة: منع الانتكاس

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

Infracost في كل Terraform PR. فارق التكلفة فحص CI إلزامي، لا اختياري. PR يضيف 5,000 دولار/شهر من الإنفاق الجديد دون تذكرة Jira تربطه بمبرر تجاري يُعلَّق حتى يوافق عليه مهندس صراحة. هذا نفس نمط ماسح الأمان الذي يعترض PR بثغرة أمنية حرجة.
مراجعات FinOps شهرية مع showback على مستوى الفريق. كل فريق يرى اتجاه تكلفته على نفس شرائح عرض أداء SLO. ارتفاعات التكلفة تحظى بنفس الاهتمام الذي تحظى به ارتفاعات معدل الأخطاء.
إنفاذ الوسوم عبر AWS Config Rules وSCPs. أي مورد يُنشأ دون الوسوم الإلزامية يتلقى تلقائياً حدثاً إصلاحياً يضع عليه وسم team=untagged ويُرسل تنبيهاً لقائد FinOps. الموارد الموسومة untagged بعد 7 أيام مؤهلة للحذف التلقائي في حسابات غير الإنتاج.

فخ خصم الالتزام بعد تخفيضات التوظيف: إذا اشترت مؤسستك Savings Plans لثلاث سنوات بناءً على 500 مهندس ثم خُفِّضت القوى العاملة إلى 300 مهندس مع أسطول أصغر بشكل مقابل، يصبح الالتزام المشترى هدراً. لا يمكن إلغاء Savings Plans قبل انتهاء مدتها (يمكن بيعها في AWS Marketplace لكن بخصم). كلما أشارت مؤسستك إلى تخفيض في القوى العاملة أو إيقاف منتج رئيسي، نمّذج فوراً أثر ذلك على استهلاك الالتزام وأوقف أي مشتريات طويلة الأمد الجديدة حتى يتضح الوضع المستقر الجديد.

مخرجاتك

بوصفك المهندس المسؤول عن برنامج تحسين التكاليف، مخرجاتك بنهاية الشهر الأول يجب أن تكون: ملخص تنفيذي بصفحة واحدة يحتوي أربعة أرقام (الإنفاق الحالي، فرصة التوفير السنوية، الخطة لـ12 شهراً، والتكلفة لكل مستأجر قبل/بعد)؛ وحدة Terraform تُطبّق VPC Endpoints وS3 Intelligent-Tiering؛ ملف Jira epic بتذكرة لكل مبادرة في الطبقتين 0 و1 مع تقديرات بالدولار في معايير القبول؛ ولوحة Grafana تحتوي cloud.cost_per_tenant ونسبة استهلاك Savings Plan وأكثر 5 خدمات إنفاقاً. هذه المجموعة من المخرجات هي كيف تُثبت نضج FinOps على مستوى المهندس الأول والمهندس المتخصص.