Отдельно проверим доступность приложений и управляющего API. Если обновление включает перезапуск etcd, выполняющиеся запросы к API server могут зависнуть на это время, даже после drain узла.

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

Сначала расставим границы обновления

У Kubernetes несколько компонентов с собственными версиями. API server принимает запросы управления, kubelet запускает контейнеры на конкретном узле, а kubeadm помогает собирать и обновлять кластер. Поэтому перед работой нужно установить, какие версии сейчас используются и каким способом создано окружение.

Начните с команды, которая покажет версии клиента kubectl и сервера:

В выводе ищите Client Version и Server Version. Это ещё не инвентаризация всех узлов: версия сервера описывает ту часть системы, к которой обратился клиент. Версии kubelet на всех узлах покажет следующая команда:

В столбце VERSION указаны версии kubelet, в STATUS ожидается Ready. Сохраните этот вывод для сравнения после обновления.

Официальный гайд kubeadm рассчитан на переход 1.36.x → 1.37.x. Если кластер старше, подготовьте последовательность промежуточных обновлений. Для EKS, GKE, AKS и других управляемых сервисов понадобится процедура провайдера: команды обслуживания самостоятельно установленного control plane нельзя автоматически переносить в managed-окружение.

Во время перехода разные версии компонентов допустимы в определённых пределах. Например, kubelet не должен быть новее API server. Когда в отказоустойчивом кластере одновременно работают API server 1.36 и 1.37, обновлять kubelet до 1.37 ещё рано. Совместимость должна сохраняться с обоими серверами. Поэтому следуйте порядку действий: сначала управляющие компоненты, потом рабочие узлы.

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

Какие static Pods перестанут запускаться

Обычный Pod создаётся через Kubernetes API. Static Pod запускается kubelet по локальному описанию на узле. Это позволяет поднимать компоненты, которые нужны для работы самого API server. В кластерах kubeadm таким способом запускаются компоненты control plane.

Static Pods изначально не предназначались для чтения объектов API, однако ошибка позволяла некоторым ссылкам на Secrets и ConfigMaps работать. В 1.37 это поведение окончательно запрещено: feature gate PreventStaticPodAPIReferences, позволявший отключить ограничение, удалён. Проблема возникает у Pod с такими ссылками, а не у любого Pod, использующего секрет.

Проверьте каталог, из которого kubelet читает static-манифесты. В конфигурации kubelet его задаёт staticPodPath; для типового kubeadm-окружения в рассмотренных материалах используется /etc/kubernetes/manifests/. Если у вас другой путь, проверять нужно именно его.

Особое внимание уделите полям configMapRef, secretRef, configMapKeyRef и secretKeyRef. Найденные ссылки требуют разбора: какой компонент читает значение, почему он запускается как static Pod и как предоставить ему конфигурацию до появления API server. Проверка должна охватывать и шаблоны, из которых вы создаёте новые узлы. В разборе devs group найдёте варианты исправления: предоставить компоненту локальный файл через hostPath или перенести подходящую нагрузку в DaemonSet. Выбор зависит от того, нужен ли компонент для запуска самого control plane.

В официальном руководстве есть ещё одна полезная деталь: kubelet читает файлы static-манифестов независимо от расширения. Если оставить рядом с рабочим файлом копию с окончанием .backup, она тоже может попасть в обработку. Поэтому резервные копии храните вне каталога static Pods. .

Какие параметры помешают запуску kubelet

В 1.37 обновлён встроенный cAdvisor, который собирает статистику контейнеров. Часть его старых флагов больше не принимается. Если они передаются kubelet при запуске, процесс завершается с ошибкой. Среди удалённых параметров есть --containerd, --boot-id-file, --machine-id-file, --global-housekeeping-interval и семейство --storage-driver-*. Из прежних флагов cAdvisor сохранён --housekeeping-interval.

Проверьте, как запускается служба: изучите systemd unit, файл /var/lib/kubelet/kubeadm-flags.env и /etc/default/kubelet. Набор мест зависит от установки: unit может подхватывать параметры из другого файла. Поэтому просмотр одного unit ещё не означает, что все аргументы найдены.

В выводе смотрите, откуда служба получает аргументы и переменные окружения. Сопоставьте найденные параметры с полным списком удалённых флагов в changelog. Название --containerd здесь относится к старому параметру cAdvisor; по нему нельзя делать вывод, что сам runtime containerd требуется удалить.

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

Отдельно проверьте панели и правила оповещений, завязанные на cAdvisor. В 1.37 исчезают серии container_cpu_load_average_10s, container_cpu_load_d_average_10s и container_tasks_state. Составьте список зависимых проверок.

Что проверить в SELinux и томах

SELinux использует метки объектов и процессов для контроля доступа. Раньше при подготовке тома runtime мог рекурсивно менять метки файлов и каталогов. Если файлов много, этот обход занимает время. Оптимизированный механизм задаёт контекст при монтировании тома через -o context=<label>.

В Kubernetes 1.37 SELinuxMount включён по умолчанию. При этом механизм применяется при выполнении набора условий: нужен подходящий PVC, известная Kubernetes SELinux-метка и поддержка со стороны драйвера. CSI-драйвер объявляет такую поддержку полем spec.seLinuxMount: true. На узлах без SELinux эти изменения не действуют.

Риск появляется при совместном использовании тома на одном узле. Официальный разбор приводит два сценария: Pods с разными метками используют разные subPath одного тома; либо том разделяют на привилегированный и непривилегированный Pods. При новом способе монтирования один из конфликтующих Pods может остаться в ContainerCreating.

В Kubernetes 1.36 можно заранее проверить такие конфликты с помощью selinux-warning-controller, который работает внутри kube-controller-manager. По умолчанию он отключён. Для проверки включите его через параметр --controllers у kube-controller-manager; в документации приведён пример --controllers=*,selinux-warning-controller.

После включения контроллер сообщает о найденных конфликтах через события и метрику selinux_warning_controller_selinux_volume_conflict. Он проверяет и Pods на разных узлах, поскольку после пересоздания они могут оказаться на одном.

Для приложения, которому нужно прежнее поведение, есть настройка Recursive. Ниже кусок спецификации Pod, который сохраняет рекурсивное применение меток:

У Deployment или StatefulSet этот параметр должен находиться внутри спецификации Pod в шаблоне: spec.template.spec.securityContext. Проверьте итоговый манифест, который действительно получает кластер. Применять исключение ко всем приложениям заранее не нужно: сначала определите затронутые нагрузки и протестируйте выбранное поведение.

Что ещё изменилось в конфигурации

Раздел Urgent Upgrade Notes содержит несколько менее заметных изменений. Их удобно пройти отдельным списком до тестового обновления.

• Удалена версия scheduling.k8s.io/v1alpha2. Changelog требует убрать соответствующие объекты до обновления. Если команда использовала экспериментальные API планировщика, ей нужно разобрать эти объекты и способ их замены.
• Значение eventRecordQPS: 0 теперь означает отсутствие ограничения частоты событий. Чтобы сохранить ограничение, задайте ненулевое значение; в release notes приведён пример 50.
• Kubelet выводит эффективную конфигурацию при запуске. Администраторам предлагают проверить доступ к nodes/logs и ограничить его доверенными пользователями.

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

Для каждого пункта запишите результат применительно к своему кластеру: используется ли настройка, кто за неё отвечает и что требуется изменить. Если экспериментальные API не включались, это тоже полезный результат проверки. Он объясняет, почему соответствующий шаг исключён из вашей процедуры, и позволяет повторить аудит позднее.

Нужно ли одновременно менять containerd и IPVS

Некоторые обзоры требуют перейти на containerd 2.x перед Kubernetes 1.37. В чейнджлоге удаление части настроек kubelet и связанного с ними резервного поведения перенесено с 1.37 на 1.38 для согласования с поддержкой containerd 1.7. Этот перенос не распространяется на перечисленные выше флаги cAdvisor: они уже удалены в 1.37 и мешают запуску kubelet, если остались в аргументах службы. Совместимость установленного runtime и срок его поддержки нужно проверять отдельно.

С IPVS ситуация тоже требует точной формулировки. В 1.37 этот режим kube-proxy продолжает работать. Официальный анонс указывает ожидаемое отключение по умолчанию в 1.40 и удаление в 1.43. Текущий режим можно посмотреть так:

Если видите mode: ipvs, добавьте миграцию в план инфраструктурных работ. Сам этот результат ещё не означает, что обновление на 1.37 нужно остановить.

Проверка cgroup v1 относится к совместимости узлов. Отказ kubelet запускаться с cgroup v1 по умолчанию действует с версии 1.35. В 1.37 сохраняется временное переопределение failCgroupV1: false, однако проект рекомендует переходить на cgroup v2.

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

Как подготовить тестовое обновление

Тест должен проверять те зависимости, которые есть в продакшене. В перечень для своего окружения включите сеть, подключение хранилищ, правила допуска запросов и мониторинг. Если приложение использует особые настройки безопасности или обновляется как StatefulSet, эти особенности тоже должны попасть в проверку.

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

Отдельно продумайте поведение при выводе узла из работы. PodDisruptionBudget, или PDB, ограничивает допустимое число недоступных реплик при добровольных прерываниях, которые используют Eviction API. Обычный drain учитывает этот бюджет. При нехватке доступных реплик он может ждать, пока приложение восстановится.

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

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

Если для подготовки нужна внешняя команда, на нашем сайте, Centicore Group есть услуги по развёртыванию ИТ-ландшафта, миграции ИТ-инфраструктуры и поддержке облачных сервисов. Перед обращением соберите сведения о текущем окружении и требованиях приложений: с ними будет проще обсудить объём работ.

В каком порядке обновлять кластер

Начните с первого узла control plane. По официальному гайду на нём обновляют kubeadm до выбранной версии 1.37.x, проверяют план и запускают обновление управляющих компонентов. Пакеты берут из репозитория соответствующей минорной версии.

Изучите предложенный план. Затем выполните команду обновления, заменив x конкретным номером патча:

На остальных узлах control plane сначала обновите пакет kubeadm, затем выполните sudo kubeadm upgrade node. Повторять kubeadm upgrade plan на каждом узле не требуется. Обновляйте управляющие узлы последовательно. Отдельно проверьте инструкцию установленного сетевого плагина CNI и выполните необходимые шаги его обновления.

Обновление kubelet и kubectl нужно выполнить и на узлах control plane. Для каждого узла предусмотрены drain, установка пакетов, перезапуск kubelet и uncordon. Учитывайте совместимость версий: если kubelet может обращаться к нескольким API server, все они должны быть обновлены до 1.37 перед переходом этого kubelet на 1.37. После обслуживания управляющих узлов переходите к рабочим узлам.

Перед минорным обновлением kubelet узел нужно освободить от обычных рабочих Pods. Команда drain помечает его недоступным для стандартного планирования и запрашивает выселение нагрузок:

Дождитесь успешного завершения. Если операция ждёт, сначала выясните причину. PDB может ограничивать выселение, а приложению может требоваться время на восстановление. --ignore-daemonsets позволяет продолжить при наличии Pods DaemonSet, но не удаляет их. Drain также не останавливает static Pods, поэтому управляющие компоненты требуют своей процедуры обслуживания.

После обновления управляющих узлов переходите к рабочим узлам под Linux. На каждом рабочем узле обновите пакет kubeadm, выполните kubeadm upgrade node, проведите drain, затем обновите пакеты kubelet и kubectl до выбранной версии. Команда upgrade node подготавливает локальную конфигурацию kubelet; установку нового пакета нужно выполнить отдельно.

После установки пакетов перезапустите службу:

Когда закончите проверки узла, разрешите планирование:

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

Что проверить перед следующим узлом

Сначала убедитесь, что kubelet работает и узел вернулся в Ready. Затем проверьте перенесённые приложения по сценарию, подготовленному до обновления. Сравните результат с исходным состоянием: появились ли новые ошибки, подключились ли тома, продолжают ли поступать данные мониторинга.

В отдельную проверку вынесите StatefulSet. В 1.37 функция MaxUnavailableStatefulSet включена по умолчанию. Поле spec.updateStrategy.rollingUpdate.maxUnavailable задаёт, сколько Pods может быть недоступно во время обновления StatefulSet. Значение maxUnavailable по умолчанию равно 1. Проверяйте его вместе с spec.podManagementPolicy: документация описывает одновременное обновление нескольких Pods для политики Parallel и maxUnavailable больше 1. При таком сочетании Pods могут становиться готовыми в разном порядке, что подходит не каждому приложению.

Просмотрите существующие стратегии обновления. Если поле уже было задано в манифесте, проверьте, какое поведение оно даёт при включённой функции. Для приложения, где нужен порядок восстановления экземпляров — отдельно тестируйте ускоренный rollout.

При этом PDB и стратегия StatefulSet регулируют разные операции. PDB учитывается при выселении через Eviction API; собственное rolling-обновление контроллера StatefulSet не ограничивается этим бюджетом. Поэтому нормальный drain и rollout приложения должны быть отдельными пунктами проверки.

Лучше заранее сформулировать условие продолжения обычным предложением: «следующий узел обновляем, когда перенесённые нагрузки восстановились и прошли свои проверки». За ним должны стоять конкретные результаты тестов. Если один Pod всё ещё ждёт том или приложение отвечает с ошибкой, переход к следующему узлу только усложнит поиск причины.

Что делать, если обновление остановилось

Разберите, на каком этапе произошёл сбой: при выполнении kubeadm, запуске kubelet или восстановлении приложения. Сохраните вывод команды и журналы проблемной службы. До выяснения причины оставьте остальные узлы на текущем этапе.

Для kubelet начните с проверки состояния и журнала:

Если проблема в старом аргументе запуска, вернитесь к проверке конфигурации службы. Если kubelet работает, а приложение застряло на подключении тома, продолжайте разбор на уровне Pod и хранения. Так результаты диагностики будут связаны с конкретным этапом обновления.

Официальный гайд допускает повторный запуск kubeadm upgrade, если операция оборвалась и автоматическое восстановление не завершилось. Процедура идемпотентна: повторное выполнение приводит компоненты к заявленному состоянию. Это механизм восстановления незавершённого обновления.

Kubeadm также создаёт каталоги резервных копий в /etc/kubernetes/tmp: kubeadm-backup-etcd-<date>-<time> и kubeadm-backup-manifests-<date>-<time>. Первая копия относится к локальному участнику etcd; при внешнем etcd соответствующий каталог будет пустым. Вторая содержит сохранённые static-манифесты. Используйте их по документированному сценарию для вашей конфигурации.

При обновлении StatefulSet со стратегией RollingUpdate и политикой OrderedReady возможна остановка: Pod с новой конфигурацией не переходит в Ready, и контроллер ждёт его восстановления. Известная проблема проявляется при восстановлении: даже после возврата рабочего шаблона контроллер может продолжать ждать готовности неисправного Pod. После возврата шаблона нужно удалить затронутые Pods с ошибочной конфигурацией, чтобы контроллер пересоздал их. Этот сценарий нужно заранее включить в тест восстановления приложения.

Когда можно переходить в прод

На начало сентября 2026 года последним патчем ветки остаётся 1.37.0. Релиз 1.37.1 запланирован на 15 сентября; дата окончания поддержки ветки указана как 28 октября 2027 года. Перед началом обновления ещё раз проверьте страницу релиза⁠: запланированный патч может ещё не выйти.

Советуем дождаться 1.37.1 или 1.37.2, если нет конкретной причины переходить сразу. Официальная рекомендация Kubernetes — использовать актуальные патчи исходной и целевой минорных версий. Ожидание можно включить в график, продолжая проверку совместимости и подготовку окружения.

Решение о продакшене должно опираться на результаты теста. Команда знает, какие манифесты пришлось исправить, как приложения пережили выселение с узла и где лежат данные для восстановления. После первого обновлённого узла она может объяснить, почему продолжать допустимо.

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

Разбираем все три слоя: как получить трассировку, не переписывая сервисы, как превратить трассы в метрики, по которым можно действовать, и как не принять смену методики измерения за изменение продукта.

Трассировка через eBPF снимает налог на ручное инструментирование, но требует ядра не ниже 5.8, несрезанной таблицы символов и знания устройства планировщика Go.

При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов в ядро ежесекундно и потолок расхода в 200–600 мс процессорного времени на ядро.

Медленный запрос это не одна проблема, а пять разных: лишняя работа, борьба за ресурсы, давление среды, деградация плана и патологические шаблоны вроде N+1.

Инструменты базы говорят, что дорого внутри неё, но не говорят, какой сервис это вызвал и был ли запрос пользовательским. Этот контекст приносят трассы.

Версия браузера, тип навигации, библиотека сбора данных и версия инструментирования входят в определение метрики: смешав их в одном графике, вы увидите изменение измерения вместо изменения продукта.

Слой первый наблюдаемости: собрать данные, не трогая код

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

Альтернатива, ставшая эксплуатационно пригодной за последние пару лет, — подключение зондов eBPF напрямую к символам рантайма и точкам входа библиотек HTTP и gRPC. Трассы восстанавливаются из событий ядра и пользовательского пространства, а файл бинарника на диске не меняется вовсе: правки идут только в памяти работающего процесса, точечно и обратимо.

Почему с Go это сложнее, чем с C

Зонд работает так: в заданное смещение работающего бинарника ставится инструкция прерывания, при попадании в неё ядро останавливает поток, выполняет свою программу и возобновляет исполнение. Для C и Rust это ложится на прологи функций почти без остатка. Go добавляет три осложнения.

Планирование горутин. Планировщик Go раскладывает множество горутин на меньшее число системных потоков. Один HTTP-запрос может обрабатываться горутиной на одном потоке в момент срабатывания зонда и переехать на другой поток до записи ответа. Наивный зонд, читающий идентификатор потока или процесса, теряет непрерывность на этом переезде. Правильный якорь — идентификатор горутины, а достать его можно либо через карту, построенную по отладочной информации, либо вычислением фиксированного смещения от указателя, лежащего в регистре локального хранилища потока.

Соглашение о вызовах. В Go 1.17 аргументы функций переехали со стека в регистры, причём сначала только на amd64; на arm64 и ppc64 это произошло версией позже. Программа зонда, написанная под прежнее соглашение и читающая контекст со смещения от указателя стека, на новых бинарниках прочитает мусор. Значит, трассировщику нужна либо логика зондов под каждую минорную версию языка, либо вычисление места по отладочной информации самого бинарника.

Встраивание функций. Компилятор Go агрессивно встраивает мелкие функции, и нужный символ может просто отсутствовать по ожидаемому адресу. Зонд, поставленный не туда, даёт пропущенные отрезки трассы или испорченные аргументы, причём молча.

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

Главная нерешённая проблема: передача контекста между сервисами

Если нельзя вписать заголовок в коде приложения, как передать идентификатор трассы дальше по цепочке вызовов? Есть три подхода, и практически применим один.

• Писать заголовок прямо в пакет на уровне сетевого интерфейса. Требует расширенных привилегий и работает только для нешифрованного HTTP/1.1: шифрование выполняется выше уровня сокета, и программа видит уже зашифрованные байты.
• Пропускать исходящие вызовы через локальный вспомогательный прокси, который держит соответствие идентификатора горутины и контекста трассы и вставляет заголовки перед пересылкой. Добавляется сетевой переход, зато шифрование не ломается.
• Править карту заголовков прямо в памяти процесса. Соответствующая функция ядра помечена как опасная и действительно способна повредить память: каждая её загрузка пишет предупреждение в журнал ядра, работа требует широкой привилегии CAP_SYS_ADMIN, а в режиме блокировки ядра она запрещена совсем.

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

Что ломается в продакшене

• Идентификаторы горутин переиспользуются. При высокой конкурентности номер может уйти на новую горутину раньше, чем потребитель разобрал события старой.
• Обновление бинарника сдвигает смещения символов. Зонды старого отображения ядро снимает само, и новый бинарник какое-то время работает без трассировки. Слежение за изменением файла сокращает разрыв до секунд, но не убирает его.
• Требования к ядру. Кольцевые буферы нужны ядру от 5.8, а переносимая компиляция зондов требует 5.4 с включённой отладочной информацией о типах. Матрицу ядер стоит проверить до внедрения, а не после.
• Срезанные бинарники. Сборка без таблицы символов и отладочной информации лишает трассировщик возможности сопоставить имена функций со смещениями. Компромисс: оставить хотя бы таблицу символов, заплатив примерно 10–15% размера бинарника.

Сколько это стоит в процессорном времени

Зонды не бесплатны: каждое срабатывание это программное прерывание с входом в ядро. При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов ежесекундно. Опубликованные замеры дают порядка 1–3 мкс на срабатывание на современном оборудовании, то есть верхняя оценка расхода составляет 200–600 мс процессорного времени в секунду на одно ядро.

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

Правильный вывод не «заменить инструментирование зондами», а «использовать оба». Зонды дают сплошное покрытие и базовое распределение задержек без усилий разработчиков, включая сторонние бинарники, которые вы не можете изменить. Ручное инструментирование даёт смысловое наполнение: идентификатор пользователя, арендатора, флаг функциональности — то, чего из сырых байтов HTTP не синтезировать. Наиболее точные схемы наблюдаемости держат оба слоя, причём слой зондов работает проверкой на непротиворечивость для отрезков, которые приложение теряет под нагрузкой.

Слой второй: превратить трассы в решения

Собранная телеметрия сама по себе ничего не улучшает. Больше телеметрии означает больше объектов для разглядывания, а не больше понимания. Полезной она становится, когда из неё извлечены закономерности, на которые можно действовать.

«Медленный запрос» это пять разных диагнозов

Прежде чем что-то чинить, стоит понять, чем именно болен запрос. Разбор CNCF раскладывает медленные запросы к базе на пять непохожих причин:

• Лишняя работа. Обычно это полный перебор таблицы из-за отсутствующего или неприменимого индекса. Выборка по идентификатору клиента без индекса растёт с 20 мс на десяти тысячах строк до минут на десяти миллионах. Запрос не менялся, изменился объём данных.
• Борьба за ресурсы. Идеально оптимизированный запрос стоит в ожидании блокировок или свободного соединения. Запрос, проводящий 95% времени в ожидании блокировки, оптимизацией текста не лечится: ему нужна перекройка транзакций.
• Давление среды. Насыщение процессора, узкое место ввода-вывода и нехватка памяти замедляют любой запрос с любым планом: тот же текст запроса и тот же план на нагруженной машине отработает в разы дольше, чем на свободной, и оптимизировать тут нечего.
• Деградация плана. Данные и текст запроса те же, а план исполнения изменился. Устаревшая статистика после массовой загрузки заставляет планировщик выбрать заведомо плохую стратегию.
• Патологические шаблоны. Проблема N+1 выполняет сотню быстрых запросов по две миллисекунды последовательно, добавляя двести миллисекунд задержки на одно только выполнение, не считая сетевых издержек на каждый обмен с базой. Ни один запрос не является медленным, а шаблон катастрофичен и в журнал медленных запросов не попадает вовсе.

Чего не хватает встроенным инструментам базы

Журналы медленных запросов, хранилища запросов и разбор планов прекрасно отвечают на вопрос, что дорого внутри базы. Они не отвечают на вопросы, которые задаёт дежурный инженер: какой сервис это вызвал, пользовательская это работа или фоновая, связано ли это со всплеском задержки, который сейчас расследуется.

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

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

Слой третий: не принять смену измерения за изменение продукта

Третья ошибка самая обидная, потому что данные при этом верны. Метрика может быть абсолютно точной, а рассказанная по ней история — совершенно неверной.

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

Общий тренд не объясняет вашу просадку

В июньском наборе данных о реальных пользователях Chrome, опубликованном в середине июля, доля источников с хорошей отрисовкой основного содержимого упала до 67,7%, с хорошей задержкой отклика на взаимодействие до 85,9%, а доля проходящих все три ключевых показателя до 55,3%. Исключением оказалась стабильность вёрстки, поднявшаяся до 81,4%.

Google объяснил движение сезонностью, сравнив его с прошлым годом. Контекст полезный, но он не является доказательством того, что у вас локально ничего не сломалось. Релиз, рекламная кампания, изменение формы согласия, сдвиг в составе устройств или новый сторонний скрипт способны совпасть с общеотраслевым движением.

Гарри Робертс формулирует критерий проверки прямо: если общая доля прошедших упала на 1,2 процентного пункта, а конкретный сайт просел на четыре, широкий тренд разницу не объяснил. Верно и обратное: если сайт почти идеально повторяет рынок по браузерам и устройствам, срочное расследование в коде потратит время всей команды впустую.

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

Изменение методики выглядит как изменение продукта

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

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

Компенсация это не исправление

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

Улучшение реальное, но документ по-прежнему перевёрстывается, если у картинки не заданы размеры или объявление меняет высоту. Браузер убирает одно видимое следствие, а причина остаётся на месте. Проверять после такого изменения стоит липкие шапки, ленты, интерфейс согласия и встроенные блоки, а чинить всё равно вёрстку, а не полагаться на маскировку.

Тот же разрыв виден и в метрике отклика. Большинство команд сегодня способны сказать, плохой у них отклик или нет. Заметно меньше способны сказать, какое именно взаимодействие в этом виновато, на каком шаге пользовательского пути оно случилось и что его задержало. Весь разбор Гарри Робертса именно про этот разрыв между наличием числа и наличием понимания.

Что забрать с собой

Три слоя решают три разные задачи, и провал на любом из них выглядит одинаково: дашборд есть, ответа нет. Без покрытия вы не видите части системы. Без перевода трасс в метрики видите всё и не понимаете ничего. Без дисциплины в чтении принимаете смену методики за регрессию.

Начинать проще всего с третьего слоя: он не требует ни новой инфраструктуры, ни единой строчки кода, только дисциплины чтения. Сверьте движение своих метрик с движением рынка и убедитесь, что расследуете настоящую регрессию, а не смену методики. Дальше уже видно, чего не хватает: покрытия или перевода трасс в решения.

Материалы разбора: устройство трассировки Go-сервисов через eBPF, перевод медленных запросов в метрики надёжности и разбор того, как метрики вводят в заблуждение.

Всё это принято называть обвязкой, и определение у неё простое.

Обвязка — это весь код между тем, что вы печатаете, тем, что получает модель, тем, что модель выдаёт, и тем, что вы видите. И это много кода, не имеющего отношения к ИИ. Модели при этом выглядят в значительной степени взаимозаменяемыми.

Разбираем три слоя обвязки, на которых результат меняется заметнее, чем от смены модели: маршрутизация вычислений, страховка надёжности в конвейере и контроль границ информации.

Обвязка — это код без единой нейросети внутри: сборка запроса, управление контекстом, проверки на выходе и координация нескольких моделей.

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

Анализ сгенерированного кода не показывает, как он поведёт себя при отказе зависимости, поэтому проверки надёжности строятся на воспроизведении реальных отказов, а не на чтении текста.

Пять источников почти всех сбоев одни и те же: процессор, память, диск, ввод-вывод и сеть. С них и начинают автоматические проверки.

Модели с постоянной памятью раскрывают лишние данные в неподходящем контексте, причём доля нарушений растёт с числом задач, а просьба быть осторожнее проблему не решает.

Слой первый: что и где считать

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

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

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

Слой второй: страховка надёжности в конвейере

Оговорка сразу: это уже не обвязка вокруг обращения к модели, а обвязка процесса поставки. Принцип тот же, объект другой: проверяется не ответ модели, а код, который агент написал и который вот-вот уедет в продакшен.

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

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

Почему чтения кода недостаточно

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

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

Пять ресурсов, с которых начинают

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

• Избыточность по зонам и узлам: что происходит при отказе целой зоны, отдельного хоста или контейнера.
• Масштабирование по процессору: корректно ли настроено расширение при всплеске и сворачивается ли оно обратно после.
• Масштабирование по памяти: то же самое, включая корректную деградацию, если расшириться не удалось.
• Отказ зависимости: как ведёт себя приложение, когда до внешнего или внутреннего сервиса не достучаться.
• Задержка зависимости: сервис доступен, но отвечает медленно. Приложение деградирует аккуратно, уходит к запасному источнику или просто падает.

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

Результат проверки возвращается агенту

Ставится это всё в конце конвейера сборки, прямо перед продвижением версии. Провалилась проверка — код помечается и уходит обратно вместе с описанием теста и предложенным исправлением.

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

Слой третий: границы информации

Третий слой обсуждают реже всего, а он становится критичным ровно в тот момент, когда система обзаводится постоянной памятью о пользователе.

Речь о контекстной целостности — принципе из теории приватности Хелен Ниссенбаум: какие сведения уместно раскрывать при выполнении конкретной задачи. Домашний адрес нужен для оформления доставки и совершенно неуместен при составлении рабочего письма коллеге. Человек проводит эту границу не задумываясь, у модели с сохранённой памятью её приходится обеспечивать отдельно.

Что показали измерения

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

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

Ещё важнее динамика. Нарушения накапливаются и по числу задач, и по числу прогонов: при росте использования с одной задачи до сорока доля нарушений у GPT-5 поднимается с 0,1 до 9,6%, а при пятикратном исполнении одного и того же промпта достигает 25,1%. Последняя цифра особенно неприятна: она означает нестабильное поведение, когда на идентичный запрос модель раскрывает разные атрибуты.

Почему просьба быть осторожнее не помогает

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

Вывод авторов прямой: проблема не решается ни лучшим промптингом, ни увеличением масштаба модели, потому что требуется собственно рассуждение о контексте, в котором система сейчас работает.

Что действительно даёт эффект

Вторая работа как раз про это. Авторы сначала просят модель явно рассуждать о том, какие сведения уместны для текущей задачи, а затем закрепляют это обучением с подкреплением. На синтетическом наборе всего из 700 примеров с разнообразными контекстами и нормами раскрытия им удалось заметно сократить неуместное раскрытие, не потеряв в качестве решения задач, причём для моделей разных размеров и семейств.

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

Что забрать с собой

Три слоя выглядят разнородно, но подчиняются одному правилу: свойство, которое вам нужно от системы, обеспечивается кодом вокруг модели, а не выбором модели. Маршрутизация даёт цену и приватность инфраструктуры: данные не покидают периметр. Автоматические проверки отказов дают устойчивость. Явный контроль границ информации даёт приватность самих данных пользователя, независимо от того, где физически стоит модель.

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

Материалы разбора: интервью Шнайера об обвязке и локальных моделях, проверки надёжности в конвейере с ИИ-кодом и обзор двух работ о контекстной целостности.

До 1.37 для этого нужен был сторонний компонент либо alpha-гейт. Теперь это часть ядра, и владельцы очередей и batch-обработчиков могут перестать платить за поды, которые часами ждут задач. Экономия заметнее всего там, где под резервирует дорогие ресурсы: выделенные ядра или GPU. Обычным HTTP-сервисам функция не подходит в чистом виде, и авторы предупреждают об этом прямо.

• Beta по умолчанию: feature gate HPAScaleToZero включён и в kube-apiserver, и в kube-controller-manager Kubernetes 1.37.
• minReplicas: 0 работает только с объектной или внешней метрикой (например, длина очереди); HPA только на CPU и памяти API-сервер отклонит.
• Kubernetes Service не буферизует запросы, пока нет готовых подов, поэтому для HTTP нужен отдельный слой буферизации.
• Условие ScaledToZero=True отличает автоматическое уменьшение до нуля от ручной паузы: HPA не разбудит workload, который остановил не он.
• Перед откатом версии или выключением гейта нужно вернуть minReplicas не меньше 1 и поднять всё, что стоит на нуле.

Почему CPU и память для этого не годятся

Обычно HPA масштабирует по загрузке CPU или памяти, а эти метрики приходят из работающих подов. Когда реплик ноль, измерять нечего, и сигнала «пора подниматься» не будет. Объектные и внешние метрики от подов не зависят: длина очереди существует независимо от того, есть ли у неё потребители. Поэтому minReplicas: 0 требует хотя бы одной такой метрики в спецификации, а HPA, где есть только ресурсные метрики, API-сервер отклоняет.

В блоге приводится пример с метрикой Prometheus queue_consumer_lag. Чтобы HPA её увидел, нужен адаптер, который отдаёт значение через External Metrics API, например Prometheus Adapter с правилом в externalRules. Перед созданием HPA авторы советуют проверить, что метрика читается:

Если запрос не возвращает значение, сначала чинится конвейер метрик: HPA не сможет поднять workload с нуля, пока метрика недоступна. В этом случае он выставляет условие ScalingActive=False с причиной вроде FailedGetExternalMetric, и восстановить мощность придётся либо починкой метрики, либо ручным масштабированием.

Как выглядит HPA с нулём реплик

Пример из блога нацелен на Deployment queue-worker, допускает от нуля до десяти реплик и просит по одной реплике на каждые 30 задач в очереди:

Когда очередь пуста, HPA уменьшает Deployment до нуля. Когда приходят задачи, внешняя метрика по-прежнему доступна, контроллер пересчитывает число реплик и поднимает поды в пределах maxReplicas. Остальные правила HPA продолжают действовать: в частности, окно стабилизации при уменьшении по умолчанию пять минут, так что короткий провал длины очереди не снесёт всех воркеров разом. Окно настраивается через spec.behavior.scaleDown.

Есть важная деталь: Deployment нужно запускать хотя бы с одной репликой. Ручная установка нуля реплик всегда означала паузу автоскейлинга, и это поведение сохранено: HPA не разбудит workload, который остановил не он сам.

Как контроллер отличает «ноль» от «паузы»

Ноль реплик двусмыслен: либо HPA сам всё погасил, либо оператор руками остановил сервис. Разрешает это условие статуса ScaledToZero. Когда HPA уменьшает workload с одной и более реплик до нуля, он записывает ScaledToZero=True, и последующие циклы согласования знают, что нулевое состояние принадлежит контроллеру и метрики нужно продолжать читать. После подъёма условие меняется на ScaledToZero=False с причиной NotScaledToZero. Workload на нуле без условия ScaledToZero=True считается поставленным на паузу. Посмотреть условия можно командой kubectl describe hpa queue-worker.

Кому это не подходит и чем грозит откат

Плата за нулевые реплики называется cold start: HPA должен заметить изменение метрики, планировщик разместить под, приложение подняться. Для очереди, которая надёжно хранит задачи, это нормально. Для HTTP это проблема: Service в Kubernetes не буферизует запросы, пока нет готовых подов, поэтому запросы, пришедшие в «ноль», просто не будут обслужены. Запросным нагрузкам нужен отдельный буферизующий слой, и блог его не предлагает, это остаётся на стороне пользователя.

С обновлением тоже есть оговорки. В 1.37 гейт HPAScaleToZero включён по умолчанию в обоих компонентах: API-сервер принимает minReplicas: 0, а controller-manager выполняет масштабирование по условию. При поэтапном обновлении control plane создавать HPA с нулём стоит только после того, как оба компонента обновлены и гейт активен на обоих: controller-manager без гейта воспринимает нулевые реплики как ручную паузу и может оставить workload лежать. Перед выключением гейта или откатом на версию без реализации на условиях нужно перевести затронутые HPA на minReplicas: 1 и выше и поднять до одной реплики всё, что сейчас стоит на нуле.

Что делать и что дальше

1. Проверьте версию кластера: по умолчанию функция включена начиная с 1.37. Что ещё вошло в этот релиз, мы разбирали в новости про потоковое чтение коллекций из etcd: https://tproger.ru/news/kubernetes-1-37-chitaet-bolwie-kollekcii-iz-etcd-potokom-i-ekono
2. Выберите кандидатов: потребители очередей, batch-обработчики, задачи на GPU. HTTP-сервисы без буфера оставьте на minReplicas: 1.
3. Убедитесь, что метрика читается через External Metrics API, до создания HPA с нулём.
4. Стартуйте Deployment с одной репликой и следите за условиями ScaledToZero и ScalingActive в describe hpa.
5. Оцените cold start для своего образа: время подъёма пода плюс инициализация приложения задают задержку первой задачи после простоя.

Путь у функции длинный: первая alpha-реализация появилась ещё в Kubernetes 1.16, версия 1.36 добавила условие ScaledToZero и поведение контроллера, которое отличает автоматику от ручной паузы, а 1.37 включила всё по умолчанию после интеграционных и end-to-end тестов на уменьшение до нуля и подъём по внешней метрике. Дизайн описан в KEP-2021, функцией владеет SIG Autoscaling. Про GA авторы пока не говорят: следующий шаг, по их словам, собрать эксплуатационный опыт с беты; обратную связь ждут в канале #sig-autoscaling в Slack Kubernetes.

Источники: Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler (блог Kubernetes, Johannes Würbach), KEP-2021: HPA supports scaling to and from zero pods, Prometheus Adapter: external metrics

Изображение на обложке: Логотип: The Kubernetes Authors

Для команд на TeamCity это означает, что пайплайны можно переводить из экспериментов в основные сборки, а тем, кто подключает к CI агентов вроде Junie или Claude Code, при подключении через OAuth больше не нужно выпускать персональный токен вручную: MCP-сервер TeamCity получил авторизацию OAuth с PKCE. Об этом сообщил в блоге JetBrains Дмитрий Коровин. Одновременно вышли исправления для двух предыдущих мажорных версий On-Premises: 2025.11.8 и 2026.1.4.

• Pipelines введены как EAP в TeamCity 2025.07; в 2026.2 они общедоступны в Cloud и On-Premises.
• В пайплайнах появились выбор ветки в режиме редактирования, предупреждение о защищённых ветках, запуск job при упавшем upstream, кнопка Promote, отладка отдельной job и пайплайны без репозитория.
• MCP получил teamcity_pipeline_get, teamcity_pipeline_post и teamcity_pipeline_delete; изменяющие инструменты работают только в Brave mode, который включается вручную.
• AI Assistant поддерживает свой ключ (BYOK): Anthropic, OpenAI, Google Gemini и совместимые с OpenAI локальные модели; сам помощник требует лицензии Enterprise.
• Kotlin DSL можно выполнять на билд-агентах, а не на сервере; плагин для IDE получил CLI и запуск сборок с незакоммиченными изменениями.

Что изменилось в пайплайнах

Pipelines появились в TeamCity 2025.07 как функция раннего доступа: сразу в Cloud и по запросу в On-Premises. С тех пор, по словам JetBrains, команда закрывала разрыв с классическими build configurations: добавила поддержку build features, шаги для .NET и возможность связывать пайплайны в цепочки сборок. Релиз 2026.2 объявляет пайплайны общедоступными на обеих поставках. Разработка при этом продолжается, дальнейшие планы вынесены в дорожную карту продукта.

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

В зависимостях между job появился переключатель Run job even if upstream fails: пайплайн доходит до конца даже после ошибки, а сам прогон при этом остаётся помеченным как упавший. JetBrains приводит очевидный сценарий: шаги очистки и уведомлений, которые должны выполниться всегда.

Кнопка Promote, которая запускает нижнюю часть цепочки от уже завершённой сборки, теперь работает и для пайплайнов. Пример из анонса: успешный прогон Build Docker image можно продвинуть в конфигурацию Upload to DockerHub и повторно задеплоить артефакт без пересборки. Отдельную job теперь можно отлаживать, не выходя из режима редактирования и не запуская весь пайплайн: лог и терминал открываются внизу редактора.

Ещё одно изменение: пайплайн можно создать без привязанного VCS root, выбрав при создании вариант Without repository. Раньше сценарии, которые ничего не выкачивают из репозитория, были доступны только в build configurations.

Как ИИ-агенты получают доступ к CI

MCP-эндпоинт, через который агенты используют сервер TeamCity как источник инструментов, появился в версии 2026.1. В 2026.2 к нему добавлены три инструмента для пайплайнов: teamcity_pipeline_get, teamcity_pipeline_post и teamcity_pipeline_delete. Чтобы агент не удалил пайплайн случайно, post и delete доступны только в Brave mode, который включается вручную; по умолчанию агент может только читать.

Авторизация MCP переведена на OAuth с PKCE. Раньше для подключения агента приходилось выпускать personal access token и прописывать его в конфигурации ИИ-окружения; при OAuth-подключении это не нужно, а ручной токен остаётся способом выдать агенту ограниченные права, например только на чтение. Плагин для IntelliJ IDEA стал поставляться вместе с CLI TeamCity и регистрирует MCP-сервер сам, так что интеграция с Junie или сторонними агентами, по словам JetBrains, требует минимум ручной настройки.

AI Assistant, встроенный помощник для разбора сборок и отладки CI, поддерживает Bring Your Own Key: в разделе Admin | AI Assistant вводится ключ разработчика, после чего запросы уходят в Anthropic, OpenAI, Google Gemini или в совместимую с OpenAI модель, в том числе развёрнутую локально. По документации, AI Assistant требует активной лицензии Enterprise, в том числе триальной, и недоступен на Professional; для команд, у которых нет доступа к провайдеру JetBrains AI, свой ключ это способ подключить ту модель, до которой доступ есть.

Что ещё вошло в релиз

• Повтор упавшей зависимости на месте. На вкладке Dependencies в настройках build configuration появилась группа Retry Settings: при включённом Use custom retry settings и заданном числе попыток TeamCity задерживает нижнюю сборку и повторяет упавшую зависимость, не перезапуская всю цепочку.
• Плагин для IDE показывает результаты тестов TeamCity прямо в IDE и умеет запускать удалённые сборки с локальными изменениями, которые ещё не закоммичены.
• Разработчики на Kotlin Multiplatform, установившие плагин в IDEA или Android Studio, могут получить бесплатный тариф TeamCity Cloud с лимитом 30 000 build credits в месяц для автоматически сгенерированных пайплайнов, которые тестируют и собирают iOS-приложения; плагин также упрощает интеграцию с TestFlight.
• Build feature Pull Requests для GitHub умеет сопоставлять pull request по исходной ветке, а не по ссылке на ветку: связанные PR в разных репозиториях с разными номерами собираются в одной цепочке.
• Для проектов с настройками в Kotlin DSL в удалённом репозитории можно выбрать, где выполняется этот код: на сервере или на билд-агентах. Выполнение на агентах JetBrains называет менее ограниченным и более безопасным, но предупреждает, что у обоих вариантов есть компромиссы, описанные в документации.

Что делать команде на TeamCity

1. Если пайплайны использовались в EAP, снятие статуса раннего доступа означает, что их можно переводить на основные сборки; полный список изменений JetBrains держит в разделе What's New документации.
2. Тем, кто остаётся на предыдущих мажорных версиях On-Premises, вышли обновления 2025.11.8 и 2026.1.4 с исправлениями ошибок.
3. Перед тем как дать агенту право менять пайплайны, оценить, нужен ли Brave mode: по умолчанию изменяющие MCP-инструменты выключены.
4. Если в проекте Kotlin DSL из удалённого репозитория, свериться с документацией по режимам компиляции до переключения на агенты.

Цены и условия лицензирования в анонсе не упоминаются. Релиз выходит через несколько дней после того, как JetBrains раскрыла детали взлома своего сервиса Cadence через непропатченный TeamCity, и на следующий день после выхода OIDC-плагина, который заменяет долгоживущие облачные ключи в CI короткими токенами. Следующий ориентир для пайплайнов, по словам компании, задаёт дорожная карта TeamCity.

Источники: TeamCity 2026.2: Pipelines General Availability, BYOK for AI Assistant, and More (блог JetBrains), What's New in TeamCity (документация)

Изображение на обложке: Логотип: JetBrains

Последняя капля, как её назвали инженеры CERN (перевод редакции), знакома всем, кто держит парк старого железа: RHEL и его производные собираются с флагом компилятора -march=x86-64-v2, и процессоры без нужных инструкций перестают загружать систему. В CERN это назвали принудительным устареванием. Для админа с парком машин десятилетней давности вопрос тот же: какую ветку дистрибутивов под них выбирать.

• Мигрируют 2200 с лишним промышленных компьютеров и встраиваемых систем управления ускорителями; срок до конца 2026 года; целевая система Debian 13.
• Дата-центры и вычислительная инфраструктура экспериментов остаются на RHEL и AlmaLinux, уточнение опубликовано отдельно.
• CERN около десяти лет использовала Scientific Linux, которую сама сопровождала, затем с 2015 года CentOS.
• Рассматривали CentOS Stream как естественное продолжение, но решающим стал флаг -march=x86-64-v2 по умолчанию в RHEL.
• Названные проблемы Debian: нет стандартного инструментария для автоматической сборки и публикации пакетов и для хранения нескольких версий одного пакета.

Что такое x86-64-v2 и почему он отсекает железо

Уровни микроархитектуры x86-64-v2, v3 и v4 описывают наборы инструкций, на которые компилятор может рассчитывать. Уровень v2 требует, среди прочего, SSE4.2 и POPCNT; это процессоры примерно 2009 года и новее. RHEL 9 и производные (AlmaLinux, Rocky, CentOS Stream 9) собираются под v2, поэтому на более старых CPU ядро и пользовательские программы просто не запускаются. Промышленные контроллеры и встраиваемые машины у ускорителей меняются редко: оборудование сертифицировано, проверено годами и работает. Debian по-прежнему собирает amd64 под базовый уровень x86-64, что и делает его вариантом для такого парка.

Чего CERN не хватило в Debian

По пересказу Phoronix, инженеры назвали два пробела. Первый: в экосистеме Debian нет стандартного инструментария для автоматической сборки и публикации собственных пакетов уровня того, к чему привыкли в мире RPM (Koji, Copr, mock). Второй: инструменты репозиториев плохо поддерживают хранение нескольких версий одного и того же пакета, что нужно для контролируемого отката на промышленных системах. Оба пробела CERN закрывает своими средствами; подробности обещаны в видеозаписи доклада с MiniDebConf.

Что остаётся на RHEL

Важное уточнение, которое Phoronix добавил после публикации: миграция касается только промышленных компьютеров управления ускорителями. Дата-центры CERN и вычислительная инфраструктура экспериментов остаются на RHEL и AlmaLinux. То есть это не «CERN уходит с Red Hat», а выбор дистрибутива под конкретный класс машин со старым железом.

Что это значит для своего парка

• Проверить, проходят ли ваши серверы уровень v2: /lib64/ld-linux-x86-64.so.2 --help | grep supported на любой glibc новее 2.33 покажет поддерживаемые уровни.
• Если в парке есть машины ниже v2, ветка RHEL 9 и новее для них закрыта; варианты: Debian, Ubuntu (тоже базовый x86-64) или остаться на RHEL 8-совместимых системах до конца их поддержки.
• Для промышленных систем ключевой вопрос не дистрибутив, а инструменты сборки пакетов и отката: под Debian их придётся собирать самим, как это делает CERN.
• Debian 13 вышел летом 2025 года и будет получать обновления безопасности до 2028 года, затем LTS; для сравнения, поддержка Debian 11 закончилась 31 августа.

Слайды и видео доклада CERN с MiniDebConf на момент публикации доступны через страницу конференции, отдельного пресс-релиза организация не выпускала. На сайте мы недавно разбирали другой пример влияния сборочных флагов на скорость: Rust Coreutils 0.11 и разницу производительности бинарников в Alpine из-за libc.

Источник: Phoronix: CERN Transitioning Industrial Computers To Debian

Изображение на обложке: Debian Project, логотип Debian Open Use

Если вы держите кластер с десятками тысяч подов или крупными объектами и видели пики памяти на kube-apiserver или etcd именно во время чтения коллекций после рестарта, это обновление адресовано вам. Тем, у кого кластер маленький, а etcd остался на 3.6, ничего не изменится: API server сам поймёт, что стриминг недоступен, и продолжит работать по-старому.

• EtcdRangeStream в v1.37 имеет статус beta и включён по умолчанию; для работы нужен etcd 3.7 или новее.
• Раньше страница ограничивалась числом ключей, поэтому страница крупных объектов могла весить сколько угодно; теперь чанки ограничены по байтам.
• Стриминг используется при инициализации watch cache и при list-запросах, которые уходят в etcd напрямую.
• Проверка: метрика etcd_request_duration_seconds_count с operation="listStream" больше нуля.
• Отключение: флаг --feature-gates=EtcdRangeStream=false на kube-apiserver.

Откуда брались пики памяти

Большую часть list- и watch-запросов API server обслуживает из своего кеша в памяти, watch cache. Чтобы этот кеш наполнить, при старте и при каждой реинициализации нужно вычитать полное состояние ресурса из etcd. Для ресурсов с большим числом объектов или с крупными объектами, вроде подов, такое чтение дорогое.

Пагинация там уже была: API server запрашивал у etcd фиксированное число ключей за раз. Проблема в том, что страница, ограниченная числом ключей, ничего не знает о размере объектов. Страница из крупных объектов остаётся очень большой, расход памяти трудно предсказать, а неудачное сочетание размера объектов и параллельных чтений заканчивается OOM. Хуже того, обычный вызов Range в etcd собирает страницу целиком до отправки, а API server держит её в памяти, пока декодирует, так что один и тот же payload одновременно лежит с обеих сторон. Основная нагрузка ложится на etcd, и именно там стриминг помогает сильнее всего.

Что делает RangeStream

В etcd 3.7 появился потоковый вариант того же чтения, RPC RangeStream. Он принимает тот же RangeRequest, что и Range, и возвращает тот же набор результатов, но не собирает ответ целиком, а режет его на чанки и стримит. Размер чанка подстраивается под возвращаемые значения, поэтому коллекция крупных объектов ограничена байтами, а не числом ключей, и память освобождается по ходу потока.

Когда функция включена, API server использует RangeStream везде, где читает из etcd целую коллекцию: при инициализации watch cache и в fallback-путях, когда list-запрос нельзя обслужить из кеша и приходится идти в etcd напрямую. Каждый чанк декодируется по прибытии и освобождается до запроса следующего, так что ни одна из сторон не держит коллекцию целиком.

Требования и совместимость

• Kubernetes v1.37 или новее.
• etcd v3.7 или новее.

RangeStream используется, когда на kube-apiserver включён feature gate EtcdRangeStream (в v1.37 он beta и включён по умолчанию) и etcd не старше 3.7. Поддержку на стороне etcd API server определяет при старте и дополнительно откатывается в рантайме, если вызов вернул Unimplemented. Поэтому API server 1.37 в паре со старым etcd сам продолжит ходить по пагинированному Range, ничего настраивать не нужно. Kubernetes 1.37 вышел 26 августа; etcd 3.7 анонсирован в июле, и RangeStream добавлен туда заранее под эту интеграцию.

Выключить функцию можно флагом:

Как убедиться, что стриминг работает

API server записывает потоковые чтения под отдельной меткой операции в своих etcd-метриках. Ненулевое значение означает, что RangeStream используется:

Если счётчик остаётся нулевым, API server по-прежнему ходит по пагинированному Range, и самая вероятная причина в том, что etcd старше 3.7. На практике это значит, что обновление control plane до 1.37 без обновления etcd эффекта не даст; проверять стоит обе версии.

Кому это нужно, а кому нет

По нашей оценке, выигрыш заметят кластеры, где list-запросы большие: много подов, крупные CRD, частые реинициализации watch cache после рестартов API server или сбоев. В небольших кластерах путь чтения при etcd 3.7 тоже сменится, но эффект, по нашей оценке, будет мал: там пиковый расход и так укладывался в лимиты. Цифр экономии памяти в анонсе нет, так что оценивать эффект придётся по собственным графикам потребления etcd и kube-apiserver до и после включения. Управляемые сервисы Kubernetes у российских облачных провайдеров обновляют версии control plane и etcd по своему графику, поэтому сначала стоит свериться с их release notes.

Подробности дизайна вынесены в KEP-5966, вопросы принимают в канале #sig-etcd в Slack Kubernetes.

Источники: Блог Kubernetes: etcd RangeStream Cuts Memory Use on Large List Reads, KEP-5966: etcd RangeStream, Анонс etcd v3.7

Изображение на обложке: Kubernetes

На практике это netcat для интернета: на одной машине запускаете tailcat в режиме ожидания и получаете одноразовый адрес-токен, на другой вызываете tailcat с этим адресом, и между ними появляется шифрованный двунаправленный канал. Сверху можно пустить SSH, передачу файлов или проброс порта. Для разового доступа к машине за NAT это заменяет и промежуточный сервер, и регистрацию в чужом сервисе.

• tailcat — CLI и Go-пакет github.com/tailscale/tailcat под лицензией BSD-3-Clause.
• Использует WireGuard, NAT traversal и DERP-релеи Tailscale, но не control plane: аккаунты, вход и tailnet не нужны; IP-адреса внутри туннеля есть, но пользователю их знать не требуется.
• Адрес машины — её публичный ключ с информацией о DERP-сервере для первого контакта, закодированный в строку с префиксом tc.
• Сценарии: SSH на машину за NAT, передача файлов, временный доступ; есть экспериментальная браузерная демонстрация на WebAssembly.
• Прототип под названием derpcat написан в сентябре 2023 года; обещаний стабильности API и CLI у проекта нет.

Как соединение работает без сервера-посредника

В обычном Tailscale центральный сервер (control plane) раздаёт машинам ключи друг друга и координаты, по которым их искать. В tailcat этого посредника нет: всё, что нужно для соединения, упаковано в сам адрес. По описанию в блоге, это публичный ключ WireGuard плюс сведения о том, через какой DERP-релей к машине можно достучаться, если прямой путь через NAT не найдётся; строка начинается с tc и кодирует эти данные в base64. Получатель адреса знает и кому доверять, и где искать.

No accounts, login flow, tailnets, or IP addresses.

Дальше работает тот же механизм, что и в Tailscale: машины пытаются пробить NAT и соединиться напрямую, а если не выходит, трафик идёт через DERP-релей, зашифрованный концами так, что релей содержимого не видит. Релеи Tailscale публичные, и их можно заменить своим. Ни root, ни TUN-интерфейс, ни права администратора не нужны: tailcat работает в пространстве пользователя как обычная программа.

Чем это отличается от ngrok, SSH-туннелей и самого Tailscale

От ngrok и подобных сервисов tailcat отличается тем, что не выставляет ничего в публичный интернет: соединение получит только тот, у кого есть адрес, а адрес — это ключ. От SSH-прыжков через промежуточный сервер — тем, что промежуточный сервер не нужен вообще: DERP лишь помогает найти друг друга и при необходимости ретранслирует уже зашифрованные байты. От Tailscale — отсутствием всей управляющей части: нет списка устройств, ACL, MagicDNS, нет и постоянной сети, каждое соединение живёт само по себе.

Отсюда и границы применимости. tailcat хорош для разового доступа: подключиться к ноутбуку коллеги, забрать большой файл с домашней машины из офиса, дать подрядчику временный вход на стенд. Для постоянной сети между десятками серверов с правами доступа он не замена Tailscale или WireGuard-конфигу, и авторы этого не обещают: README прямо предупреждает, что инструмент бесплатный, но стабильность API и CLI не гарантируется.

Как попробовать

• Установка при наличии Go: go install github.com/tailscale/tailcat/cmd/tailcat@latest; готовые бинарники смотрите в релизах репозитория.
• На принимающей стороне запустите tailcat в режиме прослушивания и скопируйте выданный адрес; на второй машине передайте этот адрес как аргумент.
• Поверх канала поднимайте SSH или пробрасывайте порт; для передачи файлов подойдёт обычное перенаправление stdin и stdout, как с netcat.
• Для закрытого контура поднимите собственный DERP-сервер: код релея открыт в репозитории Tailscale.
• Браузерная демонстрация на WebAssembly лежит на GitHub Pages проекта и показывает, что канал можно открыть даже из вкладки.
• Публичные DERP-релеи даны без SLA, с ограничением частоты запросов и лишь в нескольких регионах; для рабочих сценариев поднимите свой релей.

Контекст

Первый прототип под именем derpcat Фицпатрик написал в сентябре 2023 года, публично проект показали после конференции TailscaleUp в августе 2026-го. Мотив компании понятен: чем больше людей знакомы с её сетевым стеком, тем проще им потом прийти за полноценным продуктом. Для разработчика это честная сделка: рабочий инструмент под BSD-лицензией без обязательств, но и без гарантий, что завтра его интерфейс не изменится.

Источники: tailcat: Tailscale without Tailscale (блог Tailscale), Репозиторий tailscale/tailcat

Изображение на обложке: Tailscale

Если у вас на Workers Free крутится пет-проект, бот или небольшой сервис с базой в D1, это касается напрямую: в один день трафик чуть выше обычного, и после обеда по Москве запросы к базе начинают завершаться ошибкой до трёх часов ночи, а приложение без обработки этой ошибки показывает её пользователям. Cloudflare обещает письмо при достижении лимита, но письмо не починит прод.

• Лимиты Workers Free для D1: 5 млн прочитанных строк и 100 тысяч записанных строк в сутки, 5 ГБ хранилища на аккаунт.
• С 1 сентября при превышении запросы к D1 завершаются ошибкой до сброса счётчика в 00:00 UTC (03:00 мск); сохранённые данные не затрагиваются.
• На Workers Paid за $5 в месяц включено 25 млрд чтений и 50 млн записей в месяц, дальше $0,001 за миллион прочитанных строк и $1 за миллион записанных; 5 ГБ хранилища включено, дальше $0,75 за ГБ в месяц.
• Строки считаются по факту прочитанного движком, а не по числу строк в ответе: SELECT без индекса по таблице в 100 тысяч строк — это 100 тысяч чтений.
• Cloudflare советует посмотреть статистику запросов за прошлые дни и добавить индексы: полное сканирование таблицы съедает лимит чтений быстрее всего.

Что изменилось на самом деле

Сами лимиты не новые, они давно указаны на странице тарифов. Изменился режим их применения: до 1 сентября Cloudflare не блокировала запросы при превышении, теперь блокирует. Ограничение действует и на вызовы из кода Worker через биндинг, и на REST API, которым пользуются внешние интеграции и админки. В тексте ошибки предлагается два выхода: перейти на платный план или подождать до завтра.

Upgrade to a paid plan or wait until tomorrow.

Компания подчёркивает, что хранилище остаётся нетронутым: речь только о временной недоступности запросов, а не о потере или заморозке данных. Счётчик сбрасывается в полночь по UTC, в три часа ночи по Москве. Уведомление по электронной почте приходит при достижении дневного лимита, и Cloudflare отдельно рекомендует посмотреть активность запросов за прошлые дни, чтобы понять, насколько проект близок к границе.

Почему один запрос может стоить 100 тысяч чтений

Главная ловушка D1 — учёт по прочитанным строкам, а не по запросам. Запрос SELECT * FROM events WHERE user_id = ? без индекса по user_id заставляет движок пройти всю таблицу, и каждая пройденная строка засчитывается в лимит, даже если в ответе одна запись. Поэтому небольшой сервис с парой тысяч посетителей в день может упереться в 5 млн чтений на одном неудачном запросе в цикле. Cloudflare в changelog прямо называет виновника: запросы с полным сканированием таблиц, и советует индексы как первое средство.

Сколько строк реально прочитал запрос, D1 возвращает в объекте meta ответа: поля rows_read и rows_written. Именно по ним, а не по числу вызовов, стоит оценивать, насколько вы близки к лимиту. Суммарную картину за день показывают GraphQL Analytics API и дашборд Cloudflare; страница тарифов перечисляет все три способа отслеживать расход.

С записями та же логика: учитываются записанные строки, а не вызовы. Объединение вставок в один батч сокращает число запросов и задержку, но не уменьшает rows_written, так что от лимита в 100 тысяч записей в сутки оно не спасает. Единственный способ уложиться — писать меньше строк: агрегировать события, не хранить в D1 логи на каждый запрос, выносить телеметрию в Analytics Engine или KV.

Сколько стоит платный план

Workers Paid стоит $5 в месяц и снимает дневные лимиты. По странице тарифов в него включены 25 млрд прочитанных строк и 50 млн записанных строк в месяц, сверх этого чтение стоит $0,001 за миллион строк, запись — $1 за миллион строк. Хранилище: 5 ГБ включено, дальше $0,75 за гигабайт в месяц. Бесплатный план даёт те же 5 ГБ, но при их превышении не тарифицирует, а блокирует новые записи и изменение схемы; но 5 млн чтений и 100 тысяч записей в сутки, то есть примерно 150 млн чтений и 3 млн записей в месяц.

Что сделать до вечера

• Откройте статистику D1 в дашборде за последние две недели: если пиковые дни выше 3–4 млн чтений, по нашей оценке вы в зоне риска; порог редакционный, Cloudflare его не задаёт.
• Пройдитесь EXPLAIN QUERY PLAN по самым частым запросам и добавьте индексы там, где видите SCAN.
• Кэшируйте горячие ответы в KV или Cache API: одно чтение из кэша вместо тысячи строк из базы.
• Записи ограничены сильнее чтений: считаются записанные строки, а не вызовы, батчи не помогут; пишите меньше строк, агрегируйте события и не кладите логи в D1 на каждый запрос.
• Обрабатывайте ошибку D1 в коде: показывайте пользователю понятное сообщение и отдавайте кэшированные данные, а не пятисотую страницу.

Контекст

D1 вышла из беты в 2024 году как «SQLite на краю сети» для Workers: база живёт рядом с кодом и тарифицируется по строкам, а глобальная репликация чтения доступна как отдельная бета-функция, а не по процессорному времени. Учёт по строкам — осознанный выбор Cloudflare, и до сих пор он был безболезненным для бесплатных проектов. Для D1 «бесплатно» теперь читается буквально: в пределах квоты сервис работает, за пределами останавливается, а не копит счёт. Распространится ли такой режим на другие бесплатные лимиты Workers, changelog не говорит.

Источники: D1 free tier limit enforcement (Cloudflare Changelog), D1 pricing

Изображение на обложке: Cloudflare

Практическая проблема в том, что Bullseye — не экзотика. Это образы VPS у хостеров, базовые слои Docker-образов, которые никто не пересобирал два года, и «тот сервер, который просто работает». Задача на сентябрь простая: найти их все и решить, куда переезжать.

• LTS Debian 11 длился с 15 августа 2024 по 31 августа 2026 года для amd64, i386, arm64 и armhf; всего Bullseye прожил пять лет.
• С сентября Debian не выпускает для него обновления безопасности; часть пакетов могут поддерживать сторонние компании через платный Extended LTS.
• Debian 12 Bookworm получает LTS до 30 июня 2028 года (amd64, i386, arm64, armhf, ppc64el); Debian 13 Trixie вышел 9 августа 2025 года.
• Проверка одной командой: cat /etc/debian_version, ищите 11.x; в образах — grep по Dockerfile на bullseye.
• Путь обновления: 11, затем 12, затем 13, по одному мажорному шагу, с бэкапом перед каждым.

Чем LTS отличается от обычной поддержки

Стабильный выпуск Debian живёт три года под присмотром команд Security и Release. После этого дистрибутив передают в LTS — проект, который ведут волонтёры и заинтересованные компании, а не основные команды Debian; так описывает его вики проекта. LTS добавляет ещё два года обновлений безопасности, но уже не для всех архитектур и не для всех пакетов. Для Bullseye этот срок закончился.

Starting in September, Debian will not provide further security updates for Debian 11.

После LTS есть ещё одна ступень — Extended LTS. Это не часть Debian: несколько компаний за деньги продолжают чинить ограниченный набор пакетов для клиентов, которым переезд обходится дороже. Полного покрытия там нет, и рассчитывать на него как на бесплатную отсрочку не стоит.

Где искать Bullseye у себя

Три типичных места. Первое: старые VPS и физические серверы, поставленные в 2021–2023 годах. Второе: Docker-образы с базой debian:bullseye, python:3.x-bullseye или node:xx-bullseye, которые собраны один раз и с тех пор только тегаются заново. Третье: встроенные системы и Raspberry Pi, где Raspberry Pi OS на базе Bullseye стоял по умолчанию до конца 2023 года.

Куда обновляться

Прямого пути с 11 на 13 нет: Debian поддерживает обновление только на следующий мажорный выпуск. Значит, сначала bullseye на bookworm, потом при желании bookworm на trixie. Debian 12 Bookworm — безопасный промежуточный вариант: у него LTS до 30 июня 2028 года, а из архитектур в LTS заявлены amd64, i386, arm64, armhf и ppc64el. Для второго шага есть отдельные release notes Trixie. Для Docker-образов проще: сменить тег базового образа на bookworm или trixie и пересобрать.

• Сделайте снимок или бэкап, затем apt update && apt full-upgrade в текущей версии, чтобы уйти с чистой точки.
• Сторонние репозитории (Docker, PostgreSQL, nginx) перед обновлением отключите, как советуют release notes, а после перехода подключите их версии для bookworm.
• Замените bullseye на bookworm в /etc/apt/sources.list и файлах в sources.list.d; для Bookworm секция non-free-firmware добавляется отдельно.
• apt update && apt upgrade --without-new-pkgs, затем apt full-upgrade, перезагрузка, проверка сервисов.
• В CI запретите тег bullseye в базовых образах линтером Dockerfile, чтобы он не вернулся через полгода.

Любое зеркало Debian продолжит раздавать пакеты Bullseye, но новых обновлений безопасности от проекта в них не появится, так что «репозиторий работает» не означает «сервер защищён». При заказе нового VPS выбирайте образы Debian 12 или 13, если хостер ещё предлагает 11.

Что дальше

Следующий такой рубеж — 30 июня 2028 года, когда закончится LTS у Bookworm, то есть меньше чем через два года. Если вы переезжаете сейчас, разумно сразу планировать повтор процедуры к этой дате и держать обновление ОС в регулярном графике, а не как аварийную операцию раз в пять лет.

Источники: Debian 11 Long Term Support reaching end-of-life (Debian News), Debian LTS Wiki, Release notes Debian 12: upgrading

Изображение на обложке: Debian Project

Подтверждённый вектор атаки не требовал взлома серверов Softaculous: она прошла на уровне маршрутизации интернета и сработала потому, что клиент обновлений Virtualizor не проверял криптографическую подпись пакета, ему хватало валидного TLS. Если у вас стоит Virtualizor, а его используют многие хостинги, включая российские, компания просит проверить сервер по опубликованному индикатору, даже если обновление вручную вы не запускали.

• Окно инцидента около 33 часов: с 28 августа 20:57 UTC до 30 августа 06:10 UTC; активный перехват шёл двумя волнами общей длиной около 22 часов с перерывами, маршрут постоянно менялся.
• Поддельный маршрут /24 был специфичнее легитимного /16 Hetzner; все 368 peers RIPE RIS видели его хотя бы в один момент за окно инцидента; медианное число перенаправленных peers во время активной волны — 266 (около 72%).
• Через перехваченный трафик атакующий прошёл проверку Let's Encrypt и получил технически валидный сертификат для доменов Virtualizor.
• Вредоносное обновление подтверждено для Virtualizor; для других продуктов Softaculous таких пакетов не подтверждено. Индикатор компрометации: служба java-jre-update.service; выпущена версия 3.2.9.9 с инструментом устранения последствий и cleaning script, подпись пакетов обещана.
• Клиент обновлений не проверял подпись пакета; компания не может составить полный список затронутых серверов.

Как работает угон маршрута

BGP — протокол, по которому сети-операторы сообщают друг другу, через кого достижимы те или иные диапазоны IP-адресов. Доверие в нём во многом строится на честном слове: если кто-то объявляет, что диапазон живёт у него, соседи обычно верят. А если объявленный диапазон меньше (специфичнее) настоящего, маршрутизаторы предпочитают именно его. Так и произошло: Hetzner (AS24940) легитимно объявляет 162.55.0.0/16, атакующий объявил внутри него 162.55.80.0/24, и более точный маршрут победил.

В объявлении фигурировали AS62390 (NexonHost) и AS6204 (Zet.net), а в конце пути был оставлен Hetzner как видимый источник, чтобы подмена выглядела правдоподобно. По публичным данным RIPE RIS все 368 peers видели маршрут хотя бы в один момент за окно инцидента, а медианное число перенаправленных peers во время активной волны составляло 266. Перехват шёл двумя волнами общей продолжительностью около 22 часов с паузой примерно в 11 часов между ними, и для отдельных сетей он был прерывистым: маршрут то появлялся, то исчезал.

Почему сертификат оказался настоящим

Let's Encrypt подтверждает владение доменом, обращаясь к нему по HTTP. Если в этот момент трафик к домену идёт на сервер атакующего, проверка проходит, и сертификат выдаётся ему. Именно это и случилось: компания пишет, что злоумышленник получил «технически действительный TLS-сертификат для наших доменов» (перевод редакции). Браузеры и клиенты обновлений видели зелёный замок и доверяли ответам подменённого сервера.

The attacker obtained a technically valid TLS certificate for our domains.

Дальше сработало самое слабое звено: клиент обновлений Virtualizor доверял серверу по TLS и не проверял подпись самого пакета. Правильная схема, при которой пакет подписан офлайн-ключом разработчика и проверяется на сервере клиента, не спасла бы от перехвата трафика, но сделала бы подмену пакета невозможной. Компания обещала внедрить подпись для всех пакетов; срок и реализацию она не назвала.

Кого это задело

По словам компании, вредоносный пакет получила «горстка серверов», а не вся база пользователей Virtualizor. При этом Softaculous прямо признаёт: «Мы не можем составить окончательный список затронутых серверов» (перевод редакции), потому что подмена происходила на сетевом уровне и следов на стороне компании не оставила. Для Softaculous, Webuzo и других продуктов вредоносных пакетов не подтверждено, но те же адреса использовались и для их обновлений. Индикатор компрометации, который называет компания, — служба java-jre-update.service в системе. Softaculous выпустила Virtualizor 3.2.9.9 с инструментом устранения последствий и отдельный cleaning script, но просит при обнаружении индикатора не удалять службу самостоятельно, а связаться с поддержкой.

Что делать администратору

• Если у вас Virtualizor: обновитесь до 3.2.9.9, поищите службу java-jre-update.service и при её наличии свяжитесь с поддержкой Softaculous, как просит компания; проверять стоит, даже если обновления вы не запускали, автообновление могло сработать само.
• Сверьте по логам, не обращался ли сервер к 162.55.80.0/24 между 28 августа 20:57 UTC и 30 августа 06:10 UTC.
• Смените учётные данные панели, API-ключи и пароли, которые могли пройти через клиентскую зону или биллинг в этот период.
• Для собственных систем обновлений: подписывайте пакеты отдельным ключом и проверяйте подпись на клиенте; TLS защищает канал, но не содержимое.
• Если управляете своей сетью: включите RPKI Origin Validation и задайте свои ROA с точной длиной префикса. Оговорка: атакующий оставил Hetzner видимым origin, и без строгого maxLength в ROA такой маршрут ROV не отбросит.

Что дальше

Компания продолжает расследование; индикатор компрометации, версия 3.2.9.9 и cleaning script уже опубликованы. Открытых вопросов два: почему сети-транзиты пропустили объявление чужого /24 без проверки и когда и как будет внедрена обещанная подпись пакетов. Пока её нет, любой повторный угон маршрута снова превратится в атаку на цепочку поставок.

Источник: Security incident: BGP hijacking (Virtualizor)

Изображение на обложке: скриншот bgp.tools

Как работают Kubernetes Deployments

Начать можно с руководства по Kubernetes Deployments DevOps-инженера Пуру Туладхара. Автор объясняет, как Deployment управляет ReplicaSet и подами, поддерживает нужное количество реплик и выполняет обновления приложения.

В Kubernetes Deployment встроены две стратегии обновления: RollingUpdate (постепенное обновление подов) и Recreate (полная остановка старой версии перед запуском новой). Canary- (канареечная — постепенное открытие новой версии части пользователей) и Blue-Green-выкладку (сине-зелёная — переключение трафика между двумя параллельными версиями) собирают с помощью нескольких Deployment и дополнительного управления трафиком. Для сложной маршрутизации могут потребоваться Ingress-контроллер, API-шлюз или service mesh. Среди практических советов: держать K8s-конфигурации в системе контроля версий и подключать их к CI/CD-конвейеру, для сбора метрик можно использовать Prometheus, а для их визуализации — Grafana. Набор доступных показателей зависит от источников данных и настроенных экспортёров.

Более компактный формат у подборки Kubernetes 101 под лицензией Apache 2.0. У репозитория около полутора тысяч звёзд на GitHub, а материал разбит на четыре блока: базовые советы по Dockerfile, инфраструктура (безопасность, сети, нагрузки), ключевые концепции Kubernetes с той же канареечной и сине-зелёной выкладкой и короткий финальный раздел про деплой и ревью.

Развернуть кластер без лишних компонентов

Пошаговая инструкция по запуску K8s-кластера ориентирована на минимальный набор компонентов на виртуальных машинах с Debian 11. Прежде чем переходить к развёртыванию самого кластера, автор отключает swap, загружает модули ядра overlay и br_netfilter, а затем устанавливает kubelet, kubeadm, kubectl и CRI-O. В современных версиях Kubernetes swap можно оставить включённым при соответствующей настройке kubelet, хотя по умолчанию он по-прежнему не запускается на Linux-узле с активным swap.

После этого автор выбирает CIDR для сети подов, подключает первый рабочий узел и настраивает доступ к API кластера через kubectl. В отдельном репозитории лежат конфигурации Terraform для развёртки виртуальных машин под лицензией GPL 3.0, которые можно взять как основу и адаптировать под свою инфраструктуру.

Уточнение: материал опубликован в мае 2023 года, поэтому его стоит использовать для знакомства с устройством кластера, а команды перед запуском проверять с актуальной документацией Kubernetes и CRI-O.

Официальные рекомендации

Компактный гайд от GitLab показывает связку GitLab Agent, CI/CD и FluxCD. В примере конвейер упаковывает Kubernetes-манифесты в OCI-артефакт и помещает его в GitLab Container Registry, после чего FluxCD получает и применяет артефакт в кластере. Одной из практик оттуда является использование OCI-репозитория как кеширующего слоя между Git и FluxCD: конвейер GitLab упаковывает манифесты в OCI-артефакт и отправляет его в реестр. FluxCD следит за указанным OCIRepository, получает новую версию артефакта и применяет содержащиеся в нём манифесты.

Некоторые разделы доступны только в платных редакциях GitLab. Остальная часть руководства показывает общую схему GitOps: конвейер упаковывает манифесты в OCI-артефакт, а Flux получает его из OCI-репозитория и применяет в кластере. Источником истины при этом остаётся Git, а OCI-репозиторий работает лишь промежуточным слоем доставки.

Свой блок практик есть и у самой команды Kubernetes. В нём собраны и базовые пункты вроде «указывайте стабильные версии API», и более прикладные советы по сервисам, меткам и работе с kubectl. Разработчики рекомендуют избегать подов без привязки к ReplicaSet или Deployment и не задавать hostPort напрямую.

Как устроен Kubernetes у нас в Linx Cloud

Кластеры работают в режиме Multi Master: etcd работает в кластерном режиме на выделенных SSD-дисках, поэтому отказ одного мастера не останавливает работу остальных. Хранение данных построено на нескольких storage-классах: SSD Ceph, HDD Ceph, геораспределённый Ceph между дата-центрами, а также блочные диски по iSCSI и файловое хранилище с NFS-протоколом для legacy-приложений. Кластер масштабируется автоматически через Cluster Autoscaler: узлы добавляются и удаляются по нагрузке. Создать и удалить кластер можно через панель управления, API или собственный Terraform-провайдер.

Более свежая часть платформы — Kubernetes as a Service на базе Deckhouse Kubernetes Platform: встроенный мониторинг, управление сертификатами и безопасность из коробки, без ручной настройки инфраструктуры. Конкретный состав компонентов и версии для обеих линеек стоит уточнять у технической команды Linx Cloud перед внедрением. Документация по Kubernetes у крупного облачного провайдера обновляется часто, и часть деталей может не совпадать с формальной датой последней правки страницы.

Open Source-инструменты для Kubernetes

Glasskube был менеджером K8s-пакетов, вдохновлённым Homebrew, npm и apt: каждое обновление проходило проверку на наборе тестов, а в каталоге были доступны Ingress-NGINX, Kube Prometheus Stack, cert-manager и другие распространённые компоненты Kubernetes. В 2024 году проект вошёл в CNCF Landscape. Но 17 июня 2026 года репозиторий заархивирован владельцем и переведён в режим read-only — для нового проекта Glasskube уже не стоит рассматривать как активное решение, хотя документация (архитектура, установка на разные ОС, шаблон для ArgoCD) остаётся доступной, если инструмент уже внедрён.

K0rdent запустила Mirantis в начале 2025 года как инструментарий для проектирования распределённых сред управления контейнерами (DCME). 0rdent разворачивают как управляющую платформу. Через Cluster API он создаёт и обновляет дочерние кластеры в облачной, локальной или гибридной инфраструктуре. Набор доступных провайдеров и дополнительных сервисов зависит от версии и конфигурации. В мае 2026 года кластеры, развёрнутые и управляемые через k0rdent, прошли проверку CNCF Kubernetes v1.35 на соответствие требованиям conformance и получили статус Certified Kubernetes; сам k0rdent при этом включён в CNCF Landscape как management-платформа для сертифицированных дистрибутивов. В документации есть быстрый старт, настройка управляющего кластера и примеры конфигураций.

DeployKF разработчики описывают как платформу, которая берёт лучшее из Kubeflow, Airflow и MLflow, чтобы дать любому пользователю Kubernetes возможность строить ML-платформу без экспертизы в MLOps. На практике готова пока только экосистема Kubeflow: интеграцию с Airflow и MLflow сами разработчики помечают как «coming soon» в своей документации. Сейчас работают централизованная система конфигураций и интеграция с Istio, cert-manager, Kyverno, S3 и MySQL, хотя раздел про Kyverno в документации тоже пока не завершён.

Managed Kubernetes как сервис от Linx Cloud

Управлять кластером самостоятельно необязательно: у нас есть платформа для развёртки, масштабирования и мониторинга контейнерных приложений на основе Deckhouse Kubernetes Platform. По сравнению с «ванильной» конфигурацией она добавляет метрики и дашборды для мониторинга, готовые компоненты аутентификации и авторизации, преднастроенные Flannel или Cilium для сети.

Подробный разбор возможностей и интерфейса сервиса есть в статье на Хабре, со скриншотами или на сайте Linx Cloud. Сервис можно протестировать напрямую и задать нам вопросы по использованию.

Что показывает статистика

Компания Linx вместе с сообществом Global CIO в конце прошлого года опросила руководителей, которые отвечают за развитие IT-инфраструктуры, из компаний в 27 городах России и СНГ. В выборке 15 отраслей, больше всего – производство, банки и торговля. Картина такая.

С потерей выручки из-за простоев сталкивались все опрошенные компании без исключения. 69% ловят перебои еженедельно, 14% – ежедневно. То есть речь не о случайных форс-мажорах, а о регулярном фоне, который может случиться в любой момент. При этом устойчивой к сбоям свою инфраструктуру считает только каждая пятая компания.

Формальный план аварийного восстановления есть у многих, но два респондента из пяти признались, что не проводят реальных тестов вообще, и только один из пяти сочетает документированную DR-стратегию с регулярными проверками. Идеальная частота тестирования – раз в квартал, так делают 8% опрошенных. Половина ограничивается тестом раз в полгода или в год.

Дальше самое показательное. Когда авторы исследования сопоставили ответы, выяснилось: у половины компаний, которые не тестируют восстановление, оно и не сработало, когда понадобилось. Всего по выборке 19% не уложились в заданные временные рамки, ещё 15% потеряли данные, некоторые так и не восстановились полностью.

Восстанавливаться приходится чаще: только 15% компаний ни разу не поднимались из бэкапа. Основные причины банальные – ошибки сотрудников и сбои оборудования. Атаки шифровальщиков только на третьем месте, но у них своя специфика: злоумышленники уже поняли, что бить надо по резервным копиям, поэтому большинство атак направлено именно на их шифрование или уничтожение. Защищённые от изменений хранилища при этом используют 32% компаний.

Чем дольше простой, тем хуже прогноз. 93% компаний, которые теряют данные больше чем на 10 дней, в течение года подают на банкротство.

Бэкап и DR решают разные задачи

Термины часто смешивают, поэтому договоримся о понятиях.

Бэкап отвечает на вопрос «есть ли у нас копия данных» – это процесс создания копий продуктивных данных на отдельном носителе: если рабочие данные повреждены или уничтожены, из копии можно восстановиться. Копии обычно держат на локальной площадке для оперативного восстановления и дополнительно выносят на удалённую, чтобы пережить сбой площадки целиком.

DR, он же disaster recovery, отвечает «как быстро поднимутся наши системы, если площадка выйдет из строя» – данные постоянно реплицируются на резервную площадку, и там по сути живёт копия критически важных информационных систем. Если основная площадка надолго отключилась или утрачена совсем, нагрузка переезжает на резервную.

Оба процесса оперируют двумя метриками:

• RPO – сколько данных бизнес готов потерять без критичных последствий.
• RTO – за какое время системы должны вернуться в нормальный режим.

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

DR окупается, когда RTO измеряется десятками минут, а терять данные больше чем за одну-две минуты нельзя. Бэкапов достаточно, когда защищать нужно сами данные, а не работающие системы: вернуться на несколько точек назад, пережить шифровальщика, восстановить всё в консистентном состоянии. На практике подходы комбинируют: mission critical системы закрывают через DR, остальное восстанавливают из бэкапов помедленнее.

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

Пять мест, где ломается восстановление

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

1. Переживут ли копии тот же инцидент. Мы уже касались этого на уровне одного сервера, но правило масштабируется. Если все копии лежат в одном ДЦ, в одном облаке или под одним контуром администрирования, полноценной устойчивости нет. Важно оценить независимость резервной площадки и убедиться, что там будут связь и ресурсы для восстановления.
2. Сверены ли RTO и RPO с реальностью. Часто эти показатели живут в документах как красивые цели, которые никто не измерял на практике. Если в DRP записан час, а фактическое восстановление занимает восемь, об этом надо узнать до аварии. Полезно ещё разделять системы по классам критичности, потому что восстанавливать всё одинаково быстро затратно и не всегда обоснованно.
3. Описан ли порядок восстановления. Поднять виртуальные машины и поднять работающий сервис не одно и то же. Сервису нужна база данных, рабочая сеть, доступы, внешние интеграции. Если в момент аварии команда выясняет порядок запуска в телеграм-чате, DR-план фактически не работает. Для этого существует runbook: документ с последовательностью действий, ролями и критериями, по которым конкретный человек подтверждает, что сервис восстановлен.
4. Продуман ли failover. Заранее нужны ответы на вопросы: кто принимает решение о переключении, хватит ли ресурсов на резервной площадке, чтобы принять нагрузку, готова ли сетевая часть с балансировщиками. И отдельный пункт, про который вспоминают не все, – план возврата.
5. Регулярный dry run. DR-план устаревает по умолчанию: появилась новая система, поменялись маршруты, прошла миграция, сменился провайдер, выкатили релиз с новыми зависимостями. Тестовый прогон нужен, чтобы находить расхождения между документом и реальной инфраструктурой. Причём сам по себе прогон ничего не решает: по его итогам в план вносят изменения и сразу назначают дату следующей проверки.

Почему DR не спасает от шифровальщика

У DR есть слабое место, о котором стоит помнить отдельно. Репликация не разбирает, что она переносит: она добросовестно доставляет на резервную площадку и здоровые данные, и зашифрованные.

Сценарий выглядит так. Шифровальщик отработал на основной площадке, данные повреждены. Команда решает, что площадка потеряна, и запускает аварийное восстановление. Виртуальные машины на резервной стороне поднимаются в нужном порядке, всё по плану. А потом выясняется, что данные там те же самые: реплика успела уехать уже после шифрования. Формально DR сработал, бизнесу это не помогло.

Точки восстановления у DR-решений есть, но их заметно меньше, чем у бэкапов. Откатиться далеко в прошлое и получить консистентное состояние исторических данных – задача именно резервного копирования. Поэтому от шифровальщиков DR защищает так себе: может повезти с точкой, а может и нет. Всё упирается в то, от каких рисков вы страхуетесь.

Как строить хранение копий

Базовая схема известна давно и называется правилом 3-2-1: держать данные минимум в трёх экземплярах – продуктивные плюс две резервные копии. Носители должны быть двух разных типов, чтобы не словить на обеих копиях один и тот же баг прошивки или заводской брак. И хотя бы одна копия должна лежать на удалённой площадке, на случай если с основной что-то случится целиком.

У правила есть развитие: 3-2-1-1-0. Дополнительная единица означает, что минимум одна копия хранится в неизменяемом виде, а ноль – что восстановление регулярно тестируется. Второе спасает от бэкапа Шрёдингера: копия вроде есть, но из неё ни разу не пробовали восстановиться, поэтому неизвестно, есть ли там вообще пригодные данные. Тестировать можно руками, встроенными средствами системы резервного копирования или отдельными скриптами.

Неизменяемое хранилище устроено одним из двух способов.

1. Первый – отчуждаемые носители: записали на ленту или внешний диск, вытащили, убрали в несгораемый шкаф. Защита получается надёжная, но скорость записи и восстановления низкая, а трудозатраты мешают главному – регулярному тестированию.
2. Второй способ – ограничение на уровне прав доступа: данные можно записать один раз и читать сколько угодно, а перезаписать нельзя. Так работает, например, функция Object Lock в S3-совместимых объектных хранилищах: она защищает объекты от случайного и преднамеренного изменения или удаления. Важно понимать границы: объектное хранилище – не система резервного копирования, а удалённый репозиторий, куда система складывает копии.

Отдельный выбор – как система резервного копирования будет добираться до данных. Агентская схема ставит небольшую программу на каждый сервер и рабочую станцию: агент сидит рядом с данными и даёт гибко управлять копированием и восстановлением, но нагружает CPU и память машины, а парком агентов надо управлять. Безагентская схема работает на уровне гипервизора или отдельным сервером: разворачивается быстро, покрывает много сервисов разом, вся нагрузка остаётся на внешнем сервере. Для маленькой инсталляции обычно удобнее агенты, для большой – безагентский вариант.

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

Собрать такую схему можно на инфраструктуре Linx: у компании есть объектное хранилище с Object Lock, где данные можно защитить так, что их не изменит даже администратор облака, сервис резервного копирования с локальными и удалёнными репозиториями и услуга аварийного восстановления для инфраструктур на VMware. Если у вас Hyper-V, bare metal или другая платформа виртуализации, тот же сценарий закрывается связкой с платформой Hystex, которая переносит нагрузки между разными платформами. Подробности – на linx.ru.

Итого

Готовность к аварии проверяется не наличием бэкапа, а измеренным восстановлением. Отсюда план действий:

• Сначала аудит: посчитать, во сколько обходится час простоя и потеря данных, и разбить системы на классы критичности.
• Затем вместе с бизнесом зафиксировать целевые RPO и RTO для каждого класса, спроектировать под них архитектуру и провести тестовое восстановление.
• Полученные цифры сверить с целевыми: если в план заложен час, а по факту выходит восемь, либо меняйте архитектуру, либо честно пересматривайте цели вместе с бюджетом.
• Дальше цикл: обновили план, назначили дату следующего теста.

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

Непроверенный бэкап – не страховка, а гипотеза о страховке. Разница между ними выясняется в худший момент из возможных, и стоит она, если верить статистике, до 93% вероятности банкротства при затяжной потере данных. Тестовое восстановление обходится дешевле.

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

Как публичное облако стало вариантом по умолчанию

Одним из главных пионеров первой волны миграции стал Netflix. Компания начала перенос инфраструктуры в AWS после сбоя собственного дата-центра в 2008 году, а в январе 2016-го завершила семилетнюю миграцию и отключила последние системы стримингового сервиса, работавшие в её дата-центрах. Публичное облако позволило Netflix масштабировать инфраструктуру вместе с ростом аудитории и объёма данных.

В 2016 году McKinsey опросила руководителей более чем 50 крупных организаций из Европы и Северной Америки, чтобы сравнить экономику размещения приложений. Уже тогда они говорили, что финансовые ресурсы на частное и публичное облаком в целом одинаковые. Но компании всё равно продолжали миграцию, поскольку оценивали также скорость масштабирования и объём работы, который получалось снять с внутренних ИТ-команд.

К 2018 году публичное облако уже стало стандартной частью корпоративной инфраструктуры. Согласно RightScale State of the Cloud Report 2018, 52% крупных компаний тратили на него больше 1,2 млн долларов в год, а 71% крупных организаций собирались увеличить расходы как минимум на 20%.

На этом же этапе появилась проблема: компании научились быстро заказывать ресурсы, но хуже контролировали их использование. RightScale оценила долю неэффективных расходов в 35%, а 58% респондентов назвали оптимизацию облачных затрат главным приоритетом.

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

Что означает облачная репатриация

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

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

Такой подход требует выбирать среду отдельно для каждой нагрузки. На решение влияют её характеристики:

• насколько предсказуемо потребление вычислительных ресурсов;
• где должны храниться и обрабатываться данные;
• требуется ли специальная конфигурация оборудования;
• может ли система резко масштабироваться;
• способна ли внутренняя команда обслуживать инфраструктуру.

Разница между собственной инфраструктурой и частным облаком

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

Рынок движется именно в сторону сочетания таких моделей. Forrester в прогнозе на 2025 год ожидала роста интереса к частным облакам и расширения соответствующих решений у крупных провайдеров публичной инфраструктуры. В качестве технологической основы отдельно упоминали альтернативы VMware, включая платформы на базе открытого кода.

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

Когда публичное облако становится дорогим

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

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

Обычно экономику пересматривают, когда одновременно выполняются несколько условий:

• приложению нужен стабильный объём вычислительных ресурсов;
• объём хранилища можно спрогнозировать заранее;
• системе не требуется мгновенно добавлять сотни серверов;
• нагрузка работает достаточно долго, чтобы капитальные затраты окупились;
• у компании или провайдера есть команда для эксплуатации частной инфраструктуры.

Один из самых известных примеров – оптимизация 37Signals. Компания использовала публичное облако для своих продуктов, но потом решила перенести инфраструктуру в частную среду. Давид Хейнемейер Ханссон, сооснователь 37Signals, признавал главное преимущество облачных платформ: они позволяют поднять сотню серверов за несколько минут – для 37Signals это оказалось избыточным. Этот кейс нельзя переносить на любой бизнес. В публичном облаке есть смысл для компаний, которым нужно быстро получать вычислительные мощности и большие объёмы хранилища без больших затрат. Оно также подходит системам с плавающей и плохо предсказуемой нагрузкой.

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

Считать только цену серверов здесь бессмысленно. В частной среде компания оплачивает оборудование, размещение, резервирование, обновление и работу специалистов. В публичном облаке эти расходы включены в тариф, но к ним добавляется плата за ресурсы, сервисы и хранение данных.

Поэтому дорогим становится не само публичное облако. Дорогой становится архитектура, в которой постоянную нагрузку годами оплачивают как временную и гибкую.

Почему ИИ-нагрузки меняют выбор инфраструктуры

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

Поэтому при выборе инфраструктуры компании оценивают несколько параметров:

• какие вычислительные ресурсы нужны модели;
• где хранятся данные для обучения и инференса;
• насколько глубоко придётся настраивать среду;
• можно ли передавать промпты, ответы и логи внешнему сервису.

По прогнозу Gartner, к 2027 году больше половины моделей генеративного ИИ, которые используют компании, будут адаптированы под конкретную отрасль или бизнес-функцию. В 2024 году их доля составляла около 1%.

В Private Cloud Outlook 2025 55% опрошенных компаний выбрали частное облако для обучения, настройки моделей и инференса. Это не означает, что публичная инфраструктура перестала подходить для ИИ, просто большую часть данных, которые компании скармливают в ИИ нельзя свободно передавать во внешний контур. Из-за этого развивается и открытый набор инструментов для конфиденциального инференса. Например, OpenPCC позволяет работать с кастомными моделями в частном облаке, не раскрывая промпты, ответы и логи. Передача данных шифруется, а выполнение запросов проверяется через аппаратную аттестацию.

Итого: если ваша модель использует общедоступные данные, вам нужна мощность только время от времени – выбирайте публичное облако. Если инфраструктуру приходится настраивать под постоянный инференс и корпоративные данные – переходите на частную среду.

Почему компании выбирают частное облако провайдера

Переход в частное облако не требует строить собственный ЦОД. Компания может получить выделенную инфраструктуру у провайдера и передать ему обслуживание оборудования – то есть вам нужен отдельный контур, но не хватает ресурсов для самостоятельной эксплуатации. Обычно такое решение принимают после одного из трёх случаев:

1. оборудование устарело и требует замены;
2. мощности собственного ЦОДа закончились;
3. внутри ИТ-подразделения сократились компетенции для обслуживания инфраструктуры.

В Linx связывают рост спроса на частные облака в России с ростом внедрения ИИ в финансовых и телеком-компаниях, где нужен контроль над данными.

Сегмент private cloud в России растёт быстрее, чем в мире. Более половины объёма приходится на финансовый и телеком-секторы, где необходим максимальный контроль над данными. Государственные структуры, ритейл и медицина также существенно увеличивают потребление.

Один из примеров связан с банком, которому нужно было обновить инфраструктуру. Причина перехода – устаревшее оборудование и сокращение компетенций внутри ИТ-департамента.

Для них это прежде всего способ избавиться от капитальных затрат и снять нагрузку с внутренних ИТ-команд. Часто переломным моментом становится устаревание оборудования или исчерпание ресурсов собственного ЦОДа. Одним из недавно реализованных кейсов у нас было построение частного решения для банка – причиной перехода стали сократившиеся компетенции внутри ИТ-департамента и необходимость обновления оборудования.

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

Какие нагрузки куда размещать

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

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

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

Редакция Tproger недавно была нескольких таких ивентах и на партнёрском дне Диасофт пообщалась с членом правления Диасофт и директором по работе с партнёрами Александром Сахаровым. Мы поговорили о том, почему агентская разработка в её нынешнем виде — тупик, как строить эффективные AI-процессы разработки, почему фреймворк теперь важнее модели и что нового в AI-обновлении платформы Digital Q.

Digital Q — российская low-code экосистема разработки от «Диасофт» с готовым «заводом» инструментов для сборки корпоративных приложений: от проектирования бэкенда, дизайна интерфейсов до DevOps. В мае 2026 года вышла AI-driven версия, где искусственный интеллект встроен в саму платформу — он проектирует архитектуру, генерирует код, фронтенд и бизнес-процессы по человекочитаемой спецификации, оставляя разработчику работу с замыслом, а не с рутиной.

AI добрался до фундамента

— Александр, начну с прямого вопроса. ИИ обсуждают на каждом углу. Как вы считаете, что действительно изменилось, стало главным сдвигом, а что просто шум?

— Главный сдвиг — это то, что AI добрался до вещей, которые казались незыблемыми. ERP-системы — это же фундамент крупного предприятия. И мы своими глазами видим, как крупные компании переходят на вайб-кодинг ERP. Звучит страшновато, но это факт, это происходит не в стартапах, а в очень больших организациях. Банки, промышленность, энергетика — везде одно и то же.

А шум — это вера, что AI всё решит сам по себе. Что можно купить лицензии Copilot, посадить за них разработчиков и они вам начнут производить продукты в десять раз быстрее. Нет, не начнут. Точнее, начнут, но счета вас очень неприятно удивят.

От агентов к AI-native платформе

Агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native

— Вы на сцене показывали, как обновился Digital Q с декабря. Что конкретно поменялось за эти полгода?

— В декабре, на зимнем партнёрском дне, мы представили платформу Digital Q.GPT — на ней можно реализовывать агентский workflow. Интеграция со всеми LLM-моделями, экосистема построения агентов, мультиагентные системы. На тот момент это было супер актуально.

К маю выяснилось, что этого недостаточно. За последние шесть месяцев все — Anthropic, Google, Gartner, Amazon, Сбер на ЦИПР — пришли к одному и тому же выводу: агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native, то есть AI вшит в саму экосистему разработки, а не прикручен сбоку отдельными агентами.

— А что плохого в агентах?

— С агентами ничего плохого, они нужны. Плохо, когда вся разработка строится только вокруг них. Если кто-то хочет писать агенты — пожалуйста, в Digital Q.GPT весь функционал остался: workflow, мультиагентные системы, всё это работает. Но это уже не центральная история. Центральная история теперь — единая экосистема, в которую AI встроен на каждом этапе процесса.

Три способа потерять деньги на AI

Сегодня становится очевидно, что фреймворк важнее модели. Весь контекст, знания и артефакты разработки должны находиться внутри собственной экосистемы компании, а не зависеть от поставщика LLM. Это позволяет управлять стоимостью разработки, сохранять независимость и обеспечивать масштабирование решений.

— Давайте про антипаттерны. Вы на сцене перечислили целый список — что точно делать не надо. Какой из них самый болезненный?

— Самый болезненный — вендорлок на конкретную LLM. Если вчера вы платили 20 долларов на разработчика в месяц, завтра это 100, послезавтра 200. Скоро будет дороже, чем один разработчик в месяц. И весь ваш контекст — спецификации, история, наработки — лежит у этой модели. Вы заложник. Они вам говорят: «не парьтесь, весь контекст у нас, всё будет хорошо». Хорошо у них будет, а у вас потом будут проблемы.

Второй болезненный — зоопарк инструментов. Если у вас разработчики накодили чего-то в пяти разных средах, потом вы это нормально не соедините. Получится лоскутное одеяло, только сделанное в десять раз быстрее, чем раньше.

Третий — использовать AI только в кодировании. Это путь в галлюцинации и в бесконечные ошибки, которые вы потом просто не отследите.

— Как можно решить эти проблемы?

— Главный тезис: фреймворк важнее модели. Они это называют harness, мы называем экосистема разработки. Есть термины IDP — Integrated Development Platform, IDE — Integrated Development Environment. Суть одна. Ваш фреймворк должен быть локально у вас, весь контекст — локально у вас, модели должны быть взаимозаменяемые. Тогда вы можете переключаться между ними и управлять стоимостью.

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

Как теперь устроена разработка

— Вы говорили про два контура разработки. Объясните для тех, кто услышит об этом впервые.

— Раньше был один контур: ТЗ — постановка — кодирование — тестирование — релиз. Долго, последовательно. Цифровая трансформация это ускорила: годы превратились в кварталы и месяцы. Но всё равно один линейный процесс.

Сейчас он распадается на два. Первый — контур замысла, или, как у Сбера говорят, контур намерений. Здесь работает человек. Описывает на естественном языке, что хочет получить. Агенты помогают разложить это на артефакты — процессы, формы, справочники, архитектуру. Человек видит результат визуально, проверяет, правит, опять же голосом или текстом.

Второй контур — контур реализации. Здесь уже всё на агентах и моделях. Это фактически чёрный ящик под замыслом. Человек его контролирует только по результату. Не нравится — возвращается в контур замысла, правит спецификацию, перезапускает.

И самое важное между ними — экосистема, которая держит все артефакты и весь контекст. Если этой экосистемы нет — у вас ничего не получится развивать. Сгенерили код, отдали в продакшен, а через полгода вы уже не понимаете, как туда внести изменение.

— Это та же мысль, что и про вендорлок, по сути?

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

— Вернёмся к Digital Q. Как она теперь устроена? Если разобрать на компоненты — что там лежит?

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

На самом деле там на двухчасовой разговор материала. Но главная мысль одна: только такая штука обеспечивает вам контроль по затратам, нормальный процесс и независимость от иностранных LLM или дорогих российских моделей.

Разработчик всегда идёт на самую дорогую модель — она же лучшая. И запускает её сто раз в день. Ему кажется, что это бесплатно. Извините, не бесплатно.

— Почему вы так настойчиво возвращаетесь к теме денег? Ведь все маркетинговые материалы AI-вендоров обещают именно экономию.

— Потому что это самая опасная иллюзия сейчас. Uber, пытаясь сэкономить на разработчиках, потратил больше трёх миллиардов долларов на AI-генерацию кода. Японская компания за несколько месяцев потратила 500 миллионов долларов вместо тех людей, которых сократили. Долларов, не рублей. И это уже не теория, это свежие кейсы 2025–2026 годов.

Почему так получается? Потому что разработчик, если его не ограничивать, всегда идёт на самую дорогую модель — она же лучшая. И запускает её сто раз в день. Увидел маленькое расхождение в результате — поправил формулировку — перегенерил всё. Ему же кажется, что это бесплатно. Это так красиво, так удобно — нажал кнопку, всё пересоздалось. Извините, не бесплатно. Это огромные деньги. Свобода такая, что разоряет.

— И как вы с этим боретесь технически?

— Лимиты в самой экосистеме. Разработчикам автоматически предлагаются более дешёвые модели для простых задач, иногда вообще бесплатные. Жёстко зашиваем: при изменениях перегенерация только изменённых частей, не модуля целиком. Если в модуле 50 тысяч строк кода, и вы поправили одну спецификацию — не должны перегенериваться все 50 тысяч.

И главное — переиспользование. Когда мы даём задание на исполнение, первый шаг — найти весь код в репозитории, который можно встроить. Если компонент уже есть — мы его не генерим, мы его подключаем. Ни одного токена сюда не тратится. Половину нового модуля у нас собирается из готового кода. К модели обращаемся только за тем, чего ещё нет.

— Расскажите про демо с CRM. Вы показывали, как из 400-страничного ТЗ получается работающее приложение. Это правда один день двух человек, или там есть нюансы?

— Один день двух человек — это правда. Нюансы есть, конечно. Главный: это не black box, который сгенерил вам что-то непонятное. Это полностью оснащённый артефактами IT-проект. Можно пойти и сдать любому госзаказчику по ГОСТу. Полная документация — техническая, пользовательская, финансовая. Полный набор описанных бизнес-процессов. Полный набор тестов, включая тесты на уязвимости.

Что происходит по шагам? Загружаем ТЗ в основной контекст платформы. Она начинает читать, находит нестыковки, раскладывает по полочкам — где процесс, где поток, где архитектура. Задаёт уточняющие вопросы заказчику. Можно ответить, можно сказать «работаем как есть» — тогда она дальше креативит по тому, что есть.

Дальше прорисовывает архитектуру бэкенда. Здесь критически важный момент: она смотрит на репозиторий и решает, что писать с нуля, а что переиспользовать. У неё в инструкциях жёстко зашито: инфобез не писать, использовать готовый. Логирование не писать. Справочники, типовые штуки — не переписывать. Только то, что реально новое.

— А фронтенд?

— Полностью автогенерация. Мастер: меню справа, меню слева, нужна аналитика — не нужна, нажал галочки — получил весь фронт. Документированный, открытый, лежит в гите. Дальше можно дорабатывать голосом — буквально говоришь в микрофон «добавь форму жалобы на робота», и она лезет в MCP, смотрит схему дизайна, добавляет форму, обновляет версии, выпускает изменение. Современные разработчики уже на клавиатуре ничего не пишут — у них микрофон.

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

И финал — DevOps-сборка, докер-образы, юнит-тесты, интеграционные, регрессионные, тесты на уязвимости. Половина этих тестов сгенерилась автоматически по нашим стандартам ещё на этапе подготовки.

— Вы говорили, что AI-агенты теперь работают не только в коде, но во всех ролях — от аналитика до девопса. Как это устроено?

— У каждой роли — аналитик, архитектор, фронтенд-разработчик, бэкенд-разработчик, девопс-инженер — теперь свой набор агентов. И не только в IT-ролях. Продавцы, юристы, логисты, кадровики — у всех появляются свои агенты. На некоторых российских предприятиях речь идёт уже не о сотнях, а о тысячах агентов, которые работают параллельно и автоматизируют не только разработку, но и все процессы внутри организации.

Фишка нашей платформы в том, что мы все роли оснастили всеми агентами из коробки. Не надо ничего собирать самому. Скачали Digital Q, поставили, производите ПО.

Что доступно прямо сейчас

С июля начинаем публиковать обновлённую версию. Можно скачать, развернуть, запускать.

— И эта экосистема действительно доступна партнёрам?

— Да, мы её отдаём рынку. С июля начинаем публиковать обновлённую версию для партнёров. Можно скачать, развернуть, запускать. Правда, нужно знать, что такое Kubernetes и Kafka — это не магический инсталлер для гуманитариев. Но если знаете — берёте и работаете.

У нас уже сейчас несколько десятков компаний создали свои продукты на этой экосистеме. Кто-то с большим успехом, крупные компании тоже распробовали и начали работать.

— Возвращаясь к началу разговора. Вы фактически заявляете, что Диасофт — единственный, кто отдаёт такую экосистему рынку. Это правда так, или маркетинг?

— Это так. Давайте честно: на российском рынке такие экосистемы делают несколько компаний. Сбер, ВТБ, Тинькофф — для себя. Это им и нужно, у них колоссальные команды разработки, они это могут себе позволить. Кто-то из телекома делает для своих больших разработок. Иногда они пробуют что-то предложить рынку, но по большому счёту — это всё «для себя».

Диасофт делает экосистему и для себя, и для рынка. Сегодня в рынок такую экосистему — уже трансформированную под AI — фактически продолжаем отдавать только мы. Это наш бизнес, это наша история. Сбер и другие крупные игроки сейчас взяли паузу с публикацией для рынка, на два-три года минимум. После этого цикла, может быть, появится альтернатива. Сейчас её нет.

Если такого человека нет — никакая AI-генерация вас не спасёт. Будет только дороже и хуже.

— Какой главный совет тем, кто только сейчас задумывается о собственной AI-трансформации разработки?

— Не повторяйте чужих ошибок. Не садитесь на одну модель — это вендорлок, и он дорого стоит. Не пытайтесь решить всё через агентов поверх существующего бардака — масштабироваться не будет. Не верьте, что AI сам по себе сэкономит вам деньги — без управляющей экосистемы он их сожрёт быстрее, чем вы успеете уволить разработчиков.

И ещё одно. Команды теперь строятся вокруг продуктового инженера. Это новая ключевая роль. Раньше ценностью был код. Сейчас ценность — бизнес-компетенция, способность правильно поставить задачу. Если у вас есть человек, который понимает бизнес и умеет это сформулировать — код появится быстро. Если такого человека нет — никакая AI-генерация вас не спасёт. Будет только дороже и хуже.

Бонус: чек-лист «AI-разработка без иллюзий»

Разговор получился интересный, и мы собрали для вас короткий чек-лист, который пригодится и разработчикам, и бизнесу.

Чего точно не стоит делать:

— Сажать команду на одну LLM-модель — это вендорлок, и он будет дорожать;

— Разрешать разработчикам неограниченно гонять самую дорогую модель;

— Использовать AI только в кодировании, без интеграции в остальной процесс;

— Накупить разных инструментов и надеяться, что они потом «как-нибудь соберутся»;

— Сокращать разработчиков в расчёте на «бесплатные» токены.

Что стоит сделать:

— Держать экосистему разработки и весь контекст локально;

— Зашить в платформу переиспользование кода — половину нового модуля собирать из готового;

— Настроить лимиты: дешёвые модели для простых задач, перегенерация только изменённых частей;

— Разделить процесс на два контура — замысла (где работает человек) и исполнения (где работают агенты);

— Растить продуктовых инженеров — людей, умеющих формулировать задачу, а не только писать код.

Реклама. Рекламодатель: ООО «Диасофт», ИНН 7715560268, erid: 2W5zFJRM88q

Почему VPS замедляется, хотя железо стало лучше

Если вы работаете с VPS давно, то, наверное, заметили: серверы стали быстрее по заявлению хостинг-провайдеров, но на практике ощущение ровно обратное. Причин несколько, и все они системные.

1. Ресурсы делятся на большее число соседей

VPS – это не отдельный физический сервер, а виртуальная машина, которая получает часть ресурсов одного хоста. Один физический процессор делится между десятками виртуальных машин, и ваш vCPU – это не отдельное ядро, а право на какое-то его время.

Провайдеры это время распределяют через гипервизор. Пока соседи по хосту не нагружены – вы получаете запрошенные ресурсы. Когда все активны одновременно – гипервизор забирает у вас часть процессорного времени на других. В Linux это видно в метрике %st (steal time): она показывает, сколько времени CPU вашей ВМ простаивал, ожидая своей очереди на физическом ядре.

В 2016–2018 году на один физический поток приходилось 4–8 виртуальных CPU. Сейчас нормой у бюджетных провайдеров стало 10–16. Физические ядра стали быстрее, но конкуренция за них выросла пропорционально.

2. Операционная система потребляет больше

Базовое потребление Linux заметно выросло за последние несколько лет. Ubuntu 16.04 запускалась в 100-150 MB RAM в режиме сервера, а Ubuntu 24.04 при минимальной конфигурации занимает уже 3000-5000 MB ещё до запуска вашего приложения. Официальные рекомендации Canonical для Ubuntu 24.04 – минимум 2 GB RAM для серверной установки.

На VPS с 1-2 GB это означает, что операционная система сразу забирает треть или половину памяти. Под ваше приложение остаётся меньше, чем кажется при выборе тарифа.

3. Программный стек стал тяжелее

Если в 2015 году типичный бэкенд – это PHP-приложение, MySQL и Nginx – умещался в 512 MB, то современный стек выглядит иначе. К приложению добавляются: брокер очередей, сервис кеширования, агент мониторинга, контейнерный рантайм или несколько сервисов в Docker. Каждый компонент занимает память и использует CPU в фоне.

Поэтому, если три года назад ваш проект работал на VPS с 2 GB RAM, а сейчас вы обновили зависимости и добавили пару сервисов – тот же объём памяти уже не даёт той же производительности.

4. Патчи безопасности замедлили системные вызовы

В 2018 году стало известно об уязвимостях Spectre и Meltdown в процессорах Intel и AMD. Патчи, которые закрыли эти дыры, добавили overhead на операции с памятью и системные вызовы. Для обычного веб-приложения замедление было в пределах 5-10%, но для баз данных с большим количеством операций ввода-вывода некоторые тесты показывали падение throughput до 20%.

Три профиля нагрузки: что именно упёрлось в потолок

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

1. CPU-bound: процессор загружен, всё остальное ждёт

Симптомы: top или htop показывают устойчивую загрузку одного или нескольких ядер на 90-100%. Запросы к приложению уходят в очередь, время ответа растёт пропорционально нагрузке. При этом RAM свободна, дисковая активность минимальна.

Частая причина на VPS – однопоточный код, который упирается в одно виртуальное ядро. В таких случаях добавление второго vCPU не всегда помогает: если код однопоточный, второе ядро просто не задействуется.

Что проверить первым делом: top с сортировкой по CPU, mpstat -P ALL 1 для того, чтобы посмотреть загрузку по каждому ядру отдельно. Если одно ядро стабильно на 100% – проблема в коде или конфигурации, а не в количестве ядер.

2. RAM-bound: памяти хватает формально, но сервер уже свопит

Симптомы: в free -h показывает, что RAM занята почти полностью, активен swap. Даже на NVMe своп работает в десятки раз медленнее оперативной памяти, поэтому приложение начинает подвисать.

Что проверить: free -h для общей картины, vmstat 1 5 для активности свопа, smem или ps aux --sort=-%mem для понимания, какой процесс занимает больше всего памяти.

3. I/O-bound: диск или сеть не успевают

Симптомы: CPU свободен, RAM в порядке, но запросы всё равно медленные. В iostat -x 1 видно, что %util на диске стабильно высокий, await (среднее время ожидания операции) растёт. Это означает, что диск перегружен запросами и не успевает их обрабатывать.

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

Что проверить: iostat -x 1, iotop для определения процесса-виновника. Отдельно стоит проверить %iowait в top – если он регулярно выше 10-15%, дисковая подсистема перегружена.

Инструменты для диагностики

Для разовой проверки удобен glances – он выводит CPU, RAM, диск и сеть в одном экране. Для постоянного мониторинга подойдёт Netdata: он устанавливается одной командой, работает в браузере и показывает метрики в реальном времени с детализацией до секунды. Оба инструмента доступны в репозиториях стандартных дистрибутивов и работают на любом российском VPS-провайдере без ограничений.

Лучше собрать метрики хотя бы за неделю до принятия любого решения об апгрейде. Пиковые значения в 15-минутном срезе и средние за неделю могут сильно отличаться, и решение, основанное только на пике, часто оказывается избыточным.

Когда оптимизация ещё спасёт

Апгрейд тарифа – очевидный путь, но не всегда правильный. Во многих случаях сервер тормозит из-за конфигурации или архитектуры приложения, а не нехватки ресурсов. Прежде чем платить за более мощный план, стоит проверить несколько вещей.

Кеширование на уровне приложения

Самая частая причина перегрузки CPU на веб-проектах – повторная генерация одного и того же контента при каждом запросе. Если страница собирается из базы данных каждый раз, когда её открывают, при росте трафика процессор начнёт упираться в лимиты раньше, чем это реально необходимо.

Решается это установкой Redis и настройкой кеширования на уровне приложения. Redis хранит результаты тяжёлых запросов в памяти и отдаёт их без обращения к базе данных. Для WordPress это плагины типа Redis Object Cache, для Laravel – встроенный драйвер кеша, для Django – django-redis. Для статичных страниц дополнительно имеет смысл настроить страничное кеширование. В этом случае сервер отдаёт готовый HTML-файл без выполнения кода вообще.

Веб-сервер и обработка статики

Apache удобен в настройке, но потребляет заметно больше памяти при параллельных соединениях. Каждый процесс Apache занимает 20–50 MB RAM, и при 50 одновременных соединениях это уже 1–2.5 GB только на веб-сервер. Nginx обрабатывает соединения асинхронно и при той же нагрузке требует меньше памяти.

Если проект сейчас работает на Apache и сервер упирается в RAM, переход на Nginx может решить проблему без смены тарифа. Миграция для стандартного PHP-проекта занимает несколько часов и не требует изменений в коде приложения.

Статические файлы – изображения, CSS, JS – стоит раздавать через CDN. Российские провайдеры предлагают CDN-услуги: Selectel, VK Cloud, Яндекс Cloud. Это снимает с VPS нагрузку по раздаче файлов, которые и без того не требуют серверной обработки.

Разделение сервисов по отдельным серверам

Когда на одном VPS живут база данных, приложение и фоновые задачи, они конкурируют за одни и те же ресурсы. Если фоновая задача запустила тяжёлую операцию с базой данных, приложение начинает тормозить, хотя формально ресурсов должно хватать.

Решение – вынести нагруженные компоненты на отдельные серверы. Чаще всего первой выносится база данных: она требует быстрого диска и достаточно RAM для буферного пула, и изоляция позволяет настроить её параметры независимо от приложения. Следующий кандидат – фоновые задачи: воркеры очередей в Laravel, Celery в Django, любые ресурсоёмкие cron-задачи.

Оптимизация базы данных

База данных – отдельная точка, которую проверяют в последнюю очередь, хотя именно она чаще всего виновата в медленных ответах. Медленные запросы видно через SHOW PROCESSLIST в MySQL или pg_stat_activity в PostgreSQL. Там же видно, есть ли запросы, которые выполняются секундами и блокируют другие.

Включите лог медленных запросов: в MySQL это slow_query_log = 1 с порогом long_query_time = 1, в PostgreSQL — log_min_duration_statement = 1000. После этого в логах появятся запросы, которые выполняются дольше одной секунды. В этом случае можно добавить индексы по полям, которые участвуют в этих запросах, чтобы сократить время выполнения.

Симптомы, что VPS уже не вытянет

Оптимизация имеет предел, если вы уже настроили кеширование, перешли на Nginx, вынесли базу данных на отдельный сервер и добавили индексы, но проблемы не ушли – дело в архитектурных ограничениях самого VPS. Ниже перечислены конкретные метрики, которые указывают на это.

1. CPU steal выше 10-15% в течение дня

Steal time – это процент времени, когда ваш vCPU ждёт физического ядра, которое занято другими виртуальными машинами на том же хосте. Смотреть его можно в top в строке %st или через vmstat 1.

Разовые всплески steal до 20–30% во время общего пика нагрузки на провайдера — это нормально. Если steal стабильно держится выше 10–15% на протяжении нескольких часов в сутки, ваше приложение систематически недополучает процессорное время. Оптимизация кода в этом случае даст меньший эффект, потому что ограничение находится на уровне гипервизора, а не вашего стека.

2. Своп активен при свободном CPU

Если vmstat 1 показывает ненулевые значения в колонках si и so (swap in / swap out) при том, что CPU загружен на 20-30%, у сервера закончилась оперативная память и он начал использовать дисковое пространство как её расширение.

Добавление RAM в этом случае помогает, но только если вы ещё не выбрали максимальный тариф провайдера. Когда текущий VPS-план не позволяет добавить больше памяти, а приложению нужно 6-8 GB и выше, это архитектурное ограничение конкретного тарифа.

Верхняя граница у большинства российских VPS-провайдеров на стандартных тарифах – 8-16 GB RAM. Если приложение уже приближается к этому пределу с учётом роста, апгрейд внутри VPS-линейки даст лишь временное решение.

3. Время ответа растёт при нагрузке, которая раньше была нормальной

Конкретный признак: вы мониторите время ответа приложения (через Netdata, Zabbix или простой скрипт с curl) и видите, что при той же посещаемости, что была полгода назад, время ответа стало в полтора-два раза выше.

Если оптимизация стека уже проведена, это говорит о том, что ресурсов физически не хватает на текущий объём работы. Проверьте дополнительно: iostat -x 1 для дискового await (нормальное значение для NVMe – до 1-2 мс, значения выше 10 мс указывают на перегрузку дисковой подсистемы хоста).

Чек-лист: пора ли переезжать

Если три и более пункта из списка ниже выполняются одновременно на протяжении нескольких недель – VPS уже не справляется и оптимизация не решит проблему:

• CPU steal стабильно выше 10% в рабочие часы
• Своп активен при CPU ниже 50%
• Время ответа приложения выросло на 50% и выше за последние 3-6 месяцев без роста нагрузки
• Резервное копирование занимает вдвое больше времени, чем полгода назад
• Вы уже на максимальном тарифе VPS у текущего провайдера
• Приложение падает или деградирует при кратковременных пиках, которые раньше проходили без последствий

Чем IaaS отличается от VPS архитектурно

VPS и облачный IaaS – это виртуальные машины, но с разной архитектурой под капотом. Разница становится важной именно тогда, когда VPS упирается в описанные выше ограничения.

Как устроен VPS

VPS – это виртуальная машина на одном физическом сервере. Провайдер делит ресурсы этого сервера между несколькими клиентами: вам достаётся фиксированное количество vCPU, RAM и дискового пространства. Эти ресурсы привязаны к конкретному хосту.

Если хост перегружен соседями, вы получаете деградацию производительности. Если хост выходит из строя, ваша виртуальная машина недоступна до восстановления. Масштабирование требует смены тарифа и, как правило, перезагрузки.

Как устроен IaaS

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

Ресурсы выделяются из общего пула. Это означает, что вы можете изменить конфигурацию машины через панель управления или API без перезагрузки и без привязки к тому, что физически доступно на одном хосте. Вертикальное масштабирование (добавить CPU или RAM) и горизонтальное (добавить новые инстансы) происходит значительно быстрее.

Когда архитектурная разница имеет практическое значение

Для небольшого проекта со стабильной нагрузкой разница между VPS и IaaS минимальна. Она становится ощутимой в нескольких конкретных ситуациях.

• Сезонные пики нагрузки. Если у вашего проекта есть выраженная сезонность – распродажи, учебные периоды, праздничные кампании – VPS вынуждает вас держать мощности, рассчитанные на пик, весь год. В IaaS вы масштабируете ресурсы под конкретный период и сокращаете их после.
• Требования к доступности. VPS не обеспечивает отказоустойчивость на уровне железа: сбой хоста означает простой. Если проект требует SLA выше 99.5% и простой стоит денег, IaaS с репликацией между узлами кластера закрывает эту задачу на инфраструктурном уровне.
• Микросервисная архитектура. Когда приложение состоит из нескольких независимых сервисов, которые нужно разворачивать, масштабировать и обновлять по отдельности, управлять этим через набор VPS становится трудозатратно. IaaS в связке с Managed Kubernetes позволяет автоматизировать этот процесс.

Если вы дошли до точки, когда VPS уже не справляется и чек-лист из предыдущего раздела сработал, следующий шаг – облачная инфраструктура с нормальным SLA и возможностью масштабирования. Linx Cloud предоставляет IaaS на базе собственных дата-центров уровня TIER III в Москве и Санкт-Петербурге, работает на VMware, OpenStack, а уровнем ниже All-flash СХД и кластера хостов уровня Enterprise с полностью дублированной сетью передачи данных. Подробнее – на linx.ru/cloud/iaas.

Итого

Решение о переезде с VPS на IaaS стоит принимать на основе конкретных метрик, а не ощущения, что что-то работает медленно.

Последовательность ваших действий должна выглядеть так:

1. Сначала диагностика через top, vmstat, iostat.

2. Затем оптимизация стека – кеширование, веб-сервер, индексы в базе данных, разделение сервисов.

3. Если после этого проблемы остались и чек-лист из раздела про симптомы показывает три и более пункта, VPS исчерпал свои возможности для вашей задачи.

Матрица выбора

Если вы сейчас на этапе диагностики и ещё не решили, нужен ли переезд, начните с установки Netdata на текущий сервер и сбора метрик за две недели. Этого хватит, чтобы увидеть реальную картину нагрузки и принять решение с данными, а не по ощущениям.

Эта статья объясняет, почему классических CI/CD-ворот недостаточно для production-систем на базе ИИ. Автор делится практическим подходом к release gates для LLM-пайплайнов с помощью baseline-оценок, детектирования дрейфа, shadow-проверок и ограничений по стоимости и латентности. Акцент — на профилактике: отлов тихих AI-регрессий до того, как они достигнут пользователей, на основе реальных уроков платформенной инженерии из production-инфраструктуры.

В пятницу днём я задеплоил обновлённый RAG-пайплайн. Все оценки прошли, оценки сходства выглядели отлично, а к утру понедельника система уверенно рекомендовала устаревшие цены, потому что embedding-модель дрейфовала настолько, что предпочитала старые чанки свежим. Ни один алерт не сработал, ни один тест не упал, дашборд был зелёным, а выходные данные — мусором.

В тот момент я перестал доверять зелёному цвету как сигналу к релизу. У нас не было проблемы с деплоем. У нас была проблема с release gates. Классический CI/CD создавался для детерминированного ПО. LLM — вероятностны. Наши ворота тоже должны быть вероятностными.

Классические CI/CD-ворота работают по принципу pass/fail, но LLM поставляют поведение, а не только код, поэтому нужны ворота, отслеживающие дрейф поведения.

Три режима отказа: eval drift (постепенная деградация оценок), distribution shift (реальные запросы отличаются от тестовых) и context poisoning (изменились извлечённые документы, а тесты спрашивают вчерашнее).

Четыре release gates: baseline eval suite, eval drift detection, shadow traffic validation, cost/latency guardrails.

Ворота должны быть простыми и понятными команде, иначе инженеры начнут их обходить.

Eval-датасеты нужно версионировать так же тщательно, как Terraform state: с бэкапами и параноей.

Почему классический CI/CD не справляется с LLM-пайплайнами

В обычной доставке ПО ворота достаточно просты: unit-тесты прошли, интеграционные тесты прошли, проверки безопасности прошли — деплой. Это бинарно. Сборка зелёная или красная. Эта модель ломается, когда вы поставляете не код, а поведение.

Классический CI/CD создавался для детерминированного ПО. LLM — вероятностны. Наши ворота тоже должны быть вероятностными.

Production-система на базе ИИ может сегодня показывать relevance 0,82, завтра 0,79, а на следующей неделе 0,74. Поскольку ни один запуск не пересекает порог отказа, никого не пейджат, хотя пользователи уже получают худшие ответы.

Я больше 20 лет управлял production-инфраструктурой: приватными облаками OpenStack, миграциями баз данных, CI/CD-пайплайнами и mission-critical системами. В классическом DevOps мы усвоили: сервер, который сообщает о 99,9% аптайма при потере 0,1% финансовых транзакций, — не здоров. Он скрывает баг. Оценки LLM работают так же. Агрегированные метрики маскируют локальные отказы.

Первый режим отказа — eval drift: оценки деградируют постепенно, но недостаточно, чтобы упасть по жёсткому порогу. Второй — distribution shift: реальные пользователи задают короткие, беспорядочные, странные вопросы, о которых ваш чистый eval-датасет и не думал. Третий — context poisoning: ваши извлечённые документы изменились, а тесты всё ещё спрашивают вчерашние вопросы.

Традиционный CI/CD gate спрашивает: «Тест прошёл?» LLM release gate спрашивает: «Поведение осталось в допустимом диапазоне?» Обычный gate сравнивает ожидаемый вывод с фактическим. AI CI/CD gate сравнивает кандидатное поведение с историческим и production-поведением, а также со стоимостью, латентностью и риском. Традиционные ворота быстро отсеивают исключения. LLM release gates внимательно отсекают дрейф.

Традиционные ворота быстро отсеивают исключения. LLM release gates внимательно отсекают дрейф.

Это различие важно, потому что production AI-системы гниют, а не взрываются. Я создал llm-eval-drift-release-gates-AGENT, потому что хотел ворота, которые относятся к AI-релизам как к инфраструктурным релизам: измеримым, повторяемым и, по возможности, скучным. Скука недооценена. Она позволяет инженерам спать.

Анатомия LLM release gate

Первое ворото — baseline eval suite. Он прогоняет фиксированный датасет по кандидатному пайплайну и оценивает relevance, faithfulness, safety, groundedness и любые доменные проверки, которые вам важны. Цель не в том, чтобы доказать, что модель идеальна. Цель — поймать регрессии до того, как они станут историями от клиентов.

Вот упрощённая Python-структура из паттерна, который я использую:

Использование StrEnum сохраняет enum в виде строк без множественного наследования. Это важно в релизном инструментарии, потому что значения статусов часто логируются, сериализуются, сравниваются в CI или передаются в дашборды.

Это ловит очевидные отказы: коллапс relevance, падение faithfulness, небезопасные выходы или искажённые результаты оценщика. Если отказ жёсткий, пайплайн блокируется немедленно; если срабатывает предупреждение, требуется ручное одобрение. Мне не нравятся тихие предупреждения: это будущие инциденты в хорошей рубашке.

Второе ворото: детектирование дрейфа оценок

Второе ворото — детектирование дрейфа оценок. Фиксированного порога недостаточно. Если relevance падает с 0,91 до 0,86, ваш порог 0,80 говорит, что всё в порядке. Ваши пользователи могут не согласиться.

Поэтому я сравниваю текущие оценки с rolling baseline из недавних деплоев:

Eval suite обнаружил 6% падение relevance в 23:00 в четверг. Без него это падение достигло бы 200 пользователей к понедельнику. Ворото не знало бизнес-контекста. Ему это и не нужно. Оно знало, что кандидат хуже последнего известного хорошего релиза.

Третье ворото: shadow traffic validation

Третье ворото — shadow traffic validation. Перед полным раскатом я направляю небольшой процент реального трафика на кандидатный пайплайн. Пользователи всё ещё получают production-ответ, но система записывает кандидатный вывод для сравнения.

Это canary-deployment, применённый к ИИ. Я использовал тот же паттерн в инфраструктурных раскатах, включая идеи из моего репозитория eks-canary-deployment-pipeline. Разница в том, что для LLM вы сравниваете не только HTTP 200. Вы сравниваете качество ответа, извлечённый контекст, латентность и причины, по которым кандидат расходится с production подозрительным образом.

Judge-модель может быть полезна, но я не даю ей быть единственным авторитетом. Она даёт сигнал. Release policy принимает решение.

Четвёртое ворото: стоимость и латентность

Четвёртое ворото — стоимость и латентность. Модель, которая идеально оценивается, но стоит в 3 раза дороже, — не валидный релиз. RAG-пайплайн, который добавляет две секунды латентности, тоже не готов. Эта же логика легла в основу моей работы enterprise-rag-guardrails-costops.

Когда это ворото не проходит, система блокирует релиз или направляет его на ручное одобрение. Я научился не торговаться о латентности во время деплоя. Она всегда побеждает позже.

Эти четыре ворота не делают деплой LLM идеальным. Они делают сложнее поставку бессмыслицы под зелёным бейджем.

Как встроить это в существующий CI/CD

Release gate не должен быть отдельным научным проектом. Если ваша платформенная команда уже использует GitHub Actions или GitLab CI, LLM-пайплайн деплоя должен вписаться в этот workflow.

Паттерн намеренно скучный:

Такую форму я расширил из своей работы devsecops-pipeline-github-actions. Соберите приложение. Запустите детерминированные тесты. Запустите baseline eval suite. Сравните с rolling baselines. Провалидируйте на shadow-трафике. Проверьте бюджеты стоимости и латентности. Деплойте, только когда все ворота согласны.

Здесь guardrails MLOps становятся полезны платформенным инженерам. Вам не нужна отдельная религия деплоя. Вам нужен один дополнительный набор проверок внутри пайплайна, которому команда уже доверяет.

Вот небольшая Python-точка входа, которую можно вызывать из CI. Важная деталь: она падает аккуратно, когда нужные отчёты отсутствуют или искажены, потому что сырые stack trace — не стратегия релиза.

Лучший release gate — тот, которым команда реально пользуется. Если для настройки нужна PhD по ML, это не ворота. Это стена. Я сейчас получаю степень PhD в области безопасности облачных вычислений, и даже я не хочу процесс деплоя, которому каждую пятницу нужна диссертация. Ворота должны быть достаточно простыми, чтобы запускаться в CI, достаточно строгими, чтобы блокировать плохие релизы, и достаточно гибкими, чтобы не стать офисным украшением.

Последняя часть далась мне дольше, чем хотелось бы признать.

Ошибки, которые я совершил, и что бы сделал иначе

Моя первая версия была болезненно строгой. Каждый деплой блокировался. Eval suite жаловался на мелкие изменения формулировок, безобидные различия форматирования и пограничные падения оценок. Команда начала обходить ворота полностью. Это была моя вина.

Ворота, которые блокируют всё, хуже, чем никаких ворот. По крайней мере, без ворот люди знают, что рискуют. С плохими воротами они учатся игнорировать систему.

Ворота, которые блокируют всё, хуже, чем никаких ворот. С плохими воротами люди учатся игнорировать систему.

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

Оценки выглядели отлично. Production — нет.

Моя третья ошибка — не версионировал eval-датасет. Когда я добавлял новые крайние случаи, я терял возможность сравнивать старые релизы с новыми baselines. Теперь я версионирую eval-наборы так же, как версионирую Terraform state: внимательно, с бэкапами и с лёгкой паранойей.

Строить это из Кочабамбы, Боливия, тоже повлияло на дизайн. У меня не было неограниченных облачных кредитов на огромные eval-прогоны. Это заставило оптимизировать сэмплирование, кешировать вызовы judge-модели и разделять быстрые PR-проверки от более тяжёлых ночных.

Ограничения рождают лучшую инженерию. Раздражает, но правда.

Отправляйте уверенность, а не только код

В классическом ПО мы поставляем код и проверяем поведение. В ИИ мы поставляем поведение и проверяем соответствие. Release gates — это то, как мы закрываем этот разрыв.

LLM release gates не уберут неопределённость из production AI-систем. Ничто не уберёт. Но они дают платформенным командам практический способ поймать eval drift, distribution shift, context poisoning, скачки стоимости и регрессии латентности до пользователей.

Это важно для надёжности агентных workflow. Это важно для AI CI/CD. Это важно, потому что «все тесты прошли» больше не достаточно.

Я создал llm-eval-drift-release-gates-AGENT, потому что устал от зелёных пайплайнов, которые мне лгали. Репозиторий — open-source, offline-first референсная реализация этого паттерна release gates. Он намеренно достаточно мал, чтобы изучить, запустить, сломать и ужесточить в своём CI/CD.

Репозиторий: https://github.com/fdaniel-alvarez-dev/llm-eval-drift-release-gates-AGENT. Форкайте, ломайте, улучшайте. Худший release gate — тот, который вы никогда не построили.

Выводы

Классический CI/CD создавался для детерминированного ПО, а LLM — вероятностны. Поэтому release gates для ИИ должны отслеживать не только прохождение тестов, но и дрейф поведения: baseline-оценки, детектирование дрейфа, shadow-трафик, стоимость и латентность.

Ворота должны быть простыми, понятными и настраиваемыми. Их задача — не идеальная модель, а предотвращение тихих регрессий, которые иначе достигнут пользователей. Версионируйте eval-датасеты, проверяйте на реальном трафике и не забывайте про бюджеты. Так вы сможете доверять зелёному цвету пайплайна снова.

Если у вас нет времени смотреть все записи докладов целиком, держите главное.

Пределы стандартной сети Kubernetes

Привычная концепция сети в кластерах отлично справляется с базовой доставкой, балансировкой и фильтрацией трафика. Оркестратор дает «джентльменский набор» сетевых фич, которых вполне хватает для работы с типичными приложениями. Проблемы начинаются, когда хочется запустить в Kubernetes телефонию, libvirt или создать коммунальный кластер для нескольких команд.

Андрей Половов в своём докладе разобрал технические пределы классических CNI-плагинов. В Deckhouse отказались создавать Франкенштейна из готовых CNI- и SDN-решений, чтобы получить нативную для Kubernetes сетевую подсистему, в результате команда выкатила собственную программно-определяемую сеть.

В инструменте уже есть поддержка дополнительных сетей на классических VLAN, решён вопрос с адрес-менеджментом и dedicated NIC c поддержкой SR-IOV. В работе — дополнительные сети на XVLAN, DHCP для виртуалок, NetworkPolicy для дополнительных сетей, BGP и ALB-AAA.

Виртуалки как first-class citizens в Kubernetes

Тема с виртуалками в Kubernetes давно висит в воздухе. Компании идут в микросервисы и контейнеризацию, но в проде у многих до сих пор крутятся монолитные системы и легаси-приложения. Их реально проще держать в ВМ, чем быстро переписывать к следующему кварталу. На конференции этот вопрос разобрали в докладе Павла Тишкова через практику использования виртуализации внутри Kubernetes. Разговор шел именно про надежность и привычную управляемость виртуальных машин под управлением оркестратора.

Проблема соседства ВМ и контейнеров

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

Инженерам нужен способ держать все нагрузки в общем контуре и перестать плодить «зоопарк» из платформ, консолей и ручных регламентов. В докладе Павел разобрал практику запуска и управления виртуальными машинами наравне с контейнерамии внутри K8s.

Что меняется для инфраструктурной команды

Когда виртуалка становится штатным объектом внутри оркестратора, команда получает привычный operational flow. Ресурсы, политики, сеть и автоматизация начинают жить в одном контексте. Они больше не разъезжаются по разным панелям управления, где каждая вкладка требует отдельного ритуала. Вывод капитанский, но полезный: чем меньше ручной магии вокруг инфраструктуры, тем реже ночной дежурный вспоминает создателей этого стека.

Разработчики и DevOps получают возможность держать рядом сервис в контейнере и зависимый компонент в ВМ (которая тоже в контейнере). Изменения можно катать через знакомые процессы и постепенно разгребать наследство без миграции ради миграции. Deckhouse развивает виртуализацию без отрыва от Kubernetes и рассматривает виртуальные машины как часть общего рантайма для гибридных нагрузок.

Что стоит вынести из доклада

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

Самописный сontrol plane для SDS

Работа с Software-Defined Storage в Kubernetes часто оборачивается попытками подружить облачно-ориентированные технологии с инструментами старой школы. Александр Зимин разобрал типичный сценарий такого столкновения на примере LINSTOR. Разработчики Deckhouse изначально взяли этот инструмент на роль control plane, понимая его архитектурные ограничения. Они согласились на внешнюю базу данных и push-модель управления конфигурациями.

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

Большой болью оказался и технологический стек. Подсистему хранения данных в Deckhouse пишет Go-команда, которой приходилось тратить спринты на дебаг и патчинг чужого Java-кода. Поддерживать и дальше такой воркфлоу было абсолютно невыгодно. Поэтому, набравшись опыта с LINSTOR, инженеры просто отказались от готового решения и написали собственный control plane под программно-определяемого хранилища.

Спикер показал понятный рубикон для платформенной разработки. Полезно видеть чужой опыт и понимать, когда пора перестать адаптировать готовый open-source продукт под свои задачи и сесть за написание кастомного решения.

Реальная цена защиты кластера

При переходе в Kubernetes инженеры закладывают мощности под бизнес-логику, но не всегда учитывают ресурсы для средств защиты кластеров. Никита Ладошкин из Positive Technologies показал «налоги» на информационную безопасность, которые стоит держать в уме, если вы хотите получить больше защищенности, чем в «ванильном» Kubernetes.

Если компания дозрела до мониторинга runtime-рисков, ей приходится достраивать технологии, процессы и роли. Плата за всё это — высокие компетенции нанимаемых инженеров, дополнительные вычислительные ресурсы и время на разбор ошибок. Но есть и хорошие новости. Несмотря на то, что защита контейнерных сред неизбежно забирает своё из общего пула ресурсов, можно оформить «налоговый вычет». Например, за счет выбора правильных инструментов, фокуса на ценных активах и харденинга.

Защита самой платформы

Разумеется, информационная безопасность в контексте Kubernetes не ограничивается одним контролем уже запущенных нагрузок. Сама платформа для их развёртывания тоже должна быть защищена от разных векторов атак. В Deckhouse используют подходSecure by Design. Разработчики внедрили контроль целостности — обязательную цифровую подпись всех контейнерных образов платформы и её системных компонентов. Такой механизм исключает подмену на этапе доставки, иезаметная подмена кода полностью исключается.

Контроль всех ИБ-компонентов кластера в Dechouse Kubernetes Platform вынесли в специализированный интерфейс для централизованного контроля. А компаниям, которые подпадают под требования регуляторов пригодится сертифицированная ФСТЭК России редакция платформы.

Архитектура в пайплайнах вместо ревью

Когда код пушат десятки команд, техлиды физически не могут отсматривать каждый коммит. Архитектурное ревью быстро превращается в бутылочное горлышко, где релизы висят в ожидании согласования. Антон Исанин из «АльфаСтрахования» показал, как выпилить этот ручной труд с помощью Deckhouse Development Platform.

Ребята зашили стандарты разработки прямо в CI/CD. Теперь пайплайн сам разворачивает валидную среду и бьет по рукам, если сервис не проходит по инфраструктурным требованиям. Разработчики просто получают готовую песочницу и сразу пишут бизнес-логику. Сеньорам при этом больше не нужно тратить время на проверку базового бойлерплейта и объяснение правил при онбординге новых людей.

Что выкатил сам Deckhouse: веб-интерфейс, мониторинг, управление GPU и

В главном докладе Александр Титов и Давид Мэгтон показали ключевые апдейты Deckhouse Kubernetes Platform, а детали реализации и новости других продуктов команда раскрыла на профильных питчах.

Платформа для запуска софта должна быть простой в эксплуатации, несмотря её на сложность «под капотом». Для этого инженеры Deckhouse существенно прокачали графический интерфейс: теперь в нём доступны 100% возможностей CLI и API платформы, а ещё появилась удобная мультитенантность. Графический инсталлятор же теперь умеет ставить DKP в 9 видов инфраструктур.

С наблюдаемостью знакомая история: при росте количества метрик сборщики телеметрии начинают неадекватно потреблять оперативную память. Команда Deckhouse выкатила для решения этой задачи свою систему мониторинга Prom++. Она оптимизирует хранение данных и экономит RAM на серверах. API полностью совместим с Prometheus, поэтому переписывать привычные дашборды и алерты не придется.

Как уже было понятно из доклада про виртуализацию, DKP умеет запускать виртуальные машины наравне с контейнерами. За год с прошлой конференции здесь добавилось много новых фич, например, живая миграция и клонирование ВМ, гибкое управление USB и продвинутый мониторинг.

Под ML-задачи завезли нативное управление видеокартами. Платформа теперь умеет динамически нарезать одну физическую GPU на изолированные ресурсы для разных задач.

Представили и линейку управляемых сервисов. Сейчас в платформе уже доступны семь сервисов, которые закрывают основные сценарии работы с данными: PostgreSQL, Kafka, Cassandra, Valkey, Memcached, Hive Metastore и Trino.

Что еще стоит посмотреть в записи

Из остального расписания советуем глянуть кейс Владимира Анисимова и Антона Белоусова про партизанский кластер DKP CE. Материал пригодится инженерам, которым нужно собрать proof of concept для закрытого контура. Спикеры показали процесс развертывания платформы на обычном пользовательском железе практически без доступа в интернет. Этот опыт пригодится, если нужно обкатать гипотезу до выделения бюджетов на энтерпрайз-лицензии и серверные стойки.

Владимир Гурьянов прошелся по визуализации метрик. Доклад подойдет тем, кто устал смотреть на перегруженные данными дашборды, которые грузятся по несколько минут. Спикер разобрал частые ошибки создания дашбордов и объяснил логику выбора информации для графиков и их легенд. Увидите, почему привычка собирать на одном экране вообще все доступные параметры сервиса только мешает дежурным.

Записей докладов хватит для понимания, куда сейчас движется инфраструктурная разработка. Собирать окружение на кастомных баш-скриптах становится слишком дорого. Готовая платформа избавляет команду от необходимости связывать разные инструменты руками, и к этому формату работы пора привыкать.

Рувеб — Windows в тарифе и бюджетный старт.

UFO.Hosting — своя панель VMmanager и широкий выбор ОС.

Timeweb Cloud — масштабируемое облако с почасовой оплатой.

PSB Hosting — зарубежные локации и безлимитный трафик.

Selectel — корпоративное облако с 152-ФЗ и экосистемой сервисов.

RUVDS — быстрый старт, низкая цена входа и тест на 3 дня.

Кому нужен кроссплатформенный VPS

Разработчики и системные администраторы часто работают сразу с двумя экосистемами: Linux доминирует в вебе, DevOps и контейнерах, а Windows остаётся стандартом для корпоративного ПО, 1С, MS SQL и тестирования десктопных приложений. Кроссплатформенный VPS избавляет от необходимости заводить отдельные аккаунты у разных провайдеров: Linux- и Windows-машины управляются из одной панели, а переключение между ОС занимает минуты.

1. Рувеб — Windows в тарифе

Российский провайдер с собственными серверами в Москве и Амстердаме. Позиционируется как недорогой хостинг с прозрачными тарифами: минимальный Linux-VPS стоит меньше 400 ₽ в месяц, а лицензия Microsoft для Windows-шаблонов уже включена в стоимость.

Кейсы клиентов и кому подойдёт

По данным компании, типичный сценарий — совместное использование Linux и Windows на одном аккаунте: Linux-VPS работает как хост для сайта и Telegram-ботов, а Windows-машина используется для удалённого доступа и запуска ПО, которого нет под Linux. Также провайдер подходит разработчикам, которым нужен недорогой Ubuntu-сервер для production и отдельный Windows-VPS для тестирования совместимости.

Что можно развернуть

• Linux: AlmaLinux 8/9/10, CentOS Stream 9, CentOS 9 VMBitrix, Debian 11/12/13, Ubuntu 22.04/24.04, FreeBSD 14, Mikrotik CHR.
• Windows: Windows Server 2016/2019/2022, Windows 11.
• Панели управления: ISPmanager для AlmaLinux, Debian, Ubuntu; FastPanel для AlmaLinux 8 и Debian 11 (ISPmanager оплачивается отдельно).
• Доступ: root по SSH для Linux, RDP из коробки для Windows, веб-консоль для аварийного доступа.

Инфраструктура и экосистема

Серверы размещены в дата-центрах DataHouse в Москве и в Амстердаме, оба соответствуют уровню Tier 3. Виртуализация — KVM, диски — SSD и NVMe в зависимости от линейки. Провайдер работает по 152-ФЗ, зарегистрирован в реестре хостинг-провайдеров и предоставляет закрывающие документы для юрлиц.

Отзывы и репутация

На сайте компании публикуются отзывы клиентов со средней оценкой 4,5 из 5. Пользователи отмечают оперативную техническую поддержку и соотношение цены и качества, хотя встречаются упоминания о плановых переездах между дата-центрами с кратковременными перерывами.

Поддержка и каналы связи

Техническая поддержка работает через систему тикетов и онлайн-чат на сайте круглосуточно. Доступен бесплатный звонок по России по номеру 8(800) 505-93-34. Среднее время первого ответа — 10–30 минут. Для корпоративных клиентов и крупных проектов возможно закрепление персонального менеджера.

Тарифы, ограничения и условия

• Linux: KVMv-NANO — 1 CPU, 0,5 ГБ RAM, 12 ГБ SSD — 393 ₽/мес; KVMv-LIGHT — 2 CPU, 4 ГБ RAM, 80 ГБ SSD — 1672 ₽/мес.
• Windows: лицензия Microsoft входит в стоимость; Windows 11 доступна на тарифах от 1422 ₽/мес при оплате за год.
• Скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, год — 15%, два года — 25%.
• Тестовый период: 6 дней для Linux, 3 дня для Windows; активируется после пополнения баланса на 300 ₽.
• Трафик: до 50 000 ГБ/мес на полной скорости по Fair Use Policy, далее возможно временное снижение скорости.
• Бэкапы: вручную в панели, 1 ₽ за 1 ГБ; снапшоты бесплатны, но требуют аренду места.
• Ограничения: на тарифах NANO, MICRO и посуточных по умолчанию закрыты исходящие порты 25 и 465.

2. UFO.Hosting — своя панель VMmanager

Российский провайдер с собственной панелью управления на базе VMmanager. Отличается большим списком шаблонов ОС — от AlmaLinux и Astra Linux до Windows 10/11 и FreeBSD ZFS. Подходит тем, кому важна гибкость выбора операционной системы.

Кейсы клиентов и кому подойдёт

Провайдер описывает типичные сценарии: бухгалтерская фирма разворачивает 1С:Предприятие на Windows Server 2022 с RDP для нескольких сотрудников; разработчик держит production на Linux, а для тестирования Windows-сборок поднимает отдельный VPS. Также UFO.Hosting удобен для проектов, где нужны нестандартные дистрибутивы или десктопная Windows.

Что можно развернуть

• Linux: AlmaLinux 8/9/10, CentOS 7/8 Stream/9 Stream/10 Stream, Oracle Linux 8/9, Rocky Linux 8/9/10, Ubuntu 20.04/22.04/24.04, Debian 11/12/13, FreeBSD 13/14 ZFS, Astra Linux CE.
• Windows: Windows Server 2016/2019/2022 (включая Datacenter, Core, RUS, GPT), Windows 10/11.
• Панели: Vesta, Hestia, CyberPanel, Virtualmin, ISPmanager; первый месяц ISPmanager бесплатно, далее 400 ₽/мес.
• Доступ: SSH с ключами для Linux, RDP из коробки для Windows, VNC-консоль в панели, мультипользовательский RDP на Windows Server.

Инфраструктура и экосистема

Оборудование расположено в московском дата-центре IXcellerate уровня Tier 3. Виртуализация — KVM, диски — NVMe. В одном личном кабинете доступны VPS/VDS, выделенные серверы, домены, SSL-сертификаты и DNS-хостинг. Провайдер зарегистрирован в реестре хостинг-провайдеров, работает по 152-ФЗ, но сертификации ФСТЭК не имеет.

Отзывы и репутация

Публичные агрегированные рейтинги в предоставленных источниках не указаны. Компания позиционирует себя как провайдер с активацией серверов до 15 минут и помощью в миграции сайтов.

Поддержка и каналы связи

Техническая поддержка работает круглосуточно через онлайн-чат на сайте и тикет-систему в биллинге. Телефонная поддержка доступна в будни с 9:00 до 18:00. Поддержка в Telegram не осуществляется. Есть база знаний; выделенный менеджер для B2B планируется.

Тарифы, ограничения и условия

• Linux: тариф Naos — 1 CPU, 1 ГБ RAM, 25 ГБ NVMe — от 577 ₽/мес при оплате за 3 месяца; Brachium — 2 CPU, 4 ГБ RAM, 60 ГБ NVMe — от 977 ₽/мес.
• Windows: доступна для установки от тарифа Brachium, стоимость — от 1025 ₽/мес.
• Лицензия Windows: не входит в стоимость, ОС предоставляется в Trial-версии; для легального использования лицензию приобретают самостоятельно.
• Скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, год — 15%.
• Тестовый период: 3 дня на любой VPS-тариф; требуется верификация аккаунта (email, телефон, KYC).
• Трафик: 32 ТБ/мес, после превышения скорость ограничивается до 100 Мбит/с; на выделенных серверах трафик безлимитный.
• Бэкапы: ежедневные — 525 ₽/мес, еженедельные — 262,5 ₽/мес; восстановление через панель или поддержку.
• Ограничения: VPN запрещён, так как он заменяет сетевые настройки; исходящий SMTP-порт 25 закрыт по умолчанию.

3. Timeweb Cloud — масштабируемое облако

Крупнейший российский облачный провайдер с собственной инфраструктурой VAPI Stack. Подходит для проектов, которым нужно масштабирование ресурсов, API, Terraform и возможность загружать собственные образы.

Кейсы клиентов и кому подойдёт

Timeweb Cloud ориентирован на разработчиков, SaaS-стартапы и компании, которым нужна гибкая инфраструктура. Почасовая оплата позволяет запускать тестовые окружения на короткий срок, а API и Terraform упрощают автоматизацию. Провайдер также подходит для размещения сайтов, интернет-магазинов, баз данных и CI/CD-конвейеров.

Что можно развернуть

• Linux: Ubuntu, Debian, CentOS, Astra Linux CE, собственные образы.
• Windows: Windows Server, готовые образы в маркетплейсе.
• Инструменты управления: панель Timeweb Cloud, API, Terraform, CLI, Cloud-init.
• Дополнительно: бэкапы, снапшоты, образы дисков, DDoS-защита, балансировщики, Kubernetes, managed-базы данных.

Инфраструктура и экосистема

Серверы размещены в дата-центрах Tier 3 в России (Москва, Санкт-Петербург, Новосибирск), Казахстане (Алматы), Германии (Франкфурт) и Нидерландах (Амстердам). Виртуализация — KVM, диски — NVMe. Дата-центры сертифицированы по ISO и PCI DSS, инфраструктура соответствует 152-ФЗ. Провайдер заявляет о 150 000+ клиентах и статусе лауреата Премии Рунета.

Отзывы и репутация

На страницах услуг публикуются недавние отзывы пользователей: клиенты отмечают скорость работы серверов, удобство панели и оперативность поддержки. Провайдер заявляет о доступности серверов на уровне 99,98% по SLA с финансовыми гарантиями.

Поддержка и каналы связи

Поддержка работает 24/7 через чат, мессенджеры, социальные сети, тикеты и телефон. Провайдер бесплатно помогает с миграцией данных с других площадок и предлагает услуги администрирования.

Тарифы, ограничения и условия

• Linux: VPS с предустановленной Ubuntu — от 169 ₽/мес при оплате за год или от 477 ₽/мес помесячно; типовой тариф Cloud MSK 40 — 2 CPU, 2 ГБ RAM, 40 ГБ NVMe — 882 ₽/мес.
• Windows: Windows Server доступен в конфигураторе; точные цены уточняйте на сайте.
• Лицензия Windows: условия лицензирования Microsoft уточняйте в поддержке.
• Оплата: почасовой биллинг, минимальный платёж — 50 ₽.
• Тестовый период: возможность бесплатного тестирования рассматривается индивидуально.
• Трафик: безлимитный на всех тарифах.
• Бэкапы: 6 ₽/ГБ/мес; образы — 3 ₽/ГБ/мес; снапшоты бесплатны, один на сервер, хранятся 7 дней.
• Ограничения: диск можно увеличить, но не уменьшить; для уменьшения — обращение в поддержку.

4. PSB Hosting — зарубежные локации

Международный хостинг-провайдер с фокусом на Европу и США. Подходит для проектов, где важна география серверов, безлимитный трафик и анонимная оплата криптовалютой.

Кейсы клиентов и кому подойдёт

PSB Hosting ориентирован на пользователей, которым нужны серверы за пределами России: международные SaaS-платформы, сервисы с аудиторией в Европе и США, VPN-инфраструктура и проекты, где критична скорость отклика для зарубежных пользователей. Клиенты сами выбирают конфигурацию под свои задачи.

Что можно развернуть

• Linux: Ubuntu, Debian, CentOS, AlmaLinux, Rocky Linux, Oracle Linux, FreeBSD, Astra Linux.
• Windows: Windows Server 2016/2019/2022, Windows 10/11.
• Предустановленное ПО: Docker, Django, WordPress, OpenVPN, WireGuard, FastPanel, HestiaCP.
• Доступ: root по SSH для Linux, RDP из коробки для Windows, веб-консоль в панели.

Инфраструктура и экосистема

Серверы расположены в дата-центрах класса Tier 3+ и 4 в Амстердаме, Франкфурте, Хельсинки и Нью-Йорке. Платформа построена на процессорах AMD и Intel с DDR5-памятью и NVMe-дисками; для высоконагруженных задач есть линейка HI-CPU VPS на базе AMD Ryzen 7950X. Провайдер предоставляет подсеть /64 IPv6 на всех тарифах и полноценную панель управления DNS-записями доменов.

Отзывы и репутация

На сайте размещены ссылки на отзывы на площадках OtzyvMarketing.ru (4,8), In-Scale.ru (5,0), Aff1.ru (5,0) и 101Poisk.ru (4,89). Публичных агрегированных рейтингов на независимых площадках в предоставленных источниках не указано.

Поддержка и каналы связи

Техническая поддержка работает круглосуточно через тикеты и Telegram. Время ответа зависит от загрузки. Для B2B-клиентов доступен персональный менеджер. Документация включает API и базу знаний.

Тарифы, ограничения и условия

• Цены: конкретные тарифы в предоставленных источниках не указаны; стоимость не зависит от выбора ОС. Уточняйте на сайте.
• Лицензия Windows: покупается отдельно.
• Оплата: почасовая; принимаются карты России, СНГ и ЕС, Qiwi, криптовалюта (Bitcoin, Ethereum, Litecoin, USDT).
• Тестовый период: не предоставляется.
• Трафик: безлимитный на всех тарифах; порт до 10 Гбит/с, на VPS выделяется до 300 Мбит/с.
• Бэкапы: платно; неограниченное количество резервных копий; восстановление через панель.
• Ограничения: запрещён неправомерный контент; порт 25 открывается через службу поддержки; мультипользовательский RDP — 1 сессия.

5. Selectel — корпоративное облако с 152-ФЗ

Крупный российский облачный провайдер для команд, которым важны не только Linux- и Windows-серверы, но и инфраструктура вокруг них: сети, бэкапы, мониторинг, хранение данных и требования к персональным данным. Selectel подходит для проектов, где VPS быстро перерастает в полноценную облачную инфраструктуру.

Кейсы клиентов и кому подойдёт

Selectel стоит рассматривать компаниям, которые держат production и staging в одном облаке, работают с персональными данными или хотят запускать Linux- и Windows-серверы рядом с управляемыми сервисами. Это вариант для SaaS, внутренних корпоративных систем, CI/CD-инфраструктуры и проектов, которым нужны предсказуемые российские дата-центры.

Что можно развернуть

• Linux: Ubuntu, Debian, Fedora CoreOS, CentOS, SelectOS, Astra Linux, Alma Linux, Rocky Linux, Fedora, Oracle Linux.
• Windows: образы Windows доступны в каталоге облачных серверов; также можно использовать собственные образы, включая лицензированное ПО Microsoft, приобретённое у другого провайдера.
• Инфраструктура: виртуальные машины, сетевые диски, бэкапы, балансировщики, S3, базы данных, Kubernetes и инструменты мониторинга.
• Доступ: управление через панель Selectel; для автоматизации доступны облачные API и типовые сценарии DevOps-инфраструктуры.

Инфраструктура и экосистема

На официальной странице облачных серверов Selectel подчёркивает моментальное масштабирование, соответствие 152-ФЗ и размещение виртуальных выделенных серверов в дата-центрах уровня Tier III. Вокруг серверов есть отдельные сервисы хранения, резервного копирования, сетевой связности и информационной безопасности.

Отзывы и репутация

В эту подборку Selectel включён как инфраструктурный провайдер с официальной линейкой облачных серверов и широким набором смежных сервисов. Публичные пользовательские рейтинги в рамках этой правки отдельно не сравнивались.

Поддержка и каналы связи

На сайте указаны канал продаж sales@selectel.ru и телефон 8 800 555-06-75. Для действующих клиентов поддержка и управление услугами доступны через личный кабинет Selectel.

Тарифы, ограничения и условия

• Цены: рассчитываются в конфигураторе облачных серверов и зависят от vCPU, RAM, дисков, региона и дополнительных сервисов.
• Лицензия Windows: условия зависят от выбранного образа и лицензии; можно использовать собственные лицензированные образы Microsoft.
• Оплата: облачная модель с гибкой конфигурацией ресурсов; итоговую стоимость нужно проверять в панели перед запуском сервера.
• Трафик: условия зависят от сетевой конфигурации и выбранных сервисов.
• Бэкапы: доступны отдельные сервисы резервного копирования и сетевые диски; стоимость зависит от объёма хранения.
• Ограничения: это более инфраструктурный вариант, чем простой VPS-хостинг, поэтому для маленьких проектов конфигуратор может быть избыточен.

6. RUVDS — быстрый старт и тест на 3 дня

Российский VPS-провайдер для быстрого запуска виртуального сервера без длинной настройки инфраструктуры. RUVDS подойдёт, если нужно недорого проверить идею, поднять Linux-сервер для небольшого сервиса или взять Windows-VPS под RDP и прикладное ПО.

Кейсы клиентов и кому подойдёт

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

Что можно развернуть

• Linux: VPS-линейки для веб-сервисов, ботов, тестовых стендов и небольших backend-проектов.
• Windows: отдельная линейка VPS Windows для задач с RDP, корпоративным ПО и Windows-приложениями.
• Производительность: доступны варианты с быстрыми NVMe-дисками.
• Доступ: стандартные сценарии SSH для Linux и RDP для Windows; управление сервером через личный кабинет провайдера.

Инфраструктура и экосистема

На официальной странице RUVDS указывает 22 дата-центра уровня Tier III в 9 странах, отдельные линейки для Windows и быстрых NVMe-серверов, а также помощь с аттестацией по ФСТЭК для инфраструктурных задач с повышенными требованиями.

Отзывы и репутация

В подборку RUVDS добавлен как массовый VPS-провайдер с низкой стартовой ценой и тестовым периодом. Независимые пользовательские рейтинги в рамках этой правки отдельно не сравнивались.

Поддержка и каналы связи

На сайте указан бесплатный телефон 8 (800) 775-97-42 и круглосуточный формат связи. Для рабочих инцидентов условия реакции стоит проверять в SLA и правилах выбранного тарифа.

Тарифы, ограничения и условия

• Цены: VPS Start — от 139 ₽/мес; итог зависит от выбранной линейки и конфигурации.
• Тестовый период: новым пользователям доступен бесплатный тест на 3 дня для сервера стоимостью до 3000 ₽.
• Лицензия Windows: условия зависят от выбранной Windows-линейки и конфигурации.
• Трафик и диски: параметры зависят от тарифа; для задач с дисковой нагрузкой есть NVMe-линейка.
• Бэкапы: условия резервного копирования нужно проверять в панели и описании конкретного тарифа.
• Ограничения: минимальная цена полезна для старта, но производительные Windows-сценарии потребуют более дорогой конфигурации.

Сравнение по ключевым критериям

Ниже — текстовое сравнение по ценам, лицензиям, смене ОС и условиям для всех шести участников.

Цены и лицензии

Минимальный Linux-VPS: Рувеб — 393 ₽/мес; UFO.Hosting — от 577 ₽/мес; Timeweb Cloud — от 169 ₽/мес при оплате за год; PSB Hosting — уточняется на сайте; Selectel — рассчитывается в конфигураторе облачных серверов; RUVDS — VPS Start от 139 ₽/мес. Windows-VPS: Рувеб — от 1422 ₽/мес с включённой лицензией; UFO.Hosting — от 1025 ₽/мес, но лицензию нужно покупать отдельно; Timeweb Cloud, PSB Hosting, Selectel и RUVDS — по конфигуратору или Windows-линейке.

Лицензия Windows: у Рувеб она включена в стоимость тарифа. У UFO.Hosting ОС предоставляется в Trial-версии, у PSB Hosting — покупается отдельно, у Timeweb Cloud условия уточняются в поддержке. У Selectel можно использовать Windows-образы и собственные лицензированные образы Microsoft; у RUVDS условия зависят от выбранной Windows-линейки.

Смена ОС и управление

Смена ОС: у Рувеб и Timeweb Cloud доступна переустановка с потерей данных; у UFO.Hosting — через панель за ~20 минут; у PSB Hosting — через панель с пересозданием сервера; у Selectel и RUVDS сценарий зависит от выбранного образа и обычно решается созданием или пересозданием сервера. Панель: Рувеб использует сторонний биллинг, UFO.Hosting — собственный VMmanager, Timeweb Cloud, PSB Hosting, Selectel и RUVDS — собственные панели или конфигураторы.

Трафик, бэкапы и поддержка

Трафик: Timeweb Cloud и PSB Hosting предлагают безлимитный трафик; Рувеб — до 50 ТБ/мес по Fair Use Policy; UFO.Hosting — 32 ТБ/мес с ограничением скорости после превышения; Selectel и RUVDS зависят от выбранной конфигурации и сетевых условий тарифа. Бэкапы: у всех провайдеров платные или тарифицируются по объёму; Timeweb Cloud и PSB Hosting также предлагают снапшоты, Selectel выделяет резервное копирование в отдельный сервис. Поддержка: у всех участников есть официальные каналы связи, но формат SLA и скорость реакции лучше проверять перед заказом.

Вывод

Для бюджетного старта с готовой Windows-лицензией подойдёт Рувеб: минимальный Linux-VPS дешевле 400 ₽, а Windows 11 уже включена в тариф. Если важен широкий выбор ОС и собственная панель VMmanager — смотрите на UFO.Hosting, но учитывайте, что лицензию Microsoft придётся покупать отдельно. RUVDS стоит рассмотреть, когда нужен самый быстрый вход, тест на 3 дня и отдельная Windows-линейка.

Timeweb Cloud выигрывает у масштабируемости, API и почасовой оплаты: это вариант для растущих проектов и команд с DevOps-практиками. Selectel сильнее в корпоративных сценариях, где нужны 152-ФЗ, Tier III, бэкапы и смежные облачные сервисы. PSB Hosting стоит рассмотреть, если нужны зарубежные локации, безлимитный трафик и оплата криптовалютой — но конкретные тарифы и условия лицензирования лучше уточнить перед заказом.

Все шесть провайдеров позволяют держать Linux и Windows в одном аккаунте, но баланс цены, удобства, лицензий и инфраструктурных возможностей у каждого свой. Перед выбором советуем проверить тестовый период или минимальный депозит и протестировать сценарии, критичные для вашего проекта.

Макхост — низкий порог входа и российские документы.

UFO.Hosting — широкая линейка VPS и выделенных серверов.

SmartApe — гибкие конфигурации и быстрый старт.

PSB Hosting — зарубежные локации и безлимитный трафик.

FirstVDS — бюджетный массовый вариант для простых проектов.

Hetzner Cloud — иностранная облачная альтернатива с ограничениями для РФ.

Как мы выбирали

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

1. Макхост — низкий порог входа

Макхост — российский хостинг-провайдер с собственными панелями управления и низким стартовым тарифом. Входит в реестр хостинг-провайдеров, работает с юрлицами и предлагает VPS в России и Европе.

Кейсы клиентов и кому подойдёт

• Сайты-визитки и лендинги на минимальной конфигурации с 1 CPU и 1 GB RAM.
• Интернет-магазины на популярных CMS и телеграм-боты: по данным провайдера, часто выбирают KVM-2 с 2 GB RAM.
• 1С:Предприятие и корпоративные сайты с модулем синхронизации: рекомендуют конфигурации от 4 GB RAM.
• VPN-серверы личного использования и небольшие тестовые окружения.

Что можно развернуть

• Операционные системы: Ubuntu, Debian, AlmaLinux, CentOS Stream.
• Панели управления: ISPmanager, FastPanel; на тарифах VPS первый месяц ISPmanager 6 в подарок.
• Готовые образы и стеки: WordPress, 1С, Docker, LAMP, почта, DNS, SSL.
• SSH и root-доступ для произвольной настройки окружения.

Инфраструктура и экосистема

• Виртуализация KVM с гарантированными ресурсами.
• Дата-центры: DataPro в Москве и площадка в Амстердаме.
• Диски: NVMe и DDR4 на всех VPS-тарифах, кроме самого дешёвого KVM-NEW с SSD.
• Сеть: порт до 1 Гбит/с, безлимитный трафик на всех тарифах, кроме KVM-NEW (2 ТБ).
• Соответствие 152-ФЗ, реестр хостинг-провайдеров; закрывающие документы для юрлиц.

Отзывы и репутация

На странице VPS у Макхоста указана средняя оценка 5 на основе 13 оценок. Пользователи отмечают круглосуточную поддержку и быструю помощь в сложных ситуациях; провайдер позиционирует себя как лидер авторитетных рейтингов.

Поддержка и каналы связи

• Каналы: тикет-система и онлайн-чат на сайте.
• Среднее время первого ответа: 10–20 минут.
• Для корпоративных клиентов и крупных проектов возможен персональный менеджер.
• База знаний, блог со статьями и платное администрирование VPS при необходимости.

Тарифы, ограничения и условия

• Стартовый KVM-NEW: 1 CPU, 0.6 GB RAM, 5 GB SSD, 2 ТБ трафика — 143 ₽/мес.
• Популярный KVM-2: 1 CPU, 2 GB RAM, 30–60 GB NVMe — от 693 ₽/мес при оплате за год.
• Топовый VPS KVM-12: 6 CPU, 12 GB RAM, 180–360 GB NVMe — от 3465 ₽/мес при оплате за год.
• Скидки за предоплату: 3%, 6%, 12%, 24% за 3, 6, 12, 24 месяца соответственно.
• Тестовый период: 3 дня с активационным платежом 290 ₽, который остаётся на балансе.
• Апгрейд без пересоздания сервера, обычно с кратковременной перезагрузкой.

Официальный сайт: Макхост

2. UFO.Hosting — широкая линейка

UFO.Hosting предлагает виртуальные и выделенные серверы в России с акцентом на широкую линейку конфигураций и NVMe-диски. Подходит тем, кто рассматривает и VPS, и bare-metal в одном кабинете.

Кейсы клиентов и кому подойдёт

• Небольшие проекты и сайты-визитки на тарифе Naos с 1 CPU и 1 GB RAM.
• Интернет-магазины, корпоративные сайты и телеграм-боты с вебхуками на Brachium с 2 CPU и 4 GB RAM.
• 1С:Предприятие и нагруженные CMS: рекомендуют от 4 CPU и 8 GB RAM.
• Проекты, которым нужны выделенные серверы без соседей.

Что можно развернуть

• Операционные системы: различные дистрибутивы Linux и Windows (ISO-образы доступны на старших тарифах).
• Панели управления: ISPmanager, Vesta, Hestia, Cyberpanel, Virtualmin.
• Готовые шаблоны ПО в зависимости от выбранной ОС.
• Дополнительные IP-адреса, аренда подсетей, настройка BGP.

Инфраструктура и экосистема

• Виртуализация KVM; процессоры Intel Xeon E5-2697A v4.
• Дата-центр IXcellerate в Москве, сертифицированный Tier III+.
• NVMe-диски в RAID10 на VPS/VDS; Enterprise SSD на выделенных серверах.
• Сеть: порт до 10 Гбит/с на ноде, 32 ТБ трафика в месяц на VPS (далее ограничение 100 Мбит/с); на выделенных серверах — без ограничений.
• Работа по 152-ФЗ, реестр хостинг-провайдеров; документы для юрлиц через ЭДО.

Отзывы и репутация

Публичные отзывы и агрегированные рейтинги в предоставленных материалах не указаны. Провайдер акцентирует внимание на Tier III+ инфраструктуре и запуске серверов до 15 минут.

Поддержка и каналы связи

• Каналы: онлайн-чат на сайте и тикет-система в биллинге 24/7; телефон в будни с 9:00 до 18:00.
• Среднее время первого ответа: не более 30 минут в любое время суток.
• База знаний в блоге ufo.hosting/blog.
• Продажи и поддержка готовы консультировать B2B-клиентов.

Тарифы, ограничения и условия

• Минимальный VPS Naos: 1 vCPU, 1 GB RAM, 25 GB NVMe — 605.85 ₽/мес.
• Популярный Brachium: 2 vCPU, 4 GB RAM, 60 GB NVMe — 1025.85 ₽/мес.
• Топовый VPS Intercrus: 32 vCPU, 64 GB RAM, 510 GB NVMe — 16 800 ₽/мес.
• Выделенный сервер Восток-1: 2x E5-2697v4, 384 GB RAM ECC, 4x960 GB Enterprise SSD — 43 050 ₽/мес.
• Скидки за предоплату: 5%, 10%, 15% за 3, 6, 12 месяцев.
• Тестовый период: 3 дня на VPS после полной верификации аккаунта; на выделенных серверах — обсуждается персонально.
• Апгрейд тарифа из личного кабинета без пересоздания сервера, вступает в силу после перезагрузки.

Официальный сайт: UFO.Hosting

3. SmartApe — гибкие конфигурации

SmartApe делает ставку на гибкость: кроме фиксированных линеек есть полностью конфигурируемые тарифы, где можно менять ресурсы под задачу. Провайдер использует процессоры Intel Xeon Platinum, AMD EPYC и AMD Ryzen.

Кейсы клиентов и кому подойдёт

• Лендинги и сайты-визитки на минимальных конфигурациях с 2 CPU и 1 GB RAM.
• WordPress, корпоративные сайты и интернет-магазины до 10 тыс. посетителей в сутки.
• Bitrix, CRM, ERP и 1С: рекомендуют от 4 CPU и 8 GB RAM.
• Нагруженные API, базы данных и высоконагруженные проекты на конфигурируемых тарифах.

Что можно развернуть

• Linux- и Windows-серверы, панели управления ISPmanager, Hestia и другие.
• Готовые стеки под Docker, базы данных, веб-приложения.
• Автоматическое развёртывание сервера за 1–2 минуты; бесплатная помощь с переносом сайтов при использовании ISPmanager или Hestia.

Инфраструктура и экосистема

• Виртуализация KVM с изоляцией и гарантированными ресурсами.
• Процессоры: Intel Xeon E5-2696 v4, Intel Xeon Platinum, AMD EPYC, AMD Ryzen 9.
• Диски: серверные NVMe SSD или HDD + SSD-кэш, RAID-10.
• Дата-центры: DataPro Moscow I, II, III в России; Host-Telecom в Чехии; Partner Group в Израиле; уровни Tier III и Tier IV.
• Сеть: безлимитный трафик на всех VPS, канал до 200 Мбит/с.
• SLA 99.9%, заявленный фактический uptime 99.982%.
• Соблюдение 152-ФЗ, договор на обработку персональных данных.

Отзывы и репутация

Публичные отзывы и рейтинги в предоставленных материалах не указаны. Провайдер акцентирует внимание на показателях NVMe-хранилища: до 680 тыс. IOPS на чтение и до 185 тыс. IOPS на запись.

Поддержка и каналы связи

• Каналы: тикеты в личном кабинете, онлайн-чат, телефон.
• Среднее время первого ответа: 10–15 минут.
• Раздел помощи на smartape.ru/help.
• Персональный менеджер обсуждается индивидуально для B2B.

Тарифы, ограничения и условия

• Минимальные тарифы: HDD S1 (2 CPU, 1 GB RAM, 50 GB HDD+SSD) — 345 ₽/мес; NVMe X1 (2 CPU, 1 GB RAM, 10 GB NVMe) — 495 ₽/мес; Turbo R1 AMD Ryzen (2 CPU, 1 GB RAM, 20 GB NVMe) — 645 ₽/мес.
• Топовый VPS NVMe X64: 24 CPU, 64 GB RAM, 640 GB NVMe — 11 870 ₽/мес.
• Скидки за предоплату: 5%, 15%, 30%, 50% за 3, 6, 12, 24 месяца.
• Тестовый период: 10 дней без привязки банковской карты, нужно подтверждение номера телефона.
• Резервное копирование со стороны провайдера не предусмотрено; можно настроить самостоятельно или заказать FTP-хранилище.
• Апгрейд фиксированных тарифов — по запросу в поддержку с перезагрузкой; конфигурируемые тарифы меняются в личном кабинете.

Официальный сайт: SmartApe

4. PSB Hosting — зарубежные локации

PSB Hosting ориентирован на международные дата-центры и широкий выбор операционных систем. Подходит проектам, которым важны европейские и американские площадки, безлимитный трафик и подсеть IPv6 /64 на всех тарифах.

Кейсы клиентов и кому подойдёт

• Сайты и веб-приложения, ориентированные на аудиторию в Европе и США.
• VPN-серверы, прокси и сетевые сервисы благодаря безлимитному трафику и IPv6 /64.
• Проекты на Node.js, Django, Docker, WordPress и других стеках.
• Разработчики, которым нужна нестандартная ОС или загрузка собственного ISO.

Что можно развернуть

• Операционные системы: Ubuntu, Debian, CentOS, Windows, Astra Linux, AlmaLinux, Rocky Linux, FreeBSD, Oracle Linux; можно загрузить свою ОС через ISO.
• Предустановленное ПО: Docker, LAMP, Keitaro, FastPanel, Node.js, Portainer, WordPress, Django, Outline, OpenVPN, Wireguard, HestiaCP, VestaCP, Bitrix.
• Полноценная панель управления DNS-записями доменов.

Инфраструктура и экосистема

• Виртуализация KVM, NVMe-диски.
• Дата-центры: euNetworks в Амстердаме, Frankfurt 1 Data Center в Германии, Digita в Хельсинки, Long Island Interconnect в Нью-Йорке.
• Сеть: порт до 10 Гбит/с, безлимитный трафик, подсеть /64 IPv6 на всех тарифах.
• SLA 99.7%; мониторинг состояния сервера встроен в панель.
• Договор на обработку персональных данных; оплата картами РФ, СНГ, ЕС и криптовалютой.

Отзывы и репутация

Публичные отзывы и агрегированные рейтинги в предоставленных материалах не указаны. Провайдер позиционирует себя через широкий выбор ОС, безлимитный трафик и неограниченное количество резервных копий.

Поддержка и каналы связи

• Каналы: тикеты и Telegram 24/7.
• Время ответа зависит от загрузки; поддержка работает круглосуточно.
• Документация и API на сайте.
• Персональный менеджер доступен для B2B-клиентов.

Тарифы, ограничения и условия

• Популярная конфигурация: 4 vCPU, 8 GB RAM, 100 GB SSD — $25/мес.
• Скидки за предоплату: 5%, 10%, 15% за 3, 6, 12 месяцев.
• Бесплатного тестового периода нет.
• Резервные копии платные, создаются ежедневно; количество не ограничено.
• Апгрейд без потери данных с перезагрузкой сервера.
• Сервер выделяется за 5–10 минут после установки ОС.

Официальный сайт: PSB Hosting

5. FirstVDS — бюджетный VPS/VDS для простого старта

FirstVDS — российский VPS/VDS-провайдер с готовыми тарифами и быстрым запуском сервера. Он подходит для простых веб-проектов, тестовых окружений и задач, где важны понятная стартовая цена, российские площадки и базовые дополнительные услуги.

Кейсы клиентов и кому подойдёт

• Небольшие сайты, pet-проекты, тестовые стенды и простые backend-сервисы.
• Проекты, где важнее низкая цена входа и быстрый запуск, чем детальный подбор ресурсов под нагрузку.
• Сценарии, где можно начать с готового тарифа и позже мигрировать на более производительную линейку.

Что можно развернуть

• Linux/VDS для сайтов, блогов, небольших баз данных и веб-приложений.
• Windows-серверы: на сайте есть отдельная линейка VDS для Windows Server 2019 и 2022.
• Дополнительные услуги: S3, автоматическое резервное копирование, администрирование, DDoS-защита, мониторинг сайтов.

Инфраструктура и экосистема

На официальной странице FirstVDS указаны серверы в России, Нидерландах и Казахстане, запуск готового сервера за 2 минуты, отдельные линейки VDS Форсаж, CPU.Турбо, VDS Atlant, Storage и GPU. Это вариант для тех, кто хочет выбрать готовую линейку, а не собирать конфигурацию вручную.

Тарифы и ограничения

• Стартовая цена на сайте: VPS/VDS от 249 ₽/мес.
• Плюс: круглосуточный бесплатный телефон 8 800 775-38-37 и большое количество отзывов на сайте.
• Особенность: параметры под конкретный сценарий лучше дополнительно проверять в конфигураторе и на тестовой конфигурации.

Официальный сайт: FirstVDS

6. Hetzner Cloud — зарубежное облако для международных проектов

Hetzner Cloud — европейский облачный провайдер с API и дата-центрами в Германии, Финляндии, США и Сингапуре. Он подходит для международных проектов, тестовых окружений и команд, которым важны автоматизация, сети, firewalls и понятная облачная модель. Для российских юридических и регуляторных требований условия нужно проверять отдельно.

Кейсы клиентов и кому подойдёт

• Тестовые окружения, личные проекты, международные веб-сервисы и инфраструктура для разработчиков.
• Команды, которым нужны API, CLI, Terraform/Ansible-интеграции, private networks и firewalls.
• Проекты с аудиторией в Европе, США или Азии, где российская юрисдикция и документы не критичны.

Что можно развернуть

• Linux-дистрибутивы: Ubuntu, Debian, Fedora и другие образы.
• One-click apps: Docker, WordPress, Nextcloud, GitLab, Grafana, Jitsi Meet, WireGuard и другие.
• Облачная инфраструктура с networks, firewalls, load balancers, API, CLI и интеграциями для CI/CD.

Инфраструктура и экосистема

Hetzner описывает shared cloud как вариант для разработки, тестов, личных сайтов, небольших баз данных и веб-серверов со средней нагрузкой. Dedicated cloud рассчитан на бизнес-приложения и устойчивую высокую нагрузку. На сайте также указаны GDPR, ISO/IEC 27001 для дата-центров в Германии и Финляндии, 99,9% uptime и поддержка 24/7 по email.

Тарифы и ограничения

• Цены и конфигурации зависят от выбранной страны, валюты и типа cloud-сервера; в статье лучше считать их отдельно в калькуляторе Hetzner.
• Плюс: зрелая европейская облачная экосистема и сильная автоматизация.
• Особенность: иностранная юрисдикция и документы отличаются от российских провайдеров, поэтому для проектов с персональными данными и 152-ФЗ условия нужно проверять отдельно.

Официальный сайт: Hetzner Cloud

Сравнение по ключевым критериям

Минимальный вход: у Макхоста самый дешёвый стартовый тариф — 143 ₽/мес, но с ограниченным трафиком и SSD. SmartApe предлагает старт от 345 ₽/мес с двумя ядрами и HDD+SSD-кэшем; FirstVDS начинается от 249 ₽/мес и подходит как бюджетная точка входа. UFO.Hosting, PSB Hosting и Hetzner Cloud стоит считать по конфигурации и требованиям к географии.

Популярные конфигурации: Макхост и UFO.Hosting выделяют тарифы с 2 GB RAM для магазинов и CMS; у SmartApe стартовый NVMe-тариф даёт 2 CPU и 1 GB RAM; у PSB Hosting популярный тариф — 4 CPU и 8 GB RAM за $25/мес. FirstVDS удобен для простых стартовых задач, а Hetzner Cloud — для международных проектов и команд, которым нужны API, сети и автоматизация.

Диски и трафик: у каждого провайдера разные акценты по дискам, портам, бэкапам и ограничениям. FirstVDS даёт массовую VPS/VDS-линейку и дополнительные сервисы вроде S3, бэкапов и мониторинга. Hetzner Cloud силён по API, сетям, firewalls и included traffic; его условия нужно пересчитывать отдельно под регион и валюту.

Тестовый период: SmartApe даёт 10 дней без карты, Макхост и UFO.Hosting — 3 дня с условиями, PSB Hosting — не предусмотрен. Для FirstVDS и Hetzner Cloud тестовый период и условия пробного запуска лучше проверять на момент заказа.

География и документы: Макхост, UFO.Hosting и SmartApe подтверждают работу по 152-ФЗ и наличие российских площадок; PSB Hosting работает только из зарубежных дата-центров и предлагает оплату криптовалютой. FirstVDS имеет российские и зарубежные площадки. Hetzner Cloud работает в иностранной юрисдикции, поэтому для проектов с персональными данными россиян нужно заранее проверить документы, обработку данных и требования 152-ФЗ.

Выводы

Выбор VPS начинается с честной оценки нагрузки: 1 CPU и 1 GB RAM хватит для статического лендинга или простого бота, но для CMS с плагинами, интернет-магазина или 1С стоит закладывать минимум 2 CPU и 4 GB RAM, а лучше — тестировать реальную нагрузку на выбранной панели.

Если важен минимальный бюджет и российские документы — смотрите на Макхост. Если нужна широкая линейка от VPS до выделенных серверов в одном кабинете — на UFO.Hosting. Для гибкого подбора ресурсов под растущую нагрузку подойдёт SmartApe. Если проект ориентирован на зарубежную аудиторию и нужен безлимитный трафик — PSB Hosting.

FirstVDS подойдёт для недорогих и простых запусков с российскими и зарубежными площадками. Hetzner Cloud — для международной инфраструктуры, где важны API, сети и дата-центры за пределами России; юридические и регуляторные требования нужно проверять отдельно.

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

• Виртуальный хостинг — сайты соседствуют на одном сервере, управляет провайдер. Дешёвый старт, но ограниченная конфигурация.
• VPS и VDS — почти всегда синонимы: изолированные виртуальные серверы с root-доступом и гарантированными ресурсами.
• Выделенный сервер — отдельное железо, максимум контроля и цены, требует администрирования.
• В подборке: Интернет Хостинг Центр, UFO.Hosting, SpaceWeb, PSB Hosting, AdminVPS и FirstVDS.

Как мы выбирали участников

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

1. Интернет Хостинг Центр — гибкие конфигурации

Российский провайдер, у которого VPS и VDS — это одна услуга. Можно выбрать виртуализацию под задачу (KVM или Virtuozzo), собрать конфигурацию от минимальной до высоконагруженной и расти внутри одной платформы до выделенного сервера.

Кейсы клиентов и кому подойдёт

• Небольшой сайт компании на WordPress с 300–500 посетителей в сутки спокойно живёт на виртуальном хостинге; при росте трафика переходят на VPS.
• Интернет-магазин на 1С-Битрикс с 500–1000 пользователями в день переносят на VPS/VDS, когда подключают CRM и платёжные системы.
• Разработчик с несколькими проектами берёт VPS/VDS под API, базу данных и тестовые окружения — виртуальный хостинг здесь слишком ограничен.

Что можно развернуть

На виртуальном хостинге — сайты на PHP 5.2–8.2 с MySQL, панели IHC, cPanel или ISPmanager. На VPS/VDS — любые Linux-дистрибутивы, Windows, WireGuard, MikroTik Router, панели ispmanager/FastPanel, VPN-шаблоны, CMS вроде 1С-Битрикс.

Инфраструктура и экосистема

Дата-центры Tier III в Москве (DataPRO и IXcellerate Moscow One) и в Амстердаме. Виртуализация — KVM или Virtuozzo. Защита от DDoS входит во все тарифы, IPv6-сети /64 доступны за доплату. Есть партнёрская программа с выплатами до 50% от привлечённых оплат.

Отзывы и репутация

На сайте публикуются отзывы с внешних площадок: средняя оценка 4,8 по 20 оценкам. Клиенты отмечают стабильную работу и скорость техподдержки.

Поддержка и каналы связи

Тикеты через личный кабинет, онлайн-чат на сайте, Telegram @IHC_Support_Bot, телефоны в Москве, Санкт-Петербурге и бесплатный номер для регионов. Первый ответ обычно приходит за 10–30 минут в рабочее время. Для корпоративных клиентов доступно сопровождение через отдел продаж и аккаунт-менеджеров.

Тарифы, ограничения и условия

• Виртуальный хостинг: тариф IHC-2 — от 123 ₽/мес при оплате за год или 147 ₽/мес помесячно; 2 сайта, 2 ГБ SSD, 150 МБ под БД, домен .RU в подарок при оплате за 2 года.
• VPS/VDS: минимальная конфигурация ssdVPS:1 — 1 ГБ RAM, 20 ГБ SSD, 1 CPU, безлимитный трафик со снижением скорости после 20 ТБ — от 317 ₽/мес за год или 380 ₽/мес помесячно.
• Типовая конфигурация для небольшого проекта — 2 ГБ RAM, 1–2 CPU, 30–45 ГБ NVMe — от 609 ₽/мес за год или 700 ₽/мес помесячно.
• Тестовый период: 7 дней на виртуальном хостинге, 3 дня на VPS/VDS; для активации нужно пополнить баланс на 100 ₽, которые можно вернуть или потратить.
• Бэкапы: место под резервные копии — от 52,5 ₽/мес за 5 ГБ; снапшоты зависят от платформы.
• Работа по 152-ФЗ, есть реестр хостинг-провайдеров; закрывающие документы для юрлиц доступны.

Официальный сайт: ihc.ru

2. UFO.Hosting — космическая экосистема

Провайдер, который объединяет VPS/VDS, выделенные серверы, защиту сайтов, DNS-хостинг, аренду IP, лицензии ISPmanager и домены в одном личном кабинете. Для UFO.Hosting VPS и VDS — два названия одной услуги; разница только в терминологии.

Кейсы клиентов и кому подойдёт

• Интернет-магазин с трафиком 10–50 тыс. посетителей в день — VPS даёт стабильность при пиковых нагрузках и возможность настроить SSL, СУБД и кэширование.
• Веб-студии и агентства выбирают VPS/VDS ради изоляции ресурсов: проблемы одного клиента не влияют на соседние проекты.
• CRM-системы, лендинги с формами заявок и приложения с умеренной нагрузкой — удобно масштабировать RAM и CPU без переплаты за железо.
• Выделенные серверы берут под крупный e-commerce с интенсивным чтением/записью, проекты с жёсткими требованиями к безопасности и задачи с огромными объёмами дисков.

Что можно развернуть

VPS/VDS на Linux и Windows, панели Vesta, Hestia, CyberPanel, Virtualmin, ISPmanager. Можно поднять веб-серверы, базы данных, VPN, контейнеры, игровые серверы, DNS-зоны, а рядом заказать защиту сайта от DDoS L7 и внешнее FTP-хранилище.

Инфраструктура и экосистема

Серверы стоят в дата-центре IXcellerate в Москве, соответствующем Tier III. Сеть ноды VPS/VDS — 10 Гбит/с, распределяется между серверами по тарифу. Доступны обычные конфигурации на Intel Xeon, Hi-CPU на Ryzen и Storage-линейка с расширенным хранилищем.

Отзывы и репутация

Публичных агрегированных рейтингов в предоставленных источниках не указано. Провайдер позиционируется как экосистемный игрок с акцентом на удобное управление всеми услугами из одного кабинета.

Поддержка и каналы связи

Техподдержка 24/7 через онлайн-чат на сайте и тикет-систему в биллинге. Телефонная поддержка работает в будни с 9:00 до 18:00; Telegram не используется. Фактическое время ответа — не более 30 минут в любое время суток. Есть база знаний и блог.

Тарифы, ограничения и условия

• Минимальная конфигурация VPS/VDS Naos (Intel Xeon E5-2697A v4) — 1 vCore, 1 ГБ RAM, 25 ГБ NVMe — 605,85 ₽/мес.
• Типовая конфигурация Brachium (Intel Xeon E5-2697A v4) — 2 vCore, 4 ГБ RAM, 60 ГБ NVMe — 1025,85 ₽/мес.
• Скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, 12 месяцев — 15%.
• Тестовый период — до 3 дней на любой тариф VPS; требуется верификация аккаунта (email, телефон, KYC). На выделенные серверы — до 3 дней по договорённости.
• Трафик безлимитный с порогом 32 ТБ/мес; после превышения скорость ограничивается 100 Мбит/с.
• Root-доступ полный. На тарифах Naos и Haedus выбор ОС ограничен списком провайдера; на остальных можно ставить любую ОС.
• Бэкапы платные: ежедневные — 525 ₽/мес, еженедельные — 262,5 ₽/мес; снапшотов нет, есть услуга бэкапов.
• Работа по 152-ФЗ, сертификатов ФСТЭК нет; есть реестр хостинг-провайдеров. Для юрлиц — договор и ЭДО, постоплата недоступна.

Официальный сайт: ufo.hosting

3. SpaceWeb — посуточная тарификация

Один из старейших российских хостеров, у которого можно начать с виртуального хостинга, перейти на VPS/VDS с посуточной оплатой и докупать IP, SSL и защиту от DDoS. Удобен тем, кто хочет платить только за фактическое потребление ресурсов VPS.

Кейсы клиентов и кому подойдёт

• Лендинг, блог или сайт-визитка с небольшой посещаемостью — хватит виртуального хостинга с автоустановкой CMS.
• Интернет-магазин и корпоративный сайт на 1С-Битрикс — тарифы повышенной мощности с выделенными CPU и приоритетной поддержкой.
• Проект с непредсказуемой нагрузкой — VPS/VDS с посуточной тарификацией и изменением ресурсов «на лету».

Что можно развернуть

На хостинге — WordPress, Joomla, Drupal, 1С-Битрикс, OpenCart, MODx, Laravel, Django и другие CMS и фреймворки. Поддерживаются PHP 5.x–8.4, MySQL 8/5.7, PostgreSQL 14.4, Perl, Python, Ruby. На VPS/VDS — Ubuntu, Debian, CentOS, AlmaLinux, Rocky Linux, панели Hestia, FASTPANEL, ISPmanager, Docker.

Инфраструктура и экосистема

Дата-центры Tier III в Санкт-Петербурге, Москве и Амстердаме. Собственная SPA-панель управления, VNC-консоль, DNS-редактор, статистика, логи, бэкапы и снапшоты. На всех сайтах включена изоляция для защиты от вредоносного ПО и защита от DDoS L3-4; защиту L7 можно докупить от 290 ₽/мес.

Отзывы и репутация

На сайте публикуются отзывы клиентов: отмечают стабильную работу, быструю техподдержку и удобную панель. Некоторые пользователи работают с провайдером с 2016 года.

Поддержка и каналы связи

Email, телефон, онлайн-чат и ВКонтакте. Среднее время ответа: 1–2 минуты по телефону, в чате и ВКонтакте; до 60 минут по почте. Поддержка помогает с переносом проектов, диагностикой и администрированием серверов с ISPmanager.

Тарифы, ограничения и условия

• Виртуальный хостинг: тариф «Старт» — 1 ГБ NVMe SSD, 1 база данных, ∞ FTP и почтовых ящиков, 120 CP — 149 ₽/мес; «Взлёт» — 311 ₽/мес, «Ракета» — 530 ₽/мес, «Космос» — 755 ₽/мес.
• VPS/VDS: посуточная тарификация, параметры CPU/RAM/диска меняются «на лету»; конкретную стоимость конфигурации проверяйте в калькуляторе на сайте.
• Тестовый период: 14 дней на виртуальном хостинге и на VPS/VDS.
• Ежедневное резервное копирование включено на хостинге; резервные копии VPS — от 45 ₽/мес за 3 копии.
• Дополнительный IP — 130 ₽/мес, SSL GlobalSign — от 1 900 ₽/год, домен .RU — 179 ₽/год.
• Работа с юрлицами через договор оферты, безналичные платежи и ЭДО.

Официальный сайт: spaceweb.ru

4. PSB Hosting — зарубежные локации

Провайдер с фокусом на VPS в Европе и США: Amsterdam, Frankfurt, Helsinki, New York. Не предлагает виртуальный хостинг в привычном понимании, зато даёт полный root, /64 IPv6 на всех тарифах, неограниченные резервные копии и оплату криптовалютой.

Кейсы клиентов и кому подойдёт

• Небольшие интернет-магазины на WordPress или 1С-Битрикс, лендинги, корпоративные сайты и блоги.
• Проекты с Telegram-ботами, API-сервисами и другой автоматизацией.
• Команды, которым важны зарубежные локации и гибкие способы оплаты, включая криптовалюту.

Что можно развернуть

VPS под Linux, Windows или FreeBSD с предустановленным ПО: Bitrix, Django, Docker, FastPanel, HestiaCP, Keitaro, LAMP, Node, OpenVPN, Outline, Portainer, VestaCP, WireGuard, WordPress. Подходит под сайты, backend-приложения, VPN, корпоративные системы, базы данных и тестовые среды.

Инфраструктура и экосистема

Серверы размещены в дата-центрах euNetworks (Amsterdam), Frankfurt 1 Data Center, Digita (Helsinki) и Long Island Interconnect (New York). Оборудование — AMD и Intel с DDR5 и NVMe, RAID 10. Безлимитный трафик, порт ноды 10 Гбит/с, на VPS выделяется 300 Мбит/с. Полноценная панель управления DNS-записями доменов.

Отзывы и репутация

На сайте указаны рейтинги на независимых площадках: OtzovikMarketing.ru — 4,8, In-Scale.ru — 5,0, Aff1.ru — 5,0, 101Poisk.ru — 4,89. Провайдер позиционируется как решение для бизнеса, разработки и высоконагруженных проектов.

Поддержка и каналы связи

Поддержка работает круглосуточно через тикеты и Telegram; время ответа зависит от загрузки. Есть документация и API. Для B2B-клиентов предусмотрен менеджер.

Тарифы, ограничения и условия

• VPS: минимальный тариф на странице VPS — от 8 USD; есть High-CPU VPS на AMD Ryzen 7950X.
• Почасовая оплата доступна; скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, 12 месяцев — 15%.
• Бесплатного тестового периода нет.
• Безлимитный трафик, порт VPS — 300 Мбит/с; можно установить любую ОС; полный root-доступ.
• Бэкапы платные, снапшоты есть.
• IPv6-подсеть /64 на всех тарифах, неограниченное количество резервных копий.
• Не работает по 152-ФЗ, сертификатов ФСТЭК нет, в реестре отечественного ПО нет. Оплата картами РФ/СНГ/ЕС и криптовалютой.

Официальный сайт: psb.hosting

5. AdminVPS — VPS и хостинг в одном кабинете

Провайдер с виртуальным хостингом, VPS/VDS, выделенными серверами, доменами, SSL и дополнительными сервисами в одном аккаунте. В подборке он закрывает сценарий, когда проекту нужен обычный хостинг для сайта и отдельный VPS под приложение, базу данных или тестовую среду.

Кейсы клиентов и кому подойдёт

• Сайты на CMS и небольшие магазины, которые начинают с виртуального хостинга и постепенно переходят на VPS.
• Команды, которым нужны домены, SSL, хостинг и серверы в одном личном кабинете.
• Проекты, где важна российская площадка и возможность подобрать конфигурацию VPS под нагрузку.

Что можно развернуть

На виртуальном хостинге — сайты на популярных CMS и почту на домене. На VPS/VDS — Linux-серверы под сайты, backend, базы данных, тестовые окружения и сервисы с root-доступом. В экосистеме также есть домены, SSL-сертификаты, резервное хранилище, объектное хранилище и защита от DDoS.

Инфраструктура и экосистема

На странице VPS в России указано размещение в Москве, процессоры Intel Xeon Gold и AMD EPYC, NVMe-диски, тарифы с портом от 100 Мбит/с до 1 Гбит/с и включённым месячным трафиком. В меню также есть VPS в Германии, Нидерландах, Польше, Испании, Беларуси, Казахстане, Финляндии, Великобритании и Франции.

Отзывы и репутация

На странице VPS указана агрегированная оценка 4,9 и несколько сотен отзывов. Провайдер позиционируется как универсальная площадка для сайтов, серверов и сопутствующих услуг.

Поддержка и каналы связи

Поддержка работает круглосуточно через тикет-систему в личном кабинете. Отдел продаж доступен по телефону и через запрос на сайте.

Тарифы, ограничения и условия

• VPS/VDS в России: конфигуратор стартует от 500 ₽/мес; в готовых тарифах есть Lite с 1 CPU, 1 ГБ RAM и 15 ГБ NVMe.
• Виртуальный хостинг и CMS-хостинг доступны отдельными услугами.
• В тарифах VPS указаны месячные пакеты трафика; на младшем Lite — 1 ТБ и порт 100 Мбит/с.
• Бэкапы зависят от тарифа: для части тарифов платно, для части включены.
• Есть скидки за предоплату на 6, 12 и 24 месяца.
• На странице указано соответствие требованиям РФ по 152-ФЗ.

Официальный сайт: adminvps.ru

6. FirstVDS — готовые VDS/VPS-конфигурации

Провайдер с фокусом на виртуальные серверы: готовые VDS/VPS, отдельные линейки для высоких CPU-частот, storage-сценариев, GPU и Windows. В подборке это вариант для тех, кто выбирает именно VPS/VDS и сопутствующие услуги, а не классический shared-хостинг.

Кейсы клиентов и кому подойдёт

• Небольшие сайты и сервисы, которым нужен отдельный сервер вместо виртуального хостинга.
• Разработчики, которым важны готовые Linux-образы, SSH-доступ и быстрый запуск сервера.
• Проекты, где позже могут понадобиться Windows-серверы, storage-линейка или зарубежная локация.

Что можно развернуть

На VPS/VDS доступны Linux-дистрибутивы Debian, Ubuntu, FreeBSD, CentOS и Alma, платная Windows, панели ispmanager и дополнительные IP. В линейке есть VDS для Windows, VDS в Нидерландах и Алматы, storage-серверы, GPU-серверы и объектное хранилище S3.

Инфраструктура и экосистема

На сайте указаны дата-центры в России, Нидерландах и Казахстане. Для VDS в Москве доступны каналы до 100 Мбит/с с безлимитным трафиком или до 1 Гбит/с с пакетом 32 ТБ в месяц; для Амстердама и Казахстана условия отличаются.

Отзывы и репутация

FirstVDS работает как отдельный бренд виртуальных серверов и указывает награды отраслевой премии ЦОДы.рф. На сайте также опубликованы пользовательские отзывы и раздел базы знаний.

Поддержка и каналы связи

На сайте указан бесплатный круглосуточный телефон 8 800 775-38-37, база знаний и служба поддержки. Для серверов доступны дополнительные услуги администрирования и технического сопровождения.

Тарифы, ограничения и условия

• Готовые VDS/VPS — от 249 ₽/мес; запуск сервера заявлен за несколько минут.
• Бесплатно с сервером: 1 выделенный IP-адрес, ispmanager 6 lite на 1 месяц, установка ОС на выбор и полный SSH-доступ.
• Тестовый период предоставляется по согласованию.
• Windows тарифицируется отдельно: на странице указано 680 ₽/мес за 1 ядро, недоступно для VDS в Амстердаме и Алматы.
• Для VDS в Москве возможен канал до 100 Мбит/с с безлимитным трафиком или до 1 Гбит/с с лимитом 32 ТБ/мес.
• Дополнительные услуги: бэкап, мониторинг, BitNinja, DDoS-защита, домены, SSL и DNS-хостинг.

Официальный сайт: firstvds.ru

Сравнение по ключевым критериям

Ниже — сводка по ценам, лимитам и условиям, которые чаще всего влияют на выбор.

• Минимальный виртуальный хостинг: ИХЦ — от 123 ₽/мес (при оплате за год), SpaceWeb — от 149 ₽/мес; AdminVPS предлагает виртуальный/CMS-хостинг отдельной линейкой; UFO.Hosting, PSB Hosting и FirstVDS в подборке рассматриваются прежде всего как VPS/VDS-провайдеры.
• Минимальный VPS/VDS: ИХЦ — от 317 ₽/мес (за год), UFO.Hosting — 605,85 ₽/мес, SpaceWeb — цена в калькуляторе с посуточной тарификацией, PSB Hosting — от 8 USD, AdminVPS — от 500 ₽/мес в конфигураторе, FirstVDS — от 249 ₽/мес.
• Виртуализация: ИХЦ — KVM/Virtuozzo на выбор; UFO.Hosting — Intel Xeon и Ryzen линейки; SpaceWeb — собственная облачная платформа; PSB Hosting — KVM; AdminVPS и FirstVDS предлагают готовые VPS/VDS-линейки с Linux-образами.
• Трафик: ИХЦ и PSB Hosting — безлимитный (у ИХЦ снижение скорости после 20 ТБ); UFO.Hosting — безлимитный с порогом 32 ТБ; SpaceWeb — параметры уточняйте в конфигураторе; AdminVPS указывает месячные пакеты трафика; FirstVDS разделяет безлимитный канал 100 Мбит/с и пакеты трафика на более быстрых каналах.
• Root и ОС: полный root у всех шести; ИХЦ и PSB Hosting позволяют загружать собственные ISO; UFO.Hosting ограничивает список ОС на младших тарифах; у FirstVDS Windows и панели управления идут как платные дополнения.
• Бэкапы: SpaceWeb включает ежедневные бэкапы на хостинге; ИХЦ и PSB Hosting — платно; UFO.Hosting — платная услуга резервного копирования; AdminVPS и FirstVDS предлагают бэкапы как тарифную или дополнительную опцию.
• Тестовый период: SpaceWeb — 14 дней на хостинге и VPS; ИХЦ — 7 дней хостинг / 3 дня VPS; UFO.Hosting — до 3 дней VPS; FirstVDS — по согласованию; PSB Hosting — нет; условия AdminVPS зависят от акции и выбранной услуги.
• Дата-центры: ИХЦ — Москва + Амстердам; UFO.Hosting — Москва; SpaceWeb — Москва, Санкт-Петербург, Амстердам; PSB Hosting — Amsterdam, Frankfurt, Helsinki, New York; AdminVPS предлагает VPS в разных странах; FirstVDS указывает Россию, Нидерланды и Казахстан.
• Юридика: ИХЦ, UFO.Hosting, SpaceWeb и AdminVPS работают с российской юридической рамкой; PSB Hosting ориентирован на зарубежные локации; для FirstVDS условия документов и лицензий зависят от выбранных услуг.

Вывод

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

Если приоритет — российская юридика и плавный рост от хостинга до железа, смотрите на Интернет Хостинг Центр или SpaceWeb. Если важна экосистема из доменов, защиты и серверов в одном кабинете — UFO.Hosting или AdminVPS. Если нужен недорогой вход именно в VPS/VDS — можно сравнить FirstVDS с базовыми тарифами других участников. Если нужны зарубежные локации и гибкая оплата — PSB Hosting. Перед покупкой всегда берите тестовый период и проверяйте реальную производительность под вашей нагрузкой.

Что такое NixOS

NixOS — это дистрибутив Linux, в котором всё системное окружение описывается декларативно на языке Nix и воспроизводится из одного конфигурационного файла. Каждая сборка помещает зависимости в /nix/store, что даёт атомарные откаты и воспроизводимость, но при этом легко разрастается размер.

Одна из удобных фич — команда nixos-rebuild build-vm: она превращает конфигурацию в виртуальную машину. Но иногда нужен не «тонкий» образ, привязанный к хосту, а самодостаточный ISO, который можно записать на флешку или загрузить в облаке.

• Базовый NixOS ISO занимает 458 МБ: 416 МБ — squashfs с пользовательским окружением, 26 МБ — initrd, 13 МБ — ядро.
• Главные «тяжеловесы» внутри образа: модули ядра (144 МБ), Python 3 (128 МБ), systemd (60 МБ), Perl (56 МБ), GRUB (около 62 МБ).
• Отключение Nix, документации, SSH, firewall и лишних зависимостей сокращает ISO до 197 МБ.
• Замена Perl-активации на экспериментальные system.etc.overlay и services.userborn даёт финальный размер около 183 МБ.
• Это игрушечный эксперимент: для десктопа и сервера такие отсечения небезопасны, но полезны как источник идей.

От VM к ISO за несколько строк

Минимальная виртуальная машина на NixOS собирается из файла примерно такого вида:

Запуск: $(nix-build basic-vm.nix --attr vm --no-out-link)/bin/run-nixos-vm. При этом /nix/store монтируется с хоста, поэтому VM «тонкая». Для независимого ISO импортируем модуль iso-image.nix и собираем атрибут isoImage:

ISO собирается, загружается в QEMU, но размер сразу бросается в глаза.

458 МБ — из чего они сложились

Автор примонтировал полученный ISO и посмотрел распределение места. Вот ключевые цифры:

• 416 МБ — сжатый nix-store.squashfs с пользовательским окружением.
• 26 МБ — начальная загрузочная среда initrd.
• 13 МБ — ядро Linux.
• 3 МБ — загрузчик isolinux.

При распаковке squashfs картина ещё интереснее:

• 144 МБ — модули ядра (linux-6.18.35-modules).
• 128 МБ — Python 3.13.
• 60 МБ — systemd.
• 56 МБ — Perl.
• ~62 МБ суммарно — две копии GRUB (UEFI + BIOS).

Поскольку ISO собирается локально, все пакеты из него есть и в хостовом /nix/store. Это позволяет использовать nix why-depends, чтобы найти, кто тащит каждую зависимость.

Отключаем Nix, документацию и лишние сервисы

Первый очевидный шаг — отказаться от демона Nix внутри ISO, ведь мы строим автономный образ, а не полноценную NixOS для работы с пакетами. Достаточно двух опций:

Результат: 384 МБ. Экономия скромная, потому что часть зависимостей Nix всё ещё тянется через сервис register-nix-paths. Он регистрирует содержимое хранилища ISO при загрузке — но Nix-то мы уже убрали. Отключаем и его:

Теперь ISO уменьшился до 360 МБ, а зависимость от Boost исчезла полностью.

SSH: модуль без выключателя

Следующий кандидат на удаление — OpenSSH-клиент. Проблема в том, что модуль programs/ssh.nix добавляет его в environment.corePackages, а отдельного переключателя programs.ssh.enable нет.

Попытка полностью исключить модуль через disabledModules ломает другие модули, например Plasma 6, которые ожидают существования опций programs.ssh. Выход — подменить опцию «пустышкой», не затрагивающей реальную конфигурацию:

Параллельно автор убрал firewall, documentation.man.enable и принудительно очистил environment.defaultPackages.

GRUB: зачем две копии загрузчика

ISO-пресет NixOS включает сразу и UEFI-, и BIOS-версии GRUB — отсюда около 62 МБ. Чёткого флага для отключения одной из них нет, поэтому автор пошёл грубым путём: сбросил system.extraDependencies и environment.systemPackages, оставив только environment.corePackages, чтобы shell хотя бы стартовал.

Ядерные модули: четверть образа

Модули ядра весили 144 МБ — больше, чем весь Alpine ISO. NixOS не предоставляет удобного способа ограничить их набор для runtime, поэтому автор просто удалил папку модулей из системы после сборки:

Это полностью отключает динамическую загрузку модулей. Если что-то нужно — оно должно оказаться в boot.initrd.kernelModules или availableKernelModules. После этого образ уменьшился до 197 МБ.

Perl: заменяем активацию системы

Perl в образе нужен только для скриптов активации: настройки /etc и создания пользователей. В nixpkgs уже есть экспериментальные замены — system.etc.overlay и нативный менеджер пользователей userborn.

Оба механизма помечены как экспериментальные, но в контексте «самодельного минимального ISO» это уже не самая безумная идея. Финальный размер: 183 МБ.

Что получилось и стоит ли повторять

За несколько итераций образ сократился с 458 МБ до 183 МБ — почти в 2,5 раза. При этом система всё ещё загружается, автор смог залогиниться под root, правда разрешение экрана перестало переключаться.

Важно: конфигурация выше — это не рецепт для продакшена. Отсутствие Nix, SSH, модулей ядра и Perl-активации ломает массу сценариев. Результат интересен скорее как демонстрация границ NixOS, чем как готовый шаблон.

Автор сама отмечает: для рабочего десктопа или сервера так делать не стоит. Но если вам нужен крошечный live-образ под единичный эксперимент — здесь много идей, с которых можно начать.

Выводы

Эксперимент показывает, что NixOS позволяет не только собирать сложные системы, но и жёстко урезать их — иногда в ущерб удобству. Главный инструмент здесь не волшебная опция, а последовательный анализ: смотреть, что занимает место, находить виновника через nix why-depends и решать, готовы ли вы от него отказаться.

«At some point I just kept going because I got curious.»

Если захотите повторить — начните с отключения Nix и документации, а дальше решайте, какие модули и пакеты действительно нужны в вашем live-образе. Исходный материал — в блоге автора: I can haz smoller NixOS ISOs?.

• Apache Airflow — мощный оркестратор для сложных Python-конвейеров, но требует инфраструктуры и DevOps-культуры.
• n8n — визуальный конструктор с открытым исходным кодом: удобен для средних нагрузок, можно бесплатно хостить на своём сервере.
• Make (бывший Integromat) — облачный визуальный автоматизатор для бизнес-команд, дешевле Zapier, но тарифицирует каждый шаг сценария.
• Для российских команд критичны: возможность self-hosting, стоимость инфраструктуры и риски доступности зарубежного SaaS.
• Нет универсального победителя — выбор зависит от размера команды, сложности логики и требований к контролю над данными.

API-оркестрация — это не просто «позвонить в API», а построить надёжный конвейер: вызвать один сервис, передать результат в другой, обработать ошибку, повторить при сбое и записать лог. Иногда это пара запросов в час, а иногда — десятки тысяч операций в день. Отсюда и разница в подходах: где-то важна гибкость кода, где-то — скорость запуска, а где-то — цена за операцию.

Apache Airflow: тяжёлый артиллерист

Airflow появился в Airbnb и за десять лет стал стандартом для data-пайплайнов. Его используют Netflix, Spotify и Uber — там, где нужно управлять сотнями зависимых задач с контролем SLA и аудитом. Главная идея: вы описываете workflow как Python-код в виде направленного ациклического графа (DAG), а scheduler отвечает за порядок, ретраи и мониторинг.

Зачем выбирать Airflow

• Сложная логика: ветвления, условия, ретраи, расписания через cron.
• Полный контроль над кодом: любые библиотеки Python, кастомные операторы, unit-тесты.
• Зрелая экосистема: SLA-мониторинг, audit trail, интеграция с Kubernetes и Spark.
• Open Source: можно развернуть на своей инфраструктуре, в том числе на российских облаках.

Честный взгляд на минусы

• Высокий порог входа: нужно разворачивать БД, Redis, воркеры и веб-интерфейс.
• Минимальный кластер на VPS обходится примерно в €50/месяц без учёта времени администратора.
• При 50+ задачах DAG превращается в большой Python-файл, который сложно поддерживать без дисциплины.
• Коммуникация между задачами через XCom требует внимания: забыли очистить — получили memory leak.

Пример простого DAG, который забирает пользователя, его посты и считает количество:

Airflow хорош, когда у вас уже есть data-команда, Kubernetes и понимание, зачем нужны DAG. Для стартапа из трёх человек это, скорее, оверинжиниринг.

n8n: визуальный middle ground

n8n занимает промежуточную нишу между кодом и no-code. Это node-based редактор: вы перетаскиваете блоки, соединяете их стрелками, а логика — в JavaScript-функциях и условиях. Главное преимущество: n8n open-source, его можно поднять на собственном сервере, и за это не придётся платить пошагово.

Зачем выбирать n8n

• Быстрый старт: визуальный конструктор позволяет собрать пайплайн за час, а не день.
• Self-hosting: контейнер на VPS за $5–10/мес может обрабатывать тысячи запусков в день.
• Гибридный подход: 90 % задач решается мышкой, сложную трансформацию можно написать на JS.
• Прозрачная цена облака: плата за выполнение workflow, а не за каждый модуль.

Ограничения

• При сотнях задач в одном workflow визуальная схема становится громоздкой.
• Нативные узлы покрывают не всё: экзотический API придётся звать через HTTP Request.
• Self-hosted версия требует обновлений и бэкапов — это всё ещё инфраструктура, хоть и простая.
• Для России: облако n8n — европейский сервис, но self-hosted можно развернуть на Selectel, Yandex Cloud или любом другом провайдере.

Пример JSON-экспорта workflow, который забирает пользователей, преобразует данные и пишет в PostgreSQL:

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

Make: бизнес-автоматизация по шагам

Make (ранее Integromat) — это облачный визуальный автоматизатор для бизнес-команд. Его сценарии собираются из модулей: триггер → действие → фильтр → маршрутизатор. По сравнению с Zapier у Make глубже логика, а цена ниже, но он остаётся полностью SaaS-решением.

Зачем выбирать Make

• Быстрая интеграция с популярными сервисами: Google Sheets, Slack, Telegram, CRM, email-рассылки.
• Визуальные маршрутизаторы (routers), итераторы и агрегаторы позволяют строить ветвления без кода.
• Низкий порог входа для маркетологов, менеджеров продукта и операционистов.
• План Core стоит от $9/мес за 10 000 операций — дешевле многих конкурентов.

Подводные камни

• Тарификация по операциям: каждый модуль в сценарии считается отдельно. Десять шагов × тысяча запусков = 10 000 операций.
• Нельзя self-host: данные обрабатываются на серверах Make, что может быть проблемой для чувствительных данных.
• Для России: сервис работает как зарубежный SaaS, есть риски доступности и оплаты.
• Сложные сценарии сложнее отлаживать: приходится кликать по модулям в истории выполнений.

Типичный сценарий в Make выглядит так: вебхук из формы → проверка дубликата в Google Sheets → запись в CRM → отправка уведомления в Telegram. Всё это строится мышкой, но стоит добавить кастомную логику — и придётся использовать HTTP-модуль или встроенные функции.

Сравнение в цифрах

Сводная таблица по ключевым параметрам. Вместо абстрактных «плюсов» смотрите на конкретные ограничения:

• Airflow — код Python, self-hosted, сложность высокая, стоимость от €50/мес + администрирование, лучше для data-платформ.
• n8n — визуальный + JS, self-hosted или cloud, средняя сложность, self-hosted от $5–10/мес, лучше для средних нагрузок и гибридных команд.
• Make — визуальный no-code, только cloud, низкая сложность входа, от $9/мес за 10K операций, лучше для бизнес-автоматизации.
• Модель оплаты: Airflow — инфраструктура; n8n — инфраструктура или executions в облаке; Make — операции (каждый модуль отдельно).
• Контроль данных: максимальный у Airflow и self-hosted n8n; минимальный у Make как SaaS.

Российская специфика:
Для команд в РФ критичен self-hosted путь: Airflow и n8n можно развернуть на отечественных VPS или в Yandex Cloud/Selectel. Make, Zapier и другие зарубежные SaaS не дают гарантий доступности и оплаты. Если данные не могут покидать страну — выбор очевиден.

Как выбрать инструмент

FAQ

Выводы

Нет единого лучшего инструмента для API-оркестрации — есть подходящий под ваши ограничения. Airflow остаётся выбором зрелых data-команд, которым нужна масштабируемость и контроль. n8n закрывает большинство задач среднего уровня и даёт свободу self-hosting. Make — удобный SaaS для бизнес-автоматизации, но с привязкой к облаку и пошаговой тарификацией.

Хороший оркестратор не тот, у кого больше иконок в интерфейсе, а тот, чьи ошибки вы сможете отладить в два часа ночи.

Источник: материал основан на публикации «Airflow vs n8n vs Make for API orchestration» автора Raizan в DEV Community — dev.to/chasebot/airflow-vs-n8n-vs-make-for-api-orchestration-1lb8. Раздел про Make и сравнительный анализ дополнены редакционным контекстом.

Выход — поднять собственное S3-совместимое хранилище на том же VPS, где крутится staging. MinIO реализует API Amazon S3, понимает те же SDK и presigned URL, но стоит ровно столько, сколько стоит диск сервера. Один и тот же код приложения работает и с MinIO на dev, и с R2 в проде — меняются только переменные окружения.

Что такое MinIO и почему он подходит для staging

MinIO — это open-source сервер объектного хранилища, написанный на Go. Он поддерживает основные операции S3: бакеты, объекты, multipart upload, versioning, lifecycle, шифрование SSE-S3, CORS и IAM-политики. Для приложения он выглядит как обычный S3-эндпоинт, поэтому подходит почти любой SDK: AWS SDK, boto3, minio-js, aws-sdk-go.

На staging важно не столько масштабирование, сколько идентичность поведения продакшена. Если в проде R2 или S3, а в staging — локальная файловая система, вы тестируете не тот код. MinIO закрывает этот разрыв: тот же PutObjectCommand, те же presigned URL, те же ошибки SignatureDoesNotMatch.

• MinIO — полноценный S3-совместимый сервер, который можно развернуть в Docker на VPS за 10–15 минут.
• Для staging это экономия на хранении тестовых файлов и единый код с продакшеном.
• HTTPS и домен лучше отдавать reverse proxy — Traefik или NGINX — с Let’s Encrypt.
• Presigned URL позволяют загружать и скачивать файлы напрямую из браузера, не проксируя байты через бэкенд.
• Root-ключи MinIO нельзя отдавать приложению: создавайте отдельного пользователя с IAM-политикой только на нужный бакет.

Архитектура: прод против staging

В продакшене обычно используется управляемое хранилище: AWS S3, Cloudflare R2, Yandex Object Storage, Hetzner Object Storage. Там работают репликация, резервное копирование и чужой дежурный. В staging достаточно одного MinIO-контейнера на сервере с регулярным зеркалированием в дешёвое холодное хранилище.

Приложение не знает, с кем оно говорит: код инициализации клиента одинаков. Разница только в переменных окружения: эндпоинте, регионе, ключах и флаге forcePathStyle, который нужен большинству S3-совместимых сервисов, включая MinIO и R2.

Важно: виртуальный хостинг bucket.example.com в MinIO работает, но на staging проще включить path-style и не мучиться с DNS-записями под каждый бакет.

Что понадобится

• VPS с Linux, публичным IP и открытыми портами 80/443.
• Два A-записи: minio-staging.example.com и minio-console.example.com.
• Docker и Docker Compose v2.
• Reverse proxy с TLS — в примере Traefik v2 + Let’s Encrypt.
• Около 10 ГБ свободного места под тестовые данные.

Разворачиваем MinIO в Docker Compose

Минимальный docker-compose.staging.yml заводит один контейнер, внешнюю сеть для Traefik и именованный том для данных.

Два параметра критичны для presigned URL. MINIO_SERVER_URL говорит серверу, на каком публичном домене подписывать ссылки. Без него ссылка будет подписана для http://minio:9000 и браузер отклонит подпись. MINIO_BROWSER_REDIRECT_URL нужен для корректных редиректов веб-консоли.

Прокидываем HTTPS через Traefik

Добавляем лейблы к сервису minio, чтобы Traefik маршрутизировал API и консоль на разные порты и автоматически выпускал сертификаты.

Проверяем здоровье сервера с локальной машины: curl -I https://minio-staging.example.com/minio/health/live должен вернуть HTTP 200.

Cloudflare: для поддомена с API лучше выключить оранжевое облако. Бесплатный тариф Cloudflare обрезает тело запроса на 100 МБ и может убирать S3-заголовки, из-за чего ломается подпись.

Бакеты, политики и отдельный пользователь для приложения

После запуска создаём бакет и отдельного IAM-пользователя. Делать это root-ключами приложения — плохая идея: root может удалить всё.

Теперь создаём пользователя staging-app и IAM-политику, ограничивающую права только этим бакетом.

Логин staging-app и его секрет — это и есть S3_ACCESS_KEY и S3_SECRET_KEY для приложения.

Код приложения не меняется

Пример на AWS SDK v3 для Node.js. Обратите внимание на forcePathStyle: true: без него SDK попытается обратиться к bucket.minio-staging.example.com, и запрос уйдёт в никуда.

Переменные для staging:

Для продакшена — только другой набор значений, код идентичен.

Presigned URL: загрузка и скачивание без проксирования

Presigned URL — это обычный HTTPS URL с короткой подписью в query string. Кто угодно может выполнить ровно то действие, на которое выдана подпись: PUT для загрузки или GET для скачивания. Бэкенд проверяет права, подписывает URL и отдаёт клиенту — сам файл идёт напрямую в MinIO.

Загрузка из браузера

Важный подводный камень: Content-Type, который браузер отправляет при PUT, должен точно совпадать с тем, что было передано в PutObjectCommand. Иначе MinIO вернёт SignatureDoesNotMatch.

Скачивание приватных файлов

Почему это лучше проксирования: при прямой загрузке через ваше API все байты проходят через приложение, съедая CPU, RAM и пропускную способность. С presigned URL трафик идёт между клиентом и MinIO — бэкенд только подписывает ссылку.

CORS, lifecycle и безопасность

Несколько команд, которые стоит выполнить сразу после создания бакета.

CORS для браузерных загрузок

Автоудаление старых тестовых файлов

Шифрование данных в покое

И ещё раз: root-ключи храните в менеджере секретов и используйте только для mc admin. Консоль MinIO, если она доступна из интернета, закрывайте IP-allowlist или базовой авторизацией на уровне Traefik.

Бэкапы и мониторинг

Staging не должен хранить что-то ценное, но периодическое зеркалирование в дешёвое холодное хранилище спасает от случайного удаления. Команда mc mirror синхронизирует бакет в Backblaze B2, Yandex Object Storage или другой S3-совместимый бэкенд.

Для метрик MinIO отдаёт Prometheus-экспортёр по пути /minio/v2/metrics/cluster. В Grafana можно импортировать дашборд ID 13502 и сразу видеть занятое место, RPS, задержки и ошибки.

Типичные проблемы

• SignatureDoesNotMatch при PUT — браузер отправил Content-Type, отличный от подписанного. Проверьте заголовок PUT.
• Подписанная ссылка работает локально, но не в браузере — не задан MINIO_SERVER_URL. Ссылка подписана для внутреннего http://minio:9000.
• 403 после Cloudflare — бесплатный тариф Cloudflare модифицирует заголовки. Переведите A-запись в режим DNS-only.
• CORS preflight failed — на бакете не настроены CORS-правила.
• Консоль редиректит на http://minio:9001 — не задан MINIO_BROWSER_REDIRECT_URL.

Выводы

Self-hosted MinIO на staging — это не попытка заменить облако, а способ сделать тестовую среду дешевле и ближе к продакшену. Тот же API, те же SDK, те же presigned URL, но без счетов за хранение битых файлов и ночных сбросов базы.

Ключевые моменты, которые стоит запомнить: всегда указывайте MINIO_SERVER_URL для корректных подписей, не используйте root-ключи в приложении, включайте path-style на staging и настраивайте lifecycle, чтобы мусор не копился.

Самое дорогое в staging — не железо, а различия в кодовых путях между dev и prod. MinIO помогает убрать одну из этих разниц почти бесплатно.

Источник: freeCodeCamp — How to Self-Host an S3-Compatible Object Store with MinIO on Your Staging Server.

GitLab опубликовала отчёт на основе опроса более чем 1500 разработчиков и технологических лидеров. 60% заявили, что ROI инструментов ИИ-кодирования уже превзошёл ожидания. Однако 80% организаций внедрили ИИ быстрее, чем выработали политики управления, а 82% опасаются, что ИИ-код порождает новый технический долг.

• 60% считают ROI ИИ-кодирования выше ожиданий.
• 78% команд пишут и коммитят код быстрее.
• Только 21% видят продуктивность за пределами генерации кода.
• 85% считают, что следующий этап — управление ИИ-кодом, а не его генерация.
• Agentic infrastructure состоит из четырёх слоёв: исполнение, контекст, управление и оркестрация.

Проблема в том, что современная инфраструктура создана под человеческую скорость и подотчётность. Git-бекенды, CI/CD, системы деплоя и governance-фреймворки не рассчитаны на миллионы сессий агентов. Это ведёт к деградации надёжности платформ, росту уязвимостей и перерасходу токенов.

Четыре слоя agentic infrastructure

1. Исполнение в машинном масштабе

Git-бекенды, пайплайны CI/CD и системы деплоя проектировались под темпы человеческой работы. В эпоху агентов они должны выдерживать миллионы сессий без сбоев. Когда инцидент случается в продакшене, путь от симптома к причине должен занимать минуты, а не дни.

2. Контекст, который путешествует с кодом

Агент полезен ровно настолько, насколько полный контекст ему доступен. Контекстный граф, связывающий код, задачи, пайплайны, security-фидбек и продакшен-сигналы, позволяет агентам действовать осмысленно и снижает риск «искусственной уверенности».

Агент может быть только таким хорошим, какой контекст и семантика ему предоставлены.

3. Управление, встроенное в процесс

Действия агентов должны быть привязаны к идентичности, зафиксированы в логах и проверяемы. Низкорисковые изменения проходят быстро, высокорисковые — попадают на ревью. Для компаний вроде Mercedes-Benz, работающих под автомобильными стандартами, это не опция, а требование регуляторов.

4. Оркестрация

Исполнение, контекст и управление работают только в том случае, если ими координирует единый слой. Оркестратор определяет, какие агенты запускаются, в каком порядке, и как обрабатываются ошибки и передачи между этапами. Без него agentic infrastructure остаётся набором разрозненных возможностей.

Часто задаваемые вопросы

Выводы

Скорость и контроль перестают быть компромиссом, если управление встроено в платформу. Тогда трассируемость становится преимуществом, а контекст — институциональной памятью. Кодовая база перестаёт накапливать невидимый риск и начинает работать надёжнее с ростом нагрузки.

Источник: The New Stack — Agentic Infrastructure & AI Governance.

Компания incident.io, которая делает платформу для управления инцидентами и дежурствами, опубликовала разбор того, как её команда измеряет надёжность продукта On-call. Главный тезис: мерять нужно не то, что контролируешь, а то, что чувствует клиент.

incident.io сводит надёжность on-call к двум вещам: приём алертов и доставка уведомлений дежурным.

Вместо uptime API они меряют «хорошие минуты»: долю времени, когда ошибка приёма алертов ниже 10%.

За сбои сторонних провайдеров отвечает сам сервис: active-active redundancy для SMS/звонков.

Пользовательские задержки в escalation-цепочках вычитаются из общей задержки, чтобы измерять реальное время обработки.

Цель SLO — 99,99% в месяц для приёма алертов и для задержки уведомлений менее 5 минут.

Две метрики, которые на самом деле важны

У on-call продукта много функций: расписания дежурств, запросы замены, escalation-цепочки. Но с точки зрения надёжности incident.io оставляет только две критические операции: приём алертов и своевременная доставка уведомлений.

Для них выбраны два SLI — индикатора уровня сервиса: доступность приёма алертов и доля уведомлений, доставленных быстрее 5 минут. Внутренний SLO для обоих — 99,99% в месяц.

Приём алертов: измеряйте «хорошие минуты»

Классический SLI для HTTP API — доля ответов без ошибок:

Проблема в том, что эта метрика не видит ситуаций, когда запрос не дошёл до приложения. Например, если load balancer неправильно маршрутизирует трафик, application-метрики покажут ноль ошибок — просто потому, что запросов не было.

incident.io наблюдает трафик на уровне GCP load balancer — ближе к клиенту, чем application layer. Но и здесь есть шум: кратковременные сетевые блики, которые самолечатся за секунды. Чтобы не гоняться за каждым пиком, они меряют не запросы, а минуты:

Месяц делится на минуты. Минутка считается «хорошей», если доля ошибок в ней меньше 10%. Такой подход мотивирует и клиентов строить отказоустойчивую отправку алертов — с retries и backoff.

Третьи стороны: «не наша вина» не работает

Со стороны уведомлений вопрос сложнее: когда останавливать таймер? Простой ответ — когда уведомление передано провайдеру вроде Twilio или APNs. Если провайдер упал, разве это вина сервиса?

incident.io считает, что вина не важна — важен результат. Для SMS и звонков они используют двух провайдеров active-active: если один не справляется, срабатывает другой. Этот пробел они закрыли после инцидента в октябре 2025 года, когда единственный telecom-провайдер попал под AWS-аутедж.

Для push-уведомлений на iOS есть только один APNs, поэтому полную redundancy не построишь. Выход — подталкивать пользователей настроить несколько каналов: push, SMS и звонок одновременно. Так уведомление считается доставленным, когда его подтвердил хотя бы один провайдер.

Пользовательские задержки: как мерить то, что спрятано

Продукт позволяет гибко настраивать escalation. Например: сначала push и SMS, через 2 минуты — звонок. Если мерить время от алерта до звонка наивно, получится ложная задержка в те самые 2 минуты.

incident.io вычитает все намеренные задержки из общего времени:

Это означает: если звонок должен был прийти через 2 минуты, а пришёл через 7, — реальная задержка 5 минут, а не 7. «Это сложно мерить» не проходит краснолицый тест: компания сама рекомендует многоуровневые уведомления, поэтому должна нести ответственность и за их надёжность.

А что в России?

У нас типичная картина: Prometheus + Alertmanager шлют алерты в Telegram-бот или корпоративный мессенджер. Часто дежурство сводится к «если бот молчит — значит, всё нормально». Но мало кто меряет, доходит ли уведомление до человека, а не просто уходит ли HTTP-запрос.

Из статьи incident.io можно вынести три практических шага для российских команд:

1. Меряйте доставку уведомлений, а не только отправку. Если дежурный не подтвердил получение — это инцидент для мониторинга.
2. Стройте redundancy каналов. Telegram, SMS через провайдера, звонок — минимум два независимых пути.
3. Учитывайте настроенные задержки в SLO. Иначе вы будете наказывать себя за собственные best practices.

Ещё один момент: российские облачные провайдеры и telecom-операторы тоже падают. Поэтому active-active между двумя SMS-провайдерами или fallback на звонок — не перестраховка, а норма.

Выводы

Подход incident.io — хороший пример того, как техническая метрика перестраивается в метрику клиентского опыта. Вместо «наш API работает» — «алерт дошёл и дежурный его увидел вовремя». Вместо «провайдер виноват» — «у нас есть fallback». Вместо «это сложно мерить» — «мы меряем честно».

Customer outcomes matter more than any individual piece of the machine.

Источник: incident.io — Customers over control: how we measure On-call reliability.

Если у вас есть дежурства, пересмотрите свои SLO: они меряют опыт пользователя или просто красивые цифры для дашборда?

Service Topology — это не статическая схема из вики, а динамическая карта связей между сервисами. Она обновляется по мере того, как меняется трафик, появляются новые зависимости или старые исчезают. Карта показывает не только «кто с кем говорит», но и контекст: уровень доступности, бизнес-домен, владельца и текущее состояние здоровья.

Если тема микросервисов для вас новая, начните с базового разбора «Что такое микросервисы», а если выбираете архитектуру для проекта — сравните варианты в материале «Монолит или микросервисы». Авторский разбор внутреннего устройства Netflix читайте в статье «Разработчик изучал систему рекомендаций Netflix месяцами».

• Netflix объединила три источника данных: eBPF-сетевые потоки, IPC-метрики и распределённые трейсы.
• Каждый источник строит свой граф; общий вид получается параллельным слиянием слоёв.
• Карта обновляется почти в реальном времени и отвечает на запросы быстрее секунды.
• Инженеры используют её для поиска причин сбоев, оценки зоны поражения и планирования изменений.
• Подход можно перенести в любую распределённую систему, где нужно понимать зависимости.

Почему обычной наблюдаемости мало

Традиционные инструменты наблюдаемости показывают фрагменты картины. Метрики говорят, что что-то болит. Логи рассказывают, что конкретно произошло в одном сервисе. Трейсы прослеживают путь отдельного запроса. Но ни один из этих сигналов не показывает полную топологию зависимостей — ту самую основу, на которой держится распределённая архитектуры.

Инженеру в три часа ночи приходится мысленно склеивать данные из разных источников. Это медленно, чревато ошибками и добавляет стресса. Netflix проанализировала тысячи обращений в поддержку за четыре года и увидела повторяющиеся вопросы: кто мои upstream и downstream, что упадёт вместе со мной, почему сервис отображается в панели мониторинга как Unknown (неизвестный сервис). Ответы на них требовали единого представления о зависимостях.

Три источника данных Service Topology

Главный вывод Netflix: ни один источник не рассказывает всю историю. Поэтому система строит три независимых графа и объединяет их по запросу.

Сетевые потоки eBPF

На сетевом уровне Netflix собирает потоки ядра через eBPF. Это даёт полноту: сюда попадают все соединения, независимо от того, инструментирован сервис или нет. Слой показывает связи между кластерами и приложениями такими, какими они есть на самом деле. Недостаток — не хватает прикладного контекста: видно, что сервис А достучался до IP-адреса сервиса Б, но неизвестно, какой конкретно endpoint вызывался.

IPC-метрики

На прикладном уровне собираются метрики межпроцессного взаимодействия. Когда сервис обращается к другому через gRPC, GraphQL или REST, он фиксирует endpoint, ошибки, задержки и протокол. Этот слой даёт детали, которых нет у сетевого: какой именно путь вызывается и с какой вероятностью ошибки. Ограничение очевидно: если сервис не отправляет метрики, его вызовов здесь не будет.

Распределённые трейсы

Третий слой — трейсинг запросов от начала до конца. Он показывает не «может ли сервис А позвонить сервису Б», а «звонил ли он в рамках этого конкретного пользовательского запроса». Это помогает увидеть поведение во время выполнения, ветвления, фича-флаги и редкие пути. Поскольку трейсы собирают выборочно, редкие сценарии могут не попасть в агрегированный вид.

Когда инженер запрашивает общую картину, система обходит все три графа параллельно и сливает результаты. Сеть обеспечивает полноту, IPC добавляет контекст, трейсы показывают реальное поведение. Каждый источник компенсирует слабости остальных.

Как собирают Service Topology

Приём и обработка потоков

За кулисами работает конвейер, который держит миллионы событий в секунду. Потоки сетевых логов читаются из Kafka в нескольких регионах AWS. Для обработки Netflix использует Apache Pekko Streams — форк Akka, который разбивает нагрузку по группам автомасштабирования и сам управляет обратным давлением.

Восстановление прямых связей

Сетевой лог показывает отдельные сетевые прыжки: например, приложение → балансировщик → приложение или приложение → NAT-шлюз → приложение. Чтобы получить настоящие связи, запускается трёхступенчатая агрегация. Первая стадия забирает сырые записи, вторая распознаёт посредников и восстанавливает прямые пути между приложениями, третья финализирует агрегаты и добавляет статус здоровья. Такой градуированный подход раскидывает нагрузку и не даёт горячим узлам уронить весь конвейер.

Готовая топология хранится в графовой базе Netflix — абстракции поверх распределённого хранилища «ключ — значение». Она заточена под быстрый обход графа в несколько хопов. Поверх базы — gRPC-API с фильтрами по уровню доступности и домену, постраничным выводом больших выборок и ответом менее чем за секунду.

Хранение и API

Отдельно стоит возможность «путешествия во времени». Система не хранит каждый момент отдельно, а накапливает данные в скользящих окнах. Это позволяет спросить «как выглядела топология вчера в полночь» без взрыва объёмов хранения.

Что даёт инженерам

Интерфейс и API дают инженерам несколько рабочих сценариев — от ручного расследования до автоматических проверок.

• Видеть upstream и downstream для любого сервиса с фильтрами по уровню доступности и домену.
• Переключаться между единым видом и отдельными слоями: только сеть, только IPC или только трейсы.
• Одним кликом переходить от узла топологии к логам, трейсам и детальным метрикам.
• Оценивать зону поражения перед отключением сервиса на обслуживание и понимать, кого уведомлять.
• Накладывать статус здоровья на граф и быстро понимать, локальная ли это проблема или каскадный сбой.
• Обращаться к топологии программно — например, чтобы автоматически проверять классификацию доступности критичных сервисов.
• Смотреть историю зависимостей и находить, что изменилось перед инцидентом.

Как перенести в свою систему

Не каждая компания работает в масштабе Netflix, но логика подхода универсальна. Если у вас десятки сервисов, уже появляется эффект «тысячи кусочков пазла». Начать можно с малого: собрать список зависимостей из существующих источников и периодически сверять его с реальным трафиком.

Чек-лист для первых шагов:
1. Выберите один настоящий источник связей: логи балансировщика, агент на хосте или метрики вызовов.
2. Не пытайтесь сразу построить идеальную модель — начните с автоматически обнаруженных рёбер.
3. Добавьте контекст: владельца сервиса, уровень критичности и домен.
4. Сделайте карту доступной программно, а не только в интерфейсе — инцидент-боты и скрипты будут благодарны.
5. Проверяйте актуальность: в динамичной среде карты, устаревшие на несколько часов, быстро теряют ценность.

Для иллюстрации вот минимальный скрипт, который строит рёбра графа из логов балансировщика:

Часто задаваемые вопросы

Выводы

Service Topology — не просто красивая картинка для панели мониторинга. Это операционная основа, которая ускоряет расследования, снижает риск изменений и даёт автоматическим системам общую картину инфраструктуры. Netflix называет её knowledge graph foundation — фундаментом для интеллектуальной автоматизации, в том числе для автоматического поиска первопричины сбоев.

Service topology provides the knowledge graph foundation that makes this kind of intelligent automation possible.

Для российских команд, где инфраструктура тоже стремительно усложняется, главный урок в другом: не ждите идеальной полноты данных. Начните с одного реального источника, добавьте контекст, сделайте карту программно доступной — и она начнёт приносить пользу раньше, чем вы построите «полноценную» систему.

Источники

• From Silos to Service Topology: Why Netflix Built a Real-Time Service Map

Что значит «правильный фундамент сайта»

Под фундаментом я понимаю не только сервер и домен, а совокупность факторов: производительность, надёжность инфраструктуры, структурированные данные, качество контента, доступность и удобство использования. Фреймворк — это инструмент; фундамент — это то, ради чего инструмент используется. Плохо оптимизированный сайт на передовом стеке часто проигрывает хорошо сделанному сайту на классическом стеке. Подробнее про метрики скорости — в материале о Core Web Vitals на Tproger.

• Выбор фреймворка перестал быть решающим фактором: зрелые инструменты дают схожие возможности.
• Производительность, хостинг, домен и CDN (сеть доставки контента) напрямую влияют на трафик и конверсию.
• Структурированные данные (Schema.org / JSON-LD) помогают поисковикам и ИИ правильно понимать контент.
• ИИ-поиск и ответные системы меняют правила видимости: важны ясность, авторитетность и точные ответы.
• Качественный контент и UX становятся главным конкурентным преимуществом.

Технологический стек стал товаром

За последнее десятилетие экосистема веб-разработки выросла настолько, что большинство популярных фреймворков предлагают примерно одно и то же: компонентную архитектуру, серверный рендеринг, интеграции с API, аутентификацию и инструменты оптимизации. Разрыв между React, Vue, Svelte, Next.js, Nuxt, Laravel или Django в типичных задачах сократился до предпочтений команды, а не до объективных преимуществ.

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

Сигнал проверить себя: если команда обсуждает миграцию фреймворка, но у сайта LCP выше 2,5 с, нет CDN и картинки весят по 400 КБ — стоит сначала закрыть очевидные дыры в фундаменте.

Производительность всё ещё решает

Многочисленные исследования показывают, что задержка загрузки влияет на отказы и конверсию. Даже небольшое увеличение времени ответа заметно снижает вероятность, что пользователь дождётся контента.

Что именно оптимизировать

Современная оптимизация выходит далеко за «сожми JS». Нужно думать о форматах изображений (WebP, AVIF), ленивой загрузке, кешировании на граничных серверах, CDN, оптимизации шрифтов и времени ответа сервера. Интернет-магазин, который перевёл каталог на WebP, включил lazy loading и раздал статику через CDN, зачастую получит больше прироста, чем если бы переписал витрину с нуля.

• Измеряйте LCP (Largest Contentful Paint — отрисовку крупного контента), INP (Interaction to Next Paint — время реакции на взаимодействие) и CLS (Cumulative Layout Shift — визуальную стабильность) в PageSpeed Insights или Lighthouse.
• Переводите изображения в современные форматы и используйте адаптивные размеры.
• Включайте кеширование статики на CDN (сети доставки контента) как минимум на год.
• Убирайте неиспользуемый CSS и JS: в российских сетях каждый лишний мегабайт бьёт по скорости и по бюджету пользователя.

Домены и инфраструктура не теряют значения

Разработчики любят обсуждать код, но домен, DNS и регистратор — это цифровое имущество проекта. Неправильно настроенные записи, просроченный домен или взломанный регистратор могут положить сайт быстрее, чем баг в приложении.

В российском контексте стоит обращать внимание на локальных регистраторов — например, Reg.ru или RU-CENTER. Важны двухфакторная аутентификация в личном кабинете, блокировка переноса домена (domain lock), корректные NS-записи и резервные DNS-серверы. Если ваш бизнес зависит от сайта, отказоустойчивость DNS может спасти репутацию в момент DDoS или аварии хостинга.

• Проверьте срок действия домена и включите автообновление.
• Включите 2FA у регистратора и запретите неавторизованный трансфер.
• Используйте минимум два независимых NS-сервера в разных сетях.
• Мониторьте время отклика DNS: оно влияет на TTFB (Time to First Byte — время до первого байта ответа сервера).

Хостинг — это уже не просто сервер

Раньше хостинг означал аренду железа и развёртывание кода. Сегодня платформы предлагают глобальные CDN, автомасштабирование, встроенную безопасность, наблюдаемость и автоматизацию развёртывания. Граничные вычисления позволяют отдавать контент ближе к пользователю, снижая задержку.

Что спрашивать у провайдера

В России это может быть Selectel, Timeweb, Beget, Yandex Cloud или VK Cloud. Выбирая провайдера, смотрите не только на цену CPU/RAM, но и на SLA по доступности, географию CDN-точек, скорость развёртывания, поддержку HTTP/2 и HTTP/3, а также простоту мониторинга. Сайт, который остаётся доступным во время вирального всплеска трафика, приносит больше пользы, чем идеально написанный, но упавший сервис.

Практический контрольный список: есть ли у провайдера CDN (сеть доставки контента) в России, автомасштабирование, бэкапы и DDoS-защита? Если нет — вы платите не за хостинг, а за аренду сервера с самообслуживанием.

Структурированные данные перешли из «можно» в «нужно»

Поисковые системы и ИИ всё чаще не просто индексируют текст, а пытаются понять смысл страницы. Schema.org / JSON-LD помогает явно указать: это статья, товар, отзыв, событие, организация или рецепт.

Без микроразметки поисковику приходится догадываться из неструктурированного текста, что повышает риск ошибок. С микроразметкой контент чаще попадает в расширенные сниппеты, карточки знаний и rich results. Для русскоязычных проектов это особенно важно в Яндексе и Google: оба поисковика поддерживают Schema.org.

Пример разметки статьи на базе Schema.org — в гайде «Добавляем Schema.org в Docusaurus для GEO».

• Для статей используйте тип Article с headline, author и datePublished.
• Для товаров — Product с offers, aggregateRating и availability.
• Проверяйте разметку через валидаторы Google Rich Results Test и Яндекс.Вебмастер.
• Добавляйте FAQ и HowTo только там, где они реально отвечают на вопросы пользователей.

ИИ-поиск и Answer Engine Optimization

Пользователи всё чаще задают вопросы нейросетям и ассистентам вместо того, чтобы вбивать ключевые слова в поисковик. ChatGPT, Perplexity, ЯндексGPT, Google AI Overviews собирают ответы из множества источников и показывают их в диалоговом формате.

Как стать источником для ИИ

Это меняет правила видимости. Цель уже не только попасть на первую страницу Google, но и стать источником, который ИИ цитирует. Answer Engine Optimization (AEO) — подход, при котором контент структурируется так, чтобы давать прямые, авторитетные и легко извлекаемые ответы.

• Формулируйте ключевые тезисы в первых 100-150 словах статьи.
• Используйте чёткие заголовки H2/H3 с вопросами («Что такое...», «Как проверить...»).
• Добавляйте блоки FAQ и Ключевые выводы: ИИ-системы часто цитируют именно их.
• Подкрепляйте утверждения ссылками на первоисточники и данные.

Контент остаётся главной причиной визита

Технологии улучшают доставку, но не заменяют смысл. Тонкий контент, заточенный только под ключевые слова, всё хуже ранжируется: поисковики и ИИ всё лучше распознают экспертизу, авторитетность и релевантность.

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

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

Пользовательский опыт — новый дифференциатор

С чего начать проверку

Когда технологии доступны всем, преимущество уходит к тому, кто делает продукт удобнее. Интуитивная навигация, отзывчивая вёрстка, доступность для людей с ограниченными возможностями и стабильная работа на мобильных — это не «полировка», а часть функционала.

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

• Проверьте сайт с клавиатуры: можно ли дойти до всех интерактивных элементов?
• Запустите Lighthouse в мобильном режиме и исправьте критичные замечания по доступности.
• Тестируйте на реальных устройствах, а не только в десктопном браузере.
• Собирайте обратную связь от реальных пользователей, а не только метрики.

Подробнее про инструменты и приёмы проверки доступности — в материале «Что такое доступность сайта и как её проверить».

Будущее — за результатами, а не фреймворками

Индустрия веб-разработки дошла до точки, где любой зрелый фреймворк способен дать отличный результат. Настоящий вызов — собрать сайт, который быстро грузится, легко находится, надёжно работает и понятен людям и машинам.

Сайты, которые побеждают сегодня, строятся не на модных технологиях, а на сильном фундаменте. Разработчики, которые фокусируются на производительности, инфраструктуре, микроразметке, контенте и UX, создают проекты, которые останутся конкурентоспособными независимо от того, как изменятся поисковики, ИИ или фронтенд-стек.

FAQ

Выводы

Технологический стек важен, но он перестал быть главным предиктором успеха. В 2026 году сайт выигрывает не потому, что написан на модном фреймворке, а потому что у него сильный фундамент: быстрая загрузка, надёжная инфраструктура, понятная микроразметка, качественный контент и удобный интерфейс.

Если вы планируете запуск или редизайн, начните не со споров о стеке, а с аудита скорости, инфраструктуры и контента. Это даст больше реальной пользы, чем очередная миграция «на что-то более современное».

Источник: Manish Shivanandhan, freeCodeCamp — Building a Website in 2026: What Matters More Than Your Tech Stack. Материал подготовлен как авторская переработка идеи с добавлением российского контекста и практических рекомендаций.

Таковы результаты ежегодного исследования компании Checkmarx — вендора инструментов для анализа безопасности приложений. В опросе участвовали 2350 разработчиков, CISO (Chief Information Security Officer) и AppSec-менеджеров (application security) по всему миру. Выборка выросла на 54% по сравнению с прошлым годом, что делает данные ещё более репрезентативными.

70% разработчиков считают ИИ-код более уязвимым, чем человеческий.

30% всех опрошенных сознательно деплоят уязвимый код в продакшен.

93% компаний пережили хотя бы один инцидент безопасности из-за уязвимых приложений.

Организации, где 81–100% кода генерируется ИИ, деплоят уязвимости в 3,4 раза чаще, чем те, где ИИ-генерация составляет 1–20%.

59% кода в продакшене — open source, который тоже не идеален с точки зрения безопасности.

ИИ пишет половину кода — и это проблема

По данным Checkmarx, сегодня примерно 49% кода в продакшене создаётся с помощью ИИ. Это немного меньше, чем 54% в прошлом году, но всё ещё колоссальная цифра. Почти каждая вторая строка в вашем приложении может быть рождена нейросетью, которая обучалась на публичных репозиториях — со всеми их багами, устаревшими паттернами и скрытыми уязвимостями.

Причина проста: языковые модели обучаются на огромных массивах существующего кода, включая устаревшие практики и известные CVE (Common Vulnerabilities and Exposures). Исследователи из University of Central Florida и Birzeit University в 2025 году провели сравнительный анализ безопасности кода, сгенерированного разными LLM для Java, Python, C и C++. C-код оказался самым дырявым, Python — относительно чистым. Но ключевой вывод исследования шире: модели «недоиспользуют современные языковые и компиляторные возможности, предпочитая устаревшие практики более безопасным альтернативам». Сами исследователи оговаривают: LLM эволюционируют быстро, и их выводы — это «снимок во времени» (time-stamped view), а не вечная истина.

Почему разработчики деплоят то, что не доверяют

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

• Давление сроков и необходимость быстро деплоить фичи.
• Уязвимости слишком сложно или дорого исправлять постфактум.
• Надежда на то, что «другие инструменты безопасности подхватят» на поздних этапах.
• Нормализация риска: когда все вокруг деплоят с багами, это перестаёт восприниматься как катастрофа.

Checkmarx прямо констатирует: «Risk is normalized» — риск стал нормой. 93% респондентов сообщили о как минимум одной бреши в безопасности, связанном с уязвимыми приложениями. В прошлом году это было 98% — статистика чуть улучшилась, но не кардинально. Когда девять из десяти компаний регулярно взламывают, инцидент перестаёт быть новостью и становится рутиной.

Объём ИИ-кода напрямую коррелирует с частотой деплоя уязвимого кода, которая, в свою очередь, коррелирует с частотой инцидентов безопасности.

Самая тревожная цифра: организации, где 81–100% кода генерируется ИИ, деплоят уязвимый код в 3,4 раза чаще, чем компании с умеренным использованием ИИ (1–20%). Это прямая корреляция: чем выше доля ИИ-генерации, тем чаще в прод попадают уязвимости. Причина не только в самом коде, но и в том, что высокая скорость разработки часто сопровождается слабыми процессами безопасности.

Open source как фундамент — и фундамент трещит

Ещё один слой проблемы — open source. По оценкам респондентов, 59% кода в продакшене приходится на открытые библиотеки. Это самооценки, но они отражают реальность: современный проект без node_modules, requirements.txt или Cargo.toml немыслим. Проблема в том, что мейнтейнеры этих библиотек часто не успевают закрывать уязвимости, а злоумышленники активно внедряют вредоносные пакеты в npm, PyPI и другие репозитории.

ИИ-инструменты ускоряют разработку, но не ускоряют аудит безопасности. Veracode в своём отчёте предупреждает: скорость ИИ-разработки делает безопасность недостижимой, если процессы не перестраиваются соответствующим образом. Инструменты статического анализа и сканеры на базе ИИ уязвимостей существуют, но организации не умеют встраивать их в процесс. «Инструменты делают работу, но компании не умеют переводить это в процесс» — констатируют в Checkmarx.

Например, вот типичная разница между ИИ-сгенерированным кодом и безопасной альтернативой. Copilot или аналогичные инструменты часто предлагают устаревший pickle.load для десериализации данных:

pickle.load выполняет произвольный Python-код при десериализации — классическая уязвимость из списка OWASP Top 10. Аналогичные проблемы часто встречаются в SQL-запросах без параметризации, использовании eval() и устаревших криптографических функциях. Проверяйте каждый snippet перед мержем.

Как не превратить ИИ-ускорение в ИИ-катастрофу

Отказываться от ИИ в разработке бессмысленно — это уже не инструмент будущего, а повседневная реальность. Но можно и нужно менять подход:

1. Проверяйте ИИ-код так же тщательно, как человеческий. Не предполагайте, что нейросеть знает лучше.
2. Автоматизируйте сканирование уязвимостей в CI/CD. SAST (Static Application Security Testing) и DAST (Dynamic Application Security Testing) должны быть обязательным шагом пайплайна, а не опцией.
3. Аудитируйте зависимости. Используйте инструменты вроде npm audit, Snyk или OWASP Dependency-Check.
4. Обучайте команду безопасности. Разработчики должны понимать, какие уязвимости чаще всего генерирует ИИ для вашего стека.
5. Не жертвуйте безопасностью ради скорости. Если уязвимость критична — отложите релиз. Технический долг в безопасности обходится в разы дороже, чем в производительности.

Выводы

ИИ — это не замена разработчику, а ускоритель. Как любой ускоритель, он требует тормозов. Когда 30% всех опрошенных сознательно деплоят код, в котором сами признают уязвимости, проблема не в технологиях — а в отсутствии дисциплины. Не верьте нейросети на слово: проверяйте зависимости, сканируйте код, требуйте ревью. Ускорение без контроля — это не оптимизация, а авария в замедленной съёмке.

Источник: The Register — Devs know AI code is riddled with holes, but ship it anyway

Написать оператор можно на Go с помощью operator-sdk: сгенерировать скелет проекта, определить CRD, реализовать Reconcile и задеплоить в кластер. В этой статье разберём паттерн Operator и соберём рабочий оператор, который создаёт Deployment и Service по декларативной спецификации, отслеживает дрейф конфигурации и мгновенно откатывает несанкционированные изменения.

Оператор Kubernetes — это пользовательский контроллер, который расширяет API кластера собственными ресурсами (CRD) и непрерывно приводит фактическое состояние к желаемому.

Шаблон Reconcile — Observe → Create → Correct → Report — лежит в основе любого оператора: контроллер наблюдает, создаёт недостающее, исправляет отклонения и сообщает статус.

С помощью operator-sdk и kubebuilder-меток можно сгенерировать скелет проекта, CRD и RBAC-манифесты, не писать boilerplate вручную.

Owner Reference связывает дочерние ресурсы с родительским кастомным ресурсом (CR): при удалении WebApp Kubernetes автоматически уберёт связанные Deployment и Service.

Обновление статуса через Status().Update() изолировано от основного ресурса и предотвращает бесконечные циклы реконсиляции.

Почему стандартных примитивов Kubernetes не хватает

Kubernetes предоставляет мощный набор базовых абстракций: Pod, Deployment, StatefulSet, Service, Ingress. Они отлично справляются с запуском контейнеров, балансировкой трафика и базовым масштабированием. Однако эти примитивы агностичны к бизнес-логике приложения.

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

Сегодня операторы де-факто стали стандартом для управления сложными stateful-приложениями в Kubernetes: от баз данных и брокеров сообщений до сервисных mesh и CI/CD-систем. Концепция была сформулирована инженерами CoreOS ещё в 2016 году, а сейчас поддерживается Cloud Native Computing Foundation (CNCF) как ключевой паттерн платформенной инженерии.

Архитектура оператора: CRD, Reconciler и control loop

Любой оператор состоит из двух ключевых компонентов:

• Custom Resource Definition (CRD) — расширение API Kubernetes, которое определяет новый тип ресурса со своей схемой Spec (желаемое состояние) и Status (фактическое состояние).
• Контроллер (Reconciler) — программный цикл, который постоянно сравнивает Spec и Status, а затем выполняет действия для их сближения.

Контроллер не работает по принципу «выполнил шаги и вышел». Вместо этого он реализует control loop: каждую итерацию можно запускать снова и снова — результат не сломается, потому что код сравнивает «что есть» с «что нужно» и корректирует только расхождения. Это критически важно, потому что события в распределённой системе приходят асинхронно, а состояние объекта могло измениться за время обработки предыдущего события.

Создаём проект с operator-sdk

Вручную писать весь boilerplate контроллера — неэффективно. Инструмент operator-sdk (основанный на Kubebuilder) генерирует стандартную структуру проекта Go, включая точку входа main.go, Makefile с целями для сборки и тестирования, а также инфраструктуру для управления CRD.

Инициализируем проект и создаём API с контроллером:

Флаг --resource сгенерирует Go-структуры, описывающие схему пользовательского ресурса. Флаг --controller создаст шаблон reconciler'а — файла, в котором мы будем писать логику управления.

Определяем схему CRD

Откроем api/v1/webapp_types.go. Здесь мы описываем два структурных блока: WebAppSpec — то, что задаёт пользователь в YAML-манифесте, и WebAppStatus — то, что оператор сообщает о текущем состоянии.

Важнейшая часть — kubebuilder-маркеры над основной структурой:

Маркер +kubebuilder:subresource:status сообщает Kubernetes, что для этого ресурса нужен отдельный endpoint /status. Без него любое обновление статуса будет восприниматься API-сервером как изменение всего объекта, что вызовет каскадную реконсиляцию и может привести к бесконечному циклу.

Маркеры +kubebuilder:printcolumn настраивают вывод команды kubectl get webapps: вместо голого имени ресурса пользователь увидит фазу, желаемое и доступное количество реплик.

Reconciler: сердце оператора

Файл internal/controller/webapp_controller.go содержит функцию Reconcile — точку входа в control loop. Перед ней размещаются RBAC-маркеры, которые генерируют манифесты прав доступа при выполнении make manifests:

Без этих маркеров оператор не получит прав на чтение и запись стандартных ресурсов Deployment и Service, и при запуске в кластере упадёт с ошибкой доступа. Разберём функцию Reconcile по шагам.

Шаг 1. Получение актуального состояния

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

Здесь apierrors импортируется из пакета k8s.io/apimachinery/pkg/api/errors, а ctrl — из sigs.k8s.io/controller-runtime.

Шаг 2. Реконсиляция Deployment

Сначала проверяем, существует ли связанный Deployment. Если нет — создаём его через вспомогательную функцию deploymentForWebApp.

Вызов return ctrl.Result{Requeue: true}, nil ставит событие обратно в очередь: контроллер немедленно перезапустит Reconcile для того же объекта, чтобы продолжить с следующего шага. Это удобнее, чем ждать следующего внешнего события.

Вот как выглядит функция deploymentForWebApp:

Owner Reference — это механизм garbage collection в Kubernetes. Когда пользователь удаляет ресурс WebApp, кластер автоматически удалит все дочерние объекты, на которые ссылается поле ownerReferences. Без этой связи после удаления кастомного ресурса в кластере останутся «зомби»-поды и сервисы.

Шаг 3. Обнаружение дрейфа конфигурации

Если Deployment уже существует, мы не просто идём дальше — сравниваем желаемое и фактическое состояние. Это и есть то, что отличает оператор от одноразового скрипта.

Представьте, что кто-то из команды в обход оператора выполнил следующую команду или подменил образ на уязвимую версию. Оператор мгновенно фиксирует расхождение и принудительно возвращает ресурс к значениям, заданным в WebApp.Spec.

Шаг 4. Реконсиляция Service

С вычислительным слоем разобрались — теперь нужен сетевой доступ. Логика полностью идентична: проверяем наличие Service, создаём при отсутствии, устанавливаем Owner Reference. Для локального тестирования в Minikube используем тип NodePort.

Вспомогательная функция serviceForWebApp строит объект Service с нужными селекторами и портами:

Шаг 5. Обновление статуса

Последний шаг — сообщить пользователю текущее состояние приложения через status subresource. Здесь критически важно использовать именно r.Status().Update(), а не r.Update().

Разделение основного endpoint ресурса и subresource /status — фундаментальное свойство Kubernetes. Оно гарантирует, что обновление статуса не триггерит новое событие изменения ресурса и, соответственно, не запускает бесконечную реконсиляцию.

Тестирование: как проверить, что оператор работает

Для локального тестирования подойдёт Minikube. Запускаем оператор в одном терминале, а в другом — создаём кастомный ресурс.

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

Демонстрация: откат несанкционированных изменений

Главная ценность оператора — самовосстановление. Сымитируем вмешательство: масштабируем Deployment в обход кастомного ресурса.

Мгновенно в логах контроллера появляется сообщение:

Лог оператора:
INFO Drift detected! Updating Deployment {"DesiredReplicas": 3, "ActualReplicas": 10}

А через несколько секунд избыточные поды начинают завершаться:

В это время статус WebApp отражает промежуточное состояние Scaling, а после полного схождения — автоматически переключается обратно на Running.

Когда операторы необходимы, а когда избыточны

Не каждому приложению нужен собственный оператор. Для stateless-сервисов, которые достаточно описать парой манифестов Deployment + Service, оператор будет накладным расходом. Однако есть категории систем, где без оператора не обойтись:

• Базы данных — PostgreSQL, MySQL, MongoDB, etcd: репликация, бэкапы, обновления, failover.
• Брокеры сообщений — Kafka, RabbitMQ, NATS: управление партициями, топиками, кластерной топологией.
• Сетевые компоненты — Ingress-контроллеры, service mesh: динамическая маршрутизация и политики безопасности.
• CI/CD и GitOps — Tekton, Argo CD: оркестрация пайплайнов и синхронизация состояния кластера с репозиторием.

В российской инфраструктурной практике операторы активно используются в Managed Kubernetes от крупных облачных провайдеров. Например, в Яндекс Облаке операторы лежат в основе managed-сервисов баз данных, обеспечивая автоматизацию резервного копирования, мониторинга и масштабирования.

Выводы

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

В этой статье мы прошли полный путь: от генерации скелета проекта через operator-sdk до работающего контроллера, который создаёт инфраструктуру, отслеживает дрейф конфигурации и автоматически восстанавливает желаемое состояние. Ключевые навыки — понимание асинхронной природы control loop, правильное использование Owner Reference и изолированное обновление статуса — применимы далеко за рамками Kubernetes.

Оператор — это не магия, а дисциплина. Каждая итерация Reconcile — это честный вопрос: «Что должно быть?» против «Что есть сейчас?». Ответить на него правильно — значит построить надёжную систему.

Полный код проекта доступен в репозитории автора оригинального туториала: SandeshOjha06/k8-operator. Если вы планируете развиваться в направлении platform engineering или SRE, умение писать и отлаживать собственные контроллеры станет серьёзным конкурентным преимуществом.

Источники:

• Building a Kubernetes Operator from Scratch with Operator SDK — оригинальный туториал Сандеша Оджха.
• Kubernetes Operators — официальная документация Kubernetes.
• Operator SDK — фреймворк для разработки операторов.
• The Kubebuilder Book — руководство по построению Kubernetes API и контроллеров.

Технически связать их реально за один спринт. Платформа 1С умеет отдавать данные через REST API по протоколу OData ещё с восьмёрки — достаточно опубликовать базу на веб-сервере. Kubernetes отдаёт метрики через Prometheus. Grafana умеет читать оба источника одновременно.

В статье, как это сделать на практике: какие данные вообще стоит тащить из 1С в общий дашборд, где обычно ломается интеграция и как не превратить это всё в очередную ФИЧУ, которая падает каждый раз после обновления конфигурации.

Что умеет 1С в плане интеграции

Забудьте о том, что 1С — это закрытая коробка, к которой можно обращаться только через COM-соединение или выгрузки текстовых файлов на FTP. Современная 1С — это нормальный HTTP-бэкенд, если правильно включить тумблеры.

REST API и OData из коробки

Вам не нужно писать ни строчки кода на 1С, чтобы вытащить из неё метрики. Платформа умеет автоматически генерировать REST-интерфейс для всех объектов конфигурации сразу после публикации базы на веб-сервере (обычно это Apache или IIS).

Под капотом работает открытый протокол OData 3.0. 1С честно принимает HTTP-запросы и отдаёт чистый JSON. Хотите посмотреть количество открытых заказов? Стучитесь GET-запросом к документу. Нужны остатки на складе? Спрашиваете виртуальную таблицу регистра накопления.

Пример запроса на получение последних 10 документов продаж из опубликованной базы:

КОД

OData поддерживает фильтрацию прямо в URL. Если вам нужны только заказы за конкретный период или больше определённой суммы, вы передаёте это в параметре $filter, и 1С сама собирает нужную выборку на стороне базы данных.

HTTP-сервисы внутри конфигурации

OData отдаёт данные «как есть», повторяя структуру таблиц 1С. Иногда это слишком тяжеловесно. Например, если для дашборда вам нужна одна цифра «Сумма продаж за час», через OData придётся вытягивать массив заказов и суммировать их на стороне Kubernetes.

Для таких случаев в 1С есть HTTP-сервисы. Это кастомные эндпоинты, которые 1С-разработчик пишет прямо в конфигураторе. Вы договариваетесь с ним о контракте, он пишет код, который внутри 1С сам считает нужные метрики и отдаёт наружу лёгкий JSON в нужном вам формате.

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

Файловый обмен как запасной вариант

Случаются ситуации, когда безопасники отказываются открывать HTTP-порты сервера 1С наружу, или база крутится в закрытом контуре.

Здесь работает старый добрый асинхронный обмен. В 1С настраивается регламентное задание, которое собирает нужные метрики и складывает их в JSON-файл в общую сетевую папку или S3-хранилище. Exporter на стороне K8s просто читает этот файл по расписанию.

Да, вы получите данные с задержкой. Но если честно: динамику отгрузок за сутки или общую сумму дебиторки всё равно нет смысла обновлять на дашборде каждые 10 секунд.

Как устроен стек на стороне Kubernetes

Здесь есть чёткое разделение ролей: одни сервисы отдают метрики, другие их собирают, третьи рисуют графики.

Prometheus собирает, Grafana показывает

Стандартный стек наблюдаемости (observability) в Kubernetes состоит из двух главных компонентов.

• Prometheus — это база данных временны́х рядов. Он работает по pull-модели: у него есть список эндпоинтов, он ходит по ним с заданной частотой (например, каждые 15 секунд), забирает текущие значения метрик и складывает к себе в хранилище.

• Grafana — она ничего не хранит и ничего не собирает. Она отправляет PromQL-запросы в Prometheus, получает массивы чисел и отрисовывает их в панели.

Чтобы 1С появилась в Grafana, нам нужно научить Prometheus её опрашивать. Но Prometheus ждёт метрики в своём специфическом текстовом формате (вида orders_count{status="new"} 42), а 1С отдаёт JSON через OData. Нужен переходник.

Prometheus Exporter как мост к 1С

Этот переходник называется exporter. Технически это микросервис, который принимает запрос от Prometheus, идёт в 1С, парсит JSON-ответ и выдаёт его в нужном формате.

Пишется он элементарно. Вот рабочий пример на Python с использованием официальной библиотеки prometheus_client:

КОД

Вы упаковываете этот скрипт в Docker-образ, деплоите в Kubernetes как обычный под (Deployment) и вешаете на него Service. После этого добавляете в конфиг Prometheus новую job'у для скрейпинга вашего экспортера. Готово — метрики 1С лежат в Prometheus рядом с метриками CPU ваших подов.

Loki для логов рядом с метриками

Цифры (метрики) — это половина картины. Иногда для разбора инцидента нужны тексты ошибок: почему конкретно не провелась накладная или отвалился обмен с банком.

В экосистеме K8s за логи отвечает Loki — он умеет принимать структурированные логи и отдавать их обратно.

Если настроить выгрузку журнала регистрации 1С в сторону Loki (например, через тот же exporter или агент сборки логов), вы получаете ультимативный дашборд. На одном экране в Grafana у вас будет график падения сетевого трафика в кластере, график падения чеков из 1С, а прямо под ними — таблица с текстами ошибок из базы за ту же самую минуту.

Где обычно ломается

Интеграция 1С и K8s кажется простой только в теории, по факту — это две разные системы. Если запустить мониторинг по принципу «написали скрипт и забыли», он упадёт в первый же месяц. И вот почему.

Обновления конфигурации 1С

Главный враг любой OData-интеграции — релизный цикл самой 1С. OData жёстко завязана на имена объектов в базе данных.

Программист 1С переименовал реквизит СтатусОплаты в СтатусДокумента? Ваш Python-экспортер упадёт с ошибкой KeyError, метрики перестанут собираться, а дашборд в Grafana замрёт на старых значениях. HTTP-сервисы ведут себя аналогично — если в очередном релизе поменяли логику сбора данных, старый эндпоинт сломается.

Как чинить: Во-первых, договориться об API-контракте. Во-вторых, добавить в CI/CD пайплайн на стороне 1С банальный автотест: после сборки релиза дёргаем тестовые OData-запросы. Если тест упал — значит, обновление ломает мониторинг, и релиз останавливается.

Авторизация и сетевая доступность

Исторически 1С — это глубокий бэкофис, закрытый файрволами. Kubernetes живёт либо в облаке, либо в выделенном контуре. Подружить их по сети — это всегда квест через службу безопасности.

OData умеет в Basic-авторизацию, но слать логины-пароли в открытом виде между кластером и 1С — плохая идея.

Минимально рабочий вариант: поставить перед 1С API Gateway (тот же Nginx или Kong), закрыть его на mTLS (взаимную аутентификацию по сертификатам) и пускать внутрь только IP-адреса подов вашего экспортера. Пароль от учётки 1С должен лежать в Kubernetes Secrets, а не хардкодиться в Python-скрипте.

Разные ритмы данных

У DevOps-инженеров и аналитиков 1С разное восприятие времени. Prometheus собирает метрики CPU каждые 15 секунд. 1С может рассчитывать себестоимость раз в час или перепроводить документы задним числом.

Если натравить ваш Python-экспортер на тяжёлый OData-запрос (например, «собери-ка мне все чеки за сегодня и посчитай среднее») каждые 15 секунд, 1С просто ляжет от количества соединений. А если опрашивать 1С раз в 10 минут, то график на фоне метрик Kubernetes будет выглядеть рваным.

Как чинить: В Grafana есть настройка Min step для каждой панели. Разделите экраны: метрики K8s пусть обновляются раз в 15 секунд, а бизнес-данные из 1С — раз в минуту или пять минут. А чтобы не класть базу тяжёлыми запросами, делайте агрегацию на стороне 1С (через HTTP-сервис), а не вытягивайте тысячи строк OData в память экспортера ради одного числа.

Пошаговый план интеграции

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

1. Определите одну бизнес-метрику, которая важна SRE. Это может быть «количество чеков в минуту» или «число ошибок проведения». Не тащите всю финансовую отчётность в Grafana.
2. Опубликуйте 1С на веб-сервере. Включите поддержку стандартного интерфейса OData и проверьте, что нужный документ или регистр отдаёт JSON по HTTP.
3. Напишите Python-экспортер. Он должен делать ровно две вещи: ходить в 1С по расписанию через OData и отдавать данные в формате, понятном Prometheus. Оберните скрипт в Docker.
4. Настройте сетевой доступ. Спрячьте 1С за API Gateway. Задеплойте под с экспортером в Kubernetes и дайте ему доступ к шлюзу.
5. Настройте Prometheus. Добавьте scrape-конфиг, чтобы Prometheus начал опрашивать ваш экспортер. Убедитесь, что метрика появилась в хранилище.
6. Соберите дашборд. Выведите на один экран в Grafana технические метрики кластера (CPU, память, рестарты) и бизнес-метрику из 1С. Обязательно разведите интервалы обновления: для K8s — 15 секунд, для 1С — 1–5 минут.
7. Настройте первый алерт. Например: «Если количество ошибок из 1С > 10 за 5 минут, а в кластере есть рестарты подов — отправь уведомление в Трекер».

1С и Kubernetes — это просто два HTTP-клиента, как только вы соберёте их на одном дашборде, половина конфликтов между бизнесом и разработкой отпадёт сама собой.

Что такое Agentic SRE

Agentic SRE — это практика, в которой автономные ИИ-агенты помогают наблюдать за системами, анализировать телеметрию (метрики, логи, трейсы) и выполнять ограниченные операционные действия при заданных человеком guardrails (правил безопасности). Агент не заменяет SRE-инженера, а работает как цифровой напарник: собирает контекст, предлагает гипотезы и выполняет только те действия, которые одобрены политикой.

Ключевое отличие от классической автоматизации — способность к рассуждению. Традиционные скрипты реагируют на жёсткие триггеры («если CPU > 90%, то перезапустить»). Агент же может связать всплеск ошибок с недавним развёртыванием, проверить корреляцию по трейсам и предложить конкретный план действий — всё до того, как инженер откроет ноутбук.

Agentic SRE — это ИИ-агенты, которые помогают инженерам наблюдать, диагностировать и реагировать на инциденты.

Основная цель — сократить рутину и ускорить принятие решений, а не заменить человека.

Ключевые сценарии: триаж алертов, инцидент-копилот, автоматический RCA, безопасное исправление, обучение на инцидентах.

Безопасность превыше всего: агенты работают с allowlists, approval gates и полным аудитом.

Российские команды могут строить стек на OpenTelemetry, Prometheus/Grafana, собственных LLM и PagerDuty/Opsgenie.

Почему это важно именно сейчас

Сегодняшние системы стали слишком распределёнными, шумными и динамичными, чтобы человек успевал за ними вручную. Микросервисы, Kubernetes, feature flags и канареечные развёртывания создали ландшафт, где одно изменение может затронуть десятки сервисов, а сигналы о проблемах разбросаны по десяткам дашбордов.

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

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

Из чего строится стек

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

• Телеметрия: OpenTelemetry — стандарт сбора телеметрии — для сбора логов, метрик и трейсов в едином формате.
• Наблюдаемость: Prometheus, Grafana, Datadog, New Relic, Elastic или облачные системы — хранилище и визуализация.
• Оркестрация: MCP-серверы (Model Context Protocol от Anthropic), внутренние API или системы рабочих процессов, которые предоставляют агенту безопасные инструменты.
• Среда выполнения агента: LLM-фреймворки с function calling, планированием и работой с инструментами.
• Рабочий процесс при инцидентах: PagerDuty, Opsgenie, Slack, Jira, ServiceNow — куда агент пишет отчёты и запрашивает подтверждения.
• Safety Layer: RBAC, approval gates, audit logs, allowlists и пути отката — неотъемлемая часть, а не дополнение.

Принцип безопасности:
Агент должен уметь делать только то, что мог бы сделать дежурный инженер после одобрения. Это делает систему практичной и снижает риск случайного ущерба.

Пять сценариев, которые уже работают

1. Триаж алертов: от шума к сути за секунды

Когда срабатывает алерт, агент собирает связанные трейсы, проверяет недавние развёртывания, находит соответствующие всплески в логах и формирует краткое резюме на русском языке: вероятная причина, уверенность, рекомендуемые действия. Это решает проблему «с чего начать?», которая сжигает драгоценные минуты в начале инцидента.

2. Инцидент-копилот: второй мозг в канале

Агент подключается к каналу реагирования (Slack, Teams) и выполняет роль «второго мозга»: строит таймлайн, подтягивает ссылки на дашборды, отслеживает гипотезы по мере их проверки. Когда в инциденте участвуют несколько инженеров, это предотвращает фрагментацию контекста и дублирование усилий.

3. Автоматический черновик RCA (Root Cause Analysis)

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

4. Безопасное исправление под контролем

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

5. Обучение на инцидентах: от пожаротушения к профилактике

Агент анализирует паттерны в разных инцидентах, выявляет повторяющиеся корневые причины и предлагает, где улучшить наблюдаемость или сократить рутину. Со временем это создаёт обратную связь: боль в продакшене превращается в инвестиции в платформу. Точные алерты, подробные трейсы, недостающие дашборды — всё это становится следствием системной работы, а не хаотичных пост-инцидентов.

Guardrails: почему доверие важнее интеллекта

Главный риск агентного SRE не в том, что агент слишком умен, а в том, что он может быть слишком уверен в себе. LLM способны генерировать правдоподобные, но неверные объяснения. Поэтому каждая рекомендация должна быть прослежена до реальной телеметрии, а каждое действие — ограничено явными правами.

• Action allowlists: агент может делать только то, что в белом списке.
• Approval gates: рискованные изменения требуют подтверждения.
• Полный audit log: каждое действие агента записывается.
• Read-only mode на этапе внедрения: сначала наблюдаем, потом действуем.
• Разграничение прав по сервисам и командам.
• Human override на каждом шаге: человек всегда может взять управление.

Если вы воспринимаете агента как стажёра с феноменальной памятью, но без здравого смысла, вы спроектируете систему с гораздо лучшей защитой.

Выводы

Agentic SRE — это не модный тренд, а логичный ответ на растущую сложность инфраструктуры. Реальная ценность не в полной автономии, а в ускорении понимания, безопасной автоматизации и качественной коллаборации человека и машины в критические моменты.

Если строить это правильно, результат — продвинутая практика надёжности: меньше бесполезной работы, короче инциденты и больше времени для инженеров на системные улучшения вместо повторяющейся рутины. Настоящая ценность агентного SRE — не в замене инженера, а в том, чтобы дать ему модель работы с гораздо большей эффективностью.

Источник: Agentic SRE: The Next Frontier of Reliability — DevOps.com (Neel Shah, 2026).

Эта статья — разбор Centicore Group того, где именно ломаются алгоритмы в мониторинге инфраструктуры, почему модели теряют связь с реальностью при изменении данных и как заставить AIOps-платформу работать нормально, а не генерировать новые проблемы.

Что нам обещали и с чем мы остались

Изначально AIOps продавали как волшебную таблетку. Загружаете логи и метрики, а на выходе получаете готовые решения проблем. Сегодня вендоры пошли еще дальше и добавили агентов на базе LLM, которые сами пишут отчеты об инцидентах и открывают треды в мессенджерах.

На практике почти все платформы — это старые добрые движки правил, обернутые в интерфейс с рекламой про ИИ. Специалисты Centicore Group, которые занимаются внедрением ИТ-решений, говорят об этой же проблеме: многотысячные (иногда миллионные) инвестиции не гарантируют результат. На рынке есть примеры компаний, которые тратили огромные деньги для внедрения ИИ, но в итоге продукт просто не работал стабильно на реальных нагрузках.

Как машинное обучение в мониторинге работает на самом деле

Почти любая AIOps-платформа проходит один и тот же путь: собирает сигналы, приводит их к общему формату, склеивает похожие события, ищет связи между ними и только потом формулирует итог для человека.

Четыре шага, которые делают все платформы

1. Система собирает сигналы из разных источников. На вход летят метрики из мониторинга, логи приложений, события оркестрации, данные об изменениях после деплоя и служебные уведомления от облака или CI/CD.
2. Система нормализует данные. У разных источников разные поля, названия и уровни детализации, поэтому платформа сначала приводит их к общей схеме: время события, сервис, хост, контейнер, severity, набор тегов.
3. Система группирует похожие уведомления и собирает инцидент. Дальше алгоритмы смотрят на время, теги, топологию сервисов и шаблоны сообщений. Если за пару минут сыпятся десятки однотипных алертов от одного сервиса, платформа схлопывает их в один инцидент.
4. Система ищет связи и формулирует вывод. После группировки движок корреляции пытается понять порядок событий: что сработало раньше, какой сервис тянет за собой остальные, где проходит общая зависимость. И только на этом этапе подключается языковая модель или шаблонный summarizer.

Где заканчивается магия и начинается статистика

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

Самые полезные функции в AIOps вообще пришли из до-LLM эпохи. Лучше всего себя показали группировка похожих логов, дедупликация однотипных алертов и автоматическая подстройка порогов под реальное поведение системы.

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

Три причины, почему умный мониторинг ломается в продакшне

Почти любая AIOps-платформа хорошо работает на стабильных данных и предсказуемых паттернах нагрузки. Но есть исключения.

Система не знает того, чего не видела

Любая модель в мониторинге учится на исторических данных. Она знает, как обычно ведёт себя сервис, какие пики нагрузки считаются нормой и какие комбинации событий уже встречались раньше. Если в проде появляется новый тип сбоя, у модели нет знаний об этом: она видит отклонение, но не понимает причину. AIOps хорошо помогает там, где инфраструктура уже накопила историю и повторяемые паттерны.

Смерть модели от изменения данных

Даже если модель однажды научилась отличать норму от сбоя, это состояние быстро устаревает. Инфраструктура меняется постоянно: выходят релизы, добавляются сервисы, меняется поведение пользователей, растёт объём запросов, сдвигаются пики нагрузки.

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

Языковые модели любят выдумывать

LLM появились в AIOps как удобный интерфейс к уже найденным событиям. Они умеют собрать сводку по инциденту, вытащить фрагменты из логов и подготовить черновик RCA. Но языковая модель генерирует наиболее правдоподобный ответ, а не гарантированно верный.

Финальный вывод о причине сбоя по-прежнему требует проверки по трассировкам, метрикам, событиям деплоя и реальному поведению зависимостей.

Где алгоритмы приносят пользу

• Сокращение шума — это то, что работает сразу. Вместо 200 алертов за двадцать минут инцидента инженер получает карточку с объединёнными событиями. Это убирает ситуацию, когда первые пять минут дежурный тратит на то, чтобы понять, сколько проблем перед ним — одна или двадцать.
• Время на поиск причины сбоя сокращается по той же причине. Когда все связанные события уже собраны в одном месте и отсортированы по времени, инженер начинает расследование с готовой временно́й шкалой.

Главное условие: всё это работает только поверх уже организованного мониторинга. Если в системе есть мусор из устаревших правил, алертов без понятного ownership и уведомлений, на которые давно никто не реагирует, то AIOps уверенно группирует и этот мусор. Качество выходного сигнала всегда ограничено качеством входного.

Как выбрать вендора

Спросите, как именно система находит проблему. Если показывают алерт, который сработал потому, что CPU поднялось выше 90%, это пороговый мониторинг, а не ML. Нам нужен случай, когда модель нашла аномалию без заранее заданного порога.

Уточните, что происходит после крупного изменения в инфраструктуре. Добавили регион, поменяли архитектуру сервиса, выкатили новый компонент с другим паттерном нагрузки. Система должна адаптироваться к новым данным без ручного обновления.

Проверьте, умеет ли система учиться на ошибках. В нормальном продукте инженер может отметить алерт как ложное срабатывание, и система корректирует своё поведение для похожих ситуаций в будущем.

Спросите про cold start. Любой алгоритм, который обучается на ваших данных, требует времени на накопление baseline. Нормальный ответ — две-четыре недели на первичное обучение с явной деградацией качества в начале. Если говорят, что система работает корректно с первого дня без данных, это либо статические правила, либо модель, обученная на чужих данных, которые могут не совпадать с вашими паттернами.

Как внедрить умный мониторинг и не уволить половину команды

Провал во внедрении AIOps обычно начинается с завышенных ожиданий и плохих данных. В рабочих сценариях команды получают результат, когда запускают платформу поэтапно и заранее фиксируют, что именно считают успехом: меньше ложных алертов, ниже MTTR, короче on-call-смена.

1. Сначала привести в порядок обычный мониторинг. Перед запуском AIOps нужно проверить data readiness: теги, источники телеметрии, качество логов, долю дублей и ложных срабатываний. Этот шаг нужен, потому что платформа опирается на те данные, которые уже есть, и плохо работает на разном потоке событий.
2. Начать с режима подсказок, а не с автопилота. Сначала включают read-only сценарий: система группирует события, предлагает причины и подтягивает контекст, но не делает автоматических действий сама. Автоматизацию подключают позже, когда команда уже видит, как платформа ошибается, и понимает, где ей можно доверять.
3. Погонять систему в shadow mode. Новый контур аномалий и корреляции лучше не выкатывать две-четыре недели до замены текущего alerting-процесса. За это время видно, что платформа пропускает и насколько её выводы совпадают с реальными инцидентами.
4. Раскатывать по сервисам, а не по всей инфраструктуре сразу. Практика staged rollout работает лучше большого запуска: команда берёт два-три хронически шумных сервиса, меряет эффект, публикует метрики по false positives и MTTR, а затем расширяет охват.
5. Собирать обратную связь каждую неделю. Сколько алертов схлопнулось корректно, сколько инцидентов она объединила ошибочно, сколько времени сэкономила.
6. Автоматизировать только низкорисковые действия. В пилотах AIOps автоматические runbooks закрывают часть повторяющихся тикетов, но безопасно это работает там, где есть понятные границы, откат и аудит. Сначала подходят простые действия вроде перезапуска зависшего процесса, очистки кэша или повторного запуска джобы, а доступ к чувствительным изменениям в проде лучше оставлять под ручным подтверждением.

Финальная мысль

AIOps приносит пользу там, где команде нужно быстрее связывать события и экономить время на первом этапе инцидента. Но качество результата по-прежнему зависит от телеметрии, мониторинга и обратной связи от инженеров сильнее, чем от количества AI-функций в интерфейсе.

Если коротко, хороший AIOps не заменяет SRE-процесс и не снимает ответственность с команды. Он сокращает рутину, ускоряет triage и оставляет инженерам ту часть работы, где всё ещё нужны проверка и контекст.

Проблема в том, что 1С очень чувствительна к архитектуре. Ей нужны высокие частоты процессора на ядро, быстрые NVMe-диски для тяжелых транзакций и грамотно настроенная отказоустойчивость. Если провайдер не умеет работать с такой спецификой, миграция просто перенесет старые тормоза на чужие серверы.

Мы разобрали актуальные облачные площадки для хостинга 1С на 2026 год. Посмотрели, как платформы организуют дисковую подсистему, какие сценарии развертывания поддерживают из коробки и как обеспечивают надежность данных.

1. ITGLOBAL.COM — облако под 1С с гарантией отказоустойчивости

ITGLOBAL.COM построил отдельный кластер под ERP-системы на базе процессоров Intel Xeon Platinum 8558P пятого поколения. Инфраструктура размещена в московском дата-центре IXcellerate MOS5 и оптимизирована конкретно под нагрузки 1С.​

Процессоры работают с базовой частотой 3,1 ГГц на всех 32 ядрах. Когда запускаете ресурсоёмкую задачу (формирование сложного отчёта, проведение пачки документов), частота поднимается до 3,4 ГГц в режиме All-Core Turbo. В пиковых нагрузках система разгоняет отдельные ядра до 4 ГГц благодаря Intel Turbo Boost 2.0.​

Для 1С это важно: платформа активно использует однопоточные операции. Когда пользователь открывает форму документа, система обрабатывает запрос на одном ядре. Чем выше частота этого ядра, тем быстрее выполняется запрос.

Как работает железо

Провайдер не использует переподписку по процессорам. Соотношение 1vCPU:1pCPU означает, что каждое виртуальное ядро привязано к физическому. Вы не делите процессор с соседями по серверу — ваши ресурсы гарантированы. Если кто-то на том же физическом сервере запускает тяжёлый процесс, это не влияет на скорость вашей 1С.​

Оперативная память — DDR5 с частотой 5600 МГц. Провайдер отключил механизмы Swap, Ballooning и TPS — технологии, которые виртуализаторы используют для оптимизации использования RAM. Без них память работает на скорости физического сервера (bare-metal), что даёт предсказуемую производительность при больших нагрузках.​

NUMA-оптимизация распределяет виртуальные машины по NUMA-нодам так, чтобы минимизировать задержки при обращении к памяти.

Кэш третьего уровня (L3) — 260 МБ. Это буфер между процессором и оперативной памятью. Чем больше кэш, тем меньше процессору нужно обращаться к RAM за данными.

Диски и хранение данных

Данные хранятся на двух типах систем хранения (СХД): NetApp AFF A800 All-Flash NVMe для "горячих" транзакционных операций и NetApp ASA C60 QLC для хранения архивов, логов и аналитики.​

All-Flash NVMe работает с минимальными задержками и высокими показателями IOPS. Когда 100+ пользователей одновременно проводят документы, читают справочники или формируют отчёты, диски не становятся узким местом.

Хранилища управляются через NetApp ONTAP с встроенной защитой от программ-вымогателей (Autonomous Ransomware Protection). Система анализирует поведение файловых операций в реальном времени: если что-то начинает массово шифровать или удалять файлы, ARP автоматически выявляет аномалии и делает снимки данных; неизменяемость копий при необходимости обеспечивается через SnapLock или объектное хранилище в режиме WORM.

Поддержка и администрирование

Техподдержка работает круглосуточно, инженеры помогают с инфраструктурой: настройка сети, мониторинг, резервное копирование, обновление гипервизора.​

Если нужно администрирование самой 1С — провайдер работает с сертифицированными партнёрами из экосистемы 1С в рамках расширенной поддержки. Они обновляют платформу, оптимизируют конфигурации, диагностируют узкие места в производительности, настраивают интеграции.

Безопасность и соответствие

Инфраструктура соответствует ФЗ-152, ISO 27001. Для компаний, работающих с персональными данными, это закрывает требования регуляторов.​

Среди доступных опций — защита от DDoS-атак, двухфакторная аутентификация (2FA), антивирусная защита, изолированные VLAN-сети и шифрование каналов связи для удаленного доступа к базам 1С.

Резервное копирование настраивается через self‑service‑панель: клиент самостоятельно задаёт расписание и политики хранения. Снимки можно размещать в географически распределённых дата‑центрах, а резервные копии создаются с режимом неизменяемости (immutable backup) — удаление или изменение снимков невозможно в течение заданного периода, что обеспечивает их защиту даже при недоступности основной площадки.

SLA — 99,95% с финансовой ответственностью. Резервирование N+1 на всех уровнях инфраструктуры исключает простои при сбоях оборудования.​

Реальный кейс: как компания SPORA ускорила 1С и получила +37% по тесту Гилёва

SPORA — российская IT-компания, разрабатывающая ПО для медицины (гемодиализ и нефрология). Продукты используются в медучреждениях, поэтому надёжность и скорость IT-систем критичны.​

К середине 2025 года компания столкнулась с проблемой: 1С размещалась на физическом сервере, который не обеспечивал нужной отказоустойчивости и создавал риски остановки работы. Тестирование у другого провайдера затянулось на несколько месяцев, но нужных показателей производительности так и не получили.​

SPORA обратилась в ITGLOBAL.COM с просьбой провести испытания в облаке под реальной нагрузкой. Инженеры развернули выделенный контур в среде VMware vSphere с индивидуальными параметрами виртуализации и оптимизированной конфигурацией хранилища.​

Сначала заказчик отнёсся скептически: предыдущие испытания на процессорах с более высокой базовой частотой не дали результата. Но специалисты ITGLOBAL.COM объяснили, что на производительность 1С влияет не только частота ядра, но и архитектура CPU, настройки виртуализации и работа дисковой подсистемы.​

Результаты тестов

Клиент провёл серию сравнительных тестов:

CPU-тесты:​

• Cinebench R23.2 Single Core: +26% (1109 → 1400)
• Cinebench R23.2 Multi Core: +23% (17503 → 21558)
• CPU-Z Single Thread: +26% (498 → 626)
• CPU-Z Multi Thread: +14% (8727 → 9990)

Тест Гилёва (1С TPC-A Local Throughput):​

• Предыдущий результат: ~35 баллов ("хорошо")
• Облако ITGLOBAL.COM: 48,08 балла ("замечательно")
• Прирост: ~37%
• Максимальная скорость записи: 443 520 КБ/с
• Количество пользователей при тесте: 105

Что получили в итоге:​

• Рост производительности 1С более чем на 30% по результатам синтетических тестов
• Отказоустойчивое размещение вместо одиночного физического сервера
• Оптимальная стоимость за счёт использования общего ERP-кластера вместо выделенного приватного облака
• Стабильная работа при многопользовательской нагрузке и предсказуемое время отклика

Сегодня SPORA использует 1С в облаке ITGLOBAL.COM и рассматривает возможность переноса других сервисов для упрощения управления IT-инфраструктурой.​

Как начать и что по деньгам

Провайдер предоставляет бесплатный тестовый период. Разворачиваете инфраструктуру, переносите тестовую базу 1С, проверяете производительность на реальных задачах — и только потом принимаете решение о переходе.​

Цена зависит от конфигурации: количество vCPU, объём RAM, дисковое пространство. Для небольших баз (до 50 пользователей) есть типовые варианты. Для высоконагруженных систем с сотнями пользователей собирается индивидуальная архитектура с расчётом под проект.​

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

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

2. K2 Cloud — комплексное облако под 1С с экспертизой полного цикла

K2 Cloud — российский облачный провайдер с фокусом на корпоративный сегмент и готовым продуктом под размещение 1С от 50+ пользователей. Подход комплексный: провайдер закрывает всё — от аудита текущей инфраструктуры до поддержки пользователей и поставки лицензий.

Формат работы отличается от простой аренды виртуалок. K2 Cloud сопровождает проект на всём жизненном цикле: проектирование, миграция, тюнинг под требования 1С и проактивный мониторинг после запуска.

Производительность и отказоустойчивость

Инфраструктура построена на базе дата-центров с сертификацией Tier III Gold по Uptime Institute — это один из самых высоких стандартов надёжности для коммерческих ЦОД. SLA достигает 99,98% — выше, чем у большинства конкурентов. Если провайдер не выдержал SLA, компенсация за каждую минуту простоя считается в соотношении 1:20.

​Производительность тюнингуется под требования 1С конкретно: команда K2 Cloud проводит аудит до миграции, выявляет узкие места и оптимизирует конфигурацию. По данным провайдера, компании получают прирост производительности до 30% после переезда в K2 Облако.

Что входит в сервис

Провайдер предоставляет четыре блока услуг:​

• Облачная инфраструктура — вычислительные ресурсы, сеть, хранилище
• Поддержка и администрирование ИТ-инфраструктуры и СУБД
• Предоставление лицензий 1С — купить или взять в аренду
• Поддержка и сопровождение систем 1С — помощь с конфигурациями, обновлениями, ошибками

Это удобно для компаний, которые не хотят координировать несколько подрядчиков: один договор закрывает и серверную часть, и прикладной уровень.

Безопасность и соответствие

Платформа сертифицирована по PCI DSS 4.0, ГОСТ Р 57580.1–2017 и 152-ФЗ до уровня защищённости УЗ-1. Для компаний, которые обрабатывают персональные данные или работают в финансовом секторе, это закрывает требования регуляторов без дополнительных сертификаций. В составе продуктовой линейки есть отдельное «Облако 152-ФЗ» и сервисы кибербезопасности — межсетевое экранирование (NGFW), защита данных от потерь.​

Для каких сценариев подходит

K2 Cloud закрывает задачи компаний, которые:​

• Хотят комплексное решение: от аудита и миграции до сопровождения пользователей — в одном контракте
• Работают с высоконагруженными системами 1С от 50+ пользователей
• Переходят на импортонезависимые решения: провайдер помогает с заменой зарубежного ПО на отечественные аналоги
• Должны соответствовать 152-ФЗ УЗ-1, PCI DSS или ГОСТ Р 57580
• Хотят контролируемый процесс миграции с гарантией результата, а не просто «аренду железа»

Среди кейсов — промышленные предприятия, FMCG-компании и IT-интеграторы: «Айсберри» (гибридная инфраструктура с 1С:ERP), завод «Автомобильные технологии» (локализация ИТ-инфраструктуры).​

Как начать и сколько стоит

Провайдер предлагает экспресс-аудит со скидкой 50% на последующее размещение 1С — это способ оценить текущее состояние инфраструктуры и понять, что мешает производительности, ещё до принятия решения о миграции.​

Стоимость рассчитывается индивидуально в зависимости от конфигурации и набора услуг. Можете взять только инфраструктуру, добавить администрирование СУБД или подключить полное сопровождение 1С — всё это собирается по запросу. Контакты, документация и форма заявки доступны на сайте k2.cloud.

3. MWS — комплексный подход к облачной 1С

MWS (MTC Web Services) предлагает под 1С несколько услуг: облачная инфраструктура на базе VMware, сопровождение работы пользователей и гибкое лицензирование.

Сама инфраструктура построена на платформе VMware. Это стандарт корпоративной виртуализации. Провайдер даёт выделенные облачные ресурсы под 1С — виртуальные машины с фиксированными характеристиками, которые не меняются в зависимости от нагрузки соседей.​

Три уровня сервиса:

1С-хостинг — аренда виртуального сервера с заранее настроенными параметрами под 1С. Это не голая виртуалка, которую нужно настраивать с нуля: провайдер уже оптимизировал параметры под специфику платформы. Обслуживание инфраструктуры берёт на себя MWS: мониторинг оборудования в режиме 24/7, обновления гипервизора без участия клиента, регулярное резервное копирование данных. Вы не следите за «здоровьем» серверов — это зона ответственности провайдера.

Помимо хостинга, MWS предлагает 1С-сопровождение (поддержка пользователей по работе с приложениями) и лицензирование (продажа и аренда лицензий 1С от 3 месяцев) — но это уже отдельные услуги, которые подключаются по необходимости.

Для каких проектов подходит

MWS закрывает задачи компаний, которые:

• Хотят передать всю ответственность за работу 1С одному подрядчику — от серверов до консультаций пользователей
• Нуждаются в гибком лицензировании с возможностью аренды на короткий срок
• Ценят комплексный подход, когда не нужно координировать несколько подрядчиков
• Используют виртуальные рабочие места для удалённых сотрудников
• Хотят снизить риски, связанные с зарубежным ПО, но не знают, как это сделать технически

Как начать и сколько стоит

На сайте доступны вебинары и материалы по облачным решениям для 1С. Стоимость рассчитывается индивидуально в зависимости от конфигурации серверов, уровня сопровождения и количества лицензий.​

Тарификация зависит от выбранного пакета услуг. Можете взять только хостинг, только сопровождение или комплекс. Гибкость в том, что вы платите за реально нужные сервисы, а не за фиксированный набор.​

Контакты и формы заявок доступны на сайте mws.ru. Провайдер работает с партнёрской сетью — если вы интегратор или IT-компания, можете зарегистрировать партнёрскую сделку и получить условия для реселлинга.

4. Selectel — облачные и выделенные серверы под 1С

Selectel предлагает два формата инфраструктуры для 1С: облачные серверы с моментальным масштабированием и выделенные физические серверы с максимальной производительностью. Оба варианта запускаются через единую панель управления — выбираете конфигурацию, пополняете баланс и начинаете работать.

Провайдер — официальный партнёр 1С по аренде программного обеспечения. Платформенные лицензии и конфигурации уровня ПРОФ и КОРП доступны прямо через Selectel: не нужно искать отдельного поставщика.

Облачные серверы

Облачные серверы подходят компаниям с непостоянной или растущей нагрузкой. Ресурсы масштабируются по мере необходимости, оплата — по фактическому потреблению. Инфраструктура соответствует 152-ФЗ (УЗ-1), PCI DSS и GDPR. SLA — до 100%.​

Для управления серверами доступны панель управления, API, Terraform и KVM. Если у вас есть DevOps или системный администратор, настроить инфраструктуру под 1С можно с тем инструментарием, с которым команда уже работает.

Выделенные серверы

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

Железо и дата-центры

Selectel использует высокочастотные процессоры и NVMe SSD-диски. Дата-центры сертифицированы по уровню Tier III: резервирование электропитания, защита от пожаров, климат-контроль. Физическая инфраструктура обеспечивает базу для предсказуемой работы 1С — особенно при многопользовательской нагрузке, когда диски и процессор работают на полную.

Экосистема и интеграции

Помимо серверов, в рамках одной инфраструктуры доступны: управляемые базы данных, Managed Kubernetes, резервное копирование, защита от DDoS, балансировщик нагрузки, глобальный роутер и DNS. Если 1С интегрируется с другими сервисами — CRM, складским учётом, интернет-магазином — всё это можно развернуть внутри одной сети с минимальными задержками.

Для каких сценариев подходит

• Облачные серверы — компании с переменной нагрузкой, которым нужна гибкость и оплата по факту
• Выделенные серверы — крупные компании со стабильной высокой нагрузкой, строгими нормативными требованиями и запросом на максимальную производительность

Как начать и сколько стоит

Зарегистрируйтесь в панели, выберите формат сервера и конфигурацию. Стоимость зависит от выбранных ресурсов, тарифы и калькулятор — на сайте. Если переезжаете от другого провайдера или с on-premise, инженеры Selectel готовят план миграции и сопровождают на всех этапах. Бонусы на переезд — до 1 000 000 рублей.

5. Beeline Cloud — телеком-провайдер с Enterprise-подходом к 1С

Beeline Cloud — облачное подразделение телеком-оператора с фокусом на корпоративный сегмент. Для 1С здесь предлагают выделенную инфраструктуру и специализированный продукт "1C Cloud Pro" — отказоустойчивое решение для высоконагруженных систем.​

Формат работы построен для компаний, которым важен комплексный подход: миграция под ключ, защита от кибератак, выделенные каналы связи между ЦОД и офисом, круглосуточная поддержка с понятными SLA.​

Линейка продуктов под разные задачи

Конкретный продукт под 1С у Beeline Cloud — Cloud 1C, специализированное облако с выделенной инфраструктурой для проектов любой сложности.​

Что входит в Cloud 1C

Провайдер берёт на себя весь процесс: от переезда до настройки и поддержки.​

• Выделенная платформа — готовая инфраструктура для реализации проекта, без дележа ресурсов с соседями
• Быстрый переезд — перенос проекта 1С в облако от 1 дня
• Бесплатная настройка — конфигурацию берёт на себя провайдер
• Высокая мобильность — удалённый доступ к 1С для нужных сотрудников из любого места

Техническая база

Инфраструктура построена на высокопроизводительных серверах Cisco и HP, системах хранения данных HP и Infinidat, процессорах Intel Xeon Gold нового поколения. Комплексный подход включает выделенные каналы связи, ежедневное резервирование данных и мониторинг производительности.​

Безопасность и SLA

Инфраструктура аттестована по 152-ФЗ на уровне УЗ-1. SLA — 99,95% с финансовыми гарантиями, техподдержка 24/7. Проекты, требующие соответствия ФЗ-152, размещаются в отдельном аттестованном контуре.​

Для каких сценариев подходит

Beeline Cloud выделяет три основных сценария использования Cloud 1C:​

• Снижение расходов — готовая инфраструктура без капитальных затрат на оборудование
• Масштабирование ресурсов — облако гибко масштабируется под текущую нагрузку
• Защита персональных данных — размещение в аттестованной по УЗ-1 инфраструктуре для компаний с требованиями регуляторов

Формат Enterprise означает, что провайдер работает с крупными проектами и понимает специфику корпоративных требований. Не универсальное облако для всех, а решения под конкретные задачи бизнеса.

Как начать

Заходите на сайт, оставляете заявку — команда предложит решение или рассчитает стоимость сервиса. Можете сразу указать, какой формат нужен: публичное облако, частное, выделенный кластер или специализированное решение для 1С.​

Стоимость рассчитывается индивидуально в зависимости от выбранного продукта и конфигурации. Калькулятор доступен на сайте, но для точной оценки лучше обсудить задачи с техническими специалистами.​

База знаний, кейсы, вебинары — всё доступно на сайте.

Что выбрать

Провайдеры решают одну задачу, но по-разному.

Yandex Cloud — для тех, кто хочет использовать PostgreSQL на Linux и строить аналитику через экосистему Яндекса.

MWS — когда нужно всё сразу: инфраструктура, поддержка пользователей и аренда лицензий. Один договор вместо трёх подрядчиков.

Selectel — готовая платформа из коробки. Создали кластер, сразу работаете. Миграция за 1 рубль.

Beeline Cloud — для корпораций с требованиями к отказоустойчивости, защищённым каналам связи и 152-ФЗ УЗ-1.

ITGLOBAL.COM — специализированный ERP‑кластер на базе Intel Xeon Platinum Gen 5, оптимизированный под нагрузки 1С. Решение построено на All‑Flash NVMe‑дисками, DDR5‑памятью и без переподписки процессоров (1vCPU:1pCPU), поэтому вы получаете производительность на уровне физического сервера.

Инфраструктура, поддержка пользователей и аренда лицензий — ITGLOBAL.COM предлагает всё в рамках одного договора, через «единое окно».

Если 1С — критичная система и нужна доказанная производительность, смотрите на специализированные кластеры. Если важнее экосистема сервисов или быстрый старт — выбирайте по задачам.

Мы собрали актуальный список облачных GPU-сервисов на 2026 год. Изучили доступные архитектуры, реальную производительность и особенности биллинга разных платформ.

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

IaaS-платформа с иммерсионным охлаждением immers.cloud

В immers.cloud можно арендовать виртуальные машины и bare metal-серверы под ресурсоемкие задачи. Сервис ориентируется на обучение нейросетей, работу с LLM, инференс, 3D-рендеринг, обработку видео и сценарии, где локального железа уже мало, а покупать собственный парк серверов пока рано.

Инфраструктура размещена в Москве, в дата-центре уровня Tier-III. Базовый формат работы здесь классический для IaaS: пользователь поднимает ВМ или выделенный сервер и дальше сам собирает нужную среду под свою задачу.

Какие GPU доступны

У платформы собран пул из 13 моделей видеокарт NVIDIA под разные нагрузки. Для ML-задач с большим потреблением памяти доступны H200 на 141 ГБ и H200 на 141 ГБ с NVLink, H100 на 80 ГБ и на 94GB с NVLink, A100 на 80 ГБ и Tesla V100 на 32 ГБ. Отдельно отметим, пожалуй, H100 и A100 с поддержкой GPUDirect и NVLink. Для задач, где нужен быстрый обмен данными между ускорителями, это полезная штука.

Если речь идет о небольших моделях, агентных сценариях или более легком инференсе, доступны Tesla T4 на 16 ГБ, A2 на 16 ГБ, A10 на 24 ГБ и RTX 3080 на 10 ГБ. Для рендеринга, графических задач и смешанных вычислений можно арендовать RTX 2080 Ti на 11 ГБ, RTX 3090 на 24 ГБ, RTX A5000 на 24 ГБ, RTX 4090 на 24 ГБ или RTX 5090 на 32 ГБ.

Под какие сценарии подходит, как используют

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

1. Если ML-стартапу нужно развернуть MVP или проверить гипотезу, нет смысла сразу брать флагманы. Под пилоты обычно поднимают инстансы среднего ценового сегмента — например, с RTX 3090, RTX 4090 или Tesla V100. Стенд обходится в 65–100 ₽ за час работы и позволяет тестировать модели без капитальных затрат на железо.
2. Для R&D-команд, которые занимаются файн-тюнингом и обучением LLM, критичен объем видеопамяти. Адаптация предобученных моделей (в том числе через подготовку LoRA) уходит на тяжелые конфигурации с H200, H100 или A100.
3. Когда модель готова, её выносят в продакшн для стабильного инференса по API. Здесь выбор железа зависит от аппетитов самой нейросети: легкие модели и агенты спокойно крутятся на Tesla T4 или A10 (от 20 до 40 ₽/час), а высоконагруженные сервисы с крупными LLM забирают мощности с A100.
4. Для потоковой обработки видео, задач компьютерного зрения и 3D-рендеринга собирают стенды на профессиональных картах вроде RTX A5000 или топовых RTX 5090.

Как устроена инфраструктура и экосистема

ML-команды больше не упираются в доступность GPU на рынке, они упираются в то, сколько стоит время экспериментов и насколько быстро можно масштабировать обучение и инференс без потери контроля над инфраструктурой.

Технически платформа immers.cloud — это инфраструктурный слой на базе OpenStack. Здесь пока нет управляемого Kubernetes-сервиса, а вся работа строится вокруг виртуальных машин. С одной стороны, придется собирать окружение на ВМ самостоятельно. С другой — это дает понятную модель управления, где можно поднимать ресурсы строго под свою сборку и не бороться с абстракциями, которые навязывает провайдер.

Чтобы снять часть рутины с настройкой среды, есть маркетплейс готовых образов. Там лежат преднастроенные шаблоны с CUDA, PyTorch, TensorFlow и Jupyter.

Отдельно развернут Immers Foundation Models — каталог моделей, который закрывает сразу два этапа разработки: от выбора модели до первого запуска. Для прототипирования и проверки гипотез доступны бесплатные публичные эндпоинты. Инженер просто прокидывает токен и адрес модели в код, собирает MVP и тестирует логику продукта без затрат на инфраструктуру.

Когда сервис протестирован и готов к нагрузкам, команда переезжает на выделенные мощности. Для этого в каталоге предусмотрен запуск нужной модели «одной кнопкой». Система сама оценивает требования к VRAM и разворачивает подходящую GPU-конфигурацию.

Каталог сокращает путь и делает проще запуск: инженеру не нужно вручную проверять совместимость, подбирать GPU-конфигурацию и оценивать требования к VRAM под разные сценарии инференса. Вместо разных репозиториев и документации команда получает готовую точку входа для быстрого тестирования моделей, оценки стоимости запуска и развёртывания собственного inference-стека.

Для работы с датасетами и промежуточными артефактами к платформе подключено S3-совместимое объектное хранилище, за которое сейчас не берут плату.

Автоматизация и DevOps

Инфраструктуру можно поднимать не только руками через веб-консоль, но и встраивать в привычный инженерный контур. У сервиса есть CLI через openstack-client и Terraform-провайдер OpenStack. Managed Kubernetes находится в разработке, поэтому оркестрация контейнеров из коробки пока недоступна.

Тарификация

У платформы собран пул из 13 моделей видеокарт NVIDIA под разные нагрузки. Для ML-задач с большим потреблением памяти доступны H200 на 141 ГБ и H200 на 41 ГБ с NVLink, H100 на 80 ГБ и на 94GB с NVLink, A100 на 80 ГБ и Tesla V100 на 32 ГБ. Отдельно отметим, пожалуй, H100 и A100 с поддержкой GPUDirect и NVLink. Для задач, где нужен быстрый обмен данными между ускорителями, это полезная штука.

Если речь идет о небольших моделях, агентных сценариях или более легком инференсе, доступны Tesla T4 на 16 ГБ, A2 на 16 ГБ, A10 на 24 ГБ и RTX 3080 на 10 ГБ. Для рендеринга, графических задач и смешанных вычислений можно арендовать RTX 2080 Ti на 11 ГБ, RTX 3090 на 24 ГБ, RTX A5000 на 24 ГБ, RTX 4090 на 24 ГБ или RTX 5090 на 32 ГБ.

На платформе действует посекундная тарификация — оплата списывается только за фактическое время работы инстанса. Прерываемых (spot) машин нет.

Самая доступная конфигурация собирается на Tesla T4 16 ГБ (шаблон teslat4-1.4.8.60). Вместе с 4 vCPU, 8 ГБ RAM и сетью она обходится в 19,93 ₽ за час работы.

Стоимость других младших инстансов за час: A2 — 21,94 ₽, RTX 2080 Ti — 25,05 ₽, A10 — 36,55 ₽, RTX 3080 — 42,96 ₽.

Средний сегмент за час аренды: RTX 3090 — 66,76 ₽, RTX 4090 — 82,76 ₽, Tesla V100 — 96,61 ₽, RTX A5000 — 109,77 ₽, RTX 5090 — 130,76 ₽.

Тяжелые конфигурации в час: A100 — 211,77 ₽, H100 — 341,77 ₽, H100 NVL — 367,41 ₽, H200 — 423,04 ₽.

Для долгосрочных заказов предусмотрена скидка от 10 до 50%, а списания при таком формате происходят раз в сутки.

Особенности железа

Ключевая особенность площадки — использование иммерсионного охлаждения. Серверное оборудование полностью погружается в диэлектрическую жидкость. Это помогает держать стабильно низкую температуру GPU, исключает риск троттлинга и сохраняет производительность на длинных сессиях с высокой нагрузкой. Провайдер первым в России внедрил технологию виртуализации для этих графических процессоров.

Ограничения и безопасность

Формат работы на платформе подойдет инженерам, которые умеют собирать окружение на ВМ и работать с OpenStack-логикой. Полноценной managed ML-платформы и онбординга для ML-команд здесь нет.

Инфраструктура имеет сертификат ГОСТ Р ИСО/МЭК 27001-2021 по системам менеджмента информационной безопасности, но не соответствует требованиям 152-ФЗ. Это стоит учитывать при работе с персональными данными.

Поддержка и условия работы

Вся базовая документация собрана в подробном FAQ на русском языке. Техническая поддержка отвечает в течение 20 минут через чат на сайте, Telegram, Max или email.

Юрлицам доступна работа по договору, предоставление закрывающих документов и постоплата. Для новых клиентов предусмотрен триальный баланс на проверку гипотез и первый прогон пайплайнов.

Инфраструктура для high-load и ML-проектов ITGLOBAL.COM

На ITGLOBAL.COM разворачивают GPU-инфраструктуру для машинного обучения, высокопроизводительных вычислений (HPC), рендеринга и сложной аналитики. Форматов несколько: классические облачные инстансы, выделенные серверы, гибридные схемы и аренда суперкомпьютера на базе NVIDIA HGX. Платформа заточена под команды, которым нужны серьезные мощности Enterprise-уровня без капитальных затрат на закупку собственного железа.

Какие GPU доступны

В пуле провайдера стоят актуальные корпоративные решения. Главная техническая фича — поддержка vGPU. Физическую видеокарту можно делить между несколькими виртуальными машинами — части изолированы друг от друга, так что данные одной ВМ недоступны другим. Теперь ресурсы масштабируются только под задачу, а команда не переплачивает за ненужные мощности.

Например, NVIDIA RTX Pro 6000 Blackwell Server Edition на 96 ГБ можно нарезать на профили по 12, 24, 48 ГБ или забрать все 96 ГБ под одну ВМ. Для более тяжелых задач доступны инстансы с H200 на 141 ГБ и флагманские B300 на 288 ГБ.

Также в пуле есть A100 и A800 (по 80 ГБ), L40S на 48 ГБ, серверы с NVIDIA A16 (четыре чипа по 16 ГБ) и ускорители Sophgo SC7 HP75. Мощности Enterprise-уровня всегда держат в наличии под высоконагруженные проекты.

География и форматы размещения

Инфраструктура ITGLOBAL.COM размещена в Москве, Минске, Алматы, Ташкенте, Шэньчжэне, Амстердаме, Торонто, Нью-Джерси, Дубае и Сан-Паулу. Если проект требует строго локального размещения или интеграции с внутренним контуром безопасности, провайдер может выдать инфраструктуру с GPU прямо на площадку клиента.

Под какие задачи подходит

Ресурсы забирают под разные этапы для работы с данными. Команды Data Science обучают модели скоринга, прогнозирования оттока или рекомендательные алгоритмы на NVIDIA H200 и NVIDIA RTX PRO 6000 Blackwell Server Edition хорошо тянут видеоаналитику и Computer Vision для промышленных и логистических объектов, где нужно анализировать плотные видеопотоки.

Если речь идет про инференс LLM или запуск AI-приложений в high-load сценариях, инженеры обычно поднимают ресурсы уровня NVIDIA HGX H200 или кластеры NVIDIA HGX B300. Ограничений на фреймворки, оркестраторы или объем данных со стороны платформы нет. Клиент получает IaaS с полным контролем над средой, упираясь только в архитектурные лимиты самих чипов NVIDIA и поддерживаемые драйверы.

Как устроена инфраструктура и экосистема

Для управления ресурсами доступны API, CLI и возможность использования terraform провайдера, поэтому поднимать и гасить инстансы можно программно. Преднастроенные стеки с CUDA, PyTorch, TensorFlow или Jupyter собираются и уточняются на старте под конкретный проект. Для команд, которые хотят снять с себя часть инфраструктурной рутины, доступен Managed Kubernetes и управляемая ML-платформа.

Для хранения объемных датасетов и работы с данными предусмотрен отдельный S3-совместимый сервис объектного хранилища.

Тарификация и условия

Жесткой публичной сетки тарифов за час здесь нет — провайдер работает по проектному ценообразованию. Итоговый чек зависит от модели GPU, конфигурации, сроков аренды и формата размещения. Прерываемых (spot) инстансов не предусмотрено, зато для долгосрочных и крупных проектов действуют индивидуальные скидки.

Пользователь сам управляет ресурсами и может собрать нужную конфигурацию. Рекомендуемая минимальная сборка включает 12 ГБ vGPU, 4 vCPU и 16 ГБ оперативной памяти. При необходимости параметры можно ужать до базового минимума: 12 ГБ vGPU, один vCPU (Xeon 2.8 ГГц), гигабайт RAM и гигабайт быстрого SSD (с возможностью добавить HDD).

Оплата для юрлиц по умолчанию идет в формате постоплаты по договору с предоставлением всех закрывающих документов. Для тестирования гипотез новым клиентам открывают триальный период.

Безопасность и соответствие

Облако имеет аттестат соответствия требованиям 152-ФЗ. Также компания обладает сертификатами ФСТЭК и ФСБ. Все лицензии и документы выложены в открытом доступе на сайте.

Поддержка и документация

Влиться в работу помогает пресейл-команда: инженеры проводят проектный онбординг и помогают собрать нужную конфигурацию под конкретные ML-задачи. Техническая документация полностью доступна на русском языке.

Первичные запросы обрабатывают в течение двух часов. Оставить заявку можно через сайт, почту sales@itglobal.com, по телефону +7 812 439 18 72 или через Telegram-бота. Действующие клиенты решают вопросы через личного менеджера, клиентский портал, облачную панель или выделенную почту support@itglobal.com.

Кастомные GPU-серверы и Managed-сервисы от Selectel

В Selectel можно арендовать облачные инстансы и bare-metal серверы под ML-задачи, инференс, работу с графикой и сложные вычисления. Провайдер дает возможность гибко собрать нужную инфраструктуру: от быстрой аренды облачной ВМ на час до сборки кастомных физических серверов на базе процессоров Intel Xeon Scalable и AMD EPYC.

Базовый формат работы здесь строится вокруг классических серверов, но платформа позволяет объединять разные сервисы провайдера в сложную инфраструктуру и делегировать администрирование части слоев (например, баз данных).

Какие GPU доступны

У платформы собран широкий пул профессиональных и консьюмерских видеокарт NVIDIA под разные нагрузки. Для тяжелых ML-задач доступны NVIDIA A100 (в том числе в конфигурации на 40 ГБ) и NVIDIA V100. Из свежего железа в пуле есть NVIDIA A30.

Если речь идет о небольших моделях, агентных сценариях или более легком инференсе, доступны Tesla T4, A2 и консьюмерская линейка — GTX 1080, RTX 2080 Ti и RTX 4090. Для рендеринга, графических задач и рабочих станций VDI можно арендовать профессиональные RTX A2000, A4000 и A5000.

Под какие сценарии подходит, как используют

Платформу чаще используют под конкретные инфраструктурные задачи и этапы разработки:

Для R&D-команд, которые занимаются машинным обучением, файн-тюнингом и глубоким обучением (Deep Learning), берут тяжелые конфигурации с A100 или A30. Мощности позволяют быстро обучать нейросети под классификацию изображений, распознавание речи (face recognition) и проверку на фрод.

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

Отдельный пласт задач — транскодинг видео и работа с графикой. На серверах с GPU разворачивают среды для стриминга (с поддержкой NVIDIA NVENC и разрешением до 8192×8192), 3D-моделирования, видеомонтажа онлайн и развертывания удаленных рабочих мест (VDI). Также инфраструктуру применяют для научного моделирования и сложных параллельных CUDA-вычислений в инженерии, физике и математике.

Как устроена инфраструктура и экосистема

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

Для тех, кто не хочет возиться с голой инфраструктурой, у Selectel есть готовые PaaS-решения. В первую очередь это Managed Kubernetes — он упрощает развертывание контейнеров, масштабирование, настройку микросервисной архитектуры и CI/CD пайплайнов (от 5 958 ₽/мес). Также провайдер берет на себя администрирование облачных баз данных вроде PostgreSQL и Timescale.

Для работы с датасетами, весами и бэкапами к платформе подключается S3-совместимое объектное хранилище (от 0,81 ₽/мес) с тройной репликацией данных. Для сложной инфраструктуры можно использовать файловое хранилище (от 138 ₽/мес) и объединять локальные и облачные сети через глобальный роутер или Direct Connect.

Автоматизация и DevOps

Инфраструктуру можно поднимать не только руками через панель управления Selectel, но и встраивать в инженерный контур с помощью API.

Тарификация

Аренда доступна на гибких условиях: серверы можно брать на час, день или месяц. Точная стоимость зависит от выбранной конфигурации и типа аренды (облако или выделенный сервер). Для облачных решений есть оплата только за потребленные ресурсы.

Ограничения и безопасность

Selectel делает сильный упор на защиту данных. Серверы соответствуют требованиям 152-ФЗ до первого уровня защищенности. Инфраструктура имеет сертификат PCI DSS, ISO 27001, аттестаты ГИС К1 и СТР-К 1Г. Это значит, что на серверах можно хранить чувствительные персональные данные, медицинскую информацию и данные платежных карт.

Дополнительно в Selectel работает IAM-система для разграничения доступов и ролей, которую можно связать с внутренним SSO. Все проекты бесплатно получают базовую защиту от DDoS-атак на уровнях L3 и L4. Если нужна защита серьезнее, можно подключить фильтрацию трафика на уровне приложений L7 (от 2 600 ₽/мес).

Глобальная GPU-инфраструктура и гранты на тесты от Timeweb Cloud

На Timeweb Cloud можно арендовать облачные и выделенные серверы под параллельные вычисления: машинное обучение, аналитику бигдаты, 3D-рендеринг, IoT и гейминг. Инфраструктура развернута в дата-центрах уровня Tier III в России, СНГ, Европе и США. Провайдер делает ставку на быстрый старт — облачные инстансы поднимаются за пару минут, а вычислительные ресурсы можно быстро масштабировать.

Какие GPU доступны

Вычислительный парк провайдера построен исключительно на графических процессорах NVIDIA. Под тяжелые AI-вычисления, работу с бигдатой и профессиональное ПО предоставляются серверы с GPU серии A: A2, A30, A2000, A4000, A5000 и A6000. Для виртуализации и ML-сценариев в облаке доступна Tesla T4.

Для гейминга, стриминга и рендеринга можно арендовать серверы на базе GeForce GTX (1080 DDR5X, 1080 Ti) или RTX с поддержкой тензорных и рейтрейсинг-ядер (2080 Ti, 3080, 3090, 4090).

Топовые корпоративные ускорители под крупные модели — Tesla H200 (141 ГБ), H100 (80 ГБ), A100 (80 ГБ) и L4 (24 ГБ) — пока предоставляются в формате предзаказа.

Под какие сценарии подходит, как используют

Платформу применяют под конкретные инфраструктурные задачи и этапы разработки:

Для ИИ и машинного обучения берут инстансы под обучение нейросетей, deep learning, сборку рекомендательных систем, чат-ботов и распознавание речи и изображений. Здесь в ход идут карточки Tesla T4 и решения серии A.

Для 3D-моделирования, анимации, архитектурного дизайна и трансляции игрового процесса в реальном времени собирают стенды на консьюмерских RTX или профессиональных видеокартах. Они закрывают потребности в рендеринге сложной графики без закупки собственных дорогих рабочих станций.

Отдельный пласт задач — научные вычисления и аналитика бигдаты. Мощности арендуют под прогноз климата, изучение генома, моделирование физических процессов и обработку данных с IoT-устройств (беспилотного транспорта, умных домов, производственных конвейеров).

Как устроена инфраструктура и экосистема

Архитектура облака построена с тройным региононезависимым резервированием. Это собственная разработка провайдера, которая снижает риск потери данных при локальных сбоях.

Помимо ВМ, в экосистему входят Managed-сервисы. Для оркестрации контейнеров можно развернуть Managed Kubernetes. Для хранения весов моделей и датасетов есть S3-совместимое объектное хранилище и облачные базы данных. Также в пуле сервисов доступны балансировщики нагрузки и маркетплейс. Если команда не хочет тратить время на перенос инфраструктуры, инженеры провайдера берут миграцию данных на себя.

Автоматизация и DevOps

Управлять ресурсами можно через веб-панель или программно, встраивая запуск в инженерный пайплайн. Для этого доступны классические инструменты автоматизации: API, CLI, Terraform и Cloud-init.

Тарификация

Тарифы формируются за месяц, но оплата работает по часовой модели — деньги списываются раз в час за реально потребленное время. В любой момент можно добавить процессоры (vCPU), оперативную память (RAM) или диски без простоя системы.

Для проверки гипотез и тестирования среды предусмотрен грант до 1 000 000 ₽ на срок до шести месяцев. Это позволяет обкатать архитектуру перед финальным решением о переезде.

Ограничения и безопасность

Особенность площадки — широкая география присутствия. Дата-центры стоят в Москве, Санкт-Петербурге, Сибири, Казахстане, Нидерландах, Германии, Турции, Финляндии и Нью-Йорке.

Платформа включена в Единый реестр российского ПО, соответствует требованиям 152-ФЗ, международного стандарта PCI DSS и ISO. Облако по умолчанию защищено от DDoS-атак, при необходимости фильтрацию можно точечно усилить на уровнях L3, L4 и L7.

Поддержка и условия работы

Техническая поддержка работает в режиме 24×7×365. Для проектов с бюджетом от 50 000 ₽ в месяц включается премиум-обслуживание: прямая связь с топ-менеджментом (CEO, CTO), ответы в режиме ASAP, возможность овердрафта и повышенные скидки.

Виртуальные серверы с GPU для машинного обучения от Cloud4Y

В Cloud4Y можно арендовать облачные GPU-серверы с видеокартами NVIDIA. Инфраструктура заточена под машинное обучение (ML), искусственный интеллект (AI), параллельные вычисления, работу с большими данными и 3D-графикой. Виртуальные инстансы помогают командам ускорить обработку датасетов и тренировку нейронных сетей без закупки собственного железа.

Какие GPU доступны

Cloud4Y делает ставку на проверенные корпоративные решения. Для машинного обучения, работы с графикой и высокопроизводительных вычислений (HPC) платформа предлагает видеокарты NVIDIA Tesla V100 и NVIDIA Tesla P100.

Ресурсы предоставляются по модели vGPU. Доступны конфигурации с разным объемом видеопамяти под конкретные задачи — например, P100 с 8 ГБ или 16 ГБ, а также V100 с 1 ГБ или 2 ГБ видеопамяти на борту.

Под какие сценарии подходит, как используют

Платформу применяют под ресурсоемкие задачи, где мощностей центрального процессора уже не хватает. Графические процессоры увеличивают скорость вычислений до 8 раз по сравнению с CPU.

Для задач Data Science и обучения нейросетей (Deep Learning) мощности берут под сборку алгоритмов и анализ больших массивов данных. Инстансы можно использовать для разработки приложений виртуальной и дополненной реальности, а также для параллельных вычислений на базе архитектуры CUDA.

Отдельный сценарий — 3D-графика, транскодинг видео и рендеринг. Для этих задач на облачных серверах поднимают удаленные рабочие столы по технологии VDI (Virtual Desktop Infrastructure). Ресурсы vGPU равномерно распределяются между сессиями пользователей, а доступ к рабочему месту с графикой идет через стандартный RDP-клиент.

Как устроена инфраструктура и экосистема

Чтобы сократить время от аренды до первого запуска модели, у Cloud4Y есть готовые образы — DSVM (Data Science Virtual Machine). Серверы разворачиваются с уже предустановленными пакетами приложений: PyTorch, TensorFlow, Keras, XGBoost, Scikit-learn, OpenCV и Jupyter Notebooks.

Также из коробки доступны библиотеки NumPy и Pandas для ускорения процесса обучения. Для сложной оркестрации ML-процессов провайдер может развернуть готовый шаблон с Kubeflow.

В экосистему платформы входит S3-совместимое объектное хранилище, облачные базы данных и сервис Managed Kubernetes. Для надежности предусмотрено резервное копирование в облако и услуга Disaster Recovery (аварийное восстановление).

Тарификация

Арендовать графические мощности можно с почасовым или помесячным биллингом. Расчет стоимости по итогу месяца идет с округлением до целых единиц в большую сторону. Сама услуга vGPU приобретается как дополнение к базовой IaaS-инфраструктуре (облачному серверу). Бесплатно предоставляется интернет-канал на 100 Mbps с возможностью расширения до 1 Гбит/с.

Стоимость зависит от выделенного объема видеопамяти и ресурсов сервера:

• Базовый вариант для VDI и графики (NVIDIA GRID P100 ML vGPU) начинается от 3,39 ₽ за час.
• Конфигурация под вычисления с V100 1 Gb (6 vCPU, 64 RAM, 120 SSD) обойдется от 25 ₽ за час.
• Инстанс с P100 8 Gb (4 vCPU, 32 RAM, 120 SSD) стоит от 24,5 ₽ за час.
• Более тяжелая сборка с P100 16 Gb (16 vCPU, 64 RAM, 120 SSD) тарифицируется от 46 ₽ за час.

Аренда облачного железа позволяет сократить расходы на оборудование до 70%. Если текущих конфигураций недостаточно, провайдер может собрать GPU-сервер по индивидуальному запросу.

Поддержка и условия работы

Доступ к графическим ресурсам и серверам возможен круглосуточно из любой точки мира. Для тестирования гипотез новым клиентам предоставляют бесплатный тестовый доступ.

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

Если проект находится на стадии проверки гипотез и вам нужно быстро добежать до инференса без возни с настройкой окружения, логично смотреть в сторону площадок вроде immers.cloud. Там фокус смещен на снятие рутины через готовые хабы моделей и стабильную работу железа под нагрузкой. Когда же продукт обрастает энтерпрайз-требованиями и требует развертывания тяжелых кластеров с прицелом на глобальный рынок, инфраструктурный подход меняется, и здесь можно посмотреть в сторону решений ITGLOBAL.COM.

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

Историю обнародовал журналист Брайан Кребс в материале от 18 мая по наводке исследователя из GitGuardian. Репозиторий назывался без лишней скромности — Private-CISA — и был виден любому, кто откроет GitHub.

• Подрядчик CISA с 13 ноября 2025 года вёл публичный репозиторий Private-CISA размером 844 МБ с паролями, ключами AWS GovCloud, сертификатами Entra ID SAML и Kubernetes-манифестами.
• Пароли лежали в открытом виде в CSV-файле, а среди файлов был importantAWStokens с админ-доступом к трём серверам AWS GovCloud.
• Чтобы такое стало возможным, в аккаунте было выключено стандартное правило GitHub, блокирующее коммиты с секретами.
• GitGuardian называет утечку «худшей в карьере» исследователя, но CISA утверждает, что «нет признаков компрометации чувствительных данных».
• Репозиторий закрыли вечером 15 мая 2026 года, спустя около 26 часов после уведомления исследователей — но он был публичным около полугода.

Что лежало в Private-CISA

GitGuardian, компания, у которой сканер постоянно обходит публичные репозитории GitHub в поисках утёкших секретов, наткнулась на репозиторий 14 мая 2026 года. По объёму это 844 МБ — 498 МБ в рабочем дереве, остальное в истории Git. Среди папок и файлов исследователи нашли:

• importantAWStokens — административные токены к трём серверам AWS GovCloud (изолированный облачный регион Amazon для госструктур США).
• AWS-Workspace-Firefox-Passwords.csv — экспорт сохранённых паролей Firefox с десятками логинов и паролей от внутренних систем CISA в открытом виде.
• CAWS GitHub Token.txt — отдельный токен GitHub-организации.
• Kube-Config.txt — конфигурации Kubernetes для доступа к кластерам.
• Папку ENTRA ID — SAML Certificates с сертификатами для единого входа через Microsoft Entra ID.
• Папки All Backups, Backup-April-2026, LZ-Artifactory, Kubernetes-Important-Yaml-Files — внутренние бэкапы, манифесты ArgoCD и YAML-файлы с секретами.
• Terraform-код инфраструктуры и GitHub Actions, описывающие, как CISA собирает, тестирует и выкатывает свой софт.
• Резервные копии внутренней документации в форматах OneNote и DOCX, плюс скрипты для GitHub, Kubernetes, ArgoCD.

Один из попавших в репозиторий хостов назывался LZ-DSO — по словам исследователей это сокращение от Landing Zone DevSecOps, то есть от среды, в которой CISA «безопасно» собирает свой код. Иронично: ключи от пайплайна, который должен защищать всё остальное, лежали публично.

Это худшая утечка, которую я видел за свою карьеру.

Сначала команда GitGuardian приняла находку за розыгрыш: слишком уж красноречивые названия папок и файлов. Но личные документы, имена хостов и аккуратная структура повторных бэкапов убедили — это рабочая копия чьего-то ноутбука, которую регулярно «синхронизировали» через git push в открытый репозиторий.

Как нашли и сообщили

Согласно подробному разбору GitGuardian, программа Good Samaritan компании первой обнаружила утечку и автоматически отправила девять писем владельцу коммитов. К утру 15 мая в ответ пришли только автоответчики.

Тогда исследователи связались с Брайаном Кребсом, чтобы он передал утечку напрямую своим контактам в CISA. Параллельно подключились партнёры с прямой линией в агентство. Около 16:00 по центральноевропейскому времени удалось дозвониться, а в районе 18:00 по восточному времени США репозиторий стал недоступен. От первого выявленного слива до закрытия прошло чуть больше суток — но создан репозиторий был 13 ноября 2025 года, так что окно для злоумышленника составляло около полугода.

Хронология

• 13 ноября 2025 — создан публичный репозиторий Private-CISA, первые секреты залиты.
• 13 мая 2026 — автоматический сканер GitGuardian Good Samaritan уже успел отправить владельцу репозитория девять писем-предупреждений.
• 14 мая 2026, 16:14 CET — GitGuardian фиксирует инцидент и подаёт его в CERT/CC (координационный центр по реагированию на киберинциденты), параллельно ища личные контакты в CISA.
• 15 мая 2026 — GitGuardian параллельно выходит на Кребса для эскалации через его контакты и на собственных партнёров с прямой линией в агентство; около 16:00 CET до CISA дозваниваются.
• 15 мая, около 18:00 EST — репозиторий удалён.

Почему secret scanning не сработал

GitHub давно предлагает push protection — функцию, которая не даёт залить в публичный репозиторий распознанные секреты вроде токенов AWS, ключей SSH или ключей API. Для бесплатных публичных репозиториев она включена по умолчанию с 2024 года. Но защита от дурака легко выключается одним кликом, и в случае с Private-CISA её действительно отключили — Кребс цитирует исследователей, которые нашли в истории коммитов следы того, что владелец аккаунта вручную убрал блокировку секретов.

Это распространённый паттерн: разработчик сталкивается с блокировкой пуша, не разбирается, почему сработала защита, и снимает её через настройки. Иногда — в личном репозитории «для удобства», иногда — потому что коммит уже содержит что-то более чувствительное, чем тестовый ключ. Результат предсказуем: репозитории, в которых годами лежат «временные» .env-файлы с продакшен-доступами, и автоматические сканеры вроде GitGuardian, TruffleHog или GitHub Secret Scanning, которые рано или поздно их находят.

По версии Gizmodo, сотрудник подрядчика Nightwing использовал GitHub как личную папку «Загрузки»: коммитил файлы с рабочего ноутбука, чтобы открыть их на домашнем компьютере. То же самое многие делают через личную почту, только публичный репозиторий ещё хуже — он проиндексирован поисковиками и сканируется ботами в режиме реального времени.

Кто такая CISA и почему это важно

Особый цинизм истории — в том, кто оказался виновником. CISA (Cybersecurity and Infrastructure Security Agency) — молодое подразделение Министерства внутренней безопасности США, отвечающее за кибербезопасность всех федеральных гражданских сетей. Это именно та организация, которая публикует руководства про «никогда не храните пароли в спредшитах». При этом, по данным TechCrunch, у CISA с 20 января 2025 года нет постоянного директора, агентство потеряло около трети штата после сокращений и отпусков, а ни один временно исполняющий обязанности не был утверждён Сенатом. В таких условиях процессы по контролю подрядчиков и аудиту репозиториев предсказуемо проседают — и тот факт, что утечку у регулятора по кибербезу нашёл частный сканер, а не внутренние инструменты, красноречивее любого внутреннего отчёта.

Что делать в своей команде, чтобы не повторить историю CISA

История CISA читается как готовый чеклист «как не надо». Перевернём его в «как надо» — для команд от стартапа до крупного бизнеса.

1. Включите GitHub push protection на уровне организации и запретите её отключать. Owner organization → Security → Secret protection → Push protection: Enabled.
2. Запретите коммитеры-индивидуумам быть owner репозиториев в проде. Любой публичный репозиторий компании должен принадлежать организации с настроенными правилами.
3. Сканируйте свою историю, а не только новые коммиты. Один раз пропущенный .env остаётся в Git forever — поможет TruffleHog, GitGuardian, GitHub Advanced Security или встроенный git-secrets.
4. Не используйте Git как файлообменник между домашним и рабочим компьютером. Для этого есть VPN, корпоративный OneDrive, S3-бакет с IAM, в конце концов — scp.
5. Включите автоматическую ротацию ключей AWS и сервис-токенов. Даже если они утекут, окно использования закроется через сутки-двое.
6. Настройте мониторинг подозрительных вызовов API в облаке. Для AWS — CloudTrail + GuardDuty с алертами на новые регионы, необычные IAM-действия и обращения к AWS API из неизвестных IP. Если ключ всё-таки утёк — вы узнаете об этом по логам, а не из новостей.
7. Раз в квартал проводите аудит публичных репозиториев: gh repo list ORG --visibility public и быстрая проверка, что там должно лежать публично.

GitHub в своём блоге называет push protection первой линией защиты и приводит цифру: с момента включения по умолчанию на бесплатных публичных репозиториях функция предотвратила сотни тысяч случайных утечек. Эту настройку выключают именно те, кто потом попадает в новости.

Что говорят сами CISA и эксперты

Сводный ответ агентства для Кребса и TechCrunch звучит как стандартная PR-формула. TechCrunch уточняет, что комментарий дал пресс-секретарь CISA Марко ДиСандро:

На данный момент нет признаков того, что в результате инцидента были скомпрометированы чувствительные данные. Мы продолжаем расследование и работаем над дополнительными мерами защиты, чтобы предотвратить повторение подобных случаев в будущем.

Проблема в формулировке «нет признаков»: при шестимесячном окне публичности любые токены стоит считать скомпрометированными по умолчанию. Стандартный план действий — отозвать всё, выпустить новое, проанализировать логи AWS CloudTrail на предмет обращений с этих токенов и опубликовать честный разбор инцидента. До такого разбора инцидента публично CISA пока не дошла, и в TechCrunch агентство не ответило, отозваны ли ключи.

Что в итоге

Сюжет «подрядчик слил ключи в публичный git» повторяется в индустрии раз в пару месяцев, но обычно героем оказывается стартап или подрядчик банка. Случай с CISA выделяется тем, что виновником стало именно то агентство, которое выпускает рекомендации по защите от подобных утечек.

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

Для разработчиков вывод предельно практичный: включите push protection, проверьте свои публичные репозитории, не подсовывайте секреты в Git ни на минуту. История CISA — это просто очень громкая иллюстрация того, как один человек, перетаскивающий файлы с ноутбука на ноутбук через git, способен поставить под угрозу целое ведомство.

Источники: Krebs on Security — CISA Admin Leaked AWS GovCloud Keys on Github; GitGuardian Blog — How We Got a CISA GitHub Leak Taken Down in Under a Day; TechCrunch — US cyber agency CISA exposed reams of passwords and cloud keys to the open web; Gizmodo — «The Worst Leak That I've Witnessed».

Selectel, крупнейший независимый провайдер IT-инфраструктуры в России (более 33 000 клиентов, 17 лет на рынке), на этой конференции не только анонсировал новые продукты, но и предложил системный взгляд на то, как строить AI-инфраструктуру, чтобы она работала на бизнес, а не против него.

Главные анонсы Selectel: новый AI-сервер и развитие платформы

Первый и, пожалуй, ожидаемый анонс — новый высокопроизводительный AI-сервер Selectel. Решение разработано с акцентом на сбалансированную архитектуру. Сервер представляет собой 8U-платформу с собственной материнской платой, поддержкой двух процессоров Intel Xeon 6 (до 144 ядер) и возможностью установки до 8 ТБ оперативной памяти DDR5. Ключевая особенность — до 16 графических ускорителей на ноду и продуманная топология PCI-линий, минимизирующая задержки при передаче данных между CPU, памятью и GPU.

«Новая аппаратная платформа обеспечит стабильную, быструю и предсказуемую работу AI-моделей в реальных условиях с полным контролем над данными и производительностью», — прокомментировал Дмитрий Шиченко, руководитель отдела разработки встроенных систем Selectel.

Второй важный анонс касается AI-платформы Selectel. Обновлённый Foundation Models Catalog переведён в публичный статус и теперь доступен всем клиентам. Каталог позволяет разворачивать LLM на выделенной инфраструктуре с поддержкой автомасштабирования, получать логи и метрики инференса (observability), управлять сервисами через REST API. В качестве основного движка инференса используется vLLM — высокопроизводительный open-source фреймворк, увеличивающий производительность без роста затрат.

В каталог уже добавлены модели IBM Granite, Alibaba Qwen, DeepSeek, Microsoft Phi, Mistral AI, а в ближайшее время появятся Kimi, GLM, Gemma, Whisper и другие. Оплата сейчас идёт за фактические вычислительные ресурсы, а в ближайшее время станет доступна тарификация по токенам.

«Наша задача — обеспечить компаниям быстрый переход от экспериментов с AI к экономически эффективному применению. Мы предоставляем не просто "железо", а комплексный набор решений — от серверов c GPU до платформенных продуктов, закрывающих задачи пилотных проектов и промышленной эксплуатации», — отметил Александр Тугов, директор AI-вертикали Selectel.

Единое окно для внедрения ИИ-агентов

Ещё одно важное событие конференции — начало сотрудничества Selectel с российским вендором Data Sapience и консалтинговой группой GlowByte. Партнёры объявили о создании комплексных решений для корпоративных заказчиков: от бизнес-задачи до промышленной эксплуатации ИИ-агентов и больших языковых моделей.

В рамках партнёрства Selectel подтвердил технологическую совместимость инфраструктуры с платформой Kolmogorov AI от Data Sapience, которая обеспечивает полный цикл работы с моделями — от подготовки данных до мониторинга и оркестрации в промышленном контуре. Selectel предоставляет гибкую инфраструктуру (публичное и частное облако, аренду выделенных серверов, размещение GPU на площадке клиента, в том числе в аттестованных сегментах ЦОД), а GlowByte выступает интеграционным партнёром: консалтинг, архитектура, дообучение моделей и сопровождение.

Такой подход позволяет компаниям получать end‑to‑end предложение «из одного окна», сокращая время от пилота до реального внедрения и обеспечивая соответствие регуляторным требованиям. Решения ориентированы на автоматизацию сложных процессов, поддержку принятия решений, анализ больших данных и построение приватных ИИ-сред в условиях строгой безопасности.

«В партнёрстве с Data Sapience и GlowByte мы объединяем экспертизу инфраструктурного провайдера, вендора платформенных решений и консалтинговой компании, чтобы упростить компаниям путь к эффективному внедрению ИИ», — прокомментировал Александр Тугов.

Экосистема вокруг платформы: что обсуждали на техническом треке

Кроме докладов команды Selectel, на техническом треке выступили эксперты из других компаний. Своим опытом поделились:

• Антон Алексеев, MLOps-инженер AvitoTech рассказывал о построении централизованной ML-платформы;
• Владислав Шевченко, CTO red_mad_robot рассказывал про кризис SDLC и объяснял, почему нельзя просто написать код и ждать результата;
• Максим Пантелеев, руководитель направления Core M&D. Wildberries & Russ поделился последними результатами исследования интерпретируемости LLM по мотивам участия в сообществах и опыта работы над проектами red- и blue-teaming LLM.

Программа технического трека подтвердила главный тренд: ИИ-инфраструктура и платформенный подход становятся сквозной темой для разных отраслей.

Почему AI-инфраструктура — это не просто GPU

AI-инфраструктура не исчерпывается графическими ускорителями. В реальном пайплайне инференса LLM нагрузка распределяется между сетевыми картами, оперативной памятью, CPU (пред- и постобработка, токенизация, формирование батчей), PCI-шиной и только потом — GPU. Каждый этап может стать узким горлышком.

«Просто взять графический ускоритель и запустить на нём модель — это как поехать на болиде Формулы-1 по гравию. Двигатель мощный, но быстрее не станет», — пояснил Дмитрий Шиченко.

Именно поэтому при разработке нового AI-сервера в Selectel сделали упор на баланс ресурсов: процессоры последнего поколения с высокими частотами, 4 ТБ оперативной памяти на частоте 6400 МТ/с, высокоскоростные интерконнекты (до 128 ГБ/с между CPU и GPU, до 900 ГБ/с между GPU через NVLink). И топологию материнской платы с детерминированной архитектурой PCI-линий.

«Привычный закон Мура для AI больше не работает. У нас теперь закон Хуанга: GPU морально устаревают за 2 года, а не за 5–7. Амортизировать серверное железо по старым правилам — значит гарантированно проиграть по TCO», — считает Владислав Кирпинский, директор по облачной интеграции Selectel.

Как выглядит эффективный инференс на реальных задачах

Технические результаты наглядно показывают, что даёт сбалансированная архитектура.

Сценарий 1.

• Модель на 400 млрд параметров (Qwen 3.5), длинный контекст, сотни одновременных пользователей.
• Конфигурация: 8 × H100, 112 ядер CPU, 512 ГБ RAM.
  
• Результат: 500 токенов в секунду.
  

«При 150 токенах в секунду нейросеть уже отвечает быстрее, чем человек читает. А 500 токенов — это инференс с большим запасом для реальных Enterprise-нагрузок», поясняет Дмитрий Шиченко, руководитель отдела разработки встроенных систем Selectel.

Сценарий 2.

• Модель на 1 трлн параметров (Kimi k2, Mixture of Experts), ещё более длинный контекст, до 1000 пользователей.
• Конфигурация: RTX 6000 Pro Server Edition (увеличенный объём VRAM), 2 ТБ RAM.
  
• Результат: 150 токенов в секунду — более чем достаточно для диалоговых систем и ассистентов.
  

Итоги: AI-инфраструктура как стратегический актив

Конференция «MLечный путь» наглядно показала: рынок AI в России перешёл от экспериментов к промышленному внедрению. Но бизнес сталкивается с системными барьерами — от выбора правильного железа до построения платформ, которые позволяют масштабировать успешные пилоты.

Selectel на этом фоне предлагает комплексную историю:

• Инфраструктура — собственные сбалансированные AI-серверы, широкая линейка GPU (от потребительских до enterprise), гибкие модели потребления (BareMetal, облако, аренда на площадке клиента, гибрид).
• Платформа — Foundation Models Catalog в публичном доступе, observability, API‑управление, поддержка vLLM.
• Экспертиза — собственные инженеры, разработка серверов и материнских плат, независимость от поставщиков.
• Развитие направления партнерств с ведущими российскими AI-вендорами, обладающими экспертизой для решения отраслевых и специализированных бизнес-кейсов.
  

Как отметил один из спикеров конференции: «GPU без платформы — это кирка без рудника». Selectel же предлагает и кирку, и рудник, и карту местности. Для Enterprise это означает снижение рисков, предсказуемое TCO и возможность сфокусироваться на бизнес‑результатах, а не на том, почему инференс тормозит или почему GPU не окупаются за 5 лет.

AI‑инфраструктура перестаёт быть историей про «купить железо». Она становится историей про управляемость, экономику и скорость изменений. Именно этот переход — от GPU к платформе — стал главным итогом «MLечного пути».

Один такой кейс я помню особенно болезненно. Заказчик специально ушёл от «тяжёлых» платформ ради самописного решения: быстрее сроки, ниже чек на входе. Полгода спустя каталог перевалил за 10 000 позиций. Страницы открывались по 8–12 секунд, поиск фактически умер, обмен с учёткой превратился в ручной ад. В итоге пришлось пересобирать магазин на другой системе — и суммарно это стоило примерно в три раза больше, чем если бы выбрать нормальный фундамент сразу.

Вывод простой и непопулярный: для интернет-магазина CMS — это не «движок сайта», а контур бизнеса. Если он не тянет каталог, склады, оплаты и промо — экономия на старте превращается в налог на переделку.

Почему «красивая витрина» не спасает

Товар и дизайн важны. Но когда речь про оборот, в игру входят другие вещи: скорость выдачи каталога под нагрузкой, связка с 1С или CRM, гибкость скидок, безопасность оплат, возможность масштабировать без ручного копания в ядре.

Я бы проверял любую платформу не по «можно ли сделать красиво», а по чек-листу: большой каталог без комы в выдаче, интеграции без лютого кастома, промо-логика без боли, понятный путь от заказа до оплаты. Всё остальное — уже вторичный дизайн.

Где Битрикс реально оправдан

На корпоративных и сетевых историях Битрикс заходит потому, что это не «лендинг с корзиной», а связка магазина с процессами: каталог, заказы, складские и клиентские сценарии из коробки, обмен с 1С как отдельная экосистема.

Был у нас запуск для стройсети: 80 000 товаров, несколько складов, отдельная математика скидок для B2B. На чистом PHP такое можно дописать, но это месяцы и жирный бюджет. На готовом контуре мы вышли в прод заметно быстрее — потому что решали задачу бизнеса, а не изобретали велосипед.

Цена лицензии и сервера — да, это не «бесплатный WordPress». Зато это честная модель: вы платите за то, что масштаб и интеграции уже заложены в архитектуру, а не пробиты латками.

Kогда разумнее WooCommerce и облако

Если у вас не миллион SKU и не десять складов, а тысяча позиций и простая воронка — связка WordPress + WooCommerce часто выигрывает по скорости запуска и по цене входа. Экосистема плагинов закрывает типовые задачи без заказной разработки на каждый чих.

Облачные SaaS вроде Shopify годятся, когда компании нужен быстрый старт без администрирования сервера и команды DevOps. Комиссии и ограничения платформы нужно закладывать в юнит-экономику заранее — но для проверки гипотезы это иногда лучший компромисс.

OpenCart и аналоги я чаще видел у проектов, где важна предсказуемость и «руки разработчика на аутсорсе»: проще найти исполнителя, меньше сюрпризов, чем на экзотике. Magento и тяжёлый enterprise-класс имеют смысл, когда команда уже сильная технически и каталог — это отдельный продукт, а не «сайт с корзиной».

Самопис — не зло, но это отдельная ставка

Своя CMS имеет смысл, когда продукт по сути уникален и типовые решения мешают. Во всех остальных случаях вы покупаете не «уникальность», а дорогую поддержку собственного монстра: каждый апдейт PHP, каждый новый способ оплаты — ваш головняк.

Если уже понятно, что платформа не та

Переезд между системами редко бывает «копипастой базы». Обычно это заново собранная карточка товара, перепроверенные атрибуты, аккуратная переездная SEO-схема и пауза в маркетинге на время технических работ. Я закладываю такие работы как отдельный проект с понятным бэклогом — иначе получится хаос и простой продаж.

На этом этапе экономить опаснее всего: «перенесём как получится» почти всегда означает битые URL, дубли в выдаче и потерянные заказы в переходный месяц. Если уж делаете миграцию — делайте её один раз и основательно.

Что мы делаем перед выбором

• Считаем не «стоимость запуска», а стоимость трёх лет жизни: лицензии, хостинг, доработки, интеграции.
• Фиксируем сценарии: каталог, промо, B2B/B2C, обмен с учёткой, маркетплейсы.
• Закладываем буфер на рост — если через год SKU вырастет в пять раз, платформа должна выдержать без полной переделки.
• Перед подписанием уточняем у подрядчика три неудобных вещи: сколько стоит час поддержки после запуска, как закрываются интеграции «не из коробки», и что будет, если через полгода понадобится второй склад или новый тип оплаты.

Ответы без конкретики («сделаем как надо») для меня красный флаг. Нормальный исполнитель называет риски и диапазоны хотя бы порядка величины.

Если очень коротко: не экономьте на фундаменте там, где сайт — канал продаж. Экономия почти всегда вернётся чеком на миграцию.

Подробнее разобрал платформы и критерии в материале на сайте: как выбрать CMS для интернет-магазина — сравнение подходов.

Это не рутинное объявление об увеличении кластера. Если самый закалённый разработческой инфраструктуры игрок планеты говорит «в 10 раз — уже мало», значит фундаментальные предположения о том, как производится софт, сместились быстрее, чем GitHub успел заложить в собственные планы. Все, кто строит ниже по течению — на тех же предположениях, — попадают под тот же сдвиг.

Сигнал. CTO GitHub Влад Фёдоров: октябрьский план мощностей в 10 раз к 2026 году устарел уже к февралю — нужен план в 30 раз из-за роста AI-агентного кода.

Bottleneck не в железе. CI справится с любым потоком; не справляется валидация — очередь ревью, стенды staging, интеграционные тесты.

Стоимость поиска бага растёт по стадиям. Внутри цикла разработки — почти ноль; в CI — полный цикл сборки; в staging — деплой и очередь к стенду; в production — инцидент, откат и отдельный revert-PR.

Структурный ответ. Сдвиг валидации в inner-loop, где агент сам прогоняет изменение против реальной системы до создания PR.

Что делать командам. Отделить «compile-clean» от «correct», встроить эфемерные окружения в inner-loop агента, не наращивать слепо мощности CI.

Почему GitHub переписал план мощностей

В апреле 2026 года у GitHub было два крупных инцидента — внутренний апдейт об их разборе содержал ключевой абзац:

Мы начали в октябре 2025 года план по 10-кратному наращиванию мощностей GitHub с целью существенно улучшить надёжность и failover. К февралю 2026 стало ясно, что нужно проектировать под будущее, требующее 30-кратного объёма от текущего.

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

Объём становится проблемой, когда не конвертируется в throughput

30-кратный рост производства кода в идеальном мире давал бы 30-кратный рост поставленных фич. На практике SDLC никогда не превращал объём кода в релизную функциональность 1:1. Конверсия теряется на одном и том же этапе — валидация.

До прихода агентов это уже было больно: тест-сьюты по часу, постоянно перегруженные стенды staging, интеграционные баги, всплывающие на release candidate, очереди review, в которых сидят единственные люди, способные определить, безопасно ли изменение. Валидация — самая медленная, самая зависящая от человека и самая ошибкоёмкая часть цикла, и она встроена между «код написан» и «код задеплоен».

В cloud-native архитектурах эта проблема обостряется. Современное приложение — это граф сервисов, каждый со своим состоянием, зависимостями, темпом релизов. Изменение одного сервиса прокатывается по половине соседних, а ломается обычно то, что не видно в исходниках: contract drift (несовпадение договорённостей между сервисами), race conditions, edge-кейсы мульти-тенантности, поведение под нагрузкой.

Где ловить баг — там и платить

Стоимость найденного бага компаундится в зависимости от стадии:

• Inner loop (агент или разработчик ещё итерирует) — почти ноль.
• CI — полный цикл сборки.
• Staging — деплой + слот в очереди + время валидаторов.
• Production — инцидент, rollback, revert PR, который сам идёт через тот же pipeline.

При человеческой скорости разработки SDLC поглощал часть этой неэффективности — объём ограничивался числом инженеров. На скорости и масштабе агентов поглощать перестаёт: задержка превращается в постоянно растущий backlog. Поэтому ответ — не «больше мощностей CI, больше стендов staging, больше ревьюеров». Это тактический отклик на структурный сдвиг.

Замкнуть петлю — там, где код пишется

Структурный ответ — сдвинуть валидацию максимально влево, прямо в inner loop, где агент порождает код. Сегодня агенты для кодинга — это половина рабочей системы: они пишут код на беспрецедентной скорости, но не могут самостоятельно проверить, правильно ли он ведёт себя в распределённой системе. Compile-clean ≠ correct. Unit-тесты проверяют ровно то, что они скоупят.

Поэтому агент делает единственное, что может — объявляет изменение готовым и пушит вниз по pipeline, где работа по «а оно вообще пашет?» падает на ревьюера, интеграционные тесты, деплой на staging или инцидент в production. И вся компаундящаяся стоимость валидации включается на полную.

Замкнуть петлю — значит дать агенту способ автономно прогнать кандидатное изменение против реальной системы: реальные сервисы, реальные зависимости, реальные паттерны трафика. Быстро и дёшево настолько, чтобы агент мог итерировать, наблюдать, что сломалось, и пробовать ещё раз — без человека, без конкуренции за общий стенд staging, на скорости и масштабе агентов.

Почему не справляются текущие подходы

• Mocks — подделывают поведение зависимостей и проходят мимо реальных.
• Unit-тесты — покрывают индивидуальные функции, не интеграционную поверхность.
• Зелёный CI — говорит, что протестированное прошло. Это не равно «изменение корректно».

Чтобы петля действительно замкнулась, агенту нужно прогнать кандидата против настоящего состояния системы, а не модельного. И это требует инфраструктуры, которой массово в командах ещё нет: эпемерные окружения, изолированные на уровне one-PR-one-environment, с реальными зависимостями.

Чек-лист для тимлидов

1. Замерить текущую валидационную «вилку»: время от commit до зелёного staging для среднего PR. Если оно растёт — bottleneck уже здесь.
2. Посчитать долю PR-ов с rollback или revert. Если rollback-rate растёт месяц к месяцу — петля у агентов открытая.
3. Запустить пилот с ephemeral environments на одном из сервисов с самым большим интеграционные накладные расходы. Сравнить за 4 недели: процент PR-ов, прошедших валидацию с первого раза.
4. Не наращивать мощности CI «в ширину» как первый ответ. Это лечит симптом, не причину.
5. Дать агенту сигналы во время выполнения (не только compile + unit). Без них следующий шаг качества кода невозможен.

Выводы

Объём кода, генерируемого AI-агентами, растёт быстрее, чем планировали даже в GitHub. Стратегический вопрос для каждой инженерной организации сейчас простой: ваши агенты работают в замкнутой петле или открытой? Замкнутая — мультипликатор на throughput команды. Открытая — мультипликатор на те самые валидационные bottleneck-и, которые и так были самым узким местом.

Похожий тренд мы недавно разбирали в материале про tokenmaxxing: AI-ассистенты дают двукратную выработку кода ценой десятикратных затрат токенов и роста code churn на 861%. Природа проблемы одна: код производится массой, а инфраструктура к этому не готова.

Источник: The agent code explosion is here. We need to rethink our pipelines, fast — The New Stack.

Релиз Kubernetes 1.36, запланированный на 22 апреля 2026 года, содержит разнообразный набор новых alpha-фич, сфокусированных на трёх ключевых направлениях: производительность рабочих нагрузок, масштабируемость API и эффективное использование ресурсов. В этом обновлении много давно ожидаемых возможностей: workload-aware preemption для AI/ML-задач, шардирование API-стримов для больших кластеров, глубокая интеграция Dynamic Resource Allocation (DRA) в scheduler.

В обзоре — 20 новых фич, добавленных в Kubernetes как alpha (то есть выключены по умолчанию): от node-уровневых gRPC API до graceful leader transitions. Это даёт представление, куда движется контейнерная оркестрация.

Прим. Авторы стараются указывать актуальные изменения, но из-за быстро меняющегося ландшафта фич Kubernetes часть KEP (Kubernetes Enhancement Proposals) может быть исключена из milestone ближе к дате релиза.

— Релиз. Kubernetes 1.36 выходит 22 апреля 2026. Статья рассматривает 20 alpha-фич.

— Фокус. AI/ML (workload-aware preemption, gang scheduling, DRA), масштабируемость (sharded watches, kubelet gRPC API), ресурсы (pod-level resource managers, HPA scale-to-zero).

— По категориям. Nodes (5), Scheduling (6), API (4), Apps (1), Storage (1), Various (3) — итого 20 KEP-ов.

— Non-alpha. OCI VolumeSource → Stable; Device taints в DRA → Beta (включены по умолчанию). User namespaces в Pod → Stable после 3,5 года в альфе. gitRepo volume plugin удалён.

Nodes

DRA: Device Attributes в Downward API

KEP #5304 · Feature gate: отсутствует. Фреймворк предоставляет boolean-флаг (например, --enable-device-metadata), который драйверы встраивают в свой CLI.

KEP-5304 вводит стандартный способ для DRA-драйвера наполнять метаданные устройства. Фреймворк затем автоматически передаёт эти метаданные в контейнер, монтируя их как JSON-файл по заданному пути. Больше не нужно изобретать кастомные контроллеры или запрашивать Kubernetes API из самой рабочей нагрузки только ради этих деталей.

В текущей версии DRA, чтобы получить информацию о выделенных устройствах (например, PCIe-адреса для GPU или UUID для mediated-устройств), нужно читать статус ResourceClaim, находить подходящий ResourceSlice и парсить атрибуты. Неудобно. KEP-5304 позволяет DRA-драйверу возвращать метаданные устройства прямо в ответе на gRPC-вызов PrepareResourceClaims (kubelet → driver), а kubelet пишет их в JSON-файл и монтирует его в контейнер. В итоге приложение внутри контейнера просто читает файл /var/run/dra-device-attributes/{claimName}/{requestName}/{driverName}-metadata.json.

Новый kubelet gRPC API для локальных подов

KEP #4188 · Feature gate: PodInfoAPI.

Сейчас, чтобы получить свежий статус пода (ready ли он, его IP, его labels), компоненты на той же ноде — CNI-плагины, мониторинг-агенты — должны ходить в API-сервер. Это создаёт проблемы с надёжностью (если нода потеряла связь с control-plane, локальные компоненты не получат свежие данные, хотя они есть у локального kubelet), масштабируемостью (нагрузка на API-сервер от агентов на каждой ноде) и задержкой (сетевой вызов всегда медленнее локального).

Предлагается новый gRPC API для подов прямо на ноде: UNIX-сокет /var/lib/kubelet/pods/kubelet.sock, доступ только для привилегированных процессов. API возвращает самую свежую информацию, доступную kubelet, даже если она ещё не синхронизирована с API-сервером. Клиент может запросить полный PodSpec и PodStatus либо конкретные поля через google.protobuf.FieldMask. Три основных метода: ListPods, GetPod, WatchPods.

CRI List Streaming

KEP #5825 · Feature gate: CRIListStreaming.

Иногда kubelet нужен список всех контейнеров на ноде (например, для garbage collection). Для этого он отправляет CRI-запрос ListContainers. Проблема: существующие CRI RPC — unary, то есть клиент (kubelet) шлёт один запрос, сервер (container runtime) возвращает один ответ со всем списком. На нагруженных нодах с тысячами контейнеров (например, от множества короткоживущих CronJob) список может превысить 16 МБ — дефолтный максимум в gRPC. Этот лимит достигается уже на ~11 000 контейнерах (~14 000 подов).

Чтобы не ломать совместимость, KEP добавляет новые server-side streaming RPC. При streaming-вызове container runtime не строит весь ответ в памяти — открывает gRPC-поток и отправляет StreamContainersResponse для каждого контейнера по очереди. kubelet читает из потока, пока тот не закроется, затем обёртка собирает куски в единый список.

DRA: видимость доступности ресурсов

KEP #5677 · Feature gate: DRAResourcePoolStatus.

Разработчику хочется видеть, какие DRA-ресурсы свободны в кластере, чтобы траблшутить Pod, который не шедулится из-за «insufficient DRA resources». Админу — знать, сколько GPU доступно, для планирования мощностей. Сейчас это сложно: ResourceSlices — cluster-scoped и показывают только общую capacity, ResourceClaims — namespaced и отслеживают конкретные выделения, пользователь с ограниченными правами не видит ResourceClaims вне своего namespace, нет API-механизма видеть соотношение available/allocated.

KEP добавляет ResourcePoolStatusRequest — паттерн CertificateSigningRequest: пользователь создаёт объект с указанием driver (обязательный) и pool filter (опциональный), контроллер в kube-controller-manager подхватывает его, считает availability и пишет результат в status. Для обновления — удалить старый запрос и создать новый.

Пример — посмотреть статус всех GPU-пулов:

Pod-Level Resource Managers

KEP #5526 · Feature gates: PodLevelResources, PodLevelResourceManagers.

KEP-2837 позволил задавать единый бюджет ресурсов (CPU, память и т.д.) для всего пода целиком, а не для каждого контейнера отдельно. Это полезно для Guaranteed-QoS-подов в HPC, AI/ML, NFV. Проблема: текущие resource managers работают на уровне контейнера и не умеют использовать pod.spec.resources для NUMA-решений.

KEP-5526 даёт выбор из двух моделей управления ресурсами (обе поддерживают Guaranteed-поды с mix из Guaranteed- и non-Guaranteed-контейнеров):

• Pod Scope — Topology Manager назначает один ресурсный пул с одной NUMA-ноды на весь под, используя pod.spec.resources. CPU и Memory managers выделяют эксклюзивные сегменты для Guaranteed-контейнеров, остаток идёт в shared-пул для остальных
• Container Scope — ресурсы управляются для каждого контейнера отдельно, pod.spec.resources игнорируется при размещении

Первая модель — для ML-тренировочного контейнера с сайдкарами (логирование, ingestion, мониторинг) на одной NUMA-ноде. Вторая — для независимого управления контейнерами с разными требованиями внутри одного Guaranteed-пода: Guaranteed-контейнер получает эксклюзивные NUMA-выровненные ресурсы, non-Guaranteed в том же поде работают в shared-пуле ноды. Раньше это было невозможно: все контейнеры в поде должны были быть Guaranteed.

Scheduling

Workload-aware preemption

KEP #5710 · Feature gate: WorkloadAwarePreemption.

Scheduler может инициировать preemption — принудительное удаление подов с более низким приоритетом, чтобы освободить ресурсы под высокоприоритетный под. Проблема: он делает это пер-под. А AI/ML- и HPC-нагрузки обычно — группа тесно связанных подов (например, для распределённого обучения). Если даже один под из группы вытеснен, весь job стопорится и просто ждёт возврата этого пода, удерживая ресурсы впустую.

KEP-5710 вводит workload-aware preemption: группы связанных подов (PodGroups) теперь — единая сущность для scheduling и preemption. Scheduler прикидывает, можно ли освободить место под высокоприоритетную группу, вытеснив менее важные группы целиком.

Новое поле DisruptionMode в GangSchedulingPolicy контролирует, может ли Kubernetes вытеснять отдельные поды или группу только целиком (PodGroup). Поле PriorityClassName в PodGroupSpec задаёт приоритет всей группы — используется для всех решений о scheduling/preemption, перекрывая приоритеты отдельных подов. Строится на KEP-4671 (Gang Scheduling в Kubernetes).

Topology-aware workload scheduling

KEP #5732 · Feature gate: TopologyAwareWorkloadScheduling.

Строится на идеях KEP-4671 и KEP-5710. Классический scheduler принимает решения пер-под, что неоптимально для групп связанных подов: их имеет смысл размещать на одной ноде или хотя бы близких нодах — для снижения latency. KEP-5732 делает scheduler topology-aware: можно указать, чтобы группа подов размещалась в пределах одного topological domain, определённого общим label — например, topology.kubernetes.io/rack.

DRA: List-типы для атрибутов

KEP #5491 · Feature gate: DRAListTypeAttributes.

KEP обновляет DRA API под более сложные hardware-конфигурации. Раньше атрибуты устройств в ResourceSlice могли быть только скалярными (string, number, boolean). Нельзя было описать устройство с несколькими соединениями — например, CPU, подключённый к нескольким PCIe-шинам.

Теперь драйверы могут отдавать атрибуты как списки строк, чисел или версий. Обновлена логика в ResourceClaim: matchAttribute теперь требует непустого пересечения списков (не точного совпадения), distinctAttribute — попарной непересекаемости.

Пример ResourceSlice с атрибутом resource.kubernetes.io/pcieRoot в разных форматах:

DRA: поддержка ResourceClaim для Workloads

KEP #5729 · Feature gate: WorkloadPodGroupResourceClaimTemplate.

DRA даёт использовать специализированные ресурсы — GPU, FPGA, кастомные сетевые карты. Чтобы под получил такой ресурс, нужно создать соответствующий ResourceClaim. Проблема: если несколько подов делят ресурс, максимум было 256 подов на один ResourceClaim из-за лимита status.reservedFor.

KEP-5729 чинит: ResourceClaims теперь могут быть на уровне PodGroup. Один claim на всю группу, все поды в ней могут использовать ресурс. Поды ссылаются на ресурс по локальному group-name через PodGroupResourceClaim, а не прямому имени. Динамически создаваемые поды получают доступ к общему ресурсу, автоматически созданному для группы, без необходимости знать его имя заранее.

DRA: Native Resource Requests

KEP #5517 · Feature gate: DRANativeResources.

Появление DRA в Kubernetes породило два независимых механизма учёта ресурсов, которые управляют одним и тем же. Это даёт двойной учёт:

• Supply — capacity CPU/памяти ноды хранится в двух местах: Node.Status.Allocatable у kubelet и ResourceSlice у DRA-драйвера
• Consumption — поды могут запрашивать ресурсы двумя путями: через spec.containers[].resources.requests или spec.initContainers[].resources.requests (проверяет NodeResourcesFit) или через ResourceClaim (обрабатывает DynamicResources)

KEP-5517 интегрирует DRA-ресурсы со standard resource tracking scheduler-а, обеспечивая единый учёт и предотвращая overcommit. Пример: ML-job запрашивает GPU через ResourceClaim, но конкретная модель GPU требует определённого количества CPU и HugePages. Раньше пользователь должен был знать об этом и прописывать в PodSpec. Теперь GPU-устройство декларирует зависимости само — scheduler учитывает потребности GPU в CPU и HugePages дополнительно к обычным requests.

WAS (Workload-Aware Scheduling): декомпозиция PodGroup API

KEP #5832 · Feature gate: GenericWorkload.

Kubernetes имеет gang scheduling — запуск всех подов в группе вместе. Проблема: логика gang scheduling изначально тесно связана с конкретной реализацией API под названием PodGroup, которая была частью объекта Workload. Это создавало два неудобства:

• Другие проекты экосистемы (Kueue, JobSet), тоже требующие gang scheduling, были вынуждены использовать этот конкретный PodGroup API — не могли применить свои CRD для описания групп
• Обновление статуса одной маленькой Pod-группы требовало чтения/записи всего Workload-объекта, что давало просадку производительности и конфликты при большом числе групп

KEP-5832 разделяет PodGroup и Workload: PodGroup становится самостоятельным объектом, Workload — статичным шаблоном, определяющим общую политику и структуру групп. Высокоуровневые контроллеры (Job, JobSet, LeaderWorkerSet) автоматически создают инстансы PodGroup из шаблона Workload, затем поды этой PodGroup. В Pod spec появилось поле spec.schedulingGroup.podGroupName, указывающее прямо на PodGroup. Scheduler больше не следит за Workload-объектами — работает напрямую с потоком PodGroup.

API

Stale Controller Mitigation

KEP #5647 · Feature gate: StaleControllerConsistency.

Контроллеры в Kubernetes (например, kube-controller-manager) работают в reconciliation loop: следят за состоянием кластера, сравнивают желаемое с фактическим, синхронизируют. Они используют локальный кэш состояния, чтобы не перегружать API-сервер. Кэш обновляется через watch — это eventually consistent, то есть «когда-нибудь» изменения доедут. Задержка бывает от миллисекунд до минут.

В больших high-load кластерах проблема обостряется. Контроллер создаёт Pod, через секунду получает запрос reconcile того же объекта, но кэш ещё не обновился — контроллер «не видит» созданный под и пытается создать его снова или делает что-то ещё не то.

KEP-5647 вводит два изменения:

• В informer добавляется BookmarkFunc, единственная задача которого — уведомить слушателей, что произошло обновление. Вместе с обычными Add/Update/Delete это позволяет контроллеру знать, насколько свеж его кэш
• Улучшена логика контроллера. После успешной операции CREATE или UPDATE сохраняется новый resourceVersion объекта. Перед следующим reconcile контроллер проверяет, обработал ли informer resourceVersion как минимум такой же свежий. Если да — кэш актуален, можно продолжать. Если нет — reconcile пропускается, объект ставится обратно в очередь с exponential backoff

Graceful Leader Transition

KEP #5366 · Feature gate: GracefulLeaderTransition.

В high-availability кластерах несколько реплик ключевых control-plane-компонентов (kube-controller-manager, kube-scheduler) работают одновременно. Чтобы избежать конфликтов, используется leader election. Старый механизм при потере лидерства просто завершал процесс через os.Exit(), kubelet его рестартовал. Это съедало ресурсы, и компонент не мог gracefully завершить работу.

KEP-5366 вводит smarter способ передачи лидерства без полного рестарта:

• Рефакторинг кода контроллеров — чтобы все внутренние goroutines завершались чисто. Критично, чтобы не утекали ресурсы при частой смене ролей
• Улучшен release leader lease: вместо ожидания TTL, уходящий лидер активно освобождает lock при shutdown, ускоряя новые выборы. Управляется флагом ControllerManagerReleaseLeaderElectionLockOnExit
• Финальная стадия (флаг GracefulLeaderTransition) меняет core-логику компонента: при потере лидерства он не завершается через os.Exit(), а переходит в follower-состояние и пытается стать лидером снова

Server-side Sharded List and Watch

KEP #5866 · Feature gate: ShardedListAndWatch.

В Kubernetes контроллеры непрерывно мониторят состояние ресурсов (Pods, Services) через LIST и WATCH. С ростом кластеров эти операции тяжело масштабировать. Большинство контроллеров, как kube-controller-manager, масштабируются только вертикально — не умеют разделять watch-поток. Некоторые (kube-state-metrics) научились делать client-side sharding, но каждая реплика всё равно получает все события ресурса, десериализует всё, потом выбрасывает то, что не для её шарда. Лишняя сетевая нагрузка и CPU.

KEP-5866 переносит фильтрацию на API-сервер. Новый параметр shardSelector позволяет клиенту подписаться на конкретный шард данных — задаётся хэш-диапазон. Пример запроса:

API-сервер использует быстрый FNV-1a для хэша metadata.uid. Если хэш попадает в диапазон — событие уходит клиенту. Каждая реплика подписывается на свой диапазон и получает clean, non-overlapping поток.

Manifest Based Admission Control Config

KEP #5793 · Feature gate: ManifestBasedAdmissionControlConfig.

Чинит серьёзную startup-уязвимость в Kubernetes. Обычно все правила валидации запросов (admission webhooks — MutatingAdmissionWebhook, ValidatingAdmissionWebhook, access policies) — это API-объекты внутри кластера. Это даёт опасное окно: при старте API-сервера (или недоступности etcd) запросы могут обрабатываться до того, как правила загружены. Плюс любой пользователь с повышенными правами может — намеренно или случайно — удалить admission policies по сети.

KEP-5793 добавляет способ задавать security-политики через локальные манифест-файлы на диске control-plane-сервера. Эти файлы загружаются и применяются до того, как сервер начнёт слушать сеть. API-сервер непрерывно мониторит локальный каталог — при изменении файла правило немедленно подхватывается, валидируется и применяется без рестарта. Если валидация упала, сервер отклоняет новый манифест, логирует warning и возвращается к last-known-good конфигурации.

Apps

WAS: интеграция Workload API с Job controller

KEP #5547 · Feature gate: EnableWorkloadWithJob.

Job controller в Kubernetes отвечает за запуск джобов. Он создаёт поды, но нет гарантии, что они стартанут одновременно. Реальная проблема для распределённых нагрузок (AI/ML, MPI-задачи), где всё должно стартовать синхронно.

KEP-5547 расширяет Job controller нативной поддержкой gang scheduling (KEP-4671) через Workload и PodGroup API. Когда создаётся Job с нужными параметрами (для альфы это parallelism > 1, completionMode: Indexed, parallelism = completions), контроллер автоматически:

• Создаёт объект Workload с политикой scheduling для группы подов, указывая gang.minCount равным parallelism
• Создаёт объект PodGroup по шаблону из Workload
• При создании подов Job добавляет schedulingGroup.podGroupName в их спецификацию, связывая поды с соответствующей PodGroup

Scheduler видит, что поды — часть PodGroup, и ждёт возможности запустить все поды из minCount (минимум для старта workload) одним махом.

Storage

PVC — время последнего использования

KEP #5541 · Feature gate: PersistentVolumeClaimUnusedSinceTime.

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

KEP-5541 добавляет поле UnusedSince в статус PVC (PersistentVolumeClaimStatus). PVC protection controller ставит туда metav1.Now при удалении или переходе в terminal state последнего пода, ссылающегося на PVC, и nil при появлении нового пода, начинающего ссылаться на этот PVC.

Various

HPA: масштабирование до/от нуля по object/external metrics

KEP #2021 · Feature gate: HPAScaleToZero.

Раньше Horizontal Pod Autoscaler не мог скейлить до нуля реплик. Он опирался на метрики активных подов — CPU, память — поэтому всегда требовался минимум один работающий под для сбора данных.

KEP вводит поддержку external и object metrics: HPA может принимать решения по внешним индикаторам (например, длина очереди сообщений). Если задач нет — число подов приложения скейлится до нуля, фактически глушит его. HPA записывает это в специальный status-поле ScaledToZero. Это предотвращает случайный scale-up приложения, которое админ вручную опустил до нуля через replicas: 0. Как только появляется задача (сообщение в очереди) — HPA поднимает первую реплику.

Native Histogram Support для метрик Kubernetes

KEP #5808 · Feature gate: NativeHistograms.

Гистограммы в Prometheus сейчас работают через предопределённые buckets. Разработчик заранее задаёт диапазоны значений. Например, для latency: до 10 мс, до 50 мс, до 100 мс, до 500 мс. Если запрос занял 49 мс — инкрементится «до 50 мс». У этого два недостатка:

• Неоднозначность — невозможно узнать точное распределение внутри bucket (все запросы на 11 мс или все на 49 мс? Эта информация теряется)
• Избыточность — передаются данные для всех bucket'ов, даже если туда ничего не попало. Жрёт ресурсы и диск

Prometheus v2.40 ввёл Native Histograms (стали stable в v3.8.0) с умными auto-adjusting экспоненциальными buckets. KEP-5808 интегрирует Prometheus Native Histograms в метрики компонентов Kubernetes.

Обработка незашифровываемых ресурсов

KEP #3926 · Feature gate: AllowUnsafeMalformedObjectDeletion.

Шифрование API-ресурсов at-rest давно используется в Kubernetes. Иногда оно ломается из-за внешних сбоев или неверной настройки. Если один объект определённого типа не расшифровывается, то list этого типа в префиксе, содержащем объект, всегда падает — даже если остальные объекты читаются. Поломанный объект нельзя удалить через Kubernetes API, админ должен лезть в etcd вручную.

KEP-3926 предлагает метод идентификации ресурсов, которые не расшифровываются или не декодируются в объект, и вводит новый DeleteOption — IgnoreStoreReadErrorWithClusterBreakingPotential, разрешающий удалить ресурс, даже если его данные не читаются.

Non-alpha highlights релиза 1.36 — выбор Дмитрия Шурупова

Статья намеренно фокусируется на alpha-фичах, чтобы показать, куда движется разработка. Но каждый релиз содержит много других обновлений — это alpha, введённые раньше, или фичи, сейчас находящиеся в beta/stable. Самые заметные, по мнению Дмитрия Шурупова (сооснователя Palark, CNCF Ambassador):

• Device taints и tolerations в DRA (KEP 5055) и DRA support for partitionable devices (KEP 4815) — Beta. Включены по умолчанию
• OCI VolumeSource (KEP 4639) — Stable. Новый VolumeSource (появился в 1.31), поддерживает OCI-образы: хранение файлов и расшаривание между контейнерами в поде без включения в основной образ
• User namespaces в Pods (KEP 127) — Stable. Стартовал в alpha в 1.25 (август 2022), через 3,5 года наконец GA
• Mutating Admission Policies (KEP 3962) — Stable. Расширяет mutating admission webhooks через CEL-выражения
• Accelerated recursive SELinux label change (KEP 1710) — Stable. В beta с 1.27 (апрель 2023)
• gitRepo volume plugin (KEP 5040) — удалён. Критическая security-проблема: выполнение кода как root на ноде

Часть alpha-фич из 1.35 и более ранних релизов (gang scheduling, user namespaces в HostNetwork-подах) значительно доработана, но осталась в альфе.

Это не полный список изменений — полную информацию можно посмотреть в official enhancements tracker и changelog.

Заключение

Релиз Kubernetes 1.36 существенно расширяет инструментарий оркестратора, фокусируясь на производительности, безопасности и удобстве использования. Интегрируя gang scheduling и продвинутое управление ресурсами, Kubernetes всё лучше подходит для современных распределённых нагрузок и больших кластеров, одновременно оптимизируя ядро своих API.

Спасибо всем разработчикам и авторам KEP, сделавшим Kubernetes 1.36 возможным. Вы потрясающе сработали.

Интересуют другие alpha-фичи, недавно добавленные в Kubernetes? Читайте deep-dives по Kubernetes 1.35 (декабрь 2025) и Kubernetes 1.34 (август 2025).

Оригинал статьи: palark.com/blog/kubernetes-1-36-release-features/. Перевод публикуется с сохранением оригинальной структуры и всех технических деталей.

Рассказываем, что показала компания, о чём говорили спикеры и куда движется индустрия.

Сначала цифры: как вырос Cloud.ru

На конфренции Cloud.ru впервые публично раскрыла детальную финансовую отчётность. Выручка за 2025 год — 76,5 млрд рублей (+50% год к году). Чистая прибыль — 14,7 млрд(+86%).

Основной драйвер роста — инфраструктура для ИИ: обучение и инференс моделей дали 54% выручки. При этом классические облачные сервисы тоже выросли на 31%, что быстрее темпов роста рынка России.

По инфраструктуре Cloud.ru — один из крупнейших облачных провайдеров в стране. В парке находится 43 000+ единиц оборудования, 29 000+ серверов, 9 ЦОДов суммарной мощностью 56 МВт.

По доле рынка мы уже давно занимаем большую часть, при этом продолжая расти быстрее рынка,

Важный нюанс: убыточных направлений нет. Разные платформы находятся на разных стадиях развития, но инвестиции отбиваются в плановые сроки.

АФЛТ-Системс, например, уже в активной фазе перехода к регулярной эксплуатации AI. Павел Павленко, руководитель направления развития GenAI, говорит: «GoCloud для меня в этом году — про то, как индустрия перешла от разговоров про потенциал GenAI к разговору про реальные внедрения, метрики и архитектурные решения. Мы строим внутреннюю AI-платформу, выстраиваем процессы и запускаем первые продукты, в том числе AI-фикацию пайплайна разработки. На таком этапе ценность партнёра измеряется не презентациями, а скоростью реакции и готовностью идти в эксперимент».

Что происходит на рынке: от пилотов к промышленной эксплуатации

Последние 2–3 года компании делали пилоты по внедрению генеративного ИИ в основном благодаря визионерской силе лидеров, CEO, директоров. Пилоты часто были точечными и экспериментальными: автоматизировали поддержку и отвечали на частые простые вопросы, генерировали контент.

Сейчас модели стали лучше, а бизнес опытным путем выяснил, какие функции эффективнее передавать ИИ. Результаты пилотов всё чаще признаются успешными.

Например, Артём Бондарь, руководитель направления NLP в Центре искусственного интеллекта Т-Банка, выделяет три ключевых направления GenAI-инструментов. Первое — агенты и копайлоты в полном цикле разработки. Второе — инструменты для HQ-профессий: от генеративных моделей для общих задач до вертикальных решений вроде автоматической генерации креативов «почти без касания людей».

Но прямой финансовый эффект особенно заметен в автоматизации поддержки и операционки. Здесь задействован весь спектр GenAI-подходов:

• пошаговая автоматизация с помощью LLM там, где есть регламентированный процесс,
• агенты, которые ищут решение в сконструированной для них среде,
• и AI-сотрудник Афанасий Иванов (АИ), который работает в компании уже больше года и использует те же интерфейсы, что и люди.

Становится ясно, что перелом скоро наступит. И это точно не год.

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

DevOps-практики тоже перешли в практическую плоскость. В МТТЕХ выстроили модель GitOps, где Git — единый источник истины, а все изменения проходят через ревью и автоматизированный деплой. IaC-подход (Terraform, Ansible) и self-hosted GitLab в облаке позволяют управлять инфраструктурой как кодом.

Если раньше поднятие инфраструктуры занимало недели и требовало вовлечения нескольких команд, то сегодня мы говорим про минуты и полностью автоматизированные процессы,

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

Neocloud: GPU как отдельное направление

На этом фоне Cloud.ru выделил AI-инфраструктуру в отдельное бизнес-направление — Neocloud. Это единая управляемая среда для полного цикла работы с моделями: от разработки и обучения до инференса и эксплуатации.

Нагрузки под ИИ сильно отличаются от классических. Для них нужны высокоскоростные соединения между GPU, умный шедулинг (днём — инференс, ночью — дообучение), возможность получить кластер из сотен HGX, а потом отпустить. Но на рынке такого предложения нет. Neocloud как раз решает управление вычислительными ресурсами на масштабе.

В Neocloud есть:

• Доступ к тысячам современных GPU в публичном облаке.
• Поддержка гибридных сценариев (своя инфраструктура + облако).
• Собственная платформа Distributed Train для распределённого обучения с проактивным мониторингом, автоматической заменой отказавших узлов и гибким управлением очередями.

Чем Neocloud выгодно разработчикам

Решения такого уровня остаются доступными и для пользователей. Арендовать HGX теперь не проблема, они доступны буквально по цене обеда.

Выгодная стоимость для Cloud.ru остается приоритетом. Компания заявляет, что не планирует повышать цены в этом году.

Это не единственный аргумент в пользу облака. Как отмечает Артём Сычев, первый заместитель генерального директора РТ-Информационная безопасность, для госсектора и крупных компаний есть ещё одно важное преимущество: «С облаком удобнее проходить закупочные процедуры. Ты сделал рамочный договор, и в любой момент, когда у тебя появился новый госзаказчик, быстро развернул инфраструктуру».

Агенты: EvoClaw, Agent Space и новый способ общения с облаком

Другой инструмент, о котором рассказали на конференции, — EvoClaw. Это управляемый облачный сервис для работы с OpenClaw и другими open source агентными фреймворками. ИИ-агент обеспечивает observability, мониторинг, логирование и поддерживает политики безопасности. Cloud.ru одним из первых в России приступил к открытому тестированию OpenClaw ещё в феврале 2026 года.

Ключевые особенности EvoClaw:

• Агент запускается в пару кликов.
• Политики безопасности приведены к Zero Trust, привилегии — по минимальному принципу.
• Агенты изолированы своим рабочим пространством.
• Интеграция с AI Factory (Foundation Models, AI Agents, Managed RAG).

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

Это первый шаг к такому типу потребления, когда пользователь или организация перестают общаться напрямую с облаками и начинают общаться с агентами, которые с помощью доверенных им учёток, прав сами разворачивают инфраструктуру, сами её администрируют, дают нагрузку и так далее,

Да, для облачных провайдеров это может звучать как риск, но на самом деле агенты пока что все так же будут ходить в API облаков и строить инфраструктуру там.

Ещё одно решение Cloud.ru для работы с агентами — Agent Space — мобильное и десктоп-приложение, которое позволяет чатиться с агентом. Оно работает на протоколе A2A (Agent-to-Agent). А в каталоге представлены уже более 20 бизнес-сценариев, среди которых и «Агент Python-разработчик».

AI Workflows: low-code оркестратор

Бизнес-процесс редко состоит из одного действия. Обычно это цепочка: проверить данные в 1С, прогнать их через LLM, создать задачу в Jira, отправить уведомление в Telegram.

Для таких сценариев Cloud.ru запустил AI Workflows — low-code конструктор, который сейчас находится в публичном тестировании.

Пользователь собирает цепочку шагов в визуальном интерфейсе (как в n8n, но с ИИ-блоками). На каждом шаге можно подключить готовый коннектор к 1С, Jira, Confluence, PostgreSQL, почтовым клиентам, мессенджерам или внутренним сервисам через API. А между ними — вызовы LLM из Evolution Foundation Models, инференс-моделей или даже готовых агентов.

На старте AI Workflows ориентирован на готовые коннекторы и предсобранные кубики. Вставлять кастомные скрипты прямо в цепочку пока нельзя. Но в компании понимают, что разработчикам это нужно и планируют дать такую возможность, подчеркивает Анастасия Тафеенко, директор блока разработки платформы Cloud.ru Evolution.

На пресс-конференции прозвучала интересная мысль: AI Workflows — это тоже промежуточный этап. Через пару лет, когда компании привыкнут делегировать задачи ИИ, и этот уровень оркестрации станет не нужен, всё будет ИИ-фицировано насквозь.

Безопасность: Guardrails и Container Security

Агенты получают доступ к вашей инфраструктуре. Да, это удобно, но возникает закономерный вопрос: как не допустить, чтобы агент случайно (или специально) не отправил чувствительные данные во внешнюю LLM? Или не поднял контейнер с критической уязвимостью?

На GoCloud 2026 анонсировали два инструмента, которые закрывают эти риски — на уровне данных и на уровне инфраструктуры.

Guardrails Filter: чтобы секреты не утекли

Guardrails Filter — это фильтр между агентами и большой языковой моделью. Он сканирует исходящий запрос, находит потенциально чувствительные данные (ПДн, реквизиты, API-ключи, секреты), маскирует их и только потом отправляет в LLM. Когда модель возвращает ответ, фильтр восстанавливает реальные значения на месте.

Guardrails как раз обеспечивает фильтрацию при обращении к внешним моделям. Наши же модели не дообучаются, данные не используются, не имеют доступа в интернет. Это проверено пен-тестами,

Evolution Container Security: чтобы контейнеры не стали дырой

На уровне государства вводятся понятия «суверенного искусственного интеллекта», проходят публичные слушания по закону. Граница безопасности активно формируется. Cloud.ru отвечает на этот запрос и даёт широкую линейку сервисов безопасности, чтобы клиент мог выбрать нужный уровень под свой класс информационной системы.

По оценкам экспертов, порядка 80% запущенных кластеров Kubernetes содержат роли с избыточными привилегиями. И Evolution Container Security обеспечивает безопасность контейнерных сред Kubernetes. Сервис уже доступен в публичном тестировании.

Возможности Evolution Container Security:

• Сканирование контейнеров на уязвимости (включая БДУ ФСТЭК).
• Встроенный ИИ-агент для генерации политик безопасности.
• Создание и управление политиками через конфигуратор.
• Проверка конфигураций во время развёртывания.

Это классическая контейнерная безопасность — он проходит по настройкам кластера через фреймворк. Есть агент, который помогает настройщику сделать это правильно,

Что еще волнует безопасников

На круглом столе «Облако уже сегодня. Как получить конкурентное преимущество без компромиссов по безопасности» участники честно рассказали о своих страхах. Главный — потеря контроля. «Облако — это чёрный ящик, который необходимо контролировать, обвязывать своими сервисами, чтобы перепроверять подрядчика», — поделился Артём Сычев, первый заместитель генерального директора РТ-Информационная безопасность.

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

Облачные провайдеры, включая Cloud.ru, уже отвечают на эти запросы — едиными политиками безопасности, мониторингом и логированием как в публичном облаке, так и в гибридных средах.

Но есть и другой уровень безопасности — физический. Антон Фомин, CDO Navio, рассказывает, как GenAI помогает спасать жизни: «Как собрать данные о лобовом столкновении, не отправляя водителя на встречную машину? Мы это делаем с помощью нашего фотореалистичного стимулятора. Вот настоящая польза генеративного ИИ: заглянуть за горизонт и научить машины ездить без риска».

Гибридные облака: почему это сложно и как Cloud.ru стали одними из первых в этом поле

Гибридное облако — одна из тех тем, о которой много говорят, но мало кто делает хорошо. На конференции Cloud.ru представил исследование, которое показывает: интерес к гибридной модели растёт, но её часто воспринимают как нечто сложное и размытое.

Что такое гибрид на самом деле? Если отбросить маркетинговые формулировки, гибрид — это частное облако (on-prem) + публичное облако + связь между ними под единой платформой. Из единого личного кабинета можно управлять ресурсами и там, и там, переезжать виртуальными машинами из публичного облака в свой ЦОД и обратно.

Гибрид для меня — это возможность использования on-prem инфраструктуры, но с биллингом, управлением ресурсами, логированием, личным кабинетом

Гибрид это всё ещё больно и дорого. Публичное облако можно обновлять постоянно — раз-два в день, а то и чаще. Если в сервисе появилась ошибка, её сразу исправляют. С гибридом так не получится. Релиз, который поедет к клиенту на on-prem инфраструктуру, нужно собирать, тестировать, сертифицировать. И каждый сервис внутри этого релиза должен работать без оглядки на внешние зависимости.

Плюс требования клиента: пройти ПСИ, подтвердить безопасность, соответствие регуляторным нормам. В публичном облаке за это отвечает провайдер. В гибриде — всё ложится на клиента и интегратора.

Почему индустрия всё равно придёт к гибриду

• Безопасникам проще контролировать конфигурации и видеть всю инфраструктуру.
• Финансистам — смотреть утилизацию оборудования.
• CTO — видеть все виртуальные машины.
• В on-prem сложно инвентаризировать legacy-системы. Гибрид даёт прозрачность.

Cloud.ru начал строить гибридную платформу ещё на ранней стадии публичного облака. В прошлом году анонсировали Evolution Stack — платформу для создания частных и гибридных облаков. Клиенты уже могут получить единые политики безопасности, мониторинг и логирование для on-prem и публичного облака. Единой консоли управления «из облака» (модель Outpost, как у западных гиперскейлеров) пока нет. Но пилоты с единым центром управления готовы запускать уже сейчас.

В России почти нет провайдеров, которые могут предложить гибридное облако как отчуждаемый продукт, который можно установить у себя в ЦОДе. Cloud.ru сделал это за счёт того, что публичное облако и гибридная платформа построены на единой кодовой базе. Сервисы идентичны, пользовательский опыт одинаковый. Разработка начинается в публичном облаке, а прод уезжает на on-prem — и это работает, потому что сервисы внутри одни и те же.

Что будет с разработкой: не паникуем, но не забываем готовиться

Агенты уже пишут код, тестируют, разворачивают инфраструктуру. DevOps-инженер отдаёт помощнику создание виртуальных машин и настройку баз данных. SRE-агент сам поднимает метрики и ищет первопричины инцидентов. Вопрос, который возникает у каждого разработчика: «Меня заменят?»

В ближайшем будущем роли не отомрут, но изменятся. «Разработчику нужно поднимать уровень, становиться тимлидом — а его тиммейтами будут агенты», считает Анастасия Тафеенко, директор блока разработки платформы Cloud.ru Evolution.

Чем больше у разработчика экспертизы, чем лучше он понимает, как на самом деле устроен продукт, что такое репозитории, из каких блоков он состоит, — тем эффективнее он будет с агентами работать,

Новый челлендж — экономика решений. Можно написать агенту одну строчку, а потом 10 тысяч раз переделывать, уточнять, перезапускать. Каждый шаг — это токены. А токены — это деньги. Борьба будет не за то, кто быстрее написал код, а за то, сколько стоило решить задачу.

Новая роль — оркестратор агентов. На круглом столе «DevOps инструменты в облаке» представители МТТЕХ, Familia, Ventra и «Технологии – и точка» сформулировали главный тренд: «Мы движемся к модели, где человек становится оркестратором агентов. Он их направляет, пишет принципы, управляет — как оргструктурой».

Количество агентов будет расти драматически — от десятков до тысяч. И тот, кто научится управлять этой «армией», останется востребованным.

Агенты не приходят на пустое место. Основной барьер для внедрения ИИ-агентов не технологический, а организационный. Если в компании данные разрознены, процессы не формализованы, а культура не готова делегировать решения машине — никакой агент не поможет. И наоборот: в компаниях, где данные структурированы и процессы прозрачны, агенты достигают 60–90% автоматизации.

У экосистемы Kubernetes своя предыстория: каждая утилита появилась потому, что возможностей самого K8s просто не хватало.

Сначала вы управляете всем с помощью kubectl: запускаете kubectl get pods, describe, logs, exec, delete и apply по 50 раз в день в пяти неймспейсах. Это работает, но процесс медленный и неудобный — особенно потому, что каждый раз приходится указывать ключ -n namespace.

— На помощь приходит K9s (или Lens). Это терминальный UI, который собирает всю информацию о кластере в одном месте. С ним можно переключаться между неймспейсами и кластерами, смотреть логи, заходить в под (exec) и делать всё необходимое.

Вы деплоите манифесты с ноутбука через kubectl apply. Кто-то меняет Deployment прямо в кластере, и запущенные сервисы больше не согласуются с тем, что прописано в Git. Типичный дрейф конфигурации — про него никак не узнаешь, пока не упадёт прод.

— Внедряете Argo CD. Git становится единым источником истины: любые изменения автоматически синхронизируются с кластером; если кто-то поменяет Deployment вручную, Argo CD сразу перезапишет его обратно. (А ещё есть werf, который отлично интегрируется с Argo CD. Познакомиться с ним поближе можно на сайте проекта или в нашем курсе — заглядывайте!).

В Kafka скопилось 200К сообщений, но процессор загружен всего на 5 %, поэтому HPA не видит причин для масштабирования. Очередь растёт, пользователи ждут.

— Перехóдите на KEDA. Инструмент умеет масштабировать поды по размеру очереди, числу сообщений Simple Queue Service или метрикам Prometheus, а не только по процессору. В итоге бэклог благополучно разгребается.

Нагрузка скакнула, Horizontal Pod Autoscaler добавил поды, но узлы забиты под завязку, и те зависают в состоянии Pending. HPA свою работу сделал, но проблема в том, что новые поды просто негде разместить.

— На выручку приходит Karpenter. Поды зависли в Pending? Не беда! Karpenter поднимет новый узел за пару секунд (и удалит, когда нагрузка спадёт). Платишь только за то, что используешь.

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

— Поэтому вы используете Network Policies. База данных принимает трафик только от приложения, всё остальное закрыто. В итоге, если какой-то под взломают, радиус поражения будет минимальным.

У вас 20 микросервисов. Один из них начинает тормозить, из-за чего в четырёх других копятся повторные запросы. Начинается каскадный сбой, но определить его источник невозможно из-за непрозрачности трафика.

— Внедряете сервис меш. Istio или Linkerd подселяют сайдкар-прокси к каждому поду, и вы получаете mTLS между всеми сервисами, повторные запросы, circuit breaker'ы и метрики трафика. А самое главное — не надо править код приложения!

Секреты в Kubernetes закодированы в Base64, лежат в etcd, и их может прочесть любой, у кого есть доступ к kubectl. Хорошо бы перенести их в специализированное хранилище вроде HashiCorp Vault или AWS Secrets Manager, но переписывать код приложения — не вариант.

— Поэтому вы используете Secrets Store CSI Driver. Секреты хранятся в Vault или AWS Secrets Manager и монтируются прямо в поды как файлы. В самом Kubernetes они нигде не «светятся».

Один разработчик выкатывает контейнер с root-правами, другой забывает проставить лимиты на ресурсы. Но вы узнаёте об этом только после инцидента, и так постоянно.

— Ставите Kyverno. Ресурсы проверяются на соответствие политикам ещё до того, как попадут в кластер: теперь нельзя развернуть root-контейнеры, образы без digest-хеша и деплойменты без лимитов.

Что-то сломалось. Поды перезапускаются, задержка скачет, потребление памяти растёт, но нет ни метрик, ни истории, ни понимания, когда всё это началось.

— Значит, пора установить Prometheus и Grafana. Prometheus собирает метрики со всех подов, узлов и системных компонентов, а Grafana превращает их в наглядные дашборды. Сразу видны всплеск нагрузки, точное время его появления и сервис-виновник. (К слову, наш высокопроизводительный форк Prometheus — Deckhouse Prom++ — потребляет до 10 раз меньше памяти.)

Grafana показывает сам всплеск, но не говорит, какой запрос его вызвал, на какой сервис он пришёл первым и где именно начал тормозить. Логи дают лишь обрывки данных, а метрики — общие цифры. Ни то, ни другое не показывает картину целиком.

— Поэтому вы добавляете Jaeger. Он отслеживает путь запроса через все сервисы, показывая задержку на каждом переходе (hop) и точное место сбоя. Иголка в стоге сена находится за считаные секунды.

Рекламная пауза

Если вы не хотите разбираться в инструментах экосистемы с нуля, попробуйте Deckhouse Kubernetes Platform Community Edition — нашу готовую Open Source-платформу на базе Kubernetes. Она собрана инженерами «Фланта» из проверенных компонентов, которые не придётся обновлять вручную, и существенно сэкономит ваши ментальные ресурсы.

Реклама. Рекламодатель: АО «Флант» ИНН 7723661439, erid: 2W5zFHw9J5P

Автор формулирует задачу узко: один узел, без репликации, без масштабирования, просто надёжный S3-совместимый бэкенд на обычной файловой системе. На этой задаче большинство популярных решений либо избыточно, либо медленно, либо и то и другое.

MinIO мёртв: репозиторий архивирован, команда ушла в корпоративный рынок ИИ.

Garage: Rust, молодой, избыточно сложный для одного узла, часть S3-фич отсутствует.

SeaweedFS: красивая архитектура, но медленный на LAN — до 10 Мбит/с.

Versity GW: победитель автора. S3-шлюз над обычной ФС, работает на линейной скорости сети.

Поздние контендеры: RustFS, Zenko, Supabase Storage, filestash, rclone в режиме сервера.

Зачем ещё один S3, если есть AWS

S3 давно стал стандартным интерфейсом для объектного хранилища: один API, совместимый с сотнями библиотек и инструментов. На своём сервере тоже удобно говорить с данными через S3 — rclone, aws-cli, mc и SDK на всех языках просто работают.

Проблема в том, что реализаций S3 под самохостинг много, а «скучных» среди них мало. Типичный сценарий — пара гигабайт файлов на одной машине в LAN — у большинства решений либо требует распределённого кластера, либо деградирует по производительности без понятной причины. Автор перебирает альтернативы именно с этой точки зрения.

MinIO мёртв

В мае 2025 MinIO убрал управление из веб-консоли сообщества — оставили только read-only. В декабре 2025 проект перешёл в maintenance, а 13 февраля 2026 репозиторий заархивировали — команда ушла зарабатывать на enterprise и ИИ-рынке. Автор заметки списал MinIO ещё раньше:

После того как я указал им на баг, который их тесты не ловили — потому что они мокали ответы вместо реального исполнения кода, — а они отмахнулись, я их списал. В тот момент у них были сломаны удаления.

Это общая тема: проект, который раньше казался стандартом для self-hosted S3, перестал быть дружелюбным для тех, кому не нужна корпоративная подписка.

Garage: Rust, но пока тяжеловесный

Garage написан на Rust и позиционируется как лёгкий S3 с географическим распределением. По наблюдениям автора полгода назад проект был избыточно сложным для одного узла, часть привычных S3-фич отсутствовала, а разработка на время останавливалась (вопросы финансирования). С тех пор он, возможно, подтянулся, но «всё ещё ощущается слишком тяжёлым».

SeaweedFS: красиво, но медленно

SeaweedFS автор хвалит за архитектуру: мастер + тома, плюс надстройки для WebDAV и других протоколов. В продакшен-сценариях это ложится хорошо. Но на задаче «несколько гигабайт на LAN» SeaweedFS у него стабильно упирался в скорость:

Запускаю мастер и ноду тома — медленно. Переключаюсь на новый weed mini — всё равно медленно. В хранилище лежит пара гигабайт обычных файлов, ничего особенного, но даже в собственной локалке скачивание начинается с пары сотен килобайт в секунду и едва разгоняется до 10 Мбит/с. Почему?

Корень проблемы автор так и не нашёл — но именно это заставило его продолжить поиск.

CEPH: не для маленькой задачи

CEPH — мощная распределённая система, которую автор использует на работе. Он честно признаёт: если нужно построить что-то уровня Amazon S3, CEPH или близкий к нему SeaweedFS — разумный выбор. Для одного узла с парой гигабайт данных — это «монстр», разворачивать который ради быстрого S3 дома бессмысленно.

Versity GW: победитель

Versity S3 Gateway — малоизвестный проект, используемый Sandia National Labs, Los Alamos National Lab, военными и университетами. Автор узнал о нём из треда Reddit про бенчмарки S3-бэкендов.

Versity S3 Gateway поддерживает обобщённое POSIX-хранилище и собственную файловую систему ScoutFS.

ScoutFS — это собственная POSIX-совместимая ФС Versity для HPC-сценариев (высоконагруженные научные вычисления); для домашнего сервера она не нужна, хватит любой локальной ФС с поддержкой xattrs. Основной сценарий Versity — шлюз: он может проксировать другие S3-бэкенды, чтобы не светить их учётки наружу или прикручивать свой слой аутентификации.

Важное для его задачи: Versity умеет просто использовать локальную файловую систему как S3-хранилище, даёт веб-интерфейс с управлением политиками и анонимными/публичными бакетами. Метаданные объектов он хранит в xattrs — расширенных атрибутах файлов.

Развёртывание заняло ровно столько, сколько нужно для rclone-синка данных. Скачивание на LAN сразу пошло на линейной скорости сети.

Поздние контендеры

После публикации статьи и перехода на Versity автор наткнулся ещё на несколько решений. Он не тестировал их, но оставил заметки — полезно как стартовый список, если Versity по каким-то причинам не подходит.

RustFS

RustFS — ещё один новый S3 на Rust. По бенчмаркам быстрее MinIO (оба POSIX-бэкенд), заявлена 100%-совместимость с S3. Разработка началась в декабре 2023, публичный запуск — 2 июля 2025. Авторы обещают миграцию с MinIO прямой заменой бинарника. Интересная фича: если отдать RustFS целые диски, он сам распределит данные и умеет восстанавливаться при замене сломанного диска. Минусы по мнению автора: Rust (долгая компиляция), отсутствие во FreeBSD ports (пришлось бы портировать самому), потеря производительности на мелких объектах из-за работы напрямую с ФС вместо собственного формата.

rclone как S3-сервер

rclone умеет выступать S3-сервером, но автор не считает это основной функцией: скорее всего, режим сервера сделан для тестирования клиента. В продакшен полагаться не стоит.

filestash

filestash начинался как Dropbox-подобный менеджер файлов поверх любого протокола хранения: FTP, SFTP, S3, SMB, WebDAV, IPFS и ещё около двадцати. Автор планирует посмотреть подробнее — как «всё в одном».

Zenko CloudServer

Zenko CloudServer написан на Node.js. Автор кратко замечает: «наслаждайтесь однопоточным event loop» — намёк на то, что для высоконагруженных сценариев это не лучший выбор.

Supabase Storage

Supabase Storage тоже на Node.js, но интересен тем, что метаданные хранит в Postgres, а авторизация сделана через Row Level Security. Для проектов, где уже есть Postgres, такая связка может оказаться удобнее отдельного S3-сервера.

Выводы

Статусный MinIO превратился в корпоративный продукт, а среди open-source альтернатив нет очевидного лидера для простого сценария «S3 на одной машине». CEPH и SeaweedFS оптимизированы под кластер, Garage молод, RustFS и Supabase ещё не доехали до массового использования.

Versity GW оказался тем, что закрывает узкую задачу: S3-шлюз поверх локальной ФС, веб-интерфейс, работает на линейной скорости сети. За ним стоят серьёзные институции (национальные лаборатории США, университеты), что косвенно снимает вопросы к стабильности.

Наконец-то здравый смысл восстановлен.

Если у вас похожая задача — разверните Versity GW и сравните со своим текущим MinIO или SeaweedFS. Если захотите остаться на Rust — смотрите RustFS, особенно если планируете отдавать ему диски целиком.

Оригинал — Jonathan Feld, «I Just Want Simple S3», 10 апреля 2026 года.

• Платный картографический API → OSRM: экономия в 10–15 раз — реальный кейс delivery-платформы
• Email, мониторинг, CI/CD, аналитика, хранилище и чат — в каждой категории есть зрелая open-source альтернатива
• Для российских компаний self-hosting особенно актуален: западные сервисы ушли, а российские SaaS дорожают
• Docker Compose + VPS — минимальный порог входа для большинства инструментов
• Скрытые затраты: время на поддержку, бэкапы, обновления — закладывайте их в расчёт экономии

Почему self-hosting стал мейнстримом

Три года назад self-hosting был уделом энтузиастов с домашними серверами. Сейчас это осознанный бизнес-выбор. Причин несколько.

Цены SaaS растут быстрее инфляции. Яндекс Карты API стоят от 195 000 ₽ в год за минимальный тариф. VK Teams — от 207 ₽ за пользователя в месяц, и это базовый план. GitLab Premium — $29 за пользователя. Команды, которые закладывали скромный бюджет на SaaS-инструменты, через год обнаруживают счёт в разы больше.

Западные сервисы ушли из России. AWS, Slack, Heroku, 1Password, Datadog, Mailgun — всё это больше недоступно для российских компаний. Те, кто зависел от этих сервисов, были вынуждены мигрировать экстренно. Self-hosted решения не зависят от геополитики: ваш сервер, ваши данные, ваши правила.

Вендор-лок — реальный риск и на российском рынке. Тарифы меняются, условия ужесточаются, функциональность урезается. Если ваш бизнес-процесс завязан на конкретный SaaS — вы заложник его ценовой политики.

Приватность данных — юридический вопрос. 152-ФЗ о персональных данных, отраслевые требования (PCI DSS, банковская тайна) — многие компании обязаны хранить данные на собственной инфраструктуре. Self-hosted решает это по определению.

Инфраструктура подешевела. VPS на Timeweb Cloud стоит от 477 ₽/мес, на Selectel — сравнимо. 4 ГБ RAM и 80 ГБ SSD — достаточно для большинства self-hosted инструментов. Docker Compose снял барьер входа: развернуть сервис — это написать 30 строк YAML.

Кейс: платный картографический API → OSRM, экономия в 15 раз

Delivery-платформа с несколькими тысячами заказов в день платила за картографический API десятки тысяч рублей ежемесячно — за геокодирование адресов, построение маршрутов и отображение карт в приложении курьера. Для контекста: Яндекс Карты API стоят от 195 000 ₽/год только за JavaScript API при 1 000 запросов в сутки. При росте нагрузки счёт быстро уходит за миллион.

Стек замены:

• OSRM (Open Source Routing Machine) — построение маршрутов, аналог Directions API
• Nominatim — геокодирование и обратное геокодирование на данных OpenStreetMap
• OpenStreetMap — картографические данные, обновляются сообществом
• TileServer GL — для отображения тайлов в приложении

Итог: VPS с 16 ГБ RAM для OSRM (маршрутизация требовательна к памяти, данные OSM для региона занимают 10–30 ГБ) плюс инстанс для Nominatim. На Selectel или Timeweb это 3 000–5 000 ₽ в месяц вместо сотен тысяч за платный API.

Важный нюанс: OSRM строит маршруты быстрее платных API за счёт предвычисленных графов (алгоритм Contraction Hierarchies). Для курьерской логистики это плюс — время отклика ниже 50 мс при локальном развёртывании. Минус — карты OpenStreetMap в малонаселённых регионах России менее детализированы, чем Яндекс Карты. В крупных городах качество сопоставимо.

Категории замен: что и на что менять

Корпоративная почта: Яндекс 360 → Stalwart Mail

Яндекс 360 для бизнеса стоит от 249 ₽/пользователь/мес. Для команды из 50 человек — от 12 450 ₽/мес, или ~150 000 ₽/год. VK WorkMail — в том же диапазоне.

Stalwart Mail Server — современный self-hosted почтовый сервер на Rust: поддерживает SMTP, IMAP, JMAP, имеет встроенный антиспам, написан с нуля без легаси Postfix/Dovecot. Разворачивается одной командой через Docker. Альтернативы — Maddy (легче, для небольших команд) и Mailu (полный стек с веб-интерфейсом).

Что нужно учесть: для надёжной доставки писем важны корректные записи SPF, DKIM, DMARC и обратный DNS. IP-адрес VPS не должен быть в спам-листах. Self-hosted почта оправдана для корпоративной переписки. Для transactional email (сброс пароля, уведомления) можно использовать self-hosted Haraka или Postal.

Мониторинг: платные облачные решения → Grafana + Prometheus

Платный мониторинг в облаке — это либо встроенные решения провайдера (Яндекс Monitoring, VK Cloud), либо коммерческие лицензии Zabbix Enterprise. При росте количества хостов и метрик стоимость быстро растёт: Zabbix Enterprise стоит от нескольких сотен тысяч рублей в год в зависимости от масштаба.

Стандартный self-hosted стек: Prometheus (сбор метрик) + Grafana (дашборды и алёрты) + Loki (агрегация логов) + Tempo (трейсинг). Grafana Labs предоставляет весь стек под открытой лицензией. На tproger.ru есть подробный материал о Grafana Mimir — горизонтально масштабируемом хранилище для Prometheus-метрик.

Prometheus + Grafana — де-факто стандарт в Kubernetes-инфраструктурах, поэтому переход обычно не требует переобучения команды. При этом вы получаете полный контроль над данными и никаких ограничений на количество метрик.

CI/CD: GitLab SaaS → Gitea + Woodpecker или GitLab CE

GitLab Premium стоит ~$29/пользователь/мес. Для команды из 20 разработчиков — около $7 000 в год. Платные раннеры GitLab SaaS расходуются быстро: команда с активным CI легко тратит $500–1 500/мес на compute-минуты.

Gitea — лёгкий self-hosted Git-хостинг (форк Gogs), занимает меньше 100 МБ RAM. В связке с Woodpecker CI (форк Drone CI) получаете полный аналог GitHub/GitLab. Синтаксис pipeline в Woodpecker намеренно похож на GitHub Actions — миграция занимает часы.

Альтернатива — GitLab CE (Community Edition): бесплатная self-hosted версия GitLab со встроенным CI/CD. Требует больше ресурсов (минимум 4 ГБ RAM), но даёт знакомый интерфейс без платной подписки. Раннеры запускаете на своих серверах — никаких лимитов на минуты.

Аналитика: Яндекс Метрика → Plausible или Umami

Яндекс Метрика бесплатна, но собирает данные ваших пользователей на серверах Яндекса. Для многих компаний это приемлемо. Но если вы работаете с персональными данными, подпадаете под 152-ФЗ или просто не хотите отдавать пользовательскую аналитику третьей стороне — есть self-hosted альтернативы.

Plausible Community Edition и Umami разворачиваются за 15 минут через Docker Compose. Скрипт аналитики весит 1 КБ — страницы грузятся быстрее, и блокировщики рекламы пропускают трафик, потому что запросы идут на ваш домен.

Plausible и Umami не используют cookies и не собирают персональные данные. Это снимает необходимость в cookie-баннерах и упрощает соблюдение 152-ФЗ. Данные хранятся на вашем сервере — никакая третья сторона к ним доступа не имеет.

Объектное хранилище: облачный S3 → MinIO

S3-совместимые хранилища есть у всех российских облачных провайдеров: Яндекс Object Storage, Selectel (от 2,33 ₽/ГБ/мес), VK Cloud. При 10 ТБ данных и активном чтении месячный счёт легко превышает 50 000 ₽.

MinIO — объектное хранилище с S3-совместимым API. Любой код, который работает с S3, работает с MinIO без изменений — достаточно поменять endpoint в конфигурации. На tproger.ru есть практический материал о работе с MinIO в проекте на Go.

MinIO поддерживает erasure coding (избыточность данных), шифрование на уровне объектов и горизонтальное масштабирование. Для хранения медиафайлов, бэкапов и артефактов CI/CD — полноценная замена облачного S3. Стоимость: только ваш сервер или NAS.

Чат и коммуникации: Pachca / VK Teams → Mattermost или Matrix

VK Teams стоит от 207 ₽/пользователь/мес (базовый) до 367 ₽ (расширенный). Pachca — бесплатна для малых команд, но платные тарифы стоят сопоставимо. Для компании из 100 человек на VK Teams — от 20 700 ₽/мес, или ~250 000 ₽/год.

Mattermost — наиболее близкий аналог Slack и VK Teams по UX. Есть мобильные и десктопные клиенты, интеграции, боты, webhook'и. Self-hosted версия бесплатна и поддерживает неограниченную историю сообщений, неограниченное количество пользователей и полный контроль над данными.

Matrix / Element — децентрализованный протокол мгновенных сообщений. Подходит, если нужна федерация между организациями или максимальная приватность. Сервер Synapse или более лёгкий Conduit разворачиваются на VPS за 15 минут.

Пароли и секреты: Passwork / Bitwarden → Vaultwarden

Passwork — российский менеджер паролей для команд, on-premise решение со стоимостью по запросу (от нескольких сотен тысяч рублей за лицензию). Bitwarden cloud — $4/пользователь/мес для бизнеса. Для команды из 20 человек — от $960/год.

Vaultwarden — неофициальная реализация Bitwarden-сервера на Rust, совместимая со всеми официальными клиентами Bitwarden (браузерные расширения, мобильные приложения, CLI). Потребляет меньше 10 МБ RAM. Разворачивается за 5 минут, хранит данные в SQLite. Пожалуй, самое популярное self-hosted приложение в сообществе r/selfhosted.

Когда self-hosting не стоит усилий

Self-hosting — не серебряная пуля. Есть ситуации, когда платный SaaS оправдан.

• Нет DevOps-компетенций в команде. Развернуть сервис несложно — поддерживать его, обновлять, настраивать бэкапы и отвечать за uptime сложно. Если этим некому заниматься, экономия превратится в потери
• Нагрузка непредсказуема. SaaS масштабируется автоматически. Self-hosted требует заранее выделенных ресурсов — или вы упадёте в пиковый момент
• Сервис критичен и требует SLA. Корпоративные SaaS предлагают гарантии uptime и поддержку 24/7. Ваш self-hosted сервер — нет
• Экономия меньше стоимости времени. Если экономия составит 3 000 ₽/мес, а поддержка требует 5 часов инженерного времени — это убыток

Практическое правило: self-hosting оправдан, если экономия превышает стоимость 2–4 часов DevOps-времени в месяц на поддержку. Для большинства инструментов из этого списка это выполняется уже при команде от 5–10 человек.

Вывод

Для российских компаний self-hosting — не просто способ сэкономить, а стратегическое решение. Западные SaaS ушли, российские облачные сервисы дорожают, а требования к локализации данных ужесточаются. Self-hosted инструменты решают все три проблемы одновременно.

Рецепт прост: выпишите все SaaS-подписки, посчитайте годовые затраты по каждой категории из этого списка, оцените DevOps-ёмкость команды. Те сервисы, где экономия в 5–10 раз перекрывает стоимость поддержки, — кандидаты на миграцию. Начните с самого дорогого или самого простого в замене — и замерьте результат через квартал.

Сообщество r/selfhosted — хорошее место для старта: там регулярно появляются свежие кейсы, сравнения и готовые Docker Compose-конфиги для большинства инструментов из подборки.

Эту статью будет проще читать, если вы знакомы с основами Yoke и Air Traffic Controller.

Если вкратце, Yoke позволяет определять пакеты как распространяемые программы, скомпилированные в WASM, которые называются Flights («рейсы»). Air Traffic Controller («диспетчер воздушного движения») расширяет API Kubernetes через Airways («воздушные трассы») — специальный ресурс, который создаёт CRD и связывает его с конкретным Flight.

Этот материал как раз о том, как Air Traffic Controller открывает простор для мощной и гибкой оркестрации ресурсов.

За пределами плоского YAML: как выглядит реальная оркестрация в Kubernetes

Если вам доводилось управлять современными сложными приложениями в Kubernetes, то наверняка знакомо чувство тревоги, когда ждёшь, пока все ресурсы перейдут в healthy-статус. Например, база данных должна быть готова до запуска приложения, серия пакетных задач (batch jobs) должна выполниться в строгой последовательности, а сервис может зависеть от секрета, которым управляет совершенно другая система. Как описать эти взаимоотношения? Сегодня, по большому счёту, никак.

Годами Helm и Kustomize были основными инструментами для управления Kubernetes-приложениями. Но они работают как генераторы манифестов: вы описываете список YAML-файлов, отправляете их в API и надеетесь, что всё сработает. Для простых stateless-приложений это нормально, но когда нужны порядок выполнения, координация между компонентами или управление состоянием — такой подход не годится.

Вот тут и встаёт вопрос оркестрации: способности осмысленно управлять жизненным циклом компонентов приложения, а не просто создавать их, надеясь на удачу.

Пробел в оркестрации

Причина этого пробела кроется в истории. Инструменты вроде Helm и Kustomize — это, по сути, шаблонизаторы на стороне клиента. Они генерируют манифесты, и на этом их работа заканчивается. Даже серверные GitOps-решения вроде Argo CD или FluxCD придерживаются той же концепции, ведь они преимущественно используют те же инструменты для генерации манифестов, которые потом синхронизируют за вас.

Конечно, есть обходные пути. Вы наверняка сталкивались с хуками pre/post-install в Helm или волнами синхронизации (sync waves) в Argo CD. И хотя это полезные фичи, проблема решается лишь частично. Они срабатывают только при установке или обновлении, но не работают на протяжении всей жизни приложения.

Пара слов о YAML и итоговой согласованности

Мы осознаем, что предложение отойти от использования YAML воспринимается неоднозначно. Для многих в сообществе «голые» манифесты — единственный «правильный» способ взаимодействия с API Kubernetes. Такая привязанность привела к тому, что для решения сложных проблем с зависимостями все стали активно полагаться на один базовый паттерн — итоговую согласованность (eventual consistency).

Идея в том, чтобы выкатить всё разом и просто надеяться, что рано или поздно контроллеры всё приведут к желаемому состоянию, зависимости подтянутся и кластер сам… заведётся. Все мы видели это на практике: под уходит в CrashLoopBackOff и висит в нём, пока какая-нибудь другая система наконец не создаст нужный ему ConfigMap или Secret.

Сразу поясним: итоговая согласованность — это фундаментальная часть Kubernetes и очень мощная идея. Проблема в том, что мы слишком долго использовали её как единственный инструмент для управления комплексными воркфлоу. Нам приходилось на неё полагаться, потому что имеющиеся инструменты не давали иного выбора: что имеем, тем и пользуемся. Наши YAML-ориентированные утилиты могли описать лишь то, что мы хотим получить в итоге, но не то, как к этому прийти.

Дилемма оператора

Классический ответ на запрос о создании умных и гибких стратегий развёртывания всегда был один: «Пишите свой оператор».

И хотя создание оператора — мощный и правильный подход, это ещё и масштабная задача. Здесь и высокий порог входа, и постоянные расходы на разработку и поддержку, которые далеко не всегда оправданы. Неужели нет золотой середины?

Новая модель: логика приложения как код

Вот тут-то на сцену и выходят Yoke и Air Traffic Controller (ATC) с новым образом мышления. Вместо того чтобы генерировать статичный набор YAML-файлов, Yoke описывает пакеты в виде исполняемого кода.

Это позволяет сфокусироваться на логике оркестрации приложения, написав простую [WASM] программу, работающую по знакомой схеме:

1. Прочитать входные параметры из кастомного ресурса.
2. Принять решения, основываясь на текущем состоянии кластера.
3. Обновить статус кастомного ресурса, указав прогресс или другую информацию.
4. Создать те ресурсы, которые должны быть в кластере прямо сейчас.

И да, это очень похоже на классический цикл согласования (reconciliation loop) в контроллере Kubernetes — так и задумано.

ATC — это контроллер, чья единственная работа — приводить ресурсы в кластере к желаемому состоянию. WASM-модуль представляет собой ядро логики и выступает посредником для цикла согласования, управляя желаемым состоянием (ресурсами) пакетов и избавляя вас от необходимости создавать и поддерживать собственный оператор с нуля.

Как это работает на практике

По своей сути, «Flight» в Yoke — это просто программа (скомпилированная в WASM; аналог Helm-чартов), которая считывает кастомный ресурс (Custom Resource) из stdin и записывает желаемое состояние системы в stdout.

Но поскольку ATC перезапускает её в рамках цикла управления (control loop), она становится динамической и реагирующей. Код выполняется каждый раз, когда:

• ресурс, которым он управляет (например, Job или Deployment), обновляется или удаляется;
• внешний ресурс, который он отслеживает (например, Secret от другого инструмента), создаётся, обновляется или удаляется.

Так код реагирует на изменения в кластере в реальном времени.

Примеры

Пример 1: пайплайн для последовательного запуска задач

Предположим, вам нужно создать ресурс Pipeline для запуска трёх задач друг за другом: job-one, job-two, job-three. При этом каждая следующая задача должна стартовать только после успешного завершения предыдущей.

С Yoke эту логику можно описать прямо в коде.

Сначала определим Go-тип для кастомного ресурса Pipeline:

Затем добавим соответствующее определение Airway, которое указывает ATC, как им управлять:

Основная магия содержится в WASM-модуле. Рассмотрим её пошагово:

Эта простая Go-программа как раз и реализует логику оркестрации. Она создаёт задачу, проверяет её статус и движется дальше, только когда та завершится. А цикл управления от ATC берёт на себя всю рутину по «ожиданию» и «перезапускам».

Пример 2: координация с внешними ресурсами

Рассмотрим другой распространённый сценарий: приложению требуется база данных. Вы используете Crossplane для инициализации CloudSQLInstance, который в итоге создаёт Secret, содержащий данные для подключения. Deployment не запустится до тех пор, пока этот Secret не будет существовать.

Сегодня вы, скорее всего, просто выкатываете всё сразу и ждёте, когда появится секрет (под приложения находится в состоянии CrashLoopBackOff). Но можно поступить умнее.

Давайте опишем ресурс App, который будет управлять этим процессом:

Airway нужно будет настроить так, чтобы он имел доступ к кластеру, а если точнее — чтобы мог искать ресурсы типа Secret.

Логика в нашем WASM-модуле будет такой:

Эта логика описывает зависимость: создать базу данных, дождаться секрета и только после этого развернуть приложение. Больше никаких подов в состоянии CrashLoopBackOff, только чистая оркестрация с отслеживанием состояния!

Заключительные мысли

Применяя подход «логика приложения как код», Yoke предлагает компромисс между статическими YAML-шаблонами и полнофункциональными операторами. Он позволяет кодифицировать сложные, активно реагирующие стратегии развёртывания с отслеживанием состояния, используя привычные языки программирования и инструменты, делая настоящую оркестрацию доступной для каждого.

MLOps — это правила, версии и автоматизация для жизненного цикла ML-модели: от данных и обучения до деплоя, мониторинга качества и переобучения. Проще говоря, MLOps нужен, чтобы модель не жила в режиме train.ipynb и чатов с сообщениями “какую версию мы вообще выкатили?”.

— MLOps не заменяет DevOps: он добавляет к нему данные, эксперименты, модели и контроль качества после релиза.

— Главная задача MLOps — сделать обучение, выкладку и сопровождение модели воспроизводимыми.

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

— Начать можно без огромного стека: часто достаточно CI/CD, понятного трекинга экспериментов, одного способа деплоя и мониторинга качества.

— Если модель влияет на продукт или деньги, ручной процесс почти всегда становится слишком дорогим и хрупким.

Где заканчивается DevOps и начинается MLOps

В обычном DevOps мы доставляем код: собираем приложение, тестируем, выкатываем, следим за доступностью и ошибками. В ML-системе этого мало, потому что итог зависит не только от кода, но и от того, на каких данных модель обучалась, как считались признаки и не изменился ли сам входной поток.

• В DevOps главный артефакт обычно релиз приложения или контейнер. В MLOps артефактов больше: код, данные, конфигурация обучения, модель, метрики и правила выкладки.
• В DevOps после релиза вы в основном смотрите на uptime и ошибки. В MLOps этого недостаточно: сервис может быть здоровым, а качество предсказаний уже проседать.
• В DevOps откат часто означает вернуть прошлую версию приложения. В MLOps иногда нужно откатывать ещё и модель, и связанный с ней pipeline.
• В MLOps часто автоматизируют не только доставку, но и сам ML-pipeline. В обзоре Google Cloud это описано как отдельные уровни зрелости: continuous training и automation вокруг ML-процесса, а не просто “ещё один деплой”.

Если упростить до одной фразы, DevOps отвечает на вопрос “как надёжно возить приложение”, а MLOps — “как надёжно возить модель, которая со временем стареет и зависит от данных”.

Простой пример: как MLOps выглядит вживую

Допустим, у вас есть модель, которая советует товары в интернет-магазине. Раз в неделю команда обновляет данные о просмотрах, покупках и корзинах, обучает новую версию модели и решает, стоит ли пускать её в production.

В этом и есть суть MLOps: команда может повторить обучение, понять происхождение модели, безопасно выкатить новую версию и вовремя заметить, что она перестала приносить пользу.

Что именно MLOps держит под контролем

• Данные. Важно знать, на каком срезе данных обучали модель, какая у него схема и какие шаги подготовки применялись.
• Код и конфигурацию обучения. Без них нельзя честно воспроизвести эксперимент.
• Эксперименты. Нужно видеть, какой запуск дал лучшие метрики и почему.
• Реестр моделей. Он нужен не только для хранения, но и для управления жизненным циклом: кандидат, staging, production, rollback.
• Сервинг и качество после релиза. Модель должна быть не просто “задеплоена”, а полезна на живых данных и понятна по состоянию.

Здесь есть важная тонкость: “версия данных” — это не просто ссылка на папку. Обычно нужен хотя бы воспроизводимый снапшот, схема, split на train и validation и понимание, как были собраны признаки. Иначе воспроизводимость остаётся на словах.

Какой стек нужен на старте

MLOps не начинается с покупки большого комбайна. Для большинства команд старт выглядит довольно приземлённо.

• CI/CD для кода и пайплайнов, чтобы обучение и деплой не жили только на ручных командах.
• Трекинг экспериментов и реестр моделей. Чаще всего тут закрывают базовые боли MLflow или похожим инструментом.
• Один понятный способ выкладки: отдельный сервис, batch-job или managed endpoint в облаке.
• Мониторинг инфраструктуры и качества модели. Если у вас уже есть единая наблюдаемость, сюда хорошо стыкуются подходы из OpenTelemetry.
• Kubeflow Pipelines имеет смысл рассматривать тогда, когда у вас уже много ML-пайплайнов и вы реально живёте в Kubernetes, а не просто хотите “поставить серьёзный инструмент”.

Проще говоря, хороший стартовый MLOps-стек должен убирать ручные шаги, а не добавлять новые сущности ради модных слов.

Когда MLOps уже нужен

• Модель уже влияет на деньги, выдачу, рекомендации, скоринг или другой продовый результат.
• Команда регулярно обучает новые версии и больше не может держать всё в ноутбуках и чатах.
• Стало трудно ответить на простые вопросы: какая версия сейчас в production, на каких данных она училась и как её откатить.
• После релиза важны не только uptime и latency, но и бизнес-метрики модели.
• В ML-процессе участвуют уже не один исследователь, а несколько ролей: ML, backend, infra, аналитика, продукт.

Если же модель пока живёт в чистом исследовании и до production ещё далеко, полноценный MLOps-слой может быть преждевременным. Сначала полезнее навести порядок в базовой инженерии, а потом уже усложнять процесс.

Типичные ошибки

• Думать, что MLOps = один инструмент вроде Kubeflow. Это подход, а не название продукта.
• Версионировать только код и забывать про данные, признаки и конфигурации.
• Считать успешный деплой доказательством качества модели.
• Не иметь model registry и нормального процесса продвижения модели между окружениями.
• Строить тяжёлую платформу раньше, чем команда научилась воспроизводимо обучать и выкатывать хотя бы одну модель.

Главное

MLOps нужен в тот момент, когда модель перестаёт быть разовым экспериментом и становится частью production-системы. Если команда умеет повторить обучение, понимает происхождение модели, безопасно выкатывает её и следит за качеством после релиза, значит MLOps у неё уже начинает работать. Если нет, почти любой рост ML-продукта быстро превратится в ручной хаос.

Если хочешь глубже понять соседние слои инфраструктуры, смотри также материалы про CI/CD, Kubernetes, GitOps и roadmap DevOps-инженера. Они помогают увидеть, на какой инфраструктурной базе MLOps обычно строится.

GitOps появился как ответ именно на эту проблему. Идея простая: желаемое состояние приложения и инфраструктуры хранится в Git, а специальный контроллер сам приводит кластер к этому состоянию. Разработчик не «деплоит руками» в Kubernetes, а меняет конфигурацию в репозитории, после чего система синхронизирует окружение с Git.

GitOps — это способ управлять конфигурацией и деплоем через Git, а не через ручные действия в кластере.

Он не заменяет CI/CD: CI собирает артефакт, а GitOps следит, чтобы среда реально пришла к состоянию из репозитория.

На практике GitOps чаще всего встречается в Kubernetes-связке с Argo CD или Flux CD, Helm и Kustomize.

Главная ценность GitOps — прозрачная история изменений, воспроизводимость и меньше ручных правок в production.

Если у команды ещё нет Docker, CI/CD, review-процесса и понятной структуры конфигурации, GitOps внедрять рано.

Если у вас ещё плавают базовые термины, лучше идти по цепочке: Git и GitHub, CI/CD, Kubernetes и Helm. Но если кластер у вас уже есть, а релизы всё ещё зависят от ручного kubectl, значит вы уже упёрлись в ту самую проблему, которую GitOps решает.

Что такое GitOps и зачем он нужен

GitOps — это способ управлять выкладкой и конфигурацией через Git. Манифесты, Helm values, Kustomize-оверлеи и другие декларативные описания лежат в репозитории, а изменения проходят через обычный процесс: commit, pull request, review и merge. После этого контроллер в кластере приводит среду к состоянию из Git.

Если говорить языком OpenGitOps и Argo CD, у вас есть desired state в Git и live state в кластере. Когда они расходятся, система показывает drift и может синхронизировать окружение обратно к версии, зафиксированной в репозитории.

• Git хранит не только код, но и манифесты, Helm chart-ы, Kustomize-конфигурации и параметры окружений.
• Изменения проходят через review и историю коммитов, а не через ручной доступ к production.
• Откат для декларативной конфигурации часто сводится к возврату предыдущего commit или merge request.
• Состояние среды становится проверяемым: то, что описано в репозитории, должно совпадать с тем, что реально запущено.

Если совсем коротко: CI/CD отвечает на вопрос «как собрать и доставить новую версию», а GitOps — на вопрос «как гарантировать, что среда реально живёт по описанию из Git».

Как работает GitOps на практике

Основная механика GitOps крутится вокруг трёх сущностей: репозиторий с желаемым состоянием, контроллер в кластере и цикл синхронизации. Разработчик меняет не сам кластер, а конфигурацию в Git. Контроллер читает репозиторий, сравнивает его с реальным состоянием и приводит окружение к нужной версии.

Git как источник истины

Проще всего думать так: Git хранит не “примерную конфигурацию”, а целевое описание среды. Если сервис должен работать с двумя репликами, конкретным образом и определёнными ingress-правилами, именно репозиторий считается источником этой правды.

Это не единственно правильная структура, но принцип один и тот же: production описан в Git, а не существует только в голове дежурного инженера или в shell history.

Контроллер и reconciliation loop

В кластере обычно работает GitOps-контроллер или стек контроллеров, например Argo CD или Flux CD. Он регулярно сравнивает репозиторий с текущим состоянием среды. Если что-то не совпадает, приложение помечается как рассинхронизированное, а дальше система либо показывает diff, либо сама подтягивает кластер к desired state из Git.

Почему это лучше ручного kubectl

Ручной деплой ломается не только из-за ошибок в YAML. Он ломается из-за неявности: непонятно, кто и когда поменял кластер, почему staging отличается от production и какой набор команд вообще был выполнен. GitOps убирает эту “устную традицию”: история изменений живёт в commit и pull request, а не в чьей-то памяти или shell history.

Самый понятный сценарий выглядит так: CI собрал образ api:1.4.2, команда поменяла тег в values-prod.yaml через pull request, после merge Argo CD подтянул новую конфигурацию в кластер. Если кто-то потом руками вернёт старый тег или изменит число реплик прямо в live-среде, контроллер увидит drift и покажет, что кластер разошёлся с Git.

Чем GitOps отличается от CI/CD

GitOps часто путают с CI/CD, потому что обе темы связаны с доставкой изменений. Но зона ответственности у них разная: CI/CD собирает и публикует артефакт, а GitOps отвечает за то, чтобы среда действительно пришла к конфигурации из Git.

• CI проверяет код: тесты, линтеры, сборка, статический анализ.
• CD публикует артефакт: image, package, release или deployment-пакет.
• GitOps управляет desired state среды: манифестами, Helm values, Kustomize-оверлеями и другими конфигурациями.
• В реальной цепочке они работают вместе: CI собрал образ, CD довёл его до registry, а GitOps синхронизировал кластер с новой конфигурацией из Git.

Поэтому фраза «GitOps заменяет CI/CD» некорректна. Типовой сценарий такой: CI собрал образ api:1.4.2, команда обновила тег в values-prod.yaml через pull request, после merge Argo CD увидел diff и применил новый релиз в кластер. Пока этот последний шаг живёт вне Git, у вас есть CI/CD, но нет управляемого desired state.

Какие инструменты чаще всего используют для GitOps

GitOps — это не конкретный продукт, а подход. Но в Kubernetes-мире есть несколько типовых инструментов, которые чаще всего закрывают эту задачу.

• Argo CD — удобный первый выбор, если нужен понятный UI, diff, sync-статусы и наглядная работа с приложениями в Kubernetes.
• Flux CD — GitOps-стек из нескольких контроллеров, который часто выбирают команды, предпочитающие максимально Git-centric и CRD-based подход.
• Helm — не GitOps-инструмент сам по себе, а упаковочный слой для релизов, с которым удобно работать GitOps-контроллеру.
• Kustomize — способ описывать вариации конфигурации без шаблонов; часто используется там, где команда хочет хранить разные окружения рядом, но без Helm chart-ов.

Для первого внедрения обычно не нужен сложный зоопарк инструментов. Достаточно одной понятной связки: например, Argo CD плюс Helm или Flux CD плюс Kustomize. Важнее не количество компонентов, а дисциплина: изменения в production идут только через Git.

Где GitOps особенно полезен, а где его рано внедрять

GitOps особенно хорошо раскрывается там, где уже есть несколько окружений, несколько сервисов и больше одного человека, который влияет на деплой. Как только конфигурация начинает жить отдельно от кода, а изменения попадают в кластер в обход review, GitOps перестаёт быть модным словом и становится способом вернуть контроль над средой.

• Уже пора: у вас есть Kubernetes, staging и production, несколько сервисов или несколько команд, а история изменений в кластере должна быть прозрачной.
• Уже пора: релизы регулярно упираются в ручной kubectl, чат-инструкции или правки values-файлов мимо pull request.
• Пока рано: если у вас ещё нет нормального контейнерного и CI/CD-фундамента.
• Пока рано: если команда пока не умеет поддерживать манифесты, Helm values и окружения в Git без хаоса и копипаста.

GitOps не чинит плохую инженерную дисциплину автоматически. Если в репозитории бардак, нет review, chart-ы размножены копированием, а secrets живут где попало, контроллер начнёт очень последовательно раскатывать этот бардак по окружениям.

Типичные ошибки при внедрении GitOps

1. Считать, что GitOps = Argo CD. Argo CD — только один из инструментов, а не весь подход целиком.
2. Пытаться внедрить GitOps до Docker, CI/CD и базовой дисциплины вокруг Git и review.
3. Хранить в Git хаотичную конфигурацию без структуры по окружениям, сервисам и зонам ответственности.
4. Смешивать сборку артефакта и управление состоянием среды в один непрозрачный pipeline.
5. Оставлять ручные hotfix-изменения в кластере без возврата их в репозиторий.
6. Думать, что GitOps отменяет мониторинг, rollback-план и нормальную эксплуатацию stateful-компонентов.

Хороший тест на зрелость простой: после инцидента вы открываете Git и видите, какая конфигурация должна быть в production. Потом возвращаете кластер к этому состоянию без ручной магии. Но важно помнить границу: GitOps хорошо откатывает декларативные ресурсы и desired state, а миграции базы, данные и внешние зависимости всё равно требуют отдельного плана.

С чего начать GitOps без лишней боли

Не надо сразу переводить на GitOps весь кластер и каждую сервисную мелочь. Нормальный старт — один сервис, одно непроизводственное окружение и очень понятный путь изменений.

1. Выберите один сервис или namespace и храните его манифесты, Helm values или Kustomize-конфигурацию в Git.
2. Подключите Argo CD или Flux CD и сначала добейтесь прозрачного diff и понятного sync-статуса, а не полной магии.
3. Зафиксируйте правило: изменения в production идут только через pull request, без ручных правок через kubectl.
4. Отдельно опишите rollback для миграций, данных и stateful-изменений: Git-rollback сам по себе не откатывает всё подряд.

Когда команда привыкнет к этой дисциплине на одном сервисе, можно переносить на GitOps другие окружения и приложения. Самый плохой сценарий — внедрять красивый термин, не меняя review-процесс, ownership и работу с конфигурацией.

Выводы

GitOps — это не магическая кнопка и не синоним CI/CD. Это способ сделать деплой и конфигурацию прозрачнее: изменения проходят через Git, состояние среды сравнивается с репозиторием, а drift, откаты и расследования становятся понятнее. Особенно хорошо это работает там, где Kubernetes уже есть, а цена ручных действий в production быстро растёт.

Если вам ещё рано, сначала доберите базу: Git и GitHub, Docker, CI/CD, Kubernetes и Helm. Если база уже есть и релизы всё ещё упираются в ручной доступ к кластеру, GitOps — логичный следующий шаг. А дальше уже можно разбираться с Argo CD и более сложными сценариями.

Для практики лучше держать рядом и официальные материалы: OpenGitOps, Argo CD и Flux CD. Они помогут не перепутать общий принцип с конкретной реализацией.

Рабочий план обучения устроен иначе. Сначала нужно научиться уверенно работать с кодом, системой и сетью, потом собирать повторяемое окружение, затем автоматизировать доставку, описывать инфраструктуру, управлять кластерами и только после этого переходить к зрелым практикам вроде GitOps, политик в коде и платформенного подхода к инфраструктуре.

— Начинать стоит не с Kubernetes, а с Linux, терминала, сетей, Git и простых скриптов.

— Docker и CI/CD нужны раньше оркестрации: сначала вы делаете поставку повторяемой, потом масштабируете её.

— Для старта достаточно одного облака, одного CI-инструмента и одного стека наблюдаемости.

— Secrets, security, cost control и GitOps появляются не в конце карьеры, а после того, как у вас уже есть рабочая автоматизация.

— Лучший способ учиться — вести один реальный сервис через все этапы: локальный запуск, контейнер, pipeline, сервер, кластер, мониторинг и деплой.

Ниже — не список модных названий, а последовательный маршрут для разработчика, который хочет понять DevOps и довести обучение до практики. Порядок не высечен в камне: некоторые ветки можно изучать параллельно, но зависимости между слоями всё равно есть.

Что входит в работу DevOps-инженера

DevOps-инженер не просто «настраивает Kubernetes». Его задача — делать путь от коммита до работающего сервиса быстрым, предсказуемым и безопасным. Это значит, что нужно уметь читать код, понимать инфраструктуру, автоматизировать рутину, наблюдать систему после релиза и быстро чинить её, когда что-то пошло не так.

На практике в работу входят пять больших зон: среда исполнения, доставка изменений, инфраструктура, эксплуатация и безопасность. Поэтому хороший план обучения всегда шире, чем набор из Docker, Kubernetes и Terraform.

• Среда исполнения: Linux, процессы, файлы, сеть, сервисы, контейнеры.
• Доставка: Git, pull request, CI/CD, артефакты, окружения, rollback.
• Инфраструктура: облако, сети, IAM, Terraform, Ansible, managed-сервисы.
• Эксплуатация: метрики, логи, трассировка, алерты, инциденты, SLA и SLO.
• Безопасность: секреты, права доступа, сканирование образов, supply chain, политики.

Шаг 1. База: Linux, терминал, сети и скрипты

Первый слой DevOps — это не облака и не кластеры. Это уверенная работа в Linux, понимание того, как живут процессы и сервисы, умение читать логи и свободно пользоваться терминалом. Если вы не понимаете, что делает systemd, чем отличается порт от сокета и почему DNS резолвится не туда, дальше будет очень много механики без понимания.

Сюда же относится базовое скриптование. Не нужно сразу становиться backend-разработчиком, но умение писать небольшие утилиты на Bash или Python на практике очень помогает: разбирать логи, чистить артефакты, собирать конфиги, запускать health-check, дёргать API. Без этого DevOps быстро превращается в бесконечное копирование команд из чужих README.

• Linux: файловая система, права, процессы, systemd, пакеты, сервисы, cron.
• Terminal: ssh, curl, grep, sed, awk, перенаправления, пайпы.
• Сети: DNS, HTTP/HTTPS, TLS, reverse proxy, firewall, балансировщик, NAT.
• Скрипты: Bash для короткой автоматизации, Python или Go для более сложных утилит.
• Результат этапа: вы можете зайти на сервер, понять, что на нём происходит, и автоматизировать простую рутину без GUI.

Для входа в этот слой пригодятся материалы 100 команд Linux для ежедневной работы и что такое Git и GitHub. Даже если ваша цель — Kubernetes, этот фундамент пропускать нельзя.

Шаг 1.2. Язык для автоматизации: Bash, Python или Go

В полной карте DevOps почти всегда есть отдельная ветка про язык программирования. Смысл не в том, чтобы срочно стать backend-разработчиком на новом стеке, а в том, чтобы уметь писать автоматизацию, разбирать данные, работать с API и не бояться внутренностей CI/CD-скриптов. Для старта почти всегда достаточно Bash и Python; позже во многих инфраструктурных командах всплывает Go, потому что на нём написано много облачных и Kubernetes-инструментов.

Лучший практический подход такой: короткие shell-скрипты и glue-логика делайте на Bash, утилиты посложнее и интеграции с API пишите на Python, а Go держите как полезный следующий слой для более серьёзной автоматизации и понимания экосистемы Kubernetes. Ruby, JavaScript или Rust тоже встречаются, но они уже зависят от конкретной команды и окружения.

• Bash нужен почти каждому DevOps-инженеру: shell-обвязка, команды, пайплайны, entrypoint-скрипты, быстрая диагностика.
• Python удобен для API-интеграций, генерации конфигов, внутренней автоматизации и небольших CLI-утилит.
• Go полезен как следующий шаг: Terraform-, Kubernetes- и cloud-экосистема часто живёт рядом с ним.
• Результат этапа: вы умеете не только запускать команды, но и собирать из них рабочую автоматизацию.

Шаг 1.5. Терминальные инструменты, редакторы и базовая диагностика

В полной карте DevOps отдельной веткой идут знание терминала, работа с текстом, мониторинг процессов и наблюдение за производительностью. Это не декоративные подпункты, а повседневный набор инженера. Нужно уметь не только открыть shell, но и быстро понять, что грузит CPU, кто держит порт, какой процесс падает, где застрял запрос и что изменилось в системе после релиза.

Сюда же относятся редакторы и инструменты для правки текста прямо на машине. Не обязательно фанатично жить в vim, но знать хотя бы один консольный редактор полезно. Если вы иногда работаете с Windows-средой, пригодится и базовый PowerShell. В некоторых командах встречаются Windows-узлы или BSD-системы, но для старта основным остаётся Linux-маршрут: сама идея одна и та же, вы умеете диагностировать систему без GUI.

• Диагностика процессов и ресурсов: ps, top, htop, lsof, ss, journalctl, free, df.
• Текст и данные: grep, sed, awk, cut, sort, uniq, jq.
• Редакторы: vim, nano, VS Code Remote или любой другой инструмент, которым вы реально можете править конфиг на сервере без паники.
• Результат этапа: вы можете диагностировать систему, править конфиг, фильтровать данные и не тонуть в логах и процессах.

Шаг 1.6. Прокси, веб-серверы, балансировка и сетевые протоколы

В полной карте навыков отдельно вынесены forward proxy, reverse proxy, firewall, load balancer, caching server и web server. Для DevOps это фундамент прикладной инфраструктуры. Даже если вы не будете администрировать почтовые системы или edge-инфраструктуру каждый день, вы должны понимать, где заканчивается приложение и начинается сетевой слой перед ним.

Минимум на старте — уверенно разбираться в DNS, HTTP/HTTPS, TLS и SSH. Полезно знать, зачем нужны Nginx, Caddy, Apache или IIS, чем reverse proxy отличается от forward proxy, как работает кеширование на уровне приложения и фронт-прокси, и что делает балансировщик перед несколькими инстансами сервиса. Если проект касается почты, пригодятся и базовые представления о SMTP, IMAP/POP3, SPF, DKIM и DMARC.

Отдельный практический навык на этом слое — troubleshooting сетевых сбоёв. Нужно хотя бы на базовом уровне понимать TCP/IP, TLS-handshake, как читать ответ curl -v, чем помогают dig, nslookup, traceroute, mtr и tcpdump. Без этого любой сбой быстро превращается в гадание между приложением, прокси, DNS и сертификатом.

• Протоколы: DNS, HTTP/HTTPS, TLS, SSH, FTP/SFTP; для почтовой инфраструктуры — SMTP, IMAP, POP3, SPF, DKIM, DMARC.
• Сетевые примитивы: OSI-модель на практическом уровне, порты, NAT, firewall rules, white- и graylisting там, где это действительно нужно.
• Серверы и прокси: Nginx, Caddy, Apache HTTP Server, Tomcat, IIS, reverse proxy, forward proxy, caching layer, load balancer.
• Результат этапа: вы понимаете, как трафик доходит до сервиса, где его можно завернуть, защитить, закешировать или распределить.

Шаг 1.7. Когда нужен Windows- и PowerShell-путь

Большая часть DevOps-маршрута действительно крутится вокруг Linux, но в реальной инфраструктуре периодически встречаются Windows-серверы, AD-среды, IIS, .NET-сервисы и корпоративная автоматизация через PowerShell. Поэтому полезно понимать, где заканчивается универсальный Linux-фундамент и начинается специфический Windows-путь.

Для первого входа в профессию не нужно строить отдельную карьеру вокруг Windows, если ваша цель — современный облачный стек. Но знать базовый PowerShell, устройство Windows-сервисов, права, scheduled tasks и особенности IIS полезно. Это даёт гибкость: вы понимаете, как жить не только в Linux-кластере, но и в смешанной корпоративной инфраструктуре.

• PowerShell пригодится там, где есть Windows-серверы, AD, IIS или корпоративная автоматизация.
• Linux остаётся основным путём для старта, но знание Windows-инструментов расширяет рынок и спектр задач.
• Если ваша цель — современный облачный стек, держите Windows как дополнительную ветку, а не как главный трек.
• Результат этапа: вы понимаете, когда PowerShell действительно нужен, а когда достаточно Linux-инструментов.

Шаг 2. Git, GitHub и командная разработка

Следующий обязательный слой — контроль версий и нормальная командная работа. DevOps живёт вокруг изменений: кто что поменял, где сломалось, как откатить, что именно уехало в релиз. Если Git для вас всё ещё сводится к git add . и git push, вы будете постоянно терять контекст.

Нужно уметь не только коммитить, но и читать diff, разбирать конфликты, работать с ветками, pull request и review. Отдельно полезно понимать, как устроены GitHub, GitLab и Bitbucket как платформы: secrets, actions или pipelines, registry, environments, protected branches, runners. Подробный разбор — в нашем полном путеводителе по Git.

• Минимум: commit, branch, merge, rebase, tags, releases, pull request.
• Командная часть: code review, правила ветвления, шаблоны PR, protected branches.
• Платформа: GitHub Actions, GitLab CI или Bitbucket Pipelines как часть экосистемы вокруг репозитория.
• Результат этапа: вы воспринимаете репозиторий как источник истины не только для кода, но и для процессов доставки.

Шаг 2.5. GitHub, GitLab и Bitbucket как платформы

Отдельная ветка в карте DevOps — это платформы вокруг репозитория. Репозиторий сегодня почти всегда живёт не в вакууме, а внутри сервиса, где рядом находятся pull request, трекинг задач, CI/CD, secrets, environments, registry, релизы и права доступа. Поэтому GitHub, GitLab и Bitbucket полезно воспринимать не просто как место для git push, а как управляющий слой вокруг разработки и доставки.

На старте не так важно, какой именно сервис вы выберете. Гораздо важнее понять общую модель: репозиторий связан с пайплайнами, секретами, защитой веток, код-ревью и артефактами. Если это уложилось в голове, переход между GitHub, GitLab и Bitbucket становится намного проще, потому что вы уже понимаете не кнопки, а саму логику платформы.

• GitHub часто удобен для старта и открытых проектов, GitLab силён как единая платформа, Bitbucket регулярно встречается в корпоративной среде.
• Общие сущности у них одни и те же: PR или MR, protected branches, runners, registry, secrets, environments, release-процесс.
• Полезный навык здесь — не “знать все вкладки”, а понимать, как VCS-платформа связывает код, review, CI/CD и доступы.
• Результат этапа: вы работаете не просто с Git, а с полноценной инженерной платформой вокруг репозитория.

Шаг 3. Контейнеры, Docker и повторяемое окружение

После Git начинается первый по-настоящему практический слой DevOps: повторяемое окружение. Здесь на сцену выходит Docker. Пока приложение нельзя одинаково запустить у разработчика, в CI и на сервере, разговоры про зрелую автоматизацию бессмысленны.

На этом этапе важно не просто уметь стартовать контейнер, а понимать, как он устроен: образ, слой, registry, volume, сеть, переменные окружения, multi-stage build. Полезно хотя бы на уровне ориентира знать, что рядом существуют и более низкоуровневые контейнерные технологии вроде LXC. Отдельный обязательный навык — собрать локальный стенд из нескольких сервисов: приложение, база данных, очередь, reverse proxy.

• Освойте Dockerfile, docker build, docker run и docker compose; как ориентир держите в голове и LXC как соседний класс технологий.
• Поймите разницу между образом, контейнером, volume, сетью и registry.
• Научитесь публиковать образы в registry и тянуть их в CI.
• Результат этапа: один и тот же сервис поднимается локально, в тестовой среде и в pipeline без разъезда зависимостей.

Шаг 4. CI/CD, артефакты и среды поставки

Когда код уже живёт в Git, а приложение работает в контейнере, логично автоматизировать доставку. CI/CD — это не «ещё один сервис ради галочки», а механизм, который собирает, проверяет и продвигает артефакт по средам без ручной рутины. Для старта достаточно понять модель pipeline, а не спорить о брендах.

На этом этапе кроме самого pipeline нужно разобраться ещё с тремя вещами: где лежат артефакты, как устроены окружения и как делается откат. Реальный CI/CD — это не только тесты и сборка, но и публикация образа, миграции, промоушен между dev, staging и production, ручные approvals и rollback.

• Базовый набор: job, stage, runner, cache, artifacts, variables, secrets.
• Инструменты для старта: CI/CD, GitHub Actions, GitLab CI, Jenkins, а как ориентир по рынку — CircleCI, TeamCity и Octopus Deploy.
• Артефакты: registry для образов, package registry для зависимостей, release-версии.
• Результат этапа: после коммита система сама собирает, тестирует и готовит сервис к выкладке.

Если на этом этапе пропустить тему артефактов и сред, дальше начнутся типичные проблемы: в production уехал не тот образ, staging живёт отдельно от CI, а rollback зависит от памяти одного человека. Поэтому этот слой нужно довести до реальной практики, а не до уровня демо-пайплайна из трёх шагов.

Шаг 4.5. Артефакты, registry и package-хранилища

Полный DevOps-путь почти всегда упирается не только в pipeline, но и в место, где живут артефакты. Docker image, release-архив, Helm chart, внутренний пакет библиотеки — всё это должно быть версионируемым, неизменяемым и доступным для доставки в нужную среду. Поэтому управление артефактами в DevOps выделяют в отдельный слой.

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

• Registry и репозитории нужны для образов, пакетов, chart-ов и бинарных артефактов.
• Immutable artefact важнее названия инструмента: пересобирать один и тот же релиз под каждой средой — плохая идея.
• Проверки на этом слое: digest, SBOM, provenance, политика хранения, очистка старых версий.
• Результат этапа: вы всегда знаете, какой именно артефакт уехал в staging и production.

Шаг 5. Облака, сети, IAM и инфраструктура как код

После доставки встаёт вопрос: где всё это живёт и как этим управлять без ручного кликанья в панели облака. Здесь начинается инфраструктура как код. Нужно понимать не только Terraform и Ansible, но и сами строительные блоки: виртуальные машины, сети, балансировщики, объектные хранилища, управляемые базы данных, IAM, DNS, сертификаты и секреты.

Новички часто пытаются сразу выучить три облака, десять сервисов и все инструменты IaC. Это плохая стратегия. На старте достаточно одного облака и одной понятной связки: например, Terraform для описания ресурсов и Ansible для конфигурации машин или прикладной автоматизации поверх них.

Самый полезный первый сценарий здесь очень приземлённый: поднимите в одном облаке сеть, одну виртуальную машину, DNS-запись, сертификат, балансировщик или reverse proxy и выкатите туда свой контейнерный сервис. Если вы можете описать этот путь в Terraform, а потом воспроизвести окружение заново, слой уже перестаёт быть абстракцией.

• Terraform отвечает за ресурсы: VPC, подсети, серверы, балансировщики, DNS, managed-сервисы.
• Ansible помогает настраивать машины, пакеты, конфиги и прикладные роли после их создания.
• Обязательно понять IAM: роли, пользователи, политики, принцип наименьших привилегий.
• Освойте одно облако: AWS, GCP, Azure, DigitalOcean, Hetzner, Alibaba Cloud, Heroku, Contabo или другой провайдер, но не все сразу.
• Смотрите на стоимость с самого начала: тэги, бюджеты, права на выключение idle-ресурсов, размеры инстансов и storage lifecycle.
• Результат этапа: вы можете заново поднять окружение из кода и объяснить, кто к чему имеет доступ.

Terraform — не единственный путь. В больших облаках часто встречаются CloudFormation, AWS CDK и Pulumi: они помогают описывать инфраструктуру либо декларативно, либо через знакомый язык программирования. Полезно знать, что такие ветки существуют, но для старта одной модели достаточно: сначала понять сам принцип provisioning, а уже потом выбирать синтаксис и экосистему.

То же самое касается configuration management. В roadmap рядом с Ansible стоят Chef и Puppet — чаще они живут в старых enterprise-средах. Для новичка важно знать, что это класс инструментов для конфигурации машин и сервисов, но начинать проще с Ansible и одного облака, а не пытаться учить все подходы сразу.

Для этого слоя уже есть хороший мостик в статью как автоматизировать инфраструктуру с помощью Terraform и Ansible. Но поверх него полезно добавить ещё два практических вопроса: как хранить состояние, и как не превратить облако в свалку ресурсов без владельца и тэгов.

Шаг 6. Kubernetes, Helm и оркестрация

Как правило, после контейнеров, pipeline и базовой инфраструктуры имеет смысл переходить к Kubernetes. Иначе оркестрация будет выглядеть как стена терминов: pod, deployment, service, ingress, configmap, secret, autoscaling, statefulset. Kubernetes не заменяет Docker и CI/CD, а строится поверх них.

На этом этапе важно научиться думать не «как запустить контейнер», а «как описать приложение как систему»: сервис, конфигурация, ingress, secrets, health probes, ресурсы, rollout и rollback. Сразу после этого почти неизбежно появляется Helm, потому что вручную копировать YAML по окружениям долго и опасно.

• Kubernetes: pod, deployment, service, ingress, configmap, secret, namespace, HPA.
• Helm: chart, values, templates, releases, upgrade, rollback.
• Не пропускайте управляемые кластеры: EKS, GKE, AKS помогают понять практику без раннего героизма с self-hosted-установками.
• Результат этапа: приложение описано как релиз в кластере, а выкладка перестаёт зависеть от ручного редактирования YAML.

Здесь же стоит впервые по-настоящему заняться секретами. Если секреты лежат рядом с конфигами, например прямо в values.yaml или в переменных на одном сервере без отдельного механизма управления, система остаётся хрупкой. DevOps-маршрут без secret management и нормального доступа к конфигам всегда упирается в безопасность и аудит.

Шаг 6.5. Когда вместо Kubernetes подходят serverless и managed-платформы

В полном DevOps-roadmap рядом с Kubernetes стоят не только managed-кластеры, но и альтернативы: ECS/Fargate, Docker Swarm, AWS Lambda, Azure Functions, Cloudflare Workers, Vercel, Netlify и другие платформы, где часть операционной сложности уже скрыта. Это важная ветка, потому что не каждому проекту нужен полноценный Kubernetes-кластер.

Практическое правило простое. Если у вас небольшой сервис, предсказуемая нагрузка и нет сложной платформенной инфраструктуры, managed-платформа или serverless могут дать более короткий путь в production. Kubernetes нужен там, где важны стандартизация, плотная оркестрация, множественные сервисы, сложные rollout-ы и контроль над платформой. Поэтому DevOps-инженеру полезно понимать и этот выбор, а не сводить всё к одной технологии.

• Managed orchestration: EKS, GKE, AKS, ECS/Fargate, Docker Swarm как разные точки на шкале контроля и сложности.
• Serverless и edge-платформы: AWS Lambda, Azure Functions, Cloudflare Workers, Vercel, Netlify.
• Вопрос выбора: сколько платформы вы хотите администрировать сами, а сколько готовы отдать провайдеру.
• Результат этапа: вы умеете выбирать модель запуска под задачу, а не тянуть Kubernetes туда, где он не нужен.

Шаг 7. Наблюдаемость, алерты и работа с инцидентами

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

Полезно научиться отвечать на четыре вопроса: что сломалось, насколько это критично, где искать причину и как быстро откатиться или стабилизировать систему. Для этого нужен не только дашборд, но и набор сигналов: технические метрики, бизнес-метрики, логи приложений, трассировка запросов, health-check и понятные пороги тревоги.

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

• Метрики и дашборды: Grafana, Prometheus, SLI и SLO.
• Логи: централизованный сбор, поиск по сервисам, correlation id, retention.
• Трассировка: OpenTelemetry и распределённые traces для сложных цепочек запросов.
• Инциденты: алерты, on-call, runbook, postmortem, rollback как нормальная часть процесса.
• Результат этапа: вы не просто релизите сервис, а умеете доказуемо поддерживать его в рабочем состоянии.

Шаг 7.5. Логи, трассировка и стек наблюдаемости целиком

Чтобы покрыть карту DevOps почти полностью, важно смотреть на observability как на стек, а не на один дашборд. В инфраструктурном мониторинге часто встречаются Prometheus, Grafana, Zabbix, Datadog и New Relic. Для логов — Elastic Stack, Graylog, Splunk, Papertrail, Loki. Для трассировки и мониторинга приложений — Jaeger и OpenTelemetry. В живой работе эти слои комбинируются, а не конкурируют лоб в лоб.

На старте не нужно поднимать все эти системы одновременно. Но полезно понимать роль каждого класса инструментов: метрики помогают увидеть деградацию, логи дают контекст ошибки, трассировка показывает путь запроса через цепочку сервисов, а application monitoring помогает увидеть конкретный проблемный код и медленные места. Тогда выбор инструментов становится инженерным, а не маркетинговым.

• Практика надёжности: SLI, SLO, error budget, profiling и явные критерии деградации.
• Инфраструктурный мониторинг: Prometheus, Zabbix, Datadog, New Relic, Grafana.
• Логирование: Elastic Stack, Graylog, Splunk, Papertrail, Loki.
• Трассировка и application monitoring: Jaeger, OpenTelemetry и смежные инструменты APM.
• Результат этапа: вы понимаете, какой класс сигналов отвечает за какой тип проблем.

Шаг 7.6. Инциденты, on-call и postmortem

Полный DevOps-маршрут не заканчивается на мониторинге. Когда система падает ночью или деградирует под нагрузкой, включается incident response: кто дежурит, где лежит runbook, кто принимает решение об откате, как фиксируется таймлайн и как команда разбирает причину после восстановления. Без этого даже хороший мониторинг остаётся просто шумом в Slack.

На старте не нужно строить идеальную SRE-организацию, но полезно привыкнуть к базовой дисциплине: алерт должен вести к понятному действию, у сервиса должен быть владелец, а после серьёзного сбоя команда делает короткий postmortem с выводами и задачами. Это и есть момент, где DevOps начинает становиться зрелой эксплуатацией, а не только автоматизацией деплоя.

• On-call и escalation: кто реагирует первым, кого будить дальше и где лежат контакты.
• Runbook: короткий рабочий документ с проверками, откатом, командами и здравыми fallback-действиями.
• Postmortem: что произошло, как обнаружили, как стабилизировали, что меняем в системе, чтобы не повторилось.
• Результат этапа: аварии превращаются из хаоса в управляемый процесс восстановления.

Эту идею жёстко сформулировала Charity Majors в статье для Honeycomb, опубликованной 15 января 2026 года. Её мысль хорошо ложится на практическую часть DevOps: если у команды нет короткой обратной связи между кодом и production, то инструменты сами по себе мало что дают.

a single feedback loop connecting devs with prod.

Шаг 8. Секреты, безопасность и supply chain

Безопасность не стоит оставлять «на потом», но и пытаться учить весь DevSecOps на старте тоже не нужно. Гораздо полезнее встроить базовые практики в уже знакомую цепочку: секреты не хранятся в репозитории, доступы выдаются по ролям, образы и зависимости сканируются, а pipeline умеет остановить поставку, если в артефакте есть критическая проблема.

Сюда же относится supply chain security: кто собрал образ, откуда приехала зависимость, чем подписан артефакт, где лежит SBOM, можно ли воспроизвести релиз. Для начинающего инженера это не означает десяток экзотических продуктов. Это означает нормальную дисциплину в CI/CD, registry и правах доступа.

Кроме секретов и supply chain, здесь обязательно появляются RBAC, least privilege, ротация доступов, image signing и правила policy enforcement. На практике это означает, что не каждый сервис и не каждый человек получает админские права, а pipeline и платформа умеют останавливать небезопасные деплои ещё до production.

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

Если нужен простой первый выбор, начинайте с нативного secret manager вашего облака или другого управляемого хранилища секретов. Поднимать Vault в учебном проекте полезно позже, когда вы уже понимаете ротацию, доступы и интеграцию с CI/CD. Для старта важнее усвоить сам принцип: секреты живут отдельно от кода и попадают в систему по контролируемому каналу.

• Секреты: KMS, Vault, cloud secret manager, Sealed Secrets — выбрать один понятный путь.
• Доступы и политика: RBAC, least privilege, ротация ключей, policy enforcement и admission checks.
• Доступы: роли вместо общих аккаунтов, least privilege, аудит действий.
• Артефакты: image scanning, dependency scanning, SBOM, подпись релизов там, где это нужно.
• Результат этапа: доставка становится не только автоматической, но и контролируемой с точки зрения риска.
• Supply chain на практике: image signing, provenance, сканирование зависимостей и контроль того, что именно уходит в production.

Шаг 9. GitOps, платформенный подход и зрелые практики

Когда контейнеры, инфраструктура, кластеры и наблюдаемость уже работают устойчиво, можно переходить к следующему уровню зрелости. Здесь появляются GitOps, декларативный деплой через ArgoCD, политики в коде, типовые шаблоны для сервисов и внутренняя платформа, которая упрощает жизнь всей команде, а не только одному DevOps-инженеру. В этой же ветке полезно знать, что кроме ArgoCD существует FluxCD, а рядом с платформенным слоем часто появляются service mesh-инструменты вроде Istio, Linkerd, Consul и Envoy.

Важно понимать, что эти практики не лечат хаос сами по себе. Если у вас ещё не собраны базовые процессы, GitOps превращается в ещё один слой сложности. Но когда фундамент готов, именно здесь начинается настоящее ускорение: Git становится источником истины для доставки, а платформа — продуктом для внутренних команд.

До первой junior-позиции обычно достаточно уверенно закрыть слои от Linux и Git до Docker, CI/CD, базовой инфраструктуры, деплоя и наблюдаемости. GitOps, платформенный подход, service mesh и глубокая стандартизация платформы чаще становятся следующей ступенью уже после реальной работы с несколькими сервисами и командами.

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

Шаг 9.5. Доступность, данные и FinOps-практики

В официальной карте рядом с GitOps и платформенными практиками идут cloud design patterns: availability, data management, design and implementation, management and monitoring. Это означает, что зрелый DevOps не заканчивается деплоем. Нужно думать о резервировании, отказоустойчивости, резервном копировании, восстановлении, хранении состояния, управлении квотами и стоимости платформы.

На практике сюда входят реплики и зоны доступности, стратегия backup и disaster recovery, различие между stateless и stateful-нагрузкой, контроль за ростом storage, бюджетами и неиспользуемыми ресурсами. Именно здесь DevOps начинает пересекаться с SRE, архитектурой и FinOps. Для первой работы не нужно становиться экспертом во всём сразу, но игнорировать эти темы уже нельзя. В зрелой команде FinOps — это не отдельная бухгалтерия, а часть инженерной обратной связи: сколько стоит сервис, где ресурсы простаивают и какой архитектурный выбор реально окупается.

• Availability: health-check, реплики, зоны, failover, rollback, disaster recovery.
• Data management: stateful workload, backup, restore, retention, object storage и managed database.
• Cost management: бюджеты, квоты, тэги, cleanup idle-ресурсов, размер инстансов и storage lifecycle.
• Результат этапа: вы думаете не только о запуске сервиса, но и о его цене, устойчивости и данных.

Шаг 9.6. Карьерные треки: DevOps, SRE, platform engineer, cloud engineer

Когда база уже собрана, полезно понимать, куда дальше растёт роль. DevOps-инженер чаще сильнее сидит на доставке, инфраструктуре и автоматизации; SRE делает больший акцент на надёжности, SLI/SLO и инцидентах; cloud engineer глубже уходит в облачную платформу и сервисы провайдера; platform engineer строит внутренние инструменты, шаблоны и единый путь для команд разработки.

На старте эти роли пересекаются почти полностью, поэтому учить их отдельно рано. Но как карьерная рамка это важно: вы начинаете понимать, почему один инженер копает в Kubernetes и Terraform, другой — в error budget и postmortem, а третий — во внутренний self-service для разработчиков.

• DevOps engineer: автоматизация доставки, инфраструктуры, CI/CD и операционных процессов.
• SRE: надёжность, доступность, SLI/SLO, on-call, incident response и postmortem.
• Cloud engineer: сервисы провайдера, IAM, сеть, storage, управляемые платформы и архитектурные паттерны.
• Platform engineer: внутренняя платформа, шаблоны, self-service и developer experience.

Шаг 9.7. Где в этой карте MLOps

MLOps логично стоит рядом с платформенным и облачным треком, а не вместо базового DevOps-маршрута. Сначала вам всё равно нужны Linux, Git, контейнеры, CI/CD, инфраструктура как код, наблюдаемость и безопасность. Только поверх этого появляется специфический слой машинного обучения: данные, обучение моделей, реестр моделей, feature store, воспроизводимые пайплайны и выкладка инференса.

Если говорить совсем просто, MLOps — это DevOps для систем, где кроме кода живут ещё модели и данные. Поэтому в этом треке к обычному деплою добавляются новые вопросы: как версионировать датасеты, как переобучать модель без хаоса, как проверять качество до и после релиза, как ловить drift и как откатывать не только код, но и модель.

• База та же самая: Docker, CI/CD, облака, Kubernetes, observability, secrets и права доступа.
• Специфика MLOps: versioning данных и моделей, training pipeline, model registry, feature store, offline и online evaluation.
• Инференс в production добавляет свои задачи: latency, стоимость GPU или CPU, batch и realtime-режимы, drift monitoring, rollback модели.
• Для старта это не обязательный слой каждому DevOps-инженеру, но если вы идёте в ML-команды, его стоит рассматривать как отдельную специализацию поверх крепкого DevOps-фундамента.

Что можно оставить на потом

Одна из главных ловушек DevOps — ощущение, что нужно знать вообще всё. Это не так. Есть темы, которые стоит трогать позже, когда уже есть реальная потребность: service mesh, то есть дополнительный сетевой слой между сервисами, multi-cloud, сложные self-hosted-кластеры, bare metal, внутренние PaaS, serverless на нескольких провайдерах и тонкая оптимизация FinOps.

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

• Service mesh нужен не каждому проекту и редко бывает стартовой темой.
• Multi-cloud — история про зрелую организацию, а не про первый учебный проект.
• Serverless полезно знать, но не как замену фундаменту из сетей, CI/CD и наблюдаемости.
• FinOps и оптимизация затрат раскрываются сильнее, когда у вас уже есть реальные счета и метрики нагрузки.

Практический план обучения на 6–9 месяцев

Самая рабочая стратегия — не читать про DevOps абстрактно, а вести один сервис через весь путь. Возьмите небольшое приложение, например API или веб-сервис, и усложняйте его инфраструктуру по мере роста навыков. Тогда каждый новый слой будет опираться на уже работающую систему, а не на набор разрозненных упражнений.

Какие учебные проекты реально помогают войти в DevOps

Чтобы проект действительно работал на портфолио, у него должен быть измеримый результат. Не просто «я попробовал Kubernetes», а «вот репозиторий, вот pipeline, вот инфраструктура, вот скриншот дашборда, вот инструкция по деплою и откату». Ниже — сценарии, которые дают такой результат.

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

1. Поднять веб-приложение с базой данных через Docker Compose и опубликовать образ в registry.
2. Сделать CI-пайплайн, который тестирует проект, собирает образ и выкладывает его в staging.
3. Описать тестовую инфраструктуру через Terraform и накатить конфиг через Ansible.
4. Развернуть сервис в Kubernetes, вынести параметры в Helm и выполнить обновление с откатом.
5. Подключить Grafana и Prometheus, собрать дашборд по ошибкам и задержкам, добавить алерт на деградацию.
6. Убрать секреты из репозитория и перевести их в managed secret store или Kubernetes secrets с контролируемым доступом.

Как стать DevOps-инженером и что нужно уметь junior

Чтобы претендовать на первую DevOps-роль, не нужно знать весь рынок инструментов. Но нужно показать связный практический путь: вы умеете работать с Linux и Git, упаковывать сервис в Docker, собирать pipeline, поднимать тестовую инфраструктуру, читать метрики и не теряться при сбое. Работодатель обычно ищет не энциклопедические знания, а способность провести сервис от коммита до рабочего окружения.

Хороший junior-ready уровень выглядит так: у вас есть один или два проекта, которые можно открыть и показать. В них видно инфраструктуру, Dockerfile, pipeline, деплой, базовый мониторинг и понятные README с тем, как это запускается и как откатывается. Это намного сильнее, чем длинный список прочитанных курсов.

• Вы умеете поднять сервис локально, упаковать его в контейнер и опубликовать образ в registry.
• Вы можете настроить CI, который тестирует, собирает и публикует артефакт без ручной сборки.
• Вы понимаете базовые облачные сущности: сеть, VM, DNS, IAM, secret store, балансировщик.
• Вы можете развернуть сервис на сервере или в Kubernetes и объяснить, как его мониторить и откатывать.
• У вас есть портфолио из реального pet-проекта, а не только конспектов и скриншотов из лабораторных.

Дальше траектория обычно расходится на несколько направлений: DevOps-инженер с уклоном в доставку и инфраструктуру, SRE с акцентом на надёжность и инциденты, cloud engineer с фокусом на облачную платформу и platform engineer, который строит внутренние инструменты и шаблоны для разработчиков. На старте эти роли сильно пересекаются, поэтому базовый маршрут у них общий.

Как понять, что этап закрыт и можно идти дальше

Переход между этапами лучше проверять не ощущением «кажется, я уже почитал достаточно», а конкретными результатами. Если у вас нет практического артефакта на выходе, тема обычно ещё не закрыта. Для DevOps это особенно важно: знания быстро расслаиваются, если за ними не стоит работающий сервис, pipeline или окружение.

1. Linux и сети закрыты, когда вы можете зайти на машину по SSH, найти проблему в логах, проверить порты, DNS и сервисы без GUI-подсказок.
2. Git закрыт, когда вы спокойно работаете с ветками, pull request, конфликтами и понимаете, что именно уезжает в релиз.
3. Docker закрыт, когда ваш сервис стабильно собирается в образ, стартует вместе с зависимостями и одинаково работает локально и в CI.
4. CI/CD закрыт, когда после коммита автоматически проходят тесты, собирается артефакт, появляется версия и у вас есть понятный rollback.
5. Terraform и облако закрыты, когда вы поднимаете тестовое окружение из кода и можете заново воспроизвести его без ручного кликанья.
6. Kubernetes и Helm закрыты, когда вы выкатываете приложение в кластер, меняете конфигурацию по окружениям и обновляете релиз без редактирования YAML вручную на проде.

Как не запутаться в инструментах и не выгореть

DevOps широкий, а не линейный. Поэтому полезно думать не категориями «мне срочно нужен ещё один инструмент», а категориями «какую конкретную проблему я сейчас решаю». Если вы не умеете повторяемо запускать приложение, вам рано в service mesh и другие продвинутые сетевые надстройки. Если вы не понимаете IAM, не стоит спорить о multi-cloud-архитектуре. Если после релиза вы не видите метрик, не нужно начинать с GitOps.

Нормальный темп обучения — один слой за раз, с обязательной практикой и возвращением к предыдущим этапам. В реальной работе вы всё равно будете постоянно ходить назад: править Dockerfile после проблем в CI, улучшать Terraform после ошибок в доступах, менять алерты после неудачного инцидента. Это не откат, а нормальная сборка компетенции.

• Выберите один главный учебный сервис и не распыляйтесь на пять разных pet-проектов.
• Один инструмент на категорию лучше, чем поверхностное знакомство с тремя конкурирующими решениями.
• После каждого этапа задавайте себе вопрос: что я теперь умею делать руками, чего не умел неделю назад?
• Если новая тема не решает текущую боль, отложите её до момента, когда под неё появится практический контекст.

Выводы

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

Если хотите идти по этому маршруту через уже готовые материалы Tproger, используйте связку так: Git и GitHub → Docker → CI/CD → Kubernetes → Helm → GitOps → ArgoCD. Для инфраструктуры и наблюдаемости возвращайтесь к материалам про Terraform и Ansible и Grafana.

Когда дойдёте до конкретного инструмента, сверяйтесь уже с его официальной документацией: Docker, Kubernetes, Terraform, Argo CD. Так вы получите и общую картину, и правильные практические детали.

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

• Helm — это пакетный менеджер для Kubernetes, примерно как npm для JavaScript-проектов или apt для Linux-пакетов.
• Главная единица в Helm — chart: шаблон приложения, в котором лежат Kubernetes-манифесты, values и зависимости.
• Helm особенно полезен, когда нужно ставить одно и то же приложение в dev, staging и production с разными параметрами.
• Базовый цикл работы выглядит так: добавить репозиторий, выбрать chart, установить release, затем при необходимости обновить или откатить его.

После Docker и Kubernetes вопрос обычно уже не в том, как запустить контейнер, а как не запутаться в конфигурации приложения целиком. Вот здесь и появляется Helm.

Что такое Helm и зачем он нужен

Helm — это утилита для установки и обновления приложений в Kubernetes. В официальной документации его прямо называют пакетным менеджером для Kubernetes. На практике это значит, что вы работаете не с россыпью YAML-файлов, а с одним chart-ом, в котором уже описаны нужные ресурсы и точки для подстановки значений.

Обычно Helm появляется в тот момент, когда в кластере у вас уже не один учебный Pod, а нормальное приложение: backend, PostgreSQL, ingress-nginx, Redis и ещё несколько настроек поверх. Держать такой набор манифестов вручную быстро становится тяжело, особенно если окружений несколько.

• убирает дублирование YAML между окружениями;
• позволяет параметризовать конфигурацию через values.yaml;
• устанавливает сложные приложения одной командой;
• хранит историю релизов и умеет откатывать неудачные обновления.

Если совсем коротко: Kubernetes запускает контейнеры, а Helm помогает ставить приложение в кластер как один цельный пакет.

Из чего состоит Helm: chart, release, repo и values.yaml

Чтобы дальше не путаться, достаточно держать в голове четыре термина.

Что такое Helm Chart

Chart — это пакет приложения. В нём обычно лежат шаблоны Kubernetes-манифестов, файл Chart.yaml с метаданными, файл values.yaml со значениями по умолчанию и при необходимости зависимости от других chart-ов.

Что такое Helm Release

Release — это конкретная установленная копия chart-а в кластере. Один и тот же chart можно установить несколько раз с разными именами и настройками: например, myapp-dev и myapp-prod.

Что такое Chart Repository

Chart repository — это место, откуда вы забираете готовые chart-ы. Это может быть обычный HTTP-репозиторий с индексом пакетов или OCI-реестр. Для примеров в статье достаточно Bitnami.

Что такое values.yaml в Helm

values.yaml — файл со значениями для шаблонов. За счёт него один и тот же chart можно использовать в разных окружениях: рядом с базовым values.yaml появляются values-dev.yaml и values-prod.yaml, где меняются реплики, теги образов и домены.

Но сами values ещё не показывают, куда именно они подставятся. Ниже — минимальный фрагмент шаблона Deployment, который берёт значения из .Values.

А для разных окружений значения обычно раскладывают по отдельным файлам:

Проще всего думать так: chart — это шаблон приложения, values — параметры для него, release — установленный экземпляр, repo — место, откуда этот шаблон взяли.

Как Helm работает на практике

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

После установки Helm создаёт release и раскладывает в кластер всё, что описано в chart-е. Если позже вы меняете, например, тег образа или число реплик в values-prod.yaml, релиз обновляется без ручной правки манифестов.

На практике вокруг helm upgrade и крутится большая часть работы: поменяли образ, значения или сам chart — обновили релиз. Если после этого что-то сломалось, helm rollback позволяет быстро вернуться к предыдущей версии.

Где здесь шаблоны

Внутри chart-а YAML почти всегда параметризован: количество реплик, тег образа, имена сервисов, домены. Поэтому один и тот же chart спокойно живёт и в dev, и в production.

Почему Helm — это не просто набор YAML-файлов

Голые манифесты в Git тоже работают. Проблемы начинаются позже: куски YAML дублируются, настройки между окружениями расползаются, а история конкретного релиза живёт у вас в голове. Helm хотя бы наводит в этом порядок.

Когда Helm удобнее kubectl apply, а когда нет

Helm не заменяет kubectl. kubectl работает с отдельными ресурсами, а Helm — с приложением как с пакетом.

• kubectl apply хорош, когда ресурсов мало и они почти не меняются.
• Helm удобнее, когда приложение состоит из многих манифестов и должно ставиться повторяемо.
• Kustomize часто выбирают, когда важнее патчи поверх базовых YAML, чем пакетная модель chart-ов.
• ArgoCD и другие GitOps-инструменты нередко используют Helm как источник шаблонов, а сами отвечают уже за непрерывную доставку.

Helm и ArgoCD обычно работают в связке. Helm отвечает за шаблоны и values, а ArgoCD следит, чтобы кластер действительно пришёл к состоянию из Git.

Если проводить грубую аналогию, то Docker пакует приложение, Kubernetes его запускает, а Helm приводит в порядок конфигурацию всего этого хозяйства.

Как начать работать с Helm: минимальный сценарий

Когда готовых chart-ов уже мало, следующий шаг — собрать свой. Команда helm create создаёт стартовый каркас: шаблоны, файл values.yaml и служебные метаданные.

Дальше всё довольно прозрачно: шаблоны лежат в templates/, значения — в values.yaml, а перед установкой вы можете заранее посмотреть, какой YAML Helm реально сгенерирует.

Это особенно удобно, когда нужно сравнить dev и production до деплоя: сначала смотрите итоговый YAML локально, потом уже делаете install или upgrade.

Частые ошибки новичков в Helm

• Считать Helm заменой Kubernetes. На самом деле Helm только управляет шаблонами и релизами поверх Kubernetes API.
• Смешивать секреты, production values и тестовые настройки в одном файле. Лучше разделять values по окружениям.
• Запускать upgrade без понимания, что изменилось. Перед релизом полезно рендерить шаблоны через helm template.
• Игнорировать rollback-стратегию. История релизов — одна из самых практичных возможностей Helm, ей стоит пользоваться.
• Ставить Helm туда, где достаточно пары статичных манифестов. Если приложение маленькое, лишняя абстракция может только мешать.

На pet-проекте с двумя манифестами Helm и правда может быть лишним. Но как только появляются несколько сервисов, отдельные values для окружений и регулярные релизы, без него быстро становится тесно.

Выводы

Helm полезен не как модный инструмент из DevOps-стека, а как способ перестать руками таскать за собой растущий набор Kubernetes-манифестов.

Самый полезный следующий шаг после этой статьи — не читать ещё один ликбез, а собрать маленький учебный chart руками. Сгенерируйте его через helm create, вынесите настройки в values-dev.yaml и values-prod.yaml, прогоните helm template и сделайте первый install в Minikube или kind. После этого связка с CI/CD, Kubernetes и ArgoCD уже будет восприниматься намного проще.

Для старта хватит официальной инструкции по установке Helm, базового руководства и тестового кластера в Minikube или kind. Один вечер с install, template, upgrade и rollback обычно объясняет Helm лучше любого ликбеза.

Если хотите понять, где Helm находится в общей DevOps-цепочке, посмотрите план обучения DevOps-инженера. Там Helm связан с Docker, CI/CD, Kubernetes, наблюдаемостью и следующими шагами вроде GitOps и ArgoCD.

JAI требует Linux с ядром 6.13 и выше. На macOS и Windows утилита не работает — она использует Linux namespaces и overlayfs, которых нет в других ОС. Если вы работаете в WSL на Windows, JAI подходит.

— JAI — бесплатная утилита от Stanford Secure Computer Systems group для изоляции ИИ-агентов на Linux

— Одна команда: jai claude, jai codex или просто jai для шелла

— Рабочая директория сохраняет полный read/write доступ, home-директория защищена copy-on-write overlay

— Три режима изоляции: Casual, Strict и Bare — от лёгкого до максимального

— Не замена Docker/VM — это лёгкая песочница, которая уменьшает blast radius (радиус поражения от ошибок агента) без лишней настройки

— Исходный код: github.com/stanford-scs/jai

Проблема — ИИ-агенты с доступом к файловой системе

Современные ИИ-агенты работают напрямую с файловой системой — читают, создают и удаляют файлы. Это удобно, но опасно. Вот реальные случаи, которые приводят разработчики JAI:

• 15 лет семейных фотографий — удалены через терминал, даже не попали в корзину
• Claude Code вытер home-директорию — полная потеря активных проектов разработки
• Cursor очистил рабочее дерево — «всё просто исчезло»
• 100 ГБ удалено — агент «решил» убрать файлы с компьютера
• Antigravity стёр весь диск D — случайная полная очистка раздела

Между двумя крайностями — «дать агенту полный доступ к системе» и «поднять контейнер или виртуальную машину» — зияла пустота. Настроить Docker ради одной сессии с Claude Code — перебор. Работать без защиты — лотерея. JAI заполняет эту нишу: одна команда, и агент работает в песочнице.

Как установить JAI

JAI собирается из исходного кода. Для сборки потребуется современный C++-компилятор (GCC 15+ или Clang 22+) и ядро Linux 6.13 или новее.

Установка зависимостей (Ubuntu):

Сборка и установка из репозитория на GitHub:

После установки инициализируйте конфигурацию:

Как работает JAI

JAI — это лёгкая песочница для Linux, которая не требует настройки. Достаточно добавить jai перед командой:

Принцип работы прост:

• Рабочая директория (CWD) — полный read/write доступ. Агент работает с проектом как обычно. Важно: CWD не защищена — rm -rf в рабочей директории уничтожит файлы безвозвратно
• Home-директория — copy-on-write overlay. Агент видит ваши файлы, может «изменять» их, но оригиналы остаются нетронутыми. По умолчанию .ssh, .gnupg, .aws, .bash_history и другие чувствительные файлы маскируются — агент их не видит
• /tmp и /var/tmp — приватные, изолированные от системы
• Всё остальное — read-only. Агент может читать системные файлы, но не может ничего сломать

Никаких образов, Dockerfile, длинных команд bwrap с десятками флагов. Если запуск песочницы сложнее, чем работа без неё, — никто не станет ею пользоваться. JAI делает защиту проще, чем её отсутствие.

Три режима изоляции

JAI предлагает три режима — от мягкого до строгого:

• Casual (по умолчанию) — home-директория под copy-on-write overlay, процесс запускается от вашего пользователя. Конфиденциальность слабая: большинство файлов читаемы, но оригиналы под защитой. Поддерживает NFS home (upperdir на локальном диске)
• Strict — пустой приватный home, процесс запускается от непривилегированного jai user. Максимальная конфиденциальность и целостность: отдельный UID, полная изоляция. NFS home не поддерживается
• Bare — пустой приватный home, но процесс запускается от вашего пользователя. Конфиденциальность слабая за пределами home (тот же UID), но полная изоляция home. Поддерживает NFS home (upperdir на локальном диске)

Casual — режим по умолчанию. Подходит для повседневной работы с ИИ-агентами: ваши конфиги и настройки доступны, но оригиналы под защитой. Strict — максимальная изоляция с отдельным пользователем и пустым home. Bare — компромисс: пустой home, но процесс запускается от вашего имени. Поддержка NFS в Casual и Bare работает только при условии, что директория хранения overlay (--storage) находится на локальном диске — NFS не поддерживает расширенные атрибуты, необходимые для overlayfs.

JAI vs Docker vs bubblewrap vs chroot

JAI не пытается заменить контейнеры — он занимает другую нишу:

• Docker — отлично подходит для воспроизводимых сред на основе образов. Избыточен для одноразовой изоляции хостовых инструментов. Не поддерживает overlay-на-home сценарий
• bubblewrap (bwrap) — мощная namespace-песочница. Но требует ручной сборки файловой системы, что превращается в длинный wrapper-скрипт. JAI убирает именно эту сложность
• chroot — не является механизмом безопасности. Нет изоляции mount, PID namespace и разделения привилегий. Документация Linux прямо говорит: не предназначен для песочниц

Главное преимущество JAI — порог входа. Где Docker требует Dockerfile и образ, а bubblewrap — 40 флагов, JAI требует одну команду. Для типичного сценария «запустить ИИ-агента на пару часов» — это именно то, что нужно.

Ограничения — это не полная защита

Авторы из Стэнфорда честно предупреждают: JAI — это casual sandbox, а не бронированный контейнер. Вот что важно понимать:

• Casual mode не защищает конфиденциальность — агент может читать большинство файлов в системе, просто не может их изменить
• Даже strict mode не эквивалентен закалённому контейнерному рантайму или виртуальной машине
• Не подходит для multi-tenant изоляции — если нужна защита от целенаправленного злоумышленника, используйте Docker или VM
• Сетевой доступ не ограничен — агент по-прежнему может отправлять запросы в интернет
• CWD не защищена — рабочая директория доступна на запись. Если агент выполнит rm -rf в текущей директории, файлы будут уничтожены безвозвратно — это реальная файловая система, а не overlay

JAI уменьшает blast radius — радиус поражения от ошибок агента. Он не делает агентов безопасными, но делает последствия их ошибок менее катастрофическими.

Как начать использовать JAI

Если вы используете Claude Code, Cursor или Codex на Linux — JAI решает главную проблему: агент может работать с вашим проектом, но не может случайно удалить домашнюю директорию или SSH-ключи.

Базовое использование — добавьте jai перед командой:

Проверить, что overlay работает:

Очистить overlay после работы (сбросить все накопленные изменения агента):

Выводы

JAI решает конкретную и актуальную проблему: ИИ-агенты получают доступ к файловой системе, и рано или поздно они что-нибудь ломают. Поднимать контейнер ради каждой сессии — неудобно. Работать без защиты — рискованно. JAI занимает нишу между этими крайностями: одна команда, нулевая настройка, реальная защита от самых распространённых катастроф.

Утилита бесплатна, open-source, разработана исследовательской группой Stanford Secure Computer Systems и Future of Digital Currency Initiative. Исходный код доступен на GitHub, документация — на официальном сайте. Проект набрал активное обсуждение на Hacker News.

Если вы запускаете ИИ-агентов на Linux — попробуйте jai. Это проще, чем восстанавливать 15 лет семейных фотографий.