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

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

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

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

Рейтинг курсов ИИ для детей в 2026 году

1. «Пиксель» — Roblox Studio с ИИ

Курс Roblox Studio с ИИ для детей — «Пиксель»

Школа программирования «Пиксель» предлагает курс Roblox Studio с использованием искусственного интеллекта для детей 9–14 лет.

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

На занятиях школьники работают в Roblox Studio, изучают программирование на Lua и применяют ИИ как инструмент разработчика.

Что изучают на курсе?

В программу входят:

• основы Roblox Studio;
• программирование на Lua;
• создание игровых миров;
• разработка игровых механик;
• работа с 3D-объектами;
• персонажи и анимация;
• использование ИИ при разработке игр;
• работа с кодом с помощью AI;
• генерация идей для игровых проектов;
• создание отдельных элементов с помощью нейросетей;
• оптимизация кода.

Ребенок не просто выполняет отдельные упражнения, а постепенно собирает собственные игровые проекты.

Согласно описанию курса, ученики создают Obby, лабиринт, симулятор-кликер, систему телепортов и бонусов, работают с генерацией текстур и создают собственную ракету. Итогом становится выпуск собственной игры в Roblox.

Курс рассчитан на новичков и продвинутых пользователей. Занятия проходят онлайн, модуль состоит из 12 занятий по 90 минут, а полный курс рассчитан на 9 месяцев.

Кому подойдет?

Курс особенно интересен детям, которые уже любят Roblox и хотят разобраться, как создаются игры.

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

2. ZeroCoder — Python и ChatGPT

Курс «Python и ChatGPT» — ZeroCoder

Еще один вариант обучения ИИ — объединить нейросети с программированием.

Программа ZeroCoder «Python и ChatGPT» рассчитана на детей 10–16 лет. В ней Python изучается вместе с основами работы с искусственным интеллектом.

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

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

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

Что может заинтересовать ребенка?

• Python;
• ChatGPT;
• создание программ;
• работа с AI;
• практические проекты;
• знакомство с IT-профессиями.

Кому подойдет?

Школьникам 10–16 лет, которым интересны программирование и искусственный интеллект одновременно.

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

3. CODDY — создание игр с помощью нейросетей

Курсы по искусственному интеллекту и созданию игр — CODDY

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

Одно из направлений — создание игр с помощью нейросетей.

В таком формате ребенок знакомится с AI через понятную ему задачу — разработку собственной игры.

Нейросети могут использоваться для:

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

У школы также есть отдельные программы по нейросетям и промпт-инжинирингу.

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

Кому подойдет?

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

4. Компьютерная академия TOP — «Мастер нейросетей»

Компьютерная академия TOP

В линейке программ Компьютерной академии TOP есть направление «Мастер нейросетей».

Программа ориентирована на практическое использование современных AI-инструментов.

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

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

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

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

Кому подойдет?

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

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

5. Айтигенио — «Нейросети для школьников»

Курс «Нейросети для детей» — Айтигенио

Айтигенио предлагает несколько уровней обучения нейросетям.

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

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

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

Что может изучать школьник?

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

Кому подойдет?

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

Какие бывают курсы искусственного интеллекта для детей?

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

ИИ для творчества

Ребенок учится создавать:

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

Такой формат подходит для первого знакомства с технологией.

ИИ и программирование

В программе появляются Python, код, алгоритмы и AI-инструменты.

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

ИИ для создания игр

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

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

ИИ и машинное обучение

Более техническое направление.

Здесь могут изучаться:

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

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

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

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

Но это еще не означает, что он понимает искусственный интеллект.

Например, можно попросить нейросеть:

«Придумай игру».

И получить готовую идею.

Но гораздо полезнее, если ребенок самостоятельно определяет:

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

В таком случае нейросеть становится инструментом, а не заменой самостоятельной работы.

Боль родителей: ребенок уже пользуется нейросетями

Многие родители сталкиваются с ситуацией, когда школьник уже активно использует AI.

Он может:

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

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

Поэтому современное обучение ИИ должно включать не только технические возможности нейросетей, но и AI-грамотность:

поставить задачу → сформулировать запрос → получить ответ → проверить → исправить → сделать вывод.

Это помогает ребенку использовать искусственный интеллект осознанно.

Как выбрать курс ИИ для ребенка?

Если ребенок любит Roblox и игры

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

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

Подойдут программы, где искусственный интеллект объединен с Python.

Если нравится рисование и создание видео

Лучше искать курсы по генеративному ИИ и цифровому творчеству.

Если ребенок хочет понять, как работает искусственный интеллект

Стоит выбирать программы, где есть данные, машинное обучение и основы устройства AI-моделей.

Если это первое знакомство с ИИ

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

На что обратить внимание перед оплатой курса?

Перед записью стоит уточнить:

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

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

FAQ

С какого возраста можно изучать ИИ?

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

Нужно ли знать программирование?

Нет. Для базового знакомства с нейросетями программирование не обязательно. Но для технического изучения ИИ Python становится полезным навыком.

Что лучше: нейросети или программирование?

Эти направления можно объединять. Например, на курсе Roblox Studio с ИИ ребенок одновременно изучает программирование на Lua и использует искусственный интеллект в разработке игр.

Можно ли ребенку использовать ИИ для учебы?

Да, но важно научить школьника проверять ответы нейросети и самостоятельно понимать материал.

Что ребенок может создать с помощью ИИ?

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

Можно ли начать обучение без опыта?

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

Итог

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

Для детей, которые любят игры, интересным вариантом может стать курс «Roblox Studio с ИИ» в школе «Пиксель»: школьник создает собственную игру, изучает Lua и одновременно учится использовать нейросети в работе разработчика.

ZeroCoder объединяет ИИ с Python, CODDY использует искусственный интеллект в создании игр, TOP делает акцент на универсальных AI-инструментах, а Айтигенио предлагает программы разного уровня — от генеративных нейросетей до машинного обучения.

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

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

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

Включить функцию можно настройкой chat.agent.sandbox.enabled или переключателем Sandboxing for terminal в меню Permissions отдельной сессии. На Windows потребуются необходимые обновления ОС. Для удалённых сессий ограничения действуют на хосте, где агент запускает инструменты и команды, поэтому администраторам важно учитывать пути и разрешения именно этой машины.

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

Корпоративные пользователи могут одновременно авторизоваться в GHE.com и GitHub Enterprise Server в одном окне редактора. Проверить доступность обновления можно через Check for Updates. Отдельных сведений об ограничениях для российских пользователей или хостингов в заметках к релизу нет.

Источники

• Visual Studio Code 1.141

Функциональные флаги (feature flags, feature toggles) позволяют разработчикам включать и отключать функции приложения, но при этом не требуют повторно собирать и развёртывать код. Благодаря флагам в CI/CD можно чётко отделить друг от друга этапы «развёртывания» (доставки результатов разработки и сборки) и «релиза» (запуска новой функциональности для пользователей). Для чего и как именно это делается — разберём в этой статье.

Что такое функциональный флаг

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

Ниже приведён пример JSON, который получает приложение. Оно проверяет геотег пользователя, и если пользователь из Москвы, то значение флага возвращает true и в итоге отображается виджет погоды. Для пользователей из других городов значение флага принимает default_variant: "disabled", и виджет для них не показывается.

Функциональные флаги могут использоваться в разных сценариях — приведём основные с парой примеров:

• Повышение надёжности системы: отключение рекомендаций при высокой нагрузке, переключение на резервный платёжный шлюз при сбоях в основном.
• Обучение через продуктовые эксперименты и A/B-тестирование: сравнение двух вариантов страницы регистрации, тестирование двух видов кнопки «Купить».
• Управление доступом по тарифам и подпискам: экспорт отчётов только для пользователей Pro, расширенные настройки только для корпоративных клиентов.
• Сезонные и временные функции: промокоды на «чёрную пятницу», приём работ для конкурса.
• Аварийные выключатели (kill switches): отключение медиаплеера из-за ошибок, удаление неверно настроенного способа оплаты.

Далее рассмотрим основные типы флагов.

Типы флагов

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

По механизму работы: статические и динамические флаги

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

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

Статические флаги задаются через переменные окружения (.env), конфиг-файлы (config.json) или внешние сервисы конфигурации (Consul).

Пример в .env:

Пример в виде конфиг-файла:

Использование в коде:

Плюсы: простота, нулевые сетевые задержки, предсказуемость, безопасность (нет внешних вызовов в runtime).

Минусы: невозможность изменить поведение «на лету» — требуется пересборка/перезапуск.

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

Такие флаги управляются через внешние системы: API, БД, специализированные сервисы.

В примере ниже — два флага. Первый проверяет, попадает ли пользователь в сегмент для тестирования нового способа оформления заказа: берутся только 25 % пользователей сервиса; также они должны входить в группы "beta_testers", "premium_users" и быть из России, Беларуси или Казахстана. Второй флаг показывает, что ИИ-рекомендации при заказах пока отключены для всех пользователей, но в нужный момент это можно изменить даже во время работы приложения.

Пример конфигурации:

Использование в коде:

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

Минусы: усложнение логики системы (flag debt), дополнительная задержка при запросе состояния флага и зависимость от внешних систем.

Сведём сравнение типов флагов в небольшую таблицу:

По цели применения: релизные, экспериментальные, операционные и разрешающие флаги

Релизные флаги (release flags) позволяют отделить развёртывание от релиза, то есть экспериментальная/незаконченная фича вливается в основную ветку и развёртывается вместе с остальным кодом, но остаётся выключенной до официального релиза. Если после релиза что-то пойдёт не так, флаг можно сразу же отключить, не делая новый релиз и не откатывая приложение. Когда новая функциональность начинает работать стабильно, релизный флаг удаляют.

Например, код нового платёжного шлюза уже в продакшене, но флаг пока enabled: false. Флаг включат 1 ноября, и фича станет доступной всем. Если с платежами возникнут проблемы, флаг сразу же отключат без отката деплоя.

Экспериментальные флаги (experiment flags) — это инструмент для A/B-тестов и проверки гипотез. Они позволяют показать разные новые варианты новой функции разным пользователям (или показать новую функциональность только ограниченной лояльной группе пользователей), чтобы изучить их реакцию и на её основе сделать вывод о новой фиче. По окончании A/B-теста экспериментальный код и флаг удаляют.

В примере ниже команда интернет-магазина проводит тест, чтобы выбрать подходящий цвет для кнопки «Оформить заказ» в корзине. Выборка из 30 % пользователей распределяется случайным образом: 50 % из них видят зелёную кнопку, 25 % — красную, 25 % — оранжевую. Система собирает метрики: конверсию и отказ от корзины. Через две недели становится ясно, что оранжевая кнопка даёт +15 % к конверсии, поэтому её делают основной, а флаг и экспериментальный код удаляют.

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

Операционные флаги зачастую не удаляют и оставляют в системе.

Рассмотрим следующий пример. В «чёрную пятницу» нагрузка в приложении интернет магазина растёт, утилизация CPU превышает 85 %. Из-за этого отключаются ИИ-рекомендации (на ресурсоёмкой ML-модели) и включаются обычные статические. После того как нагрузка снижается, флаг возвращается в исходное состояние.

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

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

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

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

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

Системы управления флагами

Глобально все решения для управления флагами делятся на три категории: проприетарные, Open Source и собственные разработки.

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

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

• LaunchDarkly позволяет включать функционал для конкретных сегментов аудитории с высокой гранулярностью, то есть подходит для детального таргетинга пользователей и маркетинговых экспериментов. Платформа даёт enterprise-уровень надёжности и позволяет гибко управлять жизненным циклом флагов.
• ConfigCat обеспечивает единую точку управления, если инфраструктура состоит из разнородных технологий (веб, мобильные приложения, бэкенд на разных языках).
• Harness интегрирует управление флагами прямо в CI/CD-процессы. Предоставляет командам детальную аналитику о влиянии флагов на производительность и стабильность системы прямо в пайплайне развёртывания.

Open Source-решения дают полный контроль над кодом и данными и позволяют развёртывать систему на своих серверах (on-premise), что критично для организаций со строгими требованиями к безопасности.

Вот пара примеров Open Source-платформ для управления флагами:

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

Собственная разработка тоже возможна, но требует значительных ресурсов. На ранних этапах разработки продукта или при тестировании гипотез внедрения флагов можно использовать переменные окружения, JSON-файлы или простой API-сервис. Но по мере роста продукта поддерживать собственное решение становится всё сложнее: нужно обеспечивать отказоустойчивость, безопасность и разработку SDK для всех языков программирования в проекте. Так что переход на специализированный инструмент (Open Source или SaaS) — обычно вопрос времени.

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

Теперь посмотрим, какую роль функциональные флаги играют в CI/CD.

Функциональные флаги в CI/CD

Флаги фундаментально меняют подход к управлению исходным кодом, особенно если используется модель ветвления Trunk Based Development (TBD).

При TBD в основную ветку (main/trunk) часто вливаются изменения. Функциональные флаги позволяют разработчикам интегрировать и развёртывать фичи, которые ещё не готовы к релизу, и при этом не рисковать стабильностью всего приложения. Благодаря флагам быстрее внедряются изменения и упрощается слияние, так как весь код (и основной, и разрабатываемый) остаётся в одной ветке. Это предотвращает конфликты слияния (merge hell), которые часто случаются при долгоживущих ветках.

Флаги улучшают управление рисками, а именно:

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

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

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

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

Отдельные наборы тестов могут быть полезны, когда состояния флагов фиксированы в разных окружениях (например, staging и production) или когда предпочтительнее запускать тесты по отдельности.

Допустим, мы готовим новую версию приложения и до того, как выпустить её в продакшен, тестируем релиз-кандидата в окружении staging. CI/CD-пайплайн собрал образ release-candidate и развернул его в staging. При запуске приложения запрашивается набор флагов из централизованной системы управления флагами. Далее при запуске автотестов подбирается набор тест-кейсов для заданного окружения. Также подбирается набор флагов для конкретного пользователя после того, как его логин и user id считаются из cookie во время запроса.

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

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

Сценарий тестирования релиз-кандидата с применением функциональных флагов

Сценарий состоит из следующих шагов:

1. CI/CD-пайплайн собирает образ release-candidate и деплоит в staging.
2. При запуске приложения запрашиваются флаги из Flagsmith с параметрами environment=staging, user_id, role.
3. Система флагов возвращает конфигурацию: какие флаги включены и какие тест-кейсы нужно выполнить.
4. Автотесты динамически фильтруют тесты на основе полученного ответа. Тесты, которые не относятся к активным функциям текущего окружения, не запускаются.

Все флаги хранятся в системе управления флагами Flagsmith в формате JSON.

Здесь описан флаг new_payment_flow — он управляет новой версией процесса оплаты.

В нашем примере функция включена в staging и выключена в production.

Помимо самого состояния флага, конфигурация содержит список тестов для каждого окружения. Для staging предусмотрены три проверки:

• успешная оплата;
• обработка ошибки;
• обработка тайм-аута.

Для production пока оставлен только тест успешной оплаты.

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

Автотесты при запуске запрашивают флаги из внешней системы с помощью следующего запроса:

Здесь тестовый раннер сообщает системе флагов контекст, в котором выполняется проверка. В параметре context указаны идентификатор release candidate и источник запроса — autotest_runner.

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

Автотесты используют функциональные флаги, чтобы динамически сформировать определённый тестовый сценарий. Для этого процесс сбора тестов перехватывается через специальную функцию (conftest.py):

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

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

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

В результате pytest запустит только оставшиеся тесты.

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

Здесь из конфигурации флага new_payment_flow извлекается параметр timeout_ms. В нашей конфигурации его значение было задано — 5000. Если бы оно не было указано, использовалось бы значение по умолчанию — 3000.

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

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

Риски и рекомендации по использованию флагов

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

Основные риски при работе с флагами

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

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

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

Архитектурные рекомендации

Прежде всего, флаги нужно вовремя удалять: можно настроить в CI/CD автоматические уведомления на флаги, которые живут дольше установленного времени, например больше 30 дней. А релизные и экспериментальные флаги лучше удалять сразу после того, как стабилизировалась фича или закончился A/B-тест. У каждого флага должны быть владелец, дата создания и план удаления.

Как мы уже писали выше, флаги — это критическая зависимость, поэтому стоит обезопасить себя от сбоев в системе управления флагами: использовать на стороне приложения fallback-значения (default variants), внедрить локальное кеширование (чтобы пережить кратковременные падения сети), использовать автоотключение (Circuit Breaker) запросов к сервису флагов при множественных таймаутах.

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

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

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

Резюмируем ключевые принципы:

• Временность. Для флагов должен быть чёткий план удаления.
• Прозрачность. У каждого флага должны быть владелец, назначение и срок жизни.
• Отказоустойчивость. Приложение должно работать даже при недоступности сервиса управления флагами.
• Мониторинг. Состояние и использование флагов нужно постоянно отслеживать.

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

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

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

Согласно анонсу Kilo, Desktop уже доступен для скачивания. Стоимость приложения, лимиты использования и доступность из России в публикации не указаны.

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

Новость касается команд, чьи приложения используют затронутые Java-зависимости. IBM и Red Hat объясняют важность работы тем, что автономные ИИ-агенты могут объединять несколько менее опасных слабостей в серьёзную атаку. При этом в анонсе нет перечня библиотек, версий и CVE, поэтому определить затронутые приложения по нему нельзя.

Для российских разработчиков и хостингов вывод тот же: нужно сверять зависимости приложений с уведомлениями сопровождающих проектов и доступными обновлениями. О доступности Clearinghouse для заказчиков из России компании не сообщили. Подробности анонса приведены в пресс-релизе IBM и Red Hat.

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

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

Полная модель содержит 740 млн параметров. Для текстовых задач требуется 270 млн параметров, а для полной мультимодальной поддержки добавляются энкодеры зрения на 170 млн и аудио на 300 млн параметров. Контекстное окно выросло вчетверо, до 8 тысяч токенов. По данным Google, оно вмещает до 5,5 минуты аудио, 29 изображений или 58 видеокадров.

Для разработчиков инструментов работы с кодом заметное изменение касается качества поиска: в опубликованных Google результатах MTEB Code оценка выросла с 68,76 до 78,68. Компания также заявляет о ведущих результатах среди мультимодальных моделей размером менее миллиарда параметров. Это оценки вендора, независимые проверки в источнике не приведены.

Локальная обработка позволяет строить поиск по файлам и медиа без отправки данных в облако. Веса доступны на Hugging Face и Kaggle под лицензией Apache 2.0, допускающей коммерческое использование. Стоимость развёртывания и доступность площадок из России в анонсе не указаны.

