1 
2У міру того як програмні системи стають складнішими  -  мікросервіси, Kubernetes, мультихмара, конвеєри CI/CD, стеки спостережуваності  -  розробники витрачають більше часу на інфраструктуру і менше на створення продуктів. **Platform Engineering** вирішує це, створюючи внутрішню платформу, що абстрагує складність і надає розробникам інструменти самообслуговування для швидшої доставки.
3 
4Gartner прогнозує, що до 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 
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### Рівень 1: Developer Portal
98 
99Портал  -  єдина точка входу для розробників. Найпопулярніший open-source варіант  -  **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Платформа з жахливим 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 за 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/)  -  open-source портал розробників від Spotify
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  визначення спільноти та найкращі практики
276- [platformengineering.org](https://platformengineering.org/)  -  спільнота, заходи та ресурси
277