В первой части мы остановились на том, что Продуктовая аллея DevOpsConf 2026 показала рынок как поиск более зрелых эксплуатационных моделей. AppSec, observability и AIOps важны, потому что заставляют команды ответить на важные вопросы: где остаётся ответственность, кто владеет дефектом, с какого SLO начинается мониторинг и какие решения нельзя отдавать автоматизации без контроля.

Во второй части мы поищем ответы на вопросы кто и на какой платформе будет сопровождать production через Kubernetes, инфраструктурные платформы, DevOps as a Service, облака, data-платформы и инструменты разработчика. Команды пытаются снять рутину эксплуатации, собрать внутренние платформы, автоматизировать инфраструктуру через API и Terraform, а заодно встроить AI и data-инструменты в SDLC так, чтобы они помогали разработчику, но не получали бесконтрольный доступ к критичным средам.

Платформы: Kubernetes как продукт, сервис или облачная среда

В инфраструктурном блоке хорошо видно, что Kubernetes давно перестал быть «просто оркестратором». Для одних команд это платформа с жизненным циклом, для других - услуга, которую хочется отдать внешней команде, для третьих - часть on-prem-облака с PaaS-слоем и требованиями безопасности.

Чем зрелее платформа, тем меньше времени команда тратит на ручное поднятие окружений, аварийные обновления и споры о том, кто отвечает за DNS, ingress, сертификаты, секреты, мониторинг и сетевые политики. Но зрелость платформы нельзя оценить по одному скриншоту консоли. Нужно смотреть на жизненный цикл, поддержку, модель ответственности и интеграцию в delivery-процесс.

Deckhouse Kubernetes Platform Community Edition: готовая платформа с открытым исходным кодом

Deckhouse Kubernetes Platform — это подход к K8s как к управляемой платформе.  Решение объединяет в себе необходимое для работы: безопасность, продвинутые сетевые возможности, надёжное хранение данных, наблюдаемость и даже виртуализацию.  

Deckhouse Kubernetes Platform Community Edition (DKP CE) — это Open Source-версия платформы, которая позволяет использовать Kubernetes, а не обслуживать. 

Практический смысл заключается в переходе от сборки собственного стека к готовой эксплуатационной модели. Kubernetes сам по себе легко развернуть, но сложность начинается дальше: обновления, совместимость компонентов, мониторинг, безопасность, сетевые политики и управление доступом быстро превращаются в постоянную инженерную нагрузку.

DKP CE закрывает эту зону за счет уже собранных и интегрированных компонентов платформы. Это снижает количество ручных операций, уменьшает зависимость от разрозненных инструментов и делает эксплуатацию более предсказуемой. 

Платформа развивается с 2017 года, под управлением Open Source-редакции уже больше 600 кластеров, что говорит о накопленной практике эксплуатации. Для оценки конкретного внедрения важнее смотреть на требования команды, инфраструктуру, модель поддержки и соответствие платформы внутренним процессам.

Для инженерных и платформенных команд ценность DKP CE заключается в готовой реализации и автоматизации всех этапов о жизненного цикла Kubernetes. Если обновления, мониторинг, хранение секретов, управление кластерами и сопутствующие инфраструктурные функции становятся частью единой продуктовой модели, команда меньше зависит от разрозненных YAML-файлов, локальных договоренностей и ручных операций. 

При этом платформенный подход не отменяет необходимости зрелой эксплуатации. DKP CE может упростить управление Kubernetes и связанными компонентами, но команда всё равно должна определить модель ответственности, правила обновлений, требования к отказоустойчивости, подход к сетевой безопасности, управление доступами и процесс сопровождения кластеров. Поэтому при выборе Kubernetes-платформы важно оценивать и скорость первичного запуска, и то, кто и как будет обновлять, тестировать, поддерживать и развивать её через год после внедрения.

DaaS от «Фланта»: DevOps как сервисс передачей практик

DevOps as a Service — это не продукт в классическом смысле «установили и пользуемся», а сервисная модель комплексного DevOps-сопровождения разработки цифровых продуктов и инфраструктуры в круглосуточном режиме силами выделенной команды экспертов.

