مشروع التخرج: منصة إنتاج بمستوى الشركات الكبرى

التكلفة وتجربة المنصة

18 دقيقة الدرس 9 من 30

التكلفة وتجربة المنصة

في شركات مثل Google وAirbnb وStripe، تمتلك فرق المنصة مسؤوليتين يسهل التقليل من شأنهما حتى تتحولا إلى أزمات: الإبقاء على فاتورة السحابة قابلة للتنبؤ، وجعل المنصة شيئاً يرغب المهندسون فعلاً في استخدامه. تمنع ضمانات FinOps ظهور فاتورة مفاجئة بقيمة 400 ألف دولار بسبب autoscaler واحد مُهيّأ بشكل خاطئ. أما الخدمة الذاتية للمطورين — المسارات الذهبية وكتالوجات الخدمات وواجهات سطر الأوامر — فهي ما يُميّز منصة قادرة على التوسع ليخدمها 1000 مهندس عن منصة تغرق في تذاكر دعم Slack عند عتبة 50 مهندس. يتناول هذا الدرس كلا الموضوعين بعمق إنتاجي حقيقي.

ضمانات FinOps

حصص موارد Namespace هي خط الدفاع الأول. يجب أن يحمل كل namespace خاص بفريق ResourceQuota يضع سقفاً لكل من الطلبات والحدود. بدونه، يمكن لعمل واحد مفلت أن يُشبع مجموعة عقد بأكملها ويُطلق سلاسل autoscaler تستغرق 20 دقيقة لتفريغها. يُطبّق الحصر عند وقت القبول — إذا كان مجموع موارد Pod سيتجاوز سقف الـ namespace، يرفضه API server فوراً قبل أي جدولة.

# namespace-quota.yaml — يُطبَّق على كل namespace للفريق عبر GitOps
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: payments         # يُستبدل لكل فريق
spec:
  hard:
    requests.cpu: "40"
    requests.memory: 80Gi
    limits.cpu: "80"
    limits.memory: 160Gi
    pods: "200"
    services: "20"
    persistentvolumeclaims: "10"
    count/jobs.batch: "50"
---
# LimitRange يضع قيم افتراضية لكل حاوية حتى تُحتسب الـ Pods
# التي لا تحدد طلبات صريحة ضمن الحصة ويستطيع Karpenter تحزيمها بكفاءة.
apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: payments
spec:
  limits:
    - type: Container
      default:
        cpu: "500m"
        memory: 512Mi
      defaultRequest:
        cpu: "100m"
        memory: 128Mi
      max:
        cpu: "8"
        memory: 16Gi

دمج Karpenter وميزانيات Spot. مع تشغيل Karpenter من الدرس الرابع، تتمثل أبرز عتلات FinOps في: ضبط consolidationPolicy: WhenUnderutilized على جميع NodePools العامة، وتكوين كتلة disruption.budgets حتى لا يُخلي الدمج أكثر من 20% من الـ Pods في كل NodePool دفعة واحدة، والتحويل الجذري لأعباء العمل غير الحرجة — خطوط المعالجة الدُّفعية وعُمّال CI والعمليات غير المتزامنة — إلى Spot. يُشغّل الفريق الموهوب 60-70% من إجمالي حوسبة الكلاستر على Spot، بوفورات تتراوح بين 1.2 و1.8 مليون دولار سنوياً في المقياس المتوسط (كلاستر من 200 عقدة، مزيج m6i.4xlarge في us-east-1).

توزيع تكلفة السحابة بالعلامات المُطبَّقة في IaC. يجب أن يحمل كل مورد AWS أنشأه Terraform على الأقل: team وenv وservice وcost-centre. طبّق ذلك بكتلة required_providers في Terraform وسياسة OPA تُفحص في CI — فأي دمج يُدخل موارد بدون هذه العلامات يُفشل الخطة. في Kubernetes، ضع تعليقاً توضيحياً على الـ namespaces بـteam وcost-centre واستخدم Kubecost (أو OpenCost) لعرض الإنفاق يومياً لكل namespace.