Источники

• EmbeddingGemma 2 is a best-in-class open model for natively multimodal embeddings

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

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

Как составлялся рейтинг?

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

При подготовке рейтинга учитывали:

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

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

Важно: место в рейтинге не означает, что одна программа подходит всем детям лучше другой. Для семилетнего ребенка, школьника 10–12 лет и подростка, который уже знает Python, задачи обучения будут разными.

Рейтинг курсов по изучению нейросетей для детей

1. Пиксель — «Искусственный интеллект и нейросети для детей»

Курс «Искусственный интеллект и нейросети» — Пиксель

Курс рассчитан на детей 8–12 лет и посвящен именно изучению принципов искусственного интеллекта и нейросетей.

В программе ребенок знакомится с:

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

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

Курс состоит из трех модулей по 12 занятий продолжительностью 90 минут. Занятия проходят онлайн, доступны групповой и индивидуальный форматы.

Кому подойдет?

Школьникам 8–12 лет, которым интересно понять, как работает искусственный интеллект, а не только пользоваться готовыми нейросетями.

2. Айтигенио — «Нейросети»

Курс по нейросетям для детей — Айтигенио

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

Для детей от 10 лет программа становится глубже. В ней появляются:

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

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

Школа также предлагает бесплатный пробный урок с реальным преподавателем.

Кому подойдет?

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

3. Foxford — курсы по нейросетям

Курсы по искусственному интеллекту для детей — Foxford

Foxford предлагает несколько направлений по искусственному интеллекту для школьников.

Для подростков 12–17 лет есть программа «Нейросети: код и создание запросов». Она знакомит с принципами работы современных AI-моделей, промптингом и способами обучения ИИ.

Есть и направление «Нейросети для создания контента», где школьники работают с текстами, изображениями, аудио, видео, 3D-объектами и презентациями.

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

Кому подойдет?

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

4. Skillbox Kids — AI Python

Курс AI Python — Skillbox Kids

AI Python рассчитан на детей 11–13 лет и длится три месяца.

Программа состоит из трех блоков.

Модуль 1. Знакомство с нейросетями

Ребенок изучает виды нейросетей, принципы их работы и промпты.

Модуль 2. Нейросеть и Python

Школьник повторяет основы Python и учится использовать нейросеть при написании кода.

Модуль 3. Практическое применение AI

В программе есть Python, интернет, Minecraft и кибербезопасность.

Среди проектов — собственный чат-бот, текстовая игра или Pac-Man.

Кому подойдет?

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

5. Академия Эдюсон — «Python и нейросети для школьников»

Курс «Python и нейросети для школьников» — Академия Эдюсон

Программа рассчитана на детей от 11 лет и рассчитана на 12 месяцев.

Здесь нейросети изучаются не отдельно, а вместе с Python.

В актуальной программе указаны:

• алгоритмы;
• переменные;
• строки и списки;
• условия;
• ООП;
• AI-ассистенты;
• YandexGPT;
• Perplexity;
• AI-IDE;
• автокомплитеры;
• PyGame.

Всего заявлено 48 интерактивных уроков и 20 проектов. Среди них — AI-презентация, сайт с помощью ИИ, игра и другие проекты.

Кому подойдет?

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

6. CODDY — «Нейросети для детей: основы и практика»

Курс «Нейросети для детей» — CODDY

Программа рассчитана на детей 11–16 лет.

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

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

Кому подойдет?

Школьникам, которые хотят освоить AI-инструменты и применять их в собственных проектах без глубокого технического старта.

7. TEEN.AI Studio

TEEN.AI Studio — нейросети для детей

TEEN.AI — новый формат в этой подборке: это не классическая онлайн-школа, а детская AI-платформа для возраста 6–16 лет.

Внутри есть пять направлений:

• Фото и арт;
• музыка;
• видео;
• текст;
• код.

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

Есть бесплатный вводный курс.

Кому подойдет?

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

8. Hello World — «Нейросети для детей»

Курс «Нейросети для детей» — Hello World

Hello World предлагает отдельный курс по нейросетям для детей с 8 лет.

Школа специализируется на онлайн-обучении детей программированию и цифровым навыкам. В каталоге также представлены Python, Roblox, Unity, дизайн, Blender и компьютерная грамотность.

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

Кому подойдет?

Детям от 8 лет, которым нужен первый опыт работы с современными AI-инструментами.

9. ZeroCoder — «НейроTeen»

Программа «НейроTeen» — ZeroCoder

«НейроTeen» — программа для школьников, в которой нейросети применяются не только для генерации текста или картинок.

В открытом описании программы указаны проекты с:

• презентациями;
• сайтами;
• играми;
• музыкой;
• комиксами;
• видео;
• текстами.

Программа также ориентирована на применение AI в учебе и знакомство с разными цифровыми направлениями.

Кому подойдет?

Школьникам, которые хотят попробовать несколько способов применения нейросетей и пока не определились с конкретной IT-специализацией.

10. Компьютерная академия TOP

Компьютерная академия TOP

Компьютерная академия TOP представлена в актуальных подборках детских AI-программ. В каталоге 2026 года среди предложений по искусственному интеллекту указывается направление «Мастер нейросетей».

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

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

Кому подойдет?

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

Какие бывают курсы по изучению нейросетей?

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

1. Курсы по AI-инструментам

Ребенок учится использовать готовые нейросети:

• текстовые;
• графические;
• музыкальные;
• видео;
• голосовые.

Это самый простой вариант для первого знакомства.

2. Курсы по промптингу

Здесь основной навык — правильно ставить задачу нейросети.

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

3. ИИ + программирование

В таких программах нейросеть становится инструментом разработчика.

Ребенок пишет код на Python и использует AI для объяснения, поиска ошибок и создания проектов.

4. Искусственный интеллект и машинное обучение

Это уже более технический уровень.

Здесь появляются:

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

5. ИИ + творчество

Такие курсы подходят детям, которым интересны:

• картинки;
• мультфильмы;
• музыка;
• видео;
• комиксы;
• игры;
• цифровые истории.

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

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

Например, школьник может попросить нейросеть написать доклад, решить задачу или сделать презентацию.

Получится быстро.

Но образовательный результат при этом может оказаться минимальным.

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

Хорошее обучение должно формировать привычку:

поставить задачу → получить результат → проверить → исправить → сделать собственный вывод.

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

Что должен уметь ребенок после изучения нейросетей?

После вводного курса школьник должен хотя бы понимать:

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

На более продвинутом уровне можно изучать Python, данные, машинное обучение и создание собственных моделей.

Как выбрать курс по нейросетям для ребенка?

Для первого знакомства

Если ребенку 7–9 лет, лучше искать короткую программу с понятными визуальными заданиями.

Для школьника 10–12 лет

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

Для подростка

Подойдут программы с Python, программированием, машинным обучением, анализом данных или созданием более сложных AI-проектов.

Если ребенок любит рисовать

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

Если ребенок любит программировать

Стоит искать связку Python + нейросети.

Если ребенок спрашивает, как работает ИИ

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

На что обратить внимание перед оплатой?

Перед покупкой курса родителям стоит проверить:

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

Отдельно стоит проверить, нужны ли ребенку сторонние аккаунты и платные подписки на нейросети.

Это особенно важно для младших школьников.

FAQ

С какого возраста можно изучать нейросети?

Единого возраста нет. Некоторые программы начинаются с 6–7 лет и делают упор на творчество, другие рассчитаны на школьников 10–12 лет и старше. Например, TEEN.AI ориентирован на детей 6–16 лет, Айтигенио предлагает курс с 7 лет, а Pixel — отдельную программу по ИИ для 8–12 лет.

Нужно ли знать программирование?

Нет. Для первого знакомства программирование обычно не требуется. Если ребенок выбирает технический курс по Python и ИИ, программирование становится частью программы.

Чем изучение нейросетей отличается от обычного использования ChatGPT?

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

Можно ли ребенку использовать нейросети для учебы?

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

Что выбрать: курс нейросетей или Python?

Если ребенок хочет создавать контент и экспериментировать с AI, можно начать с нейросетей. Если его интересует разработка игр, программ или приложений, логичнее рассмотреть Python + AI.

Что лучше изучать в 2026 году: нейросети или программирование?

Это не обязательно взаимоисключающие направления. Современные программы всё чаще объединяют Python и нейросети: например, Skillbox Kids и Академия Эдюсон предлагают именно такую связку.

Можно ли начать с бесплатного занятия?

Да. Например, Pixel, Айтигенио и некоторые другие школы предлагают вводные или пробные форматы. У TEEN.AI есть бесплатный стартовый курс.

Заключение

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

Главное — правильно определить цель.

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

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

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

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

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

Также компания открыла ранний доступ к Duo Agent Platform Impact Analytics для оценки расходов и результатов работы ИИ по командам, задачам и моделям. Новый GitLab Security Standard описывает пять мер контроля безопасности и предлагает измерять время от обнаружения проблемы до проверенного исправления.

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

Источник: https://about.gitlab.com/press/releases/2026-10-06-gitlab-announces-the-foundation-for-the-governed-software-factory/

Также Cloudflare включила проверенную бета-логику обнаружения внедрения команд в основное правило Command Injection - Generic 8 - uri. У правила защиты Next.js от отравления кеша уточнили описание, сам механизм обнаружения не изменился.

Обновление важно для администраторов сайтов и API, использующих F5 BIG-IP и Cloudflare Managed Ruleset. Им стоит проверить, включён ли этот набор правил и какое действие настроено для нового обнаружения: документация позволяет менять поведение управляемых правил. Версии уязвимых систем и команды проверки в сообщении о релизе не приведены.

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

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

Что такое суперапп и зачем он нужен вашему бизнесу?

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

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

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

Ключевые характеристики корпоративного супераппа

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

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

2. Безопасность и независимость. Superapp доступен в двух вариантах развертывания: облачный SaaS и локальная установка (on-premise). В обоих случаях данные хранятся и обрабатываются на территории РФ, что гарантирует соответствие 152-ФЗ и защиту от санкционных блокировок. On-premise позволяет выстроить собственный защищенный контур с индивидуальными политиками безопасности, а облачная версия также разворачивается в сертифицированной среде. Оба варианта дают бизнесу полный контроль над инфраструктурой, а сотрудникам — уверенность в сохранности данных.

3. Интеграция процессов. Через API, ботов и мини-приложения можно связать суперапп с HRM, CRM, Service Desk, ERP и другими корпоративными системами. Сотрудник может, не выходя из супераппа, согласовать отпуск (данные уходят в HR-систему), создать заявку в Service Desk (задача автоматически появляется у специалиста), проверить данные по клиенту в CRM или согласовать закупку в учетной системе (например, 1С). Вся информация передается бесшовно.

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

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

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

Как правильно выбрать суперприложение?

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

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

При выборе стоит оценивать следующие характеристики:

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

• Интеграционные возможности. Именно интеграции превращают обычный корпоративный мессенджер в суперапп. Для бизнеса могут быть важны API, чат-боты, мини-приложения и возможность подключения внутренних систем. Чем больше рабочих действий пользователь выполняет внутри одного интерфейса, тем ближе платформа к полноценной модели super app. При этом необходимо убедиться, что решение легко обменивается данными с вашими основными системами (CRM, СЭД, кадровыми сервисами).

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

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

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

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

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

Совет: Перед покупкой запросите у вендоров демодоступ, соберите фокус-группу из сотрудников разных отделов (ИT, HR, продажи, АХО) и протестируйте 2–3 платформы на реальных бизнес-задачах. Практика покажет, какой superApp будет полезнее всего для вашей команды.

Подробный обзор 5 лучших супераппов

Directum Omni — суперприложение со встроенным ИИ-помощником

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

Ключевые особенности:

• доступ к любым системам компании;

• бесшовная интеграция с экосистемой Directum;

• наличие сертификата ФСТЭК в составе экосистемы Directum RX;

• связь между чатами, задачами и документами;

• ИИ‑ассистент, встроенный в повседневные рабочие процессы.

IVA One — платформа для эффективного общения и обучения

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

Ключевые особенности:

• возможность видеовстреч и прямых трансляций;

• полная совместимость с экосистемой IVA;

• интеграция с другими внутренними программами компании;

• ИИ-помощник для подготовки расшифровки и протоколов встреч.

VK WorkSpace — суперапп от VK для коммуникаций внутри компании

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

Ключевые особенности:

• единый календарь и почта для планирования рабочего времени;

• гибкое управление облачным хранилищем;

• таск-трекер для управления проектами;

• изолированные рабочие пространства для отделов и проектов.

eXpress — платформа для корпоративной коммуникации с фокусом на безопасность

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

Ключевые особенности:

• встроенная платформа Smart Apps;

• общение с внешними пользователями и контрагентами в защищенном контуре;

• сертификация ФСТЭК;

• обмен файлами и демонстрация экрана во время видеоконференций.

Битрикс24 — мультипространство для коллективной работы

Решение, объединяющее коммуникации и управление бизнесом в единой экосистеме.

Ключевые особенности:

• ИИ-аналитика для анализа командных встреч и созвонов;

• гибкая настройка под специфику компании;

• интегрированная CRM и управление задачами

• бесшовный доступ к экосистеме Битрикс.

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

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

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

Что такое low-code платформы и в чем их отличие от no-code

Методология Low-code (от англ. «мало кода») предполагает разработку программных продуктов с минимальным объемом ручного программирования за счет использования визуальных сред проектирования, готовых шаблонов и встроенных модулей. Разработчик конструирует приложение в графическом интерфейсе, определяя структуру данных, пользовательские экраны и алгоритмы через визуальные инструменты. Платформа автоматически преобразует эти настройки в работающий код, обеспечивает интеграцию с источниками данных и обслуживание решения. Ключевое отличие от no-code — допустимость ручной модификации кода для сложных сценариев, тогда как no-code ориентирован исключительно на визуальное конструирование.

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

Low-code vs no-code: в чем разница

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

Low-code — это подход, ориентированный на разработчиков. Он предполагает:

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

No-code — это метод, который подойдет пользователям без навыков программирования. Такие решения предлагают:

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

Главное различие заключается в том, что low-code обеспечивает гибкость и возможность масштабирования, в то время как no-code — это прежде всего скорость и простота использования.

Как выбрать подходящую Low-code систему

Выбор платформы — это стратегическое решение, которое сформирует технологический фундамент вашей компании на 5–10 лет. Чтобы не ошибиться, необходимо комплексно оценить решение по ряду критических параметров.

1. Архитектура и масштабируемость. Проверьте, способна ли платформа выдержать многократное увеличение нагрузки: от нескольких десятков до тысяч одновременных пользователей. Ключевыми факторами здесь являются возможность горизонтального масштабирования, поддержка кластерных конфигураций и распределенных систем.
2. Удобство среды разработки и пользовательский опыт. Скорость создания и адаптации Low code приложений напрямую зависит от того, насколько интуитивно понятен и эффективен визуальный редактор. Проанализируйте, легко ли в нем настраивать бизнес-логику, проектировать формы и отчеты без написания кода. Сложный интерфейс замедлит команду и увеличит затраты на разработку.
3. Бесшовная интеграция в ИТ-ландшафт. Платформа не должна быть изолированным «островом». Убедитесь, что она легко интегрируется с вашей существующей инфраструктурой: CRM, СЭД, базами данных и др. Наличие готовых коннекторов и, что более важно, мощного открытого API для реализации уникальных сценариев интеграции является обязательным условием.
4. Надежность и соответствие требованиям законодательства. В современных реалиях безопасность — приоритет. Для российских компаний критически важно, чтобы решение входило в реестр отечественного ПО. Проверьте наличие необходимых сертификатов (например, ФСТЭК), поддержку детальной ролевой модели доступа и наличие инструментов для аудита и протоколирования действий пользователей.
5. Полная стоимость владения. Не ориентируйтесь лишь на цену лицензии. Проведите расчет совокупной стоимости владения, которая включает расходы на внедрение, обучение персонала, техническую поддержку и последующее масштабирование. Перед принятием окончательного решения обязательно запросите демонстрационный доступ и протестируйте платформу на одной из ваших реальных бизнес-задач.
6. Развитость экосистемы и сообщества. Наличие открытой документации, обучающих курсов, сертификации и широкой сети вендоров-интеграторов гарантирует, что вы без труда найдете специалистов на рынке.

Рейтинг лучших low-code платформ

Ниже представлен обзор десяти ведущих российских систем, которые формируют рынок low-code разработки в 2026 году.

Directum RX

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

Характеристики:

• Глубокая интеграция: полная бесшовная совместимость с другими продуктами Directum, что позволяет строить единую информационную экосистему.
• Скорость внедрения: набор готовых «из коробки» решений для быстрой автоматизации типовых бизнес-задач.
• Информационная безопасность: подтвержденная сертификация ФСТЭК России, гарантирующая соответствие строгим требованиям регуляторов.

Плюсы

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

Минусы

• не реализована поддержка BPMN 2.0;
• для создания сложных аналитических отчетов необходимо освоить специализированный инструментарий;
• low-code среда разработки недоступна на мобильных устройствах.

ELMA365

Российская low-code платформа, позволяющая конструировать корпоративные приложения любой сложности.

Характеристики:

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

Плюсы

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

Минусы

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

GreenData

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

Характеристики:

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

Плюсы

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

Минусы

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

BPMSoft

Технологическая платформа, в основе которой лежит синергия методологий управления бизнес-процессами и low-code подхода к разработке.

Характеристики:

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

Плюсы

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

Минусы

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

Knowledge Space

Платформа для планирования и управления бизнесом.

Характеристики:

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

Плюсы

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

Минусы

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

Первая Форма

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

Характеристики:

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

Плюсы

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

Минусы

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

Docsvision

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

Характеристики:

• Мульти-инструментальная среда: вместо единого конструктора система предлагает 10 различных low-code сред, каждая из которых оптимизирована для решения своего круга специализированных задач.

Плюсы

• развитая система маршрутизации документов;
• глубокая экспертиза в СЭД;
• готовые коннекторы для интеграции с 1С, SAP и др.
• поддержка сложных регламентированных процессов.

Минусы

• требует высокой квалификации пользователей;
• возможны замедление и зависания при росте числа пользователей (от ~100+)
• основная специализация — документы, а не универсальная разработка.

SimpleOne

Low-code платформа для автоматизации бизнес-процессов с поддержкой ESM-концепции.

Характеристики:

