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

В том же выступлении Антон представил два новых сервиса для запуска моделей: Token Factory и Custom Inference. Оба продукта упрощают внедрение ИИ в процессы бизнеса: от маркетинга и поддержки клиентов до аналитики и разработки продуктов. Так, компании могут использовать готовые инструменты для работы с искусственным интеллектом без крупных вложений в инфраструктуру, разработку и найма узкоспециализированных команд.

Token Factory даёт доступ к моделям с открытыми весами, которые работают на инфраструктуре Selectel. Подключение через единый OpenAI-совместимый API, оплата в рублях за использованные токены. Самому разворачивать и обслуживать сервер под модель при этом не нужно. Сейчас сервис находится на стадии публичного тестирования (public preview).

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

aish: когда AI получает доступ к терминалу

На сцене показали и aish, AI-агента для администрирования в SELECTOS, серверной операционной системе Selectel. Агент работает в терминале, собирает контекст системы, предлагает команды и выполняет их после подтверждения человеком. Для подключения моделей используется OpenAI-совместимый API. Сам aish появился раньше конференции.

Данные для приложений и AI

Также показали семь облачных сервисов для работы с данными. Их можно объединять и комбинировать с уже имеющимися IaaS- и PaaS- решениями в зависимости от задач — от миграции и хранения до аналитической обработки и визуализации.

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

«Эксепто»: AI-агенты для бизнеса

На конференции представили «Эксепто», совместный проект Selectel и ИТМО, который занимается мультиагентными системами для бизнеса. У него есть решения для работы с документами, расследования инцидентов, создания приложений и закупочной аналитики.

Например, «Радар» помогает закупщикам собирать и сравнивать предложения поставщиков, а затем обосновывать выбор.

У вас, как и у меня, может возникнуть вопрос: как проверяется качество ответов с характеристиками товаров? Модель может выдумать характеристику товара, а клиент этого не заметит. Я задал этот вопрос на пресс-конференции. Генеральный директор «Эксепто» рассказал о двойной проверке и подтверждении данных разными источниками. При этом официальной документации система доверяет больше, чем отзывам в интернет-магазинах.

Когда агент читает чужие документы

В ответе про «Радар» речь шла о проверке данных. Андрей Давид, руководитель отдела продуктов клиентской безопасности Selectel, разбирал другой вопрос: какие действия разрешать агенту, который читает внешние документы.

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

Андрей предложил разделить роли: первый агент читает тестовое задание и передаёт результат в JSON, но не имеет доступа к почте и HR-системе. Второй работает с этими инструментами, получая структурированный результат вместо исходного документа. Фильтрация запросов и ответов через guardrails дополняет эти ограничения доступа.

Между докладами: игры

За участие в активностях давали селекоины, которые потом можно было обменять на мерч. Мерча было много и разного. Часть удалось добыть!

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

Вечером слушал про чёрные дыры

Владимир Сурдин и Алексей Семихатов записывали на сцене подкаст «Вселенная плюс». Говорили о чёрных дырах и информационном парадоксе. Было интересно послушать их вживую.

Я приятно и с пользой провёл время: за день получилось и разобраться в анонсах, и нормально отдохнуть между докладами. С удовольствием схожу ещё. Присоединитесь?

Реклама. Рекламодатель: АО «Селектел», ИНН 7810962785, erid: 2W5zFG32MoY

Код я не писал. Я был заказчиком и delivery-менеджером: рассказывал, что нужно и зачем, принимал решения, одобрял спецификации, проверял на тестовом окружении и говорил «выпускай». Всё остальное делал агент.

Это не история «AI написал за меня приложение». Это практическое руководство: как настроить процесс, чтобы агенту можно было доверять. Что поставить, что положить в CLAUDE.md, какими командами и фразами вести агента, какие проверки обязательны и на какие грабли мы уже наступили. Если захотите повторить, здесь должно быть всё, что нужно для старта.

Коротко в цифрах: 16 дней от первого коммита до prod, 18 изменений, 24 pull request, 2 выпуска в prod, 376 сценариев в спецификациях и 2 515 автотестов, руководства пользователя и администратора на двух языках со скриншотами и озвученными роликами.

Задача

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

Что получилось в итоге:

• Вход университетской учёткой Microsoft, две роли по двум группам Entra ID.
• Карточка пароля с владельцем; доступ можно дать коллеге, он может только смотреть и копировать.
• Каждый показ и копирование сначала пишутся в журнал. Не записалось — пароль не показывается.
• Отзыв доступа, уход сотрудника или снятие прав администратора помечают карточку «Change password»; владельцу и админам приходят письма и ежедневная сводка, пока пароль не сменят.
• Корзина, резервная копия всей базы, отчёт «кто что делал», ежедневная проверка по расписанию.

Инструменты

OpenSpec

Ставится глобально и инициализируется в репозитории:

Появляются папка openspec/ (спецификации specs/, изменения changes/) и команды /opsx:* для Claude Code. Совет: включите все workflow, а не профиль по умолчанию. explore, update иverify пригодятся:

В openspec/config.yaml есть два места, которые стоит заполнить сразу. context — то, что агент не выведет из кода: язык документов, стек, роли фреймворков. И rules — требования к каждому артефакту. У нас, например, так:

На последнем правиле держится вся проверка: сценарий → задача → тест.

Superpowers

Это плагин Claude Code с навыками. Я положил его копией в репозиторий (.claude/skills/superpowers/), чтобы версия была закреплена и одинакова у всех. Такой проектный плагин загружается, только если в Claude Code подтвердить доверие к папке; проверка —/plugin и superpowers@skills-dir в списке. Для облачных сессий есть хук SessionStart, который ставит тот же плагин.

CLAUDE.md — договор с агентом

Самое важное в настройке. Без него OpenSpec и Superpowers тянут в разные стороны: у Superpowers свои места для дизайна и планов (docs/superpowers/...), у OpenSpec — свои. Мой CLAUDE.md решает это явно. Что в нём:

1. Роли фреймворков. OpenSpec — «что», Superpowers — «как»; навыки Superpowers обязательны, артефакты OpenSpec обязательны для любого изменения поведения.
2. Где лежат артефакты. Таблица, которая переопределяет пути Superpowers: итог брейншторма идёт в proposal.md и design.md изменения, план — в plan.md той же папки, никакого docs/superpowers/. Там же: макеты, результаты живых проверок, видение, roadmap.
3. Жизненный цикл изменения из девяти шагов и жёсткие правила: никакого кода до одобрения артефактов, никакого кода без падающего теста, каждый #### Scenario: покрыт тестом.
4. Когда папка изменения не нужна: исправление ошибки по уже описанному поведению, рефакторинг, документы, CI.
5. Языки. Спецификации и обсуждения на русском, код и коммиты на английском; ключевые слова OpenSpec (### Requirement:, #### Scenario:, WHEN/THEN) остаются английскими, иначе валидатор не поймёт.
6. Ветки и PR, разбор безопасности перед каждым PR, проверка документации.
7. Раскладка кода. Подробная карта, которую агент поддерживает сам.

Каждое моё решение по процессу я прошу записать в CLAUDE.md с датой («решение автора, 01.11.2026»). Через неделю это очень помогает и мне, и агенту.

Видение и дорожная карта

Начал я не с кода, а с интервью. Агент задавал вопросы по одному: кто пользуется, что делаем, когда человек уходит, кто видит чужие пароли, нужен ли экспорт. Так появился docs/vision.md из трёх частей: рассказ о продукте, ответы интервью и отдельный раздел «Решения Claude (на подтверждение автора)», где агент честно отделил свои технические предположения от моих решений. Например: envelope-шифрование через Key Vault, проверка доступа раз в сутки, а не на каждый запрос, Static Web Apps Free плюс отдельный Function App ради почти нулевой стоимости.

Потом видение режется на изменения. Это docs/roadmap.md, таблица с номером, именем, тем, что даёт изменение, зависимостями, статусом и ссылкой на PR. У нас вышло 17 номеров (и одно вставное 3a). Каждое изменение — один полный цикл до prod. Небольшие идеи по ходу агент складывает в бэклог там же.

Один цикл на живом примере

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

1. Брейншторм

берем в работу документацию, начинай интервью

Агент запускает superpowers:brainstorming: один вопрос за раз, без списков вариантов, и периодически пересказывает понятое по 200–300 слов. Отвечать можно как угодно, хоть голосом:

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

На брейншторме появились решения, до которых я бы сам не дошёл сразу: руководство администратора видно только админам, переключатель EN/RU запоминается в браузере, кнопка Help не показывается на формах, а Markdown рендерится без сырого HTML (ради безопасности: у нас строгий CSP).

2. Описание изменения

/opsx:ff создаёт сразу все артефакты: proposal.md, дельта-спецификации, design.md,tasks.md (а по шагам их создаёт /opsx:continue). Читать стоит в первую очередь сценарии: это контракт. Вот два настоящих:

Если меняются экраны, агент рисует макет. В docs/mockups/ лежат статические экспорты всех одобренных экранов и писем.

3. Ворота ревью

Агент отдаёт design.md свежему субагенту с вопросом «можешь ли ты построить это, не спрашивая автора?» и приносит только те вопросы, на которые могу ответить лишь я. Плюсopenspec validate. Дальше моё слово:

подтверждаю

До этого момента рабочего кода нет. Это жёсткое правило CLAUDE.md.

4. План

superpowers:writing-plans делает plan.md: задачи с точными файлами, интерфейсами и тестами, каждая ссылается на пункт tasks.md и сценарии. В №17 вышло 14 задач. Агент спрашивает, как выполнять: субагентами (свежий агент на задачу и рецензент после неё) или сам в сессии. Субагенты дороже, но надёжнее; я почти всегда выбираю их.

5. Реализация

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

Если требования меняются по ходу, сначала правятся артефакты, потом план, потом код. Так было с роликами. Первый вариант был набором кадров, и я написал:

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

Агент выполнил /opsx:update: поправил спецификацию (озвучка на языке руководства, курсор, кольцо клика, субтитры), design и tasks, потом план, и только потом код.

6. Проверка

superpowers:verification-before-completion прогоняет все проверки на чистом дереве, а/opsx:verify сверяет: каждая задача сделана, каждое требование реализовано, у каждого сценария есть тест. Результат агент пишет в verify.md таблицей «сценарий → тест». В №17 получилось 32 из 32.

7. Живая проверка на dev

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

Агент публикует на claude.ai страницу-чек-лист: по строке на пункт, у каждого статус и заметка. Я прохожу её на живом dev и отмечаю. Можно и иначе:

пожалуйста пройди этот чек лист сам

Тогда агент проходит пункты в моём Chrome через Claude in Chrome. Вход в систему делаю я — агент пароли не вводит. После отметок агент читает страницу обратно и переносит каждый пункт вverify.md, раздел «Живая проверка на dev».

Именно здесь нашлось два настоящих бага, которые никакие юнит-тесты не ловили: субтитры роликов не показывались, потому что Vite встраивал маленькие .vtt как data:-адреса, а наш CSP их запрещает; после исправления Static Web Apps отдавал .vtt с типом application/octet-stream. Оба исправлены через TDD и перепроверены на dev.

8. Архив и PR

/opsx:archive вливает дельта-спецификации в openspec/specs/, и теперь это официальное описание системы. Затем разбор безопасности (ниже), PR в dev, CI. В приложении Claude можно включить Auto-fix: оно будит агента, если CI упал или пришли замечания.

Да, слей

9. Выпуск

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

Да, выпускай

Агент делает разбор безопасности dev против main, открывает PR dev → main, следит за деплоем prod и smoke-проверкой, а потом публикует короткий чек-лист prod на 3–5 пунктов. Его итог тоже ложится в verify.md.

Барьеры качества

Про разбор безопасности отдельно. Платного API-ключа для GitHub Action у меня нет, поэтому разбор идёт внутри сессии: встроенный в Claude Code /security-review по ветке плюс правила проекта вdocs/security-review.md. Там записано, где вообще может существовать секрет в открытом виде, какие параметры шифрования неизменны, как устроена авторизация и какие строки в инфраструктуре нельзя трогать без решения автора. Подтверждённые находки исправляются до PR через TDD, результат пишется в описание PR.

Инфраструктура и CI/CD

• Azure, два окружения (dev и prod), каждое — resource group, описанная одним шаблоном Bicep. Static Web Apps Free для фронтенда, Function App на Flex Consumption для API, Cosmos DB serverless, Key Vault, Application Insights. Всё с оплатой за использование: простаивающее окружение почти ничего не стоит.
• Без ключей и секретов. API ходит в Cosmos DB, Key Vault и Graph одной managed identity, локальная аутентификация Cosmos и Storage выключена. Почта уходит только от одного ящика через Exchange RBAC for Applications, а не через широкое право Mail.Send.
• GitHub Actions через OIDC. В GitHub Environments лежат только идентификаторы, не секреты. CI на каждый PR; push в dev деплоит dev, push в main — prod; ветки защищены ruleset.
• Разовая настройка окружения описана в docs/azure-setup.md и автоматизирована скриптом для Azure Cloud Shell. Тесты инфраструктуры проверяют, что документ и скрипт совпадают с шаблоном Bicep.

Документация из живого продукта

Это я тоже пробовал впервые. Руководства пользователя и администратора написаны в Markdown в репозитории, на двух языках, с одинаковыми разделами (это проверяет тест). Они встраиваются в приложение при сборке и открываются по кнопке Help.

Скриншоты и ролики агент снимает сам на dev:

1. Создаёт на dev показательный набор данных по описанию в docs/guides/demo-data.md — карточки, папки, доступы, пометки. Никаких настоящих паролей.
2. Через Claude in Chrome открывает нужные экраны; маленький скрипт на странице показывает демо-сотрудника как «User».
3. Для роликов снимает кадр на каждый шаг, а скрипт make-clip.py собирает видео: курсор едет к месту нажатия, на клике кольцо, нажатая клавиша видна плашкой, голос macOS say читает текст шага (Ava для английского, Milena для русского), те же фразы становятся субтитрами WebVTT. На выходе H.264 до 2 МБ.
4. Сценарий каждого ролика лежит в репозитории как JSON, поэтому переснять после изменения интерфейса — одна команда на ролик.

Правила, которые я задал агенту

Все они записаны в CLAUDE.md или в памяти агента и выполняются без напоминаний:

• worktree — только с моего согласия;
• ничего не ставить без спроса;
• никогда не вводить пароли, вход делаю я;
• не удалять данные навсегда (кнопку «Delete forever» нажимаю я);
• не менять системные настройки (улучшенные голоса для роликов я скачал сам);
• выпуск в prod — только после моего явного «да», каждый раз.

Грабли

• Маршрут Azure Functions, начинающийся с admin или runtime, хост просто не загружает, адрес отвечает 404 без ошибок.
• Таймеры на Flex Consumption под Linux работают только в UTC. 9:00 по Ташкенту это 0 0 4 * * *.
• После смены разрешений Graph токен managed identity может жить в кэше до 24 часов.
• Права Exchange RBAC for Applications применяются от 30 минут до 2 часов.
• Удалённый без --force Log Analytics держит имя 14 дней, удалённый Key Vault — 90.
• Локального входа нет (MSAL, CORS только на адрес SWA), поэтому поведение проверяется тестами с подменой MSAL и вживую на dev.
• Vite встраивает маленькие файлы как data:, строгий CSP их блокирует.
• Тесты с датами зависят от часового пояса: веб-тесты у нас закреплены на UTC.

Цифры

Тестов по объёму вдвое больше, чем кода. Это не перекос, а цена доверия к агенту.

Если хотите повторить

1. Начните с CLAUDE.md. Распределите роли фреймворков и переопределите пути артефактов, иначе документы расползутся.
2. Сначала интервью и видение, потом нарезка на маленькие изменения, каждое — до prod.
3. Читайте сценарии, а не код. Сценарий — это контракт и будущий тест.
4. Не пропускайте живую проверку. Самые неприятные баги нашлись именно там.
5. Просите записывать решения с датой в CLAUDE.md, vision.md, design.md.
6. Держите барьеры даже для мелочей. Разбор безопасности и проверка документации идут перед каждым PR, даже если в нём только тексты.
7. Оставьте за собой решения. Одобрение, приёмка, выпуск, пароли и удаление данных — ваши. Агент работает быстро именно потому, что эти решения принимает человек.

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

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

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

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

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

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

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

Что такое пользовательский образ

Пользовательский образ — это полная копия диска, из которой облачная платформа умеет запускать виртуальные машины. Клиент загружает образ операционной системы в каталог, и платформа создает из него ВМ. Для платформы это такой же образ, как стандартные Ubuntu, AlmaLinux, Debian или сборки с ispmanager, которые уже есть в каталоге Рег.облака.

Для большинства задач готовых образов достаточно: почти любое ПО, которое можно поставить, просто ставят поверх стандартной системы. Пользовательские образы нужны в другом случае — когда требуется дистрибутив или ОС, которых в каталоге нет (Arch Linux, OpenSUSE), или сборка с кастомом вроде пересобранного Hardened-ядра.

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

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

Перенос через образ оправдан, когда:

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

Настройка с нуля через IaC оправдана, когда:

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

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

Сценарии, в которых образ — основной инструмент

Перенос между провайдерами

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

Golden image и одинаковый старт всех серверов

В DevOps-процессах команды давно работают с golden image — заранее подготовленным эталонным образом. Суть golden image не столько в том, что в нем что-то предустановлено, сколько в том, что он один и заведомо известно, что внутри. Это дает понятную и, что важнее, одинаковую стартовую точку для всех серверов.

Дальше есть варианты. Можно поднимать серверы из такого образа и докручивать их инструментом управления конфигурациями. А можно зашить весь софт и настройки прямо в образ — тогда инструмент управления конфигурациями вообще не нужен: конфигурацию подтягивают через cloud-init, а корень можно сделать read-only, что повышает безопасность и снижает шанс проблем внутри ВМ. Образ ведь тестируют до того, как пустить в работу.

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

Кастомные конфигурации ОС

Через пользовательский образ запускают конфигурации, которых нет в стандартном каталоге: read-only root filesystem, преднастроенные агенты мониторинга, специализированные сборки Linux, нестандартную разметку дисков. Это случаи, когда маркетплейс готовых образов закрывает базовые потребности, но не позволяет воспроизвести особенности существующей системы без ручной донастройки.

Что проверить перед загрузкой образа

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

• Драйверы виртуальных устройств. В образе должны быть драйверы виртуального диска и сетевого адаптера, используемых облачной платформой. Для Linux обычно нужны драйверы virtio, которые в большинстве современных дистрибутивов уже включены в ядро. Если драйвер диска отсутствует или недоступен на этапе загрузки, ОС может не загрузиться. Если отсутствует сетевой драйвер — ВМ может загрузиться, но сеть работать не будет.
• initramfs. Модули ядра для виртуальных устройств должны быть собраны в initramfs, иначе система не увидит свой корневой раздел при первом старте.
• Cloud-init. Рекомендуется установить и включить cloud-init. Он используется для первоначальной настройки ВМ: добавления SSH-ключей, настройки пользователя, hostname и сети. Без cloud-init образ может загрузиться, но автоматическая настройка ВМ средствами облака работать не будет.
• Формат диска. qcow2 — основной для QEMU/KVM, поддерживает copy-on-write и снапшоты. raw — бинарная копия диска, проще, но образы получаются заметно больше. Конвертация — через qemu-img convert.
• Размер. В Рег.облаке лимит — 30 ГБ. Если образ больше, его либо уменьшают (чистят кеши, логи, временные файлы, незанятое место), либо запрашивают увеличение лимита у поддержки.
• Серверные SSH-ключи. Зашитые в исходную систему ключи лучше удалить перед снятием образа — тогда sshd сгенерирует серверные ключи сам, а клиентские для доступа подтянет cloud-init. Иначе на новой машине окажется чужой identity — и в audit-логе, и в known_hosts.
• Режим загрузки и загрузчик. Убедитесь, что в образе установлен рабочий загрузчик и режим загрузки образа соответствует режиму, поддерживаемому облаком — BIOS или UEFI.
• Архитектура ОС. Образ должен соответствовать архитектуре виртуальных машин облака, например x86_64 / amd64.

Как технически устроена загрузка в Рег.облаке

Загрузка идет через S3: multipart upload и presigned URL, без постоянных ключей доступа. Это стандартный механизм для больших файлов — он устойчив к разрывам соединения и легко вписывается в CI/CD-пайплайн или скрипт сборки инфраструктуры.

Дальше платформа кладет образ в Glance — компонент OpenStack для хранения образов виртуальных машин и их метаданных. При запуске сервера платформа берет образ из Glance, передает гипервизору, и тот создает диск ВМ. В метаданных Glance хранит тип ОС, архитектуру, формат диска и параметры загрузки — те, что задал клиент при загрузке.

Когда образа уже мало

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

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

Поэтому пользовательские образы не заменяют Terraform или Ansible, а встраиваются в автоматизированный пайплайн. Например, базовый образ собирают через Packer, загружают в облако, а дальнейшее развертывание и настройку выполняют через IaC-инструменты и cloud-init. Так воспроизводимость инфраструктуры сочетается с быстрым запуском уже подготовленных систем.

Итого

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

Если сервер настроили один раз и он годами работает без изменений, перенос через образ обычно выгоднее, чем настройка с нуля. Если же сервер всё это время велся через Ansible и так же обновлялся, выгода уже не очевидна, и стоит смотреть в сторону IaC. При этом образы не противоречат DevOps-подходу: они хорошо ложатся на golden image-пайплайны, автоматическую загрузку через S3 и CI/CD.

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

Один и тот же облачный сервер с 2 vCPU и 4 ГБ RAM у российских провайдеров стоит от 1 994,40 до 3 230,91 ₽ в месяц, а в эту цену по-разному входят IP-адрес, трафик и НДС. Собрали четыре облака и посчитали у каждого одну конфигурацию по публичным тарифам.

Коротко о главном

• Сравниваемая конфигурация: 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe, Ubuntu 24.04, один публичный IPv4, регион Москва.
• У всех участников оплата за фактическое время работы: посекундная или почасовая. Различаются плата за трафик, IP и выключенный сервер.
• Трафик не тарифицируется у immers.cloud и Timeweb Cloud, у Selectel бесплатны 3 ТБ в месяц, у Yandex Cloud — 100 ГБ, у Cloud.ru исходящий трафик платный.
• В подборке: immers.cloud, Timeweb Cloud, Selectel, Cloud.ru и Yandex Cloud.

1. immers.cloud — ядра без оверселлинга

Российское облако с собственным ЦОД Tier III в Москве на иммерсионном охлаждении. Основная специализация — GPU-серверы на 13 моделях NVIDIA, но для сравниваемой конфигурации есть CPU- и NVMe-линейки. Физические ядра закрепляются за одним клиентом.

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

• «КС Авто» запустила круглосуточную модерацию спама, фото и текстов: Ollama на 3 × RTX 4090 с NVMe, без Kubernetes. По данным провайдера, система заменила работу 15 сотрудников.
• IBS собрала R&D-песочницу на GPUStack и vLLM поверх A100, RTX 3090 и RTX 4090: 11 активных инстансов обслуживают 14 моделей.
• Бэкенд, тестовые и staging-окружения на CPU-конфигурациях: неиспользуемую ВМ можно перевести в архив (shelve) и платить только за хранение диска и IP.

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

Больше сотни образов: Ubuntu 16.04–24.04, Debian 8–13, CentOS 7–10 и Stream, Fedora 40 и 41, Windows Server 2019, 2022 и 2025 Standard. В маркетплейсе — сборки с CUDA, Docker/NGC и vLLM.

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

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

CPU-серверы работают на Intel Xeon Gold 2-го, 3-го и 5-го поколений. NVMe-линейка использует диски Samsung PM1735 и PM1743: провайдер заявляет до 360 000 IOPS на случайное чтение и до 7 100 МБ/с на последовательное, у SATA SSD — до 75 000 IOPS. Скорость сети — до 20 Гбит/с. Управление через панель или нативный API OpenStack релиза Zed, есть S3-хранилище. Зона доступности одна — Москва.

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

Поддержка работает круглосуточно: чат на сайте, Telegram, MAX и почта, для юрлиц есть менеджер. Провайдер заявляет среднее время ответа не более 5 минут. Гайды собраны в FAQ и на YouTube-канале.

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

• Сравниваемая конфигурация nvme.2.4.40 — 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe — 2,62 ₽/час или 1 886,40 ₽/мес; публичный IPv4 — 108 ₽/мес по данным конфигуратора, итого 1 994,40 ₽/мес.
• Тарификация посекундная, минимальный платёж — 100 ₽. Скидка за предоплату: 360 дней — 25%.
• Трафик не тарифицируется. Снимки дисков — около 2 ₽ за ГБ в месяц.
• Выключенная ВМ оплачивается за диски и IP, vCPU и RAM не тарифицируются.
• Тестовый период — до 30 дней. Квоты нового аккаунта — 16 vCPU, 128 ГБ RAM и 4 ВМ, расширяются через поддержку.
• Root в Linux-образах отключён, права суперпользователя — через sudo. Панелей cPanel и ISPmanager нет; снимки и Rescue — только для ВМ с локальным диском.
• Дата-центр один — в Москве. SLA — 99,9% с компенсацией простоя.
• Для юрлиц — оферта или договор с ЭДО, УПД выставляются 5-го числа. НДС не начисляется (ст. 145.1 НК РФ).

Официальный сайт: immers.cloud

2. Timeweb Cloud — готовые тарифы и конфигуратор

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

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

• Сайты, веб-сервисы и интернет-магазины, которым нужна фиксированная месячная цена сервера.
• Запуск и тестирование стартапов: серверы создаются через панель, API, CLI или Terraform.
• Команды, которым рядом с сервером нужны управляемые базы данных и Kubernetes.

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

Готовые образы Ubuntu, Debian, CentOS, Windows, Arch Linux и Astra Linux CE, больше 30 сборок в маркетплейсе. Свой образ можно загрузить в форматах iso, vmdk, vhd, vhdx, vdi, raw, img и qcow2. Виртуализация — KVM.

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

Локации — Москва, Санкт-Петербург, Новосибирск, Франкфурт, Амстердам и Алматы, дата-центры уровня Tier III. Линейки Premium и Ultra работают на 3,3 ГГц, High CPU — на 5,5 ГГц, есть Dedicated CPU. В экосистеме — облачные PostgreSQL, MySQL, Valkey, MongoDB, ClickHouse и OpenSearch, Kubernetes, S3, балансировщики, CDN и защита от DDoS. Платформа включена в реестр российского ПО, запись № 15725 от 05.12.2022.

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

Круглосуточно в Telegram, чате, по почте и телефону 8 800 700-32-92. Провайдер заявляет ответ в течение 15 минут.

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

• Сравниваемая конфигурация в линейке Premium, Москва — 2 × 3,3 ГГц, 4 ГБ RAM, 40 ГБ NVMe, IPv4 — 3 000 ₽/мес в конфигураторе; без IPv4 — 2 800 ₽/мес.
• Ближайший готовый тариф MSK 50 — 2 × 3,3 ГГц, 4 ГБ RAM, 50 ГБ NVMe, канал 1 Гбит/с — 3 840 ₽/мес.
• Тарификация почасовая, минимальный платёж — 500 ₽. Скидок за длительную оплату на страницах облачных серверов нет.
• Трафик бесплатный и безлимитный. IPv4 платные, IPv6 в Москве и Санкт-Петербурге бесплатные.
• Бэкапы оплачиваются по объёму диска, до 99 копий; снапшоты бесплатные и хранятся 7 дней.
• Бесплатное тестирование — по индивидуальному запросу в поддержку, бонусы начисляются на аккаунт.
• Диск можно только увеличивать. SLA — 99,98%. Работа по 152-ФЗ, ЭДО через СБИС.

Официальный сайт: timeweb.cloud

3. Selectel — оплата по ресурсам

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

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

• Продакшн с требованиями 152-ФЗ до УЗ-1, PCI DSS или ГОСТ Р 57580.
• Среды разработки, CI/CD и нагрузочное тестирование: «Заморозка» и прерываемые ВМ снижают плату за простаивающие серверы.
• Проекты с геораспределением: пулы ru-6a, ru-6b и ru-6c связаны общей сетью.

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

Образы Ubuntu, Debian, Windows, CentOS, Alma Linux, Rocky Linux, Fedora, Fedora CoreOS, Oracle, Astra Linux и собственная SelectOS, можно загрузить свой. Линейки: Standard, Shared с долей vCPU 10, 20 или 50%, HighFreq на Intel Xeon Gold 6354 и AMD EPYC 9474F до 3,6 ГГц, GPU, Dedicated и произвольные конфигурации до 232 vCPU и 900 ГБ RAM.

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

Дата-центры Tier III в Москве, Санкт-Петербурге и Ленинградской области, партнёрская площадка в Новосибирске. Сетевые SSD — до 75 000 IOPS, у локальных дисков задержка до 1 мс. Защита от DDoS L3/L4 включена в стоимость. В экосистеме — Managed Kubernetes, облачные базы данных, S3, балансировщики, CDN и резервное копирование; управление через панель, API и Terraform.

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

Бесплатно и круглосуточно: тикеты, почта и телефон 8 800 555-06-75. Провайдер берёт обращение в работу менее чем за 15 минут и решает 70% тикетов в первые 12 часов.

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

• Сравниваемая конфигурация в пуле ru-7a (Москва), линейка Standard — 2 vCPU по 735,19 ₽, 4 ГБ RAM по 267,34 ₽, 40 ГБ локального NVMe по 12,54 ₽ за ГБ и прямой публичный IP за 189,57 ₽ — 3 230,91 ₽/мес с НДС 22%.
• Тарификация почасовая. Выключенный сервер оплачивается полностью; в «Заморозке» не тарифицируются vCPU, RAM и GPU.
• Бесплатного тестового периода нет; минимальное пополнение — 100 ₽.
• Трафик: 3 ТБ в месяц бесплатно, сверх лимита — 0,8962 ₽ за ГБ.
• Бэкапы — 4,50 ₽ за ГБ в месяц. Скидки за предоплату в прайсе облачных серверов не указаны.
• SLA — 99,98%; за каждые 30 минут простоя компенсируется 0,5% стоимости услуги.

Официальный сайт: selectel.ru

4. Cloud.ru — гарантированная доля vCPU

Облачный провайдер с платформой Evolution: виртуальные машины тарифицируются почасово, а гарантированную долю процессорного времени можно выбрать — 10, 30 или 100%. Инфраструктура размещена в девяти дата-центрах Tier III в России.

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

• Среды разработки и тестирования: группы ВМ с оплатой по факту использования.
• Временные проекты: ресурсы для подрядчиков без доступа к основным системам.
• Сезонные пики: ресурсы добавляют вручную в консоли или автоматически через API.

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

Виртуальные машины Evolution Compute с дополнительными дисками, подсетями и IP-адресами. Подключение — по SSH-ключам, для аварийных случаев есть веб-консоль VNC. Рядом можно запустить Managed Kubernetes, Object Storage и управляемые PostgreSQL, Redis, Kafka, ClickHouse и OpenSearch.

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

ВМ работают на Intel Xeon Gold 6248R. Города и адреса площадок провайдер не публикует. Управление через консоль, публичный API и Terraform-провайдер; CLI и Python SDK заявлены как следующие инструменты. Для ML есть сервисы ML Inference и Foundation Models.

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

Бесплатный тариф поддержки 24/7: телефон 8 800 444-24-99, почта, личный кабинет и чат в Telegram. Заявлено: на звонки отвечают в первые минуты, на письма — в течение 15 минут, вопросы решают до 12 часов, критичные — до 4 часов.

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

• Сравниваемая конфигурация — ВМ 2vCPU/4GB RAM со 100% долей vCPU — 2,9707 ₽/час, диск SSD NVMe — 0,01586 ₽ за ГБ в час, публичный IP — 0,2074 ₽/час; цены с НДС по тарифам от 28 сентября 2026 года. За 720 часов — 2 745 ₽.
• Та же ВМ с долей vCPU 30% — 1,7985 ₽/час, с долей 10% — 0,9902 ₽/час.
• Исходящий трафик через публичный IP платный — 0,00366 ₽ за МБ.
• Новым пользователям — 4 000 бонусных рублей, юрлицам и ИП по заявке — 20 000 бонусов. Виртуальные машины в бесплатный объём Free Tier не входят.
• Минимальное пополнение — 100 ₽. SLA сервиса — 99,9%.

Официальный сайт: cloud.ru

5. Yandex Cloud — сервисы экосистемы Яндекса

Облачная платформа Яндекса: виртуальные машины Compute Cloud работают рядом с управляемыми базами данных, Kubernetes, Object Storage и ML-сервисами в одном аккаунте. Оплата посекундная, а время, когда ВМ выключена, по вычислительным ресурсам не тарифицируется.

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

• Веб-проекты, которым рядом с ВМ нужны управляемые сервисы той же платформы.
• Тестирование и прототипирование: ВМ создают через консоль, CLI, API, SDK или Terraform.
• Высокопроизводительные вычисления на прерываемых ВМ.

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

ВМ на платформах Intel Ice Lake, Cascade Lake, Broadwell, AMD Zen 3 и Zen 4 с гарантированной долей vCPU 20, 50 или 100%. Образы — из Cloud Marketplace, включая готовые наборы вроде LAMP; для автоматизации поддерживаются Terraform и Packer. Есть ВМ с GPU NVIDIA Tesla V100 и A100.

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

ВМ размещаются в зонах доступности региона Россия в дата-центрах Яндекса; города зон в документации не указаны. Диски — сетевые HDD и SSD, для SSD IO провайдер заявляет до 75 000 IOPS на диск; локальные SSD есть только на выделенных хостах. Провайдер заявляет соответствие 152-ФЗ с первым уровнем защищённости.

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

Три тарифа поддержки — Базовый, Бизнес и Премиум. На Базовом заявлен ответ в чате и Telegram за 15 минут, на запрос в Центре поддержки — за 24 часа; чат на этом тарифе работает по будням с 8:00 до 21:00 по Москве. С 13 октября 2026 года переход на тариф Бизнес временно недоступен.

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

• Сравниваемая конфигурация на Intel Ice Lake — 2 × 100% vCPU по 1,24 ₽/час и 4 ГБ RAM по 0,33 ₽/час (пример расчёта в документации), 40 ГБ сетевого SSD по 0,0182 ₽ за ГБ в час (тарифы на 01.01.2026), публичный IP — 0,26352 ₽/час. За 720 часов — около 3 449,89 ₽ с НДС, без платы за образ ОС.
• Тарификация посекундная. Выключенная ВМ не оплачивается за vCPU и RAM, диски тарифицируются всегда.
• Исходящий трафик: первые 100 ГБ в месяц бесплатно, дальше платно; входящий не тарифицируется.
• Снимки дисков — 0,0051 ₽ за ГБ в час. Неактивный статический IP дополнительно стоит 0,34038 ₽/час.
• Стартовый грант: на странице сервиса — до 4 000 ₽ физлицам и до 10 000 ₽ юрлицам, но в документации сказано, что пробный период и стартовый грант для новых клиентов недоступны.
• SLA — 99,95% на доступность ВМ.

Официальный сайт: yandex.cloud

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

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

• Цена конфигурации в месяц: immers.cloud — 1 994,40 ₽ (1 886,40 ₽ за nvme.2.4.40 и 108 ₽ за IPv4, без НДС); Cloud.ru — 2 745 ₽ за 720 часов с НДС, без исходящего трафика; Timeweb Cloud — 3 000 ₽ в конфигураторе Premium; Selectel — 3 230,91 ₽ с НДС в пуле ru-7a; Yandex Cloud — около 3 449,89 ₽ с НДС за 720 часов на Intel Ice Lake с сетевым SSD.
• Модель оплаты: immers.cloud и Yandex Cloud — посекундно; Timeweb Cloud, Selectel и Cloud.ru — почасово.
• Скидка за длительную оплату: immers.cloud заявляет 25% при предоплате за 360 дней; у Timeweb Cloud, Selectel и Cloud.ru на страницах облачных серверов скидок за предоплату нет; у Yandex Cloud в правилах тарификации Compute Cloud скидки за предоплату не описаны.
• Выключенный сервер: у immers.cloud и Yandex Cloud vCPU и RAM не тарифицируются, диски и IP оплачиваются; у Selectel выключенный сервер оплачивается полностью, «Заморозка» снимает плату за vCPU и RAM.
• Трафик: immers.cloud и Timeweb Cloud — без тарификации; Selectel — 3 ТБ в месяц бесплатно, сверх — 0,8962 ₽ за ГБ; Yandex Cloud — 100 ГБ исходящего в месяц бесплатно; Cloud.ru — 0,00366 ₽ за МБ исходящего трафика.
• Диски: immers.cloud заявляет до 360 000 IOPS на локальном NVMe; Selectel — задержку до 1 мс на локальных дисках и до 75 000 IOPS на сетевых SSD; Yandex Cloud — до 75 000 IOPS на SSD IO, локальные диски только на выделенных хостах; Timeweb Cloud и Cloud.ru IOPS для NVMe на страницах продукта не публикуют.
• Регионы: immers.cloud — только Москва; Timeweb Cloud — Москва, Санкт-Петербург, Новосибирск, Франкфурт, Амстердам и Алматы; Selectel — Москва, Санкт-Петербург, Ленинградская область и Новосибирск; Cloud.ru и Yandex Cloud — дата-центры в России без указания городов.
• SLA: Timeweb Cloud и Selectel — 99,98%; Yandex Cloud — 99,95%; immers.cloud и Cloud.ru — 99,9%.
• Тест и бонусы: immers.cloud — тестовый период до 30 дней; Timeweb Cloud — бонусы по запросу в поддержку; Cloud.ru — 4 000 бонусных рублей новым пользователям; у Yandex Cloud данные о стартовом гранте на сайте и в документации расходятся; Selectel — теста нет, минимальное пополнение 100 ₽.
• Root и автоматизация: у immers.cloud права суперпользователя через sudo и нативный API OpenStack; у Timeweb Cloud — API, CLI и Terraform; у Yandex Cloud — CLI, API, SDK, Terraform и Packer; у Selectel и Cloud.ru — API и Terraform.
• Юридика: immers.cloud работает без НДС и имеет сертификат ГОСТ Р ИСО/МЭК 27001-2021; Timeweb Cloud заявляет работу по 152-ФЗ и включён в реестр российского ПО; Selectel соответствует 152-ФЗ до УЗ-1 и предлагает аттестованные сегменты для ГИС; Yandex Cloud заявляет 152-ФЗ с УЗ-1; Cloud.ru заявляет соответствие 152-ФЗ.

Вывод

Одна и та же конфигурация 2 vCPU, 4 ГБ RAM и 40 ГБ NVMe стоит у пяти провайдеров от 1 994,40 до 3 449,89 ₽ в месяц. На итоговый счёт сильнее цены за ядро влияют IP-адрес, трафик, НДС и то, как тарифицируется выключенный сервер.

Если важны выделенные ядра, NVMe и возможность позже перейти на GPU в том же аккаунте, смотрите на immers.cloud. Если нужны фиксированная месячная цена и несколько локаций, включая зарубежные, — Timeweb Cloud. Если проект работает с персональными данными высокого уровня защищённости или ГИС — Selectel. Если нагрузка неравномерная и можно платить за долю процессорного времени — Cloud.ru. Если рядом с сервером нужны управляемые сервисы одной большой платформы — Yandex Cloud. Для тестовых сред с паузами у immers.cloud есть shelve, который снимает плату за vCPU и RAM. Перед покупкой проверьте производительность под своей нагрузкой: используйте тестовый период или бонусы, если они доступны, или начните с минимального платежа.

Как работает базовая станция, и что делает платформа

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

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

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

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

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

Создание платформы — только часть работы команды. Инженеры также синхронизируют вычислительные модули и создают тестовое окружение для проверки компонентов на производстве YADRO Фаб Дубна.

Технологии, тестирование и требования к надежности

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

Требования к надежности здесь очень высокие: базовые станции YADRO обеспечивают операторам доступность на уровне 99,999% — это называют «правилом пяти девяток». Такой показатель означает, что система должна оставаться доступной практически все время. Для этого инженеры внедряют механизмы аварийного обнаружения и автоматического восстановления, которые позволяют сети продолжать работу, даже если один из компонентов выходит из строя.

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

Такие задачи требуют от команды одновременно видеть архитектуру системы целиком и глубоко разбираться в отдельных компонентах. Основная часть кода написана на C++, для скриптов используется Bash, а для работы с C++ — библиотека SObjectizer.

Организация работы и развитие команды

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

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

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

Если вам интересно узнать больше о разработке в области телекоммуникаций, рекомендуем бесплатный онлайн-курс от команды YADRO «Телеком: ключевые технологии и принципы». Вы узнаете, как взаимодействуют программная и аппаратная части, как формируются требования и спецификации, как проводятся интеграция и тестирование. Курс бесплатный и доступен в записи.

Реклама. Рекламодатель: ООО «КНС ГРУПП» ИНН 7701411241, erid: 2W5zFJrmwXG

В каталоге уже сейчас доступны для инференса Qwen3.8-27B, DeepSeek-V4-Flash-0731, Qwen3.6-35B-A3B, а также OCR и text-to-speech модели: Unlimited-OCR, PaddleOCR-VL-1.6, whisper-v3-large и другие модели. Архитектура сервиса автоматически распределяет нагрузку: компактные модели работают на ускорителях уровня A2, а тяжелые решения, такие как DeepSeek-V4-Flash-0731, запускаются на серверах со связкой до восьми GPU NVIDIA H200.

Публичные эндпоинты с оплатой за токены — это готовое решение для быстрого инференса и прямой интеграции в рабочие сервисы. Разработчики могут сразу использовать API, не отвлекаясь на поддержку собственной инфраструктуры. При этом эндпоинты остаются удобным инструментом для быстрой оценки качества генерации, проверки tool calling и сборки прототипа. Если бизнес-задача требует изолированного контура, приватности данных или запуска кастомной модели, наработанный код и промпты можно без изменений мигрировать на частный эндпоинты immers.cloud с посекундной тарификацией.

«Использование искусственного интеллекта с каждым днем становится все более повседневным и привычным. Пользователи взаимодействует с большими языковыми моделями очень по-разному. И как правило, это зависит от навыков и потребностей: для кого-то достаточно ответов модели в чате; кто-то автоматизирует рабочие процессы и разработку через популярные фреймворки или агентов; стартапам и крупным компаниям, разрабатывающим продукты на основе ИИ, часто требуется не только LLM, но и надежная инфраструктура для инференса. Нашей команде известны все эти сценарии, и развивая сервис Immers Foundation Models мы стремимся сделать так, чтобы каждый шаг на пути к фантастическим возможностям ИИ был для наших клиентов максимально простым, быстрым и доступным.» — Павел Самойлов, руководитель направления по ИИ.

immers.cloud — облачный сервис для аренды серверов с GPU NVIDIA. Платформа предоставляет инфраструктуру с посекундной тарификацией и быстрым онбордингом для обучения нейросетей, инференса LLM, 3D-рендеринга и обработки видео.

Реклама. Рекламодатель ООО «ДТЛ», ИНН 9717073792, erid: 2W5zFHoWPiy

При этом перестраивать технологии нужно было в работающем продукте. Сегодня дневная аудитория соцсети — более 65 млн человек в России. Остановить её работу даже на выходные было невозможно — изменения внедряли поэтапно.

Как трансформировали продукт по сценариям

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

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

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

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

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

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

Платформа разработки вместо ручной сборки

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

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

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

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

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

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

Discovery для рекомендаций

Общие инструменты помогают быстрее развивать и рекомендации. В 2025 году инженеры AI VK запустили Discovery-платформу для рекомендаций, поиска и рекламы во всех продуктах VK.

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

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

Применение технологий Discovery только за первое полугодие 2026 года увеличило общее время, которое пользователи проводят в ленте ВКонтакте, на 11%. На основе платформы обновили и рекомендации для оригинальных авторов — тех, кто создаёт собственный контент. Их публикации могут попасть к широкой аудитории, даже если подписчиков пока мало. Просмотры постов таких авторов выросли в пять раз, а число новых подписчиков — на 22%. Эти результаты отражают совокупный эффект продуктовых изменений и внедрения новых моделей машинного обучения.

Веб на SPA

Трансформация затронула и фронтенд: ВКонтакте перевела основные разделы веб-версии на SPA (single page application), чтобы ускорить загрузку страниц и переходы между ними.

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

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

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

«Для нас было важно не просто изменить архитектуру соцплатформы, но и сохранить скорость обновлений, надёжность и качество пользовательского опыта. Переход позволил командам сократить время деплоя фронтенда до 20 сек, а релизы проходят в среднем 6 раз за сутки», — объясняет Юрий Кочарян.

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

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

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

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

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

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

Что взять в свой проект

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

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

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

Почти у каждой команды в 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, High-speed VDS (HSVDS), AdminVPS и FirstVDS.

Как мы выбирали участников

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

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. High-speed VDS (HSVDS) — архив для простаивающих серверов

Российский провайдер, который специализируется на аренде виртуальных серверов на KVM: классического виртуального хостинга и выделенных серверов нет, VPS и VDS — одна услуга. Серверы стоят в Москве, оплата списывается раз в сутки, а остановленный сервер на следующий день переносится в архив со сниженной тарификацией.

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

• Интернет-магазины на WooCommerce, OpenCart или Bitrix с самостоятельной установкой и настройкой платформы.
• Backend веб-приложений и мобильных сервисов: API, микросервисы и базы данных под управлением команды.
• Разработка, тестирование и staging-среды. Настроенный сервер можно передать со своего аккаунта на аккаунт заказчика.

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

В маркетплейсе есть образы LAMP/LEMP, Docker + Docker Compose, Django и Jupyter Notebook. Самостоятельно можно установить MySQL, PostgreSQL, MongoDB или почтовый сервер. ОС выбирают из каталога провайдера; в Linux права суперпользователя доступны через sudo, прямой вход под root по умолчанию отключён.

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

ЦОД Tier III в Москве с иммерсионным охлаждением. Платформы Supermicro на Intel Xeon Gold 2-го и 3-го поколений, DDR4 ECC Reg 3200 МГц и серверные SSD. Сеть с динамической маршрутизацией: трафик идёт через одного из интернет-провайдеров в зависимости от доступности. vCPU, RAM и SSD увеличиваются из панели без пересоздания сервера, но с остановкой.

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

Провайдер заявляет поддержку в чате 24/7; также доступна почта support@hsvds.ru. Есть русскоязычный FAQ. Отдельного менеджера для B2B-клиентов нет.

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

• Минимальная конфигурация gen2.VDS.1.1.10 (Intel Xeon Gold 2-го поколения) — 1 vCPU, 1 ГБ RAM, 10 ГБ SSD, 1 IPv4 — 185,76 ₽/мес.
• Типовая конфигурация gen2.VDS.2.4.40 — 2 vCPU, 4 ГБ RAM, 40 ГБ SSD — 541,44 ₽/мес.
• Тарификация посуточная, почасовой нет: сервер, созданный и удалённый в один день, оплачивается за полные сутки.
• Скидки за предоплату: 6 месяцев — 5%, 12 месяцев — 10%, сумма списывается за весь срок сразу. Пока только для VDS на Xeon Gold 3-го поколения; вернуться на посуточный тариф нельзя.
• Бесплатного тестового периода нет; минимальный платёж — 100 ₽ без комиссии. Оплата картой, через СБП, SberPay и Yoomoney.
• Трафик безлимитный, скорость до 10 Гбит/с. ОС — только из маркетплейса; root в Linux-образах отключён по умолчанию, права суперпользователя — через sudo.
• Автоматических бэкапов нет; снапшоты — вручную и только на остановленном сервере. При сбое Linux сервер можно загрузить в режиме Rescue.

Официальный сайт: hsvds.ru

6. 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

7. 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, HSVDS и FirstVDS в подборке рассматриваются прежде всего как VPS/VDS-провайдеры.
• Минимальный VPS/VDS: ИХЦ — от 317 ₽/мес (за год), UFO.Hosting — 605,85 ₽/мес, SpaceWeb — цена в калькуляторе с посуточной тарификацией, PSB Hosting — от 8 USD, HSVDS — 185,76 ₽/мес за 1 vCPU, 1 ГБ RAM и 10 ГБ SSD с посуточным списанием, AdminVPS — от 500 ₽/мес в конфигураторе, FirstVDS — от 249 ₽/мес.
• Виртуализация: ИХЦ — KVM/Virtuozzo на выбор; UFO.Hosting — Intel Xeon и Ryzen линейки; SpaceWeb — собственная облачная платформа; PSB Hosting и HSVDS — KVM; AdminVPS и FirstVDS предлагают готовые VPS/VDS-линейки с Linux-образами.
• Трафик: ИХЦ и PSB Hosting — безлимитный (у ИХЦ снижение скорости после 20 ТБ); UFO.Hosting — безлимитный с порогом 32 ТБ; HSVDS — безлимитный входящий и исходящий трафик до 10 Гбит/с; SpaceWeb — параметры уточняйте в конфигураторе; AdminVPS указывает месячные пакеты трафика; FirstVDS разделяет безлимитный канал 100 Мбит/с и пакеты трафика на более быстрых каналах.
• Root и ОС: права суперпользователя доступны на VPS/VDS всех семи провайдеров; у HSVDS — через sudo, прямой вход под root в Linux-образах отключён по умолчанию, ОС выбирают из маркетплейса; ИХЦ и PSB Hosting позволяют загружать собственные ISO; UFO.Hosting ограничивает список ОС на младших тарифах; у FirstVDS Windows и панели управления идут как платные дополнения.
• Бэкапы: SpaceWeb включает ежедневные бэкапы на хостинге; ИХЦ и PSB Hosting — платно; UFO.Hosting — платная услуга резервного копирования; HSVDS — без автоматических бэкапов, ручной снапшот требует остановки сервера; AdminVPS и FirstVDS предлагают бэкапы как тарифную или дополнительную опцию.
• Тестовый период: SpaceWeb — 14 дней на хостинге и VPS; ИХЦ — 7 дней хостинг / 3 дня VPS; UFO.Hosting — до 3 дней VPS; FirstVDS — по согласованию; PSB Hosting и HSVDS — нет; у HSVDS минимальный платёж 100 ₽, тарификация посуточная; условия AdminVPS зависят от акции и выбранной услуги.
• Дата-центры: ИХЦ — Москва + Амстердам; UFO.Hosting — Москва; SpaceWeb — Москва, Санкт-Петербург, Амстердам; PSB Hosting — Amsterdam, Frankfurt, Helsinki, New York; HSVDS — Москва; AdminVPS предлагает VPS в разных странах; FirstVDS указывает Россию, Нидерланды и Казахстан.
• Юридика: ИХЦ, UFO.Hosting, SpaceWeb и AdminVPS работают с российской юридической рамкой; у HSVDS доступны счета и УПД для юрлиц, работа по 152-ФЗ не заявлена; PSB Hosting ориентирован на зарубежные локации; для FirstVDS условия документов и лицензий зависят от выбранных услуг.

Вывод

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

Если приоритет — российская юридика и плавный рост от хостинга до железа, смотрите на Интернет Хостинг Центр или SpaceWeb. Если важна экосистема из доменов, защиты и серверов в одном кабинете — UFO.Hosting или AdminVPS. Если нужен недорогой вход именно в VPS/VDS — можно сравнить High-speed VDS (HSVDS) и FirstVDS с базовыми тарифами других участников. Если нужны зарубежные локации и гибкая оплата — PSB Hosting. Для тестовых сред с паузами в работе у HSVDS есть архив остановленных серверов со сниженной тарификацией. Перед покупкой проверьте производительность под своей нагрузкой: используйте тестовый период, если он доступен, или начните с минимального платежа.

Выход — поднять собственное 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-облако с AWS-совместимым API и ML-платформой от K2 Cloud

В облаке K2 Cloud можно арендовать виртуальные машины, выделенные облачные серверы и bare metal-серверы с видеокартами NVIDIA, а также подключить GPU-узлы в Managed Kubernetes. Провайдер ориентируется на крупный бизнес: обучение и дообучение моделей, инференс в продакшне, компьютерное зрение, аналитику и HPC. По данным K2 Cloud, около 90% запросов на GPU сейчас связаны с ИИ — LLM, чат-ботами, RAG, кодинг-ассистентами, распознаванием аудио и изображений.

Инфраструктура размещена в сети дата-центров уровня Tier III: четыре территориально распределённых ЦОД в Москве и один в Санкт-Петербурге. Ресурсы можно брать по факту потребления с почасовой оплатой или по коммиту на срок.

Какие GPU доступны

В пуле пять моделей видеокарт NVIDIA. Для обучения и тяжёлого инференса — H100 на 80 ГБ и A100 на 80 ГБ. Для инференса средних моделей и компьютерного зрения — L40S на 48 ГБ. Под лёгкий инференс и эксперименты подойдут L4 на 24 ГБ и T4 на 16 ГБ.

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

• H100: 1 GPU — 12 vCPU и 96 ГБ RAM, 2 GPU — 24 vCPU и 192 ГБ RAM;
• L40S: 1 GPU — 8 vCPU и 64 ГБ RAM, 2 GPU — 12 vCPU и 96 ГБ RAM;
• T4: 1 GPU — 4 vCPU и 16 ГБ RAM, 2 GPU — 8 vCPU и 32 ГБ RAM.
• H200 141 ГБ
• RTX Pro 6000 SE

Под задачу можно собрать и нестандартную конфигурацию: соотношение vCPU и памяти выбирается из схем 1:2, 1:4 и 1:8.

Под какие сценарии подходит, как используют

Провайдер приводит два примера из практики:

1. Сервис заказа поездок Drivee вынес в облако ML-сервисы на T4: фотоконтроль водителя и автомобиля перед выходом на линию и модерацию пользовательского контента. По данным кейса, ИИ закрывает 75% задач фотоконтроля без оператора, обрабатывает до 10 000 проверок в сутки и тратит на одну 2–3 секунды вместо нескольких минут. Весь бэкенд и фронтенд приложения работают в К2 Cloud в трёх зонах доступности, данные обрабатываются по 152-ФЗ до УЗ-1 и PCI DSS 4.0.
2. ИТ-компания развернула мультиагентную систему реагирования на инфраструктурные инциденты на двух L40S в контуре с аттестацией по 152-ФЗ. Система проходит путь от алерта до автоматического устранения проблемы или эскалации инженеру и работает круглосуточно.

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

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

Для ВМ с GPU при создании инстанса доступен образ Ubuntu 24.04 с CUDA и драйверами NVIDIA. В образах и на ML-платформе К2 НейроТех есть PyTorch, TensorFlow, JupyterLab, vLLM, Ollama, Triton Inference Server и SGLang. К2 НейроТех — это управляемая платформа для полного цикла ML, по назначению её можно сравнить с DataSphere или ML Space.

В Managed Kubernetes с GPU одну видеокарту можно разделить на изолированные инстансы через MIG, а на пиках нагрузки добавлять узлы. Поверх инфраструктуры провайдер разворачивает собственные ИИ-продукты: RuClaw для запуска ИИ-агентов в защищённом корпоративном контуре с ролевой моделью и журналом аудита и «ИИ-офис» для управления портфелем ИИ-инициатив.

Для датасетов есть S3-совместимое хранилище, для рабочих данных — сетевые диски HDD и SSD до 50 000 IOPS и локальный NVMe; к одной машине подключают до 16 дисков объёмом от 32 ГБ до 4 ТБ. Между дата-центрами канал больше 20 Гбит/с, инфраструктуру можно закрыть в VPC и связать с офисом через VPN или выделенный L2-канал. В консоли у ВМ с GPU выводятся графики утилизации видеокарты и видеопамяти.

Автоматизация и DevOps

Главная техническая особенность — AWS-совместимый API. Через него создают и останавливают инстансы, меняют конфигурацию, получают метрики, управляют ключами и биллингом. За счёт совместимости работают привычные инструменты: AWS CLI, AWS SDK, кастомизированный Boto3, Terraform, Packer, Ansible, а также Kubernetes, Helm, Docker Registry, GitLab CI/CD, Prometheus и Grafana. Для команд, у которых пайплайны уже написаны под AWS, это сокращает переезд.

Тарификация

ВМ с GPU тарифицируются почасово по модели pay-as-you-go, минимальный срок аренды — один час. Для постоянных нагрузок доступен коммит на 3, 6 или 12 месяцев со скидкой. Прерываемых инстансов для GPU нет: shared core-машины в К2 Cloude есть, но GPU в такие пулы не размещаются.

Новым клиентам дают бесплатный тест-драйв любой конфигурации на две недели. Юрлица работают по договору, с ЭДО, счётом в рублях с НДС и полной постоплатой.

Ограничения и безопасность

Публичного прайса на GPU нет: стоимость конфигурации считают в калькуляторе на promo.k2.cloud/gpu-calculator или в коммерческом предложении. Флагманов H200 и Blackwell в линейке нет, потолок — H100, и в одну машину ставят до четырёх карт. Облачная ВМ с GPU поднимается от 10 минут, а выделенный сервер готовят от трёх рабочих дней.

С безопасностью у провайдера сильный комплект: аттестат по 21 приказу ФСТЭК с защитой персональных данных по 152-ФЗ до УЗ-1, PCI DSS 4.0, ГОСТ Р 57580.1-2017 с оценкой R=0,95, ГОСТ Р ИСО/МЭК 27001-2021 и 27017-2021, ГОСТ Р ИСО 9001-2015. Платформа включена в реестр российского ПО, запись №5386 от 6 мая 2019 года.

Поддержка и условия работы

Поддержка работает через чат, Telegram, почту, телефон, тикет-систему и выделенного менеджера. Время реакции по SLA — 10 минут, SLA на доступность ВМ — 99,95%. Документация на русском собрана на docs.k2.cloud. Для ML-команд есть Professional Services: аудит инфраструктуры, миграция, построение и сопровождение среды.

Кастомные 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 и прочих операторов гигаваттных ЦОДов) поедут вправо. Дефицит 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 обычно строится.