# استعلام Kubecost للتوزيع — أعلى 10 namespaces حسب تكلفة 7 أيام (REST API)
curl -sG "http://kubecost.platform.internal/model/allocation" \
  --data-urlencode "window=7d" \
  --data-urlencode "aggregate=namespace" \
  --data-urlencode "accumulate=true" \
  | jq '.data[0]
        | to_entries
        | sort_by(-.value.totalCost)
        | .[0:10]
        | map({namespace:.key, cost:.value.totalCost, cpuCost:.value.cpuCost, memCost:.value.ramCost})'

# شكل المخرجات المتوقعة:
# [
#   {"namespace":"ml-training","cost":4812.34,"cpuCost":2100.10,"memCost":1340.22},
#   {"namespace":"payments",   "cost":3201.87,"cpuCost":1890.44,"memCost": 980.11},
#   ...
# ]

# تقرير تكلفة أسبوعي يُرسَل إلى Slack عبر CronJob مجدول على Kubernetes

الإظهار قبل الفوترة الداخلية. تبدأ فرق الشركات الكبرى بـ showback — إظهار التكلفة لكل فريق دون تحريك أموال فعلية. بعد ربعين من البيانات والضبط فقط تتحول إلى chargeback (فوترة داخلية حقيقية). فرض الفوترة الداخلية في اليوم الأول يُولّد مقاومة سياسية تُفشل برنامج FinOps. دع البيانات تبني الثقة أولاً.

تنبيهات الميزانية والحدود الصارمة. في AWS، استخدم Cost Anomaly Detection مع موضوع SNS يُنبّه من يتولى المناوبة عندما يتجاوز الإنفاق خلال 24 ساعة لأي علامة خدمة 150% من متوسط الـ 7 أيام الماضية. اقرنه بإجراء AWS Budget يُطلق تلقائياً Lambda لتقليص مجموعة autoscaling عند تجاوز عتبة الميزانية اليومية. هذا النمط رصد انحداراً في DynamoDB بتكلفة 60 ألف دولار يومياً لدى إحدى شركات التكنولوجيا المالية بعد ساعتين فقط من طرحه — قبل أن يمر الليل.

سطح الخدمة الذاتية للمطورين

المنصة التي تستلزم فتح تذكرة Jira للحصول على namespace جديد ليست منصة — بل هي بيروقراطية مُلفوفة بـ YAML. سطح الخدمة الذاتية هو مجموعة الواجهات التي من خلالها يُهيّئ المهندسون الموارد ويُنشرون ويُراقبون ويُحلّون المشكلات دون تنبيه فريق المنصة. عند مقياس الشركات الكبرى، يتكون هذا السطح من ثلاث طبقات معيارية: كتالوج خدمات وواجهة سطر أوامر للمنصة وقوالب المسار الذهبي.

كتالوج الخدمات (Backstage أو ما يعادله). Backstage المطوَّر بواسطة Spotify هو المعيار الفعلي لبوابة المطورين الداخلية في الشركات التي تتجاوز 500 مهندس. تُسجّل كل خدمة نفسها عبر catalog-info.yaml في جذر مستودعها. يستوعب Backstage هذا الملف ويربطه بلوحات Grafana وسياسات التصعيد في PagerDuty وكتيّبات التشغيل في Confluence وحالة أعباء العمل Kubernetes. يتعرف المهندسون على خدمة جديدة — تبعياتها ومستويات SLO ودورة المناوبة وتاريخ النشر — في دقائق عوضاً عن ساعات.

# catalog-info.yaml — يوجد في جذر كل مستودع خدمة
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payments-api
  description: Core payment processing microservice
  annotations:
    github.com/project-slug: acme/payments-api
    pagerduty.com/service-id: PABC123
    grafana/dashboard-url: https://grafana.internal/d/payments
    runbook-url: https://wiki.internal/runbooks/payments-api
  tags:
    - payments
    - critical-path
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: financial-platform
  dependsOn:
    - component:ledger-service
    - resource:payments-db
  providesApis:
    - payments-rest-api

واجهة سطر أوامر المنصة — plat. تُطلق فرق المنصة الكبيرة واجهة CLI داخلية (تُسمى عادةً plat أو kit أو dx) تُغلّف kubectl وhelm وargocd وأدوات AWS/GCP خلف أوامر فرعية موجَّهة بالرأي. الهدف هو إلغاء كُتيّب "إعداد خدمة جديدة" المكوّن من 14 خطوة واستبداله بأمر واحد. أبرز الأوامر الفرعية الشائعة:

plat new service payments-api --template go-grpc — يُهيّئ المستودع ويُسجّل في Backstage ويُنشئ تطبيق ArgoCD ويُهيّئ الـ namespace بالحصة الافتراضية وNetworkPolicy
plat promote payments-api --from staging --to production — يُثبّت digest الصورة وينشئ PR لـ GitOps على الطبقة الإنتاجية مربوطاً بتذكرة إدارة التغييرات
plat logs payments-api --tail 200 --env production — يبثّ البيانات من مُجمّع Loki/CloudWatch لـ Pods الخدمة دون الحاجة لمعرفة محددات التصنيف
plat status payments-api — يُظهر حالة الطرح ومعدل حرق SLO وآخر 5 عمليات نشر في عرض واحد

قِس الوقت حتى أول نشر. المقياس المعياري لسطح الخدمة الذاتية هو Time To First Deploy (TTFD): المدة من "المهندس لديه صلاحية الوصول للمستودع" إلى "الخدمة تعمل في بيئة staging." في Stripe يقل هذا عن 15 دقيقة للخدمات الصغيرة القياسية. راقب TTFD بطوابع زمنية في pipeline الـ CI وتتبّعه كـ SLO للمنصة. حين يتراجع تُحقّق فريق المنصة — لا مهندسو المنتج.

ضمانات FinOps (يسار) وسطح الخدمة الذاتية للمطورين (يمين) بوصفهما ركيزتَي نضج المنصة.

قوالب المسار الذهبي. المسار الذهبي هو طريقة موجَّهة ومُعتمدة مسبقاً لبناء نوع معين من الخدمات ونشرها — خدمة Go gRPC أو تطبيق React SPA أو عامل Python ML — مدمجٌ فيها كل إعدادات المنصة الافتراضية: طلبات الموارد وNetworkPolicy وتعليقات Istio التوضيحية وحقن sidecar لـ OTel وسجلات الصور المُعتمدة بـ Kyverno وpipeline CI/CD عاملة. يُنفق الفِرَق التي تسلك المسار الذهبي وقتاً صفرياً على تهيئة المنصة ويُركّزون كلياً على شيفرة المنتج. يحتفظ فريق المنصة بالقوالب في مستودع platform-templates؛ تُطلق قوالب Backstage البرمجية cookiecutter أو copier وتفتح PR ضد مستودع جديد في منظمة GitHub الهندسية.

فخ "افتح PR فقط". تطلب بعض الفرق أحياناً من المنصة منحها وصولاً مباشراً للكتابة في الكلاستر "للتحرك بسرعة أكبر." هذا اقتصاد وهمي. كل فريق يتجاوز GitOps يُضيف سطحاً لا تستطيع المنصة تدقيقه أو التراجع عنه أو رصده في توزيع التكلفة. يجب أن يكون سطح الخدمة الذاتية المسار الوحيد — وأن يكون سريعاً بما يكفي لتفضيله. إذا كان المهندسون يتجاوزون المنصة، الاستجابة الصحيحة هي تسريع المنصة، لا منح وصول خام للكلاستر.

الطرق المُمهَّدة ومخارج الطوارئ. في منصات الشركات الكبرى الناضجة (Netflix Paved Roads وSpotify System Model وAirbnb OneTouch)، يوجد مخرج طوارئ مقصود: الفرق التي لديها سبب مشروع للانحراف عن المسار الذهبي تستطيع ذلك عبر عملية RFC، لكنها تتحمل العبء التشغيلي للانحراف. يُنشئ هذا حلقة تغذية راجعة إيجابية — كلما كان الحفاظ على الانحراف مُكلفاً، كلما تقارب عدد أكبر من الفرق نحو الطريق الممهّد. يراجع فريق المنصة الانحرافات ربع سنوياً ويستوعب الأنماط التي أثبتت جدارتها في مسارات ذهبية جديدة.

بنهاية هذا الدرس، أصبحت لمنصة المشروع الختامي كل ضماناتها في مكانها: ضوابط FinOps تمنع مفاجآت التكلفة، وكتالوج خدمات يمنح كل مهندس نافذة عرض واحدة، وواجهة CLI ومكتبة قوالب تجعل الصواب هو الأسهل. يُجمّع الدرس العاشر الصورة الكاملة ويناقش مسار هذه المهنة وما يليه.