Такой формат особенно заметен там, где внутренняя команда растёт быстрее, чем успевает выстроить платформенную экспертизу. Если релизы уже завязаны на Kubernetes, инфраструктура меняется часто, а инциденты все еще разбираются вручную, внешняя команда может ускорить взросление процесса. Но здесь есть риск: DevOps as a Service не должен превращаться в «чёрный ящик», куда компания отдаёт всё, не понимая, как потом жить без внешней помощи.

Поэтому при оценке DevOps as a Service важно смотреть не только на скорость реакции внешней команды, но и на то, остаются ли у заказчика репозитории, инфраструктурный код, конфигурации, документация и понятные регламенты эксплуатации, с которыми инфраструктуру можно поддерживать дальше. Хороший сервисный формат должен оставлять после себя не только исправленные пайплайны, но и задокументированные процессы, прозрачную модель работы с инцидентами, понятные роли и улучшенную инженерную дисциплину.

Для пилота DaaS-модели полезно оценивать, становится ли команде понятнее собственная инфраструктура. Хороший признак, когда после первых недель появляются не только настроенный CI/CD-конвейер или мониторинг, но и договорённости по инцидентам, инструкции для дежурств и ясные критерии эскалации.

Практический вывод: аутсорсинг DevOps может повысить инфраструктурную зрелость, но ценность появляется только тогда, когда  подрядчик не только берет на себя эксплуатацию, но и передает заказчику практики, обеспечивая прозрачность процессов.

Yandex Cloud Stackland: on-prem-платформа с Kubernetes API и PaaS-слоем

Yandex Cloud Stackland относится к инфраструктурным платформам для заказчиков, которым нужен облачный подход к разработке и эксплуатации, но внутри собственного контура. Платформа объединяет инфраструктурный слой, Kubernetes-абстракции и PaaS-сервисы для развертывания в закрытой инфраструктуре компании.

Ценность решения связана с самим принципом: платформа стремится сохранить привычную для облака модель работы с API, автоматизацией, Kubernetes-абстракциями и готовыми сервисами. Это особенно актуально для организаций, где публичное облако недоступно из-за регуляторных, безопасностных или внутренних ограничений, но команды разработки всё равно хотят использовать облачные паттерны при создании и сопровождении приложений.

Yandex Cloud Stackland стоит рассматривать как облачный слой для закрытого контура, где базовая платформа и набор PaaS-сервисов проектируются вместе с целевой инфраструктурой заказчика. Если решение внедряется только как «ещё один Kubernetes», часть его ценности теряется. Если же вокруг платформы формируется внутренний каталог сервисов, разработчикам становится проще собирать приложения из готовых управляемых компонентов, не погружаясь каждый раз в детали инфраструктурной реализации.

Для пилотного внедрения важно заранее определить, какие PaaS-модули действительно нужны командам разработки и как будет устроена операционная модель платформы. В эту модель входят проекты, квоты, доступы, секреты, эксплуатационные роли и правила сопровождения сервисов. Документация Yandex Cloud Stackland отдельно описывает ресурсную модель, проекты и работу с секретами, поэтому эти вопросы стоит проверять еще до запуска промышленного контура.

Ограничение такого класса платформ связано с тем, что облачный интерфейс сам по себе не решает организационные вопросы эксплуатации. Чтобы Yandex Cloud Stackland работал как внутренняя облачная платформа, команде необходимо заранее определить владельцев сервисов, правила предоставления ресурсов, модель поддержки, требования к безопасности и процесс развития внутреннего каталога. В этом случае on-prem-платформа даёт не только инфраструктуру, но и более привычный облачный способ работы с сервисами внутри закрытого контура.

Yandex Managed Service for Kubernetes: managed-кластер и граница ответственности

Yandex Managed Service for Kubernetes закрывает сценарий, в котором команда хочет работать с Kubernetes как с облачной услугой и отдать провайдеру эксплуатацию управляющего слоя. Облачный провайдер берет на себя control plane: администрирование мастеров, обновление компонентов, выпуск security-патчей, выпуск и продление сертификатов, а также часть интеграций. SSH-доступа к мастерам у пользователя нет, поскольку эта зона остаётся ответственностью провайдера. Чтобы граница была прозрачной, провайдер отдельно публикует документ с разделением зон ответственности между собой и клиентом.

