هندسة المنصات وتجربة المطورين

البنية التحتية ذاتية الخدمة

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

البنية التحتية ذاتية الخدمة

في عام 2010 كان المطور الذي يحتاج قاعدة بيانات ينتظر تذكرة دعم. كان فريق DBA يوفرها في أسبوعين. في عام 2025 يفتح المطور ذاته بوابة المطور الداخلية، يملأ نموذجاً — المحرك، الإصدار، فئة التخزين، جدول النسخ الاحتياطي — يضغط إنشاء، ويحصل على قاعدة بيانات جاهزة ومتوافقة مع السياسات في أربع دقائق. البنية التحتية لا تزال تُوفَّر عبر نفس واجهات برمجة السحابة. الفرق هو من يقودها، وما إذا كانت الحواجز تمنع النتائج السيئة لحظة اتخاذ القرار بدلاً من بعد مراجعة ما بعد الحادثة.

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

لماذا واجهات برمجة المنصة لا واجهات السحابة المباشرة

تكشف كل سحابة رئيسية عن آلاف أنواع الموارد عبر مئات أسطح واجهات برمجة التطبيقات. مثيل RDS واحد يتطلب قرارات حول مجموعات الشبكات الفرعية، ومجموعات المعاملات، وأدوار IAM، ومفاتيح KMS، وقواعد مجموعة الأمان، ونوافذ النسخ الاحتياطي، وحماية الحذف، وطوبولوجيا متعددة التوفر. المطور لا يجب أن يتخذ أياً من تلك القرارات — فهي قرارات تنظيمية، تُتخذ مرة واحدة، وتُرمَّز في واجهة برمجة المنصة.

واجهة برمجة المنصة هي تجريد موجَّه ومحدد تنظيمياً. بدلاً من aws_db_instance بخمسين سمة، يرى المطور PostgresDatabase بخمس سمات: الاسم، الحجم (صغير/متوسط/كبير)، البيئة، سياسة النسخ الاحتياطي، والفريق المالك. تُعيِّن واجهة برمجة المنصة تلك المدخلات الخمس إلى الخمسة والأربعين مدخلاً للبنية التحتية التي تعكس معايير مؤسستك. هذا هو المسار الذهبي من الدرس السابق مُطبَّق آلياً.

العقد الذي يجب أن تفي به واجهة برمجة المنصة:

متبادلة: استدعاؤها مرتين بنفس المدخل ينتج نفس النتيجة؛ آمن لإعادة التطبيق عند الكشف عن انجراف.
قابلة للرصد: يمكن للمستدعين استطلاع حالة طلبهم أو مشاهدتها؛ النظام يُصدر أحداثاً عند انتقالات الحالة.
موثِّقة لنفسها: المخطط قابل للقراءة آلياً (OpenAPI أو Kubernetes CRD) بحيث تشتق منه البوابة وواجهة السطر والمحرك السياساتي من مصدر حقيقة واحد.
قابلة للتدقيق: كل تعديل يحمل هوية الممثل، والطابع الزمني، والسبب — مكتوباً في سجل تدقيق غير قابل للتغيير قبل إجراء أي استدعاء لواجهة برمجة السحابة.

Kubernetes CRDs كسطح عالمي لواجهة برمجة المنصة. Crossplane وربط Backstage بالسقالات ومعظم تطبيقات IDP اليوم تُصمِّم موارد المنصة على هيئة موارد Kubernetes مخصصة. هذا يمنحك كل آلية Kubernetes API مجاناً: خطاطيف القبول للتحقق، وRBAC للتفويض، وkubectl للوصول عبر السطر، وواجهة watch للحالة الفورية. مطوروك يعرفون بالفعل قراءة مانيفست YAML؛ لست بحاجة لبناء SDK عميل جديد.

Crossplane: مستوى التحكم كأساس للمنصة

يُمدد Crossplane كوبرنيتس ليصبح مستوى تحكم عالمياً لأي بنية تحتية. يُضيف ثلاثة أولويات فوق كوبرنيتس القياسي:

