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

«А если сотрудник из региональной поддержки спросит этого бота про зарплаты топ-менеджмента — что произойдёт?»

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

Это не история про плохую команду. Это стандартный разрыв между PoC и продакшеном для любого LLM-продукта. В демо система отвечает на вопросы. В проде она должна отвечать на вопросы правильным людям, из правильных источников, с понятной стоимостью и с кем-то, кто отвечает за инцидент, если модель выдаст что-то не то. Именно на этом стыке большинство пилотов останавливается — не потому что модель слабая, а потому что вокруг неё не спроектирована инженерная система.

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

Контур 1. Доступы: чат-бот — это еще один источник утечки данных

Первое, что ломается при масштабировании, — это предположение «у нас один индекс, и все спрашивают одно и то же». В реальной компании HR, финансы, разработка и юридический отдел имеют разные права на одни и те же документы, и ассистент обязан это учитывать так же строго, как обычная система с ACL.

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

Рабочие паттерны здесь давно известны из мира дата-инжиниринга, просто их надо перенести в LLM-контур:

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

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

Контур 2. Качество: как понять, что модель не «в целом хорошо отвечает», а действительно работает

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

Отсюда вырастает необходимость в “evals” — наборе тестовых вопросов с эталонными или хотя бы допустимыми ответами, который прогоняется при каждом изменении промпта, смене модели или обновлении базы знаний. Без этого набора любое «мы обновили промпт» — это эксперимент вслепую поверх продакшена.

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

• обязательное отображение источников в ответе — пользователь должен иметь возможность провалиться в документ и проверить;
• метрика заземления (grounding) — насколько ответ действительно опирается на найденный контекст, а не на веса модели;
• регулярная выборочная проверка ответов людьми, желательно из той же предметной области, что и пользователи.

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

Контур 3. Эксплуатация: то, что не видно на демо-стенде

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

Технически это означает необходимость закладывать:

• fallback-модели — если основной провайдер отвечает с задержкой или недоступен, запрос должен уйти на резервную модель, пусть и менее мощную, а не зависнуть;
• очереди и скорости запросов на уровне пользователя и команды, чтобы один активный отдел не съел весь бюджет задержек у остальных;
• мониторинг не только «жив ли сервис», но и задержка по перцентилям, долю ошибок генерации, долю отказов поиска;
• отдельное наблюдение за GPU-утилизацией, если часть моделей развернута локально, а не через внешний API.

Это тот слой, где выигрыш от готовой платформы обычно максимален: наблюдаемость, лимиты, инфраструктура и SLA закрываются AIaaS‑решением, таким как платформа ITGLOBAL.COM , куда быстрее, чем командой, которая строит это с нуля. Но метрики продукта — что считать приемлемой задержкой именно для этого сценария использования, какие тестовые кейсы прогонять при инцидентах — всё равно остаются на стороне команды, потому что это вопрос не инфраструктуры, а бизнес-требований.

Контур 4. Стоимость: токены как новая облачная статья расходов

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

Что реально работает на практике:

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

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

Контур 5. Ответственность: кто отвечает, если агент сделал что-то не то

Отдельный контур, который на демо вообще не обсуждается, — это ответственность за действие. Пока LLM просто отвечает на вопросы, риск ограничен качеством текста. Но как только появляется агент, который может, например, создать тикет, отправить письмо или изменить запись в CRM, вопрос смещается с «что ответила модель» на «что модель сделала».

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

Что делать самим, а что можно отдать платформе

Важная оговорка: этот список работает только применительно к реальному составу конкретного AIaaS-решения. Если в нём нет встроенного RBAC, нет мониторинга или нет managed RAG — не стоит проектировать архитектуру так, будто эти возможности уже есть. Разрыв между ожидаемым и фактическим набором функций платформы — ещё один способ провалить продакшен так же надёжно, как отсутствие проектирования вообще.

Вместо вывода

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

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

Реклама. ООО «Итглобалком Рус» ИНН 7838413489, erid: 2W5zFJ34gQR

Изначально был только сервер

В котором мы жили по уже сложившимся канонам внутри известного и подконтрольного периметра и исповедовали Zero Trust — подход к безопасности, при котором никто никому не доверяет по умолчанию. И однажды у нас появилась задача «въехать» в облако. Но не в ещё один собственный ЦОД, а во внешнее облако.

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

Почему?

Потому что традиционные средства и подходы не работают. Само по себе облако имеет специфику безопасности, а риски отличаются от традиционной инфраструктуры. Возможно, по этой причине за 2024 год больше 60% компаний столкнулись с инцидентами безопасности, связанными с облаком, а в 2025 — уже 65%?

Если, как упоминал ранее, мы жили за неким сетевым периметром, где можно было отгородиться блокирующими или разрешающими правилами или «белыми списками», то облако — это API-first инфраструктура, где используемые сервисы (особенно managed services) не стоят за какими-то фаерволами, а имеют в первую очередь публичные API, доступ к которым регулируется иными правилами: RBAC, политики, ACL.

Возникает новая модель ответственности, где часть задач берет на себя платформа и её сотрудники. Это так называемый Cloud Trust — модель безопасности, которая предполагает разделение обязанностей между провайдером и клиентом.

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

№1. Сетевой доступ

Мы сделали практически полный маппинг ресурсной организации on-premises с ресурсной организацией Yandex Cloud (ЯО далее).

Как и говорил ранее, у нас появляется новый периметр — IAM. Но и старый никуда не исчезает. Сетевая изоляция и микросегментация остаются чуть ли не самыми важными вопросами ИБ до сих пор. Потому первый же вопрос, который мы задали себе при выезде, был таков: «А как нам с ним общаться?» То есть как строить интеграции, как пускать управляющий трафик и трафик этих интеграций и так далее.

Ответом на вопрос стал интерконнект. Это оптика с тёмным волокном между Банком и Платформой, поверх которой накладывается ГОСТ-шифрование. В интерконнект мы заворачиваем весь свой трафик, ходим из сети Банка в консоль, строим внутри интеграции и т.д.

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

В банке у каждой условной системы есть свой набор сред (упрощенно: dev, test, prod). Каждая из них имеет собственный набор подсетей, строго изолированных друг от друга. В рамках одной среды подсети этой системы также изолированы фаерволами.

Такую же структуру мы организовали в облаке: система — это облако, а фолдеры – среды, каждая из которых имеет свои сети/подсети и набор правил фаерволинга, реализованных через Security Groups (как механизм сетевой изоляции).

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

Команда, как и раньше, согласовывает проект, заказывает подсети и сетевые доступа, как в on-prem, но в облаке. И даже если система поделена между on-prem и облаком, то её связность никак не нарушается. Все проекты, выезжающие в облако, получают пул IP-адресов с банковской сетью. Эти сети анонсируются в интерконнект и выглядят так, будто просто находятся в другом ЦОДе, и в нашей системе учета сетей пул заводится как обычная подсеть.

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

Единственное, что внешний трафик («интернет-интернет») в облако и из облака пока не пускаем — только через внутреннюю инфраструктуру. Но когда-нибудь сможем.

№2. Пользовательский доступ

Осознавая критичность пользовательских доступов в новой парадигме, мы решили, что и процесс управления последними также должен быть универсальным и повторять свою реализацию в новом окружении. Внутри все пользовательские доступы, доступы систем, технических учетных записей, управляются централизованно через Active Directory (AD) и KeyCloak, которые также поделены по средам. Облако позволяет их интегрировать со своим IAM и построить на их базе федерации для каждой из сред со своими наборами политик.

Фактически процесс аутентификации происходит в банке и транслируется в ЯО — то есть мы продолжаем использовать именно банковские корпоративные УЗ через банковскую же инфраструктуру для доступа к ресурсам и консоли облака.

А что с авторизацией и правами?

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

Мы начали переход в облако давно, и на первых этапах роли были примитивнее, чем сервисные. Со временем у ЯО появилась отличная грануляция сервисных прав, которая очень удобно позволяет собирать роли, соблюдая принципы наименьших привилегий. И также позволяет сопоставлять упомянутые ранее группы A D и группы пользователей IAM в ЯО. Фактически мы и здесь реализовали текущий процесс управления доступом в новом облачном окружении, сохранив командам привычный флоу работы и скорость без потери контроля.

Получился отличный баланс – аутентификация как в on-prem, но логичное делегирование авторизации в облако.

№3. Контроль конфигурации

Ну а что насчет самого разворачивания в облаке? Как вообще выезжать и контролировать то, что едет?

Чуть ранее я говорил, что мы используем ту же модель объектов в облаке, что и в банке, т.е. условно созданный Compute Cloud в облаке фиксируется в нашей системе инвентаризации как обычная WM. То же самое с сетями, то же и с другими сервисами.

Но что изменилось?

Например, мы стали вести реестр и критерии применимости Managed Services – каждый из них имеет свои возможности и нюансы, и мы начали с того, что провели анализ и составляем некую карту применимости того или иного managed services в том или ином проекте, с помощью которой можем решить, что один сервис разрешен одной команде, а другой запрещен.

Каждый проект должен создать свою проектную документацию – фактически отрисовать архитектуру с применяемыми в том числе облачными ресурсами. По итогу он получит согласование (сам процесс согласования сейчас не важен). И далее команда идет не в ЯО, а в нашу внутреннюю платформу, интегрируемую с облаком и через неё заказывает все необходимые ресурсы —> всё будет поднято для них в облаке. А мы на своей стороне сможем проверить ту же конфигурацию этих ресурсов.

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

Далее на развернутую инфраструктуру надо деплоить приклад — мы выбираем платформу CI/CD. Но здесь всё просто – у нас есть требования к платформам CI/CD и фактически такую систему можно сделать полностью облачной, что мы пробовали. Но использовать внутреннюю, уже построенную и готовую, куда удобнее: все сканеры настроены, все гейты построены.

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

А так как в облаке у нас довольно внушительная инфраструктура, много новых тяжелых подпроцессов, новых требований и моделей угроз, а команда маленькая, то без автоматизации никак. Потому с самого начала мы перекладывали все требования в код. Сейчас наши требования выглядят как набор проверок в коде — фактически это сканер облаков, являющийся клиентом над API облака, со всеми необходимыми нам функциями. Так, фактически, у нас появился собственный CSP (Cloud Security Posture Management — управление состоянием безопасности облака).

Этот подход позволяет писать любые требуемые нам проверки. Но порой нам может не хватать экспертизы в каких-то вопросах, и без экспертизы ЯО не обойтись, поэтому мы также можем использовать сервис Yandex Security Deck с его модулями.

На данном этапе мы всё ещё сохраняем преимущественно Zero Trust подход, но частично отдаём ответственность ЯО.

№4. SOC

Мы всё развернули, задеплоили, прошли проверки ИБ. А значит пора мониторить, детектить и реагировать. В on-prem мы знаем всё: у нас свои правила и полный контроль логов — на это отдельно выделена функция SOC.

Но в облаках у нас нет полного контроля над логами, так как:

• мы можем использовать только те сервисы сбора логов, что нам предоставляет площадка: Control Plane и Data Plane (= Audit Trail/Cloud Logging), а также логи действия самого провайдера;
• в ЯО постоянно появляются сервисы (которые, конечно же, сразу нужны командам), а фичи (в плане логирования) за ними не поспевают.

Но одно дело получить, другое — обработать (нужен детект). На это нужно нанимать команду, чтобы собирать, обрабатывать, а это дорого (да и свою экспертизу надо наращивать).

Поэтому мы всё ещё пользуемся сервисом YCDR от платформы, который позволяет нам закрывать эту функцию в облаке.

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

Итого

На данный момент в облаке у нас довольно большая инфраструктура: разные среды, разные системы, 1500 виртуальных машин, 100 managed services, 1000 пользователей — сотрудники и члены команд и сервисных аккаунтов.

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

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

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

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

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

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

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

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

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

Две фазы инференса, которые дорожают по-разному

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

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

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

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

KV-кеш: где на самом деле кончается память

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

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

Для модели с 32 слоями, 8 KV-головами, размерностью головы 128 и половинной точностью получается примерно 128 КБ на один токен. У других моделей цифра будет своя, но зависимость одна: чем длиннее контекст, тем больше памяти занято. Именно поэтому длинные промпты, долгие диалоги и подтянутые из поиска документы делают инференс заметно дороже, а свободный объём этого кеша прямо определяет, сколько запросов сервер потянет одновременно.

Почему агентская нагрузка тяжелее обычной

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

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

Четыре механизма, которые возвращают пропускную способность

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

Страничное внимание, оно же PagedAttention

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

Непрерывное пакетирование

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

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

Кеширование общего префикса

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

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

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

Совместимый интерфейс

Четвёртый пункт скучный, но на практике решающий: сервер выставляет интерфейс, совместимый с OpenAI. Существующие приложения и агентские фреймворки переключаются на него правкой конфигурации, а не переписыванием кода.

Когда всё это действительно нужно

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

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

Вторая половина задачи: считать деньги до запуска

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

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

Реестр токенов вместо пробного запуска

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

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

Проверим на задаче из 6000 сводок, где промпт занимает около 21 000 символов, а ответ ограничен 500. Выходит 5250 токенов на промпт плюс 125 на ответ, то есть 5375 на вызов, а на всю задачу 32 250 000 токенов при лимите в 30 000 000. Задача не помещается с запасом минус 7,5%, и узнать это удалось, не потратив ни одного токена.

Соседняя задача с промптом в 4000 символов, тем же ограничением ответа в 500 символов и 10 000 вызовов даёт 1125 токенов на вызов и 11 250 000 на всё, помещаясь с запасом в 62,5%. Живая пробная отправка ни того, ни другого не покажет: она расскажет о поведении конкретной ручки прямо сейчас, но не о сумме по всей пачке, и вдобавок сама потратит токены.

Почему расход токенов нельзя делать метрикой продуктивности

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

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

Само по себе потребление токенов отвечает на вопрос, пользуется ли человек инструментом вообще. На раннем этапе внедрения этот сигнал полезен. Но он ничего не говорит о том, получилось ли в итоге что-то осмысленное, а «много ИИ» и «хорошо с ИИ» — разные вещи.

Стоимость на результат

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

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

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

Слишком жёсткая квота выталкивает работу за периметр

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

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

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

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

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

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

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

До 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

Для тех, кто держит NGINX перед API, это меняет привычную схему. Раньше, чтобы направить запрос к /graphql или /mcp на разные бэкенды в зависимости от того, что лежит внутри JSON, приходилось подключать njs или Lua. Теперь то же самое делается директивами конфигурации на C без скриптового рантайма. Тем, кто уже использует njs с js_access, обновление стоит поставить в первую очередь: до 1.0.1 ошибка внутри асинхронной проверки приводила к тому, что NGINX продолжал обрабатывать запрос, как будто проверка пройдена.

• NGINX 1.31.5 от 2 сентября 2026 года: location по переменной (predicate locations), директива client_body_early_read, модуль ngx_http_json_module, Control API из NGINX Plus R37.0.
• Control API не имеет аутентификации: проект рекомендует запускать его только на UNIX-сокете с правами для привилегированных пользователей и не выставлять на сетевой порт.
• Главное исправление 1.31.5: use-after-free при буферизованном проксировании к клиенту по HTTP/2, из-за которого клиенту могла уйти освобождённая память или падал worker.
• njs 1.0.1 закрыл CVE-2026-18329 (обход js_access, появился в 0.9.9), CVE-2026-78222 (падение worker при пустой reason phrase у upstream, с 0.5.1) и CVE-2026-78689 (переполнение буфера в xml.exclusiveC14n(), с 0.7.10).
• Исходники и бинарные пакеты для основных дистрибутивов Linux уже доступны на nginx.org.

Что изменилось в маршрутизации

Авторы блога объясняют новую схему через почту. URI вроде /api/v1/checkout это адрес на конверте, заголовки Authorization и User-Agent это штампы, а тело запроса с JSON это само письмо внутри. Классический NGINX сортировал письма по адресу на конверте: выбирал location по URI, а тело обычно читалось уже после выбора location. Проблема в том, что современные клиенты, от GraphQL и JSON-RPC до MCP-серверов для ИИ-агентов и краулеров, шлют совершенно разные операции на один и тот же адрес /api/v1, /graphql или /mcp.

В 1.31.5 конверт можно вскрыть до сортировки. Четыре новые возможности складываются в одну цепочку: прочитать тело раньше, вытащить из JSON нужное поле в переменную, использовать переменную как условие выбора location.

Predicate locations: location по любой переменной