Смысл такого подхода в том, что значительная часть эксплуатационной рутины уходит в managed-сервис. Сюда входят релизные каналы и управляемый процесс обновлений, cluster autoscaler и автомасштабирование групп узлов, CSI-драйверы для интеграции с объектным хранилищем, Marketplace готовых приложений и maintenance window, через которое команда сама выбирает время обновлений и обычно сдвигает его ближе к ночи, в часы низкой нагрузки. Типовые сценарии ожидаемы для такой платформы: микросервисы, CI/CD, batch-задачи и ML-инференс, под который доступны разные GPU-платформы.

Отдельное преимущество связано с управлением расходами. Для переменной нагрузки работает автоскейлинг групп узлов, когда число узлов растёт под пик и сокращается после него. Прерываемые (спотовые) виртуальные машины заметно дешевле обычных, и часть команд комбинирует их с непрерываемыми, например в пропорции пятьдесят на пятьдесят. Биллинг дает детализацию по каждому кластеру, а кастомные метки позволяют отслеживать потребление по отдельным группам узлов. Этот сценарий чаще нужен крупным заказчикам со строгими бюджетными ограничениями.

Для разработчика ключевым остается понимание того, где проходит граница ответственности. Провайдер обеспечивает SLA 99,9% на доступность control plane в сценарии высокодоступных мастеров, размещенных в разных зонах, и при нарушении SLA предусмотрены компенсации. Это не означает  гарантию доступности приложения целиком: рабочие ноды, разнесение workload по зонам, security-группы, права сервисных аккаунтов, сетевые политики, хранилище и сама архитектура отказоустойчивости остаются задачей команды. Модель здесь именно разделенная: провайдер предоставляет готовый инструмент, а за безопасность внутри пользовательской зоны отвечает сам пользователь.

При выборе managed-кластера полезно заранее проверить именно пользовательскую зону. Самые частые ошибки на старте связаны с недостаточными правилами security-групп, нехваткой прав у сервисных аккаунтов и кластерами из одного мастера в одной зоне, которые ломаются при первой же инфраструктурной проблеме. Managed-сервис снижает порог входа и закрывает рутину control plane, однако инженерную дисциплину он не заменяет: модель доступа, требования к отказоустойчивости, сетевую безопасность и аудит архитектуры команда определяет сама, и при наличии архитекторов эти решения стоит валидировать вместе с ними.

Рег.облако: инфраструктура, которую можно быстро получить и описать кодом

Рег.облако представляет более классический облачный слой: виртуальные серверы, выделенные серверы, GPU, Kubernetes, S3-совместимое объектное хранилище и другие инфраструктурные сервисы для бизнеса. В каталоге Рег.облака среди сервисов перечислены облачные серверы, выделенные серверы с GPU и Cloud GPU, а также объектное хранилище S3.

В таком продукте важны две вещи: насколько быстро можно получить ресурсы и насколько хорошо они автоматизируются. Облако становится частью инженерного процесса только тогда, когда окружения можно создавать воспроизводимо, изменения — ревьюить, а ручные действия через консоль — сокращать до минимума.

Рег.облако интересно смотреть не только как IaaS для виртуальных машин, но и как слой для специализированных вычислительных сценариев. Спрос на GPU появляется в AI-задачах, рендеринге, ML-пайплайнах и экспериментальных средах, а объектное хранилище и Kubernetes позволяют собирать вокруг этих вычислений более полноценную инфраструктуру приложения.

Для DevOps-команд отдельный критерий — поддержка инфраструктуры как кода. Если провайдер даёт API и Terraform-подход, облако можно встроить в обычный delivery-процесс: окружения поднимаются повторяемо, изменения проходят review, а конфигурация перестаёт жить только в головах администраторов.

Данные: когда одной базы уже недостаточно

Отдельно от AppSec и Kubernetes стоит YTsaurus — продукт про хранение и обработку больших данных. Но для современного разработчика это тоже часть DevOps-ландшафта: всё больше приложений не просто обслуживают транзакции, а строят вокруг себя аналитику, фичи на данных, ML-пайплайны и тяжёлые вычисления.

YTsaurus: распределённое хранение и вычисления в одном контуре

YTsaurus — open source-платформа распределенного хранения и обработки больших данных. Продукт объединяет несколько связанных подсистем: MapReduce для распределённых вычислений, SQL-движок для аналитических запросов, планировщик задач и KV-хранилище для OLTP-сценариев.