• Готовые ESM-компоненты: включает в себя встроенный набор инструментов для построения сервисной экосистемы: портал самообслуживания, каталог услуг, базу знаний и др.

Плюсы

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

Минусы

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

FIS Platform

Специализированная low-code платформа, разработанная для решения задач и автоматизации процессов в финансовой индустрии.

Характеристики:

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

Плюсы

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

Минусы

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

Digital Q.LowСode

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

Характеристики:

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

Плюсы

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

Минусы

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

Сравнительная таблица

Как определить, какая платформа нужна вашему бизнесу?

В 2026 году стратегический выбор low-code решений должен опираться на конкретные бизнес-цели и масштаб компании.

• Для крупных корпораций со сложной и разветвленной ИТ-инфраструктурой, где ключевыми требованиями являются масштабируемость и глубокая интеграция, оптимальными кандидатами будут ELMA365, BPMSoft и Directum RX.
• Для среднего бизнеса, которому критически важна скорость запуска и внедрения, подойдут платформы с интуитивно понятным интерфейсом и готовыми модулями, такие как «Первая Форма» и SimpleOne.
• Для организаций финансового сектора с их строгими требованиями к безопасности и соответствию регуляторным нормам созданы специализированные решения, например, FIS Platform.
• Для управления корпоративными знаниями, контентом и документооборотом следует обратить внимание на платформы, сфокусированные на работе с информацией. Это Knowledge Space и Docsvision.
• Если в основе проекта лежит работа с большими данными и аналитика, то выбор стоит сделать в пользу систем, изначально спроектированных для этих целей, таких как GreenData.

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

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

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

Nova 2.5 Sonic доступна в регионах AWS US East (Северная Вирджиния), US West (Орегон), Europe (Стокгольм) и Asia Pacific (Токио). Цена осталась на уровне Nova 2 Sonic. Разработчикам существующих голосовых агентов стоит проверить новую версию на своих сценариях: выполнение последовательных инструкций, корректность вызовов инструментов и задержку ответа.

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

Для эксплуатации добавили лимит памяти на процесс, флаг детерминированности для совместимости с кешем запросов, управление через Cloud API и Terraform, а также метрики времени выполнения и потребления ресурсов. Исходящие сетевые запросы теперь доступны всем организациям, но пока только для Python-функций. Native runtime доступа к сети не имеет.

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

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

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

Для настройки Cloudflare отсылает к инструкциям по BGP для обоих продуктов. Пиринг через Cloudflare Network Interconnect (CNI) пока остаётся в закрытой бете. Отдельных условий доступности для российских пользователей и хостингов в объявлении нет, поэтому подтвердить их по этому источнику нельзя.

Источник: официальный changelog Cloudflare.

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

Для команд, создающих инструменты ревью, это способ проверять изменения до запуска экспериментов с пользователями. GitHub сообщает, что результаты ReviewBench совпадали по направлению с последующими A/B-тестами Copilot code review. Это заявление разработчика бенчмарка: сама компания подчёркивает, что окончательную оценку пользы дают эксперименты в продакшене.

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

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

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

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

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

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

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

Для чего дети используют нейросети?

Сегодня искусственный интеллект можно применять в нескольких направлениях.

Учеба

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

Но ребенок должен понимать, что ответ AI необходимо проверять.

Творчество

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

Программирование

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

Создание игр

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

Исследовательские проекты

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

Профориентация

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

Как составлялся рейтинг

Чтобы сравнение было более объективным, мы использовали семь критериев:

• содержание программы — 20%;
• практические задания — 20%;
• итоговые проекты — 15%;
• техническая глубина — 15%;
• соответствие возрасту — 10%;
• прозрачность условий — 10%;
• возможность продолжения обучения — 10%.

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

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

Рейтинг 10 школ и курсов по ИИ для детей

1. Пиксель — «Искусственный интеллект и нейросети для детей»

Курс «Искусственный интеллект и нейросети для детей» — Пиксель

Курс рассчитан на школьников 8–12 лет. Программа включает знакомство с искусственным интеллектом, нейросетями и датасетами. Дети изучают, как обучается ИИ, и создают собственные модели для распознавания изображений и звуков.

Курс состоит из трех модулей по 12 занятий продолжительностью 90 минут. Занятия проходят онлайн, доступны групповой и индивидуальный форматы.

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

Подойдет: школьникам 8–12 лет, которым интересна не только генерация контента, но и устройство искусственного интеллекта.

2. CODDY — «Нейросети для детей: основы и практика»

Курс «Нейросети для детей: основы и практика» — CODDY

Программа рассчитана на детей и подростков 11–16 лет и подходит начинающим. Школа указывает продолжительность от четырех модулей и 32 часов. Возможны индивидуальные и групповые занятия, онлайн и офлайн.

В программе дети знакомятся с возможностями нейросетей и создают собственные проекты. Отдельное направление CODDY посвящено промпт-инжинирингу.

Что выделяет программу: сочетание практической работы с AI и проектного подхода.

Подойдет: школьникам 11–16 лет, которые хотят использовать нейросети для создания цифровых проектов.

3. Академия Эдюсон — «Python и нейросети для школьников»

Курс «Python и нейросети для школьников» — Академия Эдюсон

Программа рассчитана на детей от 11 лет и длится 12 месяцев. Курс объединяет программирование на Python и работу с нейросетями. Обучение построено в формате игровой стажировки, где ребенок знакомится с этапами создания IT-проектов.

Что выделяет программу: техническая составляющая. Здесь ИИ рассматривается вместе с программированием.

Подойдет: подросткам, которым интересны Python, разработка и искусственный интеллект.

4. ZeroCoder — «НейроTeen»

Программа «НейроTeen» — ZeroCoder

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

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

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

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

5. KIBERone — «Нейросети»

Модуль «Нейросети» — KIBERone

Модуль рассчитан на детей 7–12 лет и включает четыре занятия по два часа. В программе — генерация изображений и текстов, решение учебных задач, исправление ошибок и создание 3D-объектов по описанию.

Школа отдельно выделяет навыки формулировки запросов и критической оценки результатов AI.

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

Подойдет: младшим школьникам, которые только начинают знакомство с ИИ.

6. Компьютерная академия TOP

Компьютерная академия TOP

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

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

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

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

7. Айтигенио — «Нейросети»

Курс «Нейросети для детей» — Айтигенио

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

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

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

Подойдет: детям от 7 лет, которым интересны генеративные нейросети и цифровое творчество.

8. ProgKids

ProgKids — онлайн-школа программирования для детей

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

Что выделяет школу: индивидуальный подход и большой выбор программирования.

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

9. Skysmart

Skysmart — онлайн-школа для детей и подростков

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

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

Что выделяет направление: сочетание AI с другими цифровыми навыками.

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

10. Skillbox Kids — AI Python

Курс AI Python — Skillbox Kids

Курс AI Python рассчитан на детей 11–13 лет, длится три месяца и включает девять занятий по 90 минут. В программе три модуля: знакомство с нейросетями, нейросеть и Python, практическое применение AI.

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

У Skillbox Kids также есть более длительные программы по Python, где модуль по нейросетям является частью большого курса. Например, программа Python + нейросети рассчитана на 11–15 лет и включает отдельный бонусный модуль из девяти уроков.

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

Подойдет: школьникам, которым интересны Python и разработка.

Какой курс выбрать ребенку?

Рейтинг не заменяет подбор программы под конкретную задачу.

Если ребенок хочет просто познакомиться с ИИ

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

Если интересует творчество

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

Если ребенок хочет программировать

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

Если ребенок хочет понять, как работают нейросети

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

Если ребенок уже активно пользуется AI

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

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

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

И у родителей возникает вопрос:

«Он действительно учится или просто перекладывает работу на искусственный интеллект?»

Это важное различие.

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

Например, вместо запроса:

«Реши задачу за меня»

можно научиться формулировать запрос:

«Объясни тему простыми словами, предложи пример и задай мне вопросы, чтобы проверить, понял ли я материал».

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

Что ребенок должен получить после курса по нейросетям?

Перед покупкой курса стоит посмотреть не только на список AI-сервисов.

Хорошая программа должна давать ребенку конкретные навыки:

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

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

FAQ

Для чего дети используют нейросети?

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

С какого возраста можно изучать нейросети?

Возраст зависит от программы. Например, Pixel предлагает отдельный курс для 8–12 лет, KIBERone — модуль для 7–12 лет, а CODDY — программу для 11–16 лет.

Нужно ли ребенку знать программирование?

Нет. Вводные программы могут не требовать знаний кода. При выборе Python + AI программирование уже становится частью обучения.

Чем отличается курс по нейросетям от курса по искусственному интеллекту?

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

Может ли нейросеть заменить обучение ребенка?

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

Что выбрать: нейросети или программирование?

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

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

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

Заключение

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

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

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

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

Что такое токен простыми словами

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

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

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

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

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

Почему один токен не равен одному слову

В документации Hugging Face есть пример для токенизатора модели BERT с идентификатором google-bert/bert-base-uncased. Он разбивает фразу из пяти слов так:

I have a new GPU!
["i", "have", "a", "new", "gp", "##u", "!"]

Получилось семь токенов. Слова I, have, a и new заняли по одному. Сокращение GPU распалось на два, а восклицательный знак стал отдельным токеном. Обозначение ## показывает, что фрагмент продолжает предыдущее слово. Этот токенизатор также переводит буквы в нижний регистр.

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

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

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

Какие токены попадают в запрос и ответ

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

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

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

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

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

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

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

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

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

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

В тарифах API обычно отдельно указаны цены входных и выходных токенов, часто за миллион. Число «1 млн» здесь обозначает единицу расчёта. Оно не означает, что для одного короткого запроса нужно израсходовать миллион токенов.

Для обычного текстового запроса без кэширования и дополнительных платных операций расчёт выглядит так:

Стоимость запроса =
    входные токены / 1 000 000 × цена входа
  + выходные токены / 1 000 000 × цена выхода

Посмотрим на конкретный тариф. На 28 сентября 2026 года в карточке deepseek/deepseek-v4-pro-0813 на RouterAI для провайдера Ionstream указаны 34 ₽ за миллион входных и 300 ₽ за миллион выходных токенов. У других провайдеров этой же модели цены могут отличаться, а рублёвые значения меняются вместе с курсом валют.

Допустим, запрос использовал 2 000 входных и 500 оплачиваемых выходных токенов. Это учебный объём для расчёта, а не результат тестирования модели. Без кэширования получится:

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

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

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

Как проверить, что кэш действительно работает

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

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

Проверяется это не по настройкам, а по ответу API — в статистике должно расти поле чтения кэша. У Claude это cache_read_input_tokens и cache_creation_input_tokens в объекте usage, как описано в документации Anthropic; у других провайдеров поля называются иначе, но смысл тот же. Если это поле стабильно нулевое при повторяющихся запросах, кэш не работает, и вы платите полную цену за один и тот же текст на каждом вызове.

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

Как узнать расход своего запроса

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

После ответа проверяйте статистику API. В примере формата ответа RouterAI для этого используется объект usage. Для учебного объёма из расчёта выше его базовые поля выглядели бы так:

Поле prompt_tokens показывает вход, completion_tokens — выход, total_tokens — их сумму. Для кэширования и рассуждений проверяйте дополнительную детализацию, которую возвращает конкретный провайдер. Умножать total_tokens на одну ставку нельзя, если вход и выход стоят по-разному.

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

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

Как сократить расход без потери нужного контекста

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

• Передавайте нужный фрагмент материала. Для объяснения одной ошибки приложите связанный с ней код и достаточное окружение. Весь репозиторий может содержать много файлов, которые не влияют на проблему.
• Управляйте историей диалога. Не передавайте её целиком в каждый новый запрос — резюмируйте закрытые темы и оставляйте дословно только то, что ещё понадобится.
• Задавайте формат результата. Если приложению нужны название ошибки и способ исправления, перечислите эти поля. Тогда у модели будет меньше причин добавлять длинное вступление и общий обзор темы.
• Ограничивайте генерацию параметром API. В RouterAI для этого описаны max_tokens и max_completion_tokens. Выбирайте параметр, который поддерживает ваша модель. Слишком низкий предел может оборвать полезный ответ; сам предел не обязывает модель заполнить его целиком.
• Проверяйте результат сокращений. Прогоните изменённый запрос на характерных задачах и сравните расход вместе с качеством ответа. Если после удаления контекста приходится повторять запрос с уточнениями, экономия может исчезнуть.
• Проверяйте кэш по факту, а не по настройке. Включённый в коде кэш ничего не гарантирует — ориентируйтесь на поле чтения кэша в статистике запроса.

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

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

Начну моё эссе с рассказа о себе.

Как я сам использую ИИ?

Точечно.

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

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

Регулярно возникает задача сделать сводный файл (без клиентских данных, разумеется) из 5-6 разных таблиц по 5 республикам. Формулы — не моя сильная сторона, и вручную эта работа займет больше, чем я могу себе позволить. Но я загружаю файлы в Claude, описываю задачу вида «Объедини файлы, чтобы строки не слетали, чтобы столбцы соответствовали друг другу» и, вуаля, через 5 минут у меня есть единый файл.

Свежий пример, когда я использовал ИИ, — подготовка стратегии на 2027-2029 года. Когда её готовил, использовал нейросети, к примеру, задал вопрос о том, сколько юридических лиц в Республике Ингушетия и в Республике Чечня. Это можно было бы сделать зайдя на официальный сайт ФНС. Но ответ нейросети я получил почти мгновенно, по сравнению с тем, сколько бы времени потратил, изучая официальные документы. И ответ был достоверен на 100%.

Если говорить про конкретные модели, то я использую Claude. Он мне нравится тем, что подготовит Word-документ под любую задачу и отправит в готовом формате. Chat GPT с теми же задачами периодически не справляется. Иногда применяю Perplexity, для изображений в презентациях — Nano Banana 2, а из «быстрых» моделей — Google Gemini. Также пробовал внутреннюю платформу банка Альфа-Ген и создал два инструмента. Первый — скриптор, — формулирует скрипты продаж. Второй выдает экспертную оценку деятельности клиента по 115 ФЗ. Для меня это был полезный опыт, мне понравилось.

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

Задач, для которых я использую ИИ, в работе не много. Но, как правило, они трудоёмкие и, благодаря дарам технологического прогресса, я экономлю 3-4 рабочих дня в месяц.

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

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

• В подписках в одной из соцсети смотрю ролики преподавателя английского языка из Чечни. Часто вижу, как он работает в платной версии ЧатGPT.
• Диетологи и тренеры повсеместно имеют подписки на ИИ и активно используют. Буквально несколько дней назад я стал участником одного обсуждения: я, фитнес-тренер и ещё один человек стоим в зале и спорим о том, насколько часто можно есть баранину, если ты худеешь. Слева я слышу, что нельзя категорически, справа, что можно раз в неделю, а спортивный блогер, ролик которого мы в этот момент смотрим в качестве источника истины, утверждает, что можно и каждый день. Тогда мы спрашиваем у ИИ и получаем ответ, основанный на научных данных, что для диеты баранину можно есть не больше двух раз в неделю. Баранина является диетическим продуктом, но помешает похудеть за счёт некоторых нюансов (дословно не повторю ответ, да это и не нужно). Оказалось, что блогер был неправ.
• Проходя по улице слышу, как несколько незнакомых человек обсуждают, что Claude лучше ЧатGPT и как его оплатить (в текущей ситуации).
• Молодежь сплошь и рядом использует ИИ для поиска ответов, решения домашней работы, курсовых.
• Об ИИ говорят в Правительстве, в университетах, школах, в детсадах и на кухнях.

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

Как я это вижу? К примеру, прямо в маску сварщика можно встроить камеру с компьютерным зрением. ИИ в режиме реального времени будет подсказывать какую величину тока задать и какой наклона электрода соблюдать. У электриков ИИ может быть интегрирован в отдельные устройства или даже в очки дополненной реальности. Мастер направляет взгляд на стену, а ИИ, в который уже загружены строительные чертежи, данные тепловизора и прочие данные, накладывает схему проводки на поверхность, а в процессе ассистент подсказывает, где проверить изоляцию. Если очки слишком футуристично (хотя это уже данность), то можно ИИ встроить в телефон. К примеру, у сантехников будет свой ИИ в телефоне: достаточно навести камеру на старый узел труб в подвале и спец-ИИ построит 3D-модель, найдет скрытые микротрещины и места коррозии, которые незаметны глазу.

Звучит фантастично? Но это уже частично реальность. Недавно узнал, что с 2021 по 2024 год российские компании ТЭК увеличили использование ИИ на 29%. Чат-ботов для приема обращений потребителей не будем рассматривать, — это уже норма, но и без этого интересно то, что ИИ уже выявляет скрытые дефекты оборудования, анализируя массивы данных с умных датчиков; фиксирует повреждения на изоляторах или провисшие провода; прогнозирует потребление электроэнергии предприятий, рассчитывая цифры по массивам данных о погоде, потребительских привычках и колебаниях спроса.

Это уже не фантастика.

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

Сейчас в ИТ есть свои рабочие инструменты: ПО для ревью кода, IDE, ПО для подготовки документации, диаграмм, тестов, деплоя, системы контроля версий, библиотеки и многое другое. На каждое действие свой инструмент, своя автоматизация. Если какое-то действие повторяется 2 раза — вы его автоматизируете. К ним добавился вайб-кодинг и десяток (или десятки?) моделей, заточенных на то, чтобы писать код, спецификации, тестировать и писать отчёты.

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

Возможно, что это чуть-чуть сделает Банк? Глобально Альфа-Банк понимает, что мне, как сотруднику, нужно, а внутри уже есть платформа, где можно сделать любого агента. Для каждой нашей роли создадут отдельные матрицы ролей с доступом к специализированному искусственному интеллекту и завернут это всё в оболочку. И я думаю, что это будет интересно многим. Например, я недавно присутствовал на событии, где коллеги демонстрировали, как они создавали разные промпты под разные задачи. Там было 415 человек. И это лишь одно мероприятие из многих.

Многие, как и я, понимают, что…

Нет иного выбора, кроме как принять технологию

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

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

Сейчас может показаться неочевидно, но я докажу тезис на примере Китая.

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

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

Развитие технологий — это вопрос выживания.