Любая переменная становится предикатом, если написать её в определении location (nginx/nginx#1633). Блок срабатывает, когда переменная непустая и не равна нулю. Условие может учитывать что угодно: подсеть клиента, клиентский сертификат, заголовки, результат map или поле из тела запроса. Пример из блога:

По словам разработчиков, условия вычисляются на уровне C без скриптового рантайма. До сих пор сложную логику выбора location собирали из map, if и внутренних редиректов либо выносили в njs и Lua.

client_body_early_read: тело до выбора location

По умолчанию NGINX читает заголовки, выбирает location и только затем буферизует тело. Директива client_body_early_read меняет порядок: тело буферизуется до сопоставления location, а разбирает его уже отдельный JSON-модуль (nginx/nginx#1641). Проект называет два сценария: маршрутизация по содержимому, когда вызов инструмента tools/call в MCP уходит на свой сервис вместо общего /mcp, и проверка на границе, когда слишком большой или некорректный payload отклоняется, ограничивается по частоте или валидируется до того, как уйдёт на бэкенд. Раньше для учёта отдельных вызовов инструментов агентов NGINX предлагал модуль MCP Observability на njs.

ngx_http_json_module: поля JSON в переменные

Новый модуль разбирает буферизованный JSON и кладёт поля, включая вложенные, в обычные переменные NGINX (nginx/nginx#1642). Дальше переменную можно подать в map или прямо в предикат location. Пример вытаскивает поле method из тела POST-запроса. В анонсе аргументы приведены в обратном порядке; по исходному коду модуля директива принимает сначала имя новой переменной, затем источник и путь:

В паре с client_body_early_read переменные из JSON заполняются до выбора location. Полное описание директив модуля разработчики обещают в отдельных статьях: в блоге анонсированы три разбора, про predicate locations, про Control API и про маршрутизацию по телу запроса.

Control API пришёл из NGINX Plus, но без аутентификации

Control API впервые появился в NGINX Plus R37.0 LTS, а теперь перенесён в открытую версию (nginx/nginx#1626). Он даёт программный доступ к состоянию процессов и конфигурации по адресам /1/control/processes и /1/control/config и позволяет перезагружать конфигурацию с синхронным ответом в JSON. Раньше перезагрузка делалась через nginx -s reload или сигнал, а результат приходилось ловить в /var/log/nginx/error.log: опечатка в конфигурации или проблема с правами на сокет обнаруживались уже постфактум. Теперь ошибка возвращается в HTTP-ответе, что удобно для конвейеров деплоя и инструментов infrastructure as code.

Для безопасного использования проект советует запускать NGINX с привязкой API к UNIX-сокету:

Control API работает и на сетевом порту, но команда NGINX прямо не рекомендует так делать: «API предоставляет открытый неаутентифицированный интерфейс к внутренностям NGINX и должен быть привязан к защищённой файловой системе, доступной только привилегированным пользователям» (перевод редакции). Путь к сокету в примере, /tmp/nginx.sock, взят из блога; на боевом сервере его стоит вынести в каталог с ограниченными правами.

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

Главной причиной обновиться разработчики называют исправление в буферизованном проксировании (nginx/nginx#1664). При ошибке на стороне клиента функция ngx_event_pipe_drain_chains() возвращала в пул все буферы, включая цепочку p->busy, которую ещё использовали фильтры вывода. По HTTP/1.1 это оставалось незаметным, потому что запрос завершался сразу. По HTTP/2 флаг ошибки ставился на фиктивное соединение, обработчик записи продолжал отправлять DATA-фреймы, указывающие на освобождённую память, и клиент мог получить содержимое кучи, а worker упасть на незамапленной странице. По словам авторов, вредоносный ввод для этого не требовался: в упрощённом описании анонса хватало ошибки в фильтре тела ответа и медленного клиента, у которого накапливались фреймы; в pull request сценарий воспроизведения описан подробнее, с настройками временных файлов и особым ответом upstream. Затронута любая конфигурация с proxy_buffering on и клиентами по HTTP/2.

• Worker без свободных файловых дескрипторов теперь завершается штатно. Раньше при заполненной таблице дескрипторов вызов recvmsg() с SCM_RIGHTS не мог прочитать канал управления, worker закрывал свой конец канала и больше не получал сигнал завершения, то есть висел после reload (nginx/nginx#1662).
• Таймер повторного включения accept удаляется вместе с listen-соединением: иначе после NGX_CMD_QUIT в логах появлялось accept4() failed (9: Bad file descriptor).
• Имена параметров fastcgi_param от 128 байт и uwsgi_param от 256 байт теперь кодируются с правильной длиной. Раньше поле длины обрезалось до одного байта, запрос к бэкенду получался повреждённым, PHP-CGI сбрасывал соединение, и NGINX отвечал 502 на каждый запрос к такому location (nginx/nginx#1648). SCGI не затронут.
• Три проверки входных данных: длины ответов memcached вблизи NGX_MAX_OFF_T_VALUE отклоняются с 502, начало диапазона Range у самого максимума в модуле slice игнорируется с ответом 416, а CRYPTO-фреймы QUIC в 1-RTT-пакетах после завершения рукопожатия отвергаются с ошибкой unexpected_message. Первые две ошибки были неопределённым поведением и роняли сборки с -fsanitize=signed-integer-overflow.
• Исправлен расчёт переполнения длины при формировании JSON в ngx_json_obj_length().

Что закрыл njs 1.0.1

njs, модуль, который добавляет в NGINX JavaScript, получил версию 1.0.1 в тот же день. В списке изменений три записи с пометкой Security.

• CVE-2026-18329: обход контроля доступа в js_access. Если асинхронное продолжение чтения тела запроса бросало исключение или завершалось необработанным rejection, NGINX продолжал обрабатывать запрос так, будто проверка js_access прошла. Ошибка появилась в njs 0.9.9; нашёл её Та Дык Тхиен.
• CVE-2026-78222: падение worker-процесса при чтении Response.statusText, когда upstream вернул строку статуса с пустой reason phrase. Ошибка присутствовала с версии 0.5.1.
• CVE-2026-78689: переполнение буфера в куче при разборе списка префиксов пространств имён, переданного в xml.exclusiveC14n(). Ошибка с версии 0.7.10; о ней сообщили исследователи из Cyera и evilgensec.

Помимо уязвимостей, в 1.0.1 исправлены use-after-free, аварийные завершения worker и утечки при циклических ссылках между объектами Fetch, HTTP-запроса и Stream-сессии в движке QuickJS, переполнение буфера на стеке при экспорте RSA-ключей длиннее 4096 бит в JWK через crypto.subtle.exportKey(), шифрование и расшифровка RSA-OAEP с SHA-256 и SHA-384, проверка значений заголовков Fetch и имён в r.headersOut, а также целей редиректа в r.return(). Добавлены глобальные функции btoa() и atob() в движке QuickJS и совместимость с quickjs-ng 0.16.0 и новее.

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

1. Если в конфигурации есть js_access, обновить njs до 1.0.1 сразу: до этого ошибка внутри проверки доступа открывала запрос вместо того, чтобы его отклонить.
2. Если NGINX проксирует с proxy_buffering on и принимает HTTP/2, обновить ядро до 1.31.5: это исправление разработчики называют главной причиной обновления.
3. Ветка 1.31 это mainline, где новые возможности появляются первыми. Predicate locations, client_body_early_read, JSON-модуль и Control API есть только здесь; в стабильной ветке их пока нет, и о сроках переноса в блоге не сказано.
4. Пробуя Control API, привязывать его только к UNIX-сокету в каталоге с ограниченными правами. Аутентификации у API нет.

NGINX 1.31.5 доступен в исходниках и бинарными пакетами для основных дистрибутивов Linux. Предыдущая версия 1.31.4 вышла 19 августа и добавила PROXY protocol v2 в модули stream и mail. По каждой из четырёх новых возможностей команда NGINX обещает отдельные статьи с примерами конфигурации, и редакция вернётся к теме, когда появится документация директив JSON-модуля.

Источники: NGINX 1.31.5: Control API, predicate locations, early body inspection, and more (NGINX Community Blog), CHANGES nginx 1.31.5, Changes with njs 1.0.1, Релиз nginx 1.31.5 на GitHub

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

Если вы держите кластер с десятками тысяч подов или крупными объектами и видели пики памяти на 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

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

По прогнозу Gartner, мировые расходы на публичные облачные сервисы в 2025 году должны были достигнуть $723,4 млрд, а к 2027 году около 90% организаций будут использовать гибридные облачные подходы. При этом локальная инфраструктура не исчезает: исследование Uptime Institute за 2025 год показало, что 45% рабочих нагрузок по-прежнему размещаются в корпоративных дата-центрах.

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

Критерии выбора инфраструктурной модели

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

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

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

Доступность и восстановление. Важно определить, какой простой допустим и насколько быстро должны восстанавливаться сервисы и данные. Обычно эти требования описывают через показатели RTO — допустимое время восстановления — и RPO — допустимый объем потерянных данных.

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

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

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

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

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

Что на самом деле требуют регуляторы

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

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

Похожий принцип действует при соблюдении PCI DSS — стандарта защиты данных платежных карт. Облачный провайдер может отвечать за безопасность физической инфраструктуры и платформы, но это не освобождает клиента от настройки доступов, защиты приложений и контроля обработки данных. PCI Security Standards Council прямо описывает безопасность в облаке как разделенную ответственность, границы которой должны быть определены между заказчиком и поставщиком.

Собственные серверы: когда контроль важнее гибкости

Собственная инфраструктура, или on-premise, означает, что компания приобретает оборудование, размещает его в серверной или дата-центре и самостоятельно отвечает за эксплуатацию: обновления, безопасность, резервное копирование и восстановление после сбоев.

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

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

Однако контроль имеет свою цену. Покупка серверов — только начало. В течение всего срока эксплуатации компания оплачивает:

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

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

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

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

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

Облако: скорость становится конкурентным преимуществом

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

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

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

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

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

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

Почему компании не переносят в облако всё

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

Первая причина — сложность миграции. Крупный ритейлер может быстро развернуть в облаке мобильное приложение или новый аналитический сервис. Но перенос старой ERP-системы, связанной со складским оборудованием, бухгалтерией и десятками внутренних приложений, потребует переработки интеграций и бизнес-процессов.

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

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

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

Частное облако: контроль без собственной серверной

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

Частное облако позволяет сохранить высокий уровень контроля, но при этом использовать преимущества облачной модели:

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

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

Гибридная инфраструктура – давно не компромисс

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

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

Например:

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

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

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

Когда гибридная инфраструктура оправдана

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

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

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

Как различаются основные модели

Частное облако Linx как элемент гибридной инфраструктуры

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

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

Linx предоставляет облачные ресурсы по модели IaaS, частные облака, сервисы резервного копирования и аварийного восстановления, а также услуги размещения оборудования и объединения площадок. Это позволяет построить гибридную архитектуру, в которой собственное оборудование, выделенная облачная среда и дополнительные вычислительные ресурсы работают как части единого IT-ландшафта.

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

Что делать на практике

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

1. Составьте карту систем. Отдельно перечислите приложения, базы данных, аналитические платформы, хранилища, тестовые контуры и средства резервного копирования.
2. Зафиксируйте среднюю и пиковую нагрузку. Определите, какие системы работают стабильно, а какие испытывают сезонные или непредсказуемые скачки.
3. Определите требования к доступности. Укажите допустимое время простоя, RTO и RPO для каждой системы.
4. Проверьте требования к данным. Уточните, где должна находиться информация, какие сертификаты и документы нужны от поставщика и кто отвечает за каждый уровень защиты.
5. Рассчитайте полную стоимость владения. Сравнивайте не цену сервера и тариф облака, а все расходы за несколько лет: оборудование, лицензии, персонал, обслуживание, резервирование и масштабирование.
6. Оцените возможности команды. Определите, какие компоненты специалисты компании готовы поддерживать самостоятельно, а какие рациональнее передать провайдеру.
7. Учтите стоимость перехода. В расчеты должны входить миграция, изменение приложений, тестирование, обучение сотрудников и возможные простои.
8. Выберите среду для каждой нагрузки отдельно. Критичные и стабильные системы можно оставить в контролируемом контуре, а переменные, временные и быстрорастущие нагрузки — разместить в облаке.

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

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

Как составить карту нагрузок

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

Для каждой нагрузки нужно ответить по пунктам на несколько вопросов:

• Какие данные она хранит и какие требования распространяются на их обработку;
• Какую задержку допускает приложение и где находятся его пользователи и зависимые системы;
• Насколько предсказуемо потребление CPU, памяти, диска и сетевого трафика;
• Какие интеграции перестанут работать при потере связи между площадками;
• Каковы целевые RTO и RPO: допустимое время восстановления и допустимая потеря данных.

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

Как связать площадки

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

Для связи офисов, ЦОД и облачных ресурсов используют выделенное подключение к сети провайдера, например, по схеме L2VPN, либо VPN через интернет. L2VPN объединяет сегменты на канальном уровне, а необходимость дополнительного шифрования определяют по модели угроз и требованиям к данным.

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

Какие задачи решает гибридное облако

Первый сценарий связан с данными, для которых установлены особые требования.

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

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

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

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

Объектное хранилище может стать общим слоем для архивов, медиаконтента, логов и резервных копий. Приложения из разных сред обращаются к данным по S3 API, а правила доступа и сроки хранения задаются централизованно. Мы отдельно разбирали, где объектное хранилище действительно помогает, а где не заменит файловую систему. Перед внедрением нужно проверить совместимость приложений с конкретной реализацией S3 API и стоимость сетевого обмена. Для защиты данных доступны резервное копирование в облако, DRaaS и объектное хранилище с поддержкой S3 API.

Порядок перехода

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

Как посчитать стоимость

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

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

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

Как защитить обе среды

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

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

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

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

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

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

Резервные копии позволяют восстановить данные до точки, которую определяет RPO. DR-план описывает последовательность запуска приложений, сетей и зависимых сервисов. Во время тестов команда проверяет, укладывается ли восстановление в заданные RTO и RPO.

Какие сервисы Linx Cloud использовать

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

Для защиты данных доступны резервное копирование в облако, DRaaS и объектное хранилище S3. Конкретный набор сервисов зависит от требуемого времени восстановления, объёма данных, используемых платформ и выбранной модели ответственности.

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

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

Такое распределение называют моделью разделённой ответственности, или Shared Responsibility Model. Она определяет, какие компоненты обслуживает провайдер, какие остаются под управлением клиента и кто отвечает за результат. Состав задач зависит от выбранной услуги, поэтому его нужно проверять в документации провайдера и закреплять в договоре.

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

В Linx Cloud границы ответственности для IaaS есть в отдельной RACI-матрице: в ней указано, какие операции выполняет провайдер, какие — клиент, а где нужны обе стороны. Документ открытый, поэтому можете посмотреть: матрица распределения ответственности Linx Cloud IaaS.

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

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

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

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

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

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

Что такое модель разделенной ответственности

Эта модель (Shared Responsibility Model) описывает, какие уровни информационной системы обслуживает провайдер, а какие остаются под управлением заказчика.

Облачная система состоит из нескольких слоев:

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

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

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

Модель разделенной ответственности применяется и при выполнении отраслевых требований. Например, PCI Security Standards Council прямо рассматривает безопасность облачной среды как совместную ответственность поставщика и клиента: стороны должны прописать обязанности и утвердить их для каждого применимого требования.

За что обычно отвечает облачный провайдер

Точный состав ответственности определяется услугой и договором. Но в базовой IaaS-инфраструктуре провайдер управляет нижними инфраструктурными уровнями.

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

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

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

Виртуализация и облачная сеть

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

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

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

Доступность ресурсов и границы SLA

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

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

Что остается на стороне бизнеса

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

Архитектура системы

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

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

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

Операционные системы

В базовом IaaS клиент сам отвечает за операционные системы внутри виртуальных машин:

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

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

Приложения и базы данных

Заказчик отвечает за программное обеспечение, которое он разворачивает поверх инфраструктуры:

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

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

Пользователи и права доступа

Большая часть инцидентов не требует физического доступа к серверу. Достаточно получить учетную запись с избыточными правами.

Поэтому бизнес обычно отвечает за:

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

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

Данные

Компания определяет, какие данные размещаются в облаке, кто имеет к ним доступ и как долго они должны храниться. Если речь идет о персональных данных, передача инфраструктуры провайдеру не снимает обязанностей с оператора. Статья 19 Федерального закона № 152-ФЗ требует от оператора принимать необходимые правовые, организационные и технические меры защиты либо обеспечивать их принятие. Поэтому заказчику необходимо определить:

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

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

Кто отвечает за информационную безопасность

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

• физическую инфраструктуру и оборудование ЦОД;
• гипервизоры, управляющие компоненты и технологические сети;
• внутренние процессы администрирования и доступ своих сотрудников.

Заказчик отвечает за безопасность ресурсов, развернутых внутри облачной среды:

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

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

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

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

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

Кто должен настраивать резервное копирование

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

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

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

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

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

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

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

Кто отвечает за аварийное восстановление

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

Провайдер может отвечать за:

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

Заказчик обычно отвечает за:

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

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

Как ответственность меняется в IaaS, PaaS и SaaS

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

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

SLA не описывает всю ответственность

SLA (соглашение об уровне сервиса) фиксирует конкретные показатели для определенной услуги. В SLA могут указываться:

• доступность сервиса;
• время реакции поддержки;
• сроки устранения неисправностей;
• порядок обработки обращений;
• исключения;
• плановые работы;
• компенсации.

При этом SLA не всегда включает восстановление приложений, возврат удаленных данных, исправление ошибок внутри ОС или достижение целевых RTO/RPO. Например, у Linx Cloud есть гарантированное SLA для облачных сервисов до 99,99%. Показатель относится к конкретной услуге и не означает автоматическую доступность приложения на том же уровне.

Матрица ответственности: как убрать серые зоны

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

В строках перечисляют процессы и компоненты:

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

В столбцах указывают участников:

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

Для каждого действия определяют роль. Можно использовать модель RACI:

• R — Responsible: выполняет работу;
• A — Accountable: несет итоговую ответственность;
• C — Consulted: участвует в согласовании;
• I — Informed: получает информацию о результате.

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

В документации Linx Cloud опубликована отдельная матрица распределения ответственности для IaaS. Она использует RACI и показывает, как роли провайдера и клиента распределяются между уровнями облачной инфраструктуры.

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

Типичные ошибки при распределении ответственности

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

Что проверить до подписания договора

Перед переходом в облако важно заранее установить, кто за что отвечает, и закрепить это в договоре, SLA, техническом задании или матрице ответственности.

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

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

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

Как передать провайдеру больше задач

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

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

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

Как распределяется ответственность в инфраструктуре Linx Cloud

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

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

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

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

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

Что делать на практике

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

1. Разложите сервис на компоненты и назначьте владельцев

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

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

2. Зафиксируйте не только зоны, но и операции

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

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

3. Проверьте модель на учебном инциденте и регулярно обновляйте

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

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

Чек-лист распределения ответственности

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

☐ Определено, какие компоненты входят в услугу провайдера.

☐ Зафиксировано, кто администрирует гостевые операционные системы.

☐ Назначены ответственные за приложения и базы данных.

☐ Определено, кто создает пользователей и управляет правами.

☐ Понятно, входит ли резервное копирование в услугу.

☐ Установлены сроки хранения и периодичность создания копий.

☐ Назначен ответственный за проверку восстановления.

☐ RTO и RPO согласованы с бизнесом.

☐ Описан порядок объявления аварии и запуска DR.

☐ Зафиксирован владелец каждого бизнес-сервиса.

☐ Определены каналы связи и порядок эскалации.

☐ SLA соотнесен с архитектурой приложения.

☐ Матрица ответственности отражает фактическую инфраструктуру.

☐ Назначена дата следующего пересмотра документа.

Главное

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

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

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

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

Что такое DR-план и какие задачи он закрывает

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

Здесь мы будем говорить про DR-план, описывающий только ИТ-контур: серверы, базы данных, сеть, приложения и инфраструктуру. Если упал интернет-магазин, DR-план отвечает на вопрос «как поднять сайт и базу заказчиков». А вот что делать с условным колл-центром, который остался без рабочих мест , — это уже более широкий вопрос, который мы в этой статье не затрагиваем.

Чем DR-план отличается от резервного копирования

Резервное копирование в облако и DR часто путают. Бэкап отвечает за наличие копии данных. DR-план отвечает за восстановление работающего сервиса в заданный срок с заданным процентом потери данных.

Разницу легко понять на примере.

У компании есть резервные копии всех баз. Они лежат на отдельном хранилище, регулярно обновляются. Всё хорошо. Но в один день дата-центр становится недоступным из-за аварии на подстанции, а ИБП и ДГУ не справились с нагрузкой. Серверы выключены, доступ к ним потерян. Копии есть, но развернуть их негде — резервной площадки нет. А даже если она есть, никто не отрабатывал их восстановление, а потому доподлинно не знает, в какой последовательности поднимать сервисы, кто за что отвечает, какие пароли использовать и т.п.. Копии есть, а работающего сервиса нет. DR-план как раз и закрывает эту проблему: он описывает, как из копий собрать работающую систему в нужный срок.

Как DR-план связан с BCP

BCP (business continuity plan) — это план непрерывности бизнеса. Он описывает, как компания будет работать в кризисной ситуации в целом: куда переедет офис, как сотрудники будут связываться друг с другом, как выполнять ключевые бизнес-функции без привычных инструментов. DR-план — это часть BCP, его ИТ-составляющая.

Порядок разработки обычно такой: сначала проводится бизнес-анализ (BIA — business impact analysis) и составляется перечень критичных бизнес-процессов. Для каждого процесса определяют, какие ИТ-системы его обеспечивают. И уже под эти системы пишут DR-план. Не наоборот. Нельзя взять и описать восстановление всех систем подряд — нужно понимать, какой сервис для чего нужен и сколько компания готова за него заплатить.

Сколько стоит простой и как это меняет требования к плану

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

В июне 2026 года на Cnews были опубликованы результаты CX-исследования, проведённого на основе глубинных интервью со 180 заказчиками. У 39% компаний за последний год стоимость часа простоя значительно выросла. Ещё 35% сказали, что она осталась на прежнем уровне. 14% отметили снижение благодаря внедрению резервных систем и процедур.

Рост стоимости простоя связан с несколькими факторами:

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

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

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

Приоритет смещается в сторону мер, которые снижают риск отказов и сокращают время восстановления. Наиболее эффективными респонденты назвали создание запасной инсталляционной базы на всех уровнях инфраструктуры (46%) и разработку детальных планов и регламентов аварийного восстановления (32%).

Ещё один способ снижать потери от недоступности ИТ-систем — страхование в облаке: решение, которое помогает управлять рисками и рационально распределять финансовые потоки. Провайдер Linx Cloud предлагает собственную инфраструктуру на базе двух сертифицированных ЦОД уровня TIER III в Москве и Санкт‑Петербурге, что позволяет строить катастрофоустойчивые архитектуры с гарантированным уровнем доступности.

Как рассчитать RTO и RPO для своих систем

RTO (Recovery Time Objective) — это время, за которое система должна быть восстановлена после аварии. Считается от момента, когда принято решение о переключении на резерв, до момента, когда сервис снова доступен пользователям.

RPO (Recovery Point Objective) — это допустимый объём потери данных. Показывает, на сколько часов (или минут) можно откатить систему назад. Если RPO = 1 час, значит, при аварии допустима потеря данных, созданные не более чем за последний час. Всё, что было раньше, должно сохраниться.

Показатели назначаются на каждый сервис отдельно. Нельзя поставить один RTO на всю инфраструктуру — у платежной системы и внутреннего чата для сотрудников требования к восстановлению будут разными.

Методика расчёта идёт от бизнеса, а не от ИТ. Сначала считают, сколько компания теряет за час простоя конкретного сервиса. Потом определяют, какой простой бизнес готов терпеть, — это и будет RTO. Аналогично с RPO: оценивается, сколько данных можно потерять без катастрофических последствий.

Пример.

Интернет-магазин с выручкой 5 млн руб. в сутки. В пиковые часы (10:00–22:00) это около 300–400 тысяч в час. Допустим, бизнес готов терпеть простой не больше двух часов — иначе убытки (денежные и репутационные) становятся критическими. Значит, RTO = 2 часа. Потеря данных за час — это потеря заказов, которые могли бы быть оформлены. Если за час через сайт проходит 30 заказов на сумму 50 тыс. руб., бизнес может с этим смириться. RPO = 1 час. Если такая потеря неприемлема, нужно снижать RPO до 15–30 минут и использовать более частую репликацию.

Матрица критичности сервисов

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

Типичные ошибки при назначении показателей

1. RTO назначает ИТ-отдел без согласования с бизнесом. Инженеры берут цифры «с потолка», исходя из того, что им кажется разумным или на что хватает существующих ресурсов. Бизнес потом удивляется, почему платёжная система простаивала четыре часа, хотя каждый час простоя стоит миллион. RTO должен утверждаться на уровне топ-менеджмента — это бизнес-решение, а не техническое. Часто после оценки стоимости обеспечения RTO со стороны ИТ, бизнесу приходится корректировать свои аппетиты и пересматривать метрику. Но в конечном итоге она точно должна согласовываться бизнесом.
2. Один общий показатель на все системы. Платёжный шлюз и система для внутренних отчётов не могут восстанавливаться за одно и то же время. Это просто-напросто сжигание бюджета расфокусировка ИТ команды. Разные уровни критичности систем — разные RTO и RPO.
3. В RTO не заложено время на принятие решения и проверку данных. В плане написано «восстановить за 2 часа», но забыли, что сначала нужно созвониться, принять решение о переключении,. Реальное время может оказаться в два раза больше, если процесс инициации восстановления не описан и не отработан..
4. Показатели ни разу не подтверждались измерением на реальном восстановлении. RTO и RPO, которые никто не проверял, — это просто цифры в документе. Без тестов они не имеют никакой ценности.

Из каких разделов состоит рабочий DR-план

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

1. Область действия и перечень охваченных систем. Чётко указать, какие сервисы, площадки и компоненты инфраструктуры входят в план, а какие — нет. Если какой-то сервис не охвачен, это должно быть написано явно.
2. Карта сервисов и зависимостей. Схема, которая показывает, как сервисы связаны друг с другом и с внешними системами. Если упадёт база данных, какие приложения перестанут работать? Если откажет внешний API, что сломается внутри? Без этой карты восстановление существенно усложняется.
3. Целевые RTO и RPO по каждому сервису. Таблица с показателями для каждого сервиса из перечня. Цифры должны быть согласованы с бизнесом и утверждены.
4. Роли, зоны ответственности, матрица эскалации. Кто принимает решение о переключении на резерв. Кто выполняет технические действия. Кто проверяет целостность данных. Кто связывается с подрядчиками. Кто информирует руководство и пользователей. Если ответственный недоступен, кто его заменяет. Схема связи при недоступности корпоративных каналов — телефоны, мессенджеры, резервная почта.
5. Критерии активации плана и лица, принимающие решения. План не активируется автоматически при любом сбое. Должны быть чёткие критерии: время недоступности, характер отказа, оценка ущерба. И конкретный человек (или группа), который принимает решение и даёт команду «переключаемся на резерв».
6. Пошаговые сценарии восстановления (runbook). Самая объёмная часть. Для каждого сценария — последовательность команд, скриншоты интерфейсов, порядок проверок. Runbook должен быть настолько подробным, чтобы по нему можно было восстановить систему даже в 3 ночи в выходной.
7. Доступы, учётные записи, ключи шифрования, места хранения резервных копий. Где лежат пароли, как получить доступ к резервным копиям, если основная площадка недоступна, какие ключи нужны для расшифровки данных. Вся эта информация хранится отдельно от основного документа, в защищённом месте, но в плане должно быть описано, как до неё добраться.
8. Процедура проверки целостности данных после восстановления. После того как системы подняты, нужно убедиться, что данные не повреждены и доступны для использования информационными системами и конечными пользователями Эта процедура прописывается для каждого типа систем отдельно.
9. Критерии завершения аварии и порядок возврата на основную площадку. Авария считается закрытой, когда все критичные сервисы работают на резервной площадке и пользователи получили доступ. Но рано или поздно нужно вернуться на основную площадку — в плане указано, как это делается, в какой последовательности и с какими проверками.
10. Контакты подрядчиков, провайдеров, вендоров с номерами договоров и SLA. Когда падает оборудование, нужно звонить поставщику, когда отказывает облако — провайдеру. В плане должны быть актуальные контакты, номера договоров и согласованные SLA по времени реакции и решения инцидентов.
11. Журнал версий и ответственный за актуализацию. DR-план — живой документ. В нём фиксируется, кто и когда вносил изменения, какая версия сейчас действует, кто отвечает за его обновление.

Сценарии аварий, которые нужно описать в плане

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

Отказ отдельного узла или дискового массива. Самый частый сценарий. Отказал один сервер или СХД . Признак: сервер недоступен, ошибки в логах хранилища. Первое действие: переключить нагрузку на другой узел в том же ЦОД. Целевой RTO: 15–30 минут. Восстановление происходит в пределах одной площадки, без переключения на резервный ЦОД.

Полная потеря площадки. Авария в ЦОД — пожар, затопление, отключение электричества, обрыв кабеля на входе. Признак: все сервисы на площадке недоступны одновременно. Первое действие: активировать резервную площадку, переключить DNS. Целевой RTO: от 1 до 4 часов в зависимости от класса сервиса.

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

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

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

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

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

Как выбрать резервную площадку и схему аварийного восстановления ИТ-инфраструктуры

Выбор резервной площадки определяется целевыми показателями RTO и RPO. Чем жёстче требования, тем дороже и сложнее схема. Основные варианты — холодный, тёплый и горячий резерв.

Холодный, тёплый и горячий резерв

DRaaS как резервная площадка

DRaaS (Disaster Recovery as a Service) — модель, при которой резервная площадка арендуется у провайдера. Компания не строит собственный резервный ЦОД, а использует облачную инфраструктуру провайдера.

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

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

До подписания договора задайте провайдеру несколько вопросов:

• Какой RPO может обеспечить сервис?
• Как часто можно проводить тестовые переключения без дополнительной оплаты?
• Где физически размещены данные — в каком регионе, в каком ЦОД?
• Кто выполняет переключение — команда провайдера/ собственная команда заказчика/совместно?
• Как организована поддержка в нерабочее время и в выходные?

Облачная инфраструктура IaaS — модель аренды виртуальных сервисов и других ресурсов, при которой компании платят только за фактическое использование мощностей. Такой подход даёт гибкость и прозрачность расходов, но многое зависит от надёжности платформы. Компания Linx Cloud строит IaaS на базе собственных ЦОД — это даёт предсказуемую отказоустойчивость и возможность географически распределять нагрузки без оглядки на сторонние площадки. Плюс платформа работает на OpenStack, что упрощает интеграцию с существующей инфраструктурой и автоматизацию.

Разнесение площадок и каналы связи

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

Каналы связи между площадками нужно резервировать. Если основной канал оборвётся, репликация остановится, и RPO будет нарушено. В плане должно быть описано, как и кем переключаются DNS и публичные IP-адреса при переключении на резервную площадку.

Вариант размещения оборудования в ЦОД — colocation, то есть использование сторонних площадок для своих ресурсов. Задействуются виртуальные частные сети — выделенные каналы связи L2VPN.

Требования регуляторов РФ к плану восстановления

Для многих компаний DR-план — юридическое требование.

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

152-ФЗ о персональных данных. Операторы персональных данных обязаны обеспечивать восстановление данных, изменённых или уничтоженных вследствие несанкционированного доступа. Требования детализированы в постановлении Правительства № 1119 и приказе ФСТЭК № 21. Приказ ФСТЭК № 21 содержит группу мер по обеспечению доступности, включая резервирование и восстановление. Актуальная редакция приказа — от 14 мая 2020 года. С 1 сентября 2026 года вступают в силу новые меры, в том числе защита от современных угроз.

187-ФЗ о безопасности критической информационной инфраструктуры. Для значимых объектов КИИ (ЗОКИИ) предусмотрены меры по реагированию на инциденты и действиям в нештатных ситуациях, включая планирование восстановления. Поправки к закону вступили в силу 1 сентября 2025 года.

26 февраля 2026 года Правительство РФ утвердило распоряжением № 360-р единый перечень типовых отраслевых объектов КИИ. Документ насчитывает 397 типовых объектов по отраслям: банки и финансовые рынки, наука, здравоохранение, энергетика, транспорт, связь, оборонная и ракетно-космическая промышленность.

Для отдельных отраслей приняты отраслевые особенности категорирования: для атомной энергии (постановление № 4 от 16.01.2026), для банковской сферы (постановление № 92 от 06.02.2026), для науки (постановление от 07.03.2026).

Приказ ФСТЭК № 117. С 1 марта 2026 года вступил в силу приказ ФСТЭК № 117 от 11.04.2025, который обновил требования к защите информации в государственных информационных системах (ГИС). Документ распространяется не только на ГИС, но и на иные информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений. Требования включают политику информационной безопасности, подразделения защиты, цикл Деминга и новый показатель защищённости КЗИ.

ГОСТ Р 53647 (менеджмент непрерывности бизнеса). Серия стандартов, которые задают методическую рамку для управления непрерывностью. Включает практическое руководство, управление человеческими ресурсами, управление организацией в условиях кризиса. Документы действуют в настоящий момент.

ГОСТ Р 57580.1 для финансовых организаций. Стандарт содержит более 400 организационных и технических мер защиты информации для банков, страховых, клиринговых компаний и финтех-стартапов. В ноябре 2025 года Банк России разослал финансовым организациям письма, обязывающие требовать от поставщиков ИТ- и ИБ-услуг соответствия стандарту. В феврале 2026 года проведены первые проверки крупнейших финансовых организаций.

Для организаций, работающих с персональными данными, важно выбирать соответствующую инфраструктуру — облако, аттестованное по 152-ФЗ. Вариант для государственных информационных систем — частное облако для ГИС.

Тестирование DR-плана

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

Виды тестов

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

1. Разбор сценария на бумаге (tabletop exercise). Участники собираются и проходят сценарий устно: «что делаем, если упала база?», «кто кому звонит?», «какие команды выполняет?». Проверяются логика, последовательность действий, понимание ролей. Риска для продуктивной среды нет.
2. Восстановление одной системы на изолированном стенде. Берётся отдельный сервис и восстанавливается из бэкапов на тестовой среде. Проверяется, что бэкапы читаются, данные консистентны , восстановление проходит без ошибок.
3. Тестовое переключение группы связанных сервисов. Несколько сервисов, которые зависят друг от друга, переключаются на резервную площадку в тестовом режиме. Проверяются зависимости, порядок запуска, работа интеграций.
4. Полномасштабное учение с переводом продуктивной нагрузки. Самый сложный и рискованный вариант. Реальная нагрузка переключается на резервную площадку, пользователи работают с резервной средой. Проверяется всё: от инфраструктуры до пользовательского опыта. Риск — если что-то пойдёт не так, бизнес пострадает. Поэтому такие учения планируют на периоды низкой нагрузки и с полным планом отката.

Периодичность и критерии успешного теста

Полный пересмотр и проверка плана — не реже раза в полгода. Частичные проверки типа восстановления отдельной системы можно делать чаще — раз в месяц или после каждого значимого изменения инфраструктуры.

Критерии успешного теста:

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

В протоколе теста фиксируется фактическое время каждого шага. Не «восстановили за 2 часа», а «базу подняли за 35 минут, веб-серверы за 50 минут, проверка данных заняла 20 минут, итого 1 час 45 минут».

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

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

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

Как поддерживать DR-план в актуальном состоянии

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

Внеплановый пересмотр нужен в следующих случаях:

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

Организационная часть: у документа должен быть владелец, который отвечает за его актуальность. Место хранения — доступное, но защищённое. Обязательно наличие офлайн-копии (бумажной или на отдельном носителе) на случай, если корпоративные системы недоступны. Новые сотрудники, которые могут участвовать в восстановлении, должны быть ознакомлены с планом в рамках онбординга.

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

Чек-лист готовности DR-плана

Пройдите по пунктам и отметьте, что уже сделано, а что ещё нет:

☐ Перечень всех ИТ-систем, которые должны восстанавливаться, составлен и утверждён.

☐ Для каждой системы назначены RTO и RPO, согласованные с бизнесом.

☐ По каждому сервису назначен ответственный за восстановление и его заместитель.

☐ Критерии активации плана записаны, лицо, принимающее решение о переключении, определено.

☐ Доступы, пароли, ключи шифрования хранятся в защищённом месте, порядок доступа к ним описан.

☐ Порядок действий при недоступности основной площадки прописан и проверен.

☐ Дата последних учений и их результат зафиксированы в протоколе.

☐ Дата последнего обновления плана — не старше 6 месяцев.

☐ Офлайн-копия плана существует и хранится отдельно от корпоративных систем.

☐ Контакты подрядчиков, провайдеров и вендоров актуальны, номера договоров и SLA записаны.

DR-план — это постоянный рабочий процесс. Документ написали, протестировали, обновили, снова протестировали. Без тестирования и регулярной актуализации план — просто текст. С тестированием и актуализацией — инструмент, который реально помогает в аварии.

Если собственной резервной площадки нет или строить её дорого, стоит обратить внимание на сервис аренды резервной инфраструктуры от DRaaS от Linx Cloud. Ресурсы компании позволяют снять вопросы с оборудованием, каналами и поддержкой, оставляя заказчику только настройку и управление процессом.

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

Откуда взялась задача

Требований у меня было немного, но именно они всё и отсеяли: сервер должен стоять у меня, телеметрия парка не утекать на сторону, и всё это работать на смешанном парке сразу. Self-hosted-вариантов под такое оказалось немного, и те, что были, спотыкались об одно и то же: либо только маки, либо платные и при этом недоступны в России, либо разваливались на простом вопросе — а что с устройством, если агент две недели просидел офлайн. Ближе всего в этом поиске подобрался Fleet — серьёзный открытый проект, к нему я ещё вернусь ниже. Но развернуть его у себя оказалось тем ещё квестом: я в России, а fleetdm на российский IP не але, так что и сервер, и сборку агентов приходилось поднимать через VPN. Вдобавок агент на macOS в моём случае вставал через раз, а то и вовсе не ставился. Инструмент, который в итоге получился, я назвал RoutineOps; дальше по тексту буду говорить «агент», «сервер» и «панель».

Ещё одно соображение, которое я держал в голове: базовую защиту управляющего канала — mTLS, аудит, вменяемую политику паролей, подпись обновлений — я считаю БАЗОЙ, и держать её за пейволлом мне казалось неправильным. Это моё мнение, не претензия к рынку. Проект в итоге открыт под Apache-2.0; платный уровень существует, но вся базовая защита — в открытой части, и это не тема статьи.

Почему постоянный gRPC/mTLS-канал, а не опрос через VPN

Вечная головная боль: как дотянуться до ноутбука, который сейчас сидит в кафе за чужим NAT. Классических ответов два, и оба мне не понравились. Загнать всех в VPN — это лишняя инфраструктура и ещё одна точка отказа. Сделать агент, который раз в N минут дёргает HTTP-эндпоинт «не прилетело ли чего», — это шторм пустых запросов, а задержка команд упирается в период опроса.

Я пошёл третьим путём. Агент — Go-бинарь, который держит постоянный gRPC-стрим поверх mTLS наружу, по обычному интернету. Соединение инициирует сам агент: оно исходящее, а значит дружит с NAT. По этому же двунаправленному стриму сервер в любой момент проталкивает команду — запусти скрипт, заблокируй экран. Задержка доставки тут — это задержка сети, а не интервал, на который выставлен опрос.

Стек намеренно скучный — скучное не будит меня в три ночи.

- Агент и сервер — Go, сервер монолитом, без зоопарка микросервисов.

- Связь — gRPC + Protocol Buffers поверх mTLS: TLS 1.3, приватный CA с пиннингом на всём канале агентов.

- База — PostgreSQL 16, источник правды.

- Очередь задач — Redis + Asynq, с ретраями.

- Веб-интерфейс — React + TypeScript (Vite), раздаётся nginx-контейнером.

- Развёртывание — Docker Compose.

Порты минимальны: `443` — веб-интерфейс, REST API, enroll, отдача бинарей; `50051` — постоянный gRPC-канал агентов. Postgres и Redis наружу не торчат вообще. На парк до 50 устройств хватает 1 vCPU / 2 GB RAM / 20 GB SSD — и это стартовая планка. Heartbeat дешёвый, инвентарь редкий, поэтому один узел спокойно тянет тысячи устройств: предел задаёт железо машины, не архитектура.

Сертификат — это идентичность, и всё

Самый важный архитектурный вопрос: как агент доказывает, что он именно то устройство, за которое себя выдаёт. Ответ короткий. `device_id` — это CN клиентского сертификата, и только он. Идентификаторам в теле сообщений сервер не верит вообще. Прилетел heartbeat, а внутри указан чужой `device_id`? Игнорируется. Значение имеет одно — чем подписан TLS-хендшейк.

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

1. Админ в панели заводит устройство и получает одноразовый токен: TTL 24 часа, single-use, гонка при погашении закрыта на уровне БД.

2. Агент локально генерирует пару ключей и отправляет CSR на `POST /api/v1/enroll`.

3. Сервер подписывает сертификат своим приватным CA и сам проставляет CN. Повлиять на свой CN агент не может.

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

Вывод из эксплуатации — это отзыв сертификата

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

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

Heartbeat и инвентаризация разведены нарочно

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

Heartbeat — лёгкий и частый, примерно раз в 30 секунд, по постоянному стриму; по нему же едут задачи. Дёшево, потому что данных в нём кот наплакал. Инвентаризация — тяжёлая и редкая, примерно раз в 5 минут: ОС, железо, серийник, установленное ПО (на Linux — из dpkg/rpm/pacman/apk), версия агента.

Такое разделение держит постоянный канал дешёвым при любом размере парка. Если устройство пропало с радаров и heartbeat не приходит дольше порога (порог настраивается через `AGENT_UNREACHABLE_MINUTES`) — поднимается алерт `agent_unreachable`, с подавлением дребезга от сна и modern standby, иначе каждый закрытый на ночь ноут спамил бы в Tele... Max :).

Результаты скриптов идемпотентны. У каждого запуска есть `run_id`, и повторная доставка дедуплицируется на сервере. Связь рвётся, ack теряется, агент шлёт результат заново — без этой механики ловил бы дубли, а на неидемпотентных командах ещё и двойное исполнение.

Скрипты, группы и вопрос «а на скольких машинах это сейчас так»

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

У скрипт-политик три триггера: расписание (cron), при подключении агента и по событию. Третий появился из практики — реакция на «поставили запрещённое» полезна в момент установки, а не в ближайшие плановые три часа ночи. Софт-политики — правила allowed/forbidden по устройству, группе или платформе; они же кормят алерты: увидел агент в инвентаре то, чего быть не должно — прилетело событие.

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

Агенту не нужна постоянная связь

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

Сложнее всего с блокировкой экрана. В офлайне полноэкранный overlay держится, а разблокировка идёт по локально хранимому bcrypt-хешу пароля — ходить за ней к серверу не нужно. Это осознанный компромисс: если бы разблокировка требовала сервер, любой обрыв связи превращал бы блокировку в невозможность войти в систему — а это уже хуже самой угрозы. Результаты и события тем временем копятся локально и досылаются, когда связь вернётся.

Обход блокировки — это тоже событие

Оверлей держится офлайн, но живёт он на машине, у пользователя которой есть руки. Поэтому у службы агента есть tamper-protection: на Windows — SafeBoot плюс реестр, на macOS — флаг `schg`. На Linux её нет, и это записано в docs/tamper-protection.md прямым текстом, а не подразумевается. Штатное снятие защиты — отдельная процедура, а не «убил процесс и пошёл дальше».

Попытка снять блокировку в обход службы поднимает событие ИБ. Логика та же, что и везде выше: при физическом доступе к железу механику рано или поздно обойдут — но пусть обход хотя бы не будет тихим. Не остановить, так зафиксировать.

Временные админ-права — без поездки к машине

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

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

Конфигурация как код — потому что кликать второй раз я не хотел

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

Поэтому появился CLI `routineops` с YAML-экспортом и применением: выгрузил скрипты, политики и группы в файлы, положил в git, применил на другом сервере. Diff конфигурации теперь читается в ревью, а не реконструируется по журналу аудита задним числом.

Fail-closed self-update и миграции

Самообновление — самый опасный канал из всех. Тот, кто им рулит, кладёт свой бинарь на все устройства как root. Поэтому здесь всё fail-closed. Примерно раз в 6 часов агент тянет манифест и проверяет sha256 и ed25519-подпись по полному манифесту: версия, ОС, архитектура, хеш подписаны одним набором сразу. Так нельзя подсунуть валидный бинарь под чужую версию или платформу. Дальше агент атомарно заменяет себя и перезапускается. Даунгрейд невозможен — есть anti-rollback floor: битый релиз чинится только версией вперёд, назад дороги нет. Приватный ключ подписи уникален для конкретной инсталляции; потеря не катастрофа — новый раздаётся через переэнролл.

На сервере тот же принцип. Схему накатывает отдельный migrate-сервис — до старта сервера. Не прошла миграция — сервер просто не поднимется на несовместимой схеме. Down-миграций нет, и это намеренно: откат — только из бэкапа, причём бэкап БД update.sh снимает сам перед каждым обновлением. Пережить факап из снапшота я предпочту тому, чтобы полагаться на корректность down-скрипта, накатываемого поверх наполовину применённого состояния.

Модель доверия: god-mode by design

А вот тут льстить не буду — и это, пожалуй, самая важная часть текста. MDM по своей природе — это god-mode над парком. Скрипт-канал исполняет произвольный `bash -c` / `powershell -Command` как root/SYSTEM на каждом устройстве. Это не дыра, которую я забыл заткнуть. Это и есть продукт: весь смысл MDM в том, чтобы раскатать одну команду на сотню машин разом. А такой инструмент по определению — санкционированный RCE.

Скажу прямо.

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

- `JWT_SECRET` (симметричный HS256) — единственный корень доверия панели. Кто прочитал этот секрет, тот печатает себе сколько угодно валидных admin-токенов. Не «подобрать пароль», не «обойти MFA» — просто сгенерировать подписанный токен и зайти админом.

- Отсюда единственный вывод: реальный периметр безопасности — это хост, на котором крутится сервер. Не TLS, не RBAC, не аудит. Они важны, но вторичны. Увели сервер — увели весь парк.

Харденинг этого хоста — работа оператора, и в SECURITY.md под неё лежит чеклист: SSH только по ключам, наружу открыты только два порта, Postgres и Redis — на localhost, `JWT_SECRET` генерируется через `openssl rand -base64 48` и лежит в режиме `600`, панель — за VPN или IP-allowlist, аудит-лог — в append-only хранилище с алертом на появление новых админов.

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

Что закрыто по умолчанию

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

- Не стартует на слабом секрете. Требует `JWT_SECRET` от 32 байт и минимум 16 различных байт. Случайно уехать в прод на `changeme` не получится.

- Admin-JWT живёт 8 часов. Logout реально ревокирует токен через jti-блоклист. Смена или сброс пароля обнуляет все ранее выданные токены пользователя разом — через token-epoch.

- Lockout по IP и по аккаунту, bcrypt cost 12. Форма входа не выдаёт, какие аккаунты вообще существуют.

- Политика сложности пароля — для всех, включая seed-админа: от 8 символов, минимум 3 класса символов из 4. Даже первый администратор не заведётся с `admin/admin`.

- RBAC на две роли — `it_admin` (всё) и `viewer` (только чтение), с проверкой на сервере. Viewer, дёрнувший мутирующий эндпоинт прямо из DevTools, упрётся в 403 ещё на сервере.

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

- Плюс одноразовые enroll-токены, журнал аудита на каждое привилегированное действие (retention по умолчанию 365 дней), security-заголовки (HSTS/CSP/X-Frame-Options/nosniff), rate-limit и cap на размер запроса.

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

Мелочи, из которых на самом деле состоит эксплуатация

Отдельного раздела каждая из них не заслуживает, но вместе они закрывают вопрос «а как я об этом узнаю»:

- Удалённая перезагрузка устройства или всей группы. Отсрочку отсчитывает сама ОС, а не таймер внутри агента: агент может умереть, ребут — нет.

- «Пользователь за консолью» в карточке. Кто прямо сейчас сидит за машиной. Без этого половина алертов повисает в воздухе.

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

- Расширенный инвентарь ПО: издатель, путь, архитектура, ключ снятия, машина/профиль. Инвентарь, по которому не отличить системную установку от пользовательской, для софт-политик бесполезен.

- `agent diag` на устройстве. Первый вопрос в поле всегда один — «почему агент не выходит на связь», и отвечать на него по логам сервера бессмысленно: сервер как раз ничего и не видит.

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

Честные ограничения

Раз обещал честность — вот граница, без прикрас.

- Один узел — одна точка отказа. Для парка в режиме «поставил и работает» этого достаточно, но иллюзий про отказоустойчивость держать не стоит.

- Нет SSO и MFA. Вход по паролю плюс RBAC. Пока разумно держать панель за VPN или allowlist.

- macOS .pkg не подписан Apple. По двойному клику встретит Gatekeeper — ставится через `installer` из терминала.

- Скрипт-канал — это RCE by design. Подробно — в разделе про модель доверия выше.

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

- Оверлея блокировки на Linux нет. Состояние блокировки хранится, экрана нет.

- Запрещённое ПО детектится, но не удаляется. Алерт есть, автоматического устранения — нет.

- Под Windows нет сборки arm64. Для Linux и macOS arm64 есть.

Про Fleet

Ближайший открытый аналог, который я смотрел, — Fleet, тоже open source, ядро под MIT. Инструмент серьёзный и зрелый, и во многом он сильнее моего: настоящий нативный MDM с профилями конфигурации и zero-touch-энроллментом, live-запросы osquery по всему парку, расчёт на масштаб в сотни тысяч машин. Построен вокруг osquery, инфраструктура — MySQL плюс Redis за балансировщиком, под горизонтальное масштабирование.

Под мой случай он просто не сошёлся по устройству. Чтобы реально управлять маками, Fleet опирается на нативный Apple MDM — а это APNs-сертификат от Apple с ежегодным продлением плюс Apple Business Manager для zero-touch. Мне не нужна была SQL-аналитика по всему парку; нужен был лёгкий агент, офлайн-лок без APNs, инвентарь и скрипты. А поверх этого архитектурного несовпадения легли те самые бытовые проблемы с развёртыванием из России и капризным macOS-агентом, о которых я писал в начале.

Чему это меня научило

Самое неожиданное в проекте — что львиная доля инженерных решений оказалась не про «как добавить», а про «как убрать». Идентичность через CN вырезала целый класс серверной авторизации; fail-closed на миграциях и обновлениях — ветки «а что если накатилось наполовину». Разведённые heartbeat и инвентарь сняли лишний трафик. А карта модели доверия избавила меня самого от иллюзии, будто TLS и RBAC — это и есть безопасность. Настоящий периметр оказался в одном месте — на хосте сервера.

Исходники я открыл под Apache-2.0; прямую ссылку на репозиторий оставлю тут :). Если вам будет интересно я бы с радостью пообщался по замечаниям именно по модели доверия — по местам, где приложение должно что-то enforce-ить, но не делает.

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

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей page object сломал и почему Android отвалился после правки для iOS.

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

Как говорил один мой коллега, перефразируя классическое “вам шашечки или ехать”:

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

Идея была «как в книжке»: один репозиторий, модульная структура, переиспользование. DRY во все поля. Ну а чё, красиво же.

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

Половина нужна только Android, другая только iOS. Но метод один. Потому что так более по программистцки, как написано в каждой второй статье про архитектуру автотестов.

Когда я работал один, было норм. Ты сам знаешь, от куда что идет.

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

Общие Page Objects звучат красиво на бумаге: пишем один раз, используем для обеих платформ. А на практике…

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

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

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

Ладно, человеческий фактор. Но были и чисто технические штуки, которые окончательно убедили меня, что кроссплатформа тут бессмысленна.

Локаторы: работай с тем, что дают

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

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

Координаты - костыль? Да. Но иногда единственный вариант. Когда у тебя кастомный контрол без accessibility-свойств, а разработчик говорит «это декоративный элемент», ты либо тыкаешь по координатам, либо не тестируешь.

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

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

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

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

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

Приложение простое, пара экранов, стандартные контролы, минимум кастомного UI.

UI реально идентичен на обеих платформах. Бывает, наверное.

Команда из одиного человека. Сам пишешь, сам мёрджишь, сам разруливаешь. Голова справляется.

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

Два проекта это не шаг назад и не двойная работа. Со стороны может выглядеть именно так, но на практике ты пишешь каждый тест один раз, под конкретную платформу, без лишних компромиссов. Потом поддерживаешь его без постоянных мерж конфликтов, каскадных обновлений и if/else в каждом втором методе.

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

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

Компания 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% вероятности банкротства при затяжной потере данных. Тестовое восстановление обходится дешевле.

• Новая спецификация MCP 2026-07-28 делает протокол stateless: сессии и handshake больше не нужны.
• Клиент передаёт свою идентификацию и возможности в поле _meta каждого JSON-RPC-запроса.
• Балансировщик может использовать обычный round-robin, ориентируясь на заголовки Mcp-Method и Mcp-Name.
• Roots, Sampling и Logging объявлены устаревшими с минимальным окном поддержки 12 месяцев.
• Финальная спецификация ожидается 28 июля 2026 года после 10-недельного окна валидации SDK.

Model Context Protocol (MCP) — открытый протокол для подключения ИИ-агентов к внешним инструментам и данным. С момента передачи Anthropic в Linux Foundation в декабре 2025-го им управляет Agentic AI Foundation, а число production-серверов уже исчисляется сотнями тысяч. До сих пор MCP работал по модели чата: сначала handshake, потом сервер выдавал идентификатор сессии, который клиент возвращал с каждым запросом.

В релиз-кандидате эта модель заменена на stateless. Клиент кладёт имя, версию и capabilities в поле _meta прямо в тело запроса. Балансировщик читает HTTP-заголовки Mcp-Method и Mcp-Name (SEP-2243) и направляет запрос на любой свободный инстанс — общее хранилище сессий больше не требуется. Если серверу нужен ввод посреди вызова, он возвращает InputRequiredResult, а клиент переотправляет запрос с inputResponses и requestState.

Вместе с ядром обновляются и расширения. Появляется MCP Apps — серверный интерактивный UI в sandboxed iframe с заранее декларируемыми шаблонами. Переработано API долгих задач: вместо tasks/list приходят tasks/get, tasks/update и tasks/cancel. Также шесть SEPов ужесточают авторизацию по OAuth/OIDC, включая проверку issuer по RFC 9207.

Часто задаваемые вопросы

Выводы

Новая спецификация — признак того, что MCP вырос из протокола для локальных подключений в полноценную enterprise-инфраструктуру. Переход к statelessness решает главную операционную проблему масштабирования, но добавляет работы тем, кто уже внедрил stateful-реализации. Главное — помнить, что релиз пока кандидат: production-серверы продолжают работать на спецификации 2025-11-25.

Источник: awesomeagents.ai.

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

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

Одним из главных пионеров первой волны миграции стал 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.

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

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

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

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

Автономный ИИ-агент получил доступ к производственной инфраструктуре Hugging Face.

Точка входа — вредоносный датасет с двумя путями выполнения кода.

Похищены ограниченный набор внутренних датасетов и несколько сервисных credentials.

Компания не нашла признаков изменений публичных моделей, датасетов, Spaces и supply chain.

Пользователям рекомендуется сменить токены и проверить активность аккаунта.

Для криминалистики Hugging Face использовала китайскую модель Z.ai GLM 5.2 — западные фронтирные модели отказали из-за guardrails.

Как проходила атака

Атака началась не с уязвимости в модели, а с данных. Злоумышленник загрузил вредоносный датасет, который при обработке запускал код внутри инфраструктуры Hugging Face. Агент использовал два вектора: удалённый загрузчик кода датасета и template injection в конфигурации. После выполнения кода на рабочем узле он повысил привилегии до уровня ноды, собрал облачные и кластерные credentials и за выходные переместился между несколькими внутренними кластерами.

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

Что делает инцидент необычным

Раньше ИИ в кибератаках чаще помогал злоумышленникам писать код или искать уязвимости. Здесь речь идёт об автономной системе агентов, которая действовала end-to-end: от первичного доступа до сбора credentials и lateral movement. Это один из первых публичных случаев, когда крупная платформа признала именно такой сценарий — «агентичного нападающего».

Меры и рекомендации

Hugging Face сообщила, что закрыла первопричину — оба пути выполнения кода, через которые проник агент. Кроме того, компания:

• удалила закрепление злоумышленника в скомпрометированных кластерах и пересобрала узлы;
• отозвала и заменила скомпрометированные credentials и токены, а также провела широкую ротацию секретов;
• ввела дополнительные guardrails и строгие admission controls в кластерах;
• улучшила детектирование и оповещения, чтобы реагировать в течение минут круглосуточно.

Пользователям рекомендуется заменить access tokens и проверить недавнюю активность в аккаунтах.

Почему расследование использовало GLM 5.2

В ходе расследования команда Hugging Face обратилась к модели Z.ai GLM 5.2 — открытой китайской модели. По словам компании, западные фронтирные модели отказали в запросах, содержащих реальные команды атаки, эксплойты и артефакты C2: их защитные guardrails срабатывали и не позволяли отличить атакующего от легитимного реагирования на инцидент. Hugging Face назвала это «пробелом, на который стоит обращать внимание»: защитникам нужна собственная модель, готовая к работе на своей инфраструктуре, чтобы не терять время и не выводить данные инцидента наружу.

Выводы

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

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

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

Чем VDS отличается от обычного хостинга

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

На виртуальном хостинге подобные возможности обычно ограничены, поскольку все клиенты используют общую программную среду. Именно поэтому разработчики, системные администраторы и владельцы сложных веб-проектов предпочитают использовать VPS или VDS.

Кроме того, современный виртуальный сервер позволяет работать с Docker, Git, Node.js, Python, PostgreSQL, Redis, Nginx и десятками других инструментов, необходимых для разработки современных приложений.

Когда действительно нужен бесплатный VDS

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

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

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

На что обратить внимание при выборе бесплатного сервера

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

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

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

Почему важно протестировать VDS перед выбором

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

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

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

Бесплатный VDS как возможность оценить инфраструктуру

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

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

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

Реклама. Рекламодатель: ООО «СпейсВэб», ИНН 7813376370, erid: 2W5zFK1N8eV

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

Selectel: серверные платформы с полным циклом разработки

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

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

От эксплуатации к разработке

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

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

Собственная аппаратная архитектура

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

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

Платформа Selectel поддерживает процессоры Intel Xeon 6, память DDR5, интерфейс PCI Express Gen5, модуль доверенной платформы TPM 2.0, а также предусматривает установку современных сетевых адаптеров и ускорителей вычислений.

Для задач искусственного интеллекта и высокопроизводительных вычислений используются серверы форм-фактора 8U с несколькими GPU, тогда как платформы 1U и 2U применяются для виртуализации, корпоративной инфраструктуры, баз данных, облачных сервисов и других сценариев эксплуатации.

BIOS, BMC и управление платформой

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

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

Для управления оборудованием Selectel использует собственный интерфейс Selectel Management Interface (SMI), разработанный на базе OpenBMC.

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

Программный уровень платформы

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

От платформы к решению под конкретную задачу

После того как серверная платформа разработана и проверена, она становится основой для инженерной работы с конкретными проектами.

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

Для CPU-интенсивных задач приоритетом становятся вычислительные ресурсы процессора и организация многопоточной нагрузки. Для систем хранения — производительность дисковой подсистемы и сетевых интерфейсов. При работе с GPU оцениваются баланс между центральным и графическими процессорами, пропускная способность PCI Express, требования к питанию и охлаждению. При необходимости проектируются конфигурации под storage- и backup-системы.

На этапе проектирования также анализируются особенности будущей инфраструктуры: тип рабочей нагрузки (CPU-bound, memory-bound, IO-bound или GPU-bound), требования к доступности и SLA, особенности электропитания, тепловыделения, размещения оборудования в стойке и существующей сетевой инфраструктуры.

Проверка гипотез до закупки оборудования

Для проверки используется Proof of Concept (PoC) — инженеры воспроизводят профиль нагрузки клиента на тестовом стенде, сочетая синтетические и прикладные тесты. Это помогает заранее оценить производительность, задержки, температурные режимы и запас вычислительных ресурсов.

Во время таких испытаний анализируются параметры, которые невозможно оценить по спецификации оборудования: NUMA-топология, баланс между CPU и GPU, производительность подсистемы хранения, влияние вариантов конфигурации памяти, пропускная способность сетевых интерфейсов и шин PCI Express.

По итогам команда получает рекомендации по конфигурации с учетом характера нагрузки и ожидаемой производительности.

Проверка совместимости и стабильности

После формирования конфигурации сервер проходит комплексную проверку.

На производственном этапе контролируются комплектность оборудования, версии компонентов и прошивок. BIOS, BMC, сетевые адаптеры, RAID- и HBA-контроллеры приводятся к согласованным версиям, что обеспечивает воспроизводимость конфигурации. Затем проверяется работа памяти, накопителей, сетевых интерфейсов, аппаратных датчиков и других компонентов платформы.

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

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

Что отличает подход Selectel

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

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

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

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

Deckhouse: Kubernetes-платформа и экосистема для Cloud Native

Deckhouse — экосистема инструментов для разработки, доставки и эксплуатации Cloud Native-приложений. В основе — Deckhouse Kubernetes Platform (DKP), которая автоматизирует управление кластерами Kubernetes поверх любой инфраструктуры: публичные и частные облака, bare metal, закрытые контуры без доступа в интернет. Вокруг платформы выстроен набор продуктов — управление виртуализацией, хранение секретов, CI/CD, мониторинг — всё в одной экосистеме с общим API и интерфейсом.

Продукты разрабатываются и размещаются на территории РФ. Платформа поддерживает российские ОС: РЕД ОС, Astra Linux, ALT Linux. Deckhouse Kubernetes Platform CSE имеет сертификат ФСТЭК России №4860, платформа внесена в реестр российского ПО.

Что входит в экосистему

Deckhouse Kubernetes Platform (DKP) — ядро. Управляет кластерами Kubernetes, системным ПО на узлах, базовыми компонентами. После установки платформа готова к работе: автомасштабирование, мониторинг, мультитенантность — из коробки, без ручной сборки из отдельных компонентов.

Deckhouse Virtualization Platform (DVP) — управление виртуальными машинами и контейнерами из одного интерфейса. Масштабируется до 1000 серверов и 50 000 виртуальных машин. Поддерживает IaC-подход через открытый API, что позволяет автоматизировать развёртывание и управление средой полностью декларативно.

Deckhouse Stronghold — управление жизненным циклом секретов: пароли, ключи API, сертификаты, SSH-ключи, токены. Совместим с API HashiCorp Vault, что упрощает миграцию с него — без выгрузки секретов наружу через внешние утилиты. Поддерживает двойное шифрование через внешние HSM (AES + ГОСТ, AES + RSA), автоматическое резервное копирование и межкластерную репликацию.

Как устроен процесс работы

Установка и конфигурация

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

Развёртывание в закрытых контурах

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

DevSecOps-практики

Сквозное применение DevSecOps на всех этапах поставки: управление сетевыми политиками, аутентификация и авторизация, заказ TLS-сертификатов, аудит-логирование, изолированные контейнеры.

Для кого это полезно

• Техлиды и архитекторы получают платформу, которая закрывает инфраструктурный слой: не нужно собирать стек из отдельных компонентов — мониторинг, service mesh, хранение секретов, балансировка уже встроены.
• Разработчики получают сокращение времени подготовки среды разработки до 15 раз, единый UI и API для управления всей инфраструктурой, понятный CI/CD-конвейер. DVP позволяет использовать IaC для управления виртуальными машинами так же, как контейнерами — через манифесты.
• QA-инженеры и SRE работают с уже настроенным мониторингом из коробки, автоматическими алертами и механизмами восстановления.

Что отличает подход

Вся экосистема продуктов разрабатывается одной командой и поддерживает единый канал экспертной поддержки. Не нужно разбираться, кто отвечает за проблему — платформа или отдельный модуль: всё покрывает один контракт.

Кластеры поддерживают любой тип инфраструктуры без изменения подхода к управлению: одни и те же практики работают в Yandex Cloud, в собственном ЦОД и на bare metal одновременно. В кейсе «Лемана ПРО» именно это позволило объединить кластеры из разных облачных провайдеров и дата-центров в единую инфраструктуру.

Высокая доступность из коробки: SLA 99,99% достигается за счёт отказоустойчивости компонентов платформы, геораспределённых конфигураций (Multicluster на базе Istio, MetroCluster) и fencing-механизмов для безопасного восстановления при сбоях узлов.

Техническая база

• Поддерживаемые ОС (host): Astra Linux SE, РЕД ОС, РОСА Сервер, ALT Linux, CentOS, Debian, Ubuntu
• Поддерживаемые ОС (guest в DVP): любые ОС на x86-64
• Интеграции: LDAP, OIDC, внешние HSM, аппаратные СХД (TATLIN, Huawei, HPE, NetApp), SCSI-протокол, LACP, VLAN
• API: открытый, совместим с HashiCorp Vault API (для Stronghold)
• Форматы дисков ВМ: VMDK, Qcow2, Raw
• Сертификация: ФСТЭК России №4860, реестр российского ПО

Управление и поддержка

Единый канал поддержки покрывает все продукты экосистемы. Для обучения работает Deckhouse Академия с курсами по платформе и инструментам безопасности. Обновления платформы приходят автоматически в выбранное окно обслуживания. Для знакомства с продуктами доступна 30-дневная пробная версия.

ELMA365 BPM: автоматизация бизнес-процессов на Low-code платформе

ELMA365 — Low-code BPM-платформа для оцифровки, автоматизации и оптимизации бизнес-процессов. В основе — процессный движок, который автоматически ставит задачи участникам, маршрутизирует процессы по заданной логике и собирает данные на каждом этапе. Моделирование ведётся в визуальном дизайнере по нотации BPMN 2.0 — без привлечения разработчиков. Сценарии и кастомная бизнес-логика пишутся на TypeScript с подсветкой синтаксиса и автодополнением прямо в интерфейсе.

Платформа разворачивается в облаке на серверах Яндекса — без установки дополнительных компонентов, всё работает через браузер. По данным TAdviser, ELMA BPM — самая внедряемая BPM-система в России и СНГ.

Продукт используют в корпоративной автоматизации: согласование документов, управление задачами и поручениями, электронный документооборот, CRM-процессы, КЭДО.

Как устроен процесс работы

Моделирование процессов

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

Формы и данные

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

Запуск и исполнение

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

Отладка и мониторинг

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

Быстрая оптимизация

Процессы редактируются без остановки уже запущенных экземпляров. Изменения вступают в силу сразу после публикации. Платформа поддерживает версионность процессов — можно откатиться к предыдущему состоянию, если что-то пошло не так. Это важно для компаний, у которых одновременно живут десятки «живых» процессов: по оценке ELMA, для компании в 500 человек таких процессов от 50 до 100, и каждый меняется со временем.

Для кого это полезно

• Разработчики и аналитики работают в среде с подсветкой синтаксиса, автодополнением и встроенным отладчиком — TypeScript-сценарии пишутся прямо в интерфейсе. Сторонние библиотеки и внешние системы подключаются через готовые скрипты и вебхуки. Стандартный API открывает возможности для интеграции с любыми внешними сервисами, веб-сайтами и базами данных.
• PM получает полную видимость по задачам и срокам: канбан, мониторинг процессов в реальном времени, автоматические уведомления при просрочке или ошибке. Перераспределение задач при отпусках и болезнях закрывается механизмом замещения — администратор назначает замещающего и выдаёт временные доступы.
• QA-инженеры могут использовать версионность процессов для контроля изменений и отладчик для проверки бизнес-логики до выхода в продакшн.

Что отличает подход

Платформа сочетает Low-code-скорость с гибкостью полноценного кода. Большинство процессов настраивается без программирования, но там, где нужна кастомная логика, TypeScript-сценарии дают полный контроль. Это позволяет аналитикам закрывать задачи самостоятельно, не ставя каждое изменение в очередь к разработчикам.

Версионность и редактирование «на лету» — принципиальная особенность для enterprise: процессы живут годами и постоянно меняются. ELMA365 позволяет управлять этим циклом без остановки операционной работы и без риска сломать уже запущенные экземпляры.

Интеграционная шина покрывает основные корпоративные сценарии: ЭДО через операторов ЮЗДО и Контур.Диадок, CRM с встроенной телефонией и мессенджерами через ChatDesk, КЭДО с электронной подписью, которая полностью легитимна и позволяет убрать бумажные носители.

Техническая база

• Язык сценариев: TypeScript (встроенная IDE с автодополнением и отладчиком)
• Нотация процессов: BPMN 2.0
• API: стандартный REST API для запуска процессов и управления ими из внешних систем
• Интеграции: ЭДО (ЮЗДО, Контур.Диадок), мессенджеры (ChatDesk), телефония, внешние БД и веб-сервисы через вебхуки и скрипты
• Развёртывание: облако (серверы Яндекс), браузерный интерфейс без установки компонентов

Управление и поддержка

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

Т1 Сфера: платформа полного цикла производства ПО

«Сфера» (SFERA — Scaled Framework for Enterprise Resilience and Agility) — платформа для управления разработкой, тестированием, эксплуатацией и поставкой ПО. Более 40 инструментов в одном контуре: таск-трекер, Git-репозиторий, CI/CD-конвейер, хранение артефактов, управление тестированием, мониторинг, документация. Платформа разрабатывается с 2020 года на основе опыта внедрения ИТ-конвейеров в крупнейших российских компаниях, включая банковский сектор.

В реестре российского ПО. Работает на инфраструктуре без выхода в интернет — подходит для закрытых корпоративных контуров. Применяют в enterprise-компаниях с большими ИТ-командами: финансовый сектор, ретейл, телеком, госструктуры. Поддерживает команды от нескольких человек до десятков тысяч специалистов одновременно.​

Как устроена платформа

Управление процессами и задачами

Сфера.Задачи — таск-трекер с настройкой под любую методологию: Agile, Scrum, SAFe, Kanban. Управляет бэклогом, декомпозицией задач, приоритизацией, назначением ответственных и дедлайнов. Закрывает те же сценарии, что Jira, Notion, Trello и Azure DevOps — в одном инструменте.

Сфера.Знания и Сфера.Документы обеспечивают базу знаний и документооборот — аналог связки Confluence + Notion. Здесь хранятся архитектурные решения, регламенты, технические спецификации и всё, что обычно теряется в чатах и почте.​

DevOps-инструментарий

Сфера.DevOps — сквозная автоматизация цикла от написания кода до деплоя. Включает:

• Git-инструмент для хранения, рецензирования и версионирования кода
• CI/CD-конвейер для непрерывной интеграции, тестирования и развёртывания
• Единое хранилище артефактов разработки
• DevOps-сервис самообслуживания для операций первого и второго дня — создание компонентов, сборка, проверка, раскатка

Тестирование

Комплекс инструментов для автоматизированного тестирования встроен в DevOps-конвейер. Поддерживает быстрый и автоматизированный процесс проверки на всех этапах жизненного цикла — от написания тест-кейсов до интеграционного и регрессионного тестирования в пайплайне.​

Мониторинг и эксплуатация

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

Особенность платформы — 3D-дашборды для контроля всех процессов производства ПО. Верхнеуровневый мониторинг детализируется до уровня отдельной команды или стрима: видно, где тормозит пайплайн, где накапливается технический долг, где горят сроки.​

Для кого это полезно

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

Разработчики работают в знакомом Git-workflow с code review, CI/CD-конвейером и хранилищем артефактов — без необходимости настраивать интеграции между десятком разных инструментов. DevOps-сервис самообслуживания сокращает время на рутинные операции: создание компонентов, настройку сборок, деплой.​

QA-инженеры используют встроенный тест-менеджмент в связке с CI/CD — тест-кейсы, автоматизация, отчётность по покрытию в одном контуре.

Что отличает подход

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

Техническая база

• Методологии: Agile, Scrum, SAFe, Kanban​
• Инструменты: таск-трекер, Git, CI/CD, хранилище артефактов, тест-менеджмент, база знаний, документооборот, мониторинг, управление инцидентами​
• Интеграции: существующие системы контроля версий (GitLab и другие), внешние DevOps-инструменты​
• Развёртывание: корпоративный контур без выхода в интернет​
• Реестр: входит в реестр российского ПО​

Управление и поддержка

Платформа разработана совместно с VK, «1С», Лабораторией Касперского и Ростелекомом в рамках дорожной карты «Новое общесистемное ПО». Поддержка охватывает все модули платформы через единый канал. Новые команды могут опираться на встроенный методологический фреймворк для выстраивания процессов производства ПО с нуля.

Comindware Platform: Low-code BPM для автоматизации сложных процессов

Comindware Platform — Low-code BPM-платформа для моделирования, автоматизации и оптимизации бизнес-процессов предприятия. В одной среде работают корпоративная архитектура, процессный движок, кейс-менеджмент, управление данными и интеграции с внешними системами. Процессы описываются в визуальном дизайнере по нотации BPMN, исполняются движком точно в соответствии с моделью — без разночтений при переносе логики из схемы в код.

Среднее время реализации MVP на стороне клиента — 4 недели. Один из подтверждённых кейсов: бизнес-аналитик ABPMP в одиночку автоматизировал процесс обработки заявок за 30 часов, ускорив его в пять раз. Платформа применяется в промышленности, финансовом секторе, ритейле, телекоме, строительстве, медицине и государственных структурах. Среди кейсов нашла проекты для Газпром Авиа, НСПК, UCS, UserGate.

Как устроен процесс работы

Моделирование и автоматизация процессов

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

Управление данными и интерфейсами

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

Событийная оркестрация

Самогенерирующийся REST API развивается вместе с платформой и клиентскими приложениями, оставаясь обратно совместимым. Документирование через Swagger/OpenAPI: разработчики получают подробное описание каждого с примерами и возможностью тестирования на реальных данных без сборки приложения.​

Встроенные коннекторы покрывают стандартные корпоративные интеграции: Git, OpenLDAP/Active Directory, SMTP/IMAP, Exchange, OData (ERP), RabbitMQ/MSMQ, MSSQL/MySQL. Для событийных сценариев поддерживаются вебхуки — обмен данными с Telegram, Viber, JivoSite, телефонией (Novofon, Mango Office), почтовыми сервисами и любыми внешними системами через HTTP.

Для кого это полезно

• Архитекторы и аналитики управляют всей картой процессов компании в одной среде — от верхнеуровневой модели до исполняемых процессов. Изменения вносятся без остановки запущенных экземпляров, логика модели напрямую транслируется в поведение системы без ручной интерпретации.​
• Разработчики работают с самогенерирующимся REST API с Swagger-документацией, встроенными коннекторами к популярным сервисам и возможностью подключать кастомную логику на C#.
• PM получает прозрачность по статусу процессов в реальном времени и аналитику по отклонениям.
• QA и аналитики проверяют логику процессов на моделях до выхода в прод. Изменения можно откатить или протестировать на отдельном контуре.

Что отличает подход

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

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

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

Техническая база

• Нотация процессов: BPMN 2.0
• Языки кастомной логики: C#, N3
• API: самогенерирующийся REST API, документирование через Swagger/OpenAPI​
• Коннекторы: Git, Active Directory/OpenLDAP, Exchange, SMTP/IMAP, OData, RabbitMQ, MSMQ, MSSQL, MySQL​
• Интеграции через вебхуки: Telegram, Viber, JivoSite, Novofon, Mango Office, Unisender, Mailchimp, CRM-системы (Bitrix24, Megaplan, MS Dynamics)​
• Развёртывание: on-premise, частное и публичное облако, гибридная схема​

Управление и поддержка

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

***

Общая закономерность у всех рассмотренных решений одна: экспертиза видна в глубине проработки конкретного слоя. Selectel копает до уровня BIOS/BMC и изучает, как ведёт себя железо под нагрузкой — потому что сами на нём работают. Чек-лист, который стоит держать в голове при выборе инструментов и подрядчиков для сложных задач:

• Есть ли у команды собственный опыт эксплуатации, а не только внедрения
• Можно ли протестировать решение под свой профиль нагрузки до принятия решения
• Насколько глубоко команда может разобраться в проблеме — до первопричины или только до симптома
• Покрывает ли поддержка весь стек или только отдельные его части
• Как решение ведёт себя при изменениях — масштабировании, миграции, обновлениях

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

Почему 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-датасеты, проверяйте на реальном трафике и не забывайте про бюджеты. Так вы сможете доверять зелёному цвету пайплайна снова.

Бэкап данных – это не восстановление

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

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

DRaaS (Disaster Recovery as a Service) строит процесс по-другому. Сервис заранее реплицирует данные в виртуальные машины на резервной площадке, и при отказе основного контура переносит на неё нагрузку в полуавтоматическом режиме.

Поэтому DRaaS закрывает три задачи, которые один бэкап не покрывает:

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

На этапе планирования и при тестировании команда отвечает на вопрос: за какое время сервис снова заработает после сбоя. Этот срок задают заранее, двумя параметрами: RTO и RPO. К ним и переходим.

RTO и RPO – две метрики, от которых всё зависит

Восстановление настраивают вокруг двух параметров, которые важно согласовать с бизнесом, а лучше от него и получить: RPO и RTO.

RTO (Recovery Time Objective) отвечает на вопрос «за какое время сервис должен быть поднят». Это срок, за который системы должны вернуться в работу после отказа. RTO в один час и RTO в одни сутки задают разный сценарий восстановления и разную стоимость.

RPO (Recovery Point Objective) отвечает на вопрос «сколько данных допустимо потерять». Это объём изменений между последней синхронизацией и моментом сбоя. RPO в пять минут означает, что при аварии теряются данные за последние пять минут работы. RPO в сутки означает потерю данных за последние сутки.

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

RTO и RPO зависят не только от провайдера сервиса Аварийного восстановления. На них влияют обе стороны:

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

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

Как это работает организационно-технически

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

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

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

Шаг 2. Репликация. Виртуальные машины основной площадки реплицируются на площадку Linx через VMware Cloud Director Availability. Инструмент делает копию виртуальных машин и поддерживает их в актуальном состоянии.

При этом можно настроить множество параметров, главные из которых:

• На каких типах дисков будут хранится данные. Чем более быстрые, тем дороже хранение.
• В каких сетях (из шага 1) и с какой адресацией будет запускаться сервер.

• Target RPO: чем чаще идёт синхронизация, тем меньше данных теряется при аварии. RPO задают индивидуально под каждую систему. Чем меньше, тем лучше, но можно уткнуться в ограничение канала связи или в рост нагрузки на СХД, поэтому нужен баланс.
• Retention policy: позволяет задать количество возможных точек восстановления и глубину их хранения. Чем больше больше таких точек, тем больше шанса, восстановить не повреждённые/не зашифрованные данные, но это увеличивает занимаемое на хранилище место. Поэтому тоже нужен баланс.

Шаг 3. Тестовое восстановление каждой ВМ.

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

Шаг 4. Настройка очерёдности восстановления.

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

Шаг 5. Переключение (failover и failback). При аварии на основной площадке, представитель Клиента ответственный за запуск плана восстановления заходит на консоль управления Cloud Director Availability и инициирует преднастроенный Recovery Plan (делает failover). ВМ восстанавливаются, инженеры проверяют работоспособность ИТ сервисов, а бизнес пользователи проверяют и подтверждают восстановление Информационных систем.

Если авария на основной площадке устранена, можно запустить reverse replication, чтобы новые данные начали реплицировать с резервной площадки обратно. А потом в спокойном режиме (например в час наименьшей нагрузки) провести failback и переключить нагрузку обратно на основную площадку.

План аварийного восстановления, который реально сработает

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

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

Тестирование строят в несколько этапов:

1. Тестовый запуск. Команда проверяет, что системы стартуют на резервной площадке сразу после репликации и настройки плана. VMware Cloud Director Availability запускает реплику в тестовом режиме, поэтому проверка идёт без влияния на основную площадку.
2. Первое реальное переключение. После теста команда планирует реальный переезд на резервную площадку. Его проводят в нерабочий день или в час наименьшей нагрузки и подключают к проверке как можно больше ролей в компании.
3. Регулярные прогоны. Тестовое переключение проводят раз в месяц, реальное – раз в полгода-год. Регулярность подтверждает, что план продолжает отрабатывать по мере изменений в инфраструктуре.

План устаревает вместе с инфраструктурой. Любое изменение в критичных системах либо не затрагивает план, либо требует обновить его сразу. Чтобы шаг не терялся, пункт про обновление DRP добавляют в стандартный шаблон Change request. Тогда план обновляется в момент изменения, а не задним числом после сбоя.

Где всё это разворачивать

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

В случае с услугой Аварийное восстановление (DRaaS) от Linx Cloud Клиент получает резервную площадку в облаке, а также получает инструмент для репликации и восстановления VMware Cloud Director Availability. RPO задаётся под каждую систему, переключение запускается с веб-портала. Подключение идёт по анкете: команда указывает количество виртуальных машин, объём данных и ресурсы (CPU, RAM), получает доступ к порталу и инструкции. Сервис работает в двух сценариях:

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

Проверить схему можно до оплаты: Linx даёт бесплатный тест-драйв на 14 дней, чтобы прогнать тестовое переключение и сверить результат с целевыми параметрами. Условия и подключение на странице DRaaS Linx Cloud.

Итого

Аварийное восстановление настраивают до сбоя, а не во время него. Бэкап сохраняет данные, но не возвращает сервис в работу. Для этого нужна реплика на резервной площадке и заранее настроенное переключение. Параметры RTO и RPO задают рамку: за какое время поднять сервис и сколько данных допустимо потерять. Репликация держит копию инфраструктуры в актуальном состоянии, план фиксирует порядок подъёма систем, регулярный тест подтверждает, что план срабатывает.

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

Рувеб — 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 в одном аккаунте, но баланс цены, удобства, лицензий и инфраструктурных возможностей у каждого свой. Перед выбором советуем проверить тестовый период или минимальный депозит и протестировать сценарии, критичные для вашего проекта.

• Виртуальный хостинг — сайты соседствуют на одном сервере, управляет провайдер. Дешёвый старт, но ограниченная конфигурация.
• 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. Перед покупкой всегда берите тестовый период и проверяйте реальную производительность под вашей нагрузкой.

Выход — поднять собственное 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.

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

С фичами всё прозрачно: написал код — увидел результат на экране. Быстрая и понятная обратная связь. Но со временем замечаешь, что проблемы повторяются. Приложение тормозит не из-за плохого кода, а потому что на один экран уходит пять-шесть сетевых вызовов. Логика на клиенте. Хочешь что-то изменить — готовь релиз, проходи App Store Review и жди недели, пока обновление дойдёт до всех.

Я перешёл в Android-инфраструктуру — начал делать инструменты для других мобильных разработчиков. Это помогло увидеть: главные проблемы не в фичах, а в слое между приложением и бэкендом.

Возвращаться к фичам стало неинтересно. В инфраструктуре задачи сложнее, результат измеряется метриками — latency, error rate, скорость релизов, — а влияние на всю систему, а не на один экран.

Что Android даёт для инфраструктуры — а чему учиться с нуля

Мобильный бэкграунд оказался не балластом, а преимуществом. Я понимал ограничения изнутри. Backend-инженер может прочитать, что мобильные сети ненадёжны, память ограничена, а батарея — критичный ресурс. Но прочитать и прочувствовать — разное. Я годами наблюдал, как приложение “захлёбывается” на устройствах среднего сегмента. Знал, что 60% пользователей сидят именно на таких. Видел, как баг, который мы починили за день, продолжает висеть у людей неделями — просто потому, что они не успели обновиться.

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

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

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

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

Что делать, если один из пяти сервисов не ответил? Как понять, что мы катимся к инциденту, до того, как пользователи начнут жаловаться?

Этому в мобильной разработке не учат.

Как я учился: пробелы, сроки и смена мышления

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

Учился итеративно, не пытаясь объять необъятное сразу. Gateway начинался как простой прокси. Затем добавили агрегацию ответов, потом — конфигурационные определения экранов. Каждый такой шаг вынуждал осваивать следующий уровень: circuit breakers, стратегии повторов, observability, планирование мощностей.

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

Что означает «выдающийся уровень» в инфраструктуре

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

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

Затем — миграция живой системы, где права на ошибку практически нет. Приложение нельзя выключить или отрепетировать в реальном масштабе. Остаётся только постепенный перевод трафика: shadow mode → 1% → 5% → 25% → 50% → 100%, с автоматическим откатом при любом росте ошибок. И всё это — пока миллионы пользователей активно работают с продуктом, не подозревая, что под капотом идёт замена двигателя на ходу. Такой уровень дисциплины и инструментации приходит только с практикой.

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

Почему путь в инфраструктуру доступнее, чем кажется?

Карьерные траектории в инфраструктуре редко бывают чётко описаны. Здесь нет готового чек-листа в духе «диплом по Computer Science, пять лет в бэкенде, обязательное знание Kafka и Kubernetes». С одной стороны, такая неопределённость пугает. С другой — именно она и делает этот путь более доступным, чем принято думать.

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

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

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

Мобильный бэкграунд как преимущество архитектора

Считаю ли я, что мобильный опыт сделал меня лучшим архитектором для mobile-first продуктов? Безоговорочно, да.

Я помнил, как ощущается медленный экран на устройстве среднего сегмента. Помнил, что случается, когда API возвращает слегка неправильные данные и приложение падает при парсинге. Помнил то чувство, когда баг уже в проде, а ты ждёшь App Store Review и ничего не можешь исправить.

Поэтому когда я проектировал gateway, я не занимался абстрактной «оптимизацией перформанса». Я опирался на совершенно конкретный опыт. Знал, что убрать один сетевой round trip — это подарок каждому мобильному разработчику. Знал, что перенос логики на сервер означает перенос в место, где я могу починить всё за минуты, а не за недели.

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

Коротко: что делать, если думаете о переходе

• Найдите промежуточный шаг. Не прыгайте сразу в бэкенд. Начните с задач на стыке: оптимизация API, инструменты для мобильных разработчиков, улучшение сетевого слоя.
• Используйте мобильный контекст как рычаг. Вы понимаете то, о чём бэкенд-инженеры только догадываются. Говорите об этом вслух.
• Учитесь измерять невидимое. В инфраструктуре результат — это метрики: latency, error rate, скорость релизов. Учитесь рассказывать историю через цифры.
• Проектируйте под отказ, а не тушите пожары. Senior-уровень — это определить, что сломается и кто за это отвечает, до того, как оно сломается.
• Не ждите разрешения. Путь не размечен, но он открыт. Начните с малого — и двигайтесь туда, где задачи становятся интереснее.

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

• Cloud.ru запустила Evolution Stack.ML — платформу для обучения ИИ-моделей в частном и гибридном облаке.
• В основе лежит сервис Evolution Distributed Train: обучение, тюнинг, развёртывание моделей и совместная работа команд.
• Платформа поддерживает изолированные рабочие пространства для более чем 200 команд одновременно.
• По заявлению компании, утилизация GPU растёт с 35% до 90%, а окупаемость серверных мощностей составляет менее 3 месяцев.

Что умеет платформа

Ядро продукта — сервис Evolution Distributed Train. Он объединяет инструменты для разработки, управления экспериментами и мониторинга в единую экосистему. Пользователи могут запускать изолированные рабочие пространства для более чем 200 команд одновременно.

Для распределения нагрузки используются механизмы очередей, приоритетов, аллокаций и спотов. По данным Cloud.ru, это позволяет поднять утилизацию GPU с 35% до 90% и окупить затраты на серверное оборудование менее чем за 3 месяца. Совместное использование кластеров, по оценке компании, ускоряет обучение и разработку новых ИИ-решений на 20%.

Встроенные механизмы self-healing автоматически обнаруживают сбои оборудования, перезапускают задачи и заменяют GPU-ноды. OSS-слой платформы Cloud.ru позволяет отслеживать загрузку инфраструктуры и контролировать расходы.

Evolution Stack.ML помогает преодолеть барьеры для внедрения ИИ в крупном бизнесе и государственных компаниях — решение соответствует строгим требованиям к безопасности и нормам регуляторов. Evolution Stack.ML повышает экономическую эффективность использования собственного «железа» и при этом даёт доступ к самым современным технологиям и методам работы с ИИ.

Для кого это

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

Cloud.ru также ссылается на собственное исследование: в России растёт спрос на гибридные сценарии. Среди наиболее востребованных — обработка данных и использование ИИ, разработка и тестирование в облаке, георезервирование и disaster recovery.

Выводы

Запуск Evolution Stack.ML — попытка Cloud.ru закрыть спрос на корпоративное ИИ-обучение с соблюдением регуляторных ограничений. Если заявленные цифры подтвердятся в реальных внедрениях, платформа может стать интересной альтернативой самостоятельной сборке инфраструктуры для машинного обучения.

Источник: пресс-служба Cloud.ru.

Реклама. Рекламодатель: ООО «Облачные технологии», ИНН 7736279160, erid: 2W5zFHcxyBP

Компания 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. Материал подготовлен как авторская переработка идеи с добавлением российского контекста и практических рекомендаций.

Написать оператор можно на 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 и контроллеров.

Не магическая кнопка, а десятки экспериментов

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

«ИИ — это не какая-то магическая кнопка, на которую ты нажимаешь, и всё становится красиво и хорошо».

За каждым запуском стоят данные, сотни экспериментов и огромная инженерная работа.

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

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

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

А еще Wildberries запускает автопереводы карточек товаров для других стран — руками это сделать невозможно из-за объемов.

Внутри компании ИИ тоже активно используется. У Wildberries есть, например, AI-агент DPO, который проверяет, что лежит в больших хранилищах данных. «Он заменил целый пласт ручной работы с разметкой. Мы его сделали, попробовали, отдали безопасникам — и теперь это работает в зоне их ответственности», — рассказывает Павел. А еще есть собственные кодинг-ассистенты, инструмент для автоматического ревью кода (им пользуются около 200 команд).

«Колесо сансары замкнулось — программисты разрабатывали ИИ, и он начал их заменять», — смеется Юрий Софронов, руководитель направления моделей и сервисов для ИИ-ассистентов в RWB.

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

Где заканчивается магия и начинается автоматизация

Первый технический блок митапа начался с неожиданного признания. Руководитель ML-платформы Даниил Понизов и MLOps-инженер Роман Лазовский из RWB рассказывали о внедрении AIOps-практик, но их главный вывод звучал почти издевательски: AI в AIOps-платформе оказался практически бесполезен.

Как это вообще могло случиться?

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

Команда выбрала KeepHQ — единственную на тот момент open-source AIOps-платформу. Развернули, настроили интеграцию с Grafana, сделали бота в мессенджере, который ведет диалог с владельцами сервисов. Система дедуплицирует алерты (из почти 400 тысяч событий схлопывается 99%), обогащает их контекстом и автоматизирует рутину. Результат впечатляет: на одном из кластеров утилизация GPU выросла на 62%.

Ирония, которая стоит особняком

Когда платформа называется AIOps, ожидаешь, что искусственный интеллект будет играть в ней ключевую роль. На практике выяснилось, что в open-source версии KeepHQ AI-функции крайне ограничены. Встроенный LLM-провайдер из коробки не заработал — пришлось патчить ролевую модель. AI-ассистент для построения воркфлоу помогает генерировать YAML, но это просто ускоритель, а не интеллект.

«AIOps в нашем случае — это автоматизация мелких ручных действий, — резюмирует Даниил. — AI-фичи, доступные из коробки, нам пока не помогли. Мы уже разрабатываем отдельного AI-агента, который будет мониторить алерты из KeepHQ, а также обогащать их контекстом из других инструментов, чтобы автоматически заводить инциденты и открывать мердж-реквесты с предложениями по оптимизации ресурсов в сервисах».

Вывод, который стоит вынести из этого опыта: open-source решения для AIOps удобны, но будьте готовы патчить всё — от Python-степов до LLM-провайдеров. И главное — не ждите, что AI решит ваши проблемы с утилизацией. Сначала выстройте прозрачный процесс, а потом уже его автоматизируйте.

Хорошая модель не спасет: данные, код и железо решают всё

Юрий Софронов, руководитель направления моделей и сервисов для ИИ-ассистентов в RWB, разобрал самый опасный стереотип: заказчики думают, что если дать им «хорошую модель», всё заработает само. На самом деле LLM-продукт — это сложная система. Юрий выделяет как минимум три слоя: данные, код и железо, и без проработки каждого модель бесполезна.

«Никому не нужен чат-бот, который думает по 20 минут, — объясняет Юрий. — Модель без дополнительного контекста — это просто очень сложный вычислительный инструмент, который умеет генерировать токены и ничего не знает про ваш бизнес и вашего пользователя. Чтобы появился LLM-продукт, нужно воспринимать его как атомарную, неделимую сущность. Это огромный каскад и технических, и продуктовых решений».

Слой данных

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

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

Сработал агент под названием «Водолаз». Он раз в сутки анализирует весь контент карточки — вопросы, отзывы, обсуждения — и извлекает из него факты, которых нет в официальном описании товара. «Подошва не скользит зимой», «хорошо держит тепло» — такие факты складываются в понятную для LLM key-value структуру и индексируются.

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

Вывод прост: не пытайтесь скормить LLM сырой контекст. Приведите данные в порядок до того, как отдадите их модели. LLM не чинит данные — она только усиливает существующий хаос.

Слой кода

Здесь Юрий был категоричен. Low-code инструменты типа LangChain — это зло для продакшна.

«Благодаря своей универсальности эти инструменты не оптимизированы. Разбирая реализацию LangChain, ты попадаешь в пять-семь слоев абстракций, неэффективно реализованные компоненты».

Где их можно использовать? Для прототипов, демо заказчику, тестирования на малой группе пользователей. Но определенно не в продакшне.

«Если кто-то в WB собирается запускать клиентские продукты на таких технологиях, как LangChain, я сильно протестую и готов всеми силами это остановить».

Альтернатива, по мнению Юрия, — разделить систему на прозрачные слои: API, роутер сценариев, сборщики контекста, саму LLM, пост-процессинг. И использовать vLLM или Triton вместо нативного PyTorch. Базовая интеграция без оптимизаций дает буст в 10–15 раз по сравнению с Transformers.

Живой пример из практики Wildberries: готовая к запуску продовая инфра с 48 GPU на end-to-end тестировании функционала в приложении показывает такие же метрики производительности, что и на 4 GPU. Производительность идентична, хотя разница в ресурсах в 12 раз! Причина оказалась не в GPU и не в модели, а в ingress-слое — стояли дефолтные лимиты на количество соединений, которые буферизовали ответы. Кодовая инфраструктура заруинила отличную GPU-инфраструктуру.

Слой железа

Самая недооцененная часть LLM-продуктов. Классический L7-балансировщик балансирует сетевой трафик, но сетевой запрос не равен нагрузке на GPU. Две одинаковые ноды с одной моделью могут отвечать с совершенно разной скоростью, одна может работать в штатном режиме, другая — зациклиться в генерациях или повлечь за собой ошибку на уровне железа. Что работает вместо этого:

• Token-aware routing — оцениваем количество токенов, не отправляем тяжелый запрос на загруженную ноду.
• KV-cache routing — используем уже посчитанный кэш на той же ноде, где он был. Трехкратный выигрыш по latency.
• Спекулятивный роутинг — кидаем запрос на две-три ноды, берем самый быстрый ответ. Ускоряет ответ на 15–25%, снижает 95-й перцентиль latency на 15%.

Когда ИИ — это переплата, а когда — полезный помощник

На панельной дискуссии встретились представители Альфа-Банка, Сбера, RWB, red_mad_robot.

Где ИИ не нужен

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

Красные флаги, которые заставляют команды отказываться от ИИ-решений, тоже довольно очевидны. Когда:

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

Что важнее — модель или обвязка?

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

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

Про деньги и веру

Честный разговор об экономике получился, пожалуй, самым интересным. Экономика LLM-проектов часто не сходится. Но есть нюансы.

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

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

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

Серебряной пули действительно не существует

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

Всё, что работает в промышленном ИИ, работает потому, что за этим стоит тяжелая, нехайповая инженерная работа. И в этом, наверное, главный урок Inside AI Meetup для тех, кто собирается внедрять ИИ завтра.

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

«Я недавно читал статью в Vogue "Can AI Ever Crack Taste?", — вспоминает Юрий Софронов. — Единственное, чего сейчас нет у ИИ — это вкуса. Я иногда смотрю на сгенерированный текст или картинку и чувствую, что что-то не так. Человек здесь по-прежнему далеко впереди».

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

Время: 11:00 мск

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

Многие ИТ-директора уверены, что если у них настроены бэкапы, то бизнес под защитой. Однако исследование Global CIO и Linx Cloud показывает обратное: большинство ИТ-руководителей путают наличие бэкапов с реальной отказоустойчивостью. 85% респондентов уже сталкивались с необходимостью восстановления из бэкапов, но в 35% случаев это привело к длительному простою или безвозвратной потере данных. Более того, даже после успешного отражения атаки критически важные процессы запускаются лишь через 3–4 дня, на полное восстановление IT-систем уходят до 2 недель, а на возврат к штатному режиму — месяцы.

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

Приглашаем руководителей бизнеса, руководителей ИТ-подразделений, ИT-специалистов на вебинар, посвящённый построению надёжной системы резервного копирования и аварийного восстановления (Disaster Recovery).

На вебинаре вы узнаете:

• какие ошибки совершают 80% компаний при организации бэкапов и почему это приводит к потере данных;

• как спроектировать DR-план, который действительно работает, а не пылится на полке;

• как минимизировать простои и финансовые потери за счёт правильной архитектуры резервного копирования.

Программа вебинара:

11:00 – 11:20

Исследование LinxCloud и GlobalCIO: "Отказоустойчивость крупного и среднего российского бизнеса в 2026 г." Разбор ошибок

• Цифры и факты: 42% компаний не имеют DR-плана, 29% хранят бэкапы в том же здании

• Угрозы реальны: 85% сталкивались с необходимостью восстановления, но в 35% случаев это привело к длительному простою или потерям данных.

11:20 – 11:40

Резервное копирование: как делать не надо. Disaster Recovery: когда бэкап — это ещё не всё

• Типы бэкапов: агентские и безагентские — что, когда и зачем.

• Правило 3-2-1 на практике: почему его соблюдают только 17% организаций и что с этим делать.

• Неуязвимость: помогут ли immutable бэкапы от шифровальщиков?

• Облачный бэкап: как не держать резервные копии на тех же полках, что и основные данные, и не платить за лишнее «железо».

• DR vs бэкап: чем отличается восстановление данных от восстановления бизнес-системы. Заменяет ли одно другое?

• Ключевые метрики RPO и RTO: как рассчитать для разных классов систем без лишней сложности.

11:40 – 12:00

От бэкапа к работающему DR: практические ошибки, метрики и чек-лист готовности

• Почему наличие бэкапов не равно готовности к восстановлению;

• Какие ошибки чаще всего мешают восстановить бизнес-системы в приемлемые сроки;

• Как правильно смотреть на RPO и RTO для разных классов систем;

• Какие элементы должны быть в рабочем DR-плане;

• Как тестировать восстановление, чтобы не обнаружить проблемы уже во время аварии;

• Какой чек-лист можно использовать для быстрой оценки готовности инфраструктуры

12:00 – 12:30

Дискуссия, ответы на вопросы

Спикеры:

• Евгений Макарьин, руководитель продуктового направления DR LinxCloud

• Александр Шукевич, директор по продажам Хайстекс

Реклама. Рекламодатель: ООО «Связь ВСД», ИНН 7713339141, erid: 2W5zFHoMCx1

Проблема в том, что 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С — критичная система и нужна доказанная производительность, смотрите на специализированные кластеры. Если важнее экосистема сервисов или быстрый старт — выбирайте по задачам.

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

ТОП-10 игровых хостингов в 2026 году

1. Hostingrust — специализация на survival-играх (Rust, ARK, DayZ, Conan Exiles), кастомизированная AntiDDoS Game защита, ЦОДы в Москве и Новосибирске.
2. XLGAMES — универсальный хостинг с одним из самых широких каталогов игр на рынке, дата-центры уровня Tier III в России, Финляндии и Германии.
3. Hosting-Minecraft — узкоспециализированный сервис под Minecraft на топовом железе (Ryzen 9 9950X, DDR5), тарифы от 39,90 руб./мес.
4. MyArena — ветеран рунета с 2009 года, собственный ЦОД в Москве, фокус на CS2, Minecraft и SAMP.
5. WorldHosts — современное железо Ryzen с бустом до 5.7 GHz, мобильная панель, Telegram-бот и гарантия TPS 20 для Minecraft.
6. RU VDS — крупный VDS-провайдер из топ-20 IaaS России, 22 дата-центра в 9 странах, Minecraft из маркетплейса в один клик.
7. Maze Host — бюджетный хостинг на инфраструктуре OVH (Франция), специализация на SAMP/CRMP/MTA, предусмотрен бесплатный тариф.
8. DS-HOST — доступный провайдер с 2012 года, упор на SAMP/CRMP/CS2/Minecraft, тестовый период 3 дня.
9. EveHost — олдскульный хостинг в ЦОД «Ростелеком» (Москва), модель оплаты за слот, фокус на классике: SAMP, MTA, CS 1.6, Minecraft Bukkit.
10. ApexMinecraftHosting — зарубежный премиум-сервис (входит в Nitrado), 15+ ЦОД по миру, 200+ модпаков в один клик.

1. Hostingrust

Российский игровой хостинг, заточенный под survival-жанр. Rust, ARK: Survival Evolved, DayZ, Conan Exiles, Unturned, Palworld, 7 Days to Die, Valheim — все, что связано с выживанием на враждебных серверах, здесь оптимизировано на уровне ядра. Дата-центры расположены в Москве и Новосибирске — две точки, которые покрывают центральную и азиатскую часть России с приемлемым пингом. Железо — Intel i7/i9 и AMD Ryzen, хранилище на NVMe SSD. Отдельная гордость провайдера — кастомизированная AntiDDoS Game защита, которая фильтрует и сетевой трафик (L3/L4: UDP-флуд, SYN/ACK, DNS/NTP-amplification), и прикладной уровень (L7).

Цена. Rust — от 990 руб./мес. (50 слотов, 8 ГБ RAM), ARK — от 1 100 руб., DayZ — от 1 000 руб., Conan Exiles — от 1 200 руб.

Плюсы:

• Узкая специализация на survival-играх: оптимизация и техподдержка заточены именно под этот сегмент.
• Два ЦОДа — Москва и Новосибирск — обеспечивают низкий пинг для аудитории от Калининграда до Красноярска.
• DDoS-защита покрывает и сетевой (L3/L4), и прикладной (L7) уровни — редкое сочетание в этом ценовом сегменте.
• Бесплатный перенос сервера со старого хостинга — миграция без потери данных и настроек.

Минусы:

• Survival-only: для других игр придется кастомизировать VDS.
• Ежедневное резервное копирование — платное дополнение, а не часть базового тарифа.
• Установка сервера после оплаты занимает до 24 часов — не мгновенная активация.

2. XLGAMES

Противоположный подход: вместо узкой специализации — максимально широкий охват. В каталоге комфортно расположились мейнстримные Minecraft и CS2, нишевые V Rising и Mordhau, и совсем экзотические Farming Simulator и Among Us — XLGAMES является редким провайдером, у которого хватает ресурсов поддерживать такой разброс. Серверные площадки распределены по трем странам (несколько точек в РФ, а также Финляндия и Германия), инфраструктура отвечает стандарту Tier III. Вычислительная база — процессоры Intel Core 12-14 поколений и AMD Ryzen, накопители NVMe, гигабитный канал. Помимо игровых серверов — VPS/VDS и веб-хостинг для клан-сайтов.

Цена. Minecraft — от 1 490 руб./мес. (8 ГБ RAM, 30 ГБ NVMe), CS2 — от 330 руб./мес. за 10 слотов, SAMP — от 5 руб./слот.

Плюсы:

• Один из самых широких каталогов игр, включая редкие тайтлы вроде Mordhau и Farming Simulator.
• Три страны размещения (Россия, Финляндия, Германия) — пинг оптимизируется под географию аудитории.
• Tier III — стандарт надежности с резервированием питания и охлаждения.
• Возврат средств в течение 5 дней, если услуга не подошла.

Минусы:

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

3. Hosting-Minecraft

Название говорит само за себя: только Minecraft — зато с железом, которое у конкурентов встречается разве что в премиум-тарифах. AMD Ryzen 9 9950X и 7950X3D с разгоном до 5.7 GHz, память DDR5 5600 MHz — для Minecraft с тяжелыми модпаками частота ядра критична, и здесь она на уровне энтузиастического десктопа. Защита — DDoS-Guard уровней L3/L4 без ограничений по количеству доменов на VPS-тарифах. Локация — Москва. Отдельная деталь: на сайте переключаются валюты оплаты (RUB, EUR, UAH, USD) — удобно для команд с участниками из разных стран.

Цена. Хостинг Minecraft Standart — от 39,90 руб./мес. VPS/VDS на Ryzen 9 9950X — от 807,50 руб./мес.

Плюсы:

• Топовое железо: Ryzen 9 9950X/7950X3D и DDR5 — редкое сочетание в этом ценовом диапазоне.
• Минимальный порог входа — от 39,90 руб./мес. за стартовый тариф.
• DDoS-Guard уровня L3/L4 без ограничений по доменам.
• Переключаемые валюты (RUB/EUR/UAH/USD) — гибкость для интернациональных команд.

Минусы:

• Игровая специализация — исключительно Minecraft; под другие тайтлы придется брать VPS и настраивать вручную.
• Готовые сборки ограничивают тех, кто планирует нестандартный сетап.
• На младших тарифах за дополнительные слоты взимается отдельная плата.

4. MyArena

Шестнадцать лет непрерывной работы — с 2009 года — и за это время MyArena выстроила вокруг себя замкнутую экосистему: дата-центр в столице, фирменная панель администрирования и DDoS-фильтрация, спроектированная под специфику игрового трафика. Перечень поддерживаемых тайтлов охватывает и классику (CS 1.6, CS: Source, Team Fortress 2, GTA SAMP), и актуальные проекты (CS2, Minecraft, Rust, Left 4 Dead 2). Также здесь можно заказать VPS/VDS, веб-хостинг, выделенные, а также голосовые серверы TeamSpeak 3. Встроенные инструменты: статистики HLstatsX:CE и PsychoStats, системы банов AmxBans и SourceBans, Fast Download.

Цена. Стандартный игровой тариф — от 150 руб./мес., CS 1.6 — от 700 руб./мес., Left 4 Dead 2 — от 224 руб./мес.

Плюсы:

• Более 15 лет опыта и собственный дата-центр в Москве — многолетняя история стабильной работы.
• DDoS-защита, разработанная специально под паттерны игрового трафика.
• Готовый набор инструментов: статистики, системы банов, Fast Download — в базовой комплектации.
• Тарифная гибкость.

Минусы:

• Ценник выше, чем у бюджетных конкурентов, — плата за «всё включено».
• Серверы расположены только в Москве — пинг для Дальнего Востока и Сибири ощутимо выше.
• Не все пользователи довольны качеством поддержки в нестандартных ситуациях.

5. WorldHosts

Провайдер существует с 2014 года, а в 2020-м прошел масштабное обновление инфраструктуры — и именно после него начал набирать аудиторию. Ставка сделана на два козыря: железо уровня энтузиастического десктопа (Ryzen свежего поколения, буст 5.7 GHz, NVMe) и удобство администрирования (панель адаптирована под смартфоны, установка модификаций — за одно касание, плюс Telegram-бот для мониторинга без захода в панель). Каталог широкий: Minecraft (Java, Bedrock), CS 1.6/Source/CS2, Rust, DayZ, L4D2, TF2, MTA, SAMP, Valheim, ARK, Killing Floor 2, Garry's Mod, 7 Days to Die. Отдельный аргумент для владельцев Minecraft-серверов — гарантия стабильного TPS 20: мир тикает с эталонной частотой без серверных лагов.

Цена. Доступные базовые тарифы; библиотека из более чем 30 000 плагинов в панели.

Плюсы:

• Современное железо: Ryzen с бустом 5.7 GHz и NVMe SSD — на уровне энтузиастических сборок.
• Мобильная панель управления — полноценное администрирование с телефона.
• Telegram-бот для мониторинга и управления сервером в реальном времени.
• Гарантия TPS 20 для Minecraft — эталонная частота тиков без просадок.

Минусы:

• Хостинг относительно молодой — меньше публичной истории и независимых обзоров, чем у ветеранов.
• Среднее время ответа техподдержки — около 30 минут; не мгновенная реакция.
• Основной упор на популярные онлайн-тайтлы; экзотических игр в каталоге нет.

6. RU VDS

Классическим игровым хостингом RU VDS не является — это один из крупнейших VDS-провайдеров страны (топ-20 IaaS, отмечен званием «Хостер года 2023» от Премии ЦОДы.рф, инфраструктура аттестована по ФСТЭК). Арендатор получает виртуальную машину с полным root-доступом и сам определяет, что на ней запускать. Для опытных администраторов это идеальный формат: любая ОС, любое ПО, любой игровой сервер. Для Minecraft есть исключение: разворачивается из маркетплейса в один клик без ручной настройки. 22 дата-центра уровня Tier III в 9 странах: Москва (включая ММТС-9), Санкт-Петербург, Казань, Екатеринбург, Новосибирск, Швейцария, Великобритания, Германия, Нидерланды, Казахстан. Каналы по 10 Гбит/с.

Цена. VPS Старт — от 139 руб./мес. Бесплатный тестовый период 3 дня для конфигураций до 3 000 руб.

Плюсы:

• 22 дата-центра в 9 странах — география, которой с большой вероятностью не предложит ни один нишевой игровой хостинг.
• Трехдневный тестовый период для конфигураций до 3 000 руб. — реальная проверка до оплаты.
• DDoS-защита первый месяц бесплатно.
• Minecraft из маркетплейса в один клик — единственное исключение из правила «настраивай сам».

Минусы:

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

7. Maze Host

Бюджетный хостинг для игр, исторически сильный в нише SAMP, CRMP и MTA — тройке, которая по-прежнему собирает стабильную аудиторию в рунете. Также в каталоге — CS 1.6, CS: Source, CS2 и Minecraft (Java, Bedrock). Помимо игровых серверов, предлагаются VPS/VDS на KVM, а также обычный веб-хостинг. Помимо российских площадок, есть локация во Франции в дата-центре OVH — одного из крупнейших европейских провайдеров инфраструктуры. Модель оплаты — по слотам.

Бесплатный период, на котором запускается реальный сервер с ограниченными ресурсами — от 5 дней с возможностью продления до месяца в зависимости от игры. Это дает низкий порог входа для запуска тестового SAMP-, CRMP- или CS-сервера до оплаты.

Цена: бесплатный тариф; платные — от низких ставок за слот.

Плюсы:

• Бесплатный тариф и тестовый период — порог входа буквально нулевой.
• Автоматическая установка готовых модов и сборок для SAMP/CRMP/MTA.
• Бесплатная база данных MySQL на каждом тарифе.
• Инфраструктура OVH — масштаб и серьезная защита от DDoS на уровне магистральных каналов.

Минусы:

• Если выбрать дата-центр OVH во Франции, пинг для игроков из России будет заметно выше.
• Сильная сторона — нишевые тайтлы; для Valheim, ARK или Palworld предложений нет.
• Часть интерфейса и автодокументации заметно устарела.

8. DS-HOST

Тринадцать лет на рынке (старт в 2012-м) и четкое позиционирование: SAMP, CRMP, CS2, Minecraft — без попыток охватить весь каталог Steam. Сильная сторона — инструментарий, который экономит время администратору. Консоль подсвечивает ошибки прямо в веб-интерфейсе, планировщик берет на себя рутину (перезагрузки по таймеру, выполнение команд по расписанию), а откат к бэкапу занимает один клик, а не полчаса работы с FTP. Хранилище — NVMe, защита от DDoS-атак — на каждой локации без доплаты. Для первого сервера, когда SSH вызывает оторопь, — один из самых комфортных вариантов в подборке.

Цена. Игровые серверы SAMP — от 200 руб./мес. Тестовый период — 3 дня.

Плюсы:

• Более десяти лет на рынке — устоявшийся провайдер с предсказуемым качеством.
• Бесплатный тестовый период 3 дня — пинг и стабильность проверяются до оплаты.
• Полная консоль с подсветкой ошибок прямо в панели управления.
• Планировщик задач: автоматические рестарты и регулярные команды по расписанию.

Минусы:

• Каталог поддерживаемых игр заметно уже, чем у универсальных провайдеров.
• Сайт работает на двух доменах (ds-host.ru и ds-host.su) — навигация иногда сбивает с толку.
• Дизайн и UX панели управления проще, чем у более молодых конкурентов.

9. EveHost

Олдскульный хостинг серверов для игр работает с 2011 года и сделал ставку на инфраструктуру Ростелекома: серверные мощности расположены в московском ЦОДе оператора, а магистральные каналы РТКоММ обеспечивают предсказуемую задержку по центральной части страны. Трафик фильтруется через Arbor Peakflow SP — промышленную систему очистки, которой пользуются финансовый и телеком-секторы. SAMP, CRMP, MTA, Minecraft Bukkit, CS 1.6, CS: Source — в каталоге представлена классика. Модель оплаты — по слотам: удобно для небольших серверов и тестовых проектов, где платить за фиксированный пакет ресурсов невыгодно.

Цена. Minecraft — от 12 руб./слот, MTA — от 3 руб./слот.

Плюсы:

• ЦОД «Ростелеком» в Москве и магистральные каналы РТКоММ — надежная инфраструктура и стабильный пинг.
• Промышленная DDoS-защита Arbor Peakflow SP — уровень, которым оперируют финансовые и телеком-компании.
• Модель «за слот» удобна для маленьких серверов и тестов — платите только за то, что используете.
• Более десяти лет работы — устоявшаяся репутация и предсказуемый сервис.

Минусы:

• Каталог строго ограничен классикой: Rust, ARK, Valheim, Palworld и другие современные тайтлы не поддерживаются.
• Сайт и панель управления выглядят заметно устаревшими по меркам 2026 года.
• Аппаратные ноды частично работают на процессорах AMD Opteron и Intel Xeon предыдущих поколений — для тяжелых модпаков это ограничение по производительности.

10. ApexMinecraftHosting

Зарубежный премиум-провайдер с фокусом на Minecraft, на рынке с 2013 года. В 2021-м вошел в группу Nitrado — одного из крупнейших игровых хостеров в мире. Помимо Minecraft (Java и Bedrock), поддерживает ARK, Rust, Valheim, Project Zomboid, Terraria, Palworld, 7 Days to Die. Свыше 100 000 клиентов в 70+ странах, 15+ ЦОД по миру: США, Канада, Бразилия, Великобритания, Франция, Германия, Сингапур, Австралия. Кастомизированная Multicraft-панель с one-click установкой более 200 модпаков. Топовый тариф EX Series — Ryzen 9 7950X, 16 ГБ DDR4, NVMe.

Цена. От $7,49/мес. за 1 ГБ RAM; 4 ГБ — $14,99; 6 ГБ — $22,49; 8 ГБ — $27,99. Безлимитные слоты на всех тарифах.

Плюсы:

• Установка более 200 модпаков в один клик — один из самых обширных каталогов в мире.
• 15+ локаций ЦОД по всему миру — пинг оптимизируется под любую географию.
• Живой чат 24/7 с агентами, которые специализируются именно на Minecraft.
• Безлимитные слоты на всех тарифах и 7-дневная гарантия возврата средств.

Минусы:

• Нет ЦОД в России — для российских игроков пинг выше, чем у локальных провайдеров.
• Премиальный ценник: заметно дороже большинства российских аналогов.
• Сайт и поддержка — на английском, оплата в долларах.

Для чего нужен игровой хостинг

Четыре сценария — четыре разных набора требований.

Сервер для друзей

Пятеро-двадцать человек хотят играть вместе, без посторонних. Самый очевидный вариант — запустить сервер на домашнем ПК. Но через пару вечеров проблемы становятся предсказуемыми: машина не справляется с нагрузкой (особенно если на ней параллельно работает браузер и Discord), NAT и проброс портов превращаются в отдельный квест, никакой защиты от DDoS нет, а стоит хозяину выключить компьютер — сервер гаснет вместе с ним. Даже для маленькой компании хороший игровой хостинг экономит нервы: сервер работает 24/7, друзья заходят когда хотят, и ничего не ломается от обновления Windows.

Публичный игровой проект

Minecraft с десятками плагинов, ролевые SAMP/CRMP-серверы, Rust с кастомными картами. Здесь на кону не вечер с друзьями, а комьюнити, которое строилось месяцами. Критичны: защита от DDoS (публичные серверы атакуют регулярно), мониторинг ресурсов, системы банов, статистика, автоматические бэкапы и быстрая поддержка, когда что-то падает в три часа ночи.

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

Киберспортивные серверы

Турниры по CS2, фан-ладдеры, тренировочные площадки. Требования жестче: пинг стабильный и низкий, джиттер близкий к нулю, выделенный IP, защита от DDoS уровней L3/L4 — киберспорт регулярно становится мишенью целенаправленных атак.

Тестовые окружения для разработчиков

Создатели модов и плагинов нуждаются в полигоне для отладки: полный доступ по FTP/SFTP, root в случае VPS, гибкая смена версий ядра и возможность откатиться к бэкапу за секунды. Панель управления с файловым менеджером и веб-консолью экономит часы по сравнению с чистой командной строкой.

Виды хостинга игровых серверов

Четыре формата размещения — от «всё включено» до «железо целиком ваше».

Специализированный game hosting (managed)

Провайдер берет на себя ОС, обновления и серверное ядро, а администратор получает веб-панель (Multicraft, Pterodactyl или фирменную разработку) и занимается только настройкой самой игры: правила, моды, слоты. Порог входа — околонулевой: терминал не понадобится. Обратная сторона — панель диктует рамки, и выйти за них без root-доступа не получится. Hostingrust, MyArena, WorldHosts, Hosting-Minecraft, DS-HOST, EveHost, Maze Host и ApexMinecraftHosting из моей подборки — именно управляемые хостинги.

VPS/VDS

Изолированная виртуальная машина с полным root-доступом (чаще всего — KVM). Важно не путать этот тип с виртуальным (shared) хостингом, где десятки сайтов делят одну среду: VPS — это отдельная система, в которой администратор решает все сам. Поставить любое ядро, откатить версию, подключить нестандартный мод — ограничений нет. Но и ответственность за настройку, обновления и бэкапы — тоже на арендаторе. RU VDS и Hostingrust из подборки предлагают именно этот формат.

Выделенный сервер (dedicated)

Физический сервер целиком в вашем распоряжении: никаких «соседей» по ноде. Имеет смысл для крупных проектов: Minecraft на 200+ человек с тяжелыми модпаками, киберспортивные площадки, мультисерверные сети. Здесь стоит подчеркнуть отличие от colocation: при dedicated — арендуете чужое железо; при colocation — привозите свое оборудование в чужой ЦОД. Два разных формата с разной логикой ценообразования.

Облачные решения

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

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

Маленький сервер для друзей — managed-тариф. Кастомные сборки с нестандартным софтом — VPS. Крупный публичный проект или киберспортивная площадка — dedicated или облако.

Каким должен быть хороший хостинг игровых серверов

Как отличить лучший хостинг для игр от красивой вывески? Семь критериев.

Производительный CPU

Большинство игровых движков утилизирует одно ядро процессора — и DayZ, и Minecraft, и Rust нагружают single-thread, а не распределяют работу по всем ядрам. Поэтому при выборе тарифа важна частота на ядро, а не их количество. В 2026 году золотой стандарт — Ryzen 7000-9000 или Intel Core 12-14 gen с бустом от 5 GHz. Серверные Xeon прошлых поколений при всей многопоточности на тяжелых модпаках проседают ощутимо.

Достаточный объем RAM

Конкретные ориентиры: Minecraft Java vanilla на 5-10 человек — от 2 ГБ; с плагинами/модами на 20+ игроков — от 6-8 ГБ; тяжелые сборки (FTB, All the Mods) — 8-12 ГБ. CS2 на 24 слота — около 1 ГБ. Rust на 50 слотов — от 6 ГБ. Предпочтительно брать с запасом: перегруженный по памяти сервер начинает лагать задолго до того, как RAM заканчивается физически.

SSD (NVMe) накопители

HDD в 2026 году — анахронизм для игрового сервера. NVMe быстрее SATA SSD в 5-7 раз по IOPS. Разница критична для загрузки чанков в Minecraft, подгрузки карт в CS2 и чтения сейвов в survival-играх.

Защита от DDoS-атак

Базовый уровень — фильтрация L3/L4: UDP-флуд, SYN-флуд, amplification-атаки отсекаются на уровне сети. Продвинутый — L7 (прикладной уровень), когда атакующий маскируется под легитимный трафик. В карточках хостингов выше указаны конкретные технологии: AntiDDoS Game, DDoS-Guard, Arbor Peakflow, StormWall. Если провайдер пишет просто «защита от DDoS» без названия решения — это маркетинг, а не гарантия.

Низкий пинг

Для российской аудитории — ЦОДы в Москве, Санкт-Петербурге, Новосибирске. Ориентиры: до 30 мс — комфортный, 30-60 мс — приемлемый, выше 100 мс — для шутеров критично. Перед покупкой полезно прогнать ping или mtr до IP-адреса провайдера.

География не только про пинг

Расположение дата-центра влияет и на юридические аспекты: серверы в РФ подчиняются российскому законодательству о хранении данных, европейские площадки — GDPR. Для большинства игровых проектов это не критично, но если сервер собирает персональные данные (регистрация на сайте, донат-система, интеграция с Discord с авторизацией) — вопрос становится более актуальным. Провайдеры с площадками в нескольких юрисдикциях (RU VDS, XLGAMES) предоставляют альтернативы: разместить игровой сервер ближе к аудитории, а веб-часть — в нужной правовой зоне.

Удобная панель управления

Pterodactyl, Multicraft, собственные разработки — конкретное название имеет значение. Признаки хорошей панели: старт/стоп/рестарт, веб-консоль с подсветкой ошибок, файловый менеджер, установка плагинов в один клик, мониторинг CPU и RAM в реальном времени.

Резервные копии

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

Доступ к статистике сервера

Провайдер, который не показывает графики загрузки в реальном времени, — как автомобиль без приборной панели. Когда сервер начинает лагать, разница между «угадывать причину» и «за полминуты увидеть, что RAM на пределе» — это разница между часом простоя и пятиминутным апгрейдом тарифа. Минимум: CPU, RAM, сетевой трафик, аптайм — в панели, а не по запросу в поддержку.

Как выбрать хостинг под конкретную игру

Четыре переменных, которые определяют выбор.

Количество игроков

От числа игроков зависит, сколько RAM и какой процессор потребуются. Для Minecraft ориентир грубый, но рабочий: 70-100 МБ оперативной памяти на человека в vanilla, 200-400 МБ — если стоят моды. Запас закладывайте сразу: сервер на 30 слотов комфортнее работает с ресурсами, рассчитанными на 50. Для Rust и ARK ориентиры еще жестче: survival-тайтлы съедают память на карту мира, объекты и NPC.

Моды и плагины

Повышают требования к CPU и RAM в 2-3 раза по сравнению с vanilla. Forge с сотней модов маленький тариф не вытянет. Важно: моды для Minecraft требуют Java-версию сервера (не Bedrock) и конкретные версии Java Runtime (17, 21 — для свежих ядер). Моды между Java и Bedrock несовместимы — это разные платформы с разными форматами.

Совместимость модов с версией сервера

Частая ошибка — выбрать хостинг, оплатить тариф, установить двадцать модов и обнаружить, что половина из них конфликтует между собой или несовместима с версией серверного ядра. Перед покупкой стоит собрать список модов, проверить их совместимость на профильных форумах (CurseForge, Modrinth для Minecraft; Steam Workshop для Rust и ARK) и убедиться, что провайдер поддерживает нужную версию ядра. Моды ставятся по одному с проверкой стабильности после каждого: загрузка всей сборки разом превращает отладку конфликтов в лотерею.

Регион сервера

Главный фактор пинга. Россия и СНГ — Москва, Санкт-Петербург, Новосибирск. Глобальная аудитория — провайдеры с несколькими ЦОДами (RU VDS — 22 локации, XLGAMES — Россия/Финляндия/Германия, ApexMinecraftHosting — 15+ по миру). Зарубежный хостинг для российской аудитории дает 80-150 мс: для Minecraft терпимо, для шутеров уже ощутимо.

Маркетинговые ловушки

«Безлимитная RAM» в тарифе почти всегда означает оверселл: провайдер продает больше ресурсов, чем физически есть на ноде, в расчете на то, что все клиенты не загрузят серверы одновременно. В пиковые часы это оборачивается просадками. «Uptime 99.9%» без опубликованного SLA (соглашения об уровне обслуживания) — декларация, за которую провайдер не отвечает финансово. Отсутствие конкретной модели процессора в описании тарифа — ещё один тревожный сигнал: серьезный хостинг указывает и модель, и частоту, а не прячет железо за формулировкой «мощные серверы».

Бюджет

Ценовой диапазон в 2026-м широкий. Дружеский сервер на 5-10 человек без модов укладывается в 100-300 руб./мес. Проект среднего масштаба с модами на 20-30 игроков — 500-1500 руб./мес. Публичный сервер на 50+ слотов — 2000-5000 руб./мес. Полноценный VPS или dedicated — от 3000 руб./мес. и выше, но потолок ограничен только полетом амбиций. Одна рекомендация: если проект публичный — на DDoS-защите экономить не стоит. Одна успешная атака обходится дороже, чем год оплаты нормального хостинга.

Десять провайдеров в этой подборке — десять разных ответов на один и тот же вопрос: где разместить игровой сервер. Managed-тариф за пару сотен рублей или выделенная машина в ЦОДе Tier III — конечные точки шкалы, между которыми найдется вариант под любой бюджет и уровень подготовки. Алгоритм выбора сводится к трем переменным: тайтл, размер аудитории, география игроков. Когда вы определяетесь с ними, хостинг игровых серверов перестает быть абстрактным понятием, превращаясь в конкретный тариф с конкретным IP-адресом.

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

О том, где в таких продуктах чаще всего возникают скрытые сложности и как найти баланс между потребностями бизнеса, пользователей и разработчиков, рассказала Наталья Буйлина, лидер стрима ITSM платформы производства ПО «Сфера» (входит в ИТ-холдинг Т1).

Корень большинства проблем лежит глубже — в логике сценариев и архитектуре. Интерфейс лишь отражает то, насколько хорошо продуманы пользовательские пути. В продуктах, работающих внутри платформы, главная боль — скрытые зависимости от сервисов и сценарии, которые «ломаются» при любых изменениях в базовой инфраструктуре. При этом человек уверен, что работает с одним продуктом, хотя за ним стоят 5–10 компонентов.

Внутренние команды: пользователи, о которых забывают

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

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

No-code и low-code: гибкость, которая может стать ловушкой

Отдельного внимания заслуживает работа команд внедрения в no-code- и low-code-среде. Такие инструменты ускоряют запуск новых сценариев, но конфигурация нередко выходит за пределы системы: появляются Excel-файлы с настройками, ручное копирование параметров между клиентами, внешние скрипты.

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

Архитектура как точка баланса

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

Продукты не должны сдерживать развитие платформы, а платформа — тормозить продуктовые команды.

Мы собрали актуальный список облачных 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. Смотрите на время, которое команда тратит на поднятие среды и поддержку узлов. Правильное облако должно ускорять релизы, а не подкидывать девопсам новые таски в бэклог.

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

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

Мультиклауд уже давно стал полноценной частью нашей жизни. Согласно исследованию MWS Cloud, среди компаний, пользующихся виртуальной инфраструктурой, 31% предприятий размещают свои данные в двух и более облаках, 10% — в трёх и более. Наше партнёрство с Cloud.ru позволит нам упростить использование этой концепции для наших клиентов — помочь им гибко управлять инфраструктурой сразу у двух ведущих российских провайдеров, чтобы эффективнее балансировать нагрузки и снижать затраты. Мы убеждены, что за мультиклаудом — будущее облачного рынка, и намерены формировать его вместе с ведущими провайдерами страны, делая мультиоблачные сценарии доступнее и удобнее для российского бизнеса.

Запуск сервиса запланирован на июнь 2026 года. На первом этапе услуга станет доступна через обращение в поддержку. В дальнейшем компании планируют организовать запуск сервиса «по клику». Это сократит время создания соединений между облаками партнёров до нескольких минут.

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

Cloud.ru — один из крупнейших облачных и ИИ-провайдеров России. Компания основана в 2019 году и за несколько лет вошла в число лидеров рынка инфраструктурных, платформенных, а также ИИ-решений.

В портфеле Cloud.ru — более 100 инфраструктурных и платформенных сервисов, публичное облако Cloud.ru Evolution на базе собственных технологий, аттестованная инфраструктура для размещения ГИС и КИИ, платформа для частных и гибридных облаков Evolution Stack, а также цифровая среда для промышленной работы с генеративным ИИ — Evolution AI Factory.

В команде компании — более 2 000 специалистов, преимущественно в области ИТ, кибербезопасности и ИИ.

Реклама. Рекламодатель: ООО «Облачные технологии», ИНН 7736279160, erid: 2W5zFHDSEaD

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

Почему ручная обработка больше не работает

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

• задержки обработки;
• ошибки операторов;
• потеря заказов;
• возвраты из-за долгого подтверждения;
• невозможность работать 24/7;
• высокий риск мошенничества.

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

Именно поэтому современные площадки переходят на автоматизированную архитектуру: платежный шлюз + API поставщика цифровых услуг + система мгновенной обработки заказов.

Почему бизнес выбирает GGPay

На фоне растущего рынка особое внимание получают сервисы, которые совмещают удобный API, стабильную инфраструктуру и понятную финансовую модель.

Одним из таких решений сегодня является GGPAY — сервис для пополнения Steam и других цифровых платформ с поддержкой автоматизированной обработки платежей.

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

• стабильная работа API;
• автоматическое проведение платежей;
• поддержка популярных способов оплаты;
• низкие комиссии;
• высокая скорость зачисления;
• работа 24/7;
• удобная интеграция для сайтов и Telegram-проектов.

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

Как устроена API-интеграция цифровых платежей

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

Типовой процесс выглядит следующим образом:

1. Пользователь выбирает цифровой товар или пополнение.
2. Сайт формирует заказ.
3. Платежный шлюз принимает оплату.
4. После подтверждения транзакции сервер обращается к API поставщика.
5. API выполняет пополнение или выдает цифровой ключ.
6. Клиент получает результат автоматически.

Подобная модель давно используется в международной игровой индустрии и интегрируется через REST API, callback-уведомления и защищенные webhook-системы.

Главное преимущество такой схемы — отсутствие ручной обработки. Бизнес получает возможность масштабироваться практически без увеличения штата.

Какие задачи решает API для цифровых товаров

Современные API-платформы позволяют автоматизировать практически весь цикл продажи:

• пополнение Steam;
• продажу игровых ключей;
• выдачу gift card;
• оплату подписок;
• работу с региональными балансами;
• массовую обработку заказов;
• автоматический возврат;
• мониторинг статусов транзакций;
• защиту от дублирования платежей.

Для крупных площадок особенно важна возможность работать с несколькими поставщиками одновременно. Это позволяет распределять нагрузку, снижать комиссии и поддерживать стабильность даже во время пикового спроса.

На что обращать внимание при выборе API-партнера

Ошибка многих проектов — выбор поставщика исключительно по размеру комиссии. На практике стабильность API намного важнее разницы в 1–2%.

При выборе сервиса необходимо оценивать:

1. Скорость обработки

Для игровых сервисов критична мгновенная выдача. Пользователь не готов ждать 10–15 минут после оплаты.

2. Аптайм инфраструктуры

Если API регулярно падает во время крупных распродаж Steam — бизнес теряет деньги и репутацию.

3. Наличие webhook и callback-систем

Это основа автоматизации статусов платежей.

4. Документация

Качественная документация сокращает время интеграции в разы.

5. Поддержка популярных способов оплаты

СБП, банковские карты, криптовалюты, электронные кошельки — современный рынок требует гибкости.

6. Защита от мошенничества

Антифрод-механизмы и валидация заказов особенно важны в сегменте цифровых товаров.

Почему рынок активно переходит на автоматические пополнения Steam

Steam остается крупнейшей игровой платформой мира, а пополнение кошелька — одним из самых востребованных цифровых продуктов в СНГ и Восточной Европе.

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

Сегодня пользователи ожидают:

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

Именно поэтому автоматизированные сервисы показывают значительно более высокую конверсию по сравнению с полуавтоматическими решениями.

Как выглядит современная архитектура цифрового магазина

Профессиональная инфраструктура обычно включает несколько уровней:

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

Дополнительно многие проекты подключают аналитические сервисы, отслеживающие:

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

Такой подход позволяет масштабировать платформу практически без ограничений.

Какие технологии будут доминировать дальше

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

• direct top-up через Steam ID;
• мультивалютные API;
• криптовалютные расчеты;
• AI-антифрод;
• распределенные платежные системы;
• автоматические системы маршрутизации транзакций.

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

Заключение

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

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

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

Реклама. Рекламодатель: ОсОО «НОВАПЭЙ», ИНН:9909710276, erid: 2SDnjf2S7a2

Эксперты Centicore Group собрали чек-лист из 12 пунктов, которые реально работают при выборе интегратора, а когда у вас станет вопрос подрядчика – вы можете воспользоваться этим списком.

1. Опыт в вашей индустрии

Системный интегратор, который делал проекты для e-commerce, не обязательно справится с финтехом. У каждой индустрии свои особенности: требования к безопасности, специфика бизнес-процессов, регуляторные ограничения.

Что проверять:

1. Портфолио с проектами в вашей сфере. Нужны конкретные кейсы: что делали, какой стек, какие результаты.
2. Понимание специфики. Если интегратор сразу задаёт правильные вопросы про ваши бизнес-процессы — хороший знак. Если предлагает типовое решение без погружения в специфику — советуем искать дальше.
3. Измеримые результаты. Везде понятные показатели: на сколько сократили время обработки заявок, сколько проект занял по времени, какая команда специалистов и к чему в итоге пришли.

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

2. Что по техстеку и обновлениям

В 2026 году оценивать интегратора по знанию условного языка программирования бессмысленно. Смотреть нужно на то, как команда работает с энтерпрайз-стеком и требованиями безопасности.

На что смотреть:

1. Соответствие вашему контуру. Если у вас закрытый on-premise, а подрядчик умеет деплоить только в публичные облака — вам не по пути.

2. Релевантные сертификаты и лицензии. Если делаете финтех — нужен опыт прохождения PCI DSS. Если работаете с госсектором или персональными данными — ищите подрядчика с лицензиями ФСТЭК и ФСБ.

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

4. Геополитические и санкционные риски. В 2026 году для российского рынка это один из ключевых рисков. Что здесь нужно проверять:

• Зависимость от иностранных облаков и компонентов.
• Отдельно open-source библиотек и фреймворков с высокой санкционной уязвимостью.
• Наличие у подрядчика плана «Б» на случай новых ограничений (альтернативные поставщики, российские облака, on-premise).
• Опыт работы с проектами, которые уже проходили через санкционные ограничения.

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

5. Отношение к ИИ-инструментам и low-code решениям. В 2026 году почти все интеграторы так или иначе используют ИИ (Cursor, GitHub Copilot, Claude, внутренние агенты). Важно понимать политику компании. Что проверять:

• Есть ли у подрядчика регламент использования ИИ-инструментов (что разрешено, что запрещено, как проверяется код, сгенерированный ИИ).
• Насколько активно они применяют low-code/no-code платформы и как это влияет на качество и поддержку решения.
• Готовы ли они комбинировать ИИ + ручную разработку или полностью полагаются на «ИИ всё сделает».
• Есть ли у них экспертиза по prompt engineering и проверке качества ИИ-генерируемого кода.

Красный флаг: Подрядчик либо полностью игнорирует ИИ («мы всё пишем руками»), либо говорит «мы всё делаем через ИИ и это в 10 раз быстрее» без упоминания проверок и рисков.

3. Насколько гибкие в разработке

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

Что важно:

1. Подход к кастомизации показывает философию компании. Если подрядчик сразу говорит о готовом решении и предлагает подстроить бизнес-процессы под него — это провал для специфичных задач. Подбор решения под клиента, а не наоборот — признак зрелого подхода.
2. Работа с изменениями — реальность любого проекта. Требования меняются в процессе, это нормально. Agile не на словах, а на деле означает готовность пересмотреть приоритеты, адаптировать бэклог, обсуждать изменения.
3. Понимание бизнес-задачи отличает хорошего интегратора от посредственного. Технари часто зацикливаются на том, как реализовать, забывая спросить, зачем это нужно. Вопрос о том, какую проблему решает функция, должен звучать чаще, чем обсуждение технологии.

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

4. Прозрачность процессов

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

Как оценить прозрачность:

1. Структура коммуникации определяет скорость решения вопросов. Кто ваш контакт — менеджер без технической экспертизы или техлид команды? Как быстро получаете ответы? Есть ли прямой доступ к разработчикам для обсуждения технических деталей?
2. Регулярная отчётность — это не бюрократия, а инструмент контроля. Демо каждый спринт, доступ к таск-трекеру вроде Jira, понимание прогресса в реальном времени. Компании с 24/7 поддержкой обычно имеют настроенные процессы коммуникации и реагирования.
3. Документация показывает зрелость процессов. Если подрядчик не может показать примеры технической документации, процессов разработки, архитектурных решений — это тревожный звонок.
4. Совпадение ценностей и корпоративной культуры. Технические навыки важны, но если ценности не совпадают — проект будет постоянным источником конфликтов. Попросите пообщаться не только с техлидом, но и с 1–2 разработчиками, которые будут работать над проектом. Задайте вопросы про их реальный опыт работы в компании. Что проверять:

• Отношение к удалённой работе и овертаймам (есть ли культура «гореть на проекте» или уважают work-life balance).
• Прозрачность внутри компании (как принимаются решения, насколько открыто руководство общается с командой).
• Отношение к качеству vs скорость (готовы ли отказываться от «быстрых костылей» ради долгосрочного результата).
• Корпоративные ценности: как компания относится к клиентам, к сотрудникам, к этике в разработке.

Красные флаги:

1. Вам говорят, что всё хорошо, но конкретики нет. Нет демо, доступа к репозиторию, промежуточных результатов. А потом в день дедлайна выясняется, что половины функционала нет. Нормальная практика — давать клиенту видимость работы: задачи, коммиты, тесты.
2. Проводите демо результатов каждые 1-2 недели. Так будете видеть рабочий код, сможете проверить функционал, задать вопросы напрямую техлиду. Ошибки дешевле исправлять на ранних этапах, чем в продакшене.
3. Команда говорит одно на собеседовании, а на деле — жёсткий overtime, токсичная культура и «мы просто кодим, а менеджеры решают».

5. Команда и культура разработки

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

Что проверять:

1. Квалификация разработчиков определяет скорость и качество работы. Соотношение мидлов и сеньоров в команде показывает, кто будет делать архитектурные решения, а кто — рутинные задачи. Если в команде только джуны под управлением одного сеньора — это риск.
2. Текучка кадров — критический показатель стабильности. Высокая текучка означает проблемы: либо с зарплатами, либо с управлением, либо с атмосферой. Всё это отразится на вашем проекте.
3. Практики разработки видны в деталях. Code review, автоматизированное тестирование, CI/CD — это страховка от багов в продакшене. Спросите, как организован процесс: делают ли ревью кода, какое покрытие тестами, как часто деплоят.

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

6. Пост-интеграционная поддержка

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

На что смотреть:

1. Гарантии и доработки. Что будет, когда система упадет из-за архитектурной ошибки вендора? Условия фикса багов и доработок после релиза должны быть зафиксированы в контракте.
2. Контроль ответственности. Должно быть четко расписано, где заканчивается зона ответственности интегратора и начинается зона ваших админов, девопсов или первой линии поддержки.
3. Документация и передача знаний. Подрядчик обязан выгрузить не только исходники, но и актуальную документацию: ADR (архитектурные решения), схемы инфраструктуры, регламенты развертывания.

Юридическая и договорная часть. Условия расторжения договора и стратегия. Кто владеет кодом и данными после завершения проекта. Штрафы за срыв сроков и SLA. Право на аудит кода и инфраструктуры.

7. Безопасность и комплаенс

1. Проверяйте сертификаты и стандарты: ISO 27001 по информационной безопасности, соответствие ФЗ-152 о персональных данных, отраслевые стандарты вроде PCI DSS для платёжных систем.
2. Пентесты, аудит кода на уязвимости, шифрование данных, управление доступами — всё это должно быть в процессе по умолчанию.
3. Убедитесь, что контракт чётко прописывает, кому принадлежит код, как защищаются ваши данные, какие санкции за утечку.

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

8. Реальные кейсы и рекомендации

Самый очевидный и простой способ проверить подрядчика — поискать в открытом доступе упоминания и кейсы в медиа или на специальных площадках. Вот на что смотреть:

1. Соблюдение сроков — классический больной вопрос IT-проектов. Уложились ли в первоначальные оценки? Если были задержки — как объясняли и решали?
2. Работа с изменениями — насколько гибко подрядчик реагировал на новые требования? Были ли конфликты по поводу доп.функционала?
3. Качество коммуникации — как быстро отвечали, насколько понятно объясняли технические вещи, был ли прямой контакт с командой?
4. Пост-поддержка — что происходило после запуска? Быстро ли реагировали на проблемы? Помогли ли с развитием продукта дальше?

9. Финансовая прозрачность

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

На что смотреть:

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

Красные флаги:

• Слишком низкая цена по рынку — либо подрядчик неправильно оценил сложность и потом будет просить доплату, либо сэкономит на качестве: джуны вместо мидлов, отсутствие тестирования, урезанная документация.
• Отказ детализировать оценку под предлогом коммерческой тайны. Нормальная практика — объяснить клиенту, из чего складывается стоимость. Если подрядчик этого не делает — он либо сам не понимает, либо что-то скрывает.

10. Масштабируемость решения

Интегратор не сдает вам в аренду серверы, поэтому он должен спроектировать систему так, чтобы при х10 росте нагрузки вам не пришлось переписывать ядро, менять СУБД или сносить весь проект.

1. Проектирование под рост бизнеса отличает стратегическое мышление от тактического. Хороший интегратор спросит о ваших планах: сколько пользователей сейчас, сколько планируется через год, через три года. И заложит архитектуру с запасом.
2. Постепенное расширение функционала дешевле полной переделки. Модульная архитектура, микросервисы, API-first подход — всё это позволяет добавлять новые возможности без переписывания существующего кода.
3. Управление техническим долгом. Любая разработка накапливает технический долг: быстрые решения, костыли, устаревшие зависимости. Профессионалы планируют рефакторинг, выделяют время на улучшение кода, следят за обновлениями библиотек.
4. Vendor lock-in и технологическая независимость. Хороший интегратор не строит систему так, чтобы вы навсегда зависели от его экспертизы, конкретного облака или проприетарного инструмента. Проверяйте: на каких лицензиях работает стек, можно ли сменить подрядчика без переписывания системы, кто владеет кодом и есть ли возможность развивать продукт силами инхаус-команды.

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

11. Скорость и качество коммуникации

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

1. Время отклика на первый запрос — если на ваше обращение отвечают через неделю — представьте, как будет идти коммуникация в процессе проекта.
2. Интегратор должен задавать вопросы не только про технические требования, но и про то, какую проблему бизнеса решает система. Это показывает стратегическое мышление.
3. Хороший подрядчик не просто делает, что сказали, а предлагает улучшения: как сделать эффективнее, дешевле, быстрее. Это требует глубокого понимания вашего бизнеса.

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

12. Репутация на рынке и стабильность

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

Что оценивать:

1. Время на рынке — один из положительных сигналов, но не гарантия. Компании с опытом 8+ лет, как правило, пережили кризисы, накопили экспертизу и выстроили процессы. Но возраст сам по себе не означает качество: проверяйте кейсы, репутацию и стабильность команды, а не только дату основания. Стартапы могут быть инновационными — просто риски у них другие.
2. Финансовая устойчивость проверяется косвенно: по масштабу проектов, количеству офисов, размеру команды.
3. Участие в профессиональных мероприятиях показывает открытость. Компании, которые выступают на конференциях, пишут статьи, делятся опытом, обычно уверены в своей экспертизе. Это также помогает проверить репутацию через знакомых в индустрии.
4. Партнёрские отношения с крупными вендорами — ещё один индикатор.

Проверка на негатив:

• Поищите упоминания компании в негативном контексте: судебные споры, публичные конфликты с клиентами, жалобы сотрудников. Одна претензия — не приговор, но если их много — стоит задуматься.
• Отсутствие следов в интернете тоже настораживает. Нормальная IT-компания в 2026 году должна быть видна: сайт, соцсети, публикации, упоминания в медиа.

Как использовать чек-лист

1. Первичный скрининг отсекает неподходящих кандидатов. Пройдитесь по критичным пунктам: опыт в индустрии, технологический стек, безопасность, репутация. Если есть красные флаги — не тратьте время на глубокую оценку.
2. Глубокое интервью для финалистов. Возьмите 2-3 компании, которые прошли скрининг, и проверьте остальные пункты детально. Встречи с командой, разбор кейсов, общение с референсами, обсуждение процессов.
3. Пилотный проект снижает риски. Перед большим контрактом протестируйте подрядчика на небольшой задаче. Это покажет реальное качество работы, скорость коммуникации, соблюдение договорённостей. Дешевле потратить месяц на пилот, чем год на исправление ошибок.

Чек-лист работает, когда применяете его последовательно. Не пропускайте пункты, которые кажутся очевидными — именно там часто скрываются проблемы. И помните: идеального подрядчика не существует. Важно найти того, чьи сильные стороны совпадают с вашими приоритетами, а слабые — не критичны для проекта.

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

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

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

Постановка задач и бизнес-требования

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

Госсектор: когда ГОСТы встречаются с CJM

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

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

Поэтому сейчас ИТ-команды в госах всё чаще занимаются проработкой клиентских путей (Customer Journey Map, CJM). Инженерная задача — это не просто закодить фичу, а умудриться соединить удобный современный пользовательский интерфейс (UI) с соблюдением требований ГОСТов, Гостеха и законодательства о защите персональных данных (ИСПДн).

Нефтегаз: цена ошибки и жизнь без права на фейл

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

Именно из-за таких рисков ИТ-команды в нефтегазе сейчас в основном работают на вспомогательных процессах: делают HR-сервисы, логистические системы и модули информационной безопасности. Этот сегмент стабильно растёт на 8% в год. Разработка здесь означает создание максимально надёжных внутренних инструментов с требованиями к отказоустойчивости. Любая, даже самая мелкая гипотеза проверяется в жёстко изолированной среде до выкатки в продакшен.

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

Финтех: когда разработчик становится экономистом

В финтехе всё диктует регуляторика. Постановления ЦБ, расчёт макропруденциальных лимитов (МПЛ), показателей долговой нагрузки (ПДН), интеграция антифрод-систем — всё это не настройки на потом, а основа бизнес-логики.

Места для свободного манёвра мало

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

Инфраструктура и безопасность

Представьте, что вы привыкли по клику раскатывать контейнеры в облаке, качать любые библиотеки из npm и сразу проверять гипотезы без долгого согласования. А теперь забудьте об этом. В энтерпрайзе то, что в продуктовом стартапе кажется паранойей, считается базовым гигиеническим минимумом. И если вы думаете, что безопасность — это просто настроить VPN и закрыть пару портов, то добро пожаловать в реальный мир.

Госсектор: как поженить ГОСТы и нейросети

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

Использовать внешние API нельзя

Вы не можете просто скормить код ChatGPT, потому что за отправку данных госоргана на внешние сервера по головке не погладят. Нужно разворачивать опенсорсные LLM прямо on-premise, внутри закрытого контура заказчика. Чаще всего в ход идут Llama и её производные, либо отечественные решения от Сбера и Яндекса. Модели дообучаются на локальных конфиденциальных датасетах. Чтобы никто, случайно или специально, не слил данные наружу, выстраивается ML-шлюз. Отдельная языковая модель ставится прямо на пути всех исходящих API-запросов из внутреннего контура во внешний мир. Если какой-нибудь сотрудник или смежный сервис формирует запрос к внешней нейросети, и локальная модель распознаёт в промпте что-то, хотя бы отдалённо похожее на конфиденциальную информацию, она не разрешает выполнить этот запрос. Нужно аппаратно и программно фильтровать ИИ-трафик другим ИИ.

Нефтегаз: разработка в абсолютном вакууме

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

Вам придётся забыть про привычные среды

Разработчики массово перекатывают сервисы на отечественные Linux-дистрибутивы: RedOS, AltLinux, AstraLinux. Любимые СУБД меняются на MariaDB и PostgreSQL.

Всё работает исключительно через демилитаризованные зоны (DMZ). Весь ваш код, все пайплайны хранятся и собираются в локальных инстансах GitLab, у которых вообще нет выхода во внешний интернет. При этом регулярно прилетают обязательные пакеты обновлений от ФСТЭК, которые влияют не только на ядро операционки, но и на прикладные компоненты.

Финтех: микросервисы и оркестрация

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

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

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

Вы завязаны на работу соседних команд

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

Внедрение ИИ и новых технологий

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

Госсектор: генерация бюрократии и предиктивная аналитика

С распространением нейросетей в ведомствах появился совершенно новый класс инженерных задач. По статистике Centicore Group практически в каждом новом проекте для государственных структур есть модули на базе машинного обучения. При этом востребованы не универсальные облачные чат-боты, а узкоспециализированные решения, которые разворачиваются строго on-premise, на серверах заказчика. Чаще всего под капотом используются открытые языковые модели семейства Llama, а также адаптированные российские аналоги от Яндекса и Сбера.

С какими конкретными задачами здесь сталкиваются разработчики?

1. Создание генераторов технической документации. На практике процесс выглядит так: системный аналитик нажимает кнопку, передаёт короткое описание задачи, а нейросеть автоматически генерирует две страницы полноценных требований, написанных сухим, регламентированным бюрократическим языком.
2. Внедряется сложный нейропоиск по внутренним базам нормативно-правовых актов (НПА), где классический полнотекстовый поиск уже не справляется с объёмами данных.
3. Разрабатываются специализированные ИИ-консультанты для сферы закупок. В систему загружается техническое задание (ТЗ), а алгоритм сам подсказывает сотруднику нужный код классификатора ОКПД-2 для корректного оформления заявки.

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

Нефтегаз и крупное производство: компьютерное зрение вместо текстов

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

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

Ещё одна массивная задача в отрасли — OCR (оптическое распознавание символов). Речь идёт о потоковом распознавании сканов первичной документации абсолютно любого, даже нестандартного формата, с автоматической нормализацией и отправкой извлечённых данных напрямую в базы 1С.

Финтех: сложная аналитика конверсий

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

Матрица выбора для ИТ-специалиста

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

Выбирайте нефтегаз, если:

• Вы готовы писать и собирать код в полностью изолированных сетевых контурах через демилитаризованные зоны (DMZ).
• Вас совершенно не пугает деплой через локальные инстансы GitLab, у которых напрочь отрезан любой доступ к внешнему интернету.
• Вы готовы своими руками переводить огромный серверный парк на AstraLinux, RedOS, AltLinux и поддерживать работу с СУБД MariaDB и PostgreSQL.
• Долгий цикл релиза вас не демотивирует, потому что вы понимаете: цена ошибки на реальном промышленном производстве недопустимо высока.
• Вам профессионально интереснее интегрировать прикладное компьютерное зрение (CV) для выявления брака на конвейерах, чем развёртывать генеративные текстовые чат-боты.

Выбирайте госсектор, если:

• Вы предпочитаете работать по чётким, детально задокументированным ТЗ, а не пытаться угадать размытые продуктовые требования бизнеса.
• Вам интересна нетривиальная архитектурная задача: как органично соединить современный пользовательский UI с жёсткими требованиями Гостеха и ИСПДн.
• Хочется на реальной практике разворачивать on-premise LLM (решения семейства Llama, Яндекса, Сбера) внутри защищённых периметров.
• Вас привлекает идея настраивать ML-шлюзы для автоматической фильтрации трафика и защиты корпоративных контуров от утечек.
• Интересна автоматизация бюрократии: разработка умного нейропоиска по базам НПА, потоковая генерация документов и ИИ-подбор кодов ОКПД-2.

Выбирайте финтех, если:

• Вы готовы прямо на проекте глубоко разбираться в расчётах МПЛ, ПДН и банковских алгоритмах досрочного погашения.
• Вас не пугает, что жёсткая, бескомпромиссная регуляторика ЦБ ложится в основу абсолютно каждой технической задачи в бэклоге.
• Вы умеете проектировать и поддерживать сложную, высоконагруженную микросервисную архитектуру, где каждый изолированный фронтовый сервис интегрирован с десятками смежных систем (скорингом, антифродом, базами кредитных историй).
• Вам интересна архитектурная работа с цифровым рублём — масштабная переработка флоу транзакций и внедрение новых сущностей в реляционные базы данных.

Вместо заключения

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

Чтобы успешно выкатить продукт в таких реалиях, недостаточно просто уметь писать чистый код. Нужна команда, которая знает, как легально протащить релиз через DMZ, развернуть on-premise LLM без риска утечек и завернуть современный пользовательский интерфейс в требования Гостеха и ИСПДн. Если вашему бизнесу предстоит сложный проект в госсекторе или промышленном энтерпрайзе, специалисты Centicore Group готовы реализовать его под необходимые требования.

1. Советские математики заложили базу для российских бигтехов

Чтобы понять, откуда в России вообще взялись программисты, вернемся в конец 1940-х годов. После Великой Отечественной войны началась технологическая гонка вооружений. У США уже была ядерная бомба, поэтому Советскому Союзу нужно было срочно создать свою. Для разработки похожего оружия применяли сложные математические расчеты, которые люди с механическими арифмометрами выполняли бы годами, поэтому Советский Союз взял курс на создание своих вычислительных машин.

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

Развитие советской техники возглавил ученый Сергей Лебедев. Сначала он построил первую отечественную ЭВМ — МЭСМ (малую электронную счетную машину), а после начал разработку серии БЭСМ (больших электронных счетных машин).

Больше о том, как создавались первые советские ЭВМ, узнайте в подкасте Контура и студии «Послушайте!» «От нуля до единицы. История российского IT». Там про это рассказывает антрополог и автор книги «Антропология русского интернета» Наталья Конрадова — с деталями, которых нет ни в этой, ни в других популярных статьях.

Вершиной разработки в Советском Союзе стала БЭСМ-6, она серийно производилась с 1968 по 1987 год и стала основным инструментом для ученых и инженеров. На этой машине считали траектории ракет и моделировали ядерные реакции. Именно на ней учили программированию студентов лучших технических вузов страны.

Работа с первыми ЭВМ сформировала советскую инженерную культуру. Специалисты привыкли писать алгоритмы в условиях ограничений вычислительных ресурсов.

2. Программирование стало языком — и это открыло рынок для коммерческих продуктов

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

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

В СССР этот мировой принцип быстро подхватили и развили локально. Программист Владимир Курочкин написал транслятор универсального языка Алгол-60 сначала для БЭСМ-2, а затем для БЭСМ-6. На этой базе выучились тысячи советских инженеров, которые впоследствии стали основателями ведущих отечественных IT-компаний.

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

3. Технологии 50-х годов помогли заложить основы для автоматизации документооборота

В 1950-х военный кибернетик Анатолий Китов первым сформулировал идею, которая сегодня кажется очевидной: управлять экономикой огромной страны только через бумажный документооборот невозможно. Люди в столице собирали статистику с производств на бумаге и рассылали обратно готовые производственные планы. Из-за долгой переписки возникали ошибки, а на складах регулярно скапливались лишние товары.

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

Позже эту идею подхватил Виктор Глушков, возглавивший Институт кибернетики. Он развил идеи Китова и довел их до уровня масштабного государственного проекта — ОГАС (общегосударственной автоматизированной системы учета и обработки информации). Эта система должна была объединить все министерства и заводы страны единой вычислительной сетью, чтобы управлять экономикой в реальном времени.

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

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

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

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

У гражданских объектов, заводов, государственных учреждений потребность обмениваться электронными документами с годами никуда не исчезла. И когда в конце 1980-х годов гражданам разрешили создавать кооперативы, частные инженеры начали разрабатывать софт для упрощения документооборота. Именно это сделал и Контур, когда в 1988 году запустил свой первый продукт «Учет труда и заработной платы — АМБа».

4. До хакатонов были олимпиады: как школьные соревнования воспитали первых разработчиков коммерческого софта

Сегодня IT-специалисты соревнуются на хакатонах, а в Советском Союзе были олимпиады по программированию. В 1981-м в Москве прошло первое такое соревнование среди школьников, а уже через четыре года информатика официально стала школьным предметом. К 1988 году в Свердловске (ныне Екатеринбург — родина Контура) организовали уже всесоюзное соревнование.

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

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

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

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

5. Кооперативы 1987 года — точка, где наука стала бизнесом

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

В 1988 году трое выпускников Уральского политехнического института (УПИ) создали компанию СКБ Контур. Их первым продуктом стала программа «АМБа» — с ней бухгалтеры смогли вести электронный учет труда и зарплаты на предприятиях. Первыми покупателями стали предприятия Свердловска, в том числе Уральский алюминиевый завод.

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

Со временем алгоритмы и опыт разработки «АМБы» стали базой для новых IT-продуктов Контура. К 2000 году появился «Контур.Экстерн» — платформа для сдачи электронной отчетности в госорганы. Она работает и развивается уже 26 лет.

6. Горбушка и пиратство создали инженерную школу реверс-инжиниринга

На московском рынке Горбушка в 1990-х продавцы торговали прямо с ящиков: запчасти для ZX Spectrum, пиратские операционные системы, бухгалтерские программы на дискетах.

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

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

Как именно выглядел этот период изнутри — рассказывают во втором эпизоде подкаста «От нуля до единицы». Там же — про утечку мозгов, первых провайдеров и то, что покупка компьютера в 90-е занимала целый день и требовала помощи знакомого студента УПИ, объезжавшего полуподвальные магазинчики.

7. Релком доказал, что открытые сети работают — и дал старт провайдерскому рынку

Параллельно с развитием стихийных рынков ПО появлялись отечественные сети связи. В начале 1990-х годов в подвале Курчатовского института группа ученых подняла первую публичную компьютерную сеть в стране — Релком. Секретные военные вычислительные центры прошлого оставались строго изолированными системами. Релком подключал всех: нужен был компьютер, модем и телефонная линия. Инфраструктура строилась на операционной системе UNIX и машинах производства DEC.

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

Локализация победила глобальных игроков — и это стало моделью для всего российского бигтеха

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

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

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

Как в нулевые взрывался рынок интернета и какими были первые социальные сети — в третьем эпизоде подкаста «От нуля до единицы». Там же — про то, почему самым популярным сайтом Рунета в 1997 году был ресурс с анекдотами и чем это время отличалось от нынешнего.

• Легислатура Мэна одобрила LD 307 — первый в США мораторий на выдачу разрешений для дата-центров мощнее 20 МВт. Действует до ноября 2027 года.
• Поводом стали два громких провала: проект на $5 млрд в Wiscasset (жители заблокировали из-за закрытого NDA и размещения на общественной земле) и проект на $300 млн в Lewiston (городской совет единогласно отклонил из-за нагрузки на сеть).
• По данным Data Center Watch, за последние два года по США заблокировано или отложено проектов дата-центров примерно на $64 млрд.
• Сейчас дата-центры потребляют около 4% электричества США; к 2030 году цифра может удвоиться — это давит на тарифы везде, где идёт ИИ-стройка.

Что именно приняли

LD 307 временно запрещает штату и муниципалитетам выдавать разрешения на дата-центры с подключённой мощностью более 20 МВт. 20 МВт — это порог, ниже которого остаются небольшие корпоративные и колокейшен-объекты, но выше него начинается всё, что строят гиперскейлеры под ИИ-нагрузки: кластеры на тысячи GPU уходят за 50–100 МВт легко.

Мораторий действует до 1 ноября 2027 года. За это время новая Data Center Coordination Council должна изучить, как такие объекты влияют на изношенную электросеть штата, и предложить постоянные правила. Губернатор Джанет Миллс (демократ) поддерживает паузу.

«Взять эту паузу сейчас — критически важно», — заявил член палаты представителей Кристофер Кесслер со ссылкой на Maine Public Radio. Застройщик Тони Макдональд назвал новые ограничения «катастрофическими» и пожаловался, что его команда «попала в эту облаву».

Почему именно Мэн

Формально инициатива на уровне штата — но раскатал её конкретный провал в Lewiston. В декабре 2025 года городской совет единогласно зарубил проект дата-центра на $300 млн внутри старого текстильного комплекса Bates Mill. Детали проекта вскрылись за шесть дней до голосования — и жители успели поднять шум вокруг расхода воды и нагрузки на сеть. Показательная деталь: раньше в том же здании сидел колл-центр TD Bank на тысячу с лишним рабочих мест, а дата-центр обещал дать всего около 30.

За месяц до этого в городе Wiscasset так же жёстко слили проект на $5 млрд. Недовольство вызвали закрытое NDA, которое город подписал с застройщиком, и размещение объекта на общественной земле. Также в подвешенном состоянии находятся площадки в Jay (на месте бывшего бумажного комбината), в Sanford и на Loring Air Force Base.

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

Не только Мэн: кто ещё тормозит

По данным Data Center Watch, за последние два года по США заблокировано или отложено проектов дата-центров примерно на $64 млрд. Локальные паузы уже ввели округа в Мичигане и Индиане. Города от Денвера до Детройта обсуждают похожие ограничения — и это ещё до того, как мэнский прецедент начнёт раскатываться дальше.

Сейчас дата-центры потребляют около 4% электричества США. Прогнозы сходятся на том, что к 2030 году цифра может удвоиться — в основном за счёт ИИ-нагрузок. Экономист Анирбан Басу назвал решение Мэна «канарейкой в шахте» для сопротивления штатов энергоаппетитам бигтеха.

Что это значит для разработчиков

Прямого эффекта «AWS завтра подорожает» ждать не стоит: Мэн — не главный ИИ-хаб США. Но если прецедент подхватят более жирные штаты (а к этому сейчас движется дискуссия в Вирджинии и Техасе, где сконцентрирована бо́льшая часть американских ЦОДов), сроки запуска нового железа у гиперскейлеров (то есть Google, AWS, Microsoft, Meta и прочих операторов гигаваттных ЦОДов) поедут вправо. Дефицит capacity — это классический триггер для роста цен на облачные инстансы и, особенно, на GPU-мощности для обучения моделей.

Российским командам это косвенно важно по двум линиям. Первая — мировые цены на ИИ-инференс: даже если вы работаете с российскими провайдерами вроде Yandex Cloud, VK Cloud или Cloud.ru, тарифы на GPU формируются под влиянием глобального дефицита H100 и B200. Вторая — локальная повестка: в России тоже регулярно вспыхивают истории про нагрузку ЦОДов на регионы, и мэнский сценарий даёт удобную шпаргалку, чего ждать от публичной дискуссии. Что конкретно стоит начать делать уже сейчас: следить за новостями по Вирджинии и Техасу как по раннему индикатору; закладывать в годовые GPU-бюджеты диапазон неопределённости на случай роста цен; мониторить spot-рынки H100/B200 у российских провайдеров — там первый эффект виден быстрее всего.

Источники: Gadget Review, Bangor Daily News, Data Center Watch.

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.

В ноябре 2025 года Starcloud запустила первый спутник с GPU Nvidia H100 на борту — и впервые в истории провела обучение ИИ-модели прямо на орбите.

— — $170 млн Series A, оценка $1,1 млрд (всего привлечено $200 млн)

— Инвесторы: Benchmark, EQT Ventures, Monolith Power Systems

— Первый спутник с Nvidia H100 уже на орбите (ноябрь 2025)

— Следующий запуск: Starcloud-2 с чипом Blackwell и серверным блейдом AWS

— Цель: орбитальный дата-центр мощностью 5 ГВт

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

Зачем дата-центры в космосе

Земные дата-центры упираются в два ресурса: электричество и охлаждение. По данным SiliconANGLE, только в США строятся дата-центры суммарной мощностью более 25 ГВт. Энергосети не справляются, а политические и экологические ограничения тормозят строительство новых.

Космос решает обе проблемы принципиально иначе:

• Энергия. Солнечные панели на орбите генерируют, по расчётам Starcloud, в 5 раз больше энергии, чем наземные — нет ночи, облаков и атмосферного поглощения
• Охлаждение. В вакууме тепло отводится через радиаторы инфракрасным излучением. Это пассивные устройства — проще конструкция, меньше энергопотребление
• Масштабирование. Не нужно согласовывать строительство, подключение к электросетям, водоснабжение. Запустил модуль — подключил к кластеру

Что уже работает: Starcloud-1

Первый спутник Starcloud-1 (NORAD 66303) вышел на орбиту в ноябре 2025 года. На борту — GPU Nvidia H100, один из самых мощных чипов для ИИ-вычислений.

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

• Обучить собственную ИИ-модель (nanoGPT) — первое в истории обучение модели в космосе
• Запустить инференс Gemma — открытой модели от Google DeepMind
• Обработать данные с радарных спутников Capella Space в реальном времени

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

Один из GPU (Nvidia A6000) вышел из строя при запуске. Полученные данные о работе чипов в космических условиях повлияют на дизайн следующих поколений.

Дорожная карта: от одного спутника до 5 ГВт

Starcloud-2 — 2026–2027

Следующий спутник получит:

• Несколько GPU, включая чип Nvidia Blackwell и серверный блейд AWS
• Крупнейший коммерческий раскладной радиатор в истории космических запусков
• Солнечную батарею, генерирующую в 100 раз больше энергии, чем Starcloud-1
• Майнер Bitcoin (да, это не шутка)

Среди первых клиентов — Crusoe, строитель ИИ-дата-центров.

Starcloud-3 — запуск со Starship

Ключевой рубеж — Starcloud-3: трёхтонный космический аппарат мощностью 200 кВт, спроектированный под систему развёртывания Starship от SpaceX. По расчётам компании, это будет первый орбитальный дата-центр, конкурентный по стоимости с наземными — около $0,05 за кВт·ч.

Условие: коммерческие запуски Starship по цене ~$500 за килограмм. CEO Starcloud ожидает, что это произойдёт в 2028–2029 годах.

Финальная цель: 88 000 спутников

Долгосрочный план — созвездие из 88 000 спутников, формирующих распределённый дата-центр мощностью 5 ГВт. Солнечная батарея площадью около 16 км² будет питать модули, соединённые лазерными каналами связи. Загрузка данных — через оптоволоконные модули, доставляемые ракетами (петабайты за рейс).

Риски и ограничения орбитальных дата-центров

Масштаб амбиций вызывает обоснованный скептицизм:

• Starship ещё не летает коммерчески. Если сроки сдвинутся, Starcloud продолжит запуски на Falcon 9 — но о конкурентной стоимости энергии придётся забыть
• Синхронизация GPU. Тренинг крупных моделей требует сотен GPU, работающих синхронно. На орбите это значит либо гигантские аппараты, либо надёжные лазерные каналы между спутниками в строю
• Масштаб пропасти. Starlink — крупнейшая спутниковая сеть (10 000 аппаратов) — генерирует, по оценкам TechCrunch, около 200 МВт. Наземные дата-центры одних только США — более 25 ГВт. Разница в 125 раз
• SpaceX как конкурент. Компания Маска запросила разрешение на запуск миллиона спутников для распределённых вычислений — под нужды Grok и Tesla

Джонстон не считает SpaceX прямым конкурентом: «Они строят под свои внутренние нужды — Grok и Tesla. Мы — энергетическая и инфраструктурная компания для сторонних клиентов».

Кто ещё строит космические дата-центры

• Aethero — бортовые ИИ-вычисления для спутников, запустила первый GPU Nvidia Jetson в космосе (2025)
• SpaceX — запросила разрешение на миллион спутников для распределённых вычислений

Отдельно Nvidia на GTC 2026 представила космические чип-модули Vera Rubin Space-1, хотя ни один ещё не произведён.

Выводы

Starcloud — первая компания, которая запустила передовой ИИ-чип на орбиту и провела на нём обучение модели. $170 млн нового раунда и статус единорога за 17 месяцев показывают, что инвесторы верят в идею.

Но между одним H100 в космосе и 5-гигаваттным созвездием — пропасть размером с целую индустрию. Ближайшие 2–3 года покажут, удастся ли Starcloud преодолеть технологический разрыв — или космические дата-центры останутся красивой, но непрактичной мечтой.

Источники: TechCrunch, SiliconANGLE, Data Center Dynamics, Nvidia Blog

Корпоративное ядро: как оно устроено

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

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

В корпоративном сегменте энергетики ядро состоит из набора базовых сервисов: каталог, почта, коммуникации, документооборот, файловый слой, рабочие места и защита. Его фундамент – доменная структура, часто на Alt Domain или RedADM (службы на базе Samba DC): эти решения без сюрпризов проходят проверки совместимости и корректно работают с Kerberos и LDAP.

В реальных проектах переход к новому домену почти всегда начинается с гибридного режима. Старый Active Directory продолжает хранить SID и привязки приложений – без trust-связей массовую миграцию просто не запустить. Так домен становится точкой опоры для всех остальных компонентов. Почта – один из первых сервисов в корпоративном сегменте, который начинает жить по доменной модели: учетные записи, группы, права. И чаще всего именно она на прикладном уровне первой замечает любые отклонения в каталоге.

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

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

На уровне ниже находится невидимый пласт сервисов, на которых держится все ядро: DNS/DHCP домена, репликация, политики и настройки безопасности. Ошибки в любом из них могут спровоцировать каскад проблем – от задержек авторизации до потери доступа у части пользователей. На такие сценарии и заточены внутренние ППИ/ПМИ каждого компонента. Сценарии отрабатывают вручную, фиксируют протоколы, закрывают замечания – и только после этого переходят к пилоту.

Все это – «серверная» часть ядра. Но самый сложный участок начинается там, где архитектура сталкивается с пользователями – на АРМ (рабочих станциях). Здесь требуется подключение к каталогу, перенос профилей, миграция данных, проверка приложений, контроль целостности и унификация конфигураций.

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

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

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

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

Как выглядит внедрение на практике

На проектах внедрение почти всегда проходит в три этапа.

1. Прототипирование – создание в миниатюре будущей инфраструктуры и выявление несовместимостей.
2. Настройка паттернов – сборка образов, настройка групп, OU, профилей, fallback-логики.
3. Переходный период – введение dual-OS, выравнивание политик и подготовка к ОПЭ.

Прототипирование занимает от трех до шести месяцев. На этом этапе всплывает все, что невозможно увидеть на этапе проектирования. Где-то рабочие станции не загружаются на новых образах без обновления BIOS. Где-то плоттеры, сканеры и терминалы требуют ручной настройки. Профили Windows при переносе в Linux теряют ярлыки, MIME-ассоциации и политики. Если корпоративный домен в гибридном режиме, любое расхождение по времени, сбой Kerberos или конфликт GPO могут вывести из строя авторизацию на половине контура.

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

Но часть задач паттернами не решить – слишком много рабочих мест держится на Windows-приложениях. Поэтому dual-OS закрепляется как рабочая норма в корпоративном контуре: пользовательский профиль — в Linux, технологические приложения — в Windows, а архитектура постепенно приводится к единому набору политик, профилей и прав.

Откат в этом контуре обязателен. Пользователь должен иметь возможность вернуться в привычную среду в любой момент. На практике команда стремится уложиться в 10–15 минут – иначе миграционный участок становится неуправляемым

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

Информационная безопасность как каркас архитектуры

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

Виртуализацию разрешают только там, где можно контролировать изоляцию гостевых систем. Каналы управления – только внутри защищенных сегментов. Требования к виртуализации опираются на ГОСТ 56938: разделение зон исполнения, защита потоков управления, никаких «черных ящиков» в обновлениях.

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

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

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

И все это не имело бы смысла без гарантированного восстановления: система должна уметь возвращать себя в рабочее состояние через резервные копии, откат и проверенные сценарии. Например, компания в финсекторе после отказа всей инфраструктуры, потери ЦОД должна заработать через 2 часа.

Стандартизация через эксплуатацию

Когда среду удается стабилизировать на первой площадке, возникает главный вопрос: можно ли повторить тот же результат без пересборки с нуля? В энергетике – можно.

Конечно же, у компаний в разных регионах – своя история, парк оборудования или глубина легаси. Но архитектурные требования одинаковые везде. Они и формируют единый «слепок» корпоративного ядра при сохранении изоляции КИИ-контуров: правила для каталога, почты, коммуникаций и подготовки рабочих мест.

Если система стабильно прошла ОПЭ на одной площадке, она, как правило, так же ведет себя и на других

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

Импортонезависимое ядро – основа цифровой устойчивости

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

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

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

Конференция будет полезна всем, кто работает с ИИ. Владельцам бизнеса и топ-менеджерам — CEO, CIO, CTO, CDO, которые хотят получить измеримый результат от внедрения технологий, а также инженерам, архитекторам и DevOps-специалистам, которым предстоит интегрировать модели в существующую инфраструктуру.

О чем расскажут на конференции

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

Для бизнес-аудитории: окупаемость, риски и стратегия

Спикеры расскажут, как компании принимают решения о внедрении ИИ и переводят проекты из разряда экспериментов в работающие инструменты. Ключевые темы:

• Финансы и риски: сколько реально стоит внедрение ИИ-агентов и с какими подводными камнями можно столкнуться.
• Дорожная карта: как составить роадмап внедрения ИИ на базе платформенных решений, чтобы не потерять деньги и время.
• Управление знаниями: как использовать большие языковые модели, чтобы перестать терять экспертизу внутри компании.
• Масштабирование: как построить агентскую платформу и поставить внедрение ИИ-проектов на поток.
• Хайп или реальность: способен ли вайбкодинг заменить классические инструменты разработки?

Для технических специалистов: железо, код и безопасность

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

• Инфраструктуру: как выбрать серверное железо под разные ИИ-нагрузки и почему инференс классических моделей и LLM — это два разных мира, которые приходится сочетать на одной платформе.
• Разработку: чем SDLC для вероятностных систем отличается от классического и почему «просто написать код» больше недостаточно.
• Безопасность: как обеспечить безопасное использование генеративных технологий в рабочих процессах.

Что еще будет

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

Участие бесплатное, но нужна регистрация. С подробной программой можно ознакомиться на сайте мероприятия. Количество мест ограничено.

Реклама. Рекламодатель: АО «Селектел» ИНН 7810962785, erid: 2W5zFGwFjd3

Что будет на конференции

Мы подготовили четыре тематических трека, чтобы участники могли выбрать фокус под свои задачи. В программе — анонсы новых продуктов, круглые столы с лидерами рынка и разборы реальных кейсов.

Трек «Прикладной ИИ»

В этом треке расскажем о крупном обновлении платформы AI Factory. Среди новинок:

• расширение каталога Foundation Models — добавятся новые LLM-модели и модели для работы с графикой;
• инструменты для создания агентных систем без единой строчки кода.

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

Трек «Данные и аналитика»

Эксперты Cloud.ru расскажут о развитии платформы Data Platform для полного цикла работы с данными, поделятся планами и покажут клиентские кейсы. Также в рамках трека пройдет круглый стол о трендах в дата-сервисах на 2026 год:

• как выбрать стратегию;
• как выстроить инфраструктуру;
• как эффективно управлять данными и командой.

Трек «Приложения и разработка»

Здесь слушателей ждет анонс нового функционала автономного ИИ-помощника. Теперь он сможет по текстовой команде разворачивать и обслуживать сервисы на виртуальной машине.

Также в программе — серия докладов про защиту cloud native приложений. Спикеры разберут сценарии атак злоумышленников и способы минимизации угроз. Отдельно представят наш ИИ-инструмент для анализа и реагирования на инциденты в облаке.

Трек «Инфраструктура»

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

Кроме того, эксперты расскажут:

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

Чем еще заняться офлайн

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

Для тех, кто не сможет приехать, организуют онлайн-трансляцию.

Подробная программа и регистрация — на сайте конференции.