Provider: حاوية متحكم تترجم موارد Crossplane إلى استدعاءات واجهة برمجة سحابة حقيقية (AWS، GCP، Azure، Vault، Helm، Terraform — هناك أكثر من 200 provider رسمي). يشحن كل provider بـ CRDs الخاصة به: CRD واحد لكل نوع مورد سحابي.
CompositeResourceDefinition (XRD): يُعرِّف نوع واجهة برمجة المنصة المخصصة — مثلاً PostgresDatabase — كمخطط CRD. هذا هو نوع المورد الذي يستهدفه المطورون ونماذج البوابة.
Composition: تعيين من مطالبة PostgresDatabase عالية المستوى إلى موارد provider منخفضة المستوى (VPC، مجموعة شبكة فرعية، دور IAM، مثيل RDS، سجل Route 53) مع جميع آراء المؤسسة مدمجة فيه.

حلقة التوفيق هي كوبرنيتس خالص: يُطبِّق مطور مانيفست PostgresDatabase؛ يقرأ متحكم Crossplane المركب الـ Composition ويُجسِّد موارد provider المكوِّنة لها؛ يُوافق كل متحكم provider تلك الموارد مع واجهة برمجة السحابة الحقيقية ويكتب الحالة عائداً. يشاهد المطور حقل الحالة في مطالبته؛ فريق المنصة لا يلمس تذكرة واحدة.

# الخطوة 1 — تثبيت Crossplane في حزمة المنصة
helm repo add crossplane-stable https://charts.crossplane.io/stable
helm install crossplane crossplane-stable/crossplane \
  --namespace crossplane-system --create-namespace \
  --set args='{--enable-composition-revisions}'

# الخطوة 2 — تثبيت AWS provider (بيانات الاعتماد عبر دور IRSA موجود)
cat <<EOF | kubectl apply -f -
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-aws-rds
spec:
  package: xpkg.upbound.io/upbound/provider-aws-rds:v1.7.0
  controllerConfigRef:
    name: irsa-provider-config
---
apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
metadata:
  name: irsa-provider-config
spec:
  serviceAccountAnnotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/CrossplaneRDSRole
EOF

# الخطوة 3 — تعريف نوع واجهة برمجة المنصة (XRD)
cat <<EOF | kubectl apply -f -
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xpostgresdatabases.platform.example.com
spec:
  group: platform.example.com
  names:
    kind: XPostgresDatabase
    plural: xpostgresdatabases
  claimNames:
    kind: PostgresDatabase
    plural: postgresdatabases
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                size:
                  type: string
                  enum: [small, medium, large]
                environment:
                  type: string
                  enum: [dev, staging, prod]
                ownerTeam:
                  type: string
              required: [size, environment, ownerTeam]
EOF

بمجرد تسجيل الـ XRD، يمكن للمطور المطالبة بقاعدة بيانات في أي namespace يملك صلاحية الكتابة فيه. لا يرى مجموعات معاملات RDS ولا معرفات الشبكات الفرعية ولا معرفات مفاتيح KMS — تلك تعيش في الـ Composition المملوك لفريق المنصة:

# مطالبة المطور (تذهب إلى namespace تطبيق الفريق)
apiVersion: platform.example.com/v1alpha1
kind: PostgresDatabase
metadata:
  name: payments-db
  namespace: team-payments
  annotations:
    platform.example.com/owner: payments-team@example.com
    platform.example.com/cost-center: "CC-4421"
spec:
  size: medium
  environment: prod
  ownerTeam: payments

# مشاهدة الحالة حتى الجاهزية (عادة 3-5 دقائق لـ RDS)
kubectl get postgresDatabase payments-db -n team-payments -w

# NAME          SYNCED   READY   CONNECTION-SECRET   AGE
# payments-db   True     True    payments-db-creds    4m32s

