هندسة المنصات مقابل DevOps: شو اللي فعلاً تغير (وشو ما تغير)

التحول من DevOps لهندسة المنصات

DevOps قال "إنت بتبنيه، إنت بتشغّله." كل مطور يدير بنيته التحتية بنفسه، يعمل deploy لخدماته بنفسه، يضبط monitoring تبعه بنفسه. نظرياً، هالشي يخلق ملكية. عملياً، يطلعلك 15 طريقة مختلفة لعمل deploy لخدمة، 8 إعدادات monitoring مختلفة، وكل فريق يعيد اختراع نفس CI/CD pipeline.

هندسة المنصات هي التصحيح. بدل ما كل فريق يبني بنية تحتية من الصفر، فريق المنصة يوفر أدوات مبنية على رأي واضح وخدمة ذاتية تخلي الشي الصح سهل والشي الغلط صعب.

التحول حقيقي بس مبالغ فيه. للفرق أقل من 30 مهندس، هندسة المنصات غالباً عبء إضافي. للفرق فوق الـ 50، ضرورية. هالمقال يغطي الأنماط العملية. كيف ننشر البنية التحتية عندنا، شوفه بدليل IaC ودليل Kubernetes.

شو هي هندسة المنصات فعلاً

هندسة المنصات مش أداة. مش Backstage. مش Kubernetes. هي نهج: ابنِ أدوات داخلية تخلي المطورين منتجين بدون ما يحتاجوا يصيروا خبراء بنية تحتية.

المقياس الأساسي: الوقت لأول deploy لخدمة جديدة. إذا مطور يحتاج يومين عشان يروح من "أحتاج خدمة جديدة" لـ "شغّالة بالـ staging"، منصتك فيها مشكلة. إذا ياخذ 15 دقيقة، منصتك شغّالة.

Golden Paths

الـ golden path هو قالب مبني على رأي واضح لإنشاء خدمة جديدة. يشمل كل شي المطور يحتاجه: هيكل المشروع، CI/CD pipeline، Dockerfile، Kubernetes manifests، إعداد monitoring، وتوثيق.

golden-path-typescript-api/
├── src/
│   ├── index.ts                    # نقطة الدخول مع health check
│   ├── routes/                     # تعريفات المسارات
│   └── services/                   # منطق العمل
├── test/
│   ├── unit/
│   └── integration/
├── Dockerfile                      # بناء multi-stage محسّن
├── .github/workflows/
│   └── ci-cd.yaml                  # بناء، اختبار، دفع، نشر
├── kubernetes/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── kustomization.yaml
│   └── overlay/
│       ├── staging/
│       └── production/
├── monitoring/
│   ├── alerts.yaml                 # قواعد تنبيه قياسية
│   └── dashboard.json              # قالب Grafana dashboard
├── docs/
│   └── runbook.md                  # قالب runbook للتشغيل
├── .env.example
├── package.json
├── tsconfig.json
└── README.md

المطور يشغّل platform create-service --name my-api --template typescript-api، يجاوب على 5 أسئلة (اسم الخدمة، الفريق، هل يحتاج قاعدة بيانات، عامة أو داخلية)، ويحصل على مشروع شغّال بالكامل مع CI/CD وmonitoring وdeployment manifests. أول deploy بـ 15 دقيقة.

مبادئ Golden Path

شو الفرق بين golden path جيد وسيء

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

المطورين ما لازم يفتحوا تذكرة عشان ياخذوا قاعدة بيانات، أو Redis instance، أو Kubernetes namespace جديد. الخدمة الذاتية يعني يقدروا يوفروا اللي يحتاجوه عبر UI أو CLI أو API.

// Platform CLI: توفير قاعدة بيانات PostgreSQL
// $ platform db create --name my-api-db --size small --env staging
interface DatabaseRequest {
    name: string;
    size: 'small' | 'medium' | 'large';  // مبني على رأي: 3 أحجام، مش مواصفات عشوائية
    environment: 'dev' | 'staging' | 'production';
    team: string;
    backupRetention: number;  // الافتراضي: 7 أيام staging، 30 يوم production
}

// وراء الكواليس: Terraform يشتغل، ينشئ RDS instance،
// يخزن credentials بـ Secrets Manager، ينشئ K8s secret،
// يضيف monitoring dashboard، يبلّغ الفريق

شو اللي لازم يكون خدمة ذاتية

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

بوابات المطورين الداخلية

بوابة المطورين الداخلية هي كتالوج لكل الخدمات، أصحابها، APIs تبعها، runbooks تبعها، وحالتها الصحية. Backstage (من Spotify) الأشهر، بس مش الخيار الوحيد.

شو لازم البوابة تعرض

Backstage مقابل البدائل

للفرق أقل من 30 مهندس، Backstage مبالغة. ريبو Git منظم مع ملفات README، ويكي Notion مشترك، وجدول بيانات بسيط لكتالوج الخدمات يغطي 80% من الاحتياج.

للفرق فوق 50 مهندس، مشكلة الكتالوج تصير حقيقية. خدمات تنشأ وتنتسى. أصحابها يمشوا وما حدا يعرف مين يصين شو. بوابة مع تتبع الملكية وhealth dashboards تصير ضرورية.

مشكلة التوثيق

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

توثيق يشتغل

Architecture Decision Records (ADRs)

كل قرار تقني مهم ياخذ ADR:

# ADR-003: استخدام PostgreSQL كقاعدة بيانات رئيسية

