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

مشروع: تصميم منصة مطورين داخلية

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

مشروع: تصميم منصة مطورين داخلية

يرشدنا هذا الدرس الختامي خطوةً بخطوة عبر تصميم منصة مطورين داخلية (IDP) لمنظمة نموذجية — Acme Corp — شركة فينتك تضم 400 مهندس وتشغّل 120 خدمة مصغّرة على Kubernetes عبر منطقتَي AWS. بنهاية الدرس ستمتلك مواصفة مسار ذهبي متكاملة، وتصميماً لسطح الخدمة الذاتية، وقالب Backstage scaffolder الذي يشغّله، وتركيبة Crossplane لقواعد بيانات PostgreSQL عند الطلب، وسياسات Kyverno التي تفرض الحواجز الوقائية — كل أداة جاهزة للإسقاط في مستودع حقيقي.

الخطوة الأولى — توصيف المنظمة

قبل كتابة سطر YAML واحد، اجمع أربعة مدخلات:

تصنيف الخدمات. لدى Acme ثلاثة أنماط: خدمة API (Java/Go، REST/gRPC)، عامل غير متزامن (Kafka consumer، Python/Go)، واستدلال تعلم آلي (Python، GPU اختياري). كل مسار ذهبي يقابل نمطاً واحداً.
مسح الأعباء المعرفية. استطلاع من 10 أسئلة للمطورين يكشف أبرز أربع نقاط ألم: (1) كتابة YAML لـ Kubernetes من الصفر، (2) توفير قواعد البيانات، (3) توصيل Datadog APM، (4) ضبط RBAC. هذه تصبح أوائل أربع إجراءات ذاتية على المنصة.
متطلبات الامتثال. نطاق PCI-DSS لعنقود المدفوعات يعني: صور حاويات غير قابلة للتغيير (لا :latest)، لا حاويات تعمل بصلاحيات root، سياسة شبكة إلزامية، وأسرار من Vault (ليس متغيرات بيئة). هذه تصبح سياسات Kyverno مُفعَّلة عند القبول.
جرد الأصول الموجودة. لدى Acme بالفعل: وحدات Terraform لـ VPC/EKS، وتركيب Vault PKI، وعميل Datadog كـ DaemonSet، و40 مخطط Helm متفاوت الجودة. المنصة تُغلّف هذه الأصول ولا تستبدلها.

الخطوة الثانية — تعريف المسار الذهبي لخدمة API

المسار الذهبي هو مسار تسليم محدد ومُوجَّه بالكامل من git init حتى الإنتاج. لنمط خدمة API في Acme، يشمل ستة أبعاد:

السقالة. قالب Backstage Software Template يولّد هيكل المستودع (Dockerfile، Makefile، .github/workflows/ci.yaml، مانيفستات k8s/، catalog-info.yaml، بذرة TechDocs) في أقل من 60 ثانية.
خط CI. GitHub Actions: فحص → اختبار وحدة → docker build --provenance=true --sbom=true → فحص Trivy (حظر عند CRITICAL) → رفع إلى ECR بعلامة ثابتة sha-<commit> → تحديث مستودع GitOps عبر PR.
التسليم عبر GitOps. تطبيق ArgoCD CR لكل بيئة (staging، production). البيئة التجريبية تتزامن تلقائياً؛ الإنتاج يتطلب موافقة يدوية.
بيئة التشغيل. مخطط Helm مُختبر مسبقاً بقيم افتراضية مدروسة: HPA، PodDisruptionBudget، Istio sidecar مُفعَّل، حقن Datadog APM.
المراقبة. لوحة Datadog تلقائية ومستوى خدمة افتراضي (99.5% نجاح، 300 مللي ثانية كامن p99) مربوط بخدمة PagerDuty.
الأمان. Vault AppRole محقون عبر Vault Agent Sidecar؛ mTLS عبر Istio؛ NetworkPolicy ترفض كل دخول غير الشبكة الداخلية وبوابة المراقبة.

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

الخطوة الثالثة — تصميم سطح الخدمة الذاتية

سطح الخدمة الذاتية هو ما يتعامل معه المطورون فعلياً بالنقر أو الكتابة. Acme تقدّم ثلاثة أسطح:

بوابة Backstage — الواجهة الرئيسية. قوالب برمجية للسقالة؛ كتالوج برمجيات للاكتشاف؛ TechDocs للتوثيق؛ بطاقات تقييم لكل خدمة.
أداة سطر الأوامر (acme) — تُغلّف استدعاءات Backstage scaffolder API للمهندسين العاملين في الطرفية. acme new service، acme provision db، acme open-dash <service>.
الخدمة الذاتية عبر GitOps — لعناصر البنية التحتية (قواعد بيانات، حاويات تخزين، طوابير)، الإجراء الذاتي يفتح PR في مستودع GitOps للمنصة. مراجع بشري أو روبوت سياسات يوافق؛ Crossplane يُوفّر الموارد. هذا يُبقي مسار مراجعة كامل في git — ضرورة حتمية لـ PCI-DSS.

إجراء Backstage scaffolder لـ PostgreSQL عند الطلب هو أكثر إجراء ذاتي استخداماً (يُشغَّل نحو 40 مرة شهرياً في Acme). ينشئ مطالبة Crossplane PostgreSQLInstance، يُعيدها إلى مستودع GitOps، ويفتح PR موسوماً بمفتاح مشروع JIRA للفريق الطالب:

# إجراء Backstage scaffolder: acme:provision-postgres
# packages/backend/src/plugins/scaffolder/actions/provisionPostgres.ts (مبسَّط)

import { createTemplateAction } from '@backstage/plugin-scaffolder-node';
import { Octokit } from '@octokit/rest';