Практическая задача такой платформы связана с тем, какую часть data-platform-нагрузки она берёт на себя. Когда в проекте появляются большие объёмы событий, аналитические витрины, регулярные вычисления и несколько команд-потребителей данных, связка из отдельных хранилищ, вычислительных контуров и самодельных пайплайнов быстро становится сложной в сопровождении. В такой ситуации важна не только производительность отдельных компонентов, но и возможность управлять разными типами нагрузок в единой инфраструктурной модели.

YTsaurus делает акцент на отказоустойчивости и эксплуатационной надежности распределенного кластера. В архитектуре заявлены отсутствие единой точки отказа, автоматическая репликация данных между серверами и возможность обновлять кластер без потери прогресса вычислений. Платформа также покрывает разные сценарии работы с данными: batch-обработку, ad hoc-аналитику, OLTP-задачи, машинное обучение и построение ETL-процессов.

Для разработчиков и data-команд важно, что YTsaurus не ограничивает работу с данными одним способом доступа. SQL-запросы могут выполняться через CHYT powered by ClickHouse, а ETL-процессы — через SPYT powered by Apache Spark. Такой подход снижает риск ситуации, когда каждая команда вынуждена строить отдельный контур для аналитики, ETL или ML-нагрузок и затем самостоятельно решать задачи переноса данных, синхронизации и эксплуатации.

Ценность YTsaurus раскрывается в сценариях, где разные нагрузки можно держать в одном управляемом контуре. Это позволяет сократить количество ручных переносов данных между Hadoop, OLTP-хранилищами, аналитическими базами и отдельными вычислительными кластерами. При этом внедрение такой платформы нельзя сводить только к замеру производительности на пилоте. Для промышленной эксплуатации заранее важны capacity-планирование, владельцы данных, квоты, изоляция команд и нагрузок, профили использования и правила сопровождения.

Инструменты разработчика: Git-платформа и AI без бесконтрольного доступа к production

После Kubernetes, облаков и data-платформ логично перейти к слою, с которого всё начинается для разработчика: репозиторию, ревью, задачам, CI/CD и помощникам в IDE. В первой части мы уже говорили, что рынок осторожно относится к «магическому» AIOps. Во второй части та же осторожность нужна для AI в SDLC: ассистент может ускорять рутину, но не должен становиться непрозрачным актором, который сам меняет критичную инфраструктуру без правил и ревью.

SourceCraft: единый контур разработки с AI-ассистентом и облачной интеграцией

SourceCraft от Яндекса — платформа для разработки IT-продуктов, которая объединяет работу с исходным кодом, управление версиями, тестирование, сборку, развертывание и сопровождение программных решений. В состав платформы входит SourceCraft Code Assistant: он помогает разработчику писать код через подсказки и автодополнение, а в агентском режиме может сопровождать цепочку от идеи до развертывания в Yandex Cloud. В такой сценарий входят создание задачи, написание кода, генерация автотестов, проверка безопасности, подготовка pull request и запуск деплоя.

Ключевая особенность такого подхода связана не только с наличием AI-помощника, а с тем, где именно он встроен в процесс разработки. Если ассистент работает рядом с репозиторием, задачами, проверками безопасности и CI/CD, он может учитывать контекст продукта и delivery-процесса, а не просто генерировать отдельные фрагменты кода. Это делает AI-инструмент ближе к реальной инженерной работе, где важны зависимости между задачами, изменениями, тестами, ревью и поставкой в среду эксплуатации.

При этом близость AI-помощника к delivery-процессу требует понятных ограничений. Для такого класса решений особенно важны права доступа, обязательное ревью изменений, правила запуска деплоя и журналирование действий. AI может ускорять рутинные операции, помогать с генерацией кода, тестов и документации, но решение о попадании изменений в production должно оставаться частью управляемого командного процесса.

Отдельный слой SourceCraft связан с безопасностью разработки. В платформе предусмотрены сканер секретов в коде, анализ зависимостей, сводная статистика по ИБ-рискам и сообщения о рисках на этапе написания кода — до попадания изменений в рабочую версию приложения. Такой подход важен для SDLC, потому что часть проблем можно обнаруживать еще до pull request или до запуска полноценного pipeline, снижая стоимость исправления и уменьшая риск попадания небезопасных изменений дальше по процессу.