## الحالة: مقبول

## السياق
نحتاج قاعدة بيانات للخدمة الجديدة. الخيارات المدروسة: PostgreSQL، MySQL، DynamoDB.

## القرار
PostgreSQL 15 عبر توفير قاعدة البيانات بالخدمة الذاتية من المنصة.

## النتائج
- الأدوات القياسية (نسخ احتياطي، monitoring، migrations) تشتغل مباشرة
- الفريق ما يحتاج خبرة DynamoDB
- latency أعلى شوي من DynamoDB لأنماط الوصول key-value (مقبول)

الـ ADRs تمنع إعادة مناقشة نفس القرارات. لما عضو جديد بالفريق يسأل "ليش PostgreSQL؟"، الجواب بالريبو، مش بذاكرة حدا.

قياس تجربة المطور

إذا عم تستثمر بمنصة، قِس إذا فعلاً عم تساعد:

الأربعة الأولى مقاييس DORA. الثلاثة الأخيرة خاصة بالمنصة. تتبّع الكل. إذا time-to-first-deploy عم يتحسن بس رضا المطورين عم ينزل، المنصة عم تضيف تعقيد بدون قيمة.

متى هندسة المنصات تكون عبء

هندسة المنصات مش مجانية. فريق منصة يكلف 2-5 مهندسين بدوام كامل. Golden paths يحتاجوا صيانة. أدوات الخدمة الذاتية تحتاج تطوير ودعم. البوابة تحتاج محتوى.

لا تبني منصة لما

• فريقك أقل من 20 مهندس (العبء يتجاوز الفائدة)
• عندك أقل من 5 خدمات (مش كفاية فرصة للتوحيد)
• إنت ستارتب ممكن يغير اتجاهه (المنصة رح تروح هدر)
• عملية الهندسة عندك سريعة أصلاً (إذا time-to-deploy أصلاً 30 دقيقة، ما تحتاج فريق منصة يحسنه)

ابنِ منصة لما

• عندك 50+ مهندس ينشروا 10+ خدمة
• إنشاء خدمة جديدة ياخذ أكثر من يوم
• الفرق عم تعيد اختراع نفس أنماط البنية التحتية
• الـ on-call مؤلم لأن كل خدمة عندها monitoring مختلف
• رضا المطورين منخفض بسبب احتكاك البنية التحتية

المنصة الدنيا القابلة للتطبيق لفريق من 30-50 شخص:

1. قالب golden path واحد (نوع الخدمة الأكثر شيوعاً)
2. قالب CI/CD pipeline (مشترك، بمعاملات)
3. monitoring قياسي (Grafana dashboards تتوفر تلقائياً)
4. كتالوج خدمات (حتى لو بس جدول بيانات)
5. صفحة واحدة دليل منصة ("كيف تنشئ خدمة جديدة")

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

أخطاء شائعة

1. بناء منصة قبل ما يكون عندك توحيد. إذا كل خدمة تستخدم لغة مختلفة، إطار عمل مختلف، وطريقة deploy مختلفة، المنصة ما تقدر تساعد. وحّد أولاً، بعدين ابنِ المنصة.

2. Backstage قبل 50 مهندس. Backstage قوي بس معقد. للفرق الأصغر، تكلفة الإعداد والصيانة تتجاوز الفائدة.

3. Golden paths ما تتحدث أبداً. قالب من سنتين بتبعيات قديمة وأنماط منتهية الصلاحية يضر أكثر مما ينفع. صينه مثل منتج.

4. كل شي بالخدمة الذاتية. IAM roles وتغييرات الشبكة ما لازم تكون بالخدمة الذاتية. blast radius الغلطة كبير جداً.

5. قياس النشاط مش النتائج. "بنينا 15 ميزة للمنصة" مش نجاح. "time-to-first-deploy نزل من يومين لـ 30 دقيقة" هو النجاح.

6. تجاهل رضا المطورين. منصة تجبر المطورين على أنماط يكرهوها رح يتجاوزوها. احكِ مع مستخدمينك (المطورين) بانتظام.

7. بدون توثيق. منصة بالخدمة الذاتية بدون توثيق هي بس نوع ثاني من الصندوق الأسود.

أهم النقاط

• هندسة المنصات مش أداة، هي نهج. ابنِ أدوات داخلية تخلي المطورين منتجين بدون ما يحتاجوا خبرة بنية تحتية. الـ golden path هو المنتج الأساسي.

• Time to first deploy هو المقياس الأساسي. إذا المطور يقدر يروح من فكرة لخدمة شغّالة بـ 15 دقيقة، المنصة شغّالة. إذا ياخذ يومين، لا.

• ابدأ ببساطة. golden path واحد، قالب CI/CD واحد، monitoring قياسي. أضف تعقيد لما النهج البسيط ما يكفي. أغلب الفرق أقل من 30 مهندس ما يحتاجوا Backstage.

• التوثيق يعيش مع الكود. توثيق API مولّد تلقائياً، runbooks بالريبو، ADRs للقرارات. صفحات الويكي تصير قديمة. الدوكس اللي بالريبو تضل محدّثة.

• قِس النتائج مش النشاط. مقاييس DORA زائد رضا المطورين. إذا الأرقام مش عم تتحسن، استثمار المنصة مش شغّال.

• فريق المنصة هو فريق منتج. مستخدمينهم المطورين. منتجهم المنصة الداخلية. يحتاجوا feedback loops وuser research وتكرار مثل أي فريق منتج.

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