Platform Engineering: چگونه یک Internal Developer Platform بسازیم

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

1~
2با پیچیده‌تر شدن سیستم‌های نرم‌افزاری  -  میکروسرویس‌ها، Kubernetes، چند ابری، خطوط لوله CI/CD، پشته‌های مشاهده‌پذیری  -  توسعه‌دهندگان زمان بیشتری را صرف زیرساخت و زمان کمتری را صرف ساخت محصولات می‌کنند. **Platform Engineering** این مشکل را با ایجاد یک پلتفرم داخلی حل می‌کند که پیچیدگی را انتزاعی می‌کند و ابزارهای سلف‌سرویس برای تحویل سریع‌تر در اختیار توسعه‌دهندگان قرار می‌دهد.
3~
4Gartner پیش‌بینی می‌کند که تا سال ۲۰۲۷، **۸۰ درصد سازمان‌های مهندسی نرم‌افزار** تیم‌های پلتفرم ایجاد خواهند کرد. در این راهنما، بررسی خواهیم کرد که 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~
76Platform 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. توسعه‌دهنده «سرویس Backend جدید» را در پورتال انتخاب می‌کند
912. زبان/فریمورک را انتخاب می‌کند (Node.js، Go، Python)
923. پلتفرم به صورت خودکار ایجاد می‌کند: مخزن Git، خط لوله CI/CD، فضای نام Kubernetes، داشبوردهای مانیتورینگ و قوانین هشدار
934. توسعه‌دهنده مخزن را کلون می‌کند و بلافاصله شروع به کدنویسی می‌کند
94~
95## ساخت Internal Developer Platform
96~
97### لایه ۱: Developer Portal
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### لایه ۲: انتزاع زیرساخت
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### لایه ۳: استانداردسازی CI/CD
153~
154CI/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### لایه ۴: مشاهده‌پذیری
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- **زمان تحویل تغییرات**: زمان از commit تا تولید
207- **نرخ شکست تغییرات**: درصد استقرارهایی که باعث خرابی می‌شوند
208- **میانگین زمان بازیابی**: زمان بازگرداندن سرویس پس از حادثه
209~
210### متریک‌های خاص پلتفرم
211- **زمان تا اولین استقرار**: چقدر طول می‌کشد از «سرویس جدید» تا اولین استقرار تولید
212- **رضایت توسعه‌دهنده (NPS)**: به طور منظم از کاربرانتان نظرسنجی کنید
213- **نسبت سلف‌سرویس**: درصد درخواست‌های زیرساخت بدون تیکت
214- **پذیرش مسیر طلایی**: درصد سرویس‌هایی که مسیر پیشنهادی را دنبال می‌کنند
215~
216## اشتباهات رایج
217~
218### ۱. ساختن بیش از حد، زودتر از موقع
219از بزرگ‌ترین نقطه درد شروع کنید، نه یک چشم‌انداز بزرگ. اگر استقرارها دردناک هستند، از آنجا شروع کنید. اگر تهیه هفته‌ها طول می‌کشد، از آنجا شروع کنید.
220~
221### ۲. رفتار نکردن با پلتفرم به عنوان محصول
222تیم پلتفرم به مدیر محصول، تحقیقات کاربر و حلقه‌های بازخورد نیاز دارد. توسعه‌دهندگان مشتریان شما هستند  -  نیازهایشان را درک کنید.
223~
224### ۳. اجباری کردن به جای جذب
225بهترین پلتفرم‌ها داوطلبانه پذیرفته می‌شوند چون زندگی توسعه‌دهندگان را آسان‌تر می‌کنند. اگر مجبور به اجباری کردن استفاده هستید، پلتفرمتان به اندازه کافی خوب نیست.
226~
227### ۴. نادیده گرفتن تجربه توسعه‌دهنده
228پلتفرمی با UX وحشتناک استفاده نخواهد شد. در مستندات واضح، پیام‌های خطای مفید و حلقه‌های بازخورد سریع سرمایه‌گذاری کنید.
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 را در ۲-۳ ماه با تیمی از ۲-۳ مهندس بسازید.
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** این مشکل را با ایجاد یک پلتفرم داخلی حل می‌کند که پیچیدگی را انتزاعی می‌کند و ابزارهای سلف‌سرویس برای تحویل سریع‌تر در اختیار توسعه‌دهندگان قرار می‌دهد.

4Gartner پیش‌بینی می‌کند که تا سال ۲۰۲۷، **۸۰ درصد سازمان‌های مهندسی نرم‌افزار** تیم‌های پلتفرم ایجاد خواهند کرد. در این راهنما، بررسی خواهیم کرد که 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~

76Platform 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. توسعه‌دهنده «سرویس Backend جدید» را در پورتال انتخاب می‌کند

912. زبان/فریمورک را انتخاب می‌کند (Node.js، Go، Python)

923. پلتفرم به صورت خودکار ایجاد می‌کند: مخزن Git، خط لوله CI/CD، فضای نام Kubernetes، داشبوردهای مانیتورینگ و قوانین هشدار

934. توسعه‌دهنده مخزن را کلون می‌کند و بلافاصله شروع به کدنویسی می‌کند

94~

95## ساخت Internal Developer Platform

96~

97### لایه ۱: Developer Portal

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### لایه ۲: انتزاع زیرساخت

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### لایه ۳: استانداردسازی CI/CD

153~

154CI/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### لایه ۴: مشاهده‌پذیری

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- **زمان تحویل تغییرات**: زمان از commit تا تولید

207- **نرخ شکست تغییرات**: درصد استقرارهایی که باعث خرابی می‌شوند

208- **میانگین زمان بازیابی**: زمان بازگرداندن سرویس پس از حادثه

209~

210### متریک‌های خاص پلتفرم

211- **زمان تا اولین استقرار**: چقدر طول می‌کشد از «سرویس جدید» تا اولین استقرار تولید

212- **رضایت توسعه‌دهنده (NPS)**: به طور منظم از کاربرانتان نظرسنجی کنید

213- **نسبت سلف‌سرویس**: درصد درخواست‌های زیرساخت بدون تیکت

214- **پذیرش مسیر طلایی**: درصد سرویس‌هایی که مسیر پیشنهادی را دنبال می‌کنند

215~

216## اشتباهات رایج

217~

218### ۱. ساختن بیش از حد، زودتر از موقع

219از بزرگ‌ترین نقطه درد شروع کنید، نه یک چشم‌انداز بزرگ. اگر استقرارها دردناک هستند، از آنجا شروع کنید. اگر تهیه هفته‌ها طول می‌کشد، از آنجا شروع کنید.

220~

221### ۲. رفتار نکردن با پلتفرم به عنوان محصول

222تیم پلتفرم به مدیر محصول، تحقیقات کاربر و حلقه‌های بازخورد نیاز دارد. توسعه‌دهندگان مشتریان شما هستند - نیازهایشان را درک کنید.

223~

224### ۳. اجباری کردن به جای جذب

225بهترین پلتفرم‌ها داوطلبانه پذیرفته می‌شوند چون زندگی توسعه‌دهندگان را آسان‌تر می‌کنند. اگر مجبور به اجباری کردن استفاده هستید، پلتفرمتان به اندازه کافی خوب نیست.

226~

227### ۴. نادیده گرفتن تجربه توسعه‌دهنده

228پلتفرمی با UX وحشتناک استفاده نخواهد شد. در مستندات واضح، پیام‌های خطای مفید و حلقه‌های بازخورد سریع سرمایه‌گذاری کنید.

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 را در ۲-۳ ماه با تیمی از ۲-۳ مهندس بسازید.

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~