SourceCraft Code Assistant работает в чат-режиме и режиме автоподсказок, поддерживает более 30 языков программирования, доступен как плагин для Visual Studio Code и JetBrains IDE и не использует ресурсы локальной машины разработчика. Эти характеристики делают инструмент ближе к ежедневной среде работы инженера: ассистент не требует отдельного переключения в новый контур и может использоваться непосредственно там, где разработчик пишет и проверяет код.

При оценке SourceCraft полезно разделять два режима применения AI в SDLC. В IDE ассистент закрывает индивидуальную рутину разработчика: подсказки, генерацию кода, тестов, документации и первичную проверку изменений. На уровне команды ключевыми остаются pull request, ревью, обсуждение архитектурных и продуктовых последствий, проверка безопасности и контролируемая история решений. Поэтому ценность AI в SDLC стоит оценивать не по эффектности демонстрационного сценария, а по тому, насколько он встраивается в существующие правила ревью, безопасности и доставки без расширения неконтролируемых прав.

GitFlic: локальная Git-платформа как центр командной разработки

GitFlic закрывает базовый, но критически важный слой SDLC — работу с Git-репозиториями, командами, merge request, задачами, релизами и CI/CD. Платформа предназначена для удалённой и комплексной работы с системой контроля версий. В ней предусмотрены импорт проектов с переносом файлов, истории коммитов, веток и тегов, командная работа, уровни доступа, merge request, задачи и релизы.

Практическая ценность такой платформы проявляется в том, что вокруг репозитория формируется управляемый процесс разработки. В одном контуре фиксируется, кто имеет доступ к коду, как проходит ревью, где живут задачи, какие проверки запускаются перед слиянием изменений, где хранятся артефакты и как выпускаются релизы. Для команд, которым важны локальный контур, self-hosted-сценарии или контроль над инфраструктурой разработки, Git-платформа становится не просто альтернативой публичному хостингу, а частью внутренней engineering-платформы.

Отдельное значение имеет CI/CD-слой GitFlic. В нём используются ключевые сущности delivery-процесса: pipeline, job, artifacts, cache и agent/runner. Такая модель помогает команде описывать стадии поставки, управлять выполнением задач, сохранять результаты сборки, переиспользовать зависимости через кэш и контролировать, где именно исполняются pipeline-задачи.

При внедрении Git-платформы важно оценивать не только удобство работы с репозиториями, но и то, насколько она поддерживает реальные правила разработки внутри команды. Сюда входят модель доступа, обязательность ревью, правила merge request, связь задач с изменениями, хранение артефактов, управление релизами и прозрачность CI/CD-процесса. Если эти правила заранее не определены, платформа даст инструменты для организации работы, но не заменит саму инженерную дисциплину.

Ограничение связано с тем, что Git-платформа является основой SDLC, а не полной заменой всех смежных процессов. Она помогает связать код, задачи, ревью, сборку и релизы, но качество разработки по-прежнему зависит от архитектурных решений, тестовой дисциплины, правил безопасности, культуры code review и зрелости delivery-практик команды.

Краткий вывод

Если первую часть можно было читать как обзор того, как AppSec, observability и AIOps взрослеют в сторону управляемых процессов, то вторая часть показывает слои платформенной ответственности. Deckhouse, DaaS, Yandex Cloud Stackland и Рег.облако по-разному отвечают на вопрос, где и кем эксплуатируется инфраструктура. YTsaurus выводит разговор за пределы классического application delivery и напоминает, что данные тоже требуют платформенного подхода. SourceCraft и GitFlic возвращают фокус к разработчику: к репозиторию, ревью, CI/CD, AI-помощникам и правилам, по которым изменения доходят до production.

Мы рекомендуем использовать нашу статью как чек-лист зрелости разработки. Если Kubernetes живёт в production, но обновления пугают стоит смотреть платформенный слой и релизные каналы. Если инфраструктурная экспертиза не успевает за ростом продукта сравнивайте сервисную модель, внутреннюю платформу и облачный слой. Если данные уже стали отдельной системой со своими владельцами и SLA рекомендуем посмотреть на data-платформы. Если AI и Git-инструменты входят в SDLC, то заранее определять границы доступа, ревью и ответственность за изменения.

И самое важное: не нужно ждать, что продукт сам исправит процесс. Продуктовая аллея показала инструменты, но ценность появляется только там, где команда заранее договорилась о владельцах, правилах, SLO, политиках безопасности, границах AI-автоматизации и критериях успешного пилота.