Китай выучил урок и то, на что у других стран уходили десятилетия, в Китае уместилось в поколение — к примеру, с 1991 по 2001 год региональный ВВП дельты Жемчужной реки вырос почти в восемь раз. Это всё случилось благодаря тому, что на юге Китая (рядом с Гонконгом и Макао) были созданы Особые экономические зоны (ОЭЗ) с налоговыми льготами. Туда хлынули инвестиции и за 10 лет с 1991 года ВВП региона вырос в 8 раз, население удвоилось, открылись десятки тысяч фабрик, а бывший аграрный край («земля рыбы и риса») превратился в главный промышленный узел планеты.

Особые экономические зоны создавались для индустриального рывка — привлечения иностранных инвестиций, строительства фабрик, логистики и физического производства товаров. Когда этот фундамент «мировой фабрики» был построен, он запустил колоссальный внутренний рынок и породил огромный спрос на ИТ-инфраструктуру. Вслед за этим были рождены ИТ-гиганты — Baidu, Alibaba, Tencent). Непосредственно в Особой экономической зоне была основана только одна компания. Остальные две появились в регионах, которые развивались параллельно благодаря общему экономическому буму в стране.

Они были основаны с 1998 по 2000 год, а к концу 2000 года число интернет-пользователей в Китае выросло с 3000 в начале 1995 года до 22,5 миллиона. В 2001 году Китай вступил во Всемирную торговую организацию. В стране начался бум урбанизации, число частных автомобилей выросло в 10 раз, и сформировался многомиллионный средний класс, начавший активно тратить деньги на путешествия, качественную еду и гаджеты.

Еще недавно в Китае варили чугун в уличных печах, а сейчас страна — технологический лидер. Так что в Китае ИИ воспринимается за благо, за новый технологический стероид, и внедряется очень активно. По мнению аналитиков, эта культура технооптимизма может и будет способствовать распространению и масштабному внедрению искусственного интеллекта, и в Китае скоро буквально все будут использовать ИИ. Ведь по данным отчёта Стэнфордского университета об индексе развития искусственного интеллекта за 2026 год, 85% китайских респондентов считают, что ИИ приносит больше пользы, чем вреда, а домохозяйки, пенсионеры, студенты и инженеры стоят в очереди, чтобы им установили на ПК OpenClaw (Clawdbot/Moltbot).

Поэтому Китай снова будет впереди планеты в технологическом плане.

Как я к этому пришёл?

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

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

Когда в первый раз я увидел такой инструмент, то он был не в лучшей своей форме. Как вы помните, это были сырые чат-боты, а генераторы видео могли создавать только странные смазанные видео с Уиллом Смитом, которые снятся при температуре 39. И я даже не мог придумать, а что у него спросить? Мой мозг ещё не понимал, что происходит, не осознавал, насколько этот инструмент серьезный. Поэтому я мог придумать только что-то вроде «Сколько тонн в одной ванной» или посмотреть как он решит какую-то математическую формулу — банальные вопросы.

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

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

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

С ИИ также. Он очень коварен.

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

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

Выше я поделился изречением Альтмана, но сейчас я бы его дополнил так: с текущей даты (в 2025) не родится человек, который не будет знать, каково это жить без искусственного интеллекта. Уже сейчас подавляющая часть молодежи с ИИ на «Ты». К примеру, в Англии, согласно свежему опросу за 2026 год, в котором приняли участие более 4000 человек в возрасте от 11 до 24 лет, почти 90% молодых людей уже использовали ИИ, а половина чаще доверяют ИИ, чем человеку.

В США, по данным Common Sense Media (июнь 2026 года) 86% детей и подростков в возрасте от 9 до 17 лет регулярно используют ИИ или взаимодействуют с ним, а среди старшеклассников (16–17 лет) эта цифра уже 92%, причем 30% используют ИИ ежедневно.

В Европе, в среднем, по данным Eurostat, 60–64% молодежи активно используют генеративный ИИ. Для сравнения, среди взрослого населения этот показатель в два раза ниже.

В России данные противоречивы, но можно однозначно сказать, что больше половины молодежи от 12 до 24 лет использует ИИ регулярно.

В Тайване в июне этого года вышло исследование в Taipei Times, где сказано, что «92% детей в возрасте от шести до 15 лет используют искусственный интеллект». А по остальному Китаю уже были данные выше.

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

Экономическая обстановка, трудовые обязанности на работе, быт — будут сами способствовать тому, что человек просто не сможет не использовать инструменты. Если 10 человек в твоем офисе работают с чатГПТ, ты не сможешь работать в команде.

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

Среда возьмет своё. Это так работает.

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

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

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

И вот, что ещё интересно.

Недавно появился глобальный доклад UNICEF Innocenti (июнь 2026). Не считая того, что в докладе поделились цифрами, которые показывают беспрецедентную скорость внедрения нейросетей в жизнь подрастающего поколения, эксперты ООН открыто заявили о формировании нового типа неравенства — AI Divide (ИИ-разрыв). Он заключается в том, что дети образованных и обеспеченных родителей используют ИИ как мощный инструмент для развития и буста карьеры. В это время дети из бедных семей или бедных стран используют его для развлечения или не имеют к нему доступа вообще. В будущем это создаст огромный разрыв в уровне квалификации на рынке труда.

А где мы хотим оказаться? На какой стороне? На стороне империи поздней династии Цин или на стороне технологичного мира 21-го века?

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

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

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

Источники

• OpenCourant — Open-source crash & impact simulation

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

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

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

Источники

• Release v1.46.0 · future-agi/future-agi · GitHub
• Future AGI · GitHub

Такую библиотеку можно опубликовать в npm, после чего другие агенты Frida смогут импортировать как вспомогательные функции, так и сами паттерны. Отдельно запускать TypeScript-компилятор и вручную согласовывать его настройки с Frida.Compiler больше не требуется. Режим наблюдения -w пересобирает пакет при изменениях, а параметр -S отключает генерацию карт исходников.

Swift ApiResolver теперь работает не только на платформах Apple, но также в Linux и Windows. Запросы к функциям, типам, протоколам и соответствиям Swift доступны везде, где загружена среда выполнения языка. Это расширяет возможности анализа кроссплатформенных Swift-приложений.

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

Источники

• Frida 17.22.0 Released | Frida • A world-class dynamic instrumentation toolkit

Для доменов на тарифах Free и Pro адаптивные наборы данных, включая HTTP-запросы, события безопасности и DNS-аналитику, теперь хранятся не менее 31 дня. За один запрос можно получить данные максимум за 30 дней. Ранее глубина истории зависела от набора данных и составляла от 24 часов до восьми дней.

Изменение действует в панели Cloudflare, пользовательских дашбордах и GraphQL Analytics API. Аналитика домена собрана в разделе Analytics с общим временным диапазоном и фильтрами, а аналитика аккаунта находится в Observability → Analytics.

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

Источники

• 30 days of analytics data on every plan · Changelog

Как использовать функцию

Например, выражение ниже сопоставит правило примерно с 10% случайно выбранных запросов:

В Cloudflare for SaaS долю трафика можно задавать отдельно для каждого hostname через пользовательский ключ rollout_pct со значением от 0 до 100. Если ключ отсутствует, функция coalesce() подставит 0, поэтому правило не выберет ни одного запроса.

Почему это важно

Функция упрощает поэтапные развёртывания и A/B-тесты на уровне правил Cloudflare. В продакшене процент запросов можно увеличивать постепенно, а для SaaS-сценариев управлять им через метаданные отдельных hostname.

Источники

• hash_in_range() is globally available for HTTP products · Changelog

Что доступно в бета-версии

На старте сервис поддерживает три поисковых провайдера: Ceramic.ai, Exa и Linkup. Все они предлагают режим Zero Data Retention для запросов через Cloudflare и обязались соблюдать стандарты компании для верифицированных поисковых роботов.

Запросы отображаются в журналах AI Gateway и оплачиваются кредитами сервиса по публичной API-цене выбранного провайдера без дополнительной наценки Cloudflare. Также разработчики могут подключить собственный API-ключ провайдера.

Для тестирования Web Search API можно использовать REST API или AI binding в Cloudflare Workers. Командам, которые добавляют веб-поиск в ИИ-приложения, это даёт единый способ выбирать провайдера и контролировать запросы через журналы шлюза.

Источники

• Introducing Web Search API · Changelog

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

Общий временной фильтр помогает проверить, совпадает ли рост ошибок Workers с изменением трафика или числом блокировок WAF.

Новые наборы доступны для каждого Worker в аккаунте, если для него включены Workers Logs или Workers Traces. Cloudflare также увеличила лимит Custom Dashboards до 100 дашбордов на аккаунт.

Источники

• Workers Observability logs and traces in Custom Dashboards · Changelog

Как работает новое ядро

LFortran представляет собой открытый компилятор Fortran на базе LLVM с интерактивным режимом. Его ядро использует C++-реализацию протокола ядер Jupyter — xeus, а для работы в браузере собрано в WebAssembly.

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

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

Ядро распространяется через emscripten-forge и может быть добавлено в развёртывания JupyterLite с jupyterlite-xeus. Для обычной установки JupyterLab по-прежнему доступен пакет LFortran из conda-forge.

Источники

• From Punch Cards to the Browser: Fortran Comes to JupyterLite · Jupyter Blog

Кого касается обновление

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

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

Как включить защиту

Cloudflare рекомендует обновить cloudflared до последней версии и передать разрешённый адрес при запуске туннеля:

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

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

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

Источники

• Protect Quick Tunnels with email authentication · Changelog

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

Сам или не сам — вот в чем вопрос

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

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

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

Что считается нормальной темой

Не хотим звучать как темщики, но «нормальные темы» в академической среде все ищут повсеместно. Только если в повседневности темки это что-то сомнительное, то в вузах норма определяется так:

1. По теме есть источники. Не 2–3 статьи в интернете, а 20-25 авторитетных источников. Хотя бы часть из них должна быть свежей. Проверка простая. Вбиваете тему в eLibrary и КиберЛенинку и смотрите, сколько статей за последние пять лет. Если результатов меньше 10, то лучше расширить тему.
2. Есть данные для практической части. Практическую часть вы пишете сами, но анализировать нужно что-то конкретное. Например, отчетность компании или опрос среди однокурсников. Спросите себя, что вы будете разбирать во второй главе и откуда это возьмете. Если ответа нет, тему можно считать сырой.
3. Влезает в объем. Курсовая в среднем составляет 25–30 страниц. «Маркетинг в интернете» туда не поместится, а «Цвет кнопки в приложении» уложится в две страницы. Ориентир такой, что тема должна звучать как задача, а не как целая область знаний.

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

Как выбрать тему быстрее при помощи ИИ

Помните, мы в начале говорили о том, что мощным инструментом тоже нужно уметь пользоваться? Зайдите в ИИ-чат от Автор24, скажите ему правильные слова, и он предложит варианты тем для курсовой работы.

Готовый промпт:

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

Специальность [ваша специальность и курс]

Дисциплина [название предмета]

Что мне интересно [пара пунктов, можно бытовым языком]

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

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

По каждой теме отдельными строками напиши.

1. Формулировка темы
2. Что будет во второй, практической главе
3. Где взять материал для нее, желательно в открытом доступе
4. Два или три запроса на русском, по которым искать литературу в eLibrary

Темы должны раскрываться в объеме 25-30 страниц.
Учитывай, что это курсовая на месяц, без долгих экспериментов и ручной разметки больших объемов данных. Сделай варианты разными по ракурсу.

Источники и ссылки не выдумывай.

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

Какие могут быть подводные камни?

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

Что стоит знать:

1. Нейросеть не знает внутрянку вашей кафедры. Откуда ИИ знать, что такую тему в прошлом году защищал ваш одногруппник. Или что вот эту научрук не одобрит.
2. Открытые данные бывают не такими уж открытыми. Нейросеть знает, что источник существует, но не знает, открыт ли он лично для вас. В той же eLibrary у материалов разные уровни доступа. Поэтому откройте источник заранее и убедитесь, что доступ у вас есть.
3. И самое главное — нейросеть не знает вас. Максимум она видит две строчки про ваши интересы и по ним предлагает темы. Но она может не знать, что от слова «эконометрика» у вас дергается глаз. Формально тема подойдет, а писать вы ее будете через силу.

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

Выбирайте то, от чего не будет воротить через месяц

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

На деле это просто модель поведения, которая усложняет жизнь. Всегда можно взять то, что вам интересно, и завернуть это в академическую формулировку. Собственно, этим промпт из статьи и занимается. Вы описываете свои интересы бытовым языком, а ИИ-чат от Автор24 возвращает восемь формулировок.

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

Реклама. Рекламодатель: ООО «ПМТ» ИНН 7813667410, erid: 2W5zFGqWzK3

Почему больше разработчиков не означает меньше работы

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

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

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

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

Как проверка паспорта затрагивает обработку заявки

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

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

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

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

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

В модели чистой архитектуры выделяют четыре области:

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

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

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

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

Что останется прежним при смене провайдера

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

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

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

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

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

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

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

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

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

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

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

Как сохранить границы, когда фича нужна вчера

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

В разборе есть три способа, рассказывающие, как с этим работать.

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

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

С чего начать в существующем проекте

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

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

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

• GPU-серверы: контроль над окружением для обучения, дообучения и инференса.
• Управляемый инференс: запуск модели с меньшим объёмом работ по развёртыванию инфраструктуры.
• Инструменты ML-разработки: ноутбуки и трекинг экспериментов для командной работы.
• Условия эксплуатации: доступность ускорителей, стоимость всей конфигурации, сеть и требования к данным.

Как выбирать облако под свою модель

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

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

Сравнивайте полную стоимость: GPU, CPU, RAM, диски, хранение датасетов, трафик и простаивающие ресурсы. Для сервиса с постоянными запросами дополнительно нужны мониторинг, резервирование и понятные условия масштабирования. Российское расположение дата-центра само по себе не закрывает требования 152-ФЗ: до загрузки персональных данных проверьте документы на конкретную услугу и распределение обязанностей между вами и провайдером.

1. immers.cloud — видеокарта на час, а не на год

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

Что это и кому подойдёт

immers.cloud — российское облако, которое сдаёт в аренду серверы с видеокартами NVIDIA. Сервер создаётся сам, через сайт или API: заявок и ожидания нет, обычно всё готово через несколько минут после регистрации и оплаты.

Кроме серверов у облака есть каталог готовых нейросетей Immers Foundation Models. По словам провайдера, в нём больше 200 открытых моделей — это крупнейший такой каталог в России. Для каждой указано, сколько видеопамяти ей нужно. Видеопамять — это рабочий стол нейросети: если модель на нём не помещается, она просто не запустится. Поэтому подсказка из каталога экономит часы проб и ошибок.

Два примера от провайдера:

• Команда «КС Авто» вынесла круглосуточную модерацию контента на три облачные RTX 4090 с Ollama: потоки изолированы по видеокартам, система работает стабильно, а на старте это обошлось дешевле команды из 15 модераторов.
• В IBS собрали песочницу для экспериментов с ИИ на GPUStack и vLLM: 11 серверов на A100, RTX 3090 и RTX 4090 обслуживают 14 моделей, и новую гипотезу проверяют за часы.

Облако рассчитано на тех, кто не боится командной строки: подключаться к серверу по SSH и настраивать окружение придётся самому. Мастера «в один клик» для всего ML-процесса здесь нет.

Какие видеокарты есть

Всего 13 моделей: H200, H100 NVL, H100, A100, V100, A10, A2, T4, RTX 5090, 4090, 3090, 3080 и 2080 Ti. В один сервер ставят до восьми карт, соединённых NVLink — быстрой шиной, через которую карты обмениваются данными, чтобы большая модель могла работать сразу на нескольких. InfiniBand для связи между серверами — по запросу.

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

Как запустить модель

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

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

Третий — обычный сервер: больше ста готовых образов в маркетплейсе, включая ComfyUI для генерации картинок. Управлять серверами можно через OpenStack API и Terraform.

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

Сколько стоит

Оплата посекундная, минимальный платёж — 100 ₽. Самый простой сервер с T4 стоит 20,34 ₽ в час, сервер с H200 — 423,04 ₽ в час. За предоплату на 30 или 60 дней дают скидку: на H200 — 10 и 15%, на T4 — 15 и 25%. Месяц H200 с предоплатой обойдётся в 274 129,80 ₽ вместо примерно 304 600 ₽.

Для новых пользователей есть тестовый период на 30 дней. Юрлица работают по оферте или договору через ЭДО, закрывающие документы приходят 5 числа каждого месяца. НДС провайдер не платит — он освобождён по статье 145.1 НК РФ.

Ограничения

• Трекинга экспериментов, версионирования моделей и датасетов, интеграций с MLflow и Kubeflow нет — полный MLOps-процесс придётся собирать самому.
• Одну модель на 400B+ параметров не получится разнести по нескольким серверам из коробки: потолок — восемь видеокарт в одной машине.
• По умолчанию у нового аккаунта лимит: четыре сервера, 16 vCPU, 128 ГБ памяти и 1600 ГБ хранилища. Расширяют через поддержку.
• В S3 нет версионирования, а скорость около 50 МБ/с и заметно плавает.
• Юрлицам на общей системе налогообложения НДС к вычету принять не получится.

Поддержка и документы

Поддержка работает круглосуточно: чат на сайте, Telegram, Max, почта и личный менеджер. Заявленное время ответа — не больше пяти минут. Инструкции собраны в FAQ на сайте и на YouTube-канале. У провайдера есть сертификат ГОСТ Р ИСО/МЭК 27001-2021 по защите информации, а за время простоя он обещает компенсацию в полном объёме.

Сайт: immers.cloud

2. Selectel — гибкие GPU-конфигурации

Selectel предлагает GPU как выделенное PCI-устройство внутри виртуальной машины. Можно подобрать CPU, RAM и диски под конкретную задачу, а рядом разместить хранилище, базу данных и другие компоненты приложения.

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

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

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

На GPU-ВМ можно использовать TensorFlow, PyTorch и другие ML-фреймворки, устанавливать собственное ПО и загружать образ системы. Доступен Kubernetes с GPU для обучения и инференса. Такой вариант удобен, если команда уже поставляет приложения в контейнерах и хочет встроить модели в тот же процесс разработки.

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

На странице продукта перечислены T4, A2, A30, A100, RTX 4090, RTX 6000 Ada и другие карты. Доступность зависит от пула. Управлять ресурсами можно через панель, API и Terraform; рядом доступны S3, IAM, балансировщики и резервное копирование дисков. Selectel заявляет соответствие серверов требованиям 152-ФЗ до УЗ-1: состав услуги и документы следует сопоставить с требованиями конкретной информационной системы.

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

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

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

