Platform Engineering: كيفية بناء منصة مطورين داخلية

spinny:~/writing $ vim platform-engineering-internal-developer-platform.md

1~
2مع تزايد تعقيد أنظمة البرمجيات  -  الخدمات المصغرة، Kubernetes، السحابة المتعددة، خطوط أنابيب CI/CD، أدوات المراقبة  -  يقضي المطورون وقتًا أكبر على البنية التحتية ووقتًا أقل في بناء المنتجات. يحل **Platform Engineering** هذه المشكلة من خلال إنشاء منصة داخلية تجرد التعقيد وتوفر للمطورين أدوات خدمة ذاتية للتسليم بشكل أسرع.
3~
4تتوقع Gartner أنه بحلول عام 2027، ستنشئ **80% من مؤسسات هندسة البرمجيات** فرق منصات. في هذا الدليل، سنستكشف ما هو Platform Engineering، ولماذا هو مهم، وكيفية بناء Internal Developer Platform من الصفر.
5~
6## ما هو Platform Engineering؟
7~
8Platform Engineering هو تخصص تصميم وبناء سلاسل الأدوات وسير العمل التي تمكن قدرات الخدمة الذاتية لمؤسسات هندسة البرمجيات. الناتج هو **Internal Developer Platform (IDP)**  -  طبقة تقع بين المطورين والبنية التحتية.
9~
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17~
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24~
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31~
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43~
44### Platform Engineering مقابل DevOps
45~
46Platform Engineering ليس بديلاً عن DevOps  -  إنه التطور التالي. قال DevOps "أنت تبنيه، أنت تشغله." يقول Platform Engineering "سنجعل البناء والتشغيل بلا جهد."
47~
48| الجانب | DevOps | Platform Engineering |
49|--------|--------|---------------------|
50| **التركيز** | الثقافة والممارسات | المنتجات والخدمة الذاتية |
51| **النهج** | كل فريق يدير البنية التحتية | فريق المنصة يجرد البنية التحتية |
52| **العبء المعرفي** | عالي (كل فريق يتعلم كل شيء) | منخفض (المسارات الذهبية متوفرة) |
53| **الناتج** | خطوط أنابيب CI/CD، سكربتات IaC | Internal Developer Platform |
54| **المستخدمون** | جميع الهندسة | فريق المنصة يخدم الهندسة |
55~
56## لماذا Platform Engineering مهم
57~
58### مشكلة العبء المعرفي
59~
60في مؤسسة حديثة نموذجية، يحتاج المطور إلى فهم:
61~
62- سير عمل Git واستراتيجيات التفريع
63- تكوين خطوط أنابيب CI/CD
64- بناء الحاويات وإدارة السجلات
65- ملفات Kubernetes و Helm Charts
66- خدمات مزود السحابة (AWS/GCP/Azure)
67- الشبكات، DNS، شهادات TLS
68- إعداد المراقبة والتسجيل والتنبيه
69- توفير قواعد البيانات والترحيلات
70- سياسات الأمان والامتثال
71~
72هذا عبء معرفي هائل يصرف الانتباه عن المنتج الفعلي.
73~
74### المسار الذهبي
75~
76يقدم Platform Engineering مفهوم **المسارات الذهبية**  -  مسارات محددة الرأي، مدعومة جيدًا وموثقة للمهام الشائعة. المسار الذهبي ليس إلزاميًا؛ يمكن للمطورين *الانحراف*، لكن المنصة تجعل الشيء الصحيح هو الشيء السهل.
77~
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88~
89**مثال على المسار الذهبي لإنشاء خدمة مصغرة جديدة:**
901. يختار المطور "خدمة خلفية جديدة" في البوابة
912. يختار اللغة/الإطار (Node.js، Go، Python)
923. تنشئ المنصة تلقائيًا: مستودع Git، خط أنابيب CI/CD، فضاء أسماء Kubernetes، لوحات مراقبة، وقواعد تنبيه
934. يستنسخ المطور المستودع ويبدأ البرمجة فورًا
94~
95## بناء Internal Developer Platform
96~
97### الطبقة 1: بوابة المطورين
98~
99البوابة هي نقطة الدخول الوحيدة للمطورين. الخيار مفتوح المصدر الأكثر شعبية هو **Backstage** (أنشأته Spotify، وهو الآن مشروع CNCF).
100~
101الميزات الرئيسية:
102- **كتالوج الخدمات**: كل خدمة، مالكها، وثائقها وتبعياتها
103- **قوالب البرمجيات**: هيكلة للخدمات الجديدة مع أفضل الممارسات المدمجة
104- **الوثائق التقنية**: التوثيق كرمز، معروض وقابل للبحث
105- **نظام الإضافات**: قابل للتوسيع بوظائف مخصصة
106~
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127~
128### الطبقة 2: تجريد البنية التحتية
129~
130لا ينبغي للمطورين كتابة Terraform أو Kubernetes YAML مباشرة. يجب أن توفر المنصة تجريدات.
131~
132**الأدوات:**
133- **Crossplane**: توفير بنية تحتية أصلية لـ Kubernetes
134- **Terraform مع الوحدات**: وحدات بنية تحتية مبنية مسبقًا ومختبرة
135- **Pulumi**: البنية التحتية كرمز حقيقي (TypeScript، Python، Go)
136~
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149~
150بدلاً من تكوين معاملات RDS، شبكات VPC الفرعية، مجموعات الأمان، وسياسات النسخ الاحتياطي، يحدد المطور ببساطة `size: small` و `backup: daily`. المنصة تتولى الباقي.
151~
152### الطبقة 3: توحيد CI/CD
153~
154قم بتوحيد CI/CD حتى لا يبني كل فريق خطوط أنابيبه الخاصة.
155~
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163~
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172~
173**الممارسات الرئيسية:**
174- قوالب CI/CD مشتركة تضمها الفرق (لا تنسخها)
175- فحص أمني تلقائي (SAST، تدقيق التبعيات)
176- استراتيجيات نشر موحدة (canary، blue/green)
177- تراجع تلقائي عند فشل فحوصات الصحة
178~
179### الطبقة 4: المراقبة
180~
181مراقبة مكونة مسبقًا حتى يحصل المطورون على لوحات المعلومات والتنبيهات جاهزة للاستخدام.
182~
183- **المقاييس**: Prometheus + Grafana مع لوحات معلومات قياسية لكل خدمة
184- **التسجيل**: تسجيل منظم مع جمع مركزي (Loki، ELK)
185- **التتبع**: تتبع موزع مع OpenTelemetry
186- **التنبيه**: تكامل PagerDuty/Opsgenie مع إعدادات افتراضية معقولة
187~
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199~
200## قياس النجاح
201~
202كيف تعرف أن منصتك تعمل؟ تتبع هذه المقاييس:
203~
204### مقاييس DORA
205- **تكرار النشر**: كم مرة يصل الكود إلى الإنتاج
206- **وقت التسليم للتغييرات**: الوقت من الالتزام إلى الإنتاج
207- **معدل فشل التغيير**: نسبة عمليات النشر المسببة للأعطال
208- **متوسط وقت الاستعادة**: الوقت لاستعادة الخدمة بعد حادث
209~
210### مقاييس خاصة بالمنصة
211- **وقت النشر الأول**: كم من الوقت من "خدمة جديدة" إلى أول نشر إنتاجي
212- **رضا المطورين (NPS)**: استطلع آراء مستخدميك بانتظام
213- **نسبة الخدمة الذاتية**: % من طلبات البنية التحتية المعالجة بدون تذاكر
214- **تبني المسار الذهبي**: % من الخدمات التي تتبع المسار الموصى به
215~
216## الأخطاء الشائعة
217~
218### 1. بناء الكثير مبكرًا جدًا
219ابدأ بأكبر نقطة ألم، وليس برؤية كبرى. إذا كان النشر مؤلمًا، ابدأ من هناك. إذا كان التوفير يستغرق أسابيع، ابدأ من هناك.
220~
221### 2. عدم معاملة المنصة كمنتج
222يحتاج فريق المنصة إلى مدير منتج، وأبحاث مستخدمين، وحلقات تغذية راجعة. المطورون هم عملاؤك  -  افهم احتياجاتهم.
223~
224### 3. الإلزام بدلاً من الجذب
225أفضل المنصات يتم تبنيها طوعًا لأنها تجعل حياة المطورين أسهل. إذا كان عليك إلزام الاستخدام، فمنصتك ليست جيدة بما فيه الكفاية.
226~
227### 4. تجاهل تجربة المطور
228منصة ذات تجربة مستخدم سيئة لن يتم استخدامها. استثمر في توثيق واضح، ورسائل خطأ مفيدة، وحلقات تغذية راجعة سريعة.
229~
230## البداية
231~
232خارطة طريق عملية لبناء أول IDP لك:
233~
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239~
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243~
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247~
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251~
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256~
257### المنصة الأدنى القابلة للتطبيق
258~
2591. **كتالوج الخدمات** (Backstage)  -  معرفة ما هو موجود ومن يملكه
2602. **قالب خدمة واحد**  -  مسار ذهبي لأكثر أنواع خدماتك شيوعًا
2613. **CI/CD موحدة**  -  خط أنابيب مشترك تضمه الفرق
2624. **وثائق أساسية**  -  كيفية استخدام المنصة، وأين تحصل على المساعدة
263~
264يمكنك بناء هذا MVP في 2-3 أشهر مع فريق من 2-3 مهندسين.
265~
266## الخاتمة
267~
268Platform Engineering لا يتعلق ببناء المنصة المثالية من اليوم الأول. يتعلق الأمر بتقليل العبء المعرفي على المطورين تدريجيًا حتى يتمكنوا من التركيز على بناء المنتجات. ابدأ صغيرًا، قس التأثير، وكرر بناءً على ملاحظات المطورين.
269~
270المؤسسات التي تستثمر في Platform Engineering ستحصل على ميزة تنافسية كبيرة: تسليم أسرع، ومطورون أكثر سعادة، وأنظمة أكثر موثوقية.
271~
272**الموارد:**
273- [Team Topologies](https://teamtopologies.com/)  -  الكتاب الذي شاع فرق المنصات
274- [Backstage](https://backstage.io/)  -  بوابة المطورين مفتوحة المصدر من Spotify
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  تعريف المجتمع وأفضل الممارسات
276- [platformengineering.org](https://platformengineering.org/)  -  المجتمع والفعاليات والموارد
277~

NORMAL · platform-engineering-internal-developer-platform.md [readonly]277 lines · :q to close

2مع تزايد تعقيد أنظمة البرمجيات - الخدمات المصغرة، Kubernetes، السحابة المتعددة، خطوط أنابيب CI/CD، أدوات المراقبة - يقضي المطورون وقتًا أكبر على البنية التحتية ووقتًا أقل في بناء المنتجات. يحل **Platform Engineering** هذه المشكلة من خلال إنشاء منصة داخلية تجرد التعقيد وتوفر للمطورين أدوات خدمة ذاتية للتسليم بشكل أسرع.

4تتوقع Gartner أنه بحلول عام 2027، ستنشئ **80% من مؤسسات هندسة البرمجيات** فرق منصات. في هذا الدليل، سنستكشف ما هو Platform Engineering، ولماذا هو مهم، وكيفية بناء Internal Developer Platform من الصفر.

6## ما هو Platform Engineering؟

8Platform Engineering هو تخصص تصميم وبناء سلاسل الأدوات وسير العمل التي تمكن قدرات الخدمة الذاتية لمؤسسات هندسة البرمجيات. الناتج هو **Internal Developer Platform (IDP)** - طبقة تقع بين المطورين والبنية التحتية.

10```mermaid

11graph TD

12 subgraph "Developers"

13 D1[Frontend Team]

14 D2[Backend Team]

15 D3[Data Team]

16 end

17~

18 subgraph "Internal Developer Platform"

19 Portal[Developer Portal]

20 Templates[Service Templates]

21 CICD[CI/CD Pipelines]

22 Infra[Infrastructure Abstraction]

23 end

24~

25 subgraph "Infrastructure"

26 K8s[Kubernetes]

27 Cloud[Cloud Services]

28 DB[Databases]

29 Monitor[Monitoring]

30 end

31~

32 D1 --> Portal

33 D2 --> Portal

34 D3 --> Portal

35 Portal --> Templates

36 Portal --> CICD

37 Portal --> Infra

38 Infra --> K8s

39 Infra --> Cloud

40 Infra --> DB

41 CICD --> Monitor

42```

43~

44### Platform Engineering مقابل DevOps

45~

46Platform Engineering ليس بديلاً عن DevOps - إنه التطور التالي. قال DevOps "أنت تبنيه، أنت تشغله." يقول Platform Engineering "سنجعل البناء والتشغيل بلا جهد."

47~

48| الجانب | DevOps | Platform Engineering |

49|--------|--------|---------------------|

50| **التركيز** | الثقافة والممارسات | المنتجات والخدمة الذاتية |

51| **النهج** | كل فريق يدير البنية التحتية | فريق المنصة يجرد البنية التحتية |

52| **العبء المعرفي** | عالي (كل فريق يتعلم كل شيء) | منخفض (المسارات الذهبية متوفرة) |

53| **الناتج** | خطوط أنابيب CI/CD، سكربتات IaC | Internal Developer Platform |

54| **المستخدمون** | جميع الهندسة | فريق المنصة يخدم الهندسة |

55~

56## لماذا Platform Engineering مهم

57~

58### مشكلة العبء المعرفي

59~

60في مؤسسة حديثة نموذجية، يحتاج المطور إلى فهم:

61~

62- سير عمل Git واستراتيجيات التفريع

63- تكوين خطوط أنابيب CI/CD

64- بناء الحاويات وإدارة السجلات

65- ملفات Kubernetes و Helm Charts

66- خدمات مزود السحابة (AWS/GCP/Azure)

67- الشبكات، DNS، شهادات TLS

68- إعداد المراقبة والتسجيل والتنبيه

69- توفير قواعد البيانات والترحيلات

70- سياسات الأمان والامتثال

71~

72هذا عبء معرفي هائل يصرف الانتباه عن المنتج الفعلي.

73~

74### المسار الذهبي

75~

76يقدم Platform Engineering مفهوم **المسارات الذهبية** - مسارات محددة الرأي، مدعومة جيدًا وموثقة للمهام الشائعة. المسار الذهبي ليس إلزاميًا؛ يمكن للمطورين *الانحراف*، لكن المنصة تجعل الشيء الصحيح هو الشيء السهل.

77~

78```mermaid

79flowchart LR

80 Dev[Developer] -- "Create new service" --> Portal[Portal]

81 Portal -- "Select template" --> Template[Service Template]

82 Template -- "Auto-provision" --> Repo[Git Repository]

83 Template --> Pipeline[CI/CD Pipeline]

84 Template --> Infra[Kubernetes Namespace]

85 Template --> Monitor[Dashboards + Alerts]

86 Repo --> Ready[Ready to Code!]

87```

88~

89**مثال على المسار الذهبي لإنشاء خدمة مصغرة جديدة:**

901. يختار المطور "خدمة خلفية جديدة" في البوابة

912. يختار اللغة/الإطار (Node.js، Go، Python)

923. تنشئ المنصة تلقائيًا: مستودع Git، خط أنابيب CI/CD، فضاء أسماء Kubernetes، لوحات مراقبة، وقواعد تنبيه

934. يستنسخ المطور المستودع ويبدأ البرمجة فورًا

94~

95## بناء Internal Developer Platform

96~

97### الطبقة 1: بوابة المطورين

98~

99البوابة هي نقطة الدخول الوحيدة للمطورين. الخيار مفتوح المصدر الأكثر شعبية هو **Backstage** (أنشأته Spotify، وهو الآن مشروع CNCF).

100~

101الميزات الرئيسية:

102- **كتالوج الخدمات**: كل خدمة، مالكها، وثائقها وتبعياتها

103- **قوالب البرمجيات**: هيكلة للخدمات الجديدة مع أفضل الممارسات المدمجة

104- **الوثائق التقنية**: التوثيق كرمز، معروض وقابل للبحث

105- **نظام الإضافات**: قابل للتوسيع بوظائف مخصصة

106~

107```yaml

108# backstage/catalog-info.yaml

109apiVersion: backstage.io/v1alpha1

110kind: Component

111metadata:

112 name: user-service

113 description: Manages user accounts and authentication

114 annotations:

115 github.com/project-slug: myorg/user-service

116 backstage.io/techdocs-ref: dir:.

117spec:

118 type: service

119 lifecycle: production

120 owner: team-auth

121 system: identity-platform

122 dependsOn:

123 - resource:postgresql-main

124 providesApis:

125 - user-api

126```

127~

128### الطبقة 2: تجريد البنية التحتية

129~

130لا ينبغي للمطورين كتابة Terraform أو Kubernetes YAML مباشرة. يجب أن توفر المنصة تجريدات.

131~

132**الأدوات:**

133- **Crossplane**: توفير بنية تحتية أصلية لـ Kubernetes

134- **Terraform مع الوحدات**: وحدات بنية تحتية مبنية مسبقًا ومختبرة

135- **Pulumi**: البنية التحتية كرمز حقيقي (TypeScript، Python، Go)

136~

137```yaml

138# Example: Crossplane composition for a database

139apiVersion: database.example.com/v1

140kind: PostgreSQLInstance

141metadata:

142 name: user-db

143spec:

144 size: small # Abstraction: small = 2 vCPU, 4GB RAM

145 version: "16"

146 backup: daily

147 team: auth-team

148```

149~

150بدلاً من تكوين معاملات RDS، شبكات VPC الفرعية، مجموعات الأمان، وسياسات النسخ الاحتياطي، يحدد المطور ببساطة `size: small` و `backup: daily`. المنصة تتولى الباقي.

151~

152### الطبقة 3: توحيد CI/CD

153~

154قم بتوحيد CI/CD حتى لا يبني كل فريق خطوط أنابيبه الخاصة.

155~

156```yaml

157# .github/workflows/platform-ci.yml

158# Teams just include the shared workflow

159name: Build and Deploy

160on:

161 push:

162 branches: [main]

163~

164jobs:

165 pipeline:

166 uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2

167 with:

168 language: node

169 deploy-target: production

170 secrets: inherit

171```

172~

173**الممارسات الرئيسية:**

174- قوالب CI/CD مشتركة تضمها الفرق (لا تنسخها)

175- فحص أمني تلقائي (SAST، تدقيق التبعيات)

176- استراتيجيات نشر موحدة (canary، blue/green)

177- تراجع تلقائي عند فشل فحوصات الصحة

178~

179### الطبقة 4: المراقبة

180~

181مراقبة مكونة مسبقًا حتى يحصل المطورون على لوحات المعلومات والتنبيهات جاهزة للاستخدام.

182~

183- **المقاييس**: Prometheus + Grafana مع لوحات معلومات قياسية لكل خدمة

184- **التسجيل**: تسجيل منظم مع جمع مركزي (Loki، ELK)

185- **التتبع**: تتبع موزع مع OpenTelemetry

186- **التنبيه**: تكامل PagerDuty/Opsgenie مع إعدادات افتراضية معقولة

187~

188```mermaid

189graph LR

190 Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]

191 Collector --> Prometheus[Prometheus]

192 Collector --> Loki[Loki]

193 Collector --> Tempo[Tempo]

194 Prometheus --> Grafana[Grafana Dashboards]

195 Loki --> Grafana

196 Tempo --> Grafana

197 Grafana --> PagerDuty[PagerDuty Alerts]

198```

199~

200## قياس النجاح

201~

202كيف تعرف أن منصتك تعمل؟ تتبع هذه المقاييس:

203~

204### مقاييس DORA

205- **تكرار النشر**: كم مرة يصل الكود إلى الإنتاج

206- **وقت التسليم للتغييرات**: الوقت من الالتزام إلى الإنتاج

207- **معدل فشل التغيير**: نسبة عمليات النشر المسببة للأعطال

208- **متوسط وقت الاستعادة**: الوقت لاستعادة الخدمة بعد حادث

209~

210### مقاييس خاصة بالمنصة

211- **وقت النشر الأول**: كم من الوقت من "خدمة جديدة" إلى أول نشر إنتاجي

212- **رضا المطورين (NPS)**: استطلع آراء مستخدميك بانتظام

213- **نسبة الخدمة الذاتية**: % من طلبات البنية التحتية المعالجة بدون تذاكر

214- **تبني المسار الذهبي**: % من الخدمات التي تتبع المسار الموصى به

215~

216## الأخطاء الشائعة

217~

218### 1. بناء الكثير مبكرًا جدًا

219ابدأ بأكبر نقطة ألم، وليس برؤية كبرى. إذا كان النشر مؤلمًا، ابدأ من هناك. إذا كان التوفير يستغرق أسابيع، ابدأ من هناك.

220~

221### 2. عدم معاملة المنصة كمنتج

222يحتاج فريق المنصة إلى مدير منتج، وأبحاث مستخدمين، وحلقات تغذية راجعة. المطورون هم عملاؤك - افهم احتياجاتهم.

223~

224### 3. الإلزام بدلاً من الجذب

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

226~

227### 4. تجاهل تجربة المطور

228منصة ذات تجربة مستخدم سيئة لن يتم استخدامها. استثمر في توثيق واضح، ورسائل خطأ مفيدة، وحلقات تغذية راجعة سريعة.

229~

230## البداية

231~

232خارطة طريق عملية لبناء أول IDP لك:

233~

234```mermaid

235flowchart TD

236 A[Month 1-2: Discovery] --> B[Month 3-4: MVP]

237 B --> C[Month 5-6: Iterate]

238 C --> D[Month 7+: Scale]

239~

240 A --> A1[Interview developers]

241 A --> A2[Map pain points]

242 A --> A3[Choose first golden path]

243~

244 B --> B1[Deploy Backstage]

245 B --> B2[First service template]

246 B --> B3[Standardized CI/CD]

247~

248 C --> C1[Gather feedback]

249 C --> C2[Add infrastructure abstraction]

250 C --> C3[Improve docs and onboarding]

251~

252 D --> D1[More templates and golden paths]

253 D --> D2[Self-service infrastructure]

254 D --> D3[Advanced observability]

255```

256~

257### المنصة الأدنى القابلة للتطبيق

258~

2591. **كتالوج الخدمات** (Backstage) - معرفة ما هو موجود ومن يملكه

2602. **قالب خدمة واحد** - مسار ذهبي لأكثر أنواع خدماتك شيوعًا

2613. **CI/CD موحدة** - خط أنابيب مشترك تضمه الفرق

2624. **وثائق أساسية** - كيفية استخدام المنصة، وأين تحصل على المساعدة

263~

264يمكنك بناء هذا MVP في 2-3 أشهر مع فريق من 2-3 مهندسين.

265~

266## الخاتمة

267~

268Platform Engineering لا يتعلق ببناء المنصة المثالية من اليوم الأول. يتعلق الأمر بتقليل العبء المعرفي على المطورين تدريجيًا حتى يتمكنوا من التركيز على بناء المنتجات. ابدأ صغيرًا، قس التأثير، وكرر بناءً على ملاحظات المطورين.

269~

270المؤسسات التي تستثمر في Platform Engineering ستحصل على ميزة تنافسية كبيرة: تسليم أسرع، ومطورون أكثر سعادة، وأنظمة أكثر موثوقية.

271~

272**الموارد:**

273- [Team Topologies](https://teamtopologies.com/) - الكتاب الذي شاع فرق المنصات

274- [Backstage](https://backstage.io/) - بوابة المطورين مفتوحة المصدر من Spotify

275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) - تعريف المجتمع وأفضل الممارسات

276- [platformengineering.org](https://platformengineering.org/) - المجتمع والفعاليات والموارد

277~