Platform Engineering: Как построить Internal Developer Platform

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

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~

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

2По мере того как программные системы становятся сложнее - микросервисы, Kubernetes, мультиоблако, пайплайны CI/CD, стеки наблюдаемости - разработчики тратят больше времени на инфраструктуру и меньше времени на создание продуктов. **Platform Engineering** решает эту проблему, создавая внутреннюю платформу, которая абстрагирует сложность и предоставляет разработчикам инструменты самообслуживания для более быстрой доставки.

4Gartner прогнозирует, что к 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 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~