Для подбора конфигурации на странице указаны sales@selectel.ru и телефон 8 800 555-06-75. Это каналы предварительной консультации; порядок обращения по техническим инцидентам и условия реакции лучше согласовать до запуска. Есть русскоязычная документация по созданию GPU-сервера, оплате, API и Terraform.

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

Оплата — по потреблению, стоимость выбранной конфигурации уточняется в калькуляторе на сайте. Для проектов аккаунта указаны 3 ТБ бесплатного внешнего трафика; дополнительный трафик — 0,90 ₽/ГБ. Услугой могут пользоваться физические и юридические лица: доступны пополнение картой и выставление счёта.

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

Официальный сайт: Selectel — облачные серверы с GPU.

3. Cloud.ru — управляемый инференс

Cloud.ru предлагает Evolution ML Inference для развёртывания моделей на GPU, в том числе из пользовательских Docker-образов. Это вариант для команды, которой нужно обслуживать запросы к готовой модели с автоматизацией развёртывания и масштабирования.

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

Разработчик может запустить модель из Hugging Face для текстового помощника; команда генеративной графики — развернуть обработку изображений; ML-инженер — передать собственное окружение в Docker. Это сценарии использования продукта, а не названные клиентские внедрения: на странице ML Inference конкретные заказчики не перечислены.

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

Поддерживаются vLLM, TGI, Ollama, Diffusers и Transformers, а также языковые, трансформерные и диффузионные модели. Помимо Hugging Face и маркетплейса, предусмотрен запуск с пользовательским Docker-образом. Сервис описывает динамическое автомасштабирование при изменении числа запросов.

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

Для ML Inference указаны V100 и H100, а также совместное использование GPU несколькими инференсами — Shared GPU. В экосистеме Evolution есть объектное хранилище, Kubernetes, реестр артефактов, мониторинг и логирование. Cloud.ru сообщает о дата-центрах в России; расположение ресурсов конкретного сервиса и доступную сетевую схему нужно проверить при проектировании.

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

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

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

Стандартная техподдержка работает бесплатно круглосуточно. На странице поддержки перечислены личный кабинет, телефон 8 800 444-24-99, support@cloud.ru и Telegram. Для проектов с дополнительными требованиями есть премиальный тариф по запросу.

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

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

Существенное ограничение для закрытых данных: Private Endpoint на странице ML Inference помечен «скоро будет доступен». Если доступ без публичного интернета обязателен, подтвердите готовность функции до выбора сервиса. ML Inference предназначен для исполнения моделей; обучение и дообучение требуют отдельного решения и расчёта ресурсов.

Официальный сайт: Cloud.ru — Evolution ML Inference.

4. VK Cloud — инструменты ML-разработки

VK Cloud предлагает GPU-ВМ и Cloud ML Platform с преднастроенными JupyterHub и MLflow. Это сочетание вычислительных ресурсов, среды для ноутбуков и инструментов работы с экспериментами.

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

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

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

GPU можно использовать для обучения и инференса на виртуальных машинах с Linux или Windows. В Cloud ML Platform доступны преднастроенные JupyterHub и MLflow; GPU-конфигурация подключается к среде разработки. Наличие этих инструментов уменьшает объём начальной настройки, но производственный API и процесс доставки модели всё равно нужно спроектировать.

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

Среди ускорителей перечислены L4, L40S, A30, A100 и V100. Для небольших нагрузок заявлена аренда доли карты через vGPU — от 1/24 до целого ускорителя. Доступные профили и объём видеопамяти необходимо уточнять под модель. Провайдер указывает российские ЦОД уровня Tier III и аттестацию виртуальных серверов по 152-ФЗ до УЗ-1. Рядом доступны объектное хранилище и управляемые базы данных.

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

Агрегированный пользовательский рейтинг на странице Cloud GPU не указан. Для оценки платформы имеет смысл провести небольшой командный эксперимент: проверить доступ к ноутбукам, запись метрик в MLflow и воспроизводимость запуска. Это покажет, насколько готовая среда соответствует процессам вашей команды.

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

Технические вопросы можно направлять через портал поддержки. При подключении Cloud GPU через заявку назначается менеджер для расчёта конфигурации и коммерческого предложения. Также доступна русскоязычная документация по GPU.

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

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

vGPU имеет смысл, когда задача не использует всю карту. Доля ускорителя ограничивает доступные ресурсы, поэтому нельзя выбирать её только по числу параметров модели: важны точность весов, длина контекста и параллельные запросы. Заявленный SLA 99,95% относится к доступности виртуальных машин и не означает такую же гарантию скорости ответов вашей модели.

Официальный сайт: VK Cloud — Cloud GPU.

5. Timeweb Cloud — облако и выделенные

Timeweb Cloud предлагает облачные и выделенные серверы с NVIDIA GPU. Провайдера можно рассмотреть для собственного ML-окружения и проектов, которым требуется отдельно подобрать физическую конфигурацию.

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

В каталоге историй на странице GPU есть проекты AI-компаний и голосовых роботов. Например, опубликована история миграции AI-сервиса и клиентских проектов. Для команды разработки практический сценарий — разместить модель рядом с бэкендом, S3 и базой данных. Для длительных вычислений можно отдельно обсудить выделенный сервер.

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

На сервер разрешено устанавливать собственное ПО; доступны SSH, KVM-консоль и приложения из маркетплейса. Провайдер относит к GPU-сценариям обучение нейросетей, распознавание речи и изображений, рекомендательные системы и чат-боты. Стек обучения, зависимости и сервер инференса можно собрать под свою модель.

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

В линейке перечислены T4, RTX 3090, RTX 4090 и карты серии A. Обычно провайдер предлагает от одной до четырёх GPU на сервер, большее количество обсуждается отдельно. В облаке есть Kubernetes, S3, базы данных и балансировщики. Наличие Kubernetes как соседнего продукта не следует автоматически считать подтверждением поддержки выбранной GPU-конфигурации в кластере.

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

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

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

Поддержка заявлена в режиме 24/7/365. На странице доступны чат, Telegram, форма обращения по электронной почте и телефон 8 800 700-32-92. Подбор нестандартной конфигурации и изменение выделенного сервера обсуждаются с командой провайдера.

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

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

У Timeweb Cloud есть российские и зарубежные площадки. Если данные должны оставаться в РФ, зафиксируйте российскую локацию и наличие нужной GPU именно в ней. Для выделенного сервера согласуйте срок подготовки и изменения конфигурации; обещание быстрого запуска облачной ВМ нельзя переносить на индивидуальную поставку оборудования.

Официальный сайт: Timeweb Cloud — серверы с GPU.

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

• Самостоятельное окружение: immers.cloud — GPU-серверы и каталог моделей; Selectel — GPU-ВМ и Kubernetes с GPU; Timeweb Cloud — облачные и выделенные серверы с установкой собственного ПО.
• Готовые инструменты: Cloud.ru — управляемый инференс с поддержкой Hugging Face, Docker и автомасштабирования; VK Cloud — Cloud ML Platform с JupyterHub и MLflow; immers.cloud — публичные и частные эндпоинты.
• Оплата: immers.cloud заявляет посекундный учёт, Selectel — оплату по потреблению, Timeweb Cloud — почасовые списания за облачные серверы. У VK Cloud минимальная аренда GPU-ВМ составляет час. Стоимость Cloud.ru нужно рассчитать для выбранной конфигурации инференса.
• Доступность: у Selectel состав GPU зависит от пула; VK Cloud предлагает подключение через заявку; H100 и H200 у Timeweb Cloud указаны как предзаказ. Наличие модели ускорителя в каталоге не гарантирует свободную конфигурацию на нужную дату.
• Ограничения: в immers.cloud потребуется самостоятельная настройка ML-процесса; у Cloud.ru Private Endpoint для ML Inference пока обозначен как будущая функция. Для Timeweb Cloud отдельно выбирайте российскую локацию, если этого требуют условия обработки данных.

Что выбрать под вашу задачу

Для проверки открытой модели начните с каталога immers.cloud, а для управляемого исполнения с масштабированием изучите Cloud.ru. Если важны командные ноутбуки и трекинг экспериментов, рассмотрите VK Cloud. Для собственного контейнерного стека с GPU подойдёт к рассмотрению Selectel; для выбора между облачной ВМ и отдельным физическим сервером — Timeweb Cloud.

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

Для агентов в API подешевел кэшированный вход: $0,10 за миллион токенов, вдвое меньше, чем у GPT-6 Sol. Кроме модели, OpenAI обновила инструменты: Codex работает в облаке с общими окружениями, Codex CLI принимает голосовые команды, Agents API научился управлять компьютером, а плагины ChatGPT встраиваются в боковую панель и реагируют на события во внешних сервисах. Запись трансляции выложена на YouTube.

• GPT-6.1 Sol: $2, $0,10 и $10 за миллион входных, кэшированных и выходных токенов; в ChatGPT Work и Codex — на Plus, Pro, Business, Enterprise и Edu, в обычном чате пока нет.
• По замерам OpenAI, на DeepSWE 1.1 GPT-6.1 Sol решает 75,2% задач при $0,65 за задачу, Astra — 74,1% при $4,43.
• Ultrafast ускоряет генерацию до 8 раз в Codex и до 6 раз в API; в подписке он есть только на Pro 500 за $500 в месяц и на подходящих тарифах Enterprise и Edu.
• Codex в облаке доступен с тарифа Plus, обновлённый Codex CLI и Code Review — на всех тарифах.
• Agents API получил computer use, а MCP Events запускает автоматизации плагинов по вебхукам из внешних сервисов.

GPT-6.1 Sol стоит в пять раз меньше Astra

GPT-6.1 Sol — обновление GPT-6 Sol, которую OpenAI выпустила в API 22 сентября. Стандартные цены у новой модели в пять раз ниже, чем у GPT-6 Astra. GPT-6.1 Sol уже работает в ChatGPT Work и Codex на Plus, Pro, Business, Enterprise и Edu со стандартной скоростью, а режим Fast, по документации, доступен там, где позволяют тариф, клиент, настройки рабочего пространства и раскатка; в обычном чате ChatGPT её пока нет.

Что показывают бенчмарки OpenAI

Результаты моделей OpenAI ниже — замеры самой компании, независимых подтверждений нет; результаты конкурентов она взяла из их публичных отчётов. На графиках по горизонтали — стоимость одной задачи в долларах, по вертикали — результат в процентах, точки на линии — уровни рассуждения от low до max. Чем точка левее и выше, тем выгоднее модель.

На DeepSWE 1.1, где модели решают длинные задачи в реальных кодовых базах, лучший результат GPT-6.1 Sol — 75,2% на уровне high при $0,65 за задачу. У Astra максимум 74,1% на xhigh при $4,43, у GPT-6 Sol — 68,8% на max при $2,74. На max GPT-6.1 Sol набирает меньше, чем на high, так что предельный уровень рассуждения здесь не нужен.

AutomationBench 1.0.6 проверяет сквозные бизнес-процессы с 47 инструментами. На уровне medium GPT-6.1 Sol на 2,2 п. п. выше Opus 5.5 примерно за треть цены, но на max впереди другие: Opus 5.5 с резервными моделями — 42,5% при $1,44, Astra — 41,4% при $1,73, GPT-6.1 Sol — 36,1% при $0,30. Цену Fable 5.1 ($2,45 за задачу) OpenAI в сноске называет заниженной: в неё не вошли вызовы резервной модели, которые понадобились примерно в 40% задач.

На OSWorld 2.0, где агент работает с обычными программами (частичная оценка на offline-наборе версии v2026.08.08), GPT-6.1 Sol на max набирает 71,4% при $1,27, Astra — 73,5% при $9,44, GPT-6 Sol — 64,4% при $3,37. Разница с Astra — 2,1 п. п. при цене примерно в 7 раз ниже.

На Terminal-Bench Science 0.1 (анализ данных, симуляции, доказательство теорем в терминале) GPT-6.1 Sol получает 57,0% при $5,47 за задачу, больше чем вдвое выше GPT-6 Sol. Лидирует Astra с 68,1% при $23,80, и OpenAI сама советует брать её для самых трудных научных задач.

На GDP.pdf, где нужно отвечать на вопросы по сложным PDF, GPT-6.1 Sol на max сравнялась с Astra — по 31,0% — при цене $0,42 против $2,08. Доля ответов с фактической ошибкой на уровне low снизилась с 11,4% до 7,7%, но замер сделан на специально трудных диалогах, нетипичных для обычной работы.

Ultrafast ускоряет генерацию токенов до 8 раз, но в подписке только на Pro 500

Ultrafast — платный уровень скорости: по данным OpenAI, в Codex это до 300 токенов в секунду, до 8 раз быстрее обычного режима, в API — до 6 раз быстрее. Широко он доступен только для GPT-6 Astra, для GPT-5.6 Sol в API есть превью. В API режим включается параметром service_tier, лимиты — от 500 тыс. до 5 млн токенов в минуту в зависимости от уровня аккаунта, региональные эндпоинты вроде европейского не поддерживаются, цены вынесены в отдельную таблицу. В Codex, по документации, Ultrafast расходует включённый в подписку лимит в 8 раз быстрее обычного режима.

Подписка Pro теперь бывает трёх видов: Pro 100 за $100, Pro 200 за $200 и Pro 500 за $500 в месяц, последний с Ultrafast и лимитом в 25 раз выше, чем у Plus. Pro 200 снова открыт для новых подписчиков, но с сокращённым лимитом. Подписчики, попавшие под условия сохранения, держат прежний лимит до 29 октября 2026 года. Ultrafast это не даёт, и покупка кредитов на Pro 100 или Pro 200 его тоже не открывает.

Codex получил облачные окружения, а CLI начал слушать голос

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

В Codex CLI задачи можно ставить и направлять голосом (голосовые диалоги появились ещё в версии 0.155.0), а новый экран /agents показывает сразу несколько делегированных задач. OpenAI также улучшила возобновление сессий и работу с git worktree. Доступно на всех тарифах, обновление ставится той же командой, что и сам CLI:

Code Review в десктопном приложении ChatGPT показывает сводку и диффы и позволяет спросить Codex о проблемах до комментария в пулл-реквесте GitHub или мерж-реквесте GitLab; в автоматическом режиме Codex делает первый проход в облаке сам. Функция есть на всех тарифах.

Codex Security Cloud сканирует репозитории GitHub по запросу или расписанию, следит за новыми коммитами, сам отсеивает дубли и готовит исправления, которые можно оформить черновым пулл-реквестом. В него входит доступ к моделям программы Daybreak Blue без отдельной заявки. Тарифы — Pro, Business, Enterprise и Edu.

Какие API OpenAI дала для собственных агентов

Agents API получил computer use: агент на нём может сам работать с программами. Туда же перенесли возможности Codex — несколько агентов в одной задаче, поиск инструментов, сжатие контекста, а инфраструктуру держит OpenAI. Песочницу для команд и файлов может дать OpenAI или ваш провайдер. В Codex и ChatGPT Work функция доступна на Pro 500 и Enterprise. По словам OpenAI, отдельной платы за сам Agents API нет: оплачиваются токены и инструменты.

Decisions API сводит работу модели Luna к ответам на заданные вопросы с фиксированными вариантами: так можно классифицировать контент, маршрутизировать запросы или выбирать следующий шаг агента. Пока это ограниченное превью. Bedrock Managed Agents, сделанные вместе с Amazon, запускают агентов OpenAI целиком внутри AWS.

Sign in with ChatGPT даёт тратить лимит подписки Plus или Pro в 16 сторонних сервисах, среди них Devin, Notion, Vercel и T3, с отдельным потолком для каждого.

Для компаний OpenAI собрала набор Private Intelligence: Private Safety Processing вместе с нулевым хранением данных позволяет проводить автоматические проверки безопасности без доступа сотрудников OpenAI к содержимому запросов, а превью Private Inference на конфиденциальных вычислениях обещано осенью.

Плагины встраиваются в интерфейс ChatGPT и реагируют на события

Plugin extensions открывают сторонним разработчикам платформу, на которой OpenAI делает функции ChatGPT: плагин получает пункт в боковой панели, панель рядом с диалогом, свой просмотрщик для форматов файлов, формы и упоминания в поле ввода. Точки входа объявляются в метаданных MCP-сервера ключом openai/ui, SDK есть для TypeScript и Python. Canva, Figma и Adobe уже используют расширения.

Для авторов плагинов появились Plugin Creator и обновлённая подача в каталог с более понятной обратной связью, а сами плагины можно подключать к Sites на тарифах Business, Enterprise, Healthcare и Edu.

MCP Events — поддержка предложенной спецификации событий MCP. ChatGPT подписывается на события сервера и выполняет инструкцию пользователя: например, на каждый баг-репорт в канале #product-feedback открывает черновой пулл-реквест. Серверу нужны протокол MCP версии 2026-07-28, методы events/list, events/subscribe и events/unsubscribe и доставка вебхуками с подписью Standard Webhooks, не больше 256 КиБ на событие. Опрос и стриминг не поддерживаются, события могут прийти не по порядку, поэтому инструменты записи должны быть идемпотентными.

Dots — агенты на GPT-6 Astra, которые работают круглосуточно

Dots — постоянно работающие агенты на GPT-6 Astra со своим облачным компьютером и браузером; через плагины они подключаются к более чем 4000 приложений и доступны в ChatGPT, Slack и Teams. OpenAI приводит сценарий для разработчика: агент следит за отзывами клиентов, сам делает мелкие исправления с тестами и приносит готовые пулл-реквесты. В фоне он работает только с инструментами на чтение. Первый dot входит в Pro и Business Premium без доплаты, раскатка идёт в поддерживаемых странах; у Enterprise, Edu и Healthcare это бета, которую включает администратор.

Что OpenAI добавила в ChatGPT для командной работы

• ChatGPT Space — общее пространство команды, ChatGPT и агента dot; Pro, Business и Enterprise, создавать и править можно в десктопном приложении и вебе, на телефоне пока только искать, читать и делиться.
• Pages — документы, которые вместе правят люди и агенты; Pro, Business и Enterprise.
• Совместные слайды с экспортом в PowerPoint и Google Slides — в ближайшие недели для Pro, Business и Enterprise.
• Команды и общие задачи, которые запускаются по расписанию или по событию, например новому письму; Business и Enterprise.
• @ChatGPT в Slack и Microsoft Teams, коллегам не нужна своя лицензия; Business и Enterprise.
• Плагин Meetings пишет заметки со встреч, аудио удаляется после подготовки заметок; бета на macOS для Pro и Business.
• Профили, где можно делиться своими Sites и плагинами; Business и Enterprise.
• OpenAI Marketplace: подходящие корпоративные клиенты могут подать заявку и направить часть действующего обязательства перед OpenAI на одобренный софт 32 партнёров, от Adobe и Figma до Salesforce и CrowdStrike.

