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

ضبط الأحجام وإزالة الهدر

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

ضبط الأحجام وإزالة الهدر

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

الموارد الخاملة

المورد الخامل هو مورد يعمل ويُحسب ثمنه دون أن يقدّم أي قيمة للمستخدم. أمثلة شائعة: مثيل EC2 تطويري تُرك مشغّلاً طوال عطلة نهاية أسبوع ممتدة، قاعدة بيانات RDS تعطّل تطبيقها منذ ستة أشهر، موزّع أحمال بدون أهداف سليمة، توزيع CloudFront يشير إلى أصل محذوف، أو مجموعة عُقد GKE بمتوسط استخدام CPU 3% لخدمة تم إيقافها. التحدي أن الارتفاعات المتفرقة تجعل الخامل يبدو نشيطاً ما لم تنظر في الإشارة الصحيحة على نافذة زمنية كافية.

استعلام الاكتشاف الأساسي لـ EC2 يعتمد مقاييس CloudWatch. اسحب متوسط CPU على مدى 14 يوماً وضع علامة على كل ما هو أقل من 5%. لكن CPU وحدها مُضلِّلة — طبقة الكاش أو المثيل الاحتياطي قد يُظهر صفراً بينما يخدم حركة مرور حيوية على ارتفاعات المنافذ. تحقّق بالتقاطع مع بايتات الشبكة وعدد الاتصالات قبل اتخاذ أي إجراء.

# AWS CLI: البحث عن مثيلات EC2 بمتوسط CPU أقل من 5% خلال 14 يوماً الماضية
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123456789 \
  --start-time $(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 1209600 \
  --statistics Average \
  --query 'Datapoints[0].Average'

# فحص مجمّع باستخدام AWS Cost Explorer + Resource Groups Tag API
aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=running \
  --query 'Reservations[*].Instances[*].[InstanceId,InstanceType,LaunchTime,Tags]' \
  --output json > running_instances.json

# توصيات Compute Optimizer القائمة على التعلم الآلي
aws compute-optimizer get-ec2-instance-recommendations \
  --filters name=Finding,values=NotOptimized \
  --query 'instanceRecommendations[*].{ID:instanceArn,Finding:finding,CurrentType:currentInstanceType,RecommendedType:recommendationOptions[0].instanceType}' \
  --output table

استخدم AWS Compute Optimizer أو GCP Recommender بدلاً من استعلامات المقاييس الخام. تُطبّق هذه الأدوات تعلّماً آلياً على 14 يوماً من المقاييس (CPU، ذاكرة عبر CloudWatch agent، شبكة، قرص، إنتاجية EBS) وتُخرج قائمة مرتّبة واحدة بالوفورات المتوقعة شهرياً لكل مثيل. اربط مخرجات JSON الخاصة بها بأتمتة Jira أو webhook في Slack بحيث تُنشأ تذكرة تلقائياً كل أسبوع لكل فريق تظهر موارده في القائمة.

المثيلات المفرطة الحجم

المبالغة في الحجم تختلف عن الخمول: المورد يُستخدم فعلاً، لكنه جُهّز بحجم لم يكن مبرّراً أصلاً أو كان كذلك ثم تقلّص الحمل. نمط شائع في الإنتاج: خدمة مصغّرة أُطلقت على m5.4xlarge "لأننا لم نكن متأكدين من الحمل"، وبعد ستة أشهر تكون P99 CPU لها 8% والخدمة تعمل على نفس العتاد. الفارق بين m5.4xlarge (0.768$/ساعة) وm5.large (0.096$/ساعة) هو 8x — على أسطول من 50 خدمة مماثلة يعني ذلك 300,000$/سنة.

ضبط الأحجام دورة من ثلاث خطوات: قِس، اقترح، غيّر مع خطة تراجع. لا تُغيّر الحجم في الإنتاج دون تراجع مُختبَر. للخدمات عديمة الحالة خلف موزّع أحمال، التراجع هو تغيير قالب إطلاق Auto Scaling Group في دقيقة. للخدمات ذات الحالة (قواعد بيانات، طوابير، خدمات تنسيق)، التراجع هو استعادة لقطة — اختبر وقت الاستعادة قبل تغيير الحجم.

# Terraform: تحديد نوع المثيل كمتغير بحيث يكون ضبط الحجم تغييراً في سطر واحد
variable "instance_type" {
  description = "نوع مثيل EC2؛ تُراجَع ربع سنوياً من قِبل FinOps"
  type        = string
  default     = "m5.large"
}

resource "aws_instance" "api_server" {
  ami           = data.aws_ami.app.id
  instance_type = var.instance_type
}

# ضبط حجم RDS: تغيير فئة المثيل (يتطلب نافذة صيانة)
resource "aws_db_instance" "postgres" {
  identifier        = "prod-postgres"
  instance_class    = var.db_instance_class   # كانت db.r6g.4xlarge؛ ضُبطت إلى db.r6g.xlarge
  apply_immediately = false
  skip_final_snapshot = false
  final_snapshot_identifier = "pre-resize-snapshot-${formatdate("YYYYMMDD", timestamp())}"
}

مقاييس الذاكرة نقطة عمياء في AWS Compute Optimizer ما لم تُثبّت CloudWatch agent. مثيل يُشغّل كاش في الذاكرة قد يبدو مُحسَّن الحجم بمقياس CPU بينما هو في الواقع ناقص الذاكرة. نشر CloudWatch agent دائماً (مقياس mem_used_percent) وGCP Ops Agent على كل مثيل قبل الثقة بأي توصية لضبط الحجم. بدون بيانات الذاكرة، سيوصي Optimizer بمثيل موجّه للحوسبة لعبء عمل محدود بالذاكرة وستتسبب في OOM في الإنتاج.

التخزين المهجور

التخزين المهجور هو فئة الهدر الأكثر خداعاً لأن هذه الموارد لا تظهر في لوحات المراقبة العادية. أمثلة شائعة: أقراص EBS منفصلة عن مثيلات محذوفة (لا تُحذف افتراضياً)، لقطات EBS لأقراص لم تعد موجودة، صور AMI مسجّلة لكنها لم تُستخدم قط، أدلة S3 بدون سياسات دورة حياة، لقطات RDS تتجاوز سياسة الاستبقاء، وعناوين Elastic IP مُخصَّصة لكن غير مرتبطة (تُفوتر بـ 0.005$/ساعة — ضئيلة للوحدة لكنها ضخمة على نطاق واسع).

في AWS، الإعداد الافتراضي الأكثر إغفالاً هو أن علامة DeleteOnTermination لقرص EBS الجذر تكون true افتراضياً، لكن الأقراص الإضافية تكون false افتراضياً. كل مجموعة Auto Scaling ترفق قرص بيانات ثانوياً ستترك أقراص EBS مهجورة عند كل حدث تقليص ما لم تضبط DeleteOnTermination=true صراحةً عند الإرفاق أو عبر قالب الإطلاق.

#!/usr/bin/env bash
# صائد الموارد المهجورة: البحث عن أقراص EBS غير مرتبطة وعناوين EIP غير مربوطة

echo "=== أقراص EBS غير المرتبطة ==="
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType,AZ:AvailabilityZone,Created:CreateTime}' \
  --output table