export const createProvisionPostgresAction = () =>
  createTemplateAction<{
    serviceName: string;
    environment: 'staging' | 'production';
    storageSizeGi: number;
  }>({
    id: 'acme:provision-postgres',
    schema: {
      input: {
        required: ['serviceName', 'environment', 'storageSizeGi'],
        properties: {
          serviceName: { type: 'string' },
          environment: { type: 'string', enum: ['staging', 'production'] },
          storageSizeGi: { type: 'number', minimum: 10, maximum: 500 },
        },
      },
    },
    async handler(ctx) {
      const { serviceName, environment, storageSizeGi } = ctx.input;
      const claimYaml = `
apiVersion: platform.acme.io/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: ${serviceName}-${environment}
  namespace: ${serviceName}
spec:
  parameters:
    storageSizeGi: ${storageSizeGi}
    version: "15"
    highAvailability: ${environment === 'production'}
  writeConnectionSecretToRef:
    name: ${serviceName}-postgres-creds
`;
      const octokit = new Octokit({ auth: ctx.secrets?.githubToken });
      await octokit.repos.createOrUpdateFileContents({
        owner: 'acme-corp',
        repo: 'platform-gitops',
        path: `claims/${environment}/${serviceName}-postgres.yaml`,
        message: `chore: provision postgres for ${serviceName} (${environment})`,
        content: Buffer.from(claimYaml).toString('base64'),
        branch: `provision-${serviceName}-postgres-${Date.now()}`,
      });
      ctx.logger.info(`Postgres claim PR opened for ${serviceName} in ${environment}`);
    },
  });

الخطوة الرابعة — مخطط معمارية المنصة

يوضح المخطط أدناه كيف تتفاعل المستويات الأربعة لمنصة Acme في وقت التشغيل: مستوى المطور، ومستوى التحكم (Backstage + منصة API)، ومستوى التسليم (GitOps)، ومستوى البنية التحتية (Crossplane + واجهات برمجة السحابة).

بنية IDP في Acme Corp — أربعة مستويات: المطور، التحكم، التسليم، والبنية التحتية.

الخطوة الخامسة — فرض الحواجز الوقائية بـ Kyverno

الحواجز الوقائية هي السياسات التي تجعل المسار الذهبي جديراً بالثقة. Acme تُشغّل أربع ClusterPolicies لـ Kyverno تُطبَّق على كل namespace باستثناء kube-system:

# سياسة: require-immutable-image-tag.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-immutable-image-tag
  annotations:
    policies.kyverno.io/category: Best Practices
    policies.kyverno.io/description: >
      تحظر :latest والعلامات القابلة للتغيير؛ يجب أن تستخدم جميع الصور علامة sha-<commit>.
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: check-image-tag
    match:
      any:
      - resources:
          kinds: [Pod]
          namespaceSelector:
            matchExpressions:
            - key: kubernetes.io/metadata.name
              operator: NotIn
              values: [kube-system, monitoring, vault]
    validate:
      message: "يجب أن تتطابق علامة الصورة مع sha-[a-f0-9]{7,40}. :latest محظور."
      pattern:
        spec:
          containers:
          - image: "*:sha-?([a-f0-9]{7,40})*"
---
# سياسة: require-non-root.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-non-root
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-non-root
    match:
      any:
      - resources:
          kinds: [Pod]
    validate:
      message: "يجب ألا تعمل الحاويات بصلاحيات root (مطلوب runAsNonRoot: true)."
      pattern:
        spec:
          securityContext:
            runAsNonRoot: true
          containers:
          - securityContext:
              allowPrivilegeEscalation: false

الخطوة السادسة — قياس نجاح المنصة

منصة بلا مقاييس هي فريق منصة يعمل على الأمل. Acme يتتبع أربعة KPIs مُحاذاة لـ DORA بدقة أسبوعية:

وقت الإعداد حتى أول نشر — الهدف: أقل من ساعتين من acme new service حتى أول مزامنة ArgoCD للبيئة التجريبية.
معدل نجاح الخدمة الذاتية — نسبة طلبات توفير قواعد البيانات والطوابير التي تكتمل دون تذكرة لفريق المنصة. الهدف: أكثر من 90%.
معدل التبني في المسار الذهبي — نسبة الخدمات ذات نقاط Backstage scorecard أعلى من 80/100. الهدف: أكثر من 75% من الخدمات.
كامن API للمنصة عند p99 — يجب أن تستجيب Backstage backend وplatform API في أقل من 200 مللي ثانية p99. تجاوز هذا المستوى ينبّه فريق المنصة.

انشر لوحة مقاييس المنصة علناً داخل مؤسستك. عندما يرى الفرق الإنتاجية أن 87% من الخدمات على المسار الذهبي وأن وقت الإعداد انخفض من 3 أيام إلى 90 دقيقة، يكسب فريق المنصة ثقة المؤسسة وميزانية المرحلة التالية. الإفصاح عن البيانات ميزة منتج بذاتها.

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

تجميع كل شيء معاً

تُشحن منصة Acme ك mono-repo: platform-gitops/ يحمل الحالة المرغوبة (ArgoCD ApplicationSets، Crossplane Compositions، سياسات Kyverno، سياسات Vault)؛ platform-backstage/ يحمل البوابة؛ acme-cli/ يحمل أداة سطر الأوامر. كل مكوّن مُصدَر بإصدار مستقل ومُنشَر عبر خط GitOps الخاص به وله مستوى خدمة محدد. فريق المنصة يتعامل مع هذا المكدس كمنتج: له خارطة طريق، وسجل تغييرات، وسياسة إيقاف، ودوارة مناوبة للحوادث. هذا العقل الإنتاجي — لا اختيار أدوات بعينها — هو ما يُميّز المنصات القابلة للتوسع عن المنصات التي تتحول إلى إرث تقني.