Что ещё не вышло и что можно сделать сегодня

GPT-6.1 Sol Ultrafast обещан в ближайшие дни, широкий доступ к Decisions API — тоже, совместные слайды — в ближайшие недели, превью Private Inference — осенью. Точных дат OpenAI не назвала.

• В API достаточно заменить имя модели на gpt-6.1-sol; в Codex CLI модель меняется командой /model, режим Fast включается командой /fast.
• 14 октября 2026 года GPT-5.5 уйдёт из ChatGPT, ChatGPT Work и Codex на всех тарифах; в API она останется.
• Подписчикам Pro 200 стоит проверить почту: письмо о сохранённом до 29 октября лимите получат только те, кого коснулось изменение.

Источники: OpenAI: DevDay 2026 Recap, OpenAI: Introducing GPT-6.1 Sol, OpenAI: Introducing dots, OpenAI Help Center: About ChatGPT Pro tiers, OpenAI API: Ultrafast mode, ChatGPT Learn: Speed, ChatGPT Learn: Codex Cloud, ChatGPT Learn: Codex CLI, ChatGPT Learn: Code review, ChatGPT Learn: Codex Security Cloud setup, OpenAI: Introducing the Agents API, OpenAI Plugins: Extensions, OpenAI Plugins: MCP Events, OpenAI API: Private Safety Processing, Трансляция OpenAI DevDay 2026

Изображение на обложке: Кадр трансляции: OpenAI

Почти у каждой команды в 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

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

Для OAuth2 появился браузерный сценарий авторизации вебхуков n8n User Auth. Командам, которые используют агентов или такие вебхуки, стоит проверить существующие сценарии и права доступа в тестовой среде: версия пока предварительная.

Источники

• Release n8n@2.42.0 · n8n-io/n8n · GitHub

Среди ключевых изменений: устранение гонки активных запросов, закрытие основного дескриптора WAL перед заменой файла при восстановлении и отказ от тихого усечения слишком длинных целочисленных литералов до типа HUGEINT. Также исправлены ошибки оптимизации Top-N, работы с UNION ALL и Parquet, а также автоматического отката неудачных неявно обёрнутых наборов из нескольких SQL-инструкций.

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

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

Изменение касается разработчиков, которые повторно используют Browser Sessions для параллельной автоматизации. Чтобы страницы, cookies и хранилище разных запросов не пересекались, Cloudflare рекомендует создавать отдельный browser context для каждого клиента.

Для работы одновременных подключений нужно обновить @cloudflare/puppeteer до версии 1.1.0 или новее. После завершения запроса следует закрывать его context и отключать клиент через browser.disconnect(), не завершая общую браузерную сессию.

Источники

• Connect multiple clients to one Browser Run session · Changelog

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

На старте доступны Gemini 3 Flash Preview, Gemini 3.1 Pro Preview и Gemini 3.5 Flash. Ask также умеет искать сведения в документации Earth Engine и каталоге данных. Вместо этих источников можно подключить результаты Google Search, но одновременно использовать эти режимы нельзя.

Функция может сократить время на поиск методов API и ручное исправление ресурсоёмких запросов, однако пока это заявленные Google возможности. Для работы нужен собственный ключ Gemini API. Компания упоминает бесплатные варианты, а при использовании платного тарифа расходы рассчитываются по API. Ask заявлен как доступный по всему миру, но условия работы и оплаты из России отдельно не уточняются.

Источники

• Accelerate geospatial coding with AI in Google Earth Engine | Google Cloud Blog

Что вошло в обновление

В релизе опубликованы исправления для шести бюллетеней безопасности. Также разработчики скорректировали проверки длины данных и тайм-аутов, обработку H.264, работу звуковых каналов и программной смарт-карты, а также клиентов для Android, iOS, SDL и X11.

Кого касается

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

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

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

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

Пакеты релиза опубликованы на сайте проекта: https://pub.freerdp.com/releases/. Полный список изменений доступен в сравнении версий 3.32.0 и 3.32.1 на GitHub.

Источники

• 3.32.1 release

Новый режим позволяет обойти фиксированную версию Webpack в Forge CLI и загружать код из указанных каталогов без изменений. Разработчики могут запускать собственный tsc, выбирать другую версию TypeScript, использовать Vite или Esbuild либо отказаться от бандлера.

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

Если вы уже использовали ручную упаковку в рамках EAP, ничего менять не нужно. Для подключения функции следует указать bundler: manual@2026 и путь в секции app.package манифеста, а для UI Kit путь можно задать у отдельного ресурса.

Источники

• Forge changelog

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

Разработка важна для полупроводниковых компаний и создателей сложных систем: Synopsys пытается перенести ИИ с отдельных вспомогательных задач на выполнение целых инженерных процессов. Fujitsu сообщила о росте производительности при генерации RTL-кода на 10–30%, однако это результат отдельного кейса Fujitsu, а не независимый тест платформы.

По данным Synopsys, сейчас ведётся более 50 проектов сотрудничества с использованием AgentEngineer и Autopilot. Общая доступность запланирована на конец 2026 года. В релизе не указаны цены, условия лицензирования и доступность продуктов для клиентов из России.

Источники

• Synopsys Powers Autonomous Engineering with a Broad Portfolio of Long-Horizon Agents and Autopilot Platform - Sep 28, 2026

Чем отличаются монолит, модульный монолит и микросервисы

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

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

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

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

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

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

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

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

Что меняется, когда вызов функции становится сетевым запросом

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

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

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

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

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

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

Стоимость взаимодействия покажем на примере системы мониторинга качества видео Amazon Prime Video. Сначала она работала как распределённое решение на AWS Lambda и Step Functions. При увеличении нагрузки обмен данными и управление выполнением компонентов потребовали слишком больших расходов. Команда объединила систему в монолитное приложение, после чего расходы на неё снизились примерно на 90%.

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

Как масштабировать монолит и микросервисы

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

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

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

Воркеры и очереди задач

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

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

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

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

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

Чтение и запись в базе данных

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

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

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

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

Что усложняется при разделении данных между сервисами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы обсудить решение на конкретных примерах, команда может ответить на несколько вопросов:

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

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

Как понять, что компонент готов стать отдельным сервисом

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

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

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

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

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

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

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

Итого

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

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

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

NGENIX — фильтрация без центров очистки

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

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

Провайдер рассказал два сценария использования:

• Крупный федеральный ритейлер (название под NDA) пришёл в 2024 году с проблемой роста бот-трафика: боты парсили каталог, цены и остатки, резервировали товары без выкупа и искажали аналитику. Антибот-защита с поведенческим анализом, классификацией трафика и WAF в качестве последнего эшелона защиты позволила более чем вдвое сократить объём нежелательного трафика, устранить сценарии массового бронирования товаров, повысить конверсию, снизить показатель отказов на 35% и число клиентских жалоб более чем на 30%.
• Российская авиакомпания в сезонный пик столкнулась с ботами, которые отслеживали цены и бронировали билеты без выкупа — в отдельных случаях автоматика резервировала весь борт. После подключения антибот-защиты удалось существенно сократить количество автоматизированных обращений и обеспечить стабильную работу сервисов бронирования для реальных пользователей даже в период пиковых нагрузок.

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

Что можно подключить

NGENIX защищает от DDoS-атак на сетевом (L3/L4) и прикладном (L7) уровнях. Фильтрация L3 и L4 включена по умолчанию для всех заказчиков и работает круглосуточно, фильтрация L7 доступна с тарифа Lite. Заявленная мощность митигируемых атак — 7+ Тбит/с и 5 М+ RPS, включая атаки на DNS. IP-адреса веб-инфраструктуры маскируются, а при прямом подключении к платформе скрываются полностью, поэтому атака в обход не проходит.

Антибот строится на классификации: система анализирует поведенческие признаки, отпечатки браузера и сетевого стека и результаты JS-проверок и относит запрос к одной из четырёх категорий — «Публичный бот», «Точно бот», «Вероятно бот» или «Вероятно человек». Для каждой настраивается сценарий: пропустить, ограничить интенсивность через rate limiting, отправить на проверку (JS-челлендж, CAPTCHA, анализ отпечатков) или заблокировать. Строгие проверки применяются только к подозрительным запросам, чтобы исключить ложные срабатывания.

Для API анализируется не отдельный запрос, а поведение клиента целиком: последовательность вызовов, частота и интервалы, распределение по эндпоинтам. Так отсекаются парсеры с корректной авторизацией, неотличимые от легитимных клиентов по одиночным запросам. Отдельно закрываются скальперы, брутфорсеры, SMS-бомберы и кликеры, а запросы роботов Yandex и Google выделены в категорию публичных ботов.

Способов подключения четыре: делегирование DNS-зоны на серверы NGENIX (рекомендуемый), изменение DNS-записей через Anycast IP или CNAME и подключение по BGP. Среднее время подключения — один рабочий день. Правилами управляют через портал NGENIX Multidesk, открытый API или Terraform, метрики отдаются в формате Prometheus.

Редактор правила обработки запросов в NGENIX

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

Более 50 узлов в 23 регионах присутствия в России и ближнем зарубежье, пропускная способность — 7+ Тбит/с, более 1000 провайдеров в прямом взаимодействии. Каждый узел одновременно выполняет функцию центра очистки: анализ и фильтрация идут на месте. По данным провайдера, платформа ежедневно обрабатывает 60 млрд запросов и блокирует 2 млрд. Для анализа поступающего трафика используются технологии машинного обучения, которые помогают выявлять аномальный трафик и определять источники его возникновения. Результаты анализа применяются для классификации трафика и принятия решений о его блокировке либо дополнительной валидации. DNS построен на распределённой сети с производительностью 100+ млн QPS и поддержкой DNSSEC.

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

Поддержка работает круглосуточно: почта, телефон, мессенджеры, веб-форма и тикет-система в портале. Заявленная скорость реакции на критичные инциденты — до 15 минут, на «Энтерпрайзе» подключается персональный менеджер. Документация по настройке и API открыта в Центре поддержки, на публичной странице публикуется состояния сервисов.

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

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

Что именно входит в тариф

• Lite — 16 900 ₽ в месяц: 1 веб-ресурс, 100 Гбайт исходящего трафика, 100 млн. легитимных запросов, SLA: 99,4%
• Start — от 29 900 ₽ в месяц: 2 веб-ресурса, 1 000 Гбайт исходящего трафика, 200 млн. легитимных запросов, SLA: 99,4%
• Pro — от 69 900 ₽ в месяц при сроке от 12 месяцев,  2+ веб-ресурса, 3 000+ Гбайт или 50+ Мбит/с исходящего трафика, 200+ млн. или 100+ RPS легитимных запросов, SLA: 99,9%
• Ultimate — по запросу: 2+ веб-ресурса, 3 000+ Гбайт или 50+ Мбит/с исходящего трафика, 200+ млн. или 100+ RPS легитимных запросов, SLA: 99,95%+

Для компаний и организаций

Услуги оказывает российское юрлицо — ООО «Современные сетевые технологии» (ИНН 7733546298, ОГРН 1057747348427, Москва). Для регулируемых отраслей есть отдельный продукт: аттестованное публичное облако, соответствующее требованиям ФСТЭК по 152-ФЗ, ГОСТ Р 57580.1 и PCI DSS 4.0.1, с изоляцией сегментов сети.

Официальный сайт: ngenix.net

DDoS-Guard: надежная защита сайтов, API и мобильных приложений от DDoS-атак без тарификации атакующего трафика

DDoS-Guard — российский провайдер защиты от DDoS-атак, работающий с 2011 года. Компания управляет собственной сетью фильтрации ёмкостью 4 Тбит/с и защищает сайты, API и мобильные приложения от DDoS-атак в формате облачного сервиса, подключаемого через смену DNS-записей.

На рынке отличаются тем, что:

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

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

Провайдер поделился кейсами:

• Топ-3 сервис по заказу и покупке лекарств в стране столкнулся с техническими проблемами при использовании зарубежного сервиса защиты: высокой задержкой TTFB, медленной реакцией на rerouting и отсутствием гибкости в настройке защиты от DDoS-атак и парсинга, что напрямую влияло на производительность, безопасность и доверие клиентов. DDoS-Guard обеспечил миграцию с минимальным даунтаймом; стабильное соединение с сетью фильтрации и быстрый DNS resolve на территории РФ сразу значительно уменьшили показатель TTFB. Защиту подключили на уровнях L3–L4 и L7, а также настроили набор инструментов управления трафиком — правила защиты, сегментацию сайта и лимит запросов — для эффективной защиты от парсинга и скрейпинга. Дополнительно реализовали «параноидальный режим» с автоматической валидацией CAPTCHA, фильтрацию ботов с помощью JS challenge и управление функционалом через REST API.

• Крупное российское сообщество стремилось повысить устойчивость к постоянным кибератакам и сложным L7/L3–L4 атакам, сократить время простоя сайта с часов до секунд, а также внедрить инструменты для прозрачного анализа трафика и быстрой диагностики проблем пользователей. DDoS-Guard подключил защиту с постоянной фильтрацией L7-трафика и сетевого уровня (L3–L4): запросы проходят через каскад фильтров, вредоносный трафик блокируется до достижения серверов, а подозрительные запросы проверяются через CAPTCHA для минимизации ложных срабатываний. Также задействовали правила защиты, сегментацию сайта и лимит запросов (rate limiter). Во время аварийных работ в основном дата-центре функция «Активной балансировки» автоматически перевела весь трафик на резервный дата-центр, сохранив непрерывность работы для пользователей. Для ускорения диагностики проблем и сокращения ложных срабатываний разработали и внедрили решение с уникальным Request ID и сервисными страницами, содержащими детальные данные запроса (IP, временная метка).

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

Что можно защитить

Обеспечивается полная защита на уровнях модели OSI L3–L7. Под защиту ставятся сайты, API и мобильные приложения, при этом система эффективно фильтрует трафик и отделяет легитимные запросы от ботов-парсеров. Для защиты от скрапинга, брутфорса и SMS-бомбинга доступен модуль «Правила защиты» по условию «доверенный источник запросов», работающий на базе собственной репутационной базы DDoS-Guard. Для API-трафика этот функционал существенно снижает число ложных срабатываний.

Также среди инструментов управления трафиком доступны:

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

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

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

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

Управление правилами защиты вынесено в REST API (доступно на всех тарифах, кроме Basic). Решение полностью совместимо с инфраструктурами других облачных провайдеров, таких как AWS, Yandex Cloud и Selectel.

В услугу входят бесплатный SSL-сертификат, DNS-хостинг с полным доступом к управлению записями и CDN.

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

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

Из подтверждённой фактуры — запись в едином реестре российского ПО № 3665 от 28.06.2017 на продукт DDoS-GUARD Protection, свидетельство о государственной регистрации программы № 2023618722 от 27.04.2023, лицензия ФСТЭК № Л024-00107-00/00582472 и лицензии на телематические услуги и передачу данных. Компания аккредитована как ИТ-организация с 2016 года

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

Техническая поддержка и дежурная смена инженеров работают круглосуточно 24/7/365. Основное взаимодействие ведется через тикет-систему в личном кабинете, а в рамках приоритетных каналов связи используются Telegram-чаты.

Обработка обращений во всех каналах осуществляется исключительно сотрудниками — без применения автоматизированных ответов или ИИ-ассистентов. Заявленное время ответа зависит от тарифа: до 2 часов на Basic, до 40 минут на Normal, до 30 минут на Medium, до 15 минут на Premium и до 10 минут на Enterprise. Гарантированный SLA по доступности сервиса — 99,95%.

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

• Basic — 8 000 ₽/мес за один домен,
• Normal — 20 000 ₽/мес за один домен,
• Medium — 48 000 ₽/мес за три домена,
• Premium — 80 000 ₽/мес за пять,
• Enterprise — 200 000 ₽/мес за десять.

При оплате за 3, 6 и 12 месяцев действуют скидки 5%, 10% и 15%. Новым пользователям доступны 3 дня бесплатно на Basic.

В базовый тариф уже входят геоблокировки, бесплатный SSL-сертификат, DNS-хостинг и CDN.

Дальше набор услуг расширяется по тарифам:

• Normal: выделенный IP-адрес и поддержка сторонних сертификатов
• Medium: отчёты по L7-атакам и балансировка трафика между несколькими серверами
• Premium: пользовательские правила защиты и уведомления об инцидентах
• Enterprise: кастомные страницы, WAF и Bot Mitigation

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

Ограничения: на Basic нет управления через API и пользовательских правил защиты, WAF и Bot Mitigation подключаются на старших тарифах отдельными модулями, подключение реализовано только сменой DNS-записей — защита собственной сети по BGP относится к другому продукту — «Защита сети», а распространение новых DNS-записей занимает до 24 часов при высоком TTL домена.

Процесс подключения

Быстрое подключение через изменение DNS-записей. Настройка услуги в личном кабинете занимает от 5 минут (в том числе в условиях активной атаки), а само обновление DNS-записей занимает от 5 минут до 24 часов в зависимости от параметров TTL домена.

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

Для компаний и организаций

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

Официальный сайт: ddos-guard.ru

Curator: облачная защита сайтов, API и мобильных приложений от DDoS-атак и ботов без капчи

Curator — российский провайдер защиты от DDoS-атак и киберугроз, известный на рынке как Qrator Labs. Компания выросла из исследовательского проекта 2006 года, в 2009-м превратила его в коммерческое облачное решение, а в 2010-м запустила собственную фильтрующую сеть. Сегодня это сеть из 21 центра фильтрации по всему миру с пропускной способностью анализа и фильтрации свыше 6 Тбит/с.

На рынке отличаются тем, что:

• не используют CAPTCHA как основной механизм проверки: защита прозрачна для легитимных пользователей, а вредоносные запросы блокируются с первого обращения
• фильтруют HTTPS-трафик без раскрытия ключей шифрования SSL — это отдельная технология, критичная для банков и финансовых сервисов
• заявляют 0% ложных срабатываний в стандартном режиме работы и не более 5% под массированной атакой
• держат время реакции на атаку менее секунды на L3–L4 и до 60 секунд на L7
• собрали вокруг Anti-DDoS целую линейку из семи продуктов: CURATOR.ANTIDDOS, CURATOR.WAF, CURATOR.ANTIBOT, CURATOR.CDN, CURATOR.BGP, CURATOR.SECONDARYDNS и CURATOR.SCANNER — все работают в едином облачном периметре
• не тарифицируют нежелательный трафик: клиент платит только за легитимную полосу

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