echo ""
echo "=== عناوين Elastic IP غير المربوطة ==="
aws ec2 describe-addresses \
  --filters Name=domain,Values=vpc \
  --query 'Addresses[?AssociationId==`null`].{AllocationId:AllocationId,PublicIP:PublicIp,Tags:Tags}' \
  --output table

echo ""
echo "=== لقطات أقدم من 90 يوماً بدون قرص مقابل ==="
CUTOFF=$(date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)
aws ec2 describe-snapshots \
  --owner-ids self \
  --query "Snapshots[?StartTime<='${CUTOFF}'].{ID:SnapshotId,VolumeId:VolumeId,Size:VolumeSize,Created:StartTime}" \
  --output table | head -60

echo ""
echo "=== أدلة S3 بدون سياسة دورة حياة ==="
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
  lc=$(aws s3api get-bucket-lifecycle-configuration --bucket "$bucket" 2>&1)
  if echo "$lc" | grep -q "NoSuchLifecycleConfiguration"; then
    size=$(aws s3api list-objects-v2 --bucket "$bucket" \
      --query 'sum(Contents[*].Size)' --output text 2>/dev/null || echo "0")
    echo "لا سياسة دورة حياة: $bucket  (بايتات تقريبية: $size)"
  fi
done

سير عمل ضبط الأحجام على نطاق واسع

التنظيف المتقطع حدث لمرة واحدة؛ الهدر في الإنتاج يتراكم باستمرار. يبني المهندسون المتمرسون خط أنابيب أسبوعي آلي يُنفّذ ما يلي: سحب التوصيات من Compute Optimizer وأدوات GCP/Azure المقابلة؛ ربطها بقاعدة بيانات الوسوم لتحديد الفريق المالك ومركز التكلفة؛ حساب الوفورات المتوقعة شهرياً؛ فتح تذكرة Jira مُعيَّنة للفريق بمهلة أسبوعين؛ تتبع معدل الإغلاق لكل فريق؛ تصعيد التذاكر غير المُغلقة إلى مدراء الهندسة. يحوّل هذا ضبط الأحجام من حملة تنظيف بطولية إلى انضباط تشغيلي مستمر.

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

فعّل S3 Intelligent-Tiering لجميع الأدلة التي يتجاوز متوسط حجم كائناتها 128 كيلوبايت وأنماط وصولها غير متوقعة. ينقل الكائنات تلقائياً عبر طبقات Frequent وInfrequent وArchive Instant وDeep Archive دون رسوم استرداد للطبقتين الأوليين. للأدلة ذات أنماط وصول معروفة (كأرشيف السجلات غير المُصل إليها بعد 30 يوماً)، استخدم قاعدة دورة حياة صريحة بدلاً من ذلك — إنها أرخص لأن Intelligent-Tiering يُفوتر رسوم مراقبة صغيرة لكل كائن تتراكم على الأدلة التي تحوي ملايين الكائنات الصغيرة.

ضمانات الحماية على مستوى الإنتاج

كل برنامج لإزالة الهدر يحذف في نهاية المطاف شيئاً لا ينبغي حذفه. ابنِ الضمانات قبل أتمتة الحذف: ضع وسم do-not-delete=true على كل مورد يجب أن يبقى بغض النظر عن المقاييس؛ اشترط موافقة بشرية لأي حذف فوق حد حجم محدد (أقراص EBS تتجاوز 500 GB، أدلة S3 تتجاوز 1 TB)؛ شغّل جميع سكريبتات الحذف في وضع التجربة لمدة أسبوع قبل تفعيل الوضع الحي؛ واحتفظ بسجل تدقيق 30 يوماً لكل شيء تم حذفه، من قِبل من (أو أي أتمتة)، مع ARN المورد والمقياس الذي أثار الحذف. نجح سجل التدقيق في إنقاذ مهندسي الاستجابة في حالات انقطاع غامضة تبيّن أنها كانت بسبب أتمتة تنظيف أزالت قائمة انتظار "صفرية الحركة" اكتُشف لاحقاً أنها كانت قائمة رسائل ميتة تُراجع مرة في الشهر من قِبل مهمة امتثال.

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