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