Что можно защитить

CURATOR.ANTIDDOS нейтрализует DDoS-атаки всех типов на уровнях L3–L4 и L7, включая мультивекторные. Защитить можно как отдельный веб-ресурс, так и всю инфраструктуру — это зависит от способа подключения.

CURATOR.ANTIBOT закрывает отдельный класс угроз: веб-скрейпинг и копирование контента, брутфорс логинов и промокодов, credential stuffing и захват учётных записей, скликивание рекламы и накрутку метрик, автоматизированные атаки на API, а также бот-трафик, который используется как топливо для L7-атак. Продукт блокирует более 4 млрд бот-запросов ежемесячно.

Для мобильных приложений на iOS и Android предусмотрена отдельная схема: проверка окружения через браузерную аутентификацию при входе и валидация токенов безопасности для API-запросов. Прямые обращения к API тоже фильтруются.

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

CURATOR.WAF защищает от эксплуатации уязвимостей: SQL-инъекции, XSS, command injection, весь OWASP Top 10, атаки на бизнес-логику и на API. Для API доступны валидация HTTP-запросов, контроль параметров и заголовков, rate limiting и блокировка источников при аномалиях.

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

21 точка фильтрации по всему миру, суммарная пропускная способность анализа и фильтрации — свыше 6 Тбит/с. Сеть подключена к Tier-1-провайдерам, компания состоит в RIPE NCC с 2016 года и участвует в инициативе MANRS с 2021-го. Команда — более 80 экспертов в шести локациях, партнёрская сеть — свыше 200 партнёров по миру.

Решение полностью облачное: устанавливать модули на стороне клиента не нужно. Подключить можно двумя способами. DNS-подключение защищает веб-ресурсы на L7, работает с TCP-трафиком и не требует собственной автономной системы. BGP-подключение закрывает всю инфраструктуру, поддерживает все протоколы, включая UDP, но требует собственной AS и IP-блока.

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

Техподдержка доступна по бесплатному номеру, вопросы решаются также через почту mail@curator.pro, Telegram и сообщество во «ВКонтакте».

Гарантированная доступность сервиса зафиксирована в SLA и различается по тарифам: 97% на Professional, 99% на Business, 99,5% на Corporate и 99,9% на Enterprise.

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

• Professional — от 23 000 ₽/мес, SLA 97%, фильтрация вредоносного трафика до 10 Гбит/с
• Business — от 78 000 ₽/мес, SLA 99%, фильтрация до 50 Гбит/с, HTTPS-фильтрация без раскрытия ключей шифрования, защита WebSocket и TCP
• Corporate — от 160 000 ₽/мес, SLA 99,5%, фильтрация до 500 Гбит/с, BGP-подключение и выделенные порты
• Enterprise — по запросу, SLA от 99,9%, индивидуальная настройка

В каждый тариф включено 10 Мбит/с легитимной полосы, дальше — 800 ₽ за каждый дополнительный Мбит/с. Нежелательный трафик не тарифицируется вообще. Каждый IP-адрес сверх первого стоит от 7 000 до 25 000 ₽/мес в зависимости от тарифа. DNS подключается от 8 000 ₽/мес, CDN — от 10 000 ₽/мес. Новым пользователям доступны 7 дней бесплатно.

Ограничения: WAF, антибот, CDN, DNS и управление через API идут отдельными платными опциями, а не входят в базовый функционал. HTTPS-фильтрация без раскрытия ключей недоступна на Professional. BGP-подключение требует собственной автономной системы и IP-блока, поэтому проекту без своей AS остаётся только DNS-схема.

Процесс подключения

Настройка DNS-подключения занимает около 15 минут и не требует установки оборудования или модулей на стороне клиента. Дальше трафик идёт через фильтрующую сеть Curator, а в личном кабинете становятся доступны аналитика в реальном времени и автоматические отчёты по инцидентам. Бесплатный тестовый период — 7 дней, но если ресурс в этот момент уже под атакой, он сокращается до 24 часов.

Для компаний и организаций

ПО в реестре российского ПО и аккредитация ИТ-компании закрывают требования по импортозамещению при закупках. Решение поддерживает соответствие PCI DSS — за счёт фильтрации HTTPS без раскрытия ключей шифрования. Отдельный продукт CURATOR.BGP пригодится тем, кому важен мониторинг маршрутизации и защита от BGP-инцидентов.

Официальный сайт: curator.pro

StormWall: защита сайтов, сетей и TCP/UDP-сервисов от DDoS-атак с оплатой только легитимного трафика

StormWall — российский разработчик и поставщик защиты от DDoS- и хакерских атак для сайтов, серверов, сетей и ИТ-инфраструктур. Сеть очистки трафика состоит из 10 узлов по всему миру с общей ёмкостью фильтрации более 8 000 Гбит/с. Подключение веб-ресурса занимает 10 минут и делается через перенаправление DNS-записи на защищённый IP-адрес StormWall.

На рынке отличаются тем, что:

• держат самую большую заявленную ёмкость фильтрации среди российских провайдеров: более 8 000 Гбит/с
• берут деньги только за легитимный трафик: клиент платит за реальных пользователей, а не за объём атаки
• отбивают атаку быстро и бесплатно даже до заключения договора и отдают отчёт — решение работать дальше остаётся за клиентом
• дают SLA и время реакции прямо в тарифной сетке: от 3 часов на младшем тарифе до 15 минут на старшем
• закрывают не только сайты, но и сети через BGP и произвольные TCP/UDP-сервисы — это отдельные продукты, а не опции к веб-защите
• имеют статус локального интернет-регистратора (LIR), состоят в RIPE и являются официальным партнёром DE-CIX

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

Что можно защитить

StormWall для сайта фильтрует весь входящий трафик по технологии проксирования на уровнях L3–L7 и блокирует SYN Flood, UDP Flood, HTTP Flood, Slowloris, DNS amplification и атаки с ботнетов. Помимо веб-ресурсов защита есть для сетей через BGP и для произвольных TCP/UDP-сервисов — это отдельные продукты линейки. Для тех, кому нужна защита в собственной инфраструктуре, существует StormWall Appliance.

Антибот идёт двумя уровнями. Базовый включён во все тарифы на защиту сайта, не требует настройки и отделяет людей от скриптов интерактивными проверками: cookie-валидация, HTTP-редиректы, JavaScript-испытания и капча, когда без неё не обойтись. Продвинутый антибот доступен на тарифе Enterprise: настраиваемые сценарии защиты под конкретную бизнес-логику, анализ TLS-отпечатков JA3 и JA4, списки доверенных и недоверенных отпечатков, моделирование паттернов HTTP-запросов и гибкие комбинации правил. Реакций на срабатывание несколько — пропустить запрос, ограничить частоту, показать интерактивную проверку или заблокировать.

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

WAF защищает веб-приложения и API: SQL-инъекции, XSS, CSRF, атаки на API с контролем доступа и rate limiting, эксплуатация бизнес-логики. Покрытие — от OWASP Top 10 до целевых атак на API, с ML-детектом 0-day и 1-day угроз. Вместе с Anti-DDoS и антиботом получается трёхуровневая защита в одном контуре.

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

Сеть очистки — 10 узлов общей ёмкостью более 8 000 Гбит/с: Москва (ММТС-9), Санкт-Петербург (Selectel SPB-2), Майами (Equinix MI1), Лос-Анджелес (Equinix LA1), Франкфурт-на-Майне (Equinix FR5 и e-Shelter FR1), Гонконг (Equinix HK1), Сингапур (Equinix SG3), Дубай (SmartHub Fujairah), София (Telepoint Center) и Джакарта. На 2026 год заявлен запуск площадок в Сан-Паулу, Мумбаи и Алматы.

Кэширование статических элементов работает по технологии HyperCache и снимает нагрузку с веб-серверов — CDN идёт внутри подписки, без дополнительных затрат. Защита возможна без раскрытия SSL. На SEO и сервисы аналитики фильтрация не влияет, реальные IP-адреса посетителей сохраняются в HTTP-заголовке.

Личный кабинет даёт аналитику в реальном времени, настраиваемые правила фильтрации, историю атак, аналитику запросов и кодов ответов, автоматические уведомления об атаках, подробные отчёты в PDF и управление субаккаунтами и ролями. Отчёты о защите можно получать на почту не только по расписанию, но и в произвольный момент. На старших тарифах доступны управление антиботом (JA3 и цепочки) и доступ к логам запросов через Graylog.

Технологический стек компания раскрывает открыто: бэкенд на Python, PHP и C, фронтенд на HTML5, CSS3 и JS, PostgreSQL в качестве основной СУБД, контейнеризация по стандарту OCI и оркестрация на Kubernetes во внутренней инфраструктуре.

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

Поддержка работает круглосуточно, заявленная скорость ответа — до 15 минут. Поддержка в мессенджере доступна начиная с тарифа Business ONE. Гарантированное время реакции на запрос зафиксировано в тарифе: 3 часа на Personal, 30 минут на Business ONE, 15 минут на Enterprise ONE и StormWall Private.

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

Цены на защиту сайта опубликованы открыто (за один домен второго уровня):

• Personal — 12 000 ₽/мес, 25 Мбит/с полосы, SLA 98%, реакция за 3 часа
• Business ONE — 45 000 ₽/мес, 50 Мбит/с, SLA 99,2%, реакция за 30 минут
• Enterprise ONE — от 115 000 ₽/мес, 50 Мбит/с и выше, SLA 99,5%, реакция за 15 минут
• StormWall Private — от 348 000 ₽/мес, премиальная защита по индивидуальным правилам

Процесс подключения

Подключение занимает 10 минут и проходит в три шага. Клиент получает защищённый IP-адрес StormWall, DNS-запись сайта перенаправляется на этот адрес — дальше весь трафик проверяется, фильтруется и оптимизируется, а вредоносные запросы блокируются сразу. На сервер приходит только чистый трафик с сохранением реальных IP-адресов посетителей в HTTP-заголовке. Если у компании есть собственные сети, защиту сайта можно подключить по BGP без смены IP-адреса. Бесплатный тестовый период предусмотрен, а идущую прямо сейчас атаку в StormWall обещают отбить бесплатно и выдать отчёт.

Для компаний и организаций

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

Официальный сайт: stormwall.pro

Servicepipe: высокоточная защита сайтов, API и мобильных приложений от DDoS-атак и продвинутых ботов — в облаке и на своей инфраструктуре

Servicepipe — российский разработчик систем защиты веб-ресурсов и ИТ-инфраструктуры, работающий с 2015 года. Компания заявляет более 200 компаний под защитой, свыше 500 реализованных проектов, партнёрскую сеть из 110+ компаний и команду более 150 человек — инженеров NOC и SOC, аналитиков данных и разработчиков высоконагруженных систем. Отличие от чисто облачных провайдеров в том, что Servicepipe одинаково закрывает и сценарий «поставьте нам защиту в облаке», и сценарий «разверните её внутри нашего периметра».

На рынке отличаются тем, что:

• дают четыре схемы интеграции вместо одной: облачный Proxy, локальный модуль Cybert на NGINX или Angie, гибрид и IP-Transit с анонсом подсети — можно собрать конфигурацию под требования безопасности, а не подстраиваться под вендора
• принимают решение по каждому запросу менее чем за 1 миллисекунду и анализируют более 100 технических параметров запроса
• заявляют менее 0,01% ложных срабатываний
• работают без капчи по умолчанию: интеграция с CAPTCHA возможна, но не обязательна
• умеют терминировать зашифрованный трафик локально, без передачи ключей SSL/TLS наружу — через Cybert
• фильтруют не по IP-адресу, а по отдельным запросам, что важно для NAT и мобильного трафика
• тарифицируют защиту по полосе легитимного трафика без ограничений по объёму атаки: ни пиковая атака, ни многодневный DDoS не приводят к смене тарифа

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

Что можно защитить

Под защиту ставятся сайты, веб-приложения, API и мобильные приложения. Система закрывает DDoS-атаки на уровнях L3–L7, включая высокочастотные и низкочастотные, объёмные UDP-флуды с амплификацией, некорректные TCP-соединения, проблемы SSL-сессий и низкочастотные атаки поверх HTTPS.

По ботам список угроз шире обычного: веб-скрейпинг и парсинг контента, сканирование уязвимостей, SMS-бомбинг, брутфорс пользовательских аккаунтов, фейковые регистрации и мошеннические заявки, атаки на бизнес-логику из OWASP API Security Top 10 и OWASP Automated Threats.

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

Инструменты управления в личном кабинете: собственные правила, списки блокировки и разрешений, географические ограничения и лимиты частоты запросов. Для API отдельно доступен rate limiting.

Облачный WAF подключается поверх и закрывает атаки прикладного уровня. Устроен он необычно: Servicepipe предлагает на выбор три решения — PT Cloud Application Firewall от Positive Technologies, SolidWall от SolidLab и ПроWAF от WMX. Поддержка бывает двух уровней: базовая (подключение, дефолтные политики, сопровождение инфраструктуры) и Managed WAF (настройка политик под приложение, разбор ложных срабатываний, работа с вендором и закрытие уязвимостей правилами WAF).

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

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

Схем интеграции четыре. Proxy — облачная фильтрация ботов и DDoS через смену A-записи DNS с передачей SSL/TLS-сертификата. Module — локальный модуль Cybert на веб-сервере NGINX или Angie, без смены DNS-записей и без передачи ключей шифрования. Hybrid — облачная фильтрация DDoS в связке с локальной защитой от ботов через обратный TCP-прокси, при этом терминация SSL остаётся на стороне клиента. IP-Transit — фильтрация DDoS на сетевом уровне через анонс подсети.

Cybert — отдельный продукт для тех, кому нужна локальная защита сайтов, веб-приложений и API внутри собственной инфраструктуры. Работает на L7, решение принимает менее чем за 1 миллисекунду, ложных срабатываний менее 0,01%, поддерживает NGINX и Angie. Продукт соответствует требованиям PCI DSS и ГОСТ Р 57580.1–2017. Cybert используют более 20 российских компаний.

Для инфраструктуры есть DosGate (on-premise) и FlowCollector, для маркетинга — линейка Visibla, отдельно существуют защищённый DNS-хостинг и Digital Fraud Protection. В лабораторном контуре доступны стресс-тестирование и анализ логов веб-сервера.

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

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

Техническая поддержка работает круглосуточно и в проактивном режиме — она включена в услугу, а не продаётся отдельным пакетом. Заявленное время реакции на инцидент — 10 минут. Связаться можно по телефону, почте welcome@servicepipe.ru для новых обращений и cybert@servicepipe.ru для действующих клиентов. Для WAF отдельно доступен формат Managed, когда политики и разбор ложных срабатываний берёт на себя команда Servicepipe.

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

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

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

Ограничения: WAF работает только в схеме Proxy в связке с Web DDoS Protection или Web DDoS & Bot Protection, потому что для анализа прикладного уровня нужна расшифровка SSL/TLS. Локальный модуль Cybert поддерживает только NGINX и Angie — другие веб-серверы придётся закрывать облачной схемой. Публичных цен нет, так что быстро прикинуть бюджет по сайту не получится.

Процесс подключения

Подключение занимает от 10 до 30 минут. В облачной схеме нужно сменить A-запись DNS и передать SSL/TLS-сертификат — дальше трафик проходит через платформу фильтрации, проверяется и уходит на защищаемый ресурс обратным прокси. В локальной схеме модуль Cybert ставится на NGINX или Angie, менять DNS-записи не требуется. После подключения в личном кабинете становятся доступны правила, списки, геоограничения, лимиты частоты запросов, дашборды и логи.

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

Для компаний и организаций

Cybert в реестре российского ПО, у компании три лицензии ФСТЭК — требования по импортозамещению при закупках закрываются. Соответствие ГОСТ Р 57580.1–2017 и PCI DSS делает решение применимым в финансовом секторе, а локальная терминация шифрованного трафика подходит организациям, которым нельзя выпускать расшифрованный трафик за периметр. Для перехода с зарубежных ИБ-решений у компании есть отдельная программа миграции.

Официальный сайт: servicepipe.ruЧто выбрать

Если проблема не в объёме атак, а в ботах, которые работают по бизнес-логике — парсят цены, резервируют товар, накручивают клики, — смотрите NGENIX. Запросы раскладываются по четырём категориям, и для каждой вы сами выбираете сценарий; для API анализируется поведение клиента целиком, а не отдельный запрос.

Если вы под атакой прямо сейчас — DDoS-Guard. Настройка занимает от пяти минут даже в разгар атаки, порог входа — 8 000 ₽/мес за домен, опции докупаются без заявок и согласований, а в поддержке отвечают живые инженеры.

Остальные три — под более узкие задачи:

• Curator — когда нельзя терять живых пользователей на проверках: капча не используется как основной механизм, HTTPS фильтруется без раскрытия ключей.
• StormWall — когда нужно посчитать бюджет, не написав в отдел продаж: прайс открыт. Закрывает и сети по BGP.
• Servicepipe — когда расшифрованный трафик нельзя выпускать за периметр: модуль ставится на ваш NGINX или Angie. Цены по запросу.

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

Что исправили

• GHSA-x4c7-fpcx-w9q6, высокая опасность: смешение поставщиков идентификации позволяло принять SAML-утверждение не от того IdP, для которого начат вход, и захватить аккаунт.
• GHSA-jh92-5mrj-p2w2, высокая опасность: неподписанная cookie сессии Login V2 могла использоваться для захвата аккаунта.
• GHSA-w4gv-rcwj-w6r5, низкая опасность: пользователь с возможностью выдавать себя за конечных пользователей мог также имитировать администратора. Теперь для этого требуется разрешение admin.impersonation.

Кого касается обновление

В зоне внимания находятся администраторы ZITADEL 4.x, особенно администраторы инсталляций с SAML и интерфейсом Login V2. Login V1 не затронут проблемой с cookie.

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

1. Проверьте версию развёрнутого ZITADEL. Для всех установок ветки 4.x разработчики рекомендуют переход на 4.19.2.
2. Если используется Login V2, задайте переменную ZITADEL_SESSION_COOKIE_SECRET. Секрет должен содержать не менее 32 символов и совпадать на всех репликах. В Docker Compose ему соответствует LOGIN_SESSION_COOKIE_SECRET.
3. Предупредите пользователей о повторном входе после обновления. Старые cookie не имеют подписи и будут проигнорированы, а при поэтапном развёртывании авторизация может потребоваться несколько раз. Сессии приложений и уже выпущенные токены не затрагиваются.

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