عدِّل نسخ الـ Compositions، ليس فقط XRDs. تدعم Crossplane مراجعات Composition. حين تُحدِّث سياسة تنظيمية — مثلاً إلزام تشفير التخزين بمفتاح KMS جديد — انشر نسخة Composition جديدة واستخدم compositeDeletePolicy: Foreground. المطالبات الحالية تبقى على النسخة القديمة؛ المطالبات الجديدة تأخذ النسخة الجديدة. هذا يمنحك مسار ترحيل آمناً دون يوم تغيير جذري يكسر كل البنية التحتية الحالية. تستخدم أدوات المنصة الداخلية لـ Google نفس نموذج المراجعات — لا تُعدِّل البنية التحتية تحت أحمال العمل الجارية بدون نافذة انتقال.

طبقات التجريد: مجموعة مستوى التحكم

نادراً ما يُستخدم Crossplane وحده. تُرتِّب منصات الإنتاج طبقات متعددة من مستويات التحكم ومستويات التجريد. المجموعة القياسية على مقياس التقنية الكبرى تبدو هكذا، من أعلى تجريداً إلى أدناه:

بوابة المطور / مانيفست GitOps: نقطة دخول المطور. يُصيِّر قالب Backstage نموذجاً، يلتزم بـ YAML لـ PostgresDatabase في مستودع GitOps للفريق، ويزامن تطبيق Flux أو Argo CD إلى حزمة المنصة.
واجهة برمجة المنصة (Crossplane XRD / Claim): العقد التنظيمي. يتحقق من المدخلات، يُطبِّق اتفاقيات التسمية عبر خطاف قبول، يختم التسميات الافتراضية (مركز التكلفة، الفريق، البيئة)، ويوجِّه إلى الـ Composition الصحيح استناداً إلى البيئة.
Composition: الرأي التنظيمي. يُعيِّن المطالبة إلى مجموعة من الموارد المُدارة مع جميع الإعدادات الافتراضية المتصلَّبة: التشفير في وضع السكون، متعدد التوفر للإنتاج، احتفاظ النسخ الاحتياطية، حماية الحذف، مجموعة الأمان التي تسمح فقط بـ CIDR pods التطبيق.
موارد Provider المُدارة: طبقة ترجمة واجهة برمجة السحابة. CRD provider واحد لكل نوع مورد سحابي (مثل RDSInstance، SubnetGroup، DBParameterGroup). يستدعي متحكم provider AWS SDK ويُوافق باستمرار.
مستوى تحكم السحابة (AWS/GCP/Azure): البنية التحتية الفعلية. يُصادق provider عبر IRSA/Workload Identity، يُجري استدعاءات API بأقل امتياز نطاقها حساب أو مشروع واحد لكل بيئة.

كل طبقة تترجم نية عالية المستوى إلى عمليات موارد أدنى مستوى. يتفاعل المطورون فقط مع الطبقتين الأولى والثانية؛ السياسة التنظيمية تعيش في الطبقة الثالثة؛ السحابة لا ترى سوى استدعاءات API بأقل امتياز في الطبقة الخامسة.

الحواجز: السياسة قبل التوفير

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

التحقق من المخطط (XRD openAPIV3Schema): يرفض المطالبات المشوهة عند القبول. المطور لا يستطيع طلب size: xlarge إذا كان التعداد يسمح فقط بصغير/متوسط/كبير. هذه بوابة متزامنة بزمن استجابة صفري.
سياسات قبول OPA/Kyverno: منطق أعمال لا يستطيع مخطط XRD التعبير عنه. أمثلة: موارد الإنتاج تتطلب تسمية مركز التكلفة؛ لا يجوز لـ namespace مطور توفير أكثر من ثلاث قواعد بيانات؛ الإصدار الرئيسي لـ RDS يجب أن يكون على القائمة المعتمدة. سياسات Kyverno هي CRDs بحد ذاتها — خاضعة للتحكم بالنسخ جنباً إلى جنب مع كود المنصة.
الإعدادات الافتراضية المُطبَّقة بواسطة Composition: حتى لو قدَّم مطور مطالبة صالحة، تُطبِّق الـ Composition إعدادات عامة للمنصة لا يمكن تجاوزها: deletionPolicy: Delete فقط للتطوير، وOrphan للإنتاج؛ التشفير مُطبَّق بصرف النظر عما تقوله المطالبة؛ الحد الأدنى لاحتفاظ النسخ الاحتياطية 7 أيام في الإنتاج بصرف النظر عن قيمة حقل backupPolicy.

