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 vs DevOps
45 
46Platform Engineering  -  это не замена DevOps, а следующая эволюция. DevOps сказал: «Ты строишь  -  ты управляешь». Platform Engineering говорит: «Мы сделаем строительство и управление лёгким делом».
47 
48| Аспект | DevOps | Platform Engineering |
49|--------|--------|---------------------|
50| **Фокус** | Культура и практики | Продукты и самообслуживание |
51| **Подход** | Каждая команда управляет инфраструктурой | Платформенная команда абстрагирует инфраструктуру |
52| **Когнитивная нагрузка** | Высокая (каждая команда изучает всё) | Низкая (предоставляются golden paths) |
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### Golden Path
75 
76Platform Engineering вводит концепцию **golden paths**  -  принципиальных, хорошо поддерживаемых и документированных путей для типичных задач. Golden path  -  это не мандат; разработчики *могут* отклоняться, но платформа делает правильное действие лёгким.
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**Пример golden path для создания нового микросервиса:**
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- **Принятие golden path**: % сервисов, следующих рекомендованному пути
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. **Один шаблон сервиса**  -  golden path для наиболее распространённого типа сервиса
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