Источники

• Release v4.19.2 · zitadel/zitadel · GitHub

• Help Desk vs Service Desk: Хелпдеск работает реактивно и чинит то, что уже сломалось. Сервис деск действует проактивно: управляет ИТ-услугами, изменениями и системными проблемами по канонам ITIL.
• Главный риск 2026 года: «Теневое ИТ» и заявки в мессенджерах. Если вы не контролируете поток обращений через единое окно, вы не контролируете бюджет и безопасность.
• Выбор архитектуры: Избегайте жестких монолитов. Ищите Low-code платформы, но обязательно с механизмами контроля изменений (Dev/Test/Prod), иначе аналитики «положат» вам продакшен.
• Метрики: Среднее время решения инцидентов MTTR — коварная метрика. Если этот показатель снижается, а доля возвращенных заявок Reopen Rate растет, ваши агенты просто «футболят» тикеты ради красивых отчетов.

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

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

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

Дисклеймер: статья подготовлена продуктовыми аналитиками SimpleOne. Мы создаем решения Enterprise-уровня и знаем, где проходят реальные границы применимости разных классов систем. Наша цель — дать объективный фреймворк для оценки Service Desk систем, без привязки к конкретным брендам.

Что такое Service Desk система

В академическом смысле Service Desk система — это единая точка контакта, или SPOC, между поставщиком ИТ-услуг и потребителями, будь то штатные сотрудники или внешние клиенты.

Если говорить языком эксплуатации, Service Desk это нервный центр вашей ИТ-инфраструктуры. Это программное обеспечение, которое перехватывает неструктурированный поток боли (письма «у меня всё висит», звонки, алерты от Zabbix) и превращает его в стандартизированные, отслеживаемые объекты с жесткими дедлайнами уровня SLA и понятными ответственными.

Service Desk и Help Desk: в чём разница и почему это важно

Главная ошибка бизнеса при закупке софта — путать эти два класса.

• Help Desk. Инструмент для оперативного тушения пожаров. Цель: как можно быстрее закрыть обращение клиента. Главный фокус здесь направлен на омниканальность: объединение чатов и соцсетей. Этот формат идеально подходит для интернет-магазинов и B2C-сегмента. Если у вас сломался принтер, Help Desk поможет быстро назначить специалиста техподдержки, который его починит;
• Service Desk. Инструмент стратегического управления ИТ. Цель: предоставление ИТ-услуги бизнесу с заданным качеством. Сервис деск система не просто чинит принтер. Она учитывает этот принтер в базе активов, понимает, по какому контракту он куплен, формирует заявку на закупку картриджей и отслеживает метрику доступности услуги печати для всего этажа.

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

Service Desk системы и ITIL 4: что реально нужно бизнесу, а что — маркетинг

Многие вендоры продают «полное соответствие ITIL 4». На практике, попытка внедрить все 34 практики ITIL одновременно гарантированно убьет ваш ИТ-отдел бюрократией. Зрелая система Service Desk должна железобетонно поддерживать 4 базовых процесса:

1. Управление инцидентами (Incident Management). Цель — восстановить работу сервиса любой ценой, даже если для этого потребуется временный «костыль» или жесткая перезагрузка. Скорость важнее всего.
2. Управление запросами на обслуживание (Service Request Management). Стандартные запросы, такие как выдача новых доступов или закупка периферии. Они должны быть автоматизированы через портал, чтобы не отвлекать дорогих инженеров L2/L3 от реальной работы.
3. Управление проблемами (Problem Management). Поиск корневых причин. Если роутер падает каждый вторник — это инциденты. Когда инженер анализирует логи и меняет прошивку — это управление проблемами. Это ваш инструмент борьбы с техническим долгом.
4. Управление изменениями (Change Enablement). Контроль любых релизов и патчей. Операционная реальность 2026 года: классический CAB-комитет из 20 человек, заседающий раз в неделю — мертв. Современный Service Desk должен уметь проводить 80% стандартных, низкорисковых изменений автоматически через CI/CD пайплайны, оставляя людям только согласование критичных релизов.

Зачем бизнесу Service Desk система: 3 сценария, когда без неё больно

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

1. Compliance и Аудит. К вам приходит аудитор (PCI DSS, ISO, Центробанк) и просит показать, кто и на каком основании выдал права администратора в ERP-системе уволенному сотруднику полгода назад. В чатах вы этого не найдете. Service Desk дает железный, неизменяемый лог (Audit Trail).
2. «Арбузные» SLA (Watermelon SLAs). Ваш ИТ-директор показывает красивый дашборд, где SLA зеленый (99%). Но бизнес в ярости, потому что CRM висит второй день. Без Service Desk с нормальной ресурсно-сервисной моделью (CMDB) вы измеряете доступность серверов, а не доступность услуги для бизнеса.
3. Удержание знаний (Bus Factor). Если работу вашей инфраструктуры понимает только один Senior DevOps, который завтра решит уволиться, ваш бизнес в заложниках. Service Desk с интегрированной базой знаний заставляет инженеров документировать решения.

Функции Service Desk системы

Полноценная Service Desk система обязана иметь под капотом:

• сложную машину маршрутизации (Routing) по навыкам, графикам дежурств (On-call) и загрузке агентов;
• движок SLA, учитывающий рабочее время разных филиалов, праздники и часовые пояса;
• гранулярную ролевую модель (RBAC) — чтобы инженер L1 не мог удалить финансовые отчеты;
• тесную интеграцию с CMDB (базой данных конфигураций).

Как работает система Service Desk

Разберем на примере инцидента в 3 часа ночи.

1. Система мониторинга (например, Prometheus) ловит скачок нагрузки на БД и через API создает инцидент в Service Desk.
2. Система проверяет CMDB и видит, что эта БД критична для мобильного приложения. Приоритет автоматически повышается до P1.
3. Таймер SLA начинает тикать.
4. Система смотрит график On-call и отправляет пуш-уведомление или SMS дежурному инженеру L2.
5. Инженер открывает тикет, видит привязанную статью из базы знаний с Known Error (известной ошибкой) и выполняет скрипт перезапуска пула соединений.
6. Инцидент закрывается, время простоя зафиксировано для отчета перед бизнесом.

Какой должна быть современная Service Desk система

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

Единое окно и омниканальность

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

Портал самообслуживания и база знаний

Это ваш главный инструмент экономии бюджета (Shift-Left). Если пользователь может сам найти статью и сбросить пароль без привлечения инженера L1 — вы экономите реальные деньги (Cost per Ticket).

Автоматизация и Low-code

Бизнес меняется. Вам нужно добавить новый маршрут согласования для ИБ. Если для этого нужно писать ТЗ вендору и ждать месяц — это плохая система. Современные платформы используют визуальные Low-code конструкторы. Но будьте осторожны: Low-code без жесткого контроля (Dev/Test/Prod) за год превратит вашу систему в неконтролируемое «спагетти» из процессов.

AI и чат-боты

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

Интеграции и экосистема

Система не должна быть изолированной. Ищите открытый REST API, коннекторы к Active Directory, системам мониторинга и инструментам вроде Jira или GitLab для прямой связи с разработчиками.

Мобильность и удобство

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

Service Desk на платформе SimpleOne: автоматизация, которая выходит за рамки заявок

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

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

• ESM-экосистема: единая платформа и общая модель данных позволяют автоматизировать работу не только ИТ, но и сервисных подразделений предприятия, включая HR, АХО, юридические и финансовые службы. Больше не нужно покупать 5 разных программ и мучиться с их интеграцией;

• встроенный IT-Governance:  мы учитываем риски Low-code разработки. Поэтому в SimpleOne встроен механизм версионирования метаданных (VCS). Бизнес-аналитик настраивает процесс в Dev-среде, тестирует, и только потом пакетно, безопасно переносит на Production. Никаких прямых правок в рабочей среде;
• ИИ-помощник (GenAI + RAG): интегрирован прямо в портал самообслуживания. Пользователь пишет «не могу зайти в почту», а ИИ сам находит нужную статью в KEDB или предзаполняет форму инцидента.

Преимущества Service Desk системы для бизнеса

С точки зрения ИТ-директора, внедрение правильной системы дает прозрачный ROI:

• снижение TCO (стоимости владения): за счет Low-code вы перестаете платить армиям сторонних программистов за каждую доработку формы;
• защита бюджета: вы можете с цифрами в руках доказать финансовому директору потребность в расширении штата, опираясь на графики переработок и роста объема заявок;
• минимизация штрафов: контроль SLA не позволяет нарушать контракты с внешними заказчиками.

Метрики Service Desk: 5 KPI, которые покажут реальную эффективность

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

1. FCR (First Contact Resolution) — процент заявок, решенных силами первой линии прямо во время первичного обращения. Формула: (решённые на 1-й линии / всего заявок) × 100%. Норма: 65-75%. Показывает квалификацию L1 и качество базы знаний.
2. MTTR (Mean Time to Resolve) — среднее время решения инцидента. Считается от создания тикета до закрытия. Важно: следите за этой метрикой в жесткой связке с Reopen Rate, то есть процентом переоткрытых заявок. Если MTTR падает, а возвраты растут — ваши инженеры формально закрывают тикеты ради KPI, не решая проблему по существу.

1. SLA Compliance — процент заявок, решенных в срок по SLA. Норма: >95%.
2. CSAT (Customer Satisfaction) — удовлетворенность пользователей после закрытия заявки. Измеряется коротким опросом (1-5 звезд).
3. Cost per Ticket — стоимость обработки одного тикета. Формула: (ФОТ службы поддержки + инфраструктура) / количество закрытых заявок. Должна снижаться по мере внедрения ИИ и портала самообслуживания.

По этим метрикам можно определить, на каком уровне зрелости находится ваш Service Desk.

Уровни зрелости Service Desk: на каком этапе ваша компания

1. Хаос (Реактивный): заявки в почте и мессенджерах. Инженеры работают в режиме постоянного стресса. Метрик нет.
2. Контроль (Базовый ITSM): внедрена система заявок. Есть инциденты и запросы. Появились базовые SLA и первая аналитика.
3. Проактивность (Зрелый ITSM): работает управление проблемами и изменениями. Инциденты предотвращаются до их появления. CMDB актуальна на 85-90%.
4. Бизнес-партнер (ESM + AI): ИТ-отдел транслирует свои сервисные практики на всю компанию (HR, АХО). ИИ забирает на себя рутину. Высокий процент самообслуживания (Shift-Left).

Как выбрать Service Desk систему

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

1. Смотрите на модель развертывания. Нужен ли вам On-premise?
2. Проверяйте Vendor Lock-in. Насколько легко выгрузить данные? Насколько проприетарный язык используется для написания скриптов? (В SimpleOne это стандартный JavaScript).
3. Оценивайте TCO, а не цену лицензии. Дешевая облачная подписка может разорить вас на стоимости интеграций и доработок в будущем.
4. Проводите нагрузочное тестирование (PoC). Ни один маркетинг не заменит теста на ваших реальных, тяжелых данных.

Ошибки при внедрении Service Desk

Даже лучшая система не взлетит, если ошибиться в процессах:

Автоматизация хаоса (Lift and Shift)

• что происходит: вы просто переносите кривые процессы пересылки писем в новую систему;

• к чему приводит: система становится дорогой почтой. MTTR не падает;

• как избежать: перед внедрением перерисуйте процессы (сделайте реинжиниринг).

Внедрение «всего ITIL сразу»

• что происходит: вы заставляете операторов заполнять по 15 полей для простой заявки, внедряете Проблемы и Изменения в один день;

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

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

Игнорирование UX для инженеров L1

• что происходит: руководство выбирает систему по красивым дашбордам для себя;

• к чему приводит: инженеры тратят лишние клики на закрытие тикета, выгорают и ищут обходные пути;

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

Миграция на российский Service Desk: что нужно знать до начала

Если вы съезжаете с Jira SM или ServiceNow, помните главное правило эксплуатации: не тащите с собой мусор.

Перенос 10-летней истории закрытых тикетов убьет производительность новой базы данных и сломает поиск.

• что делать: старую систему переведите в режим Read-Only (или выгрузите архивы в Data Lake для аудиторов);
• что переносить: мигрируйте только активные инциденты, актуальную структуру CMDB, живые контракты SLA и базу знаний;

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

Как Service Desk выглядит на практике: кейс из жизни

При запуске на рынок нового облачного провайдера «Облако.ру» (входит в АО «Группа Систематика») команда столкнулась с жестким дедлайном. Требовалось с нуля развернуть полнофункциональный Service Desk для технической поддержки внешних клиентов всего за 3 месяца.

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

Что сделали:

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

• на главную страницу вывели связку из контекстного поиска по базе знаний и формы мгновенной регистрации инцидентов, реализовав логику Shift-Left, то есть самостоятельное решение типовых проблем пользователем;
• настроили ядро процессов ITIL 4: управление инцидентами, регламентные запросы на обслуживание и управление проблемами для фиксации системных сбоев облачной инфраструктуры;
• разделили зоны видимости: клиенты получили прозрачный личный кабинет с трекингом статусов заявок, а вторая и третья линии поддержки — специализированные очереди с контролем параметров SLA.

Результат:

• Time-to-Market: полнофункциональный Service Desk корпоративного класса был введен в промышленную эксплуатацию ровно за 3 месяца;
• снижение нагрузки на L1: благодаря модульной структуре портала и доступности инструкций клиенты закрывают типовые вопросы через базу знаний, не создавая лишних обращений;
• архитектурная независимость: провайдер получил не закрытую «коробку», а гибкую платформу, логику которой внутренняя команда может перестраивать и развивать под новые сервисы без участия внешних разработчиков.

Заключение

Выбор Service Desk системы — это всегда компромисс между скоростью внедрения сегодня и стоимостью владения завтра.

Самая дорогая система — та, архитектурные ограничения которой заставят вас проводить новую миграцию через год. Поэтому при выборе инструмента смотрите за пределы ИТ-отдела. Оценивайте, сможет ли платформа масштабировать вашу сервисную модель на HR, юристов или АХО (в рамках ESM), насколько легко она интегрируется с системами мониторинга (CMDB) и позволяет ли вносить изменения без написания сотен строк кода.

Инвестируйте в архитектурно зрелые решения, тестируйте их на своих реальных данных в рамках пилота (PoC) и помните: задача Service Desk — не плодить бюрократию, а делать так, чтобы ИТ-услуги приносили бизнесу прогнозируемую пользу, защищая продакшен от хаоса.

FAQ

Что такое сервис деск система простыми словами?

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

В чем разница между Help Desk и Service Desk?

Help Desk сфокусирован на быстром решении текущих проблем. Service Desk — это более широкое понятие, он сфокусирован на предоставлении комплексных ИТ-услуг бизнесу, управлении качеством (SLA) и предотвращении будущих сбоев.

Чем Service Desk отличается от ITSM?

ITSM — это набор принципов, правил и лучших практик (методология, например, ITIL). Service Desk — это программный инструмент (софт) и подразделение людей, которые реализуют эти принципы на практике.

Можно ли использовать service desk без ИТ-отдела?

Да. Это называется ESM (Enterprise Service Management). Современные платформы уровня SimpleOne позволяют перенести в единый Service Desk процессы приема на работу из HR, ремонтные заявки из АХО и согласование договоров от юристов. Все отделы работают в одной среде по единым стандартам SLA.

Сколько стоит внедрение service desk системы?

Легкие облачные решения (SaaS) для малого бизнеса обойдутся в несколько тысяч рублей за оператора в месяц. Внедрение тяжелой Enterprise-платформы (On-premise) с интеграциями, настройкой CMDB и консалтингом — это капитальные затраты (CAPEX), исчисляемые миллионами рублей. Всегда считайте ТСО на 3-5 лет.

Как долго длится внедрение?

Облачный хелпдеск можно запустить за неделю. Полноценное внедрение Enterprise Service Desk с аудитом процессов, настройкой интеграций (AD, 1C, мониторинг) и обучением сотен инженеров занимает от 3 до 9 месяцев. Обещания сделать это за месяц — маркетинговый миф.

Как мигрировать с Jira или ServiceNow на российскую систему?

Ищите платформу с сопоставимой объектной моделью и Enterprise-архитектурой (Low-code + Pro-code), например, SimpleOne. Откажитесь от стратегии «Lift and Shift», то есть слепого копирования старых неэффективных процессов в новую систему. Проведите аудит, вычистите мусорные данные, мигрируйте только активные заявки и актуальную базу знаний, используя инструменты автоматического импорта.

Реклама. Рекламодатель: ООО «СИМПЛ 1» ИНН 9725013892, erid: 2W5zFK7Lq3w

GitHub также исправила загрузку расширений при применении управляемой политики MCP. Кроме того, устранены сбои Git 2.36 и новее в приложениях, запущенных из оболочек CLI, когда отбрасывались пустые переменные окружения. Эти исправления важны прежде всего для организаций с централизованными настройками и разработчиков, запускающих другие инструменты из сессии Copilot.

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

Версия 1.0.89-5 помечена как предварительная. Для работы с Copilot CLI нужна активная подписка Copilot, каждый запрос расходует один премиальный запрос. Цена, конкретные месячные лимиты и доступность сервиса из России в материалах к релизу не указаны.

Источники

• Release 1.0.89-5 · github/copilot-cli · GitHub
• GitHub Copilot CLI · GitHub

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

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

Источники

• Release Release 2026-09-27 14:08 · TanStack/router · GitHub

Кого касается обновление

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

Перечисленные изменения доступны после обновления FreshRSS до версии 1.27.1.

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

Администраторам стоит проверить версию своей установки и запланировать переход на 1.27.1. После обновления имеет смысл убедиться, что вход и повторная аутентификация работают штатно, а для Docker-развёртываний настроить доступный теперь healthcheck. Точные команды зависят от способа установки и в примечаниях к релизу не приведены.

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

Источники

• Release FreshRSS 1.27.1 · FreshRSS/FreshRSS · GitHub

В новой версии исправили обработку исключений в обработчике TCP connect(). Разработчики также изменили отмену TransformStream: теперь она завершается на основе состояния записываемой стороны, а объект преобразования освобождается после окончания работы потока.

Среди других изменений: политика повторных попыток для вызовов JSRPC, чтение отсоединённых и вышедших за границы буфера фрагментов DataView как пустых, обновление типов reasoning для Workers AI и дополнительные проверки линтера на использование перемещённых объектов.

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