# Kyverno ClusterPolicy: اشتراط تسمية مركز التكلفة على جميع مطالبات المنصة
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-cost-center-label
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: check-cost-center
      match:
        any:
          - resources:
              kinds:
                - PostgresDatabase
                - RedisCluster
                - KafkaTopic
              namespaceSelector:
                matchLabels:
                  environment: prod
      validate:
        message: "Production platform resources must carry a platform.example.com/cost-center annotation."
        pattern:
          metadata:
            annotations:
              platform.example.com/cost-center: "?*"

انجراف Composition هو القاتل الصامت للمنصات ذاتية الخدمة. بمجرد أن يثق المطورون بالمنصة لتطبيق الإعدادات الصحيحة، يتوقفون عن مراجعة الموارد الفردية. إذا أزال تغيير Composition عن غير قصد قاعدة احتفاظ بنسخ احتياطية أو خفَّف قاعدة مجموعة أمان، قد تُعدَّ مئات قواعد البيانات بشكل خاطئ قبل أن يلاحظ أحد. عامل كل تغيير Composition كتغيير إنتاجي: اطلب مراجعة PR من فريق الأمان، شغِّل اختبار وحدة Crossplane composition (crossplane beta render)، وانشر الفرق في الموارد المُصيَّرة قبل الدمج. في Spotify، كل PR لـ Composition يتضمن فرق الموارد المُصيَّرة كأثر مراجعة إلزامي.

أنماط الفشل الإنتاجية

تُظهر البنية التحتية ذاتية الخدمة أنماط فشل خاصة بها تختلف عن البنية التحتية الموفَّرة يدوياً:

تتالي تقييد Provider: Composition تُنشئ عشرة موارد مُدارة في وقت واحد ستُجري عشرة استدعاءات لواجهة برمجة السحابة بالتوازي. على النطاق الواسع — 50 فريقاً يُنشئون قواعد بيانات في وقت واحد أثناء تدوير الأسطول — ستصطدم بحدود معدل API الخاص بـ AWS. تكشف providers لـ Crossplane عن علامتَي --max-reconcile-rate و--poll-interval. اضبطهما: 10 كحد أقصى لمعدل التوفيق، و10 دقائق كفاصل استطلاع، نقطة بداية معقولة لـ RDS على مقياس 500 مورد.
موارد يتيمة من compositions فاشلة: إذا أنشأت Composition موارد A وB وC وفشل إنشاء C فشلاً دائماً، قد يبقى المورد A وB — مُفوتَران، غير محميَّان، غير مُراقَبَيْن. طبِّق متحكم تنظيف قائم على finalizer وأنذر على مطالبات XPostgresDatabase العالقة في Synced: False لأكثر من 30 دقيقة.
نطاق دور IRSA واسع جداً: كثير من الفرق تُنشئ دور IAM واحداً عابراً للحسابات لـ Crossplane provider بأكمله. حاوية provider مُخترَقة حينئذٍ لها وصول كتابة لجميع موارد السحابة في الحساب. استخدم ProviderConfig منفصلاً لكل بيئة وقيِّد كل دور IAM إلى نوع مورد واحد عبر مفاتيح الشرط (rds:* فقط، لا *:*).

البنية التحتية ذاتية الخدمة المُنفَّذة بشكل جيد تكون غير مرئية للمطورين وقابلة للتدقيق للجميع الآخرين. يحصل المطور على قاعدة بيانات في أربع دقائق؛ يرى فريق الأمان مسار تدقيق كامل؛ يجد فريق المالية تسمية مركز التكلفة على كل مورد؛ يقضي فريق المنصة صفراً من الوقت على التذاكر. وقت التوفير الأربع دقائق — مع الامتثال الكامل للسياسات مدمجاً فيه — هو المقياس المنتجي الملموس الذي يُبرر بناء المنصة من الأساس.