[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-platform-engineering-poglotil-devops-idp-2026":3},{"article":4,"author":55},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":24,"related_articles":35},"d0100000-0000-0000-0000-000000000013","a0000000-0000-0000-0000-000000000015","Platform Engineering поглотил DevOps: строим Internal Developer Platform в 2026 году","platform-engineering-poglotil-devops-idp-2026","80% крупных инженерных организаций теперь имеют выделенные платформенные команды. Internal Developer Platform — порталы самообслуживания, предварительно одобренная инфраструктура, автоматические ограждения — стал стандартным способом масштабирования DevOps.","## 80% крупных организаций имеют платформенные команды — и вам тоже стоит\n\nОтчёт Gartner 2026 Engineering Effectiveness Report подтверждает то, что многие уже ощущали: **80% крупных инженерных организаций** (500+ разработчиков) теперь имеют выделенные платформенные команды — по сравнению с 45% в 2024 году. Индустрия проголосовала штатным расписанием, и вердикт однозначен — платформенная инженерия не тренд, а операционная модель.\n\nПереход произошёл потому, что DevOps в своей изначальной концепции упёрся в стену масштабирования. «You build it, you run it» прекрасно работает для стартапа на 20 человек. При 200 инженерах это превращается в «вы строите, вы запускаете, и вы тратите 40% времени на недифференцирующую инфраструктурную работу». Платформенная инженерия — ответ: централизуйте экспертизу инфраструктуры, предоставьте её через интерфейсы самообслуживания и позвольте разработчикам приложений сосредоточиться на поставке функций.\n\n## Что такое Internal Developer Platform?\n\nInternal Developer Platform (IDP) — это набор инструментов, рабочих процессов и возможностей самообслуживания, абстрагирующих сложность инфраструктуры для разработчиков приложений. Это не единый продукт — это интеграционный слой, соединяющий существующие инструменты в целостный опыт разработчика.\n\nОсновной принцип: **разработчики должны иметь возможность развернуть новый сервис в продакшен без заполнения тикета, ожидания ops-команды или чтения 50-страничного руководства.**\n\n### Архитектура IDP\n\nПродакшен-IDP в 2026 году обычно состоит из пяти уровней:\n\n```\n+------------------------------------------------------------------+\n|                    Портал разработчика (Backstage)                |\n|   Каталог сервисов, документация, шаблоны, скаффолдинг, поиск   |\n+------------------------------------------------------------------+\n|                    Портал самообслуживания                        |\n|   Деплой сервиса, создание БД, создание окружения                |\n|   Запрос ресурсов, просмотр затрат, управление секретами         |\n+------------------------------------------------------------------+\n|                    CI\u002FCD-пайплайн (стандартизированный)           |\n|   Сборка, тестирование, сканирование, деплой — с AI-оптимизацией |\n+------------------------------------------------------------------+\n|                    Предварительно одобренная инфраструктура       |\n|   Terraform-модули, Kubernetes-операторы, database-as-a-service  |\n|   Всё просканировано, валидировано, с тегами стоимости           |\n+------------------------------------------------------------------+\n|                    Ограждения и политики                          |\n|   Политики OPA\u002FKyverno, лимиты затрат, базовые линии безопасности|\n|   Автоматизированные проверки соответствия, обнаружение дрифта   |\n+------------------------------------------------------------------+\n```\n\n### Уровень 1: Портал разработчика (Backstage)\n\n**Backstage**, graduated-проект CNCF, изначально созданный в Spotify, стал де-факто стандартным интерфейсом для IDP. По состоянию на март 2026:\n\n- **3 200+ компаний** используют Backstage в продакшене (по сравнению с 900 в 2024)\n- **700+ open-source плагинов** доступны в маркетплейсе Backstage\n- **Backstage 2.0** (выпущен в январе 2026) представил новый фронтенд-фреймворк, декларативные UI-расширения и нативную поддержку платформенных действий\n\nBackstage служит единой точкой входа для разработчиков:\n\n- **Обзор каталога сервисов** — каждый сервис, библиотека и инфраструктурный компонент зарегистрированы с метаданными (владелец, документация, зависимости, API-спецификации, статус деплоя)\n- **Скаффолдинг новых сервисов** — шаблоны программного обеспечения генерируют новые проекты с CI\u002FCD, мониторингом и деплоем из коробки\n- **Просмотр документации** — TechDocs рендерит Markdown-документацию рядом с каталогом сервисов\n- **Поиск по всему** — единый поиск по сервисам, API, документации, руководствам и инцидентам\n- **Запуск платформенных действий** — деплой сервиса, создание БД, ротация секретов, создание нового окружения — всё через портал\n\n```yaml\n# Шаблон Backstage Software Template для нового микросервиса\napiVersion: scaffolder.backstage.io\u002Fv1beta3\nkind: Template\nmetadata:\n  name: microservice-template\n  title: Production Microservice\n  description: Создаёт новый микросервис с CI\u002FCD, мониторингом и K8s-деплоем\nspec:\n  owner: platform-team\n  type: service\n  parameters:\n    - title: Детали сервиса\n      properties:\n        name:\n          title: Имя сервиса\n          type: string\n          pattern: \"^[a-z][a-z0-9-]*$\"\n        language:\n          title: Язык\n          type: string\n          enum: [rust, go, typescript, python]\n        database:\n          title: База данных\n          type: string\n          enum: [postgresql, none]\n  steps:\n    - id: scaffold\n      action: fetch:template\n      input:\n        url: .\u002Fskeleton\n        values:\n          name: ${{ parameters.name }}\n          language: ${{ parameters.language }}\n    - id: create-repo\n      action: publish:gitlab\n      input:\n        repoUrl: gitlab.com?repo=${{ parameters.name }}&owner=backend\n    - id: provision-infra\n      action: terraform:apply\n      input:\n        module: microservice-base\n        vars:\n          service_name: ${{ parameters.name }}\n          database: ${{ parameters.database }}\n    - id: register-catalog\n      action: catalog:register\n      input:\n        repoContentsUrl: ${{ steps.create-repo.output.repoContentsUrl }}\n```\n\n### Уровень 2: Инфраструктура самообслуживания\n\nУровень самообслуживания предоставляет разработчикам **предварительно одобренные инфраструктурные ресурсы**, которые могут быть мгновенно созданы:\n\n- **Базы данных** — инстансы PostgreSQL, Redis, MongoDB с автоматическими бэкапами, мониторингом и пулингом соединений\n- **Очереди сообщений** — Kafka-топики, RabbitMQ-vhost, NATS-subjects\n- **Окружения** — эфемерные preview-окружения для pull request-ов, staging-окружения с production-подобными данными\n- **Секреты** — управляемые Vault секреты с автоматической ротацией и инъекцией\n- **DNS и сертификаты** — автоматическое создание DNS-записей и провизионирование TLS-сертификатов через cert-manager\n\nКлючевое слово — **предварительно одобренные**. Платформенная команда уже проверила, просканировала и оптимизировала по стоимости каждый тип ресурса. Разработчики выбирают из меню валидированных опций, а не пишут сырой Terraform с нуля.\n\n### Уровень 3: Стандартизированный CI\u002FCD\n\nПлатформенная команда предоставляет стандартизированные CI\u002FCD-пайплайны, обеспечивающие организационные стандарты:\n\n```yaml\n# Предоставляемый платформой CI\u002FCD-пайплайн (разработчики его не пишут)\nstages:\n  - build:\n      steps:\n        - compile\n        - unit-test\n        - lint\n  - security:\n      steps:\n        - sast-scan        # Статический анализ (Semgrep, CodeQL)\n        - dependency-audit  # Сканирование известных уязвимостей\n        - container-scan    # Сканирование образов (Trivy)\n        - secrets-scan      # Предотвращение утечки учётных данных (Gitleaks)\n  - deploy-staging:\n      steps:\n        - deploy-to-staging\n        - integration-test\n        - performance-test\n  - deploy-production:\n      steps:\n        - canary-deploy-10-percent\n        - automated-rollback-on-error-spike\n        - progressive-rollout-to-100-percent\n        - post-deploy-smoke-test\n```\n\nРазработчики не настраивают пайплайны — они просто пушат код. Платформа автоматически обрабатывает сборку, тестирование, сканирование и деплой.\n\n### Уровень 4: Предварительно одобренные инфраструктурные модули\n\nПлатформенная команда поддерживает библиотеку **Terraform-модулей** и **Kubernetes-операторов**, кодирующих организационные лучшие практики:\n\n- Каждый модуль версионирован, протестирован и проверен на безопасность\n- Модули обеспечивают соглашения по тегированию, сетевые политики, лимиты ресурсов и расписания бэкапов\n- Оценка стоимости рассчитывается перед провизионированием\n- Обнаружение дрифта оповещает, когда инфраструктура расходится с объявленным состоянием\n\n### Уровень 5: Ограждения и политики\n\nОграждения — секретный ингредиент, делающий самообслуживание безопасным. Без них самообслуживание превращается в «разработчики создают всё что хотят, и счёт взрывается».\n\n**OPA (Open Policy Agent)** и **Kyverno** обеспечивают политики на нескольких уровнях:\n\n- **Admission в Kubernetes** — блокировка деплоев без лимитов ресурсов, health check-ов или security context-ов\n- **Terraform plan** — отклонение инфраструктурных изменений, нарушающих бюджет или правила соответствия\n- **Шлюзы CI\u002FCD** — провал сборок, вносящих критические уязвимости или пропускающих обязательные тесты\n- **Runtime** — оповещение или блокировка runtime-поведения, нарушающего базовые линии безопасности\n\nПример политики Kyverno:\n\n```yaml\napiVersion: kyverno.io\u002Fv1\nkind: ClusterPolicy\nmetadata:\n  name: require-resource-limits\nspec:\n  validationFailureAction: Enforce\n  rules:\n    - name: check-limits\n      match:\n        any:\n          - resources:\n              kinds: [\"Pod\"]\n      validate:\n        message: \"Все контейнеры должны иметь лимиты CPU и памяти\"\n        pattern:\n          spec:\n            containers:\n              - resources:\n                  limits:\n                    memory: \"?*\"\n                    cpu: \"?*\"\n```\n\n## AI в CI\u002FCD: 76% внедрение и в 3 раза меньше сбоев деплоя\n\nОтчёт State of DevOps 2026 показывает, что **76% инженерных организаций** теперь используют AI в CI\u002FCD-пайплайнах — по сравнению с 31% в 2024 году. Влияние измеримо: команды, использующие AI-ассистированный CI\u002FCD, сообщают о **3-кратном снижении сбоев деплоя** и **40% сокращении lead time**.\n\n### Где AI помогает в пайплайне\n\n| Этап | Применение AI | Влияние |\n|------|--------------|--------|\n| Code review | AI-комментарии, предложения по безопасности | На 30% меньше багов доходят до CI |\n| Генерация тестов | AI генерирует unit и integration тесты из изменений кода | На 60% выше покрытие тестами |\n| Выбор тестов | AI предсказывает, какие тесты релевантны для изменения | На 70% короче выполнение тест-сьюта |\n| Риск деплоя | AI оценивает риск деплоя на основе характеристик изменения | На 50% меньше высокосерьёзных инцидентов |\n| Реагирование на инциденты | AI коррелирует деплой с аномалиями в продакшене | На 65% быстрее MTTR |\n| Решение о откате | AI рекомендует откат на основе тренда ошибок | На 80% быстрее инициация отката |\n\n### AI-управляемый выбор тестов\n\nОдно из наиболее эффективных применений AI в CI\u002FCD — **предиктивный выбор тестов**. Вместо запуска всего тест-сьюта при каждом коммите (30-60 минут для больших кодовых баз) AI-модели предсказывают, какие тесты могут упасть:\n\n- **Launchable** и **Gradle Predictive Test Selection** — лидирующие инструменты\n- Анализируют историю результатов тестов и паттерны изменений кода\n- Типичный результат: запуск 20% тест-сьюта, обнаружение 99% сбоев\n- Среднее сокращение времени CI: 60-70%\n\n### AI-ассистированная оценка риска деплоя\n\nПлатформенные команды обучают модели для оценки риска деплоя на основе:\n\n- Размера изменения (строки кода, изменённые файлы)\n- Радиуса поражения (количество зависимых сервисов)\n- Опыта автора с кодовой базой\n- Времени с последнего деплоя\n- Исторической частоты сбоев для похожих изменений\n\nВысокорисковые деплои автоматически получают дополнительные меры защиты: меньшие canary-проценты, более длинные периоды наблюдения и шлюзы с человеческим одобрением.\n\n## DevSecOps: автоматизированное и встроенное сканирование безопасности\n\nДвижение «shift left» превратилось из лозунга в автоматизированную реальность. В современном IDP сканирование безопасности **встроено в платформу** — разработчики не выбирают, запускать его или нет.\n\n### Стек сканирования безопасности\n\n| Уровень | Инструмент | Что обнаруживает |\n|---------|------------|------------------|\n| IDE | Semgrep, Snyk IDE | Баги при разработке |\n| Pre-commit | Gitleaks, TruffleHog | Утечки секретов |\n| SAST | Semgrep, CodeQL | Уязвимости кода |\n| SCA | Snyk, Dependabot, Trivy | Уязвимые зависимости |\n| Контейнер | Trivy, Grype | Уязвимости образов |\n| IaC | Checkov, tfsec | Ошибки конфигурации инфраструктуры |\n| DAST | ZAP, Nuclei | Runtime-уязвимости |\n| Runtime | Falco, Tetragon | Аномальное поведение |\n\n### Безопасность цепочки поставок\n\nАтаки на цепочки поставок ПО ускорили внедрение:\n\n- **SLSA Level 3** — происхождение сборки для всех артефактов\n- **Sigstore\u002Fcosign** — подпись образов контейнеров\n- **Генерация SBOM** (SPDX или CycloneDX) для каждого развёрнутого артефакта\n- **VEX-документы** для уязвимостей зависимостей\n\nПлатформа автоматизирует всё это. Разработчики не генерируют SBOM и не подписывают образы вручную — CI\u002FCD-пайплайн делает это прозрачно.\n\n## Developer Experience как метрика\n\nНаиболее прогрессивные платформенные команды приняли **Developer Experience (DevEx)** как первоклассную метрику, измеряемую комбинацией количественных и качественных сигналов:\n\n### DORA-метрики (количественные)\n\nЧетыре DORA-метрики остаются золотым стандартом измерения производительности поставки ПО:\n\n| Метрика | Порог элитного уровня | Как помогает платформенная инженерия |\n|---------|----------------------|-------------------------------------|\n| Частота деплоя | По запросу (несколько раз в день) | Самообслуживаемый деплой, автоматизированные пайплайны |\n| Lead time изменений | Менее 1 часа | Готовые шаблоны, AI-выбор тестов |\n| Частота сбоев изменений | Менее 5% | Автоматизированное сканирование, canary-деплои |\n| Время восстановления сервиса | Менее 1 часа | Автоматический откат, инструменты инцидентов |\n\n### Фреймворк SPACE (качественный)\n\nФреймворк SPACE (Satisfaction, Performance, Activity, Communication, Efficiency) захватывает то, что DORA упускает — человеческий опыт использования платформы:\n\n- **Опросы удовлетворённости разработчиков** — ежеквартальные опросы с оценкой платформы по шкале 1-10\n- **Time-to-first-deploy** — сколько времени нужно новому сотруднику для первого деплоя в продакшен? (Цель: \u003C1 дня)\n- **Индекс когнитивной нагрузки** — сколько инструментов, систем и процессов должен понимать разработчик? (Цель: минимум, платформа абстрагирует остальное)\n- **Доля toil** — какой процент времени разработчика тратится на недифференцирующую инфраструктурную работу? (Цель: \u003C10%)\n\n## Построение IDP: 12-недельная дорожная карта\n\nДля команд, начинающих с нуля, вот прагматичная дорожная карта:\n\n### Недели 1-3: Фундамент\n\n- Разверните Backstage с базовым каталогом сервисов\n- Зарегистрируйте существующие сервисы (имя, владелец, репозиторий, ссылка на документацию)\n- Создайте первый шаблон для наиболее распространённого типа сервиса\n- Организуйте канал платформенной команды для обратной связи от разработчиков\n\n### Недели 4-6: Стандартизация CI\u002FCD\n\n- Определите стандартный CI\u002FCD-пайплайн для основного языка\u002Fфреймворка\n- Интегрируйте сканирование безопасности (SAST, SCA, сканирование контейнеров)\n- Реализуйте автоматизированные canary-деплои в продакшен\n- Измерьте базовые DORA-метрики\n\n### Недели 7-9: Инфраструктура самообслуживания\n\n- Создайте Terraform-модули для общих ресурсов (БД, кэш, очередь)\n- Предоставьте их через Backstage-действия или API самообслуживания\n- Реализуйте тегирование и видимость стоимости\n- Разверните ограждения OPA\u002FKyverno\n\n### Недели 10-12: Полировка и измерение\n\n- Проведите опрос удовлетворённости разработчиков\n- Измерьте time-to-first-deploy для моделируемого нового сотрудника\n- Определите топ-3 болевых точки разработчиков и устраните их\n- Задокументируйте архитектуру платформы и опубликуйте в Backstage\n\n## Часто задаваемые вопросы\n\n### Platform Engineering устраняет потребность в DevOps-инженерах?\n\nНет. Платформенная инженерия реорганизует работу DevOps, а не устраняет её. DevOps-инженеры становятся платформенными инженерами — вместо поддержки отдельных команд они строят и поддерживают общую платформу. Навыки те же (инфраструктура, автоматизация, надёжность), но масштаб смещается с уровня команды на уровень организации.\n\n### Какой размер платформенной команды оптимален?\n\nРаспространённое соотношение — 1 платформенный инженер на 15-25 разработчиков приложений. Организация с 200 инженерами обычно нуждается в 8-12 платформенных инженерах. Начните с малого (3-4 человека) и растите по мере необходимости.\n\n### Backstage — единственный вариант для портала разработчика?\n\nBackstage — самый популярный open-source вариант, но существуют альтернативы. Port, Cortex и OpsLevel предлагают коммерческие порталы с меньшими операционными затратами. Некоторые команды строят кастомные порталы поверх существующих инструментов. Однако экосистема плагинов и сообщество Backstage делают его выбором по умолчанию для большинства организаций.\n\n### Что если разработчики сопротивляются использованию платформы?\n\nСопротивление обычно возникает из двух источников: платформа не решает их реальных проблем или ощущается как ограничение, а не как инструмент. Решение одно: разговаривайте с разработчиками, понимайте их болевые точки и стройте платформу вокруг их потребностей — не вокруг того, что платформенная команда считает нужным. Сделайте платформу путём наименьшего сопротивления, а не мандатом.\n\n### Как обрабатывать команды с уникальными требованиями?\n\nПлатформа должна покрывать 80% общих потребностей через стандартизированные пути. Для оставшихся 20% предоставьте «пути отхода» — возможность кастомизировать пайплайны, использовать собственные Terraform-модули или запрашивать нестандартные ресурсы через лёгкий процесс ревью. Цель — «золотые пути, а не золотые клетки».","\u003Ch2 id=\"80\">80% крупных организаций имеют платформенные команды — и вам тоже стоит\u003C\u002Fh2>\n\u003Cp>Отчёт Gartner 2026 Engineering Effectiveness Report подтверждает то, что многие уже ощущали: \u003Cstrong>80% крупных инженерных организаций\u003C\u002Fstrong> (500+ разработчиков) теперь имеют выделенные платформенные команды — по сравнению с 45% в 2024 году. Индустрия проголосовала штатным расписанием, и вердикт однозначен — платформенная инженерия не тренд, а операционная модель.\u003C\u002Fp>\n\u003Cp>Переход произошёл потому, что DevOps в своей изначальной концепции упёрся в стену масштабирования. «You build it, you run it» прекрасно работает для стартапа на 20 человек. При 200 инженерах это превращается в «вы строите, вы запускаете, и вы тратите 40% времени на недифференцирующую инфраструктурную работу». Платформенная инженерия — ответ: централизуйте экспертизу инфраструктуры, предоставьте её через интерфейсы самообслуживания и позвольте разработчикам приложений сосредоточиться на поставке функций.\u003C\u002Fp>\n\u003Ch2 id=\"internal-developer-platform\">Что такое Internal Developer Platform?\u003C\u002Fh2>\n\u003Cp>Internal Developer Platform (IDP) — это набор инструментов, рабочих процессов и возможностей самообслуживания, абстрагирующих сложность инфраструктуры для разработчиков приложений. Это не единый продукт — это интеграционный слой, соединяющий существующие инструменты в целостный опыт разработчика.\u003C\u002Fp>\n\u003Cp>Основной принцип: \u003Cstrong>разработчики должны иметь возможность развернуть новый сервис в продакшен без заполнения тикета, ожидания ops-команды или чтения 50-страничного руководства.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch3>Архитектура IDP\u003C\u002Fh3>\n\u003Cp>Продакшен-IDP в 2026 году обычно состоит из пяти уровней:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>+------------------------------------------------------------------+\n|                    Портал разработчика (Backstage)                |\n|   Каталог сервисов, документация, шаблоны, скаффолдинг, поиск   |\n+------------------------------------------------------------------+\n|                    Портал самообслуживания                        |\n|   Деплой сервиса, создание БД, создание окружения                |\n|   Запрос ресурсов, просмотр затрат, управление секретами         |\n+------------------------------------------------------------------+\n|                    CI\u002FCD-пайплайн (стандартизированный)           |\n|   Сборка, тестирование, сканирование, деплой — с AI-оптимизацией |\n+------------------------------------------------------------------+\n|                    Предварительно одобренная инфраструктура       |\n|   Terraform-модули, Kubernetes-операторы, database-as-a-service  |\n|   Всё просканировано, валидировано, с тегами стоимости           |\n+------------------------------------------------------------------+\n|                    Ограждения и политики                          |\n|   Политики OPA\u002FKyverno, лимиты затрат, базовые линии безопасности|\n|   Автоматизированные проверки соответствия, обнаружение дрифта   |\n+------------------------------------------------------------------+\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Уровень 1: Портал разработчика (Backstage)\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Backstage\u003C\u002Fstrong>, graduated-проект CNCF, изначально созданный в Spotify, стал де-факто стандартным интерфейсом для IDP. По состоянию на март 2026:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>3 200+ компаний\u003C\u002Fstrong> используют Backstage в продакшене (по сравнению с 900 в 2024)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>700+ open-source плагинов\u003C\u002Fstrong> доступны в маркетплейсе Backstage\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Backstage 2.0\u003C\u002Fstrong> (выпущен в январе 2026) представил новый фронтенд-фреймворк, декларативные UI-расширения и нативную поддержку платформенных действий\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Backstage служит единой точкой входа для разработчиков:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Обзор каталога сервисов\u003C\u002Fstrong> — каждый сервис, библиотека и инфраструктурный компонент зарегистрированы с метаданными (владелец, документация, зависимости, API-спецификации, статус деплоя)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Скаффолдинг новых сервисов\u003C\u002Fstrong> — шаблоны программного обеспечения генерируют новые проекты с CI\u002FCD, мониторингом и деплоем из коробки\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Просмотр документации\u003C\u002Fstrong> — TechDocs рендерит Markdown-документацию рядом с каталогом сервисов\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Поиск по всему\u003C\u002Fstrong> — единый поиск по сервисам, API, документации, руководствам и инцидентам\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Запуск платформенных действий\u003C\u002Fstrong> — деплой сервиса, создание БД, ротация секретов, создание нового окружения — всё через портал\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode class=\"language-yaml\"># Шаблон Backstage Software Template для нового микросервиса\napiVersion: scaffolder.backstage.io\u002Fv1beta3\nkind: Template\nmetadata:\n  name: microservice-template\n  title: Production Microservice\n  description: Создаёт новый микросервис с CI\u002FCD, мониторингом и K8s-деплоем\nspec:\n  owner: platform-team\n  type: service\n  parameters:\n    - title: Детали сервиса\n      properties:\n        name:\n          title: Имя сервиса\n          type: string\n          pattern: \"^[a-z][a-z0-9-]*$\"\n        language:\n          title: Язык\n          type: string\n          enum: [rust, go, typescript, python]\n        database:\n          title: База данных\n          type: string\n          enum: [postgresql, none]\n  steps:\n    - id: scaffold\n      action: fetch:template\n      input:\n        url: .\u002Fskeleton\n        values:\n          name: ${{ parameters.name }}\n          language: ${{ parameters.language }}\n    - id: create-repo\n      action: publish:gitlab\n      input:\n        repoUrl: gitlab.com?repo=${{ parameters.name }}&owner=backend\n    - id: provision-infra\n      action: terraform:apply\n      input:\n        module: microservice-base\n        vars:\n          service_name: ${{ parameters.name }}\n          database: ${{ parameters.database }}\n    - id: register-catalog\n      action: catalog:register\n      input:\n        repoContentsUrl: ${{ steps.create-repo.output.repoContentsUrl }}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Уровень 2: Инфраструктура самообслуживания\u003C\u002Fh3>\n\u003Cp>Уровень самообслуживания предоставляет разработчикам \u003Cstrong>предварительно одобренные инфраструктурные ресурсы\u003C\u002Fstrong>, которые могут быть мгновенно созданы:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Базы данных\u003C\u002Fstrong> — инстансы PostgreSQL, Redis, MongoDB с автоматическими бэкапами, мониторингом и пулингом соединений\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Очереди сообщений\u003C\u002Fstrong> — Kafka-топики, RabbitMQ-vhost, NATS-subjects\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Окружения\u003C\u002Fstrong> — эфемерные preview-окружения для pull request-ов, staging-окружения с production-подобными данными\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Секреты\u003C\u002Fstrong> — управляемые Vault секреты с автоматической ротацией и инъекцией\u003C\u002Fli>\n\u003Cli>\u003Cstrong>DNS и сертификаты\u003C\u002Fstrong> — автоматическое создание DNS-записей и провизионирование TLS-сертификатов через cert-manager\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Ключевое слово — \u003Cstrong>предварительно одобренные\u003C\u002Fstrong>. Платформенная команда уже проверила, просканировала и оптимизировала по стоимости каждый тип ресурса. Разработчики выбирают из меню валидированных опций, а не пишут сырой Terraform с нуля.\u003C\u002Fp>\n\u003Ch3>Уровень 3: Стандартизированный CI\u002FCD\u003C\u002Fh3>\n\u003Cp>Платформенная команда предоставляет стандартизированные CI\u002FCD-пайплайны, обеспечивающие организационные стандарты:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\"># Предоставляемый платформой CI\u002FCD-пайплайн (разработчики его не пишут)\nstages:\n  - build:\n      steps:\n        - compile\n        - unit-test\n        - lint\n  - security:\n      steps:\n        - sast-scan        # Статический анализ (Semgrep, CodeQL)\n        - dependency-audit  # Сканирование известных уязвимостей\n        - container-scan    # Сканирование образов (Trivy)\n        - secrets-scan      # Предотвращение утечки учётных данных (Gitleaks)\n  - deploy-staging:\n      steps:\n        - deploy-to-staging\n        - integration-test\n        - performance-test\n  - deploy-production:\n      steps:\n        - canary-deploy-10-percent\n        - automated-rollback-on-error-spike\n        - progressive-rollout-to-100-percent\n        - post-deploy-smoke-test\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Разработчики не настраивают пайплайны — они просто пушат код. Платформа автоматически обрабатывает сборку, тестирование, сканирование и деплой.\u003C\u002Fp>\n\u003Ch3>Уровень 4: Предварительно одобренные инфраструктурные модули\u003C\u002Fh3>\n\u003Cp>Платформенная команда поддерживает библиотеку \u003Cstrong>Terraform-модулей\u003C\u002Fstrong> и \u003Cstrong>Kubernetes-операторов\u003C\u002Fstrong>, кодирующих организационные лучшие практики:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Каждый модуль версионирован, протестирован и проверен на безопасность\u003C\u002Fli>\n\u003Cli>Модули обеспечивают соглашения по тегированию, сетевые политики, лимиты ресурсов и расписания бэкапов\u003C\u002Fli>\n\u003Cli>Оценка стоимости рассчитывается перед провизионированием\u003C\u002Fli>\n\u003Cli>Обнаружение дрифта оповещает, когда инфраструктура расходится с объявленным состоянием\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Уровень 5: Ограждения и политики\u003C\u002Fh3>\n\u003Cp>Ограждения — секретный ингредиент, делающий самообслуживание безопасным. Без них самообслуживание превращается в «разработчики создают всё что хотят, и счёт взрывается».\u003C\u002Fp>\n\u003Cp>\u003Cstrong>OPA (Open Policy Agent)\u003C\u002Fstrong> и \u003Cstrong>Kyverno\u003C\u002Fstrong> обеспечивают политики на нескольких уровнях:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Admission в Kubernetes\u003C\u002Fstrong> — блокировка деплоев без лимитов ресурсов, health check-ов или security context-ов\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Terraform plan\u003C\u002Fstrong> — отклонение инфраструктурных изменений, нарушающих бюджет или правила соответствия\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Шлюзы CI\u002FCD\u003C\u002Fstrong> — провал сборок, вносящих критические уязвимости или пропускающих обязательные тесты\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Runtime\u003C\u002Fstrong> — оповещение или блокировка runtime-поведения, нарушающего базовые линии безопасности\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Пример политики Kyverno:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\">apiVersion: kyverno.io\u002Fv1\nkind: ClusterPolicy\nmetadata:\n  name: require-resource-limits\nspec:\n  validationFailureAction: Enforce\n  rules:\n    - name: check-limits\n      match:\n        any:\n          - resources:\n              kinds: [\"Pod\"]\n      validate:\n        message: \"Все контейнеры должны иметь лимиты CPU и памяти\"\n        pattern:\n          spec:\n            containers:\n              - resources:\n                  limits:\n                    memory: \"?*\"\n                    cpu: \"?*\"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"ai-ci-cd-76-3\">AI в CI\u002FCD: 76% внедрение и в 3 раза меньше сбоев деплоя\u003C\u002Fh2>\n\u003Cp>Отчёт State of DevOps 2026 показывает, что \u003Cstrong>76% инженерных организаций\u003C\u002Fstrong> теперь используют AI в CI\u002FCD-пайплайнах — по сравнению с 31% в 2024 году. Влияние измеримо: команды, использующие AI-ассистированный CI\u002FCD, сообщают о \u003Cstrong>3-кратном снижении сбоев деплоя\u003C\u002Fstrong> и \u003Cstrong>40% сокращении lead time\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Ch3>Где AI помогает в пайплайне\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Этап\u003C\u002Fth>\u003Cth>Применение AI\u003C\u002Fth>\u003Cth>Влияние\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Code review\u003C\u002Ftd>\u003Ctd>AI-комментарии, предложения по безопасности\u003C\u002Ftd>\u003Ctd>На 30% меньше багов доходят до CI\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Генерация тестов\u003C\u002Ftd>\u003Ctd>AI генерирует unit и integration тесты из изменений кода\u003C\u002Ftd>\u003Ctd>На 60% выше покрытие тестами\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Выбор тестов\u003C\u002Ftd>\u003Ctd>AI предсказывает, какие тесты релевантны для изменения\u003C\u002Ftd>\u003Ctd>На 70% короче выполнение тест-сьюта\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Риск деплоя\u003C\u002Ftd>\u003Ctd>AI оценивает риск деплоя на основе характеристик изменения\u003C\u002Ftd>\u003Ctd>На 50% меньше высокосерьёзных инцидентов\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Реагирование на инциденты\u003C\u002Ftd>\u003Ctd>AI коррелирует деплой с аномалиями в продакшене\u003C\u002Ftd>\u003Ctd>На 65% быстрее MTTR\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Решение о откате\u003C\u002Ftd>\u003Ctd>AI рекомендует откат на основе тренда ошибок\u003C\u002Ftd>\u003Ctd>На 80% быстрее инициация отката\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>AI-управляемый выбор тестов\u003C\u002Fh3>\n\u003Cp>Одно из наиболее эффективных применений AI в CI\u002FCD — \u003Cstrong>предиктивный выбор тестов\u003C\u002Fstrong>. Вместо запуска всего тест-сьюта при каждом коммите (30-60 минут для больших кодовых баз) AI-модели предсказывают, какие тесты могут упасть:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Launchable\u003C\u002Fstrong> и \u003Cstrong>Gradle Predictive Test Selection\u003C\u002Fstrong> — лидирующие инструменты\u003C\u002Fli>\n\u003Cli>Анализируют историю результатов тестов и паттерны изменений кода\u003C\u002Fli>\n\u003Cli>Типичный результат: запуск 20% тест-сьюта, обнаружение 99% сбоев\u003C\u002Fli>\n\u003Cli>Среднее сокращение времени CI: 60-70%\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>AI-ассистированная оценка риска деплоя\u003C\u002Fh3>\n\u003Cp>Платформенные команды обучают модели для оценки риска деплоя на основе:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Размера изменения (строки кода, изменённые файлы)\u003C\u002Fli>\n\u003Cli>Радиуса поражения (количество зависимых сервисов)\u003C\u002Fli>\n\u003Cli>Опыта автора с кодовой базой\u003C\u002Fli>\n\u003Cli>Времени с последнего деплоя\u003C\u002Fli>\n\u003Cli>Исторической частоты сбоев для похожих изменений\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Высокорисковые деплои автоматически получают дополнительные меры защиты: меньшие canary-проценты, более длинные периоды наблюдения и шлюзы с человеческим одобрением.\u003C\u002Fp>\n\u003Ch2 id=\"devsecops\">DevSecOps: автоматизированное и встроенное сканирование безопасности\u003C\u002Fh2>\n\u003Cp>Движение «shift left» превратилось из лозунга в автоматизированную реальность. В современном IDP сканирование безопасности \u003Cstrong>встроено в платформу\u003C\u002Fstrong> — разработчики не выбирают, запускать его или нет.\u003C\u002Fp>\n\u003Ch3>Стек сканирования безопасности\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Уровень\u003C\u002Fth>\u003Cth>Инструмент\u003C\u002Fth>\u003Cth>Что обнаруживает\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>IDE\u003C\u002Ftd>\u003Ctd>Semgrep, Snyk IDE\u003C\u002Ftd>\u003Ctd>Баги при разработке\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Pre-commit\u003C\u002Ftd>\u003Ctd>Gitleaks, TruffleHog\u003C\u002Ftd>\u003Ctd>Утечки секретов\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>SAST\u003C\u002Ftd>\u003Ctd>Semgrep, CodeQL\u003C\u002Ftd>\u003Ctd>Уязвимости кода\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>SCA\u003C\u002Ftd>\u003Ctd>Snyk, Dependabot, Trivy\u003C\u002Ftd>\u003Ctd>Уязвимые зависимости\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Контейнер\u003C\u002Ftd>\u003Ctd>Trivy, Grype\u003C\u002Ftd>\u003Ctd>Уязвимости образов\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>IaC\u003C\u002Ftd>\u003Ctd>Checkov, tfsec\u003C\u002Ftd>\u003Ctd>Ошибки конфигурации инфраструктуры\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>DAST\u003C\u002Ftd>\u003Ctd>ZAP, Nuclei\u003C\u002Ftd>\u003Ctd>Runtime-уязвимости\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Runtime\u003C\u002Ftd>\u003Ctd>Falco, Tetragon\u003C\u002Ftd>\u003Ctd>Аномальное поведение\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>Безопасность цепочки поставок\u003C\u002Fh3>\n\u003Cp>Атаки на цепочки поставок ПО ускорили внедрение:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>SLSA Level 3\u003C\u002Fstrong> — происхождение сборки для всех артефактов\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sigstore\u002Fcosign\u003C\u002Fstrong> — подпись образов контейнеров\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Генерация SBOM\u003C\u002Fstrong> (SPDX или CycloneDX) для каждого развёрнутого артефакта\u003C\u002Fli>\n\u003Cli>\u003Cstrong>VEX-документы\u003C\u002Fstrong> для уязвимостей зависимостей\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Платформа автоматизирует всё это. Разработчики не генерируют SBOM и не подписывают образы вручную — CI\u002FCD-пайплайн делает это прозрачно.\u003C\u002Fp>\n\u003Ch2 id=\"developer-experience\">Developer Experience как метрика\u003C\u002Fh2>\n\u003Cp>Наиболее прогрессивные платформенные команды приняли \u003Cstrong>Developer Experience (DevEx)\u003C\u002Fstrong> как первоклассную метрику, измеряемую комбинацией количественных и качественных сигналов:\u003C\u002Fp>\n\u003Ch3>DORA-метрики (количественные)\u003C\u002Fh3>\n\u003Cp>Четыре DORA-метрики остаются золотым стандартом измерения производительности поставки ПО:\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Метрика\u003C\u002Fth>\u003Cth>Порог элитного уровня\u003C\u002Fth>\u003Cth>Как помогает платформенная инженерия\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Частота деплоя\u003C\u002Ftd>\u003Ctd>По запросу (несколько раз в день)\u003C\u002Ftd>\u003Ctd>Самообслуживаемый деплой, автоматизированные пайплайны\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Lead time изменений\u003C\u002Ftd>\u003Ctd>Менее 1 часа\u003C\u002Ftd>\u003Ctd>Готовые шаблоны, AI-выбор тестов\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Частота сбоев изменений\u003C\u002Ftd>\u003Ctd>Менее 5%\u003C\u002Ftd>\u003Ctd>Автоматизированное сканирование, canary-деплои\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Время восстановления сервиса\u003C\u002Ftd>\u003Ctd>Менее 1 часа\u003C\u002Ftd>\u003Ctd>Автоматический откат, инструменты инцидентов\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>Фреймворк SPACE (качественный)\u003C\u002Fh3>\n\u003Cp>Фреймворк SPACE (Satisfaction, Performance, Activity, Communication, Efficiency) захватывает то, что DORA упускает — человеческий опыт использования платформы:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Опросы удовлетворённости разработчиков\u003C\u002Fstrong> — ежеквартальные опросы с оценкой платформы по шкале 1-10\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Time-to-first-deploy\u003C\u002Fstrong> — сколько времени нужно новому сотруднику для первого деплоя в продакшен? (Цель: <1 дня)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Индекс когнитивной нагрузки\u003C\u002Fstrong> — сколько инструментов, систем и процессов должен понимать разработчик? (Цель: минимум, платформа абстрагирует остальное)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Доля toil\u003C\u002Fstrong> — какой процент времени разработчика тратится на недифференцирующую инфраструктурную работу? (Цель: <10%)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"idp-12\">Построение IDP: 12-недельная дорожная карта\u003C\u002Fh2>\n\u003Cp>Для команд, начинающих с нуля, вот прагматичная дорожная карта:\u003C\u002Fp>\n\u003Ch3>Недели 1-3: Фундамент\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Разверните Backstage с базовым каталогом сервисов\u003C\u002Fli>\n\u003Cli>Зарегистрируйте существующие сервисы (имя, владелец, репозиторий, ссылка на документацию)\u003C\u002Fli>\n\u003Cli>Создайте первый шаблон для наиболее распространённого типа сервиса\u003C\u002Fli>\n\u003Cli>Организуйте канал платформенной команды для обратной связи от разработчиков\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Недели 4-6: Стандартизация CI\u002FCD\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Определите стандартный CI\u002FCD-пайплайн для основного языка\u002Fфреймворка\u003C\u002Fli>\n\u003Cli>Интегрируйте сканирование безопасности (SAST, SCA, сканирование контейнеров)\u003C\u002Fli>\n\u003Cli>Реализуйте автоматизированные canary-деплои в продакшен\u003C\u002Fli>\n\u003Cli>Измерьте базовые DORA-метрики\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Недели 7-9: Инфраструктура самообслуживания\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Создайте Terraform-модули для общих ресурсов (БД, кэш, очередь)\u003C\u002Fli>\n\u003Cli>Предоставьте их через Backstage-действия или API самообслуживания\u003C\u002Fli>\n\u003Cli>Реализуйте тегирование и видимость стоимости\u003C\u002Fli>\n\u003Cli>Разверните ограждения OPA\u002FKyverno\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Недели 10-12: Полировка и измерение\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Проведите опрос удовлетворённости разработчиков\u003C\u002Fli>\n\u003Cli>Измерьте time-to-first-deploy для моделируемого нового сотрудника\u003C\u002Fli>\n\u003Cli>Определите топ-3 болевых точки разработчиков и устраните их\u003C\u002Fli>\n\u003Cli>Задокументируйте архитектуру платформы и опубликуйте в Backstage\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"\">Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3 id=\"platform-engineering-devops\">Platform Engineering устраняет потребность в DevOps-инженерах?\u003C\u002Fh3>\n\u003Cp>Нет. Платформенная инженерия реорганизует работу DevOps, а не устраняет её. DevOps-инженеры становятся платформенными инженерами — вместо поддержки отдельных команд они строят и поддерживают общую платформу. Навыки те же (инфраструктура, автоматизация, надёжность), но масштаб смещается с уровня команды на уровень организации.\u003C\u002Fp>\n\u003Ch3 id=\"\">Какой размер платформенной команды оптимален?\u003C\u002Fh3>\n\u003Cp>Распространённое соотношение — 1 платформенный инженер на 15-25 разработчиков приложений. Организация с 200 инженерами обычно нуждается в 8-12 платформенных инженерах. Начните с малого (3-4 человека) и растите по мере необходимости.\u003C\u002Fp>\n\u003Ch3 id=\"backstage\">Backstage — единственный вариант для портала разработчика?\u003C\u002Fh3>\n\u003Cp>Backstage — самый популярный open-source вариант, но существуют альтернативы. Port, Cortex и OpsLevel предлагают коммерческие порталы с меньшими операционными затратами. Некоторые команды строят кастомные порталы поверх существующих инструментов. Однако экосистема плагинов и сообщество Backstage делают его выбором по умолчанию для большинства организаций.\u003C\u002Fp>\n\u003Ch3 id=\"\">Что если разработчики сопротивляются использованию платформы?\u003C\u002Fh3>\n\u003Cp>Сопротивление обычно возникает из двух источников: платформа не решает их реальных проблем или ощущается как ограничение, а не как инструмент. Решение одно: разговаривайте с разработчиками, понимайте их болевые точки и стройте платформу вокруг их потребностей — не вокруг того, что платформенная команда считает нужным. Сделайте платформу путём наименьшего сопротивления, а не мандатом.\u003C\u002Fp>\n\u003Ch3 id=\"\">Как обрабатывать команды с уникальными требованиями?\u003C\u002Fh3>\n\u003Cp>Платформа должна покрывать 80% общих потребностей через стандартизированные пути. Для оставшихся 20% предоставьте «пути отхода» — возможность кастомизировать пайплайны, использовать собственные Terraform-модули или запрашивать нестандартные ресурсы через лёгкий процесс ревью. Цель — «золотые пути, а не золотые клетки».\u003C\u002Fp>\n","ru","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:37.176892Z","Platform Engineering поглотил DevOps: строим IDP в 2026","80% крупных организаций имеют платформенные команды. IDP с Backstage, самообслуживаемой инфраструктурой, AI CI\u002FCD и ограждениями. Архитектура и дорожная карта.","platform engineering",null,"index, follow",[22,27,31],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000012","DevOps","devops","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000006","Docker","docker",{"id":32,"name":33,"slug":34,"created_at":26},"c0000000-0000-0000-0000-000000000007","Kubernetes","kubernetes",[36,43,49],{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":41,"published_at":42},"d0200000-0000-0000-0000-000000000013","Почему Бали становится хабом импакт-технологий Юго-Восточной Азии в 2026 году","pochemu-bali-stanovitsya-khabom-impakt-tekhnologiy-2026","Бали занимает 16-е место среди стартап-экосистем Юго-Восточной Азии. Растущая концентрация Web3-разработчиков, ИИ-стартапов в области устойчивого развития и компаний в сфере эко-тревел-технологий формирует нишу столицы импакт-технологий региона.","Инженерия","2026-03-28T10:44:37.953039Z",{"id":44,"title":45,"slug":46,"excerpt":47,"locale":12,"category_name":41,"published_at":48},"d0200000-0000-0000-0000-000000000012","Защита данных в ASEAN: чек-лист разработчика для мультистранового комплаенса","zashchita-dannykh-asean-chek-list-razrabotchika-komplaens","Семь стран ASEAN имеют собственные законы о защите данных с разными моделями согласия, требованиями к локализации и штрафами. Практический чек-лист для разработчиков мультистрановых приложений.","2026-03-28T10:44:37.944001Z",{"id":50,"title":51,"slug":52,"excerpt":53,"locale":12,"category_name":41,"published_at":54},"d0200000-0000-0000-0000-000000000011","Цифровая трансформация Индонезии на $29 миллиардов: возможности для софтверных компаний","tsifrovaya-transformatsiya-indonezii-29-milliardov-vozmozhnosti-dlya-kompaniy","Рынок IT-услуг Индонезии вырастет с $24,37 млрд в 2025 году до $29,03 млрд в 2026 году. Облачная инфраструктура, искусственный интеллект, электронная коммерция и дата-центры обеспечивают самый быстрый рост в Юго-Восточной Азии.","2026-03-28T10:44:37.917095Z",{"id":13,"name":56,"slug":57,"bio":58,"photo_url":19,"linkedin":19,"role":59,"created_at":60,"updated_at":60},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]