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

Сам или не сам — вот в чем вопрос

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

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

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

Что считается нормальной темой

Не хотим звучать как темщики, но «нормальные темы» в академической среде все ищут повсеместно. Только если в повседневности темки это что-то сомнительное, то в вузах норма определяется так:

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 и какие правки это уже вызывает. На примере проверки паспорта задача состоит в том, чтобы отделить правила обработки заявки от получения результатов проверки.

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

Почти у каждой команды в 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

Чем отличаются монолит, модульный монолит и микросервисы

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

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

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

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

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

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

В микросервисной архитектуре части системы работают как самостоятельные сервисы. Заказы и биллинг можно развёртывать отдельно, выделять им разные ресурсы и разрабатывать силами разных команд. Для получения суммы заказов биллинг обращается к сервису заказов через 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. Цены по запросу.

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

• 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

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

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

Коротко о рейтинге

1. Pixel

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

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

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

Кому подойдёт: детям, которым интересны ИИ, программирование и создание собственных цифровых проектов.

2. 3D.GRYZ — «Мультфильм с нейросетями»

Это один из наиболее специализированных вариантов именно для создания мультфильмов с ИИ.

Курс рассчитан на детей 10–14 лет. Программа включает 8 занятий по 90 минут. Ребёнок проходит путь от идеи до готового мультфильма примерно на 30 секунд.

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

Используются Flux, AI-видео, AI-озвучка и DaVinci Resolve. Генерация выполняется на серверах курса, поэтому мощная видеокарта не требуется.

Стоимость живого потока указана от 12 990 рублей.

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

3. Компьютерная академия TOP — «Создание мультфильмов с нейросетями»

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

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

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

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

4. CODDY — «Нейросети и ИИ для подростков»

Программа CODDY рассчитана на подростков и включает не только генерацию изображений, но и создание видеороликов с помощью ИИ.

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

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

Кому подойдёт: подросткам 13–16 лет, которые хотят изучать ИИ комплексно.

5. Rocket Tech School — «Нейросети для детей»

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

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

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

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

6. Пандаматика — «Мультипликация с ИИ»

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

Курс рассчитан на детей и подростков 8–16 лет, длится 2 месяца и включает 16 занятий. Группа — до 6 человек.

В программе заявлены Midjourney, Kandinsky, Kling AI, Runway ML, ElevenLabs, Suno, CapCut и DaVinci Resolve.

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

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

7. II Университет — «Нейросети для детей»

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

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

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

Кому подойдёт: подросткам, которым интересно создавать разный контент с помощью ИИ.

8. T-Teach — «Бесплатные нейросети для детей»

Курс рассчитан на детей от 8 лет и знакомит с разными возможностями нейросетей.

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

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

Кому подойдёт: для первого знакомства с AI-инструментами.

9. TEEN.AI

TEEN.AI позиционирует себя как онлайн-школа нейросетей для детей 6–14 лет.

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

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

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

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

Родителям стоит проверить пять вещей.

1. Что ребёнок создаст?

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

2. Есть ли монтаж?

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

3. Есть ли обратная связь?

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

4. Сколько практики?

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

5. Что лучше: курс по ИИ или отдельный курс по мультфильмам?

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

Что должен уметь ребёнок после курса?

Хороший результат — не просто список освоенных нейросетей.

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

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

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

FAQ

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

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

Нужно ли ребёнку уметь рисовать?

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

Нужен ли мощный компьютер?

Зависит от курса. Например, на программе 3D.GRYZ генерация выполняется на серверах, поэтому мощная видеокарта не требуется.

Что лучше: курс по ИИ или отдельный курс по мультфильмам?

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

Итог

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

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

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

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

И начнем мы с типа хостинга.

VPS, PaaS и Serverless хостинг для ботов

В зависимости от цели, вам подойдут разные варианты.

VPS/VDS сервер даёт полный контроль над работой инфраструктуры, но требует самостоятельной настройки сервера и его администрирования. Вы сами ставите Python или Node.js, настраиваете systemd, чтобы бот перезапускался при сбоях, Nginx для приёма вебхуков, сертификаты, файрвол. Примерами VPS-провайдеров являются Selectel и Beget.

PaaS-платформы позволяют полностью избавиться от настройки сервера. Вы привязываете репозиторий или загружаете код в интерфейсе. Сборку, запуск и настройку делает сам сервис. Примерами таких специализированных PaaS-платформ являются Heroku, Render и российская PaaS-платформа Amvera. Принцип такой, что вы делаете git push и не беспокоитесь о настройке инфраструктуры, всё просто работает само. Международные PaaS-сервисы требуют оплату иностранными банковскими картами, если хотите платить рублевой картой, рассмотрите Amvera.

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

PaaS-платформы для хостинга ботов

PaaS-платформы позволяют поставить бота на хостинг через механику git push to prod и не требуют настройки сервера.

Amvera – российское PaaS-облако с оплатой в рублях. Деплоить можно через git push, drag and drop в интерфейсе или MCP. Есть встроенная поддержка Python, Node.js, Docker, Go, JVM, PHP, C# и других окружений. Токен бота можно сохранять в сервисе секретов. Для webhook в Amvera есть бесплатные https-домены. Хранить данные можно в постоянном хранилище с бэкапами (подходит для SQLite или JSON) или в управляемых PostgreSQL, Redis, MySQL, MongoDB. Есть возможность управления и откатов версий сборок.

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

Код ботов в Amvera работает непрерывно без холодных стартов.

На сентябрь 2026 в Amvera уже зарегистрировано более 100 000 разработчиков, что делает Amvera одним из лидеров среди российских PaaS-облаков.

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

Для хостинга Telegram-ботов и их доступа к Telegram Bot API в Amvera есть регионы в Европе и США и бесплатное проксирование из Российского региона.

Мы создаём сервис, задача которого облегчить процесс деплоя. Миссия Amvera — позволить вам сфокусироваться на своем проекте, а не на настройке сервера. Git push to prod — всё что вам нужно для деплоя в Amvera.

Heroku – родоначальник PaaS-облаков и изобретатель механики git push to deploy. Есть поддержка основных языков и окружений, встроенный CI/CD, продвинутый мониторинг и много корпоративных функций.

Хранить данные можно в управляемых Redis и PostgreSQL.

Для бота подойдут тарифы за 4–25$ в месяц (российские карты не принимаются).

Важно, что с 2026 Heroku находится в состоянии поддержки и не выпускает новых функций.

Описать Heroku можно цитатой ее сооснователя:

Главное, что взрывало людям мозг, — это команда git push для деплоя. Именно эту основную идею люди перенимали у Heroku: она полностью избавляла от всей той рутины, которую, как они думали, они обязаны были делать.

Render – более современная и простая альтернатива Heroku. Есть почти всё, что и в Heroku, но отдельно вынесены сервисы Background Workers и Cron Jobs. Есть бесплатный тариф, но он для ботов не подходит из-за засыпания процесса через 15 минут и минутного холодного старта.

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

VPS и VDS-серверы для хостинга ботов

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

Selectel – крупный инфраструктурный провайдер. Цены на VPS начинаются от 200 р. (для региона в Казахстане будет дороже). Selectel больше специализируется на Bare Metal, но и виртуальные серверы у провайдера есть.

Beget – один из старейших хостингов, известный своей клиентоориентированностью и качеством поддержки. Стоимость аренды VDS начинается от 660 р. в месяц.

Бесплатный хостинг бота у Serverless-провайдеров

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

Yandex Cloud Serverless Functions – российское облако с сервисом Serverless.

По актуальности на сентябрь 2026 г. в рамках Free Tire в сервисе входит 1 млн вызовов функций, 10 Гб/час работы процесса и 100 Гб трафика.

Поддерживаются такие окружения как Node.js (актуальная поддерживаемая версия — Node.js 22), Python, Go, PHP, Java / Kotlin, C# (.NET Core), Bash / R.

Время холодного старта составляет до секунды для интерпретируемых языков и до 5 секунд для статически типизированных языков.

Цена сверх бесплатного уровня составляет 19 р. за миллион вызовов и 6,5 р. за Гб/час работы процесса.

Cloudflare Workers – один из международных лидеров, среди Serverless-провайдеров.

По актуальности на сентябрь 2026 г. в рамках Free Tire есть 100 000 запросов в день, трафик бесплатен.

Поддерживается JavaScript / TypeScript, Python и компилируемые в WASM языки.

Холодный старт составляет менее 5 мс.

Цена сверх бесплатного уровня составляет 0,3$ за 1 млн запросов и 1 цент за 1 млн миллисекунд процессорного времени.

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

Нужен ли боту постоянно работающий сервер?

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

Как Webhook и long polling влияют на выбор хостинга?

Webhook быстрее и экономичнее по трафику, но требует публичного HTTPS-адреса. PaaS-платформы обычно выдают такой домен вместе с сертификатом. Long polling проще настроить, и он не требует домена, но хуже масштабируется и чувствительнее к сетевым разрывам. Для polling чаще используется VDS или такие PaaS, как Amvera, где код работает непрерывно.

Сколько ресурсов реально нужно серверу бота?

Типичный код бота на aiogram на Python версии 3.11 в среднем потребляет около 150 мб ОЗУ, но все зависит от конкретной реализации. Если вы используете VPS, надо закладывать еще место под ОС, и брать сервер с 1–2 Гб ОЗУ. Если вы используете такие PaaS-платформы как Amvera, тарифицируется только фактическое потребление ресурса кодом и для типичного бота хватит самых младших тарифов за 170–290 р. в месяц.

Как хранить данные бота?

Если бот хранит данные, нужна СУБД. В качестве СУБД для ботов чаще всего используются SQLite, PostgreSQL и Redis. На таких PaaS, как Amvera, управляемые базы данных есть как отдельная услуга с бэкапами (а для SQLite доступно встроенное бесплатное постоянное хранилище с бэкапами), без необходимости настраивать и обслуживать СУБД вручную. На VPS СУБД придётся устанавливать и администрировать руками и нести ответственность за корректность их бэкапов.

Как оплачивать аренду сервера из России?

У зарубежных PaaS-платформ Render и Heroku нет поддержки российских банковских карт, что требует наличия иностранной картой. Российская платформа Amvera и другие российские провайдеры принимают оплату напрямую рублёвыми картами и переводами от российских юридических лиц.

Как обеспечить доступ к Telegram Bot API, OpenAI и другим внешним сервисам из России?

Для доступа к Telegtam Bot API и API LLM-провайдеров из России нужен прокси. Amvera предоставляют встроенный бесплатный прокси для доступа к таким сервисам, что избавляет от необходимости поднимать и поддерживать его самостоятельно. Альтернативным сценарием является размещение проекта в иностранном регионе, где нет блокировок у российских или иностранных сервисов.

PaaS или VDS — что выбрать?

Если не хочется разбираться с Nginx, systemd и сертификатами, и поставить бот на хостинг за минуту через git, то выбирайте PaaS (Amvera, Heroku). Если нужен полный контроль над окружением, нестандартный стек или много приложений на одном сервере, можно выбрать VPS (Beget, Selectel) или аналогичного провайдера и настроить всё самостоятельно.

Какой сервер арендовать для Телеграм-бота в 2026–2027

Если вам нужен простой деплой через Git, оплата в рублях, встроенные управляемые базы данных и работа без холодного старта, Amvera закрывает большинство основных потребностей бота “из коробки”. Amvera не требует настройки и администрирования сервера и даёт все функции PaaS-платформ. Для более нестандартных сценариев, или если требуется глубокая настройка окружения, имеет смысл рассмотреть классические VPS, такие как Beget. А если нужен бесплатный хостинг бота, то можно попробовать уложиться во Free Tier от Serverless-провайдеров, таких как Cloudflare Workers.

Сколько времени занимает работа

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

В среднем человек бодрствует около 16 часов. На работу, дорогу и всё, что с ней связано, уходит 8–10 часов, а иногда и больше. Получается, профессиональная сфера занимает от ½ до ⅓ активного времени.

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

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

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

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

Сначала ресурс, потом мотивация

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

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

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

На перестройку привычки может уйти от 21 до 40 дней. В этот период сопротивление нормально: новая модель поведения ещё не стала автоматической. Несколько неудачных дней не отменяют весь процесс.

Сильные стороны помогают тратить меньше усилий

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

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

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

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

Фокус внимания меняет отношение к рутине

Даже интересная работа состоит из повторяющихся действий. Вопрос в том, что именно вы в них замечаете.

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

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

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

Если задачи не вдохновляют

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

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

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

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

Ритуалы снижают внутреннее сопротивление

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

• Свободное письмо в течение 5–7 минут помогает выгрузить накопившиеся мысли.
• Фраза «Я выбираю заниматься своей работой», произнесённая вслух, возвращает ощущение собственного решения.
• Короткая прогулка, чашка чая без телефона или несколько минут тишины дают паузу перед следующей задачей.

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

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

Удовольствие от работы можно тренировать

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

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

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

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

Что именно сломалось 1 апреля 2026 года

Это не слух из телеграм-каналов. Apple завела под эту историю отдельную страницу поддержки — support.apple.com/en-us/126891, дата последнего обновления 29 мая 2026 года.

Формулировка там такая: с 1 апреля 2026 года оплата подписок и цифровых покупок Apple в России недоступна со счетов мобильных операторов по причинам, не зависящим от Apple. И дальше главное — новые покупки в App Store и других сервисах Apple Media Services, включая покупки внутри приложений и продление подписок, в России больше недоступны, если на балансе аккаунта Apple нет средств.

Список задетых сервисов Apple приводит целиком: Apple Arcade, Apple Fitness+, Apple Music, Apple One, подписки в Apple Podcasts, покупки и подписки App Store, покупки и подписки Apple TV, iCloud+, покупки в iTunes Store и покупки рингтонов.

Что это значит по шагам:

• Если на балансе аккаунта пусто, списывать за iCloud+ нечего — подписка прекращается. Apple так и пишет: если списать оплату не выходит, подписка заканчивается.
• Пополнить баланс аккаунта Apple в России тоже нельзя. Это отдельный абзац на той же странице: обработка платежей для пополнения баланса в России недоступна с той же даты.
• Карты российских банков тут ни при чем — Visa и Mastercard российского выпуска не работают за периметром страны с 2022 года, «Мир» Apple не поддерживает. Оплата со счета мобильного была последним простым каналом, и он закрылся.
• Коды App Store, которые вы купили раньше, еще активируются. Apple это прямо разрешает.

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

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

Отдельно: если вам предлагают «пополнить Apple ID за пять минут»

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

Я за этот месяц насмотрелся таких предложений в поиске и в чатах. Логика у них одна: «дайте логин и пароль, мы зальем баланс». За паролем от Apple ID лежат ваши фотографии, «Локатор», переписка в iMessage и все привязанные платежные методы. Это не та цена, которую стоит платить за подписку на облако.

Почему иностранная карта на российском аккаунте не помогает

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

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

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

Рабочая связка состоит из трех элементов сразу:

1. регион аккаунта Apple — страна, где Apple принимает платежи;
2. карта иностранного эмитента, желательно той же страны;
3. платежный адрес, совпадающий с этим регионом.

Одного или двух элементов недостаточно. Я проверял.

Что Apple требует перед сменой страны

Процедура штатная и описана в справке Apple — support.apple.com/en-us/118283. Перед сменой региона нужно:

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

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

Сама смена делается за минуту: «Настройки» → ваше имя → «Медиаматериалы и покупки» → «Просмотреть учетную запись» → «Страна или регион». Или в браузере на account.apple.com в разделе личных данных. И еще одна строчка из справки, которую стоит держать в голове: после обновления платежного адреса и способа оплаты тариф iCloud+ считается уже по ценам нового региона.

Сколько стоит iCloud+ и в каком регионе дешевле

Цены я брал не из обзоров, а с официальной страницы Apple — support.apple.com/en-us/108047, обновление от 16 сентября 2026 года. Там собраны цены по всем странам; ниже выписаны регионы, которые реально рассматривают россияне. Объем хранилища во всех странах одинаковый, различаются только валюта и сумма. Бесплатно Apple дает 5 ГБ.

Цены за месяц — 50 ГБ / 200 ГБ / 2 ТБ:

• Россия (рубли) — 59 ₽ / 149 ₽ / 599 ₽. Цены на странице Apple остались, но заплатить по ним нечем.
• США (доллары) — $0,99 / $2,99 / $9,99.
• Еврозона (евро) — 0,99 € / 2,99 € / 9,99 €.
• Турция (лиры) — 49,99 TL / 169,99 TL / 549,99 TL.
• Казахстан (тенге) — 499 ₸ / 1 490 ₸ / 4 990 ₸.
• Армения (доллары) — $1,19 / $3,49 / $11,99.
• Грузия (доллары) — $0,99 / $3,49 / $11,99.
• Великобритания (фунты) — £0,99 / £2,99 / £8,99.

Теперь то же самое в рублях по курсу ЦБ на 19 сентября 2026 года: доллар 84,1975 ₽, евро 96,6671 ₽, турецкая лира 1,73135 ₽, тенге 0,189387 ₽.

• США — 50 ГБ за 83 ₽ в месяц, 200 ГБ за 252 ₽ в месяц, или 3 021 ₽ в год.
• Казахстан — 50 ГБ за 94 ₽, 200 ГБ за 282 ₽, или 3 386 ₽ в год.
• Еврозона — 50 ГБ за 96 ₽, 200 ГБ за 289 ₽, или 3 468 ₽ в год.
• Турция — 50 ГБ за 87 ₽, 200 ГБ за 294 ₽, или 3 532 ₽ в год.

Здесь меня ждал главный сюрприз этой темы. Турцию до сих пор советуют как самый дешевый регион для Apple, и года два назад это было правдой. Летом 2026 Apple подняла турецкие цены, и теперь 200 ГБ в Турции стоят дороже, чем в США — 294 ₽ против 252 ₽ по курсу ЦБ. Разница за год выходит около 500 ₽. Не катастрофа, но совет «переезжайте в турецкий регион ради экономии» в 2026 году просто неверен, а повторяют его по инерции повсеместно.

Российские 149 ₽ за 200 ГБ были дешевле любого иностранного региона, и это придется принять: после переезда вы платите примерно вдвое больше за тот же объем. Плюс надбавку карты к курсу — обычно 5–19% в зависимости от сервиса и тарифа. Реальный месяц на 200 ГБ выходит в районе 265–300 ₽.

Что входит в iCloud+ кроме гигабайтов, одинаково на всех платных тарифах: «Частный узел», «Скрыть e-mail», свой домен для почты, Apple Invites и поддержка защищенного видео HomeKit. Разница только в числе камер — одна на 50 ГБ, до пяти на 200 ГБ, без ограничений на 2 ТБ. Любой платный тариф делится с пятью членами семьи.

И две вещи, на которых легко споткнуться. Годового варианта у iCloud+ нет вообще, только помесячно — значит, карту придется держать живой и с балансом двенадцать месяцев подряд. А подарочные карты Apple Store для повышения тарифа iCloud+ не принимаются: Apple пишет об этом прямо на странице с ценами. Принимаются кредитные и дебетовые карты и баланс аккаунта Apple, который пополняется картами App Store и iTunes. Это два разных продукта с похожими названиями, и путают их постоянно.

Шесть сервисов, где я выпускал карту

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

Одно общее предупреждение, которое сэкономит вам деньги: перед выпуском проверяйте, поддерживает ли конкретный тариф именно App Store и iCloud+. У некоторых сервисов тарифы различаются не только ценой, но и списком сервисов, которые карта вообще пропускает. Apple в такие ограничения попадает чаще, чем что-либо другое.

«Плати по всему миру» — биллинг-адрес виден сразу, и форма Apple заполняется без гаданий

«Плати по всему миру» — сервис с российским юрлицом: ООО «Капибара», ИНН 9703231520. Управление в мини-приложении Telegram, в MAX или в веб-кабинете. Для привязки к Apple это оказалось удобнее всего по одной конкретной причине: платежный адрес и полные реквизиты видны в кабинете сразу, а форма привязки у Apple проверяет именно адрес. Придумывать его нельзя, и искать по чатам, какой адрес подставить, — отдельное удовольствие, которого тут нет.

Что входит:

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

Тарифы:

• «Для подписок» — 2 990 ₽, срок действия 4 года, под регулярные списания;
• «Для путешествий» — 3 990 ₽, срок 2 года, под брони и оплату за границей;
• «Премиальная» — 14 990 ₽, срок 2 года, нулевая комиссия за операцию и лучший внутренний курс.

Автопополнение под iCloud+ — вещь недооцененная. Подписка списывается двенадцать раз в год маленькими суммами, и забыть перевести деньги на карту перед датой списания получится обязательно; тут баланс пополняется сам. Из наград на сайте подтверждены Finnext 2026 и TAdviser IT Prize 2026.

Из минусов. Со второго года включается абонентская плата, равная цене выпуска: у карты «Для подписок» это еще 2 990 ₽ ежегодно, и в стоимость владения это надо закладывать сразу. На младших тарифах удерживается $0,25 за каждую операцию, включая неуспешные попытки — а Apple при привязке карты делает проверочные списания, так что несколько центов уйдет еще до первой подписки. Внутренний курс выше курса ЦБ, на премиальном тарифе разрыв заметно меньше. И еще: валюта карты «Для подписок» на лендинге и в справочном центре описана по-разному — я бы уточнил это в поддержке до оплаты выпуска, потому что под европейский регион аккаунта и под американский нужны разные карты.

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

Сайт проекта: «Плати по всему миру»

Yello Card — ноль за обслуживание в любой год, но iCloud+ только на старшем тарифе

Yello Card — карты Mastercard с пополнением рублями по СБП. Для подписки, которая живет годами, тут важна одна строчка: платы за обслуживание нет ни в первый год, ни во второй. Выпуск платится один раз, дальше карта стоит только курс и комиссию за операции.

Что входит:

• два тарифа вместо разветвленной линейки, выбор занимает минуту;
• пополнение рублями по СБП, итоговая сумма видна до оплаты;
• поддержка регулярных списаний заявлена прямо, а не подразумевается названием тарифа;
• Apple Pay, Google Pay и Alipay на старшем тарифе;
• открытый каталог совместимости с конкретными сервисами.

Тарифы:

• Standard — 1 699 ₽;
• Ultima+ — 2 999 ₽, плюс мобильные кошельки и офлайн-оплата;
• обслуживание на обоих — 0 ₽ в месяц, срок действия карт — 2 года.

А теперь то, ради чего этот блок стоит дочитать. У сервиса на главной странице лежит открытый каталог, где напротив каждого сервиса стоит отметка — проходит карта или нет. И по этому каталогу на тарифе Standard App Store и iCloud+ не оплачиваются. Они доступны только на Ultima+. Там же, к слову, видно, что на Standard не проходят ChatGPT, Claude, Telegram Premium и Google Play, а Steam не проходит ни на одном тарифе. Проверить это можно за минуту, не регистрируясь, — я проверял прямо перед публикацией.

Вывод практический: под айклауд дешевый тариф брать бессмысленно, нужен Ultima+ за 2 999 ₽. И даже так на двухлетней дистанции он остается одним из самых дешевых вариантов в подборке — потому что второй год бесплатный.

Из минусов помимо этого: срок действия карты 2 года, то есть реквизиты у Apple придется обновлять чаще, чем у четырехлетних карт. Комиссия за операцию — от $0,40, самая высокая в подборке; на двенадцати списаниях iCloud+ в год это около 400 ₽ сверху, сопоставимо с половиной годовой стоимости тарифа на 50 ГБ. Юридическое лицо на витрине не раскрыто, и это минус на фоне сервисов, которые публикуют ИНН.

Кому подходит: тем, кто считает расходы на два-три года вперед и готов сразу брать Ultima+, а не экономить на выпуске.

Сайт проекта: Yello Card

Wayment — бонус 10 долларов и пять лет без обновления реквизитов

Wayment выпускает карты через телеграм-бота и начисляет 10 долларов на счет при открытии. Для iCloud+ это переводится в конкретную цифру: бонус закрывает больше трех месяцев тарифа на 200 ГБ в американском регионе или почти год тарифа на 50 ГБ. То есть привязку можно проверить до того, как переводить собственные деньги, — для меня это оказался самый спокойный способ тестировать. Бонус разовый, начисляется при выпуске.

Что входит:

• выпуск в телеграм-боте, без отдельного приложения;
• бонус 10 долларов новому пользователю;
• пополнение рублями по СБП без комиссии за зачисление;
• три страны эмитента в одной линейке;
• добавление карты в Apple Pay и Google Pay.

Тарифы:

• «Для подписок» — 2 990 ₽, эмитент Сингапур, срок действия 5 лет;
• «Для путешествий» — 3 990 ₽, эмитент Армения, срок 2,5 года;
• «Премиальная» — 7 990 ₽, эмитент США, срок 2,5 года.

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

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

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

Сайт проекта: Wayment

WantToPay — американский BIN, если аккаунт вы переводите в США

WantToPay выпускает долларовые карты с американским BIN. Если вы перевели аккаунт в США — а это самый очевидный вариант, потому что там цены ниже всего и каталог полный, — совпадение страны карты и региона аккаунта снимает часть отказов на привязке. Ко мне это относилось напрямую, и здесь у меня действительно не было проблем с добавлением карты.

Что входит:

• долларовые карты с американским BIN;
• удобное пополнение: СБП и несколько альтернативных способов на выбор;
• поддержка 3-D Secure;
• добавление в Apple Pay и Google Pay на старших тарифах;
• верификация через Sumsub — ту же платформу, что используют крупные международные сервисы.

Тарифы:

• Prepaid — от 790 ₽, предоплаченная карта, не пополняется;
• Easy — 990 ₽, пополняемая, лимит $4 000 в месяц;
• Smart — 1 590 ₽, плюс мобильные кошельки;
• Pro — 3 490 ₽, лимит до $50 000 в месяц.

Тариф тут подбирается под оборот, и это честно устроено. Но для iCloud+ есть пункт, из-за которого я в итоге взял карту в другом месте: на пополняемых тарифах действует ежемесячная плата около 6 долларов после первого бесплатного месяца. Это примерно 6 000 ₽ в год — дороже, чем сама подписка на 200 ГБ, ради которой все затевалось. Я узнал об этом не из тарифа, а когда карта внезапно перестала работать в середине месяца.

Из остальных минусов: Prepaid под автопродление не годится в принципе — пополнить его нельзя, и на втором списании подписка отключится; вывод средств сервис не поддерживает; на старших тарифах верификация обязательна; а юрисдикция в разных источниках указана по-разному — где-то WTP Technology Limited из Гонконга, где-то киргизская регистрация. Расхождение я бы уточнил в поддержке до оплаты выпуска.

Кому подходит: тем, кто переводит аккаунт именно в США и готов считать карту отдельной ежемесячной статьей расходов.

Сайт проекта: WantToPay

Card.club — карта в евро и отдельный дешевый тариф под магазины приложений

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

Что входит:

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

Тарифы:

• Тариф под магазины приложений и игровые площадки — от $2,5 за выпуск;
• Долларовая карта — под подписки и зарубежные сервисы;
• Карта в евро — под платежи европейским поставщикам без двойной конвертации.

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

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

Из минусов, и для iCloud+ они существенные. Комиссия за пополнение 4% при минимуме $25 — то есть реальная сумма при выпуске выходит заметно выше витринной, и пополнять приходится редко и крупно, а не под каждое списание. На игровом тарифе комиссия берется и за отклоненную транзакцию, а отмена платежа тарифицируется отдельно — с учетом проверочных списаний Apple это не мелочь. И у сервиса есть черный список мерчантов, в котором claude.ai, Adobe, Starlink и Twilio: для айклауда не блокер, но универсальной картой на все подписки эта карта не станет. Юрлицо на витрине не раскрыто.

Кому подходит: тем, у кого европейский регион аккаунта, и тем, кто хочет отдельную дешевую карту только под Apple.

Сайт проекта: Card.club

EasyPayments — настоящий счет в банке, а не баланс в приложении

EasyPayments — это не финтех-обертка, а посредник по удаленному открытию счета в банке Киргизии или Армении. Работает от российского юрлица ООО «АЙТИ ВОРЛД» из Перми. Разница принципиальная: тут выпускается именная банковская карта на ваше имя, с физическим пластиком и доставкой, а ее BIN принадлежит банку, а не массовому финтех-спонсору.

Что входит:

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

Тарифы:

• Киргизия — от 19 990 ₽;
• Киргизия — от 25 990 ₽;
• Киргизия — от 27 990 ₽;
• Армения — от 39 990 ₽.

Условия по Казахстану и Турции публично не опубликованы. IBAN на сайте не заявлен — рассчитывать стоит только на SWIFT. Карта живет до пяти лет и перевыпускается банком, есть рассрочка от 1 250 ₽ в месяц, обслуживание от 20 долларов в год.

Зачем это под подписку за 252 ₽ в месяц? Ради одного свойства: банковский BIN в стоп-листы мерчантов практически не попадает. Финтех-карта может перестать проходить у конкретного поставщика через полгода без объяснений — с банковской такого почти не случается.

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

Кому подходит: тем, кому карта нужна не под одну подписку, а под весь набор зарубежных расходов сразу.

Сайт проекта: EasyPayments

Какую карту брать именно под iCloud

У iCloud+ три особенности, которые меняют выбор по сравнению с разовой покупкой. Списание ежемесячное, годового тарифа нет. Суммы маленькие — 0,99, 2,99 или 9,99 в валюте региона. И подписка должна прожить годы, а не один платеж.

Отсюда практические выводы:

• Комиссия за операцию важнее цены выпуска. Двенадцать списаний в год по $0,40 — это $4,8, то есть почти половина годовой стоимости тарифа на 50 ГБ. По $0,25 — $3. На премиальном тарифе — ноль. Считайте эту строчку первой, а не последней.
• Абонентская плата со второго года решает все на длинной дистанции. «Первый год бесплатно» читается как «дальше тоже», и это ошибка, которая обнаруживается через двенадцать месяцев. У одних сервисов со второго года списывается сумма, равная цене выпуска. У других платы нет вообще.
• Валюта карты должна совпадать с валютой региона. Евро-карта под европейский аккаунт, доллар — под США или Армению. Иначе на каждом из двенадцати списаний набегает лишняя конвертация.
• Срок действия карты должен перекрывать горизонт планирования. Карта на два года — это перепривязка через два года, и пропустить этот момент легко: письмо от Apple приходит на почту аккаунта и теряется среди рассылок.
• Проверьте совместимость до оплаты выпуска. У части сервисов есть открытые каталоги с отметками, проходит ли карта в App Store и iCloud+. Пять минут чтения дешевле, чем впустую потраченные две-три тысячи рублей.

И общий вывод, который я вывел дорогой ценой: считайте не цену выпуска, а стоимость владения за два года. Карта за 990 ₽ с ежемесячной платой в шесть долларов за два года обойдется примерно на десять тысяч дороже карты за 2 999 ₽ без абонентки. Витрина этого не показывает.

Пошагово: от заполненного хранилища до работающей подписки

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

1. Сначала выгрузите то, что боитесь потерять. Пока данные доступны, скачайте фото и видео через iCloud.com или на компьютер. Если со сменой региона что-то пойдет не так, этот шаг спасет.
2. Решите, в какой регион переводите аккаунт. По ценам на 200 ГБ сейчас выигрывают США. Турция свое преимущество потеряла. Смотрите не только на цену: от региона зависит и каталог доступных приложений.
3. Выпустите карту нужной валюты и страны. Именно в этом порядке: сначала решение по стране аккаунта, потом карта. У финтех-сервисов выпуск занимает 10–15 минут, у банковской карты через посредника — от одного до пятнадцати рабочих дней.
4. Найдите в кабинете сервиса платежный адрес. Не придумывайте его: он сверяется на стороне Apple. Обычно лежит в деталях карты, рядом с номером и CVV.
5. Обнулите баланс аккаунта и отмените мешающие подписки. Это требование Apple, без него смена страны не пройдет. Из семейной группы, если вы в ней, придется выйти.
6. Смените страну и привяжите карту. «Настройки» → имя → «Медиаматериалы и покупки» → «Страна или регион». На шаге способа оплаты вводите реквизиты и адрес ровно как в кабинете сервиса, до запятой.
7. Оформите iCloud+ заново и дождитесь второго списания. Не подписывайтесь сразу на 2 ТБ — возьмите 50 ГБ за доллар. Первый платеж проходит почти всегда, честная проверка — через месяц, на автопродлении.

Держите на балансе запас процентов в пятнадцать сверх суммы подписки. Курс, комиссия за операцию и проверочные списания Apple вместе съедают больше, чем ожидаешь, а списание на 252 ₽, не прошедшее из-за нехватки двадцати рублей, выключает подписку так же надежно, как пустой счет.

Где я ошибался

Пробовал платить через «Озон Банк» и счет МТС. Ни один из этих маршрутов не работает и не заработает. Запросы вроде «оплатить айклауд через озон банк» до сих пор находят подробные инструкции — просто написаны они до апреля. Смотрите дату публикации, прежде чем повторять.

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

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

Не проверил каталог совместимости. У одного из сервисов младший тариф вообще не проводит платежи в App Store и iCloud+, и об этом написано в открытом доступе на главной странице. Я туда не заглянул и узнал уже после оплаты.

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

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

Частые вопросы

Можно ли оплатить iCloud в России в 2026 году?

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

Что будет с фотографиями, если подписку не продлить?

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

Как оплатить айклауд через Сбербанк?

Никак. Карты российских банков не принимаются с 2022 года, и Сбербанк тут не исключение — отказ приходит на стороне платежного провайдера Apple, а не банка. То же самое с «Озон Банком», Т-Банком и любым другим российским банком.

Можно ли оплатить iCloud с баланса Apple ID?

Да, если на балансе есть деньги — это единственное, что Apple оставила работающим в российском регионе. Проблема в том, что пополнить баланс в России больше нельзя. Если что-то осталось с прошлого года, оно потратится, и на этом все.

Можно ли оплатить iCloud без смены региона?

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

Какой картой можно оплатить айклауд на айфоне?

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

Сколько стоит iCloud+ на 200 ГБ в рублях?

В американском регионе $2,99 в месяц — 252 ₽ по курсу ЦБ на 19 сентября 2026 года. Плюс надбавка карты к курсу, обычно 5–19%, плюс комиссия за операцию, если она есть. Реальный месяц выходит в районе 265–300 ₽.

Как продлить подписку iCloud на айфоне?

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

Можно ли оплатить iCloud подарочной картой?

Баланс аккаунта, пополненный кодом App Store, для этого годится. А вот подарочные карты Apple Store для повышения тарифа iCloud+ не принимаются — Apple пишет об этом на странице с ценами. Два похожих продукта с разным назначением.

Как часто можно менять страну аккаунта?

В справке Apple ограничения по частоте нет. Требования другие: обнулить баланс, отменить мешающие подписки, дождаться завершения незакрытых операций и иметь действующий способ оплаты для новой страны. Правило «раз в 90 дней», которое часто приводят, относится к Google Play, а не к Apple.

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

Карта выпущена, а привязка не проходит. Что делать? Проверьте четыре вещи по порядку. Совпадает ли регион аккаунта со страной выпуска карты. Точно ли платежный адрес введен так, как записан в кабинете сервиса. Хватает ли денег с запасом на курс, комиссию и проверочное списание. И не входит ли Apple в ограничения вашего тарифа. Первые три лечатся за пять минут, четвертое — только картой другого сервиса.

Итог

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

Как я бы разложил выбор сейчас:

• Одна подписка iCloud+ и больше ничего — карта без абонентской платы и с низкой комиссией за операцию. Цена выпуска тут вторична: на двухлетней дистанции она объясняет меньше половины расходов.
• Европейский регион аккаунта — карта в евро, чтобы не терять на второй конвертации в каждом из двенадцати списаний.
• Американский регион — долларовая карта, желательно с американским BIN, но заранее посмотрите, нет ли у сервиса обязательной ежемесячной платы.
• Хочу привязать один раз и забыть на годы — карта с максимальным сроком действия.
• Карта нужна не только под Apple, но и под поездки и снятие наличных — тогда это уже не виртуалка, а счет в банке страны СНГ, со всей сопутствующей отчетностью.

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

Цены и условия актуальны на сентябрь 2026 года. Перед оформлением проверяйте актуальные тарифы на официальных сайтах сервисов — политика Apple и финтех-условия могут меняться.

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

Почему нейросеть не пишет как в вузах?

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

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

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

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

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

Промпты, которые заставят нейросеть оформить по методичке

Мы собрали три промпта, которые помогут разобраться в требованиях методички и организовать работу над текстом. Для работы советуем использовать AI-chat от Автор24 — ИИ для помощи в создании курсовых работ, дипломов и рефератов. За все время работы со студентами он видел сотни методичек.

Промпт 1. Собрать требования в один список

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

Ты — методист кафедры. Во вложении методичка по курсовой работе.

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

Ответ оформи так:
1. Цифры: объем работы, объем каждого раздела, количество разделов,количество источников, процент оригинальности.
2. Структура: какие разделы обязательны и в каком порядке.
3. Введение: что в нем должно быть, каждый элемент отдельной строкой.

Каждый пункт пиши одной строкой, без пояснений.

Ничего не додумывай, бери только то, что есть в методичке. Чего в методичке нет, вынеси в конец под заголовком «Уточнить у научрука».

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

Промпт 2. План под вашу тему

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

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

Моя работа:

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

В плане пропиши:

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

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

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

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

Промпт 3. Черновик подраздела

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

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

Требования к тексту:

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

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

Если для утверждения нужны цифры или ссылка на исследование, не выдумывай их, а оставь пометку [НУЖЕН ИСТОЧНИК].

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

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

Что остается на студенте

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

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

Фактчекинг. Каждая пометка [НУЖЕН ИСТОЧНИК] обозначает место, куда нужно подставить настоящую цифру. Все остальное, что похоже на факт, тоже стоит перепроверить.

Источники. Искать их придется самому на eLibrary, КиберЛенинке и в библиотеке вуза. Ссылки, которые нейросеть придумывает сама, выглядят настоящими ровно до момента, когда научрук решит их чекнуть.

Оформление. Шрифт, поля, нумерация и подписи к таблицам выставляются в Word руками.

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

Реклама. Рекламодатель: ООО «ПМТ» ИНН 7813667410, erid: 2W5zFJoegdP

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

ХоумВорк — профессиональная помощь с дипломами и курсовыми

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

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

Где экономит время

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

Предметы и форматы

Направление может быть любым: клиент любой специальности прикладывает файлы и формулирует тему, а сервис оценивает задачу и подбирает автора — так же работает и с дипломом, и с курсовой, и с отдельной задачей. Материалы принимаются во всех перечисленных форматах: PDF, DOCX, PPTX, аудиозаписи лекций и изображения конспектов.

Сколько стоит

Стоимость зависит от типа работы: дипломная — от 11 900 ₽; курсовая — от 2 300 ₽; отчёт по практике — от 2 200 ₽; реферат — от 600 ₽. Бесплатного тарифа или пробного периода нет. Сервис также работает и с юрлицами.

Ограничения и кому подойдёт

Сценарии, где сервис подходит:

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

Формат не подойдёт тем, кто хочет разобраться в теме самостоятельно или получить мгновенный ответ от AI-инструмента: весь процесс здесь идёт через менеджера и куратора, а не через самостоятельную работу в сервисе. Связаться с ХоумВорк можно через Telegram и чат внутри сервиса.

Перейти на ХоумВорк

Открытое образование — университетские курсы для самостоятельной учёбы

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

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

Где экономит время

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

Предметы и форматы

В курсе СПбПУ «Высшая математика. 1 семестр» разбирают линейную и векторную алгебру, аналитическую геометрию и основы математического анализа. Занятия состоят из видеолекций с примерами и тестов по темам. У УрФУ есть «Технологии программирования» с материалами по C#, структурам данных и алгоритмам: к видео добавлены текстовые объяснения и практические задания.

Сколько стоит

Условия оплаты зависят от курса. Например, для «Высшей математики. 1 семестр» СПбПУ стоимость аттестации с подтверждением личности составляет 3 600 ₽. Это цена процедуры оценки для получения сертификата. В отдельных курсах платным бывает и полный доступ к материалам: в «Технологиях программирования» УрФУ бесплатно доступна первая неделя.

Ограничения и кому подойдёт

Сценарии, где сервис подходит:

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

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

Перейти на Открытое образование

CodeRun — практика программирования перед стажировкой

CodeRun — тренажёр Яндекса, в котором можно решать задачи по программированию и отправлять код на автоматическую проверку. Для отправки решений нужен Яндекс ID. На платформе также можно читать разборы других участников и публиковать собственные объяснения.

Где экономит время

Задачи уже собраны в подборки под конкретные цели. Для знакомства с платформой есть «Быстрый старт», для подготовки к отбору — «Стажировка // Бэкенд» и «Стажировка // Фронтенд». Можно сразу выбрать подходящий набор и тренироваться на нём, получая результат автоматической проверки после отправки решения.

Предметы и форматы

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

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

Сколько стоит

Решать задачи на платформе можно бесплатно. Яндекс описывает CodeRun как бесплатный сервис для разработчиков и аналитиков.

Ограничения и кому подойдёт

Сценарии, где сервис подходит:

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

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

Перейти на CodeRun

GitVerse — учебные проекты и совместная работа над кодом

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

Где экономит время

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

Предметы и форматы

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

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

Сколько стоит

Тариф GitVerse Free бесплатный. В него входят неограниченное количество публичных и приватных репозиториев, задачи, вики и проверка кода. Для крупных файлов через Git LFS выделено 5 ГБ, для пакетов, артефактов CI/CD и релизов — ещё 1 ГБ. GitVerse Pro стоит 399 ₽ за пользователя в месяц при оплате за год и увеличивает доступные лимиты.

Ограничения и кому подойдёт

Сценарии, где сервис подходит:

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

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

Перейти на GitVerse

Факультетус — поиск практики, стажировки и первой работы

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

Где экономит время

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

Предметы и форматы

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

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

Сколько стоит

Функционал для студентов и выпускников предоставляется бесплатно.

Сервис подходит:

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

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

Перейти на Факультетус

Итого: что выбрать

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

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

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

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

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

История 1. Осьминог на кредитном комитете: как мы искали продуктовые идеи с помощью МФО

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

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

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

Но если вам уже надоело просто «допиливать» существующие продукты и хочется выбить команду из шаблонного мышления, попробуйте не обычный брейншторм, а метод фокальных объектов (МФО). Это метод генерации новых идей через перенос свойств случайных объектов на объект, который требуется усовершенствовать.

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

Метод состоит из нескольких последовательных действий:

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

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

Давайте покажу на примере.

Сформулировать кейс

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

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

Это уже достаточно конкретная задача и задаёт направление поиска.

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

1. Выручка зависит от сезонности.
2. Закупки сырья нужно финансировать заранее.
3. Отгрузки клиентам происходят с отсрочкой платежа.
4. Часть оборотного капитала заморожена в запасах.
5. Потребность в деньгах меняется в течение года
6. Финансовый директор не всегда понимает, какой объём лимита будет доступен через месяц.
7. Важно своевременно информировать банк об изменениях в бизнесе и не допускать ухудшения качества портфеля.

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

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

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

Как проходила сессия

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

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

На первом этапе мы не связываем объект с кредитованием. Просто описываем, как он устроен и как себя ведёт:

• У него несколько щупалец.
• Щупальца могут действовать параллельно.
• Часть нервной системы распределена по телу.
• Он быстро адаптируется к среде.
• Меняет цвет и фактуру.
• Исследует пространство через прикосновение.
• Умеет прятаться
• При угрозе выпускает чернила и меняет сценарий поведения.

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

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

Теперь начинаем переносить признаки на фокальный объект

На оборотное финансирование в нашем случае. У корпоративного клиента редко бывает только одна потребность в ликвидности. Одновременно ему могут требоваться деньги на:

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

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

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

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

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

Примечание. Все свойства рассматривать нет смысла, остановимся на одном.

Как из ассоциации получить проверяемую гипотезу

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

• Какое свойство мы перенесли?
• Как оно могло бы проявляться в продукте?
• Для какого клиента это имеет ценность?
• Какую проблему клиента решает?
• Какие данные или события запускают новый сценарий?
• Что меняется в процессе?
• Какие риски появляются?
• Как проверить идею на небольшом пилоте?

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

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

Так случайная ассоциация превращается в объект продуктовой проверки.

Как провести такую сессию у себя

До встречи нужно подготовить:

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

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

Этап генерации (45–60 минут):

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

Фасилитатору важно останавливать фразы вроде «Это невозможно» и «Так никто не делает». Вместо этого можно спросить:

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

Этап отбора. После завершения генерации команда возвращается к конвергентному мышлению. Идеи можно оценить по пяти критериям (клиентская ценность, экономика, риск, право/комплаенс, реализуемость).

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

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

Важно. Не любая странная ассоциация превращается в хорошую бизнес‑идею. Здесь дело в другом: МФО временно снимает ограничения с этапа генерации, чтобы команда получила более широкий набор вариантов, затем ограничения возвращаются в работу, а идея проверяется на клиентскую ценность, экономику, риск, право, данные, ИТ и операционную модель.

Ограничения метода

У метода есть несколько ограничений.

• Во‑первых, МФО плохо работает, если кейс сформулирован слишком широко. «Как улучшить корпоративное кредитование?» — плохая постановка. «Как сократить неопределённость клиента при использовании возобновляемого лимита?» — значительно лучше.
• Во‑вторых, случайные объекты должны действительно быть случайными. Если команда заранее выбирает только «полезные» или технологичные предметы, метод быстро превращается в обычную аналогию.
• В‑третьих, нельзя смешивать генерацию и оценку. Если специалист по рискам начинает комментировать каждую идею в момент её появления, команда снова возвращается в конвергентный режим.
• В‑четвёртых, итогом должны быть не просто необычные сочетания, а проверяемые гипотезы. Иначе сессия останется хорошим упражнением на воображение.

Метод фокальных объектов — это не замена рискам и аналитике, а способ отключить внутренний стоп-кран ещё до того, как идея родится. В корпоративном кредитовании мы привыкли сразу искать ограничения, из-за чего часто просто «допиливаем» существующие продукты. Необычные метафоры вроде “осьминога” помогают выскочить из этой колеи и задать неудобные вопросы: “а что, если делать лимиты гибкими”, “ловить сигналы бизнеса раньше отчётности” и уйти от крайностей «всё доступно или всё заблокировано»? Смысл МФО в том, чтобы сначала выбить команду из шаблонного мышления и веером нагенерировать смелых решений, и только потом прогнать их через суровый фильтр корпоративной реальности.

Бонус‑кейсы с воркшопов: идеи, которые «созревали» вместе с рынком

Снятие налички на кассе магазинов

В своё время, на подобных воркшопах ещё в 2018 году, мы нагенерировали мысль, что можно было бы снимать деньги с карты на кассах магазинов. Тогда эта идея в прод не пошла, но уже в 2026‑м это рабочий способ получить наличку. Но некоторые идеи «созревают» вместе с рынком и инфраструктурой. Задача продакта — не убивать их сразу, а фиксировать и возвращаться, когда контекст изменится.

Досрочное погашение и онбординг в проблемных точках

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

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

История 2. Как сделать CJM, когда оно стоит как крыло от самолёта

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

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

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

В нашем случае сервис участвует в нескольких этапах жизненного цикла корпоративного кредита:

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

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

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

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

Но наша аудитория — крупный корпоративный бизнес. В реальности это квест уровня «хард»: надо попробовать найти ЛПР какой‑нибудь авиакомпании, пробить стену службы безопасности, а потом, обойдя переносы и отмены, добраться до кабинета с табличкой «Оставь надежду, всяк сюда входящий». И вот твоё исследование умерло, так и не начавшись (но не попало в ад, потому что оно уже там).

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

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

Ответ: бюджетно.

Однажды я подготовила фрейм в Miro, где накидала сценарии, которые пользователи могут проходить в процессе корпоративного кредитования, внезапно и без объявления собрала 20 человек из команд разработки (свою и смежную) — разработчиков, аналитиков, дизайнеров, — и разбила на группы, раздала этапы и отдала на разграбление два swimlane:

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

Этапы кредитного процесса у юрлиц разбиваются на крупные блоки:

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

Каждой группе досталась часть этого этапа. Задача групп: заполнить этап по шаблону (триггер, цель, действия, инструменты, touchpoints).

И тут начался самый кайф. К примеру, одна группа представила:

«Я — казначей, в календаре стоит встреча, чтобы обсуждать инвестиционный проект, и мне, как казначею, нужно примерно понять, сколько средств компания может выбрать в текущий момент и сколько будет стоить финансирование по условиям договора; успеет ли компания получить деньги к дате платежа поставщику?»

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

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

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

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

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

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

Главный эффект воркшопа

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

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

Два часа воркшопа, на котором я «заставила» команду разработки представить себя на месте клиента — и у нас родилось десяток гипотез. Да, это пока не доказанные факты, а наши коллективные галлюцинации. Но теперь с этим объёмным, живым «монстриком» можно идти валидироваться об реальную ЦА, аналитику и саппорт.

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

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

Ограничения внутреннего воркшопа

Воркшоп нельзя рассматривать как замену реального интервью с клиентом, потому что это некорректно. У внутреннего воркшопа есть серьёзные ограничения:

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

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

Но до воркшопа на грумингах звучало «Давайте выведем на экран ещё один финансовый показатель», команда проектировала UI/UX из позиции «Смотрите, сколько у нас данных и что мы умеем», а за спиной тихо строилась фабрика фичей.

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

Сейчас у нас вопросы другие: «Какую задачу этот показатель решает? Для какой роли? На каком этапе? Что человек сделает с ним дальше?»

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

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

История 3. Как метрика Time to Interactive помогла победить «призрачный» негатив клиентов

Любой крупный финтех — это баланс между идеальной архитектурой и скоростью Time‑to‑Market. Когда‑то давно для запуска сервиса был сделан базовый заявочный процесс:

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

Главный нюанс: единой мастер‑системы со сквозной статусной моделью у процесса не было.

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

Последствиями были пачки негативных отзывов от пользователей, которые приносила поддержка, с одной и той же формулировкой — «Ничего не работает!». Если открыть логи, то видно, что заявки уходят, четыре банковские системы по цепочке успешно их обрабатывают, а операции исполняются. По договору у банка есть 2 дня на обработку (SLA), и система железобетонно укладывается в этот срок. Backend‑инженеры рапортуют, что всё штатно.

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

Как мы сместили фокус с серверных метрик на пользовательский опыт

Мы решили это проверить и сместили фокус с серверных метрик на пользовательский опыт и измерили Time to Interactive (TTI) — но не в классическом смысле общей готовности страницы, а точечно: разницу между моментом отрисовки страницы и моментом отрисовки нужного нам элемента — главной целевой кнопки. То есть не «когда страница в целом стала интерактивной», а конкретно «когда стала кликабельна кнопка, которая ведёт клиента дальше по сценарию».

Результаты замеров — это шок‑контент. Уберите от экранов детей, стажёров и джунов: средний TTI кнопки составлял 18 секунд.

Один час на планете Миллер равен семи годам на Земле. А 18 секунд ожидания кнопки в финтехе — это вечность для нервной системы клиента. За это время человек успевает сделать три глотка кофе, подумать, что страница «зависла» или сайт «сломался», яростно покликать по неактивной кнопке, закрыть вкладку и уйти писать разгневанный отзыв.

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

Что мы нашли в цепочке инициализации

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

Пока этот тяжёлый расчёт не завершался, фронтенд не активировал ключевое действие.

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

Выводы

Не верьте только бэкенд‑логам. Если по метрикам сервера всё «зелёное», это не значит, что пользователь счастлив. Негатив может формироваться на этапе ожидания UI.

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

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

Заключение: что остаётся после таких историй

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

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

Если после этой статьи вы хотя бы раз спросите...:

• «А какую проблему это решает?»
• «Для какой роли?»
• «На каком этапе?»
• «Что человек сделает с этим дальше?» —

…значит, эти истории уже сработали.

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

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

«Пополнить Alipay» — это два разных запроса

С этого надо начать, иначе дальше все будет путаться.

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

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

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

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

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

Почему российская карта не привязывается к Alipay

Причина не в Alipay и не в настройках телефона.

Карту отклоняет не приложение, а платежная инфраструктура. Alipay принимает карты международных систем — Visa, Mastercard, American Express, JCB, Discover, Diners Club. Карты «Мир» в этом списке нет и не было: система китайской платформой не поддерживается, и отказ приходит на этапе привязки.

Visa и Mastercard российского выпуска формально «международные», но после отключения российских банков от международного клиринга в 2022 году они за пределами страны не обслуживаются. BIN — первые шесть-восемь цифр номера карты — указывает на российский банк-эмитент, и транзакция не проходит. Сбербанк, ВТБ, Т-Банк, Альфа-Банк, Россельхозбанк тут в абсолютно одинаковом положении: отказ одинаковый, и от банка он не зависит.

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

Комиссии и лимиты: что нужно знать до поездки

Тут много мифов, поэтому разберу по пунктам.

Правило 200 юаней. Комиссия Alipay за платеж привязанной иностранной картой считается так: платеж до 200 юаней включительно — без комиссии сервиса; платеж свыше 200 юаней — 3% от всей суммы, а не от превышения. Это официальное правило, оно описано и в материалах китайских госорганов для иностранных гостей, и в справке самого Alipay.

Считаем на цифрах. По курсу ЦБ на 19 сентября 2026 года юань стоит 12,567 ₽, то есть 200 юаней — это около 2 513 ₽. Счет на 300 юаней (примерно 3 770 ₽) обойдется в 9 юаней комиссии, около 113 ₽. Счет на 190 юаней — бесплатно.

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

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

Международные карты UnionPay от этой комиссии освобождены. Если у вас есть карта UnionPay иностранного банка, 3% не берутся вообще. Это заметная экономия при крупных тратах.

Лимиты. Народный банк Китая еще в марте 2024 года поручил платежным платформам, включая Alipay, поднять лимиты для иностранцев: разовый платеж — с 1 000 до 5 000 долларов, годовой оборот — с 10 000 до 50 000 долларов. Это официальная позиция, опубликованная в том числе на портале Госсовета КНР. В рублях по текущему курсу разовый лимит — около 421 тысячи, годовой — порядка 4,2 миллиона. Для туристической поездки это потолок, которого вы не заметите.

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

Комиссия вашего банка. Alipay конвертацию не наценивает — курс определяет платежная система и банк-эмитент. А вот сам эмитент может добавить свою надбавку к курсу, и у финтех-карт она обычно составляет 5–19% в зависимости от сервиса и тарифа. Это, как правило, больше, чем комиссия самого Alipay, и смотреть надо именно на нее.

Возвраты. Если платеж вернули, комиссия 3% возвращается пропорционально сумме возврата.

Шесть сервисов, где я выпускал карту

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

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

«Плати по всему миру» — карта, которую успеваешь подготовить накануне вылета

«Плати по всему миру» — сервис с российским юрлицом: ООО «Капибара», ИНН 9703231520. Для поездки тут важна скорость: карта выпускается в день обращения, а не за неделю, и реквизиты появляются в мини-приложении сразу. Если вы вспомнили про оплату за вечер до вылета — этот сценарий закрывается.

Что входит:

• выпуск в день обращения, для регистрации нужен номер телефона;
• платежный адрес и полные реквизиты сразу в кабинете;
• пополнение рублями по СБП — работает и из поездки, если есть интернет;
• подтверждение 3-D Secure в мини-приложении, а не эсэмэской;
• справочный центр со сценариями привязки к конкретным сервисам.

Тарифы:

• «Для подписок» — 2 990 ₽, срок действия 4 года;
• «Для путешествий» — 3 990 ₽, срок 2 года;
• «Премиальная» — 14 990 ₽, срок 2 года, нулевая комиссия за операцию.

Две вещи, которые в поездке оказываются важнее, чем кажутся дома. Первая — пополнение по СБП прямо из Китая: если юани на карте кончились посреди дня, вы доливаете их с российского счета за минуту, не ища обменник. Вторая — 3-D Secure подтверждается в мини-приложении: роуминговая эсэмэска может не дойти, а подтверждение в приложении доходит по любому интернету. Из наград на сайте подтверждены Finnext 2026 и TAdviser IT Prize 2026.

Из минусов. Со второго года включается абонентская плата, равная цене выпуска — у карты «Для подписок» это 2 990 ₽ ежегодно, и если карта нужна на одну поездку, это надо учитывать. На младших тарифах удерживается $0,25 за операцию, включая неуспешные попытки: при оплате мелких счетов в Китае, где транзакций за день десяток, фиксированная комиссия набегает быстрее курсовой. Внутренний курс выше курса ЦБ, на премиальном тарифе разрыв меньше. И валюта карты «Для подписок» на лендинге и в справочном центре описана по-разному — под Китай я бы уточнил этот момент в поддержке до оплаты выпуска.

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

Сайт проекта: «Плати по всему миру»

Yello Card — Ultima+ добавляется прямо в Alipay, но только Ultima+

Yello Card — карты Mastercard с пополнением рублями по СБП. Для китайского сценария у сервиса есть конкретная особенность, которую он заявляет прямо: старший тариф добавляется не только в Apple Pay и Google Pay, но и в Alipay. Плюс обслуживание стоит 0 ₽ в месяц и в первый год, и во второй.

Что входит:

• два тарифа вместо разветвленной линейки;
• пополнение рублями по СБП, итоговая сумма видна до оплаты;
• добавление в Apple Pay, Google Pay и Alipay на старшем тарифе;
• поддержка регулярных списаний заявлена прямо;
• открытый каталог совместимости с конкретными сервисами.

Тарифы:

• Standard — 1 699 ₽;
• Ultima+ — 2 999 ₽, плюс мобильные кошельки и офлайн-оплата;
• обслуживание на обоих — 0 ₽ в месяц, срок действия карт — 2 года.

И сразу важное, потому что на этом легко промахнуться. В открытом каталоге на главной странице сервиса напротив Alipay стоит отметка: на тарифе Standard не оплачивается, на Ultima+ оплачивается. Проверяется это за минуту, без регистрации, — я смотрел каталог прямо перед публикацией. Под Китай младший тариф брать бессмысленно, нужен Ultima+ за 2 999 ₽.

Из минусов помимо этого: срок действия карты 2 года; комиссия за операцию от $0,40 — самая высокая в подборке, а в Китае транзакций много и они мелкие, так что фиксированная комиссия здесь бьет ощутимее, чем при оплате подписок; юридическое лицо на витрине не раскрыто.

Кому подходит: тем, кто хочет добавить карту в сам кошелек Alipay и не платить за обслуживание во второй год.

Сайт проекта: Yello Card

Wayment — три юрисдикции на случай, если BIN не прошел

Wayment выпускает карты через телеграм-бота и дает 10 долларов на счет при открытии — примерно 80 юаней, то есть пара обедов или несколько поездок на такси. Полезно не как экономия, а как способ проверить, что карта вообще привязывается к Alipay, до того как заводить свои деньги.

Что входит:

• выпуск в телеграм-боте, без отдельного приложения;
• бонус 10 долларов новому пользователю;
• пополнение рублями по СБП без комиссии за зачисление;
• три страны эмитента в одной линейке;
• добавление карты в Apple Pay и Google Pay.

Тарифы:

• «Для подписок» — 2 990 ₽, эмитент Сингапур, срок действия 5 лет;
• «Для путешествий» — 3 990 ₽, эмитент Армения, срок 2,5 года;
• «Премиальная» — 7 990 ₽, эмитент США, срок 2,5 года.

Три юрисдикции — здесь это не маркетинг, а страховка. Привязка карты к Alipay иногда не проходит по причинам, которые вам никто не объяснит: не тот эмитент, не тот банк, сработал антифрод. Возможность взять карту другой страны без новой регистрации в такой ситуации стоит дороже, чем кажется. Отдельное ограничение, о котором сервис пишет сам: ChatGPT и Claude оплачиваются только картой «Для подписок».

Частая путаница, которую снимем сразу: цифра 14 990 ₽ относится к премиальному тарифу другого сервиса, у Wayment верхний тариф стоит 7 990 ₽. Из минусов: первый год обслуживания бесплатный, а стоимость второго на витрине не раскрыта — уточняйте до выпуска. Пятилетний срок только у одного тарифа. Юрлицо гонконгское, российского ИНН нет. И сервис относительно новый: агрессивные условия на старте — хорошо, но репутация конкурентов обычно значит больше, чем бонус.

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

Сайт проекта: Wayment

WantToPay — американский BIN и высокие лимиты под закупки

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

Что входит:

• долларовые карты с американским BIN;
• удобное пополнение: СБП и несколько альтернативных способов на выбор;
• поддержка 3-D Secure;
• добавление в Apple Pay и Google Pay на старших тарифах;
• верификация через Sumsub — ту же платформу, что используют крупные международные сервисы.

Тарифы:

• Prepaid — от 790 ₽, предоплаченная карта, не пополняется;
• Easy — 990 ₽, пополняемая, лимит $4 000 в месяц;
• Smart — 1 590 ₽, плюс мобильные кошельки;
• Pro — 3 490 ₽, лимит до $50 000 в месяц.

Лимит Pro в 50 000 долларов в месяц — единственный в подборке, который дотягивается до платформенного потолка Alipay. Если у вас не туристическая поездка, а регулярные закупки, это осмысленный выбор.

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

Из остальных минусов: вывод средств не поддерживается; на старших тарифах верификация обязательна; юрисдикция в разных источниках указана по-разному — где-то WTP Technology Limited из Гонконга, где-то киргизская регистрация. Расхождение стоит уточнить в поддержке до оплаты.

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

Сайт проекта: WantToPay

Card.club — самая низкая цена входа, если карта нужна на одну поездку

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

Что входит:

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

Тарифы:

• Тариф под магазины приложений и игровые площадки — от $2,5 за выпуск;
• Долларовая карта — под подписки и зарубежные сервисы;
• Карта в евро — под европейских поставщиков.

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

Из минусов, и для Китая они существенные. Комиссия за пополнение 4% при минимуме $25 — то есть реальная сумма при выпуске выходит заметно выше витринной, и это самая частая претензия в отзывах. Пополнять приходится редко и крупно, а в поездке удобнее наоборот. На игровом тарифе комиссия берется и за отклоненную транзакцию — при привязке к Alipay отказы бывают, и каждый из них будет стоить денег. Есть черный список мерчантов, в котором claude.ai, Adobe, Starlink и Twilio: к Китаю отношения не имеет, но универсальной картой на все эта карта не станет. Юрлицо на витрине не раскрыто.

Кому подходит: тем, кто едет один раз и не хочет платить за карту после возвращения.

Сайт проекта: Card.club

EasyPayments — единственный вариант, который умеет наличные

EasyPayments — не финтех-обертка, а посредник по удаленному открытию счета в банке Киргизии или Армении. Работает от российского юрлица ООО «АЙТИ ВОРЛД» из Перми. Здесь выпускается именная банковская карта на ваше имя, с физическим пластиком и доставкой.

Что входит:

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

Тарифы:

• Киргизия — от 19 990 ₽;
• Киргизия — от 25 990 ₽;
• Киргизия — от 27 990 ₽;
• Армения — от 39 990 ₽.

Условия по Казахстану и Турции публично не опубликованы. IBAN на сайте не заявлен — рассчитывать стоит только на SWIFT. Карта живет до пяти лет, обслуживание от 20 долларов в год, есть рассрочка от 1 250 ₽ в месяц.

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

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

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

Сайт проекта: EasyPayments

Если баланс кошелька все-таки нужен

Все, что выше, решает задачу оплаты по QR. Если вам нужны именно юани на балансе Alipay — вариантов меньше, и они хуже.

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

TourCard. Это отдельная мини-программа внутри Alipay — предоплаченный кошелек от Bank of Shanghai, который пополняется с иностранной карты. Раньше назывался Tour Pass. Срок действия — 90 дней с активации, остаток по истечении возвращается на карту. Главный минус написан в пользовательском соглашении: за пополнение берется сервисный сбор, и в документе он описан на уровне 5%. Это больше, чем комиссия Alipay при прямой оплате картой, поэтому TourCard в 2026 году имеет смысл держать как запасной вариант — на случай, если ваша карта у какого-то конкретного мерчанта не проходит. Актуальные условия стоит смотреть на странице самой мини-программы: они менялись.

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

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

Что не работает, хотя про это до сих пор пишут

Привязка карты Сбербанка, ВТБ, Т-Банка или Альфа-Банка. Не работает и не заработает: карта отклоняется на этапе привязки по BIN. Статьи с инструкциями по каждому из этих банков написаны до 2022 года или основаны на ошибке.

Карта «Мир». Alipay эту систему не поддерживает.

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

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

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

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

1. Установите Alipay и зарегистрируйтесь по своему номеру. Российский номер подходит, менять симку не нужно. Код подтверждения приходит на него.
2. Пройдите верификацию по загранпаспорту. Понадобится четкое фото страницы с данными. Обычно проверка проходит за несколько минут, но закладывайте запас: в редких случаях она занимает до нескольких суток.
3. Выпустите иностранную карту. Виртуальная — 10–15 минут, банковская через посредника — от одного до пятнадцати рабочих дней.
4. Пополните карту с запасом. Считайте бюджет поездки, добавляйте 3% комиссии Alipay на крупные платежи и надбавку карты к курсу.
5. Привяжите карту в разделе банковских карт. Банк может запросить подтверждение — код или подтверждение в приложении. Поэтому делайте это дома, пока связь надежная.
6. Сделайте тестовый платеж. Пополните телефон на небольшую сумму или оплатите что-нибудь мелкое. Если прошло — карта рабочая.
7. Сохраните запасной вариант. Вторая карта другого эмитента, немного наличных юаней или установленный TourCard. Одна точка отказа в чужой стране — плохая идея.

Подводные камни

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

Трехпроцентная комиссия на крупных счетах. Правило считается по каждой отдельной транзакции, а не по итогу дня. Отель на 2 000 юаней — это 60 юаней комиссии, около 750 ₽. Если по той же карте можно заплатить напрямую на стойке, иногда дешевле так.

Фиксированная комиссия за операцию бьет по мелким платежам. В Китае вы платите телефоном по десять раз в день. Если у карты комиссия $0,25–0,40 за каждую операцию, за неделю набежит больше, чем вы ожидали. Для Китая тариф с нулевой комиссией за операцию окупается быстрее, чем для подписок.

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

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

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

Частые вопросы

Как пополнить Alipay из России? Баланс кошелька — только переводом от пользователя с китайским банковским счетом либо через TourCard с его сервисным сбором. Иностранной картой баланс не пополняется. Но для оплаты в Китае баланс и не нужен: привязанная карта списывает деньги напрямую.

Можно ли пополнить Alipay через Сбербанк или ВТБ? Прямого канала пополнения кошелька Alipay у российских банков нет. Функции переводов в Китай, если они есть, работают на банковский счет получателя, а не на кошелек физлица.

Можно ли привязать к Alipay карту «Мир»? Нет, эта платежная система китайской платформой не поддерживается.

Какие карты принимает Alipay? Международные Visa, Mastercard, American Express, JCB, Discover и Diners Club иностранных банков-эмитентов. Российские карты этих же систем не подходят: BIN указывает на российский банк.

Какая комиссия за пополнение Alipay? Правильнее говорить о комиссии за оплату. Платеж до 200 юаней включительно — без комиссии сервиса, свыше 200 юаней — 3% от всей суммы. Международные карты UnionPay от нее освобождены. Сверх этого возможна надбавка вашего эмитента к курсу конвертации.

Какой лимит у Alipay для иностранцев? По решению Народного банка Китая — до 5 000 долларов на одну операцию и до 50 000 долларов в год для верифицированных пользователей. Реальный лимит может быть ниже из-за политики банка-эмитента и категории мерчанта.

Нужен ли китайский номер телефона? Нет. Регистрация проходит по иностранному номеру, в том числе российскому. Китайская симка нужна только для отдельных сценариев внутри мини-программ.

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

Можно ли платить Alipay во Вьетнаме или других странах? Точечно — там, где мерчант принимает Alipay. В некоторых странах Азии такие точки есть, но это не массовое явление, и строить на этом поездку не стоит. Полноценно кошелек работает в материковом Китае.

Работает ли Alipay в Гонконге? Гонконг использует отдельное приложение AlipayHK, это самостоятельный продукт. Материковый Alipay там работает не везде.

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

Что делать, если платеж не проходит? Проверьте по порядку: хватает ли на карте денег с учетом 3% и надбавки к курсу; не требует ли банк-эмитент подтверждения, которое не дошло; не превышен ли лимит. Если все в порядке, а платеж все равно не идет — это ограничение на стороне конкретного мерчанта, и решается оно другим способом оплаты.

Итог

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

Из комиссий важны две цифры: 3% Alipay на платежи свыше 200 юаней и надбавка вашей карты к курсу, которая обычно больше первой. Лимиты — 5 000 долларов на операцию и 50 000 в год — вы в отпуске не почувствуете.

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

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

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

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

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

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

Почему лекции так выматывают?

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

1. Понимать поток речи.
2. Отбирать важное.
3. Формулировать кратко и записывать.

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

По словам психолога Джорджа Миллера, здесь и сейчас человек может обрабатывать 4–7 элементов информации. Представьте, что вы пытаетесь послушать, усвоить и записать материал, а вишенкой на торте становится пиксельная презентация 2007 года, при разглядывании которой сам черт ногу сломит. На ней еще налеплено текстовое полотно, в котором половина слов — канцелярит.

3 лайфхака для усвоения лекций

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

1. Превью за 5–10 минут. Перед лекцией загуглите тему и прочитайте короткую выжимку, чтобы прийти на пару хотя бы немного в теме, а не с чистого листа.
2. Метод акцентирования. Первый раз записываете лекцию как есть, в тетрадь или ноутбук. Второй раз проходитесь по записи и выделяете главное. Так полотно текста превращается в удобный конспект.
3. Школьное изложение. Да-да, то самое. Слушаете материал, а после пары своими словами пересказываете, что запомнили. Для первокурсников эти методы еще свежи. Восполнить их не должно быть трудно.

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

Как упростить конспектирование: «слушать» + «записывать»

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

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

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

1. Загрузите аудиозапись лекции в транскрибатор.
2. Запустите перевод аудио в текст.
3. Готово!, теперь у вас есть текст, с которым можно работать дальше.

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

Что в итоге?

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

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

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

Реклама. Рекламодатель: ООО «ПМТ» ИНН 7813667410, erid: 2W5zFHvmZUu

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

Неожиданный путь к цели: от C к C++ — и обратно

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

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

За несколько лет он стал хорошо известен в C++-сообществе: писал статьи, выступал с докладами, модерировал дискуссии на митапах, а со временем вошёл в программный комитет одной из главных конференций сообщества.

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

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

От статьи — к работе, о которой мечтал

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

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

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

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

Использовала прошлый опыт, чтобы построить направление с нуля

До YADRO Елена много лет работала в Nokia в направлении телеком. В 2022 году компания закрыла R&D-центр в Санкт-Петербурге, и большая часть команды, в которой работала Елена, перешла в YADRO.

Здесь опыт Елены и её коллег пригодился уже в новых условиях. Телеком-направление в YADRO тогда только появлялось, поэтому многое предстояло выстраивать практически с нуля. Но команда уже проходила этот путь и понимала, где могут возникнуть сложности и что теперь можно сделать иначе.

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

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

После 18 лет в одной экосистеме — к новым продуктам и технологиям

До YADRO Василий 18 лет проработал в IBM. Начинал инженером по серверным платформам x86, а со временем стал руководителем сервисного департамента в России и странах СНГ.

В 2022 году IBM ушла из России, а установленное у заказчиков оборудование продолжало работать и требовало поддержки. Василий вместе с командой из 20 инженеров перешёл в YADRO. Так удалось сохранить накопленную за годы экспертизу и продолжить поддерживать заказчиков уже в новых условиях.

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

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

От самостоятельной работы — к руководству командой

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

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

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

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

У каждого свой путь

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

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

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

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

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

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

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

Рейтинг курсов по созданию мультфильмов с ИИ

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

1. Pixel — Нейросети и ИИ для детей 8-12 лет

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

Для школьников также есть курс «Программирование в Scratch с ИИ». Ученики создают анимации и интерактивные игры, используют ИИ для генерации графики, знакомятся с чат-ботами, компьютерным зрением и собственными AI-моделями.

Ещё один вариант для более глубокого знакомства с анимацией — курс Moho для детей 14–17 лет. На нём ученики создают персонажей, осваивают 2D-анимацию и выпускают собственный мультфильм.

Кому подойдёт: детям, которые хотят объединить ИИ, анимацию и цифровое творчество.

Особенность: у ребёнка есть возможность продолжить развитие от простых AI-проектов к анимации и более сложным цифровым направлениям.

2. Компьютерная академия TOP — создание мультфильмов с нейросетями

У Компьютерной академии TOP есть специализированный курс «Создание мультфильмов с нейросетями».

Программа рассчитана на подростков и длится около пяти месяцев. В ней объединены 2D-графика, покадровая анимация, Stop-motion, видеомонтаж и современные нейросети.

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

Кому подойдёт: подросткам, которым интересны мультфильмы, визуальное творчество и создание видео.

3. 3D.GRYZ School — «Мультфильм с нейросетями»

Это один из наиболее узко направленных вариантов в подборке. Курс рассчитан на детей 10–14 лет и длится один месяц: 8 занятий по 90 минут.

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

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

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

4. Пандаматика — «Мультипликация с ИИ»

Курс «Мультипликация с ИИ» рассчитан на детей и подростков 8–16 лет. Программа длится два месяца и включает 16 занятий.

Заявленная цель — пройти путь от идеи до готового мультфильма. В программе используются Midjourney, Kandinsky, Kling AI, Runway ML, ElevenLabs, Suno, CapCut и DaVinci Resolve.

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

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

5. Rebotica — ИИ и нейросети для детей

Rebotica предлагает курс по искусственному интеллекту для школьников 9–11 лет, где ребёнок знакомится с ИИ через разные творческие проекты.

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

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

6. Pixel — Scratch с ИИ

Для младших школьников интересным вариантом может стать курс «Программирование в Scratch с ИИ».

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

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

Кому подойдёт: детям, которым нравятся одновременно мультфильмы, игры и программирование.

7. Skillbox Kids — углублённый курс по анимации

У Skillbox Kids есть углублённый курс по анимации для детей 10–12 лет. Программа длится восемь месяцев и посвящена созданию собственных мультфильмов — от раскадровки до готового анимационного ролика.

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

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

8. Академия Эдюсон — Scratch и нейросети

У Академии Эдюсон есть программа «Scratch и нейросети для детей». Курс сочетает основы Scratch, цифровую грамотность, создание проектов и использование современных AI-инструментов. В программе заявлены 48 интерактивных уроков и 19 проектов.

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

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

9. ИИ Университет — «Нейросети для детей»

Курс «Нейросети для детей» рассчитан на школьников 12–17 лет и длится два месяца.

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

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

10. TEEN.AI — ИИ и творчество

TEEN.AI — онлайн-школа нейросетей для детей 6–14 лет. В программе есть создание рисунков, мультфильмов, сайтов и ботов с помощью искусственного интеллекта.

Школа заявляет более 50 практических уроков и знакомство с 10+ AI-инструментами. Также есть бесплатные первые пять уроков.

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

Как создаётся мультфильм с помощью ИИ?

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

Обычно ребёнок проходит несколько этапов:

1. Идея.

2. Персонажи.

3. Сценарий.

4. Раскадровка.

5. Генерация изображений.

6. Анимация.

7. Озвучка.

8. Монтаж.

Все элементы объединяются в готовый мультфильм.

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

Что беспокоит родителей?

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

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

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

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

Для подростков можно постепенно добавлять более сложные инструменты, монтаж, сторителлинг, 2D/3D-анимацию и работу с несколькими нейросетями.

Как выбрать курс по созданию мультфильмов с ИИ?

Перед записью ребёнка стоит проверить:

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

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

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

Итог

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

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

Для первого знакомства можно выбрать короткую программу по мультфильмам с ИИ. Если ребёнок всерьёз увлёкся анимацией, стоит переходить к более глубокому изучению 2D, 3D, Moho, Blender и профессиональных инструментов.

А если школьнику одновременно нравятся мультфильмы, игры и программирование, интересным вариантом станет курс, где ИИ объединён с Scratch или другими инструментами разработки.

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

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

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

Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

№4. SOC

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

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

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

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

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

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

Итого

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

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

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

Куда должен вести пуш

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

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

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

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

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

• Приложение закрыто. При холодном старте оно запускается и загружается, после чего должно продолжить переход к экрану из уведомления. Во время проверки проследите, куда пользователь попадает по завершении запуска.
• Приложение работает в фоне. Здесь проверяют возвращение из свёрнутого приложения и открытие целевого экрана. При действующей сессии пользователь должен продолжить работу в приложении; дополнительную перезагрузку при открытии пуша стоит разобрать с командой.
• Телефон заблокирован. Откройте уведомление с экрана блокировки и разблокируйте устройство с помощью Face ID или PIN-кода. После этого маршрут к нужному экрану должен сохраниться.
• Пользователь уже работает в приложении. Полученное уведомление открывают во время активной работы. Проверьте, как переход вписывается в текущую навигацию и вызывает ли он перезагрузку приложения.

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

Что происходит после повторного входа

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

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

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

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

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

Что показать, если нужный экран недоступен

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

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

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

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

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

Один диплинк может использоваться в пушах, рекламных баннерах, письмах и СМС. Ссылку также размещают в QR-кодах, социальных сетях и мессенджерах. Команда должна проверить переход из каждого канала, где эта ссылка используется.

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

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

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

Как организовать работу с диплинками

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

В запись о каждом диплинке можно включить следующие поля:

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

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

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

Итого

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

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

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

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

Дмитрий Абрамов занимается уязвимостями, которые приносит генеративный код: что именно ломается, когда код пишет агент. Юрий Туманов отвечает за вторую половину задачи — за разбор находок. Он строит на локальных языковых моделях триаж сработок SAST: статический анализатор просматривает код и выдаёт список подозрительных мест (это и есть сработки), а триаж — разбор этого списка на настоящие уязвимости и ложные срабатывания.

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

Находок стало больше. Но не только из-за уязвимостей

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

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

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

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

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

Три механизма, из-за которых дефекты идут пачками

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

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

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

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

Третий механизм Дмитрий Абрамов называет самым коварным:

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

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

Что ушло, что пришло

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

Вместо них выросли пути эскалации привилегий, архитектурные дефекты, SSRF (когда сервер можно заставить сходить по адресу, который выбрал злоумышленник), отсутствие CSRF-защиты и security-заголовков. Плюс, как формулирует Дмитрий, «отсутствие понимания архитектуры приложения» — код, который сам по себе корректен, но не учитывает, как устроена система вокруг.

Причину он называет одну:

«Но все эти ошибки чаще всего проскакивают из-за недостаточности контекста, передаваемого агенту».

Часть проблем лечится буквально этим. Заголовки и CSRF в его команде почти исчезли после того, как добавили то, что они назвали «ИБ-контекстом». Модель не отказывалась делать безопасно — ей просто не сказали, что от неё этого ждут.

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

Кстати, он поправил саму постановку вопроса про слепые зоны:

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

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

Ошибки не в коде, а в поведении агента

Есть категория проблем, которая не попадёт ни в один SAST, потому что это вообще не про код.

«Лишний вызов инструмента, преждевременное завершение задачи, „починил“ тест вместо кода, сфабрикованный отчёт о прогоне — как у Replit. Это не свойство кода, это свойство процесса, и статические анализаторы к нему не приспособлены по определению».

Эта мысль пригодится дальше. Модель, которая уверенно рапортует об успехе, — проблема не только на стороне написания кода, но и на стороне его проверки.

Разбирать некому. Ставим на разбор модель

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

Напрашивается очевидное: спросить у модели, настоящая это уязвимость или ложное срабатывание. Спросить действительно можно.

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

У него в докладе есть слайд, который так и называется: «Складно ≠ доказано».

Почему прямой вопрос не работает

Причин три.

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

«Само-оценка модели без внешней калибровки театральна, опираться на неё нельзя».

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

«Универсальная рамка „найди источник и сток“ на дефектах-„свойствах“ хоронит реальное: на одном моём замере неудачная постановка вопроса похоронила 140 реальных сработок из 363».

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

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

Модель предполагает, правила решают

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

Второе — сработки разделены на два сорта, и доказываются они по-разному.

Уязвимость-свойство. Опасен сам факт в коде: пароль в исходниках, слабый хеш, слишком открытые права. Вопрос ровно один — настоящий секрет или заглушка. Никакого пути данных здесь нет и быть не должно. Таких сработок в потоке подавляющее большинство, около 93%.

Для них выстроена лестница проверок, и модель на ней — лишь одна из ступеней. Сначала работает алгоритмика без всякой LLM: ключ в формате боевого AWS — сразу подтверждаем, файл сгенерированный или из SBOM — сразу ложное срабатывание. Это снимает больше половины шума и не стоит ни одного обращения к модели. Дальше вопрос уходит модели, но задаётся по сути факта. Потом больше сотни детерминированных правил проверяют её ответ и могут вердикт поправить. Потом пороги по классам: слабый ответ превращается в Unknown. Последняя ступень — человек. Отдельным правилом запрещена сама формулировка «не вижу пути атаки» как причина закрытия: именно на ней система и теряла те самые 140 сработок из 363.

Уязвимость-путь. Здесь опасен маршрут данных: SQL-инъекция, XSS, обход каталогов. Вопрос другой — дошли ли данные атакующего до опасного вызова и была ли по дороге защита. Вот для этого типа и сделан evidence gate.

Evidence gate: перечисли факты — вердикт выведется сам

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

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

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

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

«Придумать вывод легко, придумать проверяемую улику сложно. <…> Фактам — да, поэзии — ни-ни».

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

И снова всё упирается в контекст. Чаще всего система отвечает «недостаточно данных» по одной причине: трасса слишком короткая. Модель видит место, где переменная попадает в опасный вызов, но не видит, откуда эта переменная пришла и проверяли ли её по дороге. Лечится это не увеличением окна и не моделью побольше, а доставкой недостающего кода. Юрий пробовал 72B через внутренний портал и получил обратный результат:

«Дисциплина важнее размера».

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

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

Почему локально

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

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

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

Со стоимостью тоже всё сходится: одна игровая RTX 4080 разбирает около восьми тысяч сработок в сутки за электричество.

История про токен

Самая показательная часть доклада— не про метрики.

«Боевой GitLab-токен, модель с уверенностью 1.0 обозвала его „placeholder in test configuration“ — заглушкой в тестовом конфиге, — поверила пути файла и похоронила. Реальный секрет, закрытый автоматом».

Доверие команды после такого падает мгновенно:

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

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

«Доверие к автомату устроено как доверие к коллеге: ошибаться можно, прятать ошибки нельзя. Система, которая сама показывает промахи и после каждого меняется, доверие возвращает. Система, которая уверенно бормочет „всё хорошо“, теряет его навсегда».

Где проходит граница

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

Дмитрий Абрамов:

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

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

Юрий Туманов отвечает про свою часть работы, но приходит к тому же. Автомат работает там, где улика видна прямо по артефакту, а полноту можно проверить канарейками. Цепочечные классы — SQL-инъекции, XSS, path traversal, всё, где нужно доказать путь данных через приложение, — идут к человеку: именно там небольшие модели выдают уверенные галлюцинации, а уверенный неверный вердикт обходится дороже, чем честный ответ «недостаточно данных». Необратимые действия без человека — ротация и отзыв секретов, блокировки, автопатчи с автомержем — тоже нет. И отдельно:

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

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

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

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

Что вообще можно делать в агрегаторе нейросетей

Если Вы раньше не пользовались такими сервисами, вот примерный список задач, которые закрываются в одном окне:

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

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

Три вида агрегаторов: какой нужен именно Вам

Слово «агрегатор» используют для трёх разных вещей, и половина разочарований случается именно из-за этой путаницы.

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

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

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

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

1. ERA2.ai — все типы нейросетей в одном кабинете

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

ERA2.ai — тот случай, когда одним сайтом закрывается вообще всё. Внутри свыше 140 нейросетей, разложенных по четырём разделам. Текст: ChatGPT, Claude, Gemini, Grok, DeepSeek, Perplexity, Qwen — больше тридцати моделей. Картинки: Nano Banana 2, Seedream, Flux, GPT Image, Ideogram, Recraft. Видео: Sora, Veo, Kling, Seedance, Hailuo, Runway, HeyGen. Озвучка и музыка: ElevenLabs и Suno. Отдельно есть готовые ИИ-помощники под задачи в несколько шагов.

Здесь видно, сколько стоит каждое действие, ещё до того как Вы его запустите. Цена написана прямо на кнопке: сообщение в чате — от 3 кредитов, картинка — от 5 до 380 в зависимости от модели, видеоролик — от 125. Кредиты общие для всех инструментов и, что важно, не сгорают в конце месяца — остаток переносится дальше. Оплата обычная: карты российских банков, СБП, есть рассрочка, работает через ЮKassa.

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

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

Плюсы:

• свыше 140 нейросетей в одном кабинете: текст, картинки, видео, озвучка;
• цена каждого действия видна заранее — не придётся гадать, на что ушли деньги;
• кредиты не сгорают и переносятся на следующий месяц;
• бесплатный старт: 150 кредитов без привязки карты;
• понятные тарифы в рублях — 790 и 1 490 рублей в месяц, докупка от 290 рублей, при оплате на год скидка 15%;
• всё на русском языке, запрос можно писать как думаете.

Минусы:

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

Открыть ERA2.ai

2. +Вайб (vibeplus.ai) — фото, видео и озвучка нажатием кнопки

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

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

Что внутри: генерация и обработка изображений, больше 6 000 готовых сценариев ИИ-фотосессий — от делового портрета до отпускных кадров, — видео на движках Kling и Veo, оживление старых снимков, говорящие аватары, озвучка на 200 голосов и чат с ChatGPT, Claude, Gemini, DeepSeek и Grok. Плюс больше 60 отдельных инструментов: реставрация архивных фото, удаление лишних объектов, замена фона, распознавание текста с картинки, сборка инфографики для маркетплейсов.

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

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

Плюсы:

• всё для фото, видео и звука в одном месте, включая озвучку и чат;
• больше 6 000 готовых стилей фотосессии — выбрал и получил результат;
• лицо на серии кадров остаётся узнаваемым;
• 60+ инструментов в один клик, запрос писать не нужно;
• платите только за то, чем пользуетесь, стартовые кредиты бесплатно;
• рубли, российские карты и СБП.

Минусы:

• шесть тысяч стилей — это ещё и шесть тысяч вариантов выбора: с первого захода легко зависнуть в каталоге.

Открыть +Вайб

3. Freepik (Magnific) — большой набор для картинок и видео

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

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

Сложности начинаются с оплатой. Тарифы валютные: Premium — 20 долларов в месяц, Premium+ — 45, Pro — 280. Оплатить российской картой не получится, придётся искать посредника, а он возьмёт свою комиссию. Второй момент — неизрасходованные кредиты не переходят на следующий месяц. И третий: модерация строгая, часть вполне обычных сюжетов сервис отказывается генерировать.

Бесплатный тариф есть — около 20 картинок в день, чтобы посмотреть.

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

Плюсы:

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

Минусы:

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

4. Aymo AI — сравнить ответы нескольких нейросетей сразу

Вид: готовое рабочее место. Цена: бесплатный план на 500 сообщений, дальше от 4 долларов в месяц.

Больше 54 нейросетей в одном окне: GPT-5.5, Claude Sonnet и Opus, Gemini, DeepSeek, Llama, Qwen, Grok, Mistral. Главная особенность, ради которой сервис и стоит смотреть, — Вы задаёте вопрос один раз, а ответ приходит сразу от нескольких нейросетей, и они выводятся рядом. Очень наглядно, когда нужно выбрать формулировку: видно, какая модель поняла задачу лучше.

Ещё умеет разбирать PDF и документы, искать в интернете и работать в команде. Тарифы считаются в сообщениях: бесплатно 500 в месяц, потом примерно от 4–8 долларов за 3 000 и от 12–20 долларов за 12 000 сообщений с полным набором моделей. Тут есть нюанс: разбор стостраничного документа спишет ровно одно сообщение, как и слово «привет», — то есть на длинных задачах это выгодно, а на коротких переплачиваете.

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

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

Плюсы:

• ответы нескольких нейросетей на один вопрос в одном окне;
• заметный бесплатный план — 500 сообщений в месяц;
• разбирает PDF и документы, умеет искать в интернете;
• есть командный доступ.

Минусы:

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

5. Сигмачат — в основном для текста, с оплатой за символы

Вид: готовое рабочее место, профиль — текст. Цена: оплата за фактический расход, пополнение от нескольких сотен рублей.

Российский сервис, у которого сильная сторона — именно текстовые нейросети. В каталоге вся линейка ChatGPT от 3.5 Turbo до 5.6, Claude от Haiku до Opus, DeepSeek, Gemini, Grok и «думающие» модели серии o1. Картинки (Flux, DALL·E 3, Midjourney, SDXL), видео (Sora, Luma, Veo) и музыка через Suno тоже есть, но это скорее приятное дополнение — основной сценарий здесь всё-таки переписка с текстовой моделью.

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

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

Плюсы:

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

Минусы:

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

6. Гервин — конвейер для текстов и рекламных материалов

Вид: сервис под конкретную задачу, профиль — текст. Цена: есть бесплатный пробный доступ, платные планы от нескольких сотен рублей.

Платформа выросла из копирайтинга и этот профиль сохранила. Ядро сервиса — готовые шаблоны под типовые тексты: описание товара, пост в соцсети, рассылка, текст для сайта. Придумывать запрос не нужно, достаточно заполнить поля. Заявлено больше 200 нейросетей и мини-приложений: текстовые Gemini, Claude, GPT, Qwen, DeepSeek, генераторы картинок FLUX, Midjourney, Recraft, Nano Banana, видео Seedance, MiniMax, Runway, звук — ElevenLabs, Suno. Но картинки и видео здесь дополняют тексты, а не живут своей жизнью.

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

Кому подойдёт: тем, кто пишет много однотипных текстов — интернет-магазинам, авторам рассылок, специалистам по продвижению.

Плюсы:

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

Минусы:

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

7. OpenRouter — для тех, кто встраивает нейросети в свои программы

Вид: инструмент для программистов. Цена: пополнение баланса плюс комиссия сервиса.

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

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

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

Плюсы:

• больше 400 нейросетей от 70+ поставщиков в одном месте;
• автоматическое переключение, если модель недоступна;
• подробная статистика расходов;
• лучший выбор, если ИИ встраивается в собственный продукт.

Минусы:

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

8. AITunnel — то же самое, но с рублями и документами

Вид: инструмент для программистов. Цена: оплата за расход, минимальный баланс 500 рублей.

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

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

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

Плюсы:

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

Минусы:

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

9. RouterAI — оплата строго по факту, без подписки

Вид: инструмент для программистов. Цена: только фактический расход, минимального платежа нет.

Ещё один российский сервис для встраивания нейросетей: сотни моделей — Claude, GPT, Gemini, DeepSeek и открытые решения. Заявленный принцип — никаких подписок, скрытых комиссий и обязательных минимальных платежей: платите ровно за то, что использовали. Если основная модель не отвечает, запрос автоматически уходит на резервную.

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

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

Плюсы:

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

Минусы:

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

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

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

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

Если в основном тексты. Большой каталог картинок Вам только помешает. Здесь важнее качество текстовых моделей и цена за объём — этот сценарий закрывают Сигмачат и Гервин.

Если Вы разработчик. Ваш случай — три последних сервиса из обзора. Из них рублёвые расчёты и документы для организации дают AITunnel и RouterAI.

Главное правило при выборе тарифа

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

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

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

Как получить хороший результат: пошаговый пример

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

1. Текстовые нейросети — ChatGPT, Claude, Gemini — начните с текста: сценарий, структура, черновик. Самый дешёвый шаг, а качество остального зависит именно от него.
2. ИИ-агенты и ассистенты — готовые помощники для задач в несколько шагов: разобрать сотню отзывов, переписать описания товаров по шаблону, собрать план публикаций.
3. Генерация изображений с помощью ИИ — сделайте пять-десять черновых картинок на быстрой модели, чтобы определиться с композицией.
4. Nano Banana 2 — генерация изображений — финальную картинку рисуйте здесь: эта модель лучше других справляется с русскими надписями внутри кадра.
5. Удалить фон с фото — аккуратно отделить объект, если картинку нужно вставить в макет или карточку товара.
6. Генерация видео с помощью ИИ — оживите готовый кадр: Sora, Veo, Kling и Runway делают короткий ролик по описанию движения.
7. Генератор видео Seedance — если в ролике несколько сцен и нужна единая стилистика, этот движок лучше держит картинку от кадра к кадру.
8. Генерация аудио и голоса с помощью ИИ — озвучка голосом диктора на русском и фоновая музыка, без поиска стоков и разбирательств с лицензиями.

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

Сколько стоит подписаться на всё по отдельности

Сколько стоит подписаться на всё по отдельности

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

Текст — подписка на топовую нейросеть: около 20 долларов в месяц.

Картинки — Freepik Premium+: 45 долларов в месяц.

Видео — отдельный видеогенератор: 15–30 долларов в месяц.

Озвучка — сервис синтеза речи: около 22 долларов в месяц.

Музыка — генератор треков: около 10 долларов в месяц.

Итого: около 112–127 долларов в месяц.

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

Для сравнения — тарифы российского сервиса из первой строчки обзора:

Старт — бесплатно, без карты: 150 кредитов разово; базовые модели текста и картинок.

Базовый — 790 ₽ в месяц: 3 000 кредитов в месяц; все текстовые модели, все картинки, пять видеомоделей, безлимитный чат.

Про — 1 490 ₽ в месяц: 8 000 кредитов в месяц; весь каталог, качество 4K, без очереди, увеличение и удаление фона бесплатно.

Докупка — 290 / 1 290 / 4 490 ₽: 1 000 / 5 000 / 20 000 кредитов; кредиты не сгорают и переносятся.

Что это значит на практике. Сообщение в чате стоит от 3 кредитов, картинка — от 5 до 380, видеоролик — от 125. То есть тариф за 790 рублей — это примерно 60 картинок на хорошей модели и полторы сотни сообщений, либо около 20 коротких роликов. Тариф за 1 490 рублей — 8 000 кредитов и весь каталог. При оплате на год действует скидка 15%, а в большом пакете кредит обходится в 0,22 рубля против 0,29 в маленьком.

Итого: набор зарубежных подписок обойдётся примерно в 10 000 рублей в месяц, с комиссиями и сгорающим остатком. Сопоставимый объём в рублёвом сервисе — 790–1 490 рублей, и неизрасходованное переносится. Посмотреть тарифы

Что это значит на практике. Сообщение в чате стоит от 3 кредитов, картинка — от 5 до 380, видеоролик — от 125. То есть тариф за 790 рублей — это примерно 60 картинок на хорошей модели и полторы сотни сообщений, либо около 20 коротких роликов. Тариф за 1 490 рублей — 8 000 кредитов и весь каталог. При оплате на год действует скидка 15%, а в большом пакете кредит обходится в 0,22 рубля против 0,29 в маленьком.

Итого: набор зарубежных подписок обойдётся примерно в 10 000 рублей в месяц, с комиссиями и сгорающим остатком. Сопоставимый объём в рублёвом сервисе — 790–1 490 рублей, и неизрасходованное переносится. Посмотреть тарифы

Частые вопросы

Какой агрегатор нейросетей выбрать в 2026 году? Для большинства задач — ERA2.ai: 140+ нейросетей всех типов, русский интерфейс, тарифы от 790 рублей. Если нужны в основном фото и видео и не хочется разбираться с запросами — +Вайб. Если только тексты — Сигмачат или Гервин. Если Вы программист — AITunnel, RouterAI или OpenRouter.

Есть ли бесплатный агрегатор нейросетей? Полностью бесплатных нет: каждая генерация — это работа чужих видеокарт, за которую кто-то платит. Но начать бесплатно можно почти везде. ERA2 даёт 150 кредитов при регистрации и не просит карту, у +Вайб есть стартовый пакет, Сигмачат разрешает первый запрос бесплатно, у Гервина есть пробный доступ, Aymo AI даёт 500 сообщений в месяц, у Freepik — около 20 картинок в день.

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

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

Какие агрегаторы принимают российские карты? Из этого обзора — ERA2.ai (карты, СБП и рассрочка), +Вайб, Сигмачат, Гервин, AITunnel и RouterAI. Freepik, Aymo AI и OpenRouter требуют зарубежную карту, то есть оплату через посредника с комиссией.

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

Итоги

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

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

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

Реклама. Рекламодатель: ИП Изюк Валерия Олеговна ИНН 621904482944, erid: 2W5zFGLrKnH

Однако в 2026 году на Low-code строятся уже не просто легкие прототипы, а критически важные Enterprise-системы: биллинги, CRM, сервисные порталы и ERP-модули. При интеграции таких решений в сложный ИТ-ландшафт на первый план выходят вопросы архитектуры, отказоустойчивости и информационной безопасности. Неправильно подобранный фундамент обернется невозможностью масштабирования и жестким vendor lock-in.

Чтобы избежать этих ошибок, недостаточно сравнивать списки функций в презентациях. В этом обзоре мы проанализировали 10 популярных российских Low-code платформ через призму промышленной эксплуатации (Day 2 Operations). Мы оценим, как системы ведут себя при высоких нагрузках, как переносят настройки между средами (Dev/Test/Prod) и сколько реально стоит их поддержка.

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

Что такое платформа автоматизации в 2026 году

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

Однако фундаментальное отличие платформ кроется в их архитектуре. Классические BPM-системы и Low-code платформы по-разному обрабатывают сложную логику. Автоматизация линейных заявок (например, заказ курьера) не требует сложной инфраструктуры. Но создание отказоустойчивой корпоративной системы на тысячи пользователей с ролевой моделью доступа (RBAC), интеграцией через корпоративные шины данных (ESB) и передачей метрик мониторинга требует совершенно иного архитектурного подхода.

Ключевой вызов Low-code: внедрение визуальной разработки не отменяет потребности в квалифицированных ИТ-специалистах. Напротив, для поддержки масштабной Low-code системы требуются компетентные DevOps-инженеры, администраторы баз данных (DBA) и архитекторы. Их задача — контролировать качество генерируемых системой запросов к БД и не допускать деградации производительности при росте количества бизнес-правил, созданных аналитиками.

Три уровня Low-code платформ: от форм до промышленных систем

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

• Уровень 1. Простая автоматизация. Предназначены для работы с линейными заявками, простыми маршрутами согласований и справочниками. Архитектурно заменяют процессы, ранее ведшиеся в Excel и электронной почте. Оптимальны для быстрого старта периферийных задач, но требуют контроля во избежание появления «теневого ИТ» (Shadow IT).
• Уровень 2. Корпоративные бизнес-приложения. Решения для создания учетных систем, корпоративных порталов, автоматизации сервисных процессов (ITSM/ESM) и сложного документооборота. Требуют строгой ролевой модели, глубоких интеграций с ИТ-ландшафтом компании и рассчитаны на нагрузку в тысячи пользователей, где время простоя критично для бизнеса.
• Уровень 3. Полноценная разработка систем. Платформы для создания продуктовых приложений со сложной транзакционной логикой и высокой нагрузкой (кастомные CRM, модули ERP, WMS). На этом уровне необходимы инструменты CI/CD для переноса конфигураций, профилирование баз данных и использование Pro-code (профессиональной разработки) для реализации сложных интеграций и вычислений.

ТОП-10 платформ для автоматизации бизнес-процессов

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

1. Технологическая платформа SimpleOne

Происхождение: платформо-нативный Low-code (изначально проектировалась как Enterprise-фреймворк).

Уровень: 3 (полноценная разработка систем).

Сильные стороны: нативная архитектура позволяет строить единые контуры ESM, ITSM, HR и CRM на общей модели данных. Встроенная система версионирования (VCS) обеспечивает IT-governance, выстраивая разработку по циклу Dev/Test/Prod, что необходимо для безопасного развертывания изменений. Масштабируемое Enterprise-ядро дополнено платформенным GenAI-слоем для оркестрации больших языковых моделей (LLM).

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

Для кого: крупный бизнес и государственные структуры, переходящие к сквозной сервисной модели (ESM) и готовые инвестировать в создание внутренних Центров Компетенций (CoE).

2. BPMSoft

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

Уровень: 3 (полноценная разработка систем, CRM-класс).

Сильные стороны: зрелая логика управления процессами продаж и маркетинга. Строгое соответствие нотации BPMN 2.0. Платформа обладает мощным блоком профессиональной разработки (Pro-code) на базе C#, что является преимуществом для Enterprise-команд.

Слабые стороны: для реализации нестандартных интеграций или сложных пользовательских интерфейсов (UI) требуется привлечение разработчиков .NET (C#). Собственная система объектно-реляционного отображения (ORM) требует мониторинга производительности баз данных при высоких нагрузках.

Для кого: компании, замещающие западные CRM-системы (Salesforce, Dynamics) и выстраивающие комплексные клиентские процессы при наличии экспертизы в C#.

3. ELMA365

Происхождение: эволюция классического BPM-движка.

Уровень: 2 (корпоративные бизнес-приложения).

Сильные стороны: высокий уровень оркестрации межфункциональных процессов благодаря зрелому BPMN-движку. Наличие готовых модулей для ESM/ITSM и электронного документооборота (ЭДО). Платформа включает модуль ELMA Cortex для интеграции ИИ-решений.

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

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

4. Comindware

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

Уровень: 2 (корпоративные бизнес-приложения).

Сильные стороны: поддержка BPMN 2.0 и кейс-менеджмента (CMMN) для гибких, неструктурированных процессов. Использование графовой архитектуры обеспечивает возможность изменения структуры данных без остановки процессов (zero-downtime scheme evolution).

Слабые стороны: переход на графовую базу данных требует адаптации подходов администраторов баз данных (DBA) и ИТ-архитекторов компании, привыкших к реляционным моделям.

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

5. Pyrus

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

Уровень: 1 (простая автоматизация).

Сильные стороны: быстрое развертывание в облачной среде (SaaS). Низкая стоимость владения на старте. Удобное мобильное приложение и простота освоения бизнес-пользователями.

Слабые стороны: архитектурные ограничения для построения сложных транзакционных систем. Отсутствие глубоких интеграционных механизмов (управления состоянием) и невозможность установки в закрытом контуре компании (On-premise).

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

6. Directum RX

Происхождение: системы электронного документооборота (ECM/СЭД).

Уровень: 2 (корпоративные бизнес-приложения).

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

Слабые стороны: архитектура исторически сфокусирована на сущности «Документ». Построение высокотранзакционных систем вне экосистемы документооборота (например, биллинга) может быть архитектурно неоптимальным.

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

7. Битрикс24

Происхождение: CRM и корпоративный портал.

Уровень: 1 → 2 (простая автоматизация и легкие корпоративные сценарии).

Сильные стороны: широкий базовый функционал «из коробки» (CRM, интранет, задачи, коммуникации). Быстрый старт и интуитивно понятный интерфейс для массового пользователя.

Слабые стороны: монолитная архитектура коробочной версии. Сложности при масштабировании, внедрении сложной Enterprise-логики и глубокой интеграции с корпоративными шинами (ESB) при обработке больших массивов данных.

Для кого: малый и средний бизнес (СМБ), нуждающийся в едином пространстве для совместной работы и CRM без необходимости сложного архитектурного планирования.

8. GreenData

Происхождение: платформо-нативный Low-code.

Уровень: 3 (полноценная разработка систем).

Сильные стороны: объектная модель данных, поддержка BPMN 2.0. Высокий заявленный уровень комплаенса (ФСТЭК, 152-ФЗ, PCI DSS), что важно для финансового сектора.

Слабые стороны: для реализации сложной бизнес-логики и интеграций требуется профессиональная разработка (Pro-code) на языке Groovy, что смещает фокус с бизнес-аналитиков на квалифицированных Java/Groovy-разработчиков.

Для кого: ИТ-департаменты, планирующие замену legacy-систем на платформенное решение и обладающие штатом разработчиков.

9. Naumen SMP

Происхождение: Enterprise Service Desk и контакт-центры.

Уровень: 2 (корпоративные бизнес-приложения).

Сильные стороны: высокая отказоустойчивость при реальных высоких нагрузках (HighLoad) в контакт-центрах и службах поддержки. Зрелые процессы маршрутизации и контроля SLA.

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

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

10. Digital Q (Diasoft)

Происхождение: экосистема для финансового сектора.

Уровень: 2.

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

Слабые стороны: специфика технологического стека, ориентированного преимущественно на материнскую отрасль (финтех). Ограниченное количество публичных референсов внедрения платформы вне банковского сектора в качестве универсального Low-code инструмента.

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

Сравнительная матрица платформ

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

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

Выбор Low-code платформы должен основываться на архитектурных требованиях и доминирующем типе процессов в компании.

Задача: единый Сервис-деск, ОЦО, ITSM/ESM

• Рекомендуемые платформы: SimpleOne, Naumen.

• Почему: Встроенные ESM-инструменты (CMDB, SLA, Порталы), доказанная масштабируемость для сервисных подразделений.

Задача: сквозное управление процессами, ЭДО

• Рекомендуемые платформы: ELMA365, Directum RX.

• Почему: Сильные BPMN-движки и глубокая экспертиза в работе с документами.

Задача: комплексная CRM + BPM

• Рекомендуемые платформы: BPMSoft.

• Почему: Исторически зрелая CRM-логика и инструменты для отдела продаж.

Задача: простая автоматизация в СМБ

• Рекомендуемые платформы: Pyrus, Битрикс24.

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

Выводы

Резюмируя опыт внедрения и эксплуатации различных платформ автоматизации, выделим четыре главных правила для ИТ-руководителей при выборе Low-code решений:

1. Low-code не заменяет классическую ИТ-экспертизу. Внедрение Enterprise-платформы не позволит отказаться от услуг профильных инженеров. Напротив, для обеспечения стабильности и масштабируемости вам потребуются сильные системные архитекторы, DevOps-инженеры и специалисты по базам данных. Их задача — выстроить надежный фундамент, на котором бизнес-аналитики смогут безопасно собирать процессы.
2. Главная ценность платформ — Time-to-Market, а не прямая экономия на ФОТ. Инвестиции в Low-code окупаются за счет радикального ускорения вывода новых бизнес-продуктов на рынок. Разработчики освобождаются от рутины и переключаются на сложные интеграции и обеспечение безопасности, а аналитики берут на себя гибкую настройку бизнес-правил.
3. Оценивайте архитектурные ограничения до старта проекта. Выбирайте систему не по количеству функций в презентации, а по ее способности интегрироваться в ваш ИТ-ландшафт и выдерживать целевые нагрузки. Выбирайте платформу, с архитектурными особенностями которой вы готовы мириться ближайшие 5–7 лет.
4. Технологическая дисциплина важнее гибкости. Легкость настройки процессов таит в себе риски. Без внедрения строгого IT-governance, разделения контуров (Dev/Test/Prod) и использования систем версионирования, любая современная платформа рискует быстро превратиться в неконтролируемое legacy.

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

Как выбрать цифровую платформу для ведения ИТ-проектов и по каким критериям оценивать системы? На какие решения стоит обратить внимание в 2026 году? В статье разберем функциональность 5 популярных ИСУП и подсветим плюсы и минусы каждого ПО.

В чем особенность ИТ-проектов

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

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

И все же ряд особенностей у ИТ-проектов есть:

1. В основе реализации лежат Agile-подходы. Классические методы задают рамку (сроки, бюджет, контроль), но реальная работа строится через гибкие практики: внутри почти всегда используются спринты, бэклог, инкременты.

2. Итерационная поставка ценности. Управление строится не только вокруг соблюдения плана: результат создается не в конце проекта, а через регулярные релизы.

3. Работа в цифровой среде. Команда (разработчики, аналитики, тестировщики) используют информационные системы: таск-трекеры, репозитории, CI/CD. Проект «живет» в инструментах, а не в отчетах.

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

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

Какой должна быть система для управления ИТ-проектами

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

1. Поддержка гибридных подходов (Agile + Waterfall). Руководитель работает с этапами, сроками, бюджетом, исполнители — с досками, бэклогами и спринтами.

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

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

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

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

Из технологических критериев стоит обратить внимание на:

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

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

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

• безопасность — чтобы защитить данные и управлять правами доступа пользователей;

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

Обзор популярных российских сервисов для управления ИТ-проектами

Directum Projects — платформенное решение для управления проектами, бизнес-процессами, командами, документами, задачами и знаниями

Система полностью импортонезависима и безопасна: разработана в России и включена в реестр отечественного ПО (№4499), доступно размещение в «облаке» и на сервере предприятия.

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

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

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

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

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

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

Система совместима с отечественным и свободно распространяемым ПО. Благодаря сервисам интеграции можно объединить любые инструменты, используемые в компании, в единую экосистему. Настроить Directum Projects под требования бизнеса поможет разработка без кода или с низким его содержанием (no-low-code).

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

Цена: от 8190 рублей в год за человека.

SimpleOne SDLC — специализированная система для управления полным циклом разработки ПО: от идеи до выпуска продукта

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

Доступны:

• управление разработкой: диаграмма Ганта, гибкие методологии, ИИ-анализ кода;

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

• планирование и учет трудозатрат;

• библиотека документации: связь файлов с задачами и услугами;

• аналитика: кастомные формы отчетов, Agile-метрики;

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

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

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

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

Цена: по запросу.

EvaProject — отечественная система управления проектами и командами

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

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

• жизненным циклом разработки и задачами от постановки до релиза;

• бэклогом и спринтами: есть приоритизация и контроль выполнения;

• релизами и дорожной картой: можно спланировать этапы поставки и развития продукта;

• изменениями: фиксируются и контролируются все корректировки;

• импортом данных из зарубежных решений;

• прогрессом: в систему «заведены» информационные панели для мониторинга задач, загрузки и выполнения проекта.

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

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

Цена: от 450 рублей в месяц за человека.

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

Сервис входит в экосистему Яндекс 360: можно «подтягивать» почту, синхронизировать встречи с календарем и ставить задачи из писем. Включен в реестр отечественного ПО.

Ключевые возможности:

• организация совместной работы: можно объединять разные команды в одном проекте;

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

• классика и гибкость: доступны доски и диаграмма Ганта;

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

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

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

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

Цена: от 399 рублей в месяц за человека.

Timetta — отечественная ИСУП, ориентированная на контроль ресурсов и экономику проектов

Программа подходит для компаний с проектной моделью бизнеса (интеграторы, консалтинг, ИТ-подразделения). Доступна в облаке и локальной поставке (on-premise).

Функциональность и особенности:

• фокус на экономике проектов, учет трудозатрат, расчет себестоимости и маржинальности;

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

• связка плана и факта: есть возможность сравнить запланированные и реальные трудозатраты;

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

• понятная аналитика, отчеты по эффективности проектов и использованию ресурсов в разных разрезах.

Можно адаптировать систему под потребности компании.

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

Цена: от 1105 рублей в месяц за лицензию.

Основные функциональные критерии отечественных ИСУП

Итог

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

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

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

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

Рейтинг школ ИИ для детей

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

1. Pixel

Если ребёнок любит Minecraft, но родители хотят превратить интерес к игре в полезное обучение, можно обратить внимание на курс «Программирование на Python в Minecraft с ИИ» в школе Pixel.

Программа рассчитана на детей от 9 лет и школьников 3–7 классов. Подойдёт как начинающим, так и ученикам с опытом программирования. Главное отличие курса — ребёнок изучает Python не на абстрактных задачах, а сразу применяет код внутри знакомого игрового мира.

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

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

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

Программа первого модуля включает:

• знакомство с Python;
• переменные и основы логики;
• работу с координатами;
• циклы;
• функции;
• управление блоками Minecraft с помощью Python;
• автоматическое строительство;
• создание мини-игр;
• основы работы с ИИ через API;
• создание собственного итогового проекта.

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

Курс состоит из 12 занятий по 90 минут, которые проходят онлайн один раз в неделю. В мини-группе — до 12 учеников. После занятий ученик получает домашние задания для закрепления материала, а в личном кабинете доступны учебные материалы и записи пропущенных уроков.

Кому подойдёт: школьникам от 9 лет, которые любят Minecraft, интересуются программированием или хотят попробовать ИИ на практике.

Главный плюс курса: Minecraft здесь используется не просто как игровая оболочка, а как среда, в которой ребёнок может увидеть, как Python-код превращается в реальные действия и изменения игрового мира. Это помогает связать изучение программирования с понятным для ребёнка результатом.

2. Алгоритмика

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

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

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

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

3. CODDY

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

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

Например, курс по промпт-инжинирингу для подростков 13–16 лет учит работать с текстовыми и графическими нейросетями и создавать собственные проекты. В программе используются YandexGPT, GigaChat, Kandinsky и другие инструменты.

Кому подойдёт: детям, которым интересны современные AI-сервисы, создание контента или программирование.

Плюсы: несколько специализаций, практические проекты, разные уровни сложности.

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

У TOP есть направление «Мастер нейросетей» для подростков. Программа ориентирована на практическое применение ИИ — от промптинга до работы с современными AI-инструментами.

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

Кому подойдёт: подросткам, которые хотят разобраться в возможностях современных нейросетей.

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

5. Умназия

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

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

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

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

6. Skysmart

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

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

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

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

7. Skillbox Kids

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

Например, курс «Кодим с AI: Python для юных разработчиков» рассчитан на детей 11–15 лет. Школьники изучают Python и используют ИИ как помощника при написании и отладке кода. Программа длится три месяца и включает практические проекты.

Это важный формат: ребёнок не просто учится пользоваться чат-ботом, а понимает, как применять ИИ в разработке.

Кому подойдёт: подросткам, которым интересно программирование.

Плюсы: Python + ИИ, практические задачи, актуальный подход к разработке.

8. Академия Эдюсон

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

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

Кому подойдёт: подросткам с интересом к программированию и AI.

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

9. Hello World

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

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

Кому подойдёт: начинающим школьникам.

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

10. Айтигенио

Айтигенио — онлайн-школа, которая предлагает детям программирование и отдельные занятия по нейросетям.

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

Кому подойдёт: детям и подросткам, которые хотят попробовать нейросети и программирование.

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

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

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

Если ребёнку 7–9 лет

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

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

Если ребёнку 10–12 лет

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

Хороший показатель программы — наличие собственных проектов.

Если подростку 13–15 лет

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

Если школьнику 16–17 лет

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

Главная ошибка родителей при выборе курса

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

Сегодня конкретные AI-сервисы быстро меняются. Поэтому гораздо важнее дать школьнику универсальные навыки:

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

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

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

Это зависит от интересов ребёнка.

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

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

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

Итог

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

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

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

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

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

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

При выборе школ учитывали несколько критериев:

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

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

Рейтинг школ по обучению ИИ для детей

1. Pixel

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

Курс рассчитан на детей и подростков 7–17 лет. Программа подбирается с учётом возраста и уровня подготовки ученика. На занятиях ребёнок знакомится с принципами работы нейросетей, учится формулировать запросы и использовать искусственный интеллект для решения учебных и творческих задач.

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

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

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

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

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

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

2. Алгоритмика

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

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

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

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

Особенности

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

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

3. Умназия

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

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

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

Что изучают

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

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

4. Skysmart

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

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

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

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

Преимущества

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

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

5. Hello World

Международная школа программирования Hello World предлагает детям обучение программированию, разработке игр, сайтов и приложений.

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

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

Преимущества

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

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

Что изучают на курсах ИИ для детей?

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

Нейросети и генеративный ИИ

Ребёнок знакомится с современными AI-инструментами и узнаёт, какие задачи они умеют решать.

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

Промптинг

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

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

Работа с информацией

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

Создание собственных проектов

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

Например, ребёнок может создать:

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

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

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

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

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

Необязательно ждать старших классов.

7–9 лет

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

10–13 лет

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

14–17 лет

Подросткам уже доступны более технические направления — Python, API, AI-приложения, автоматизация и разработка собственных проектов.

При этом возраст — не единственный критерий. Важно учитывать интересы и предыдущий опыт ребёнка.

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

Определите цель

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

Если интересует программирование, лучше искать курс, где ИИ объединён с Python или разработкой.

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

Посмотрите на практику

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

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

Уточните формат

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

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

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

Большой список AI-сервисов ещё не означает качественную образовательную программу.

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

Почему детям важно учиться работать с ИИ?

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

Обучение помогает сформировать несколько важных навыков:

Критическое мышление. Ребёнок учится проверять ответы нейросети.

Цифровую грамотность. Понимает, какие данные нельзя передавать AI-сервисам.

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

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

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

FAQ

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

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

Можно ли изучать ИИ онлайн?

Да. Онлайн-формат подходит для большинства программ по нейросетям и программированию.

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

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

С какого возраста подходят курсы ИИ?

Первые программы можно начинать примерно с 7–9 лет, а технические курсы чаще рассчитаны на подростков.

Нужно ли родителям разбираться в нейросетях?

Нет. Преподаватель объясняет ребёнку основные принципы работы с инструментами и показывает, как применять их в проектах.

Итоги

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

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

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

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

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

Сначала разделим деплой и релиз

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

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

Держите в фокусе четыре параметра:

1. какой именно артефакт попадает в среду;
2. какая доля запросов или пользователей видит изменение;
3. по каким сигналам выкладка продолжается или останавливается;
4. сколько времени занимает возврат к рабочей версии.

Время восстановления тоже нужно определить заранее. Например, отключение функции через флаг должно занимать не более 1–5 минут, возврат к предыдущей стабильной версии — до 15 минут. Для сбоев, затрагивающих базу данных или требующих ручного вмешательства, устанавливают отдельное целевое время восстановления — например, 30–60 минут. Эти значения служат отправной точкой: уточняйте их с учётом критичности сервиса, архитектуры и требований бизнеса.

Один артефакт для всех сред

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

С подобной проблемой столкнулись и мы в RWB. При непрерывной интеграции и доставке (CI/CD) пайплайны для разных сред запускались независимо. Из-за повторной сборки в прод мог попасть образ, который не проходил проверку на стейджинге.

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

Для прода в RWB добавили отдельное правило. Если пайплайн не находит ранее собранный образ, выкладка завершается ошибкой. Правило находится непосредственно в коде пайплайна.

После внедрения этого подхода RWB еженедельно пропускает около 700 сборок. Это 30% сборок с включённой фичей и 5% общего числа сборок через CI/CD. Главное — между тестированием и продом сохраняется один и тот же исполняемый код.

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

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

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

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

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

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

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

Метрики, которые останавливают релиз

Статус контейнера Running подтверждает только запуск процесса. Для решения о продолжении выкладки нужны сигналы нескольких уровней.

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

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

Feature flags управляют доступностью функции

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

Флаг не заменяет канареечную выкладку контейнера. Эти механизмы контролируют разные уровни:

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

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

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

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

Миграции данных требуют собственного плана отката

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

Для изменений, затрагивающих схему данных, применяют подход expand–migrate–contract:

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

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

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

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

Откат нужно репетировать

В рабочий сценарий нужно включить:

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

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

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

Минимальный набор перед первой управляемой выкладкой

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

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

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

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

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

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

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

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

Система управления проектами (Project Management System, PMS) — это программная среда, которая помогает компаниям планировать работу, распределять ресурсы, контролировать сроки и бюджеты, а также организовывать совместную работу команд для достижения конкретной бизнес-цели.

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

Отличие от таск-трекера

Это самое важное разграничение, на котором спотыкаются многие компании при покупке ПО.

• таск-трекер (Trello, Todoist, легкие версии Jira) — это инструмент для операционной работы. Он отвечает на вопрос: «Что мне нужно сделать сегодня?». Его горизонт планирования — одна-две недели. Это отличный выбор для микрокоманд, где достаточно перетаскивать карточки из колонки «В работе» в «Готово»;
• система управления проектами — это инструмент стратегического контроля. Она отвечает на вопросы: «Сколько стоит этот проект?», «Хватит ли нам инженеров на следующей неделе?», «Как задержка поставки оборудования повлияет на сроки сдачи объекта?». В таких системах есть диаграммы Ганта со сложными зависимостями, управление ресурсами (Capacity), финансовое планирование и контроль рисков.

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

Если вы узнаете в этих пунктах свою компанию, значит, время простых таск-трекеров и Excel безвозвратно ушло:

1. Проекты постоянно выходят за рамки бюджета. Вы не можете в реальном времени отследить, сколько денег (и часов сотрудников) уже потрачено на задачу, пока проект не завершится.
2. Ресурсный хаос. Одни сотрудники регулярно перерабатывают и выгорают, а другие простаивают, ожидая своей части работы. Руководители не могут предсказать загрузку отделов.
3. Зависимости ломают сроки. Если смежник задерживает сдачу своего этапа работы на два дня, вы не видите, как это автоматически сдвигает дедлайн всего большого проекта.
4. Срыв коммуникаций. Инструкции к задаче лежат в корпоративной Wiki, обсуждение идет в Telegram, а файлы пересылаются по почте. При подключении нового человека к проекту уходят дни на то, чтобы собрать весь контекст воедино.
5. Отчетность «на коленке». Чтобы собрать отчет для руководства о статусе портфеля проектов, проектным менеджерам (PM) приходится тратить часы, вручную сводя данные из разных источников.

Как мы составляли рейтинг систем управления проектами

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

Критерии оценки:

• функциональная глубина: наличие инструментов не только для Agile (спринты, канбан), но и для классического водопадного (Waterfall) управления (диаграмма Ганта, критический путь, вехи);
• архитектура и масштабируемость: способность системы не тормозить при тысячах активных пользователей и возможности кастомизации (наличие Low-code движка);
• безопасность и суверенитет: нахождение в Едином реестре российского ПО, возможность установки на серверы компании (On-premise), поддержка российских операционных систем;
• интеграционный потенциал: открытое API, готовые коннекторы к бухгалтерским (1С), кадровым и коммуникационным корпоративным системам;
• стоимость владения (TCO): мы учитывали не только цену лицензии, но и сложность внедрения и последующей поддержки.

Исключения: Из обзора сознательно исключены системы, официально покинувшие рынок РФ (Microsoft Project, Jira, Asana, Trello), так как их использование несет неприемлемые риски для стабильности бизнеса и противоречит требованиям ИБ.

Сводная таблица: системы проектного управления в цифрах

10 систем управления проектами в 2026 году

Перейдем к детальному разбору каждой платформы.

1. SimpleOne SDLC

Флагманская Enterprise-платформа SimpleOne SDLC создана для управления полным жизненным циклом разработки ПО и сложными бизнес-инициативами. Отличительная черта этой системы управления проектами — мощная Low-code архитектура, которая позволяет адаптировать систему под уникальные процессы компании, а не ломать процессы под софт.

Сильные стороны:

• единая экосистема: бесшовная связь процессов разработки с ИТ-поддержкой (ITSM) на одной платформе. Инциденты напрямую превращаются в задачи для разработчиков;
• гибкость Low-code: настройка рабочих процессов, форм и статусов выполняется аналитиками визуально, что радикально ускоряет внесение изменений (Time-to-Market);
• глубокая интеграция с кодом: нативная связка с системами контроля версий (GitLab, Bitbucket). Статусы задач обновляются автоматически на основе коммитов разработчиков;
• высокая отказоустойчивость: архитектура спроектирована под высокие конкурентные нагрузки корпоративного масштаба.

Ограничения:

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

Реалистичная стоимость: рассчитывается индивидуально под проект (Enterprise-модель лицензирования).

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

2. Kaiten

Российский визуальный трекер задач Kaiten сделал ставку на идеологию Kanban и максимальную прозрачность процессов. Этот инструмент отлично подходит для продуктовых команд, работающих по гибким Agile-методологиям.

Сильные стороны:

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

Ограничения:

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

Реалистичная стоимость: облачная версия от 185 руб. за пользователя в месяц в тарифе «Старт» (до 15 пользователей), тариф «Бизнес» с неограниченным количеством пользователей от 580 руб/мес за пользователя.

Вердикт: подходит, если вы Agile-команда, продуктовая студия или маркетинговое агентство, и вам важна скорость и наглядность. Не подходит, если вы строите завод и вам нужны сложные бюджеты и диаграммы Ганта на 5000 строк.

3. Битрикс24

Корпоративный мега-комбайн Битрикс24 объединяет в себе всё: от системы управления проектами до CRM, конструктора сайтов и внутрикорпоративного мессенджера. Это самая массовая и узнаваемая система в малом и среднем бизнесе РФ.

Сильные стороны:

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

Ограничения:

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

Реалистичная стоимость: Облако от 1 743 руб/мес (за 5 человек). Коробочная версия от 109 000 руб.

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

4. ПланФикс

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

Сильные стороны:

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

Ограничения:

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

Реалистичная стоимость: от ~300 до 900 руб. за пользователя в месяц. Оплата номинирована в евро с конвертацией — при жёстких требованиях к реестру РФ и импортонезависимости уточняйте актуальный статус продукта у вендора.

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

5. Directum Projects

Корпоративная система Directum Projects от известного российского вендора СЭД глубоко интегрирует классическое проектное управление с жизненным циклом юридически значимых документов.

Сильные стороны:

• документооборот: глубокий контроль проектной документации — версионирование, ЭЦП, сложные маршруты согласований договоров и смет;
• методология PMBOK: строгое следование классическим стандартам проектного управления;
• безопасность: высочайший уровень ИБ, наличие сертификатов ФСТЭК, что критично для КИИ и госсектора.

Ограничения:

• система ориентирована на «водопадное» (Waterfall) планирование, функционал для Agile-команд присутствует скорее в базовом виде;
• консервативный «корпоративный» интерфейс, который может отпугнуть молодую аудиторию.

Реалистичная стоимость: рассчитывается индивидуально (поставка On-premise).

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

6. ADVANTA

Классическая российская платформа ADVANTA предназначена для управления портфелями проектов (PPM). Исторически она создавалась для руководителей высшего звена, чтобы они могли контролировать сроки и инвестиции по модели «сверху вниз».

Сильные стороны:

• финансовый контроль: отличный функционал для учета бюджета проекта (Capex/Opex), планирования затрат и расчета рентабельности;
• верхнеуровневая аналитика: дашборды со «светофорами» статусов проектов, позволяющие генеральному директору оценить здоровье портфеля за секунды;
• управление ресурсами: глубокие инструменты для планирования загрузки специалистов в масштабах компании.

Ограничения:

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

Реалистичная стоимость: Облако от ~4 500 ₽/польз./мес. Внедрение на сервер (On-premise) — по запросу.

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

7. YouGile

Легкая облачная система YouGile позиционируется как удобный гибрид Agile-доски и корпоративного мессенджера. Главный фокус в ней сделан на бесшовную и прозрачную коммуникацию команды.

Сильные стороны:

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

Ограничения:

• отсутствует сложная автоматизация бизнес-процессов.
• не потянет масштабное планирование ресурсов или бюджетирование.

Реалистичная стоимость: бесплатно до 10 пользователей. Далее от 594 руб. за пользователя в месяц.

Вердикт: подходит, если вы небольшая веб-студия, рекламное агентство или стартап, где скорость общения важнее сложных регламентов. Не подходит, если вы строите Enterprise-архитектуру.

8. Мегаплан

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

Сильные стороны:

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

Ограничения:

• специфический функционал для ИТ-разработки (интеграция с Git, спринты) практически отсутствует;
• интерфейс развивается медленнее, чем у более молодых и гибких конкурентов.

Реалистичная стоимость: тариф «Базовый» от 315 руб. за пользователя в месяц (облако). Есть On-premise версии.

Вердикт: подходит, если вы компания сферы услуг или торговли сегмента СМБ, и вам нужно в одном окне вести клиентов и контролировать выполнение поручений сотрудниками. Не подходит, если вы технологическая ИТ-компания.

9. Аспро.Cloud

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

Сильные стороны:

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

Ограничения:

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

Реалистичная стоимость: от 2390 руб/мес за пакет на 5 пользователей.

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

10. Yandex Tracker

Мощный сервис для управления задачами Yandex Tracker был создан в недрах Яндекса для собственных нужд, а затем выпущен на публичный рынок в рамках надежной экосистемы Yandex Cloud.

Сильные стороны:

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

Ограничения:

• специфический UX: логика работы с «очередями» задач и уникальная терминология требуют времени на адаптацию, особенно для пользователей, не связанных с ИТ;
• слабо развит функционал классического финансового проектного управления (бюджетирование).

Реалистичная стоимость: автономное использование (без Яндекс 360) обойдется в 440 руб. за пользователя. При подключении в качестве опции к бизнес-пакетам стоимость варьируется от 569 до 1539 руб. в месяц за рабочее место.

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

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

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

1. Определите свою методологию. Вы строите дома или пишете софт? Для первых нужен жесткий Waterfall (Диаграмма Ганта, ADVANTA, Directum). Для вторых — Agile (Scrum/Kanban, SimpleOne SDLC, Kaiten).
2. Где должны храниться данные? Если у вас строгая служба информационной безопасности и данные нельзя выносить за пределы компании — сразу отсеивайте SaaS-only решения. Ищите системы с вариантом установки On-premise (SimpleOne, ADVANTA).
3. Оцените необходимость интеграций. Проектная система не должна быть «островом». Если вы разрабатываете ИТ-продукты, вам критически важно, чтобы система нативно интегрировалась с Git-репозиториями и внутренним Service Desk.
4. Проверьте возможности масштабирования. То, что отлично работает на 20 человек, «ляжет» на 500. Выбирайте платформы с Low-code архитектурой, которые можно будет адаптировать под новые бизнес-процессы без покупки нового софта.
5. Запросите демо и пилот. Никогда не покупайте систему по картинкам в презентации. Возьмите тестовый период, заведите реальный проект и попросите команду поработать в ней неделю.

Выводы

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

1. Отталкивайтесь от методологии, а не интерфейса. Для проектов со строгой сметой и сроками (стройка, промышленность) выбирайте классические PPM-системы с сильным Гантом (ADVANTA, Directum). Для ИТ-команд — трекеры с фокусом на Agile (SimpleOne SDLC, Kaiten).
2. Считайте совокупную стоимость владения (TCO). Недорогая облачная подписка может обернуться миллионными тратами на кастомизацию кода. Для среднего и крупного бизнеса Low-code платформы (например, SimpleOne или ПланФикс) оказываются выгоднее на дистанции, так как позволяют менять процессы силами аналитиков.
3. Оценивайте требования безопасности на берегу. Если ваша компания работает с КИИ, гостайной или имеет строгие регламенты ИБ, сразу отсекайте SaaS-only решения. Ищите продукты с возможностью On-premise развертывания из реестра отечественного ПО.
4. Смотрите на перспективу. Инструмент должен расти вместе с вами. Для растущего Enterprise-сегмента оптимальны платформы, способные объединить разрозненные команды — от разработки до техподдержки — в едином прозрачном контуре.

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

Что такое Wanttopay: карта, эмитент, BIN

Wanttopay — финтех-сервис компании WTP Technology Limited из Гонконга. Это не банк: сервис не открывает счета и не хранит вклады, а выпускает виртуальные карты через банк-эмитент и дает интерфейс для управления ими. Карта существует только в виде реквизитов — номер, срок, трехзначный код CVC и биллинг-адрес, — которые вводятся в платежную форму сервиса так же, как реквизиты любой пластиковой карты.

Валюта карты — доллар США. Деньги лежат на ней в долларах, и когда сервис списывает доллары, конвертации нет. Если счет выставлен в евро или другой валюте, конвертацию делает эмитент по своему курсу.

Почему это работает, объясняется одним словом — BIN. Это первые шесть-восемь цифр номера карты, по которым платежная система понимает, какой банк и из какой страны ее выпустил. Часть иностранных сервисов принимает карты не всех стран, и карта с иностранным BIN эту проверку проходит. У карт Wanttopay BIN зависит от конкретной карты: у тарифа Smart условия прямо указывают регион выпуска — США; у Prepaid и Easy встречаются карты с сингапурским BIN, что видно по списку протестированных сервисов, где для этих тарифов подтверждены App Store и Spotify в регионе Singapore. Страна вашей карты видна в реквизитах после выпуска, и от нее зависит, какой регион ставить в аккаунтах сервисов.

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

Тарифы Prepaid, Easy и Smart: лимиты и комиссии

У сервиса три тарифа, различаются они лимитом на траты, поддержкой оплаты телефоном и размером комиссии за операцию.

Prepaid: бесплатный выпуск с оговорками

Выпуск не стоит ничего, ежемесячной платы нет. Но карта активируется только с депозитом от $10, из каждого пополнения $1 резервируется на покрытие комиссий, а $0,25 списывается за каждую операцию, включая отклоненные. Пополнять можно на фиксированные суммы от $10 до $150.

Ограничения важнее цены. Активация пробных периодов и промокодов с Prepaid не гарантируется — у ChatGPT и Perplexity в списке сервисов прямо стоит пометка, что бесплатный триал с карт не активируется. Условия запрещают игры и донаты, а часть магазинов и сервисов — Adobe, LinkedIn, Uber, Shopify — может заблокировать карту на стороне эмитента. Через 24 месяца карта удаляется вместе с остатком, возврат средств не предусмотрен. Для разовой покупки или годовой подписки, которую вы оплатите один раз, тариф подходит; для ежемесячных автосписаний — нет.

Easy: карта под подписки

Стоит 990 рублей или $10, лимит $4 000 в месяц, пополнение от $4 до $5 000 за раз, комиссия $0,25 за операцию, только онлайн-платежи. Это тариф под связку «ChatGPT плюс YouTube Premium плюс облако»: три-четыре подписки, привязанные один раз. Требует активной подписки Plus, без нее карта замораживается.

Smart: большие суммы и оплата телефоном

Стоит 1 590 рублей или $15, лимит $50 000 в месяц, срок 36 месяцев, добавляется в Apple Pay, Google Pay и Samsung Pay. Оплата телефоном не работает в РФ и других странах под санкционными ограничениями — так записано в условиях тарифа, поэтому смысл в ней есть для поездок. Комиссия $0,50 за операцию плюс 0,2% при бесконтактной оплате. Smart нужен в трех случаях: платежи выше $4 000 в месяц, путешествия и сервисы, которые подтверждены только на нем — Booking.com, Airbnb-конкуренты вроде Trip.com, Discord, Cloudflare, Facebook Ads.

Подписка Plus: как считается и что без нее

Обслуживание Easy и Smart оплачивается подпиской Plus: 6 USDT или 690 рублей за 30 дней; при оплате на 3, 6 или 12 месяцев — 1 860, 3 310 и 4 100 рублей соответственно, то есть годовая обходится примерно в 340 рублей в месяц. Одна подписка покрывает все карты пользователя.

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

Почему платеж отклоняют: BIN, страна эмитента, биллинг

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

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

Второй — на уровне проверок конкретного сервиса, и здесь иностранный BIN сам по себе не помогает. Сервис может сверять страну карты, биллинг-адрес, регион аккаунта и страну, из которой вы подключаетесь, и требовать совпадения. База знаний Wanttopay приводит примеры: App Store и Claude требуют, чтобы страна карты совпадала с платежными данными аккаунта. Биллинг-адрес выдается вместе с картой и виден в ее карточке — его и указывают в платежном профиле, а регион аккаунта у требовательных сервисов выставляют по стране карты.

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

Верификация: что проверяет Sumsub и сколько это занимает

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

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

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

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

Как открыть карту и оплатить первый сервис

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

1. Открыть мини-приложение через бота WantToPayBot или по ссылке с сайта Wanttopay, указать почту.
2. Подтвердить номер телефона. Приложение отправляет код само; если не сработало, код приходит в отдельный бот Verification Codes.
3. Пройти верификацию: страна, тип документа, фото, селфи.
4. Выбрать тариф: Easy под подписки, Prepaid под разовую покупку, Smart под большие суммы или поездки.
5. Оплатить выпуск и внести депозит. Способы пополнения перечислены в разделе «Главная» мини-приложения; реквизиты для каждого пополнения одноразовые, повторный перевод по старым реквизитам не зачисляется и не возвращается. Деньги приходят обычно сразу, в отдельных случаях до трех часов.
6. Открыть карточку карты, скопировать номер, срок, CVC и биллинг-адрес.
7. В ChatGPT: Settings → Subscription → Upgrade, ввести реквизиты, в поле адреса — биллинг-адрес карты, страну — по стране карты. Валюту, если сервис дает выбор, оставить доллары.
8. Подтвердить платеж кодом 3-D Secure, который придет в чат бота. Проверить списание в разделе «Транзакции» мини-приложения.

Как пополнить карту Wanttopay дальше: карточка карты → «Пополнить» → способ из списка. Курс пополнения показывается до подтверждения, и именно в нем основная переплата, поэтому смотреть его стоит каждый раз. На балансе нужно держать сумму списания плюс комиссию: для подписки за $20 на Easy — не меньше $20,25.

Что можно оплатить: проверенные сервисы

Ниже — выборка из списка протестированных сервисов Wanttopay на дату написания. «Подтверждено» означает, что сервис проверял оплату и по многим позициям ведет инструкцию; отсутствие в списке не значит, что платеж не пройдет, но гарантий нет.

Нейросети

— ChatGPT — все три тарифа; пробный период с карт не активируется;

— Claude — все три тарифа; страна карты должна совпадать с данными аккаунта;

— Midjourney, Suno, Runway, ElevenLabs — все три тарифа;

— Perplexity — все три тарифа; пробный период с карт не активируется.

Видео, музыка, приложения

— YouTube Premium, Google One, Google Play — все три тарифа;

— Spotify Premium — Prepaid и Easy в регионе Singapore; на Smart не проходит;

— App Store — Prepaid и Easy в регионе Singapore, Smart в регионах USA и Hong Kong; есть инструкция по смене региона;

— Amazon Prime Video, Tidal — только Smart;

— Discord — только Smart;

— Netflix в списке протестированных отсутствует.

Авторы и контент

— Patreon, Gumroad — все три тарифа.

Работа и учеба

— Canva, Figma, Zoom — все три тарифа;

— JetBrains, Cursor, OpenAI API — все три тарифа; пригодится разработчикам;

— Udemy, Dropbox, Cloudflare — только Smart.

Путешествия

— Airbnb — все три тарифа;

— Booking.com, Trip.com, Airalo — только Smart.

Игры

— Brawl Stars, Genshin Impact, Epic Games Store, PlayStation Store — картами не оплачиваются ни на одном тарифе;

— для Steam, PlayStation, Nintendo и Roblox у сервиса есть отдельные подарочные карты, для покупки которых достаточно почты и подтвержденного номера телефона.

Две подсказки из этого списка. Первая: регион имеет значение. Одну и ту же подписку Spotify или App Store на Prepaid и Easy оплачивают в регионе Singapore, а на Smart — в USA или Hong Kong; это следствие разного BIN у карт. Вторая: если нужного сервиса в списке нет, начните с Prepaid на $10–20 — прошел платеж, значит можно переносить подписку на Easy.

Что делать, когда сервис вернул отказ

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

#D001 — недостаточно средств. На карте должна быть сумма платежа плюс комиссия. Пополнить и повторить один раз; не нажимать «оплатить» несколько раз подряд.

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

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

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

Если код не подходит ни под один случай, есть поддержка в Telegram: отдельный бот WantToPaySupportBot, с 08:00 до 22:00 по московскому времени. На части страниц сайта еще указаны старые часы, 07:00–00:00; актуальные — в условиях тарифов, и поддержка их подтвердила.

Антифрод, блокировки и внутренний баланс

Три механизма на стороне сервиса, о которых лучше знать заранее.

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

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

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

Сколько стоит карта в год: расчет на ChatGPT и Midjourney

Возьмем типичную связку: ChatGPT Plus за $20 и Midjourney за $10 в месяц, обе подписки на одной карте Easy.

Выпуск — 990 рублей один раз. Plus на 12 месяцев — 4 100 рублей. Списаний за год — 24, по $0,25 каждое — $6. Пополнения — $360 за год по внутреннему курсу сервиса. Итого фиксированные расходы — 5 090 рублей и $6 сверх самих подписок, при курсе на дату написания это около 16% от $360. Если добавить на ту же карту YouTube Premium и облако, доля фиксированных расходов падает пропорционально: карта дешевеет с каждой подпиской на ней.

Альтернатива — Prepaid без Plus: 0 рублей за выпуск, но карта не рассчитана на автосписания, а $1 резерва и $0,25 за операцию остаются. Она выигрывает только в сценарии «оплатить годовую подписку один раз и забыть».

Что стоит знать о правилах

Карта Wanttopay — электронное средство платежа иностранного сервиса, а не счет в иностранном банке. Уведомлять налоговую об открытии не требуется; отчет о движении средств нужен, только если зачисления за год превысили 600 000 рублей — для пары подписок это неактуально. Сервис — не банк, и деньги на карте не застрахованы АСВ, так что хранить на ней запас на год не нужно.

Если карту берет ИП или компания под рабочие сервисы, есть два дополнительных вопроса к бухгалтеру: иностранный сервис выдаст только инвойс, а не счет-фактуру, и покупка электронных услуг у иностранного поставщика тянет обязанность по НДС (с 2026 года ставка 22%), которую оплата с личной карты не снимает.

Отзывы: что пишут и где проверять

Запрос «wanttopay отзывы» — второй по частоте после названия сервиса. Отзывы есть на Otzovik и Trustpilot, в агрегаторах CRMindex и Partnerkin, на banki.ru, на VC — там и разборы, и жалобы. Типичные плюсы — скорость выпуска и поддержка; типичные минусы — отказы у конкретных сервисов и курс пополнения.

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

Частые вопросы

Wanttopay — что это за сервис

Финтех-компания из Гонконга, выпускающая долларовые виртуальные карты после проверки личности. Управление — в мини-приложении Telegram. Карта для онлайн-оплаты у иностранных сервисов и магазинов; хранить деньги и выводить их с нее нельзя.

Wanttopay net или wanttopay ru — какой сайт настоящий

Официальный домен — wanttopay.net; он указан в условиях использования, на него ведут ссылки из мини-приложения. Домены .ru и .org в выдаче встречаются, их принадлежность сервису мы не проверяли. Открывайте мини-приложение через официального бота или по ссылке с основного сайта.

Одинаковая ли верификация на разных тарифах

Да. Процедура и требования к документам не зависят от тарифа; это подтверждает поддержка сервиса.

Какой у карты BIN — США или Сингапур

Зависит от карты. У Smart регион выпуска — США по условиям тарифа; у Prepaid и Easy встречаются сингапурские BIN. Страна карты видна в реквизитах после выпуска, по ней и выставляется регион в аккаунтах сервисов.

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

Да, в пределах лимита тарифа: $1 000 у Prepaid, $4 000 у Easy, $50 000 у Smart. Подписка Plus при этом одна на все карты.

Активируется ли пробный период ChatGPT

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

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

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

Как отвязать карту от сервиса

В настройках оплаты самого сервиса. Условия Wanttopay обязывают отвязывать карту от неиспользуемых сервисов; оставлять ее пустой в расчете на отказы нельзя — три отказа подряд заблокируют карту.

Можно ли пополнить карту криптовалютой

Да, криптовалюта — один из способов пополнения баланса; доступные варианты показаны в мини-приложении. На пополняемых тарифах за такое пополнение берется комиссия, ее размер указан в условиях тарифа. Сама карта остается долларовой.

Работает ли Apple Pay

Только на Smart и только за пределами РФ. Prepaid и Easy — исключительно онлайн.

Что будет с деньгами, если карту заблокирует антифрод

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

Итог

Wanttopay подходит, если нужна одна долларовая карта под три-пять подписок у иностранных сервисов, с подтвержденным списком того, что она оплачивает, 3-D Secure и внятной документацией по отказам. Правильный тариф под эту задачу — Easy с Plus на год; Prepaid — под разовую покупку или годовую подписку; Smart — если суммы выше $4 000 в месяц, вы едете за границу или ваш сервис подтвержден только на нем.

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

Цены и условия актуальны на сентябрь 2026 года. Перед оформлением проверяйте актуальные тарифы на сайте WantToPay — условия сервиса могут меняться.

Материал подготовлен в ознакомительных целях и не является руководством к действию или финансовой рекомендацией. Сайт не несет ответственности за ваши финансовые решения.

Реклама. Рекламодатель: ИП Изюк Валерия Олеговна ИНН 621904482944, erid: 2W5zFHDSz2V.

Но пользоваться нейросетью и понимать, как с ней работать, — разные вещи. Ребенку важно научиться составлять понятные запросы, проверять ответы AI, соблюдать правила цифровой безопасности и использовать искусственный интеллект не для бездумного копирования, а для создания собственных проектов.

Поэтому обучение ИИ в 2026 году становится отдельным образовательным направлением. Школы предлагают программы для разного возраста: от знакомства с генеративными инструментами до создания сайтов, игр, чат-ботов и приложений с искусственным интеллектом.

В этой статье собрали топ-5 школ с ИИ для детей и сравнили их программы, возраст, формат обучения и практические результаты.

Как выбирали школы?

В рейтинг вошли образовательные организации, у которых есть отдельные программы по искусственному интеллекту, нейросетям или использованию AI-инструментов.

При сравнении учитывали:

• возраст учеников;
• содержание программы;
• формат занятий;
• продолжительность;
• наличие преподавателя или наставника;
• количество практики;
• итоговые проекты;
• возможность пройти пробное занятие;
• стоимость, если она указана в открытом доступе.

Рейтинг не означает, что одна школа подходит абсолютно всем детям. Для младшего школьника и подростка, который уже программирует на Python, задачи будут разными.

Топ-5 школ с ИИ для детей

1. Pixel

Pixel — школа программирования для детей и подростков, где искусственный интеллект изучается не только как отдельный инструмент, но и в связке с созданием игр, приложений и других цифровых проектов.

Для детей 9–14 лет есть курс «Roblox Studio с ИИ». На занятиях ученики создают собственные игры в Roblox Studio, изучают основы программирования на Lua, работают с 3D-объектами, игровыми механиками, текстурами и эффектами.

ИИ используется как помощник разработчика: с его помощью ученики придумывают игровые идеи, создают визуальные элементы, получают подсказки по коду и учатся находить ошибки. При этом ребёнок не просто копирует готовые решения, а разбирается в логике программного обеспечения и самостоятельно применяет его в своих проектах.

Программа включает три модуля: от знакомства с Roblox Studio и создания первых игровых объектов до разработки сложных механик, системы очков, сохранения данных, GamePass и подготовки собственной игры к публикации в Roblox.

Занятия проходят онлайн в Zoom. Курс рассчитан на детей с разным уровнем подготовки: начать можно без опыта программирования. Обучение построено вокруг практики — каждый ученик постепенно создаёт собственные игровые проекты и видит результат своей работы.

Стоимость обучения начинается от 800 рублей за занятие. Предусмотрено бесплатное пробное занятие, на котором ребёнок сможет познакомиться с Roblox Studio и попробовать создать первые элементы игры.

Преимущества: сочетание Roblox Studio, программирования на Lua и ИИ, обучение через создание собственных игр, постепенное усложнение заданий, возможность подготовить проект к публикации.

Кому подойдет: детям 9–14 лет, которые любят Roblox и хотят не только играть, но и создавать собственные игры, изучать программирование и использовать искусственный интеллект как инструмент разработчика.

2. Алгоритмика

Алгоритмика — международная школа программирования для детей, где цифровые технологии изучаются через практические задания и создание собственных проектов.

В зависимости от возраста ребенок может познакомиться с основами алгоритмического мышления, визуальным программированием, разработкой игр и более сложными языками программирования. Элементы искусственного интеллекта используются при работе с современными цифровыми инструментами и проектами.

Для младших школьников обучение строится в игровой форме. Дети создают простые интерактивные истории, персонажей и игровые сценарии. Подростки могут переходить к Python, веб-разработке и созданию приложений.

Занятия доступны онлайн и в офлайн-классах. Формат зависит от города и выбранной программы.

Преимущества: международная методика, постепенное усложнение материала, много практики, возможность продолжать обучение несколько лет.

Кому подойдет: детям, которым важно последовательно развивать навыки программирования и постепенно переходить к проектам с использованием ИИ.

3. Умназия

Умназия предлагает онлайн-обучение для детей, направленное на развитие логики, цифровой грамотности и навыков работы с современными технологиями.

В программах, связанных с искусственным интеллектом, ребенок знакомится с принципами работы нейросетей, учится формулировать запросы и использовать AI-инструменты для учебных и творческих задач.

Большое внимание уделяется самостоятельному мышлению. Школьник не просто получает готовый ответ от нейросети, а учится анализировать информацию, находить ошибки и выбирать подходящий способ решения.

Занятия проходят онлайн, а задания можно выполнять в удобном темпе. Такой формат подходит детям, которым комфортнее заниматься самостоятельно при поддержке образовательной платформы.

Преимущества: развитие логики, онлайн-формат, задания для разных возрастов, акцент на цифровую грамотность.

Кому подойдет: младшим школьникам и подросткам, которым нужно спокойное знакомство с ИИ без сложного программирования.

4. Skysmart

Skysmart предлагает детям и подросткам курсы по программированию, цифровому творчеству и современным технологиям.

В зависимости от выбранного направления школьники могут изучать нейросети, создавать изображения и тексты, разрабатывать игры, сайты и приложения. Более старшие ученики знакомятся с Python и другими инструментами разработки.

Занятия проходят онлайн с преподавателем. Ученик получает задания, выполняет практические проекты и может задавать вопросы во время урока.

Программы рассчитаны на разные уровни подготовки. Начинающие знакомятся с основами цифровых технологий, а более опытные школьники могут переходить к созданию сложных проектов.

Преимущества: индивидуальные занятия, широкий выбор IT-направлений, преподавательская поддержка, практические задания.

Кому подойдет: детям и подросткам, которые хотят изучать ИИ вместе с программированием, дизайном или созданием цифрового контента.

5. Международная школа программирования Hello World

Hello World обучает детей программированию, созданию игр, сайтов и приложений. В отдельных программах искусственный интеллект используется как инструмент для разработки и работы с цифровым контентом.

Младшие школьники могут начинать с визуальных сред и простых игровых проектов. Подростки переходят к Python, веб-разработке и созданию собственных приложений.

На занятиях ребенок не только изучает теорию, но и постепенно собирает портфолио из готовых работ. В AI-проектах школьники могут создавать чат-ботов, генераторы контента и интерактивные приложения.

Обучение доступно онлайн и очно. Формат зависит от города, возраста и выбранного курса.

Преимущества: проектное обучение, программирование и ИИ в одной программе, портфолио, разные уровни сложности.

Кому подойдет: детям, которые хотят не просто пользоваться нейросетями, а применять их при создании игр, сайтов и приложений.

Чем отличается обучение ИИ для детей разного возраста?

Возраст сильно влияет на содержание курса.

7–10 лет

В этом возрасте лучше подходят визуальные и творческие задачи. Ребенок может создавать изображения, персонажей, простые истории и игровые проекты.

Главная цель — показать возможности технологии и сформировать безопасные привычки работы с нейросетями.

10–13 лет

Можно переходить к более сложным задачам: чат-ботам, созданию сайтов, игр и первым программным проектам.

Здесь уже появляется смысл объединять ИИ и программирование.

14–17 лет

Подростки могут изучать Python, API, AI-приложения, автоматизацию и другие технические направления.

Если школьник планирует связать будущее с IT, искусственный интеллект можно изучать не только как инструмент, но и как технологию разработки.

Что изучают на курсах ИИ?

Несмотря на различия между школами, программы обычно включают несколько общих тем.

Промптинг. Ребенок учится формулировать запросы так, чтобы получать более полезные результаты.

Генерация контента. Школьники работают с текстом, изображениями, видео, музыкой и другими форматами.

AI-проекты. Нейросети становятся частью более крупной работы — сайта, игры, чат-бота или приложения.

Проверка информации. Ребенок узнает, что ответ нейросети не всегда является правильным.

Цифровая безопасность. Важно понимать, какие личные данные нельзя передавать AI-сервисам и почему нельзя бездумно использовать сгенерированный контент.

Как выбрать школу с ИИ для ребенка?

Определите интерес ребенка

Если школьнику нравятся рисунки, видео и творчество, выбирайте программу с генеративными нейросетями.

Если интересует программирование — смотрите на курсы Python и ИИ.

Если ребенок хочет создавать сайты, игры или приложения, ищите программы с практическими AI-проектами.

Проверьте уровень подготовки

Не каждому школьнику нужен сложный технический курс.

Для первого знакомства достаточно курса без программирования. А подростку с опытом Python может быть интереснее работа с API и создание собственных приложений.

Посмотрите на итоговые проекты

Один из лучших вопросов школе:

«Что ребенок сможет создать после курса?»

Если программа предполагает несколько законченных проектов, родителям проще оценить практическую ценность обучения.

Сравните формат

Индивидуальные занятия позволяют подстраивать темп под одного ученика.

Группа может быть интереснее ребенку, которому нравится взаимодействовать со сверстниками.

Записанный курс подойдет самостоятельным школьникам, но здесь особенно важна мотивация.

Не ориентируйтесь только на сертификат

Сертификат может быть приятным дополнением, но сам по себе не показывает уровень навыков.

Гораздо важнее, умеет ли ребенок самостоятельно использовать нейросети и создавать с их помощью реальные проекты.

FAQ

С какого возраста можно изучать искусственный интеллект?

Некоторые программы подходят детям уже с 7–9 лет. Более технические курсы обычно рассчитаны на школьников среднего и старшего возраста.

Нужно ли знать Python для обучения ИИ?

Нет. Для промптинга и генеративных нейросетей программирование не требуется. Python понадобится, если ребенок захочет перейти к созданию собственных AI-приложений.

Можно ли изучать ИИ онлайн?

Да. Большинство современных программ доступны онлайн. Можно выбрать группу, индивидуальные занятия или формат с видеоматериалами.

Что лучше: короткий курс или длительная программа?

Для знакомства с темой достаточно короткого курса. Если ребенок хочет создавать полноценные проекты и развиваться в IT, лучше выбрать длительную программу.

Какие проекты ребенок может сделать с помощью ИИ?

Это могут быть изображения, комиксы, мультфильмы, сайты, игры, чат-боты, виртуальные помощники и приложения.

Нужно ли проверять ответы нейросети?

Обязательно. Нейросеть может ошибаться или создавать недостоверную информацию. Один из важных навыков обучения ИИ — критически оценивать результат.

Как понять, подходит ли ребенку курс?

Лучше всего воспользоваться пробным занятием, если оно предусмотрено. После него стоит оценить интерес ребенка, понятность объяснений и желание продолжать.

Итог

Обучение ИИ в 2026 году уже не ограничивается знакомством с отдельными чат-ботами. Детские школы постепенно переходят к проектному формату, где нейросети становятся инструментом для создания игр, сайтов, изображений, чат-ботов и приложений.

При выборе курса важно учитывать возраст и интересы ребенка. Для младших школьников подойдет творческое знакомство с AI, для детей среднего возраста — проекты и первые программные задачи, а подросткам можно предлагать Python, API и разработку собственных AI-приложений.

В нашем топ-5 школ с ИИ для детей представлены разные подходы: от индивидуального обучения нейросетям до серьезного сочетания искусственного интеллекта и программирования.

Главное — выбрать не просто курс, где ребенок научится пользоваться несколькими нейросетями, а программу, после которой он сможет самостоятельно применять ИИ, проверять полученные результаты и создавать собственные проекты.

Отдельно проверим доступность приложений и управляющего API. Если обновление включает перезапуск etcd, выполняющиеся запросы к API server могут зависнуть на это время, даже после drain узла.

Команды проверки и изменения конфигурации разнесены по этапам: сначала собираем сведения, затем готовим приложения и только после этого обновляем компоненты.

Сначала расставим границы обновления

У Kubernetes несколько компонентов с собственными версиями. API server принимает запросы управления, kubelet запускает контейнеры на конкретном узле, а kubeadm помогает собирать и обновлять кластер. Поэтому перед работой нужно установить, какие версии сейчас используются и каким способом создано окружение.

Начните с команды, которая покажет версии клиента kubectl и сервера:

В выводе ищите Client Version и Server Version. Это ещё не инвентаризация всех узлов: версия сервера описывает ту часть системы, к которой обратился клиент. Версии kubelet на всех узлах покажет следующая команда:

В столбце VERSION указаны версии kubelet, в STATUS ожидается Ready. Сохраните этот вывод для сравнения после обновления.

Официальный гайд kubeadm рассчитан на переход 1.36.x → 1.37.x. Если кластер старше, подготовьте последовательность промежуточных обновлений. Для EKS, GKE, AKS и других управляемых сервисов понадобится процедура провайдера: команды обслуживания самостоятельно установленного control plane нельзя автоматически переносить в managed-окружение.

Во время перехода разные версии компонентов допустимы в определённых пределах. Например, kubelet не должен быть новее API server. Когда в отказоустойчивом кластере одновременно работают API server 1.36 и 1.37, обновлять kubelet до 1.37 ещё рано. Совместимость должна сохраняться с обоими серверами. Поэтому следуйте порядку действий: сначала управляющие компоненты, потом рабочие узлы.

Зафиксируйте исходное состояние в плане работ. Для каждого этапа укажите узел, целевую версию и проверку, после которой можно продолжать, особенно, если обновление выполняют несколько человек или оно занимает несколько окон обслуживания.

Какие static Pods перестанут запускаться

Обычный Pod создаётся через Kubernetes API. Static Pod запускается kubelet по локальному описанию на узле. Это позволяет поднимать компоненты, которые нужны для работы самого API server. В кластерах kubeadm таким способом запускаются компоненты control plane.

Static Pods изначально не предназначались для чтения объектов API, однако ошибка позволяла некоторым ссылкам на Secrets и ConfigMaps работать. В 1.37 это поведение окончательно запрещено: feature gate PreventStaticPodAPIReferences, позволявший отключить ограничение, удалён. Проблема возникает у Pod с такими ссылками, а не у любого Pod, использующего секрет.

Проверьте каталог, из которого kubelet читает static-манифесты. В конфигурации kubelet его задаёт staticPodPath; для типового kubeadm-окружения в рассмотренных материалах используется /etc/kubernetes/manifests/. Если у вас другой путь, проверять нужно именно его.

Особое внимание уделите полям configMapRef, secretRef, configMapKeyRef и secretKeyRef. Найденные ссылки требуют разбора: какой компонент читает значение, почему он запускается как static Pod и как предоставить ему конфигурацию до появления API server. Проверка должна охватывать и шаблоны, из которых вы создаёте новые узлы. В разборе devs group найдёте варианты исправления: предоставить компоненту локальный файл через hostPath или перенести подходящую нагрузку в DaemonSet. Выбор зависит от того, нужен ли компонент для запуска самого control plane.

В официальном руководстве есть ещё одна полезная деталь: kubelet читает файлы static-манифестов независимо от расширения. Если оставить рядом с рабочим файлом копию с окончанием .backup, она тоже может попасть в обработку. Поэтому резервные копии храните вне каталога static Pods. .

Какие параметры помешают запуску kubelet

В 1.37 обновлён встроенный cAdvisor, который собирает статистику контейнеров. Часть его старых флагов больше не принимается. Если они передаются kubelet при запуске, процесс завершается с ошибкой. Среди удалённых параметров есть --containerd, --boot-id-file, --machine-id-file, --global-housekeeping-interval и семейство --storage-driver-*. Из прежних флагов cAdvisor сохранён --housekeeping-interval.

Проверьте, как запускается служба: изучите systemd unit, файл /var/lib/kubelet/kubeadm-flags.env и /etc/default/kubelet. Набор мест зависит от установки: unit может подхватывать параметры из другого файла. Поэтому просмотр одного unit ещё не означает, что все аргументы найдены.

В выводе смотрите, откуда служба получает аргументы и переменные окружения. Сопоставьте найденные параметры с полным списком удалённых флагов в changelog. Название --containerd здесь относится к старому параметру cAdvisor; по нему нельзя делать вывод, что сам runtime containerd требуется удалить.

После изменения конфигурации проверьте перезапуск службы на тестовом узле. Исправление должно попасть и в систему, которая формирует конфигурацию следующих узлов, иначе при расширении кластера проблема вернётся. Это следует из различия между исправлением работающей машины и исправлением шаблона её создания.

Отдельно проверьте панели и правила оповещений, завязанные на cAdvisor. В 1.37 исчезают серии container_cpu_load_average_10s, container_cpu_load_d_average_10s и container_tasks_state. Составьте список зависимых проверок.

Что проверить в SELinux и томах

SELinux использует метки объектов и процессов для контроля доступа. Раньше при подготовке тома runtime мог рекурсивно менять метки файлов и каталогов. Если файлов много, этот обход занимает время. Оптимизированный механизм задаёт контекст при монтировании тома через -o context=<label>.

В Kubernetes 1.37 SELinuxMount включён по умолчанию. При этом механизм применяется при выполнении набора условий: нужен подходящий PVC, известная Kubernetes SELinux-метка и поддержка со стороны драйвера. CSI-драйвер объявляет такую поддержку полем spec.seLinuxMount: true. На узлах без SELinux эти изменения не действуют.

Риск появляется при совместном использовании тома на одном узле. Официальный разбор приводит два сценария: Pods с разными метками используют разные subPath одного тома; либо том разделяют на привилегированный и непривилегированный Pods. При новом способе монтирования один из конфликтующих Pods может остаться в ContainerCreating.

В Kubernetes 1.36 можно заранее проверить такие конфликты с помощью selinux-warning-controller, который работает внутри kube-controller-manager. По умолчанию он отключён. Для проверки включите его через параметр --controllers у kube-controller-manager; в документации приведён пример --controllers=*,selinux-warning-controller.

После включения контроллер сообщает о найденных конфликтах через события и метрику selinux_warning_controller_selinux_volume_conflict. Он проверяет и Pods на разных узлах, поскольку после пересоздания они могут оказаться на одном.

Для приложения, которому нужно прежнее поведение, есть настройка Recursive. Ниже кусок спецификации Pod, который сохраняет рекурсивное применение меток:

У Deployment или StatefulSet этот параметр должен находиться внутри спецификации Pod в шаблоне: spec.template.spec.securityContext. Проверьте итоговый манифест, который действительно получает кластер. Применять исключение ко всем приложениям заранее не нужно: сначала определите затронутые нагрузки и протестируйте выбранное поведение.

Что ещё изменилось в конфигурации

Раздел Urgent Upgrade Notes содержит несколько менее заметных изменений. Их удобно пройти отдельным списком до тестового обновления.

• Удалена версия scheduling.k8s.io/v1alpha2. Changelog требует убрать соответствующие объекты до обновления. Если команда использовала экспериментальные API планировщика, ей нужно разобрать эти объекты и способ их замены.
• Значение eventRecordQPS: 0 теперь означает отсутствие ограничения частоты событий. Чтобы сохранить ограничение, задайте ненулевое значение; в release notes приведён пример 50.
• Kubelet выводит эффективную конфигурацию при запуске. Администраторам предлагают проверить доступ к nodes/logs и ограничить его доверенными пользователями.

В первом случае недостаточно найти старую строку версии в репозитории и заменить её во всех файлах. В плане работ должны быть учтены существующие объекты. Во втором случае привычный ноль меняет поведение после обновления. В третьем нужно проверить права на диагностическую информацию.

Для каждого пункта запишите результат применительно к своему кластеру: используется ли настройка, кто за неё отвечает и что требуется изменить. Если экспериментальные API не включались, это тоже полезный результат проверки. Он объясняет, почему соответствующий шаг исключён из вашей процедуры, и позволяет повторить аудит позднее.

Нужно ли одновременно менять containerd и IPVS

Некоторые обзоры требуют перейти на containerd 2.x перед Kubernetes 1.37. В чейнджлоге удаление части настроек kubelet и связанного с ними резервного поведения перенесено с 1.37 на 1.38 для согласования с поддержкой containerd 1.7. Этот перенос не распространяется на перечисленные выше флаги cAdvisor: они уже удалены в 1.37 и мешают запуску kubelet, если остались в аргументах службы. Совместимость установленного runtime и срок его поддержки нужно проверять отдельно.

С IPVS ситуация тоже требует точной формулировки. В 1.37 этот режим kube-proxy продолжает работать. Официальный анонс указывает ожидаемое отключение по умолчанию в 1.40 и удаление в 1.43. Текущий режим можно посмотреть так:

Если видите mode: ipvs, добавьте миграцию в план инфраструктурных работ. Сам этот результат ещё не означает, что обновление на 1.37 нужно остановить.

Проверка cgroup v1 относится к совместимости узлов. Отказ kubelet запускаться с cgroup v1 по умолчанию действует с версии 1.35. В 1.37 сохраняется временное переопределение failCgroupV1: false, однако проект рекомендует переходить на cgroup v2.

Для вашей процедуры из этого следует простой подход: зафиксировать обязательные исправления отдельно от запланированных миграций. Если runtime или сеть тоже требуют изменений, выделите им собственные проверки. Тогда при неудачном тесте будет понятнее, какое именно изменение вызвало новое поведение.

Как подготовить тестовое обновление

Тест должен проверять те зависимости, которые есть в продакшене. В перечень для своего окружения включите сеть, подключение хранилищ, правила допуска запросов и мониторинг. Если приложение использует особые настройки безопасности или обновляется как StatefulSet, эти особенности тоже должны попасть в проверку.

Составьте короткий сценарий для каждого важного приложения: что должно запуститься после переноса, к каким данным оно обращается и как вы подтвердите работоспособность. Результат «Pod появился в списке» слишком узок для решения о доступности сервиса. Проверка должна доходить до операции, ради которой приложение запущено.

Отдельно продумайте поведение при выводе узла из работы. PodDisruptionBudget, или PDB, ограничивает допустимое число недоступных реплик при добровольных прерываниях, которые используют Eviction API. Обычный drain учитывает этот бюджет. При нехватке доступных реплик он может ждать, пока приложение восстановится.

Например, в документации разобран случай с тремя репликами и требованием сохранять две доступными. Одну реплику можно остановить для обслуживания узла: Kubernetes создаст ей замену, а две другие продолжат работать. Остановить следующую получится, когда новая реплика будет готова. Если для её запуска не хватает ресурсов, потребуется вернуть в работу обслуженный узел или добавить новый. Поэтому заранее проверьте, хватит ли на остальных узлах ресурсов для запуска Pods на время обновления.

Подготовьте резервные копии состояния приложений и процедуру восстановления. В официальном гайде kubeadm отдельно упомянуты данные уровня приложения, например, базы. В своём плане укажите место хранения копий, ответственного за восстановление и момент, после которого команда прекращает обновление и начинает разбор сбоя.

Если для подготовки нужна внешняя команда, на нашем сайте, Centicore Group есть услуги по развёртыванию ИТ-ландшафта, миграции ИТ-инфраструктуры и поддержке облачных сервисов. Перед обращением соберите сведения о текущем окружении и требованиях приложений: с ними будет проще обсудить объём работ.

В каком порядке обновлять кластер

Начните с первого узла control plane. По официальному гайду на нём обновляют kubeadm до выбранной версии 1.37.x, проверяют план и запускают обновление управляющих компонентов. Пакеты берут из репозитория соответствующей минорной версии.

Изучите предложенный план. Затем выполните команду обновления, заменив x конкретным номером патча:

На остальных узлах control plane сначала обновите пакет kubeadm, затем выполните sudo kubeadm upgrade node. Повторять kubeadm upgrade plan на каждом узле не требуется. Обновляйте управляющие узлы последовательно. Отдельно проверьте инструкцию установленного сетевого плагина CNI и выполните необходимые шаги его обновления.

Обновление kubelet и kubectl нужно выполнить и на узлах control plane. Для каждого узла предусмотрены drain, установка пакетов, перезапуск kubelet и uncordon. Учитывайте совместимость версий: если kubelet может обращаться к нескольким API server, все они должны быть обновлены до 1.37 перед переходом этого kubelet на 1.37. После обслуживания управляющих узлов переходите к рабочим узлам.

Перед минорным обновлением kubelet узел нужно освободить от обычных рабочих Pods. Команда drain помечает его недоступным для стандартного планирования и запрашивает выселение нагрузок:

Дождитесь успешного завершения. Если операция ждёт, сначала выясните причину. PDB может ограничивать выселение, а приложению может требоваться время на восстановление. --ignore-daemonsets позволяет продолжить при наличии Pods DaemonSet, но не удаляет их. Drain также не останавливает static Pods, поэтому управляющие компоненты требуют своей процедуры обслуживания.

После обновления управляющих узлов переходите к рабочим узлам под Linux. На каждом рабочем узле обновите пакет kubeadm, выполните kubeadm upgrade node, проведите drain, затем обновите пакеты kubelet и kubectl до выбранной версии. Команда upgrade node подготавливает локальную конфигурацию kubelet; установку нового пакета нужно выполнить отдельно.

После установки пакетов перезапустите службу:

Когда закончите проверки узла, разрешите планирование:

Обновляйте остальные рабочие узлы по очереди. Следите, чтобы на оставшихся узлах хватало ресурсов для работы приложений. В вашей инструкции должны быть записаны конкретные имена узлов и версии пакетов. Все значения в угловых скобках и x в примерах заменяются до запуска.

Что проверить перед следующим узлом

Сначала убедитесь, что kubelet работает и узел вернулся в Ready. Затем проверьте перенесённые приложения по сценарию, подготовленному до обновления. Сравните результат с исходным состоянием: появились ли новые ошибки, подключились ли тома, продолжают ли поступать данные мониторинга.

В отдельную проверку вынесите StatefulSet. В 1.37 функция MaxUnavailableStatefulSet включена по умолчанию. Поле spec.updateStrategy.rollingUpdate.maxUnavailable задаёт, сколько Pods может быть недоступно во время обновления StatefulSet. Значение maxUnavailable по умолчанию равно 1. Проверяйте его вместе с spec.podManagementPolicy: документация описывает одновременное обновление нескольких Pods для политики Parallel и maxUnavailable больше 1. При таком сочетании Pods могут становиться готовыми в разном порядке, что подходит не каждому приложению.

Просмотрите существующие стратегии обновления. Если поле уже было задано в манифесте, проверьте, какое поведение оно даёт при включённой функции. Для приложения, где нужен порядок восстановления экземпляров — отдельно тестируйте ускоренный rollout.

При этом PDB и стратегия StatefulSet регулируют разные операции. PDB учитывается при выселении через Eviction API; собственное rolling-обновление контроллера StatefulSet не ограничивается этим бюджетом. Поэтому нормальный drain и rollout приложения должны быть отдельными пунктами проверки.

Лучше заранее сформулировать условие продолжения обычным предложением: «следующий узел обновляем, когда перенесённые нагрузки восстановились и прошли свои проверки». За ним должны стоять конкретные результаты тестов. Если один Pod всё ещё ждёт том или приложение отвечает с ошибкой, переход к следующему узлу только усложнит поиск причины.

Что делать, если обновление остановилось

Разберите, на каком этапе произошёл сбой: при выполнении kubeadm, запуске kubelet или восстановлении приложения. Сохраните вывод команды и журналы проблемной службы. До выяснения причины оставьте остальные узлы на текущем этапе.

Для kubelet начните с проверки состояния и журнала:

Если проблема в старом аргументе запуска, вернитесь к проверке конфигурации службы. Если kubelet работает, а приложение застряло на подключении тома, продолжайте разбор на уровне Pod и хранения. Так результаты диагностики будут связаны с конкретным этапом обновления.

Официальный гайд допускает повторный запуск kubeadm upgrade, если операция оборвалась и автоматическое восстановление не завершилось. Процедура идемпотентна: повторное выполнение приводит компоненты к заявленному состоянию. Это механизм восстановления незавершённого обновления.

Kubeadm также создаёт каталоги резервных копий в /etc/kubernetes/tmp: kubeadm-backup-etcd-<date>-<time> и kubeadm-backup-manifests-<date>-<time>. Первая копия относится к локальному участнику etcd; при внешнем etcd соответствующий каталог будет пустым. Вторая содержит сохранённые static-манифесты. Используйте их по документированному сценарию для вашей конфигурации.

При обновлении StatefulSet со стратегией RollingUpdate и политикой OrderedReady возможна остановка: Pod с новой конфигурацией не переходит в Ready, и контроллер ждёт его восстановления. Известная проблема проявляется при восстановлении: даже после возврата рабочего шаблона контроллер может продолжать ждать готовности неисправного Pod. После возврата шаблона нужно удалить затронутые Pods с ошибочной конфигурацией, чтобы контроллер пересоздал их. Этот сценарий нужно заранее включить в тест восстановления приложения.

Когда можно переходить в прод

На начало сентября 2026 года последним патчем ветки остаётся 1.37.0. Релиз 1.37.1 запланирован на 15 сентября; дата окончания поддержки ветки указана как 28 октября 2027 года. Перед началом обновления ещё раз проверьте страницу релиза⁠: запланированный патч может ещё не выйти.

Советуем дождаться 1.37.1 или 1.37.2, если нет конкретной причины переходить сразу. Официальная рекомендация Kubernetes — использовать актуальные патчи исходной и целевой минорных версий. Ожидание можно включить в график, продолжая проверку совместимости и подготовку окружения.

Решение о продакшене должно опираться на результаты теста. Команда знает, какие манифесты пришлось исправить, как приложения пережили выселение с узла и где лежат данные для восстановления. После первого обновлённого узла она может объяснить, почему продолжать допустимо.

Если проверка нашла конфликт меток или неподходящую конфигурацию службы, подготовка уже принесла результат: проблема найдена до окна обслуживания. Пофиксите её, повторите затронутый сценарий и внесите исправление в процедуру. Тогда следующее обновление начнётся с накопленных знаний о вашем кластере.

Последние два года команда VK собирает такие задачи на общем технологическом фундаменте. В него входят внутренняя платформа разработки, облачная инфраструктура One-cloud, технологии видеоплатформы и единая система работы с данными и экспериментами. Команды получают готовые платформенные решения и могут тратить больше времени на задачи продукта.

Платформа для новых сервисов

В начале 2025 года ВКонтакте началась технологическая трансформация: большую часть системы перевели на новый стек и сервисную архитектуру. Отдельные компоненты получили свои зоны ответственности, поэтому их можно обновлять независимо.

У такой архитектуры есть обратная сторона. Каждый компонент нужно встроить в общий контур: создать репозиторий, выделить инфраструктуру, настроить сборку, проверки, доступы, мониторинг и выпуск в продакшен. Вручную эта подготовка может занять больше времени, чем разработка.

Повторяющиеся операции техническая команда ВКонтакте собрала во внутреннюю платформу разработки: разработчик выбирает готовый шаблон, получает ресурсы, подключается к каталогу, настраивает сборку, логи и метрики.

Для типовых задач действует self-service. Команда самостоятельно проводит изменение от кода до продакшена и следит за его работой. Платформа запускает проверки, создаёт изолированную тестовую среду и помогает постепенно включать новую логику с помощью фича-флагов.

С помощью новой платформы ВКонтакте создала более 300 новых сервисов, а в 2026 году решение масштабировали на другие продукты VK. Платформа поддерживает Go, Java и Python, а в её контуре зарегистрированы тысячи сервисов, работающих во внутреннем облаке.

Мы не просто ускорили создание сервисов — мы изменили логику работы команд. Они смогли самостоятельно пройти путь от идеи до запуска, не собирая каждый раз инфраструктуру по частям. Это стало одной из опор трансформации ВКонтакте: создание нового сервиса занимает около часа, тогда как раньше на тот же путь уходило сильно больше времени.

Как VK объединила инфраструктуру разных продуктов

После запуска новому сервису нужны процессорные ядра, память, сеть и хранилище. Эти потребности меняются вместе с нагрузкой. У видеосервиса быстро растёт объём данных, а у другого продукта пик может прийтись на отдельное событие.

Раньше продукты VK управляли инфраструктурой отдельно: планировали оборудование, закрепляли мощности за системами и вручную перераспределяли их при изменении нагрузки. Внутреннее облако One-cloud объединило серверы и хранилища в общий пул. Команда указывает, как он должен работать и сколько ресурсов требуется, а платформа размещает нагрузку и управляет её жизненным циклом.

One-cloud не проектировали сразу для всей компании. Платформа выросла из инфраструктуры Одноклассников, а следующим крупным этапом стала миграция Дзена. Затем к ней подключились ВКонтакте, VK Видео, MAX и другие сервисы. Сейчас платформа объединяет около десятков тысяч серверов, миллионы процессорных ядер и более 2 ЭБ данных. Продукты получают мощности из общего пула по мере роста нагрузки.

Для команд разница заметна в повседневной работе. Например, вычислительные ресурсы для базы данных можно получить примерно за несколько минут.

VK Видео может прибавить петабайт данных за несколько дней. При таком темпе сложно вручную перераспределять серверы и заранее подбирать мощности под каждую новую волну нагрузки. Облако делает это за команду: берёт ресурс из общего пула и добавляет его по мере роста сервиса. Поэтому команда VK Видео сосредоточена на развитии продукта, а рост аудитории не мешает стабильному просмотру.

Как один видеоконвейер работает для разных продуктов

В одних продуктах VK видео составляет основу сервиса. В других оно нужно для публикаций, кружочков в мессенджере, историй или продвижения товаров. Любой видеофайл проходит один путь: его загружают, транскодируют, сохраняют, доставляют пользователю и воспроизводят. Эту работу берёт на себя видеоплатформа VK.

У видеоплатформы есть два основных сценария: загрузка ролика автором и его просмотр зрителем. Когда автор публикует видео, система принимает файл, присваивает ему идентификатор и отправляет на транскодирование — подготовку версий в разных разрешениях и форматах. Для этого платформа использует три кодека. H.264 поддерживает большинство устройств. VP9 сильнее сжимает видео, но требует больше вычислительных ресурсов. AV1 обеспечивает самое эффективное сжатие, однако создаёт ещё более высокую нагрузку при обработке. Поэтому с его помощью кодируют популярные ролики: их смотрит много людей, а меньший битрейт позволяет сократить объём трафика при сохранении качества.

Для зрителя эта работа остаётся незаметной. Когда он запускает видео, плеер получает подготовленные версии и выбирает подходящую с учётом устройства и скорости интернета.

После транскодирования появляется несколько версий ролика с разным качеством, аудиодорожками и метаданными. Каждая версия хранится как целый MP4-файл. При этом данные внутри файла структурированы так, чтобы плеер мог запрашивать видео по частям и воспроизводить нужный отрезок, не загружая ролик целиком. Когда зритель запускает видео, сеть доставки контента ищет нужные данные на ближайшей кеш-площадке. Если их там ещё нет, система получает их из центрального хранилища и сохраняет в кеше для следующих просмотров.

Плеер получает видео по фрагментам, поэтому просмотр начинается до загрузки всего файла. Он учитывает скорость интернет-соединения и выбирает подходящее разрешение. Если связь ухудшается, следующий фрагмент приходит в другом разрешении — это помогает продолжить просмотр без пауз и ожидания загрузки. Когда соединение восстанавливается, плеер может снова повысить разрешение. Перезапускать ролик при этом не нужно.

Так видеоплатформа работает и с VK AdBlogger. В этом сервисе авторы могут выбирать товары продавцов маркетплейсов, публиковать о них посты или видео ВКонтакте и получать вознаграждение за покупки по реферальным ссылкам. Такие публикации называют шопсами.

Команда VK AdBlogger хотела добавлять шопсы в истории ВКонтакте без ручной подготовки контента. Для истории нужен другой формат ролика и отдельная карточка с изображением и названием товара. VK AdBlogger публикует контент через API, поэтому обработку исходного видео, добавление карточки и создание истории объединили в единый процесс.

VK AdBlogger не пришлось создавать собственную систему обработки видео ради одной механики. Команда интегрировала сервис с видеоплатформой VK: AdBlogger передаёт ей исходный ролик и карточку товара, а платформа готовит версию для историй автора, добавляет баннер и направляет видео в нужный сценарий ВКонтакте. Автор загружает ролик один раз — всё остальное происходит автоматически.

От локальной метрики к общему результату: как работает OneAB

После запуска нужно проверить, как изменение повлияло на пользователей и показатели продукта. В VK Видео пользовательский путь связывает главную, подписки, рекомендации и другие разделы. Изменение одного элемента может затронуть соседние, поэтому A/B-тест оценивают в контексте всего сервиса.

Для такого анализа VK развивает единую платформу данных: она объединяет хранилище, каталог данных, управление доступами и качеством, BI-системы и инструменты для A/B-тестов. Объём данных превышает 400 ПБ.

За A/B-тестирование отвечает OneAB. Раньше продукты по-разному распределяли аудиторию и считали результаты. Новый продукт объединил настройку теста, разделение пользователей и расчёт метрик. Система сравнивает поведение контрольной и тестовой групп.

OneAB особенно важна для тестов нескольких команд. Например, команда VK Видео меняет интерфейс, а другая проверяет новую модель рекомендаций. Система включает оба изменения для одной группы, и аналитики видят их совместный эффект.

Аудиторию распределяет отдельный сервис на Go. Активные тесты хранятся в оперативной памяти, а продукты обращаются к системе по gRPC или HTTP. Сервис обрабатывает около двух миллионов запросов в секунду и определяет группу меньше чем за миллисекунду.

Эксперименты распределены по областям продукта. В независимых разделах их запускают параллельно, а для одной поверхности выделяют непересекающиеся группы. После теста аналитик видит показатели главной, подписок, рекомендаций и разных типов контента.

Если время просмотра на главной выросло, мы проверяем, что произошло со всем сервисом. Иногда рост означает, что мы просто перетянули внимание с соседней поверхности. При ручном расчёте пришлось бы несколько раз досчитывать разные группы метрик. В OneAB около 90% нужных нам показателей рассчитываются автоматически, поэтому аналитик быстрее переходит от результата к интерпретации эффекта и подготовке рекомендаций для продукта.

Ежемесячно через OneAB проходит более тысячи A/B-тестов. Системой пользуются ВКонтакте, Одноклассники, VK Видео и другие продукты компании.

Что изменилось для инженерных команд

Общий технологический фундамент VK вырос из задач отдельных продуктов. Решения сначала проверяли на реальной нагрузке, а затем масштабировали на всю компанию. Единая платформа разработки помогает быстро выпустить сервис, One-cloud даёт ему инфраструктуру, видеоплатформа доставляет ролики, а OneAB оценивает эффект изменений.

ВКонтакте, Одноклассники, Дзен, VK Видео, MAX сохраняют собственные задачи и логику развития. Общими стали технологии, которые не определяют продуктовые решения, а помогают быстрее воплощать и проверять их.

Нейросети становятся привычным цифровым инструментом для школьников. Дети используют их для создания изображений и текстов, подготовки презентаций, поиска идей и учебных проектов. При этом простого знакомства с ChatGPT или другой нейросетью недостаточно, если родители хотят, чтобы ребенок действительно научился работать с искусственным интеллектом.

В 2026 году школы предлагают разные варианты обучения: от коротких вводных занятий по промптингу до долгосрочных программ, где ИИ объединяется с Python, разработкой игр, сайтов и приложений.

Разобраться в предложениях непросто: отличаются не только программы, но и возраст учеников, формат занятий, продолжительность и стоимость. Поэтому в этой статье собрали школы с ИИ для детей в 2026 году и сравнили их основные программы.

Ниже — сводная таблица, а затем подробный разбор курсов и рекомендации, как выбрать обучение под возраст и интересы ребенка.

Как мы составляли подборку?

Мы сравнивали образовательные программы, в которых искусственный интеллект или нейросети являются самостоятельной темой обучения либо используются как важная часть практических заданий.

Учитывали:

• возраст учеников;
• содержание программы;
• формат занятий;
• длительность;
• наличие преподавателя или наставника;
• практические проекты;
• пробное занятие;
• стоимость, если она опубликована;
• итоговые результаты.

Если школа не указывает стоимость или продолжительность программы в открытом доступе, мы не стали предполагать эти данные.

Важно учитывать, что цены, расписание и состав курсов могут изменяться. Перед записью ребенка стоит проверить актуальные условия на сайте выбранной школы.

Школы с ИИ для детей: сравнение курсов

Pixel: ИИ вместе с программированием

Pixel предлагает несколько программ, связанных с искусственным интеллектом, для разных возрастов.

Для детей 10–13 лет есть курс Python и ИИ. Здесь нейросети изучаются не изолированно, а вместе с программированием. Ученики создают чат-ботов, умных помощников, игры и другие проекты.

Для подростков 14–17 лет предусмотрено обучение созданию приложений с искусственным интеллектом. В программе объединяются проектирование интерфейсов, мобильная разработка и AI-функции.

Занятия проходят онлайн в Zoom. Можно заниматься в группе или индивидуально. Для игровых онлайн-курсов используется структура из трех модулей по 12 занятий продолжительностью 90 минут.

Важная особенность программы — проектный подход. Ребенок не просто знакомится с возможностями нейросетей, а применяет их при создании собственного цифрового продукта.

Преимущества: несколько возрастных направлений, ИИ + программирование, практические проекты, индивидуальный и групповой формат.

Кому подойдет: детям, которые хотят не только пользоваться нейросетями, но и создавать с их помощью игры, программы и приложения.

Rebotica: нейросети через творчество

Программа по ИИ и нейросетям в Rebotica рассчитана на детей 9–11 лет.

Курс построен вокруг творческих задач. Школьники работают с текстами, изображениями, музыкой, видео, играми и сайтами.

Обучение проходит индивидуально онлайн с персональным наставником. Программа включает 36 занятий по 60 минут и девять проектов.

Среди итоговых работ могут быть игра, мультфильм, комикс или сайт. Отдельное внимание уделяется безопасности: ребенок знакомится с дипфейками, защитой данных и правилами работы с искусственным интеллектом.

Стоимость начинается от 6 376 рублей в месяц при рассрочке.

Преимущества: индивидуальный формат, много практики, наставник, понятные проекты.

Кому подойдет: детям младшего школьного возраста, которые хотят познакомиться с ИИ через творчество.

Фоксфорд: нейросети и промптинг

Фоксфорд предлагает несколько вариантов обучения искусственному интеллекту для школьников.

Для подростков 12–17 лет есть программы, связанные с нейросетями, созданием запросов и программированием. Отдельные курсы рассчитаны на более короткое знакомство с AI.

Важное место занимает практика. Ребенок учится составлять запросы, использовать нейросети для решения задач и создавать собственные проекты.

В зависимости от программы доступны занятия с преподавателем, мини-группы и записи. Некоторые вводные программы начинаются примерно от 990 рублей.

Преимущества: разные форматы обучения, можно выбрать короткую или более продолжительную программу.

Кому подойдет: школьникам, которым нужен гибкий формат и возможность начать с базового знакомства с нейросетями.

CODDY: промптинг для подростков

CODDY предлагает отдельный курс по нейросетям и промпт-инжинирингу для подростков 13–16 лет.

Ученики изучают, как правильно формулировать запросы, получать нужный результат от нейросетей и использовать AI-инструменты для создания мультимедийного контента.

В программе могут использоваться текстовые и графические нейросети. Среди практических задач — создание комиксов, изображений, видео, музыки, сайтов и виртуальных собеседников.

Курс рассчитан на 36 занятий по 1,5 часа. Занятия проходят онлайн или очно с преподавателем. Предварительное знание программирования не требуется.

Преимущества: подходит начинающим, много практики, индивидуальный формат.

Кому подойдет: подросткам, которые хотят научиться применять нейросети для учебы, творчества и создания контента.

Нейрокадо: индивидуальное обучение ИИ

Нейрокадо ориентируется непосредственно на обучение искусственному интеллекту и современным AI-инструментам.

Программы рассчитаны на детей и подростков 9–17 лет. Занятия проходят онлайн один на один с преподавателем.

В зависимости от уровня ученики могут работать с GPT, Claude, Midjourney, Stable Diffusion и другими инструментами. Более продвинутые программы включают API, HTML/CSS, JavaScript и создание цифровых продуктов.

Предусмотрены абонементы на четыре, восемь или 12 занятий в месяц. Стоимость составляет 12 000, 20 000 и 27 000 рублей соответственно.

Основной результат — собственные проекты и портфолио.

Преимущества: индивидуальный маршрут, широкий набор инструментов, возможность перейти к техническим AI-задачам.

Кому подойдет: детям и подросткам, которым важно персональное обучение и большое количество практики.

Дельфа: базовый курс по нейросетям

Учебный центр «Дельфа» предлагает курс по введению в нейросети для школьников 11–18 лет.

Программа рассчитана на 12 занятий по 80 минут. Ученики знакомятся с ChatGPT и другими AI-инструментами, создают изображения, презентации и итоговые проекты.

Занятия доступны онлайн и очно. Стоимость групповых занятий начинается примерно от 4 240 рублей в месяц, индивидуальных — от 6 400 рублей.

После обучения выдается сертификат.

Преимущества: понятная программа, онлайн и офлайн, практические задания.

Кому подойдет: школьникам, которым нужен структурированный курс для знакомства с основными возможностями нейросетей.

KIBERone: первое знакомство с ИИ

KIBERone предлагает программу по искусственному интеллекту для детей 7–12 лет.

Курс рассчитан на начальный уровень. Дети знакомятся с возможностями нейросетей, учатся создавать запросы и использовать AI для работы с цифровым контентом.

Формат обучения — очный. Программа включает 4 занятия, поэтому ее можно рассматривать как короткое введение в тему.

Главное преимущество такого формата — невысокий порог входа. Ребенку не нужно заранее изучать программирование.

Преимущества: короткая программа, очный формат, подходит новичкам.

Кому подойдет: детям 7–12 лет, которые только начинают знакомиться с искусственным интеллектом.

Академия Эдюсон: Python и нейросети

Если подростку интересен не только пользовательский, но и технический аспект искусственного интеллекта, можно рассмотреть курс «Python и нейросети для школьников».

Программа рассчитана на детей от 11 лет и длится около 12 месяцев.

Здесь Python изучается вместе с AI-инструментами. Ученики работают с YandexGPT, Perplexity и инструментами для программирования с поддержкой искусственного интеллекта.

Программа включает около 20 проектов. Среди них — умный помощник, игры и веб-проекты.

Преимущества: программирование + ИИ, длительная траектория, большое количество проектов.

Кому подойдет: школьникам, которые хотят связать изучение нейросетей с программированием и будущей IT-карьерой.

Яндекс Лицей: программирование как следующий шаг

Яндекс Лицей не является классическим курсом по нейросетям. Основной фокус здесь — программирование.

Однако для подростков, которые хотят в дальнейшем развиваться в области искусственного интеллекта, программирование может стать важной базой.

В программах представлены Python, Go и другие языки. Обучение рассчитано прежде всего на школьников старших классов и проходит очно или онлайн в зависимости от курса.

Особенность Яндекс Лицея — бесплатное обучение и конкурсный отбор.

Преимущества: серьезная техническая база, бесплатное обучение.

Кому подойдет: подросткам, которые уже заинтересованы в программировании и рассматривают ИИ как дальнейшее профессиональное направление.

Как выбрать обучение ИИ для ребенка

1. Определите, зачем ребенку нейросети

Если ребенок хочет создавать картинки, видео и тексты, ему подойдет творческий курс.

Если интересуется чат-ботами и программами — стоит обратить внимание на Python и AI.

Если подростку интересны технологии как будущая профессия, можно искать более техническую программу с программированием, API и разработкой AI-приложений.

2. Учитывайте возраст

Для младших школьников лучше выбирать программы с простыми практическими задачами.

В 11–13 лет можно постепенно добавлять программирование.

Для подростков 14–17 лет уже доступны более сложные проекты, включая приложения, сайты и работу с API.

3. Смотрите на количество практики

Наличие большого списка нейросетей еще не означает, что ребенок хорошо освоит ИИ.

Лучше узнать, сколько проектов он сделает самостоятельно и сможет ли сохранить их в портфолио.

4. Обратите внимание на преподавателя

При изучении ИИ ребенок может столкнуться с непредсказуемыми ответами нейросети, ошибками в коде или сложными настройками.

Наставник помогает разобраться в проблеме и объясняет, почему результат получился именно таким.

5. Проверьте пробный урок

Если школа предлагает бесплатное занятие, стоит им воспользоваться.

Важно оценить не только преподавателя, но и реакцию ребенка: интересно ли ему, понятно ли объяснение и хочет ли он продолжать.

Что должен уметь ребенок после курса ИИ?

Результат зависит от уровня программы, но хорошее обучение должно дать больше, чем набор готовых промптов.

После курса ребенок может научиться:

• формулировать запросы к нейросетям;
• проверять полученную информацию;
• создавать тексты и изображения;
• использовать AI для учебных задач;
• работать с несколькими AI-инструментами;
• создавать сайты, игры или чат-ботов;
• применять ИИ при программировании;
• самостоятельно разрабатывать небольшие проекты.

Особенно важно научить ребенка понимать ограниченность нейросетей. AI может ошибаться, придумывать факты и выдавать убедительный, но неправильный ответ.

Поэтому один из главных навыков — не просто пользоваться ИИ, а проверять его результат.

FAQ

С какого возраста можно начинать обучение ИИ?

Зависит от программы. Некоторые курсы рассчитаны на детей 7–9 лет, а технические программы чаще подходят школьникам от 11–13 лет.

Нужно ли знать программирование?

Нет. Для курсов по промптингу и генеративным нейросетям специальная подготовка обычно не нужна. Для создания AI-приложений желательно постепенно освоить программирование.

Что лучше изучать сначала — нейросети или Python?

Если ребенок только знакомится с ИИ, можно начать с готовых нейросетей. Если интерес к технологии сохраняется, следующим шагом может стать Python и создание собственных AI-проектов.

Сколько длится обучение?

Есть короткие программы на несколько занятий и долгосрочные курсы на несколько месяцев или год. Выбор зависит от цели.

Нужен ли ребенку мощный компьютер?

Для работы с большинством облачных нейросетей достаточно обычного современного компьютера с интернетом. Но конкретные технические требования зависят от программы.

Что важнее — сертификат или проект?

Для практического развития важнее проект. Сертификат подтверждает факт обучения, а готовая работа показывает, что ребенок умеет применять знания.

Можно ли заниматься ИИ онлайн?

Да. Большинство современных курсов по искусственному интеллекту доступны онлайн. Можно выбрать групповой или индивидуальный формат.

Итоги

Обучение ИИ в 2026 году может выглядеть совершенно по-разному. Для младшего школьника это может быть создание картинок, игр и мультфильмов с помощью нейросетей. Для подростка — промптинг, чат-боты, сайты и приложения. А для старшеклассника, который задумывается о профессии в IT, следующим этапом может стать Python и более техническое изучение искусственного интеллекта.

Если нужен курс с сочетанием ИИ и программирования, стоит обратить внимание на Pixel и Академию Эдюсон. Для знакомства с нейросетями через творчество подойдет Rebotica. Подросткам, которые хотят глубже изучить промптинг и AI-инструменты, можно рассмотреть CODDY или Нейрокадо.

Перед выбором стоит определить возраст, интересы и цель ребенка, затем сравнить формат, продолжительность, стоимость и количество практических заданий.

И главное — смотреть не только на список нейросетей в программе. Хороший результат обучения — это когда ребенок понимает возможности и ограничения искусственного интеллекта, умеет критически оценивать ответы нейросети и способен самостоятельно использовать AI для создания собственных проектов.

На связи команда облачного провайдера Beget – сегодня мы расскажем, как можно сэкономить на хранении данных, когда их становится всё больше.

Мы с вами живем в цифровую эпоху, где ежедневно создается приблизительно 402,74 млн терабайт информации, а данные – один из ключевых ресурсов каждого бизнеса.

Изображения, видео, документы, пользовательские файлы, резервные копии – их объем постоянно растет: по статистике, неструктурированные наборы данных составляют 90% всей информации, генерируемой предприятиями, а ее размеры зачастую достигают терабайтов или петабайтов.

И вместе с этим, соответственно, увеличиваются требования к инфраструктуре и расходы на ее содержание.

При этом удалять данные только потому, что они занимают много места, бизнес не может: новые файлы необходимы для работы, а старые – могут понадобиться клиентам, команде или для восстановления проекта после сбоя.

В этих реалиях возникает задача – как сократить расходы на хранение данных и не потерять к ним доступ.

Расскажем о решении, которое может в этом помочь.

Когда серверу становится тесно

Зачастую это происходит внезапно: сначала серверу хватает места, а через несколько месяцев – уже нет: добавляются новые файлы, а вместе с ними растут и затраты на инфраструктуру.

Однако не всей информации нужны ресурсы основного сервера – вот примеры данных, которые так хранить необязательно:

· резервные копии;

· архивы и старые версии файлов;

· логи и истории событий;

· изображения, видео и другой медиаконтент;

· документы, которые редко используются;

· выгрузки и результаты обработки данных;

· дистрибутивы, установочные файлы и образы;

· данные для долгосрочного хранения и аудита.

Ко многим из этих данных обращаются редко, а хранить их нужно постоянно.

Чтобы сэкономить на хранении и при этом сохранить быстрый доступ к информации, когда она понадобится, можно подключить S3 – безлимитное облачное объектное хранилище для работы с большими объемами неструктурированных данных.

С ним можно разделить вычисления и хранение: оставить на серверах только то, что действительно нужно приложению для работы, а большие объемы файлов, архивов и резервных копий вынести в объектное хранилище – такой подход позволяет увеличивать объем данных по мере роста бизнеса, не перестраивая основную инфраструктуру.

Что дает объектное хранилище

· Моментальное масштабирование – облачное хранилище S3 расширяется автоматически, загружайте столько данных, сколько потребуется.

· Надежность и доступность – при аренде S3-хранилища данные хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности.

· Гибкое управление – версионирование, настройка доступа и классы хранения позволяют контролировать, где и как хранятся данные.

· Доступ к данным 24/7 из любой точки мира и из любого браузера.

· Удобная модель оплаты Pay as you go – оплачивайте только тот объем, который используете.

В настоящее время S3 хранит сотни эксабайт данных в сотнях триллионов объектов, обрабатывая в среднем более 200 миллионов запросов в секунду.

Разберем конкретнее, какую пользу объектное хранилище может принести бизнесу.

S3 на практике: кто и как использует

Итак, объектное хранилище может пригодиться для:

· хранения бэкапов, отчетов, медиафайлов и другого контента отдельно от серверов – чтобы сэкономить и снизить риск потери данных при сбоях;

· архивирования – сохраняйте редко используемые документы, логи и старые версии файлов без нагрузки на основные диски;

· обмена данными между сервисами – можно организовать единое хранилище для микросервисов и упростить передачу файлов между ними;

· масштабирования проектов – увеличивайте объем хранимых данных без пропорционального расширения серверных дисков.

S3 используют более 398 тысяч компаний – и вот лишь несколько примеров результатов:

· производитель шин Apollo Tyres – на 90% снизил затраты на резервное копирование за 2 года на трех из семи своих заводов;

· платформа EZJobs – снизила затраты на 50% благодаря интеллектуальному многоуровневому хранению;

· маркетплейс Ozon – благодаря дедупликации в среднем сэкономил на обработке данных около 13% по всем бакетам;

· технологическая компания Bynder – сэкономила 65% затрат на хранение данных о клиентах благодаря системам интеллектуального многоуровневого хранения S3;

· финансовый маркетплейс “Сравни” – уменьшил затраты на инфраструктуру БД в 1,5 раза.

На примере этих и других компаний заметно, что объектное хранилище S3 помогает решать сразу несколько бизнес-задач – сокращать расходы на хранение, разгружать серверную инфраструктуру и масштабировать объем данных без сложных перестроек.

Если у вашего проекта большое количество данных и вы хотите оптимизировать расходы на их хранение, то создать объектное хранилище S3 в Beget буквально в один клик можно уже сейчас.

Заключение

Примерно 90% из генерируемых пользователями данных являются неструктурированными.

В этой ситуации S3-хранилище может помочь бизнесу хранить растущие объемы файлов отдельно от серверной инфраструктуры, не переплачивая за дисковые ресурсы и сохраняя быстрый доступ к нужной информации.

При этом экономия на хранении данных – далеко не единственная задача, которую могут помочь решить продукты Beget, например, вы также можете:

· развернуть производительный VPS с готовностью за 10 секунд и готовыми решениями для ваших задач;

· подключить мощные облачные базы данных для разработки сложных веб-сервисов и приложений;

· настроить сеть доставки контента для снижения нагрузки на сервер и увеличения скорости загрузки сайта;

· удобно управлять инфраструктурой – с Kubernetes;

· обеспечить контроль и прозрачность изменений – с Terraform.

А еще облако Beget – это:

· глобальный охват – выбирайте локацию серверов в России или Казахстане и будьте ближе к вашей аудитории;

· новейшее железо – мощные серверные решения на базе Amd Epyc с NVMe-дисками;

· надежность и стабильность – благодаря uptime 99,98% и дата-центрам Tier III (стандарт с защитой от аварийных ситуаций);

· бесплатные автоматические бэкапы – копии создаются раз в 2–5 дней и хранятся на двух независимых серверах в разных дата-центрах;

· универсальный интерфейс – единая панель для управления всеми облачными решениями;

· комфортный мониторинг с возможностью кастомизировать правила для отслеживания состояния серверов;

· защита от атак – серверы защищены на сетевом и транспортном уровне (L3/L4), а наша собственная разработка Syncookied обеспечивает защиту от SYN/ACK/DATA-флуда;

· функциональный API – управляйте серверами и доменами без необходимости заходить в панель управления.

Если у вас остались вопросы, вы хотите обсудить эту статью или просто пообщаться с коллегами по цеху и сотрудниками Beget, будем рады видеть вас в нашем уютном Telegram-чате – с удовольствием на всё ответим и пообщаемся.

Также сейчас для новых пользователей мы начисляем 10% кешбэка за первое пополнение баланса – чтобы вы могли начать хранить данные еще выгоднее с самого первого дня.

Реклама. ООО «Бегет», ИНН 7801451618, erid: 2W5zFJqF2Y9

Есть классическая проблема: изолированные процессы — хорошо для надёжности, но хочется иногда позвать функцию из соседа, как будто она лежала в той же библиотеке. Стандартные IPC — это всегда протокол: описал интерфейс, сгенерировал стабы, поднял сервер, прописал адреса. simplerpc предлагает путь короче: ты пишешь обычную функцию на Си, линкуешь библиотеку — и она автоматически становится RPC-методом, доступным другим процессам на той же машине.

Архитектура держится на трёх решениях. Во-первых, данные едут не через сокет, а по разделяемой памяти — SHMEM. Аргументы вызова лежат в общем сегменте, отображённом по одному виртуальному адресу во всех процессах, и копирования между адресными пространствами нет. Сокет используется только для сигналов: регистрация функций, передача дескриптора памяти (SCM_RIGHTS), обнаружение смерти клиента. Во-вторых, свой аллокатор — транзакционный TLSF с откатом при падении процесса. Межпроцессный мьютекс встроен прямо в структуру пула, а если владелец мьютекса погибает, следующий автоматически откатывает незавершённую транзакцию. Пул консистентен без внешнего сторожа. В-третьих, вместо стандартных примитивов синхронизации — POSIX-семафоры в разделяемой памяти и lock-free MPMC-очередь для передачи задач от клиента к воркерам.

Но самое интересное — как демон оказывается в системе. Исполняемый файл демона не лежит на диске. Он встроен в libsrpc.so в виде C-массива, записывается в анонимный memfd целиком в оперативной памяти и запускается через fexecve(). При загрузке библиотеки любым приложением автоматически форкается демон. Если процессов несколько — проигравший гонку bind() на абстрактном Unix-сокете молча завершается. Когда последний клиент отключается — демон выходит, а память исчезает вместе с последней ссылкой на memfd. Никакого PID-файла, никакого init-скрипта, никакого сервиса. Библиотека сама себя разворачивает.

Библиотека организована так: guard daemon (фоновый координатор), транспорт (Unix-сокеты и SCM_RIGHTS), аллокатор TLSF с транзакциями, сборщик мусора в разделяемой памяти с hazard pointers, RPC через X-макросы (один файл — единственный источник истины), динамическая линковка через weak alias, дескрипторы процессов и потоков, lock-free очереди и синхронизация. Всё это — в bench/ можно найти бенчмарки, если захотите сравнить сами.

Попробовать три команды: mkdir build && cd build && cmake .. && make, затем в одном терминале ./log, в другом ./app. Готово.

Ограничения: только Linux, только локальные процессы на одной машине, ранняя стадия развития — API стабильностью не отличается. Функции с переменным числом аргументов не поддерживаются, указатели осмыслены только если адресуют разделяемый пул.

Репозиторий: github, лицензия Apache-2.0. Если интересно — смотрите код на Си.

Разбираемся, где именно ломается учет ИТ-активов, и как выстроить систему, при которой пропажа монитора обнаруживается не через полгода, а в момент, когда его выносят из офиса.

Учет — это всегда про прошлое

Событие случилось, вы его зафиксировали. Купили ноутбук — записали. Пользователь уволился и унес гарнитуру — узнали постфактум благодаря инвентаризации. Сервер умер — выяснили, что гарантия закончилась месяц назад. Это классический учет активов.

Учет отвечает на вопросы в прошедшем времени: что есть, где лежит, сколько осталось. Это снимок состояния на момент последней сверки. Необходимый для бухгалтерии, но практически бесполезный для вас.

Управление — это взгляд в будущее: у какого железа через полгода заканчивается жизненный цикл? Что нужно докупить до того, как это станет проблемой? На каком оборудовании пора планировать замену, чтобы оно не умерло под нагрузкой?

«Учет сам по себе не является управлением, а управление не может существовать без учета. Учет — это фундамент», — отмечает Анастасия Монокина, администратор проектов компании «ИнфраМенеджер». Проблема в том, что большинство ИТ-отделов сидят именно на фундаменте и даже не пытаются подняться выше.

Чем оборачивается такой подход:

• Внезапными поломками. Не потому что железо плохое, а потому что плановое обслуживание никто не отслеживал.
• Хищениями и потерями, которые обнаруживаются через полгода, когда уже никто не помнит, кто последним брал пропавший монитор.
• Закупками вслепую. Бизнес заказывает новую партию техники, а на складе пылятся нераспакованные коробки. Или наоборот — все уверены в наличии запаса, а его нет.
• Лицензионными сюрпризами. Приходит проверка и выясняется, что количество лицензий меньше числа инсталляций.

Отдельная боль — инструменты

Некоторые вендоры продают под видом ITAM-систем по сути те же таблицы, только с веб-интерфейсом.

Главная проблема этих решений в том, что данные в них устаревают быстрее, чем вы успеваете их обновлять. Парк живет своей жизнью: что-то перемещается между кабинетами, что-то уходит в ремонт, что-то обновляется, что-то умирает. В системе все красиво — карточки активов, вкладки, фильтры. Но данные статичны: вы завели карточку, и она лежит мертвым грузом до следующей инвентаризации.

Если ваш ITAM требует, чтобы вы руками поддерживали его актуальность, — это не ITAM, а еще одна задача в вашем бэклоге.

Как выглядит нормальный подход

Нормальный подход — управлять не перечнем техники, а жизненным циклом каждой единицы. От момента, когда кто-то сказал, что это нужно, и до момента, когда это уехало на утилизацию.

При нормальном подходе все изменения пишутся в историю. Напоминания о плановом обслуживании приходят сами. По любому активу в любой момент можно ответить: что это, где оно, кто за него отвечает, что с ним делали и что с ним будет дальше. Для этого не приходится поднимать архивы, листать переписки или идти спрашивать у Пети, который в курсе.

Когда данные начинают работать

Переход от учета к управлению — это не смена одной таблицы на другую, более красивую. Это смена логики: данные об активах начинают работать на вас, а не вы на них. «ITAM позволяет запустить бесперебойный конвейер имущественных операций, где каждый актив работает на компанию ровно столько, сколько нужно, и окупает каждый вложенный в него рубль», — поясняет Анастасия Монокина, администратор проектов компании «ИнфраМенеджер».

Один из сценариев, который админ обычно тащит на себе вручную — выдача техники: при заявке на новый ноутбук нужно открыть таблицу, сверить остатки, написать на склад, дождаться ответа. Когда процесс автоматизирован, система сама проверяет складские остатки и резервирует свободную единицу.

При увольнении сотрудника запускается бизнес-процесс возврата оборудования с контролем каждого шага: кто принял, что принял, в каком состоянии.

Если у какого-то актива истекает гарантия, вы получаете уведомление и успеваете загнать железо в ремонт по гарантии, а не через 3 дня после ее окончания.

Кроме того, система с заданной периодичностью сама опрашивает сеть. Частоту выставляете вы — под то, насколько динамично живет ваш парк.

Система собирает фактические данные об оборудовании и софте и сопоставляет их с учетными записями. При расхождении сама обновляет карточки. Железо и софт перестают быть черным ящиком. Фактическое состояние парка живет в системе, а не в чьей-то голове.

Вместо сбора данных по таблицам из всех отделов у вас появляется единая точка входа: запросы подразделений, текущий парк, сроки жизни активов, загрузка ресурсов. В следующий раз, когда прилетит задача провести инвентаризацию, вы откроете не Excel, а дашборд. Сверка займет всего несколько минут, потому что система уже все посчитала за вас.

За последний год путь от идеи до рабочей версии сжался с кварталов до дней, а заметную долю нового кода, по отраслевым оценкам, уже пишет ИИ. Собрать что-то работающее стало быстро и дёшево, и ценность ушла оттуда, где лежала последние двадцать лет. Раньше дефицитом было исполнение, и выигрывал тот, кто мог сделать. Сейчас порог входа в «сделать» резко упал, а дефицитом стало другое: понять, что именно делать, и решить это раньше остальных.

Для руководителя это разворот, к которому оказался мало кто готов. Его работа много лет была устроена вокруг распределения исполнения: кто, что, к какому сроку. Теперь ограничением стал он сам, точнее скорость, с которой он входит в контекст, принимает решение и передаёт его дальше вместе со смыслом.

Почему покупка инструмента ничего не даёт

Логичный ход в этой ситуации: купить ИИ и успокоиться. Так и сделали почти все, результат известен. По опросу McKinsey, регулярно применяют ИИ хотя бы в одной функции почти девять компаний из десяти, но прирост операционной прибыли от пяти процентов и выше связывают с ним около шести процентов. Предварительный отчёт MIT по корпоративным пилотам даёт картину ещё резче, хотя выборка там небольшая и рецензирования он не проходил.

Инструмент ускоряет операцию, которая уже есть в процессе. Если память о проектах живёт в головах и в переписке, а согласования идут кругами, ускорение отдельной операции почти не считывается: ограничение в другом месте. Способ работы в команде задаёт руководитель, значит, меняться должен в первую очередь он, а не только его инструментарий.

Шесть мест, где прежнее управление даёт сбой

Если разложить обычный день руководителя по слоям, сбои видно поимённо.

Встречи. Половину планёрки съедает пересказ статусов: работу памяти делают живые люди в самое дорогое время команды.

Решения. Вопрос, требующий анализа, встаёт в очередь и возвращается через недели, когда вводные уже поменялись.

Память. Через полгода никто не помнит, почему выбрали именно это, и спор «мы договаривались иначе» решается не фактом, а тем, у кого увереннее интонация.

Делегирование. Задача уходит строчкой в трекере, картина остаётся у постановщика, дальше недели переписки «я не то имел в виду».

Команды. Что происходит внутри, руководитель узнаёт раз в месяц на отчётке, а люди на грани ухода отчётки не ждут.

Развитие. Честную обратную связь про себя руководитель получает раз в полгода, поэтому слепые зоны живут годами.

Ни один из этих сбоев не новый. Новое то, что в прежнем темпе они были терпимы, а в нынешнем перестали, и первым это чувствует самый загруженный.

Глория Марк из Калифорнийского университета в Ирвайне меряла, что происходит с человеком, которого постоянно дёргают: прерванную работу люди дописывают не медленнее, но платят за это стрессом, спешкой и заметно большим усилием на тот же объём. Возврат к прерванной задаче она оценивала примерно в 23 минуты, и это не выброшенное время, а время, в течение которого голова тащит несколько контекстов сразу. У руководителя таких переключений десятки в день. Дело не в собранности: человеческий мозг просто не рассчитан на тот объём, который на него грузят.

Три операции, которые стали дефицитом

Здесь стоит сказать прямо, кого это касается в первую очередь. Войти в контекст, принять решение и передать его дальше вместе со смыслом это не работа тех, кто пишет код. Это работа руководителя команды, проектного менеджера и продакта, то есть ровно тех ролей, которым последние годы приходилось объяснять бизнесу, зачем они нужны, если продукт делают инженеры.

Когда исполнение стоило недели, эти три операции выглядели накладными расходами вокруг производства. Их старались сократить, а потери от неточной постановки размазывались по кварталу и никого не пугали. Сейчас реализация стоит часы, и неточная постановка оплачивается сразу: команда быстро и качественно делает не то. Ошибка в понимании задачи стала дороже ошибки в исполнении.

То же с решениями. Вопрос, требующий анализа, раньше вставал в очередь и возвращался через недели, когда вводные поменялись, и это было терпимо, потому что реализация всё равно шла месяц. Теперь за эти недели половина работы уже сделана в одну из сторон, и решение принимается задним числом.

И третье, самое неудобное. Контекст, который руководитель помнит сам и раздаёт кусками по мере вопросов, перестал быть рабочим способом: команда успевает сделать раньше, чем задаст второй вопрос. То, что годами считалось накладными расходами, стало в производстве самым дефицитным ресурсом, и спрос на эти роли вырос вместе с требованиями к ним.

Кто такой руководитель нового типа

Формула короткая: руководитель плюс ИИ-агент, с которым он работает в связке. Принципиально не название продукта, а роль: не инструмент, которому спихивают задачи, а второй контур, с которым думаешь.

Базовый уровень доступен сегодня каждому: разбор задач и исследований в диалоге с агентом, инженерный бэкграунд не нужен. Продвинутый уровень я называю вторым мозгом, и он устроен из трёх частей. Память направления в обычных текстовых файлах: решения, протоколы встреч, слой по каждому проекту и по каждому человеку. Агент, который эту память читает и пишет, а не просто отвечает на вопросы. И ритуалы, которые всё это прокручивают: утренний план, разбор встреч, недельная сводка, ежедневное зеркало.

Смысл конструкции в том, что она закрывает ровно те три операции. В контекст руководитель входит не по памяти и не по переписке, а по собранной картине темы. Решение готовится к встрече заранее, вместе с вариантами и возражениями. Задача уходит вниз не строчкой, а вместе с историей вопроса. Ни одна из трёх операций не исчезает, они перестают упираться в то, сколько человек успел вспомнить сегодня утром.

Правило «агент готовит, решает человек» произносят все, и оно почти ничего не гарантирует. В экспериментах Гарвардской школы бизнеса у людей с более качественным помощником усилие падало сильнее: они шли за рекомендацией не глядя и работали хуже тех, кому достался слабый инструмент, причём сами были уверены, что решают. Работает не декларация, а привычка просить не ответ, а развилку с аргументами против. Ошибается агент регулярно, поэтому спорное я перепроверяю в первоисточнике, а не в пересказе.

Про границы, потому что это спрашивают первым. Агент видит рабочий контур: отчёты и протоколы, к которым у меня и так есть доступ по роли. Личной переписки и скрытых от людей выводов там нет, и эту границу стоит проводить сознательно.

Что это дало в цифрах

Сразу оговорюсь: это опыт одного направления, а не исследование. Считал я сам, контрольной группы у меня нет.

Заметнее всего поменялись планёрки. Раньше около получаса из часа уходило на пересказ статусов, сейчас на это не уходит ничего: статусы собраны заранее и разосланы обеим сторонам до встречи, разговор начинается сразу с развилок. Час такой встречи закрывает порядка семи вопросов, большая часть мелкие, но раньше они расходились по переписке на неделю. Цикл «вопрос появился, решение принято» сжался с месяца до дня.

Появился и слой, которого раньше не было вообще: отчёты и протоколы, которые годами просто лежали, теперь складываются в общую картину. Дважды из неё стало видно то, чего мне не сказали вслух: человеку не с кем обсудить своё будущее в компании. Разговор случился в ту же неделю, а не через полгода на ревью.

Есть и внешний замер. Доля положительных ответов по опроснику Gallup Q12 в направлении выросла до 86,7%, плюс 6,6 процентных пункта, и сильнее всего вырос пункт «получал признание за последние семь дней», плюс 16,6. Отнести это целиком на свою систему я не могу, в тот же период менялось многое. Но выросло сильнее всего ровно то, чем она занимается.

Отдельно про себя. Я написал агенту «научи меня фасилитации», и с тех пор он разбирает, как я веду встречи, от встречи к встрече. Съехать не получается: он помнит, что я обещал себе в прошлый раз. Раньше обратную связь такого рода я получал раз в полгода и в основном про результаты, а не про то, как я работаю.

Делегировать надо контекст, а не строчку

Обычное делегирование устроено так. Руководитель формулирует задачу в две строки и отдаёт человеку, а вся картина остаётся у него в голове: зачем это делаем, что уже пробовали, чего боимся, кого ещё касается. Дальше человек восстанавливает её вопросами или, что хуже, не восстанавливает и делает не то. Мы годами считали это нормой, хотя это чистые потери. Теперь задача уходит вместе с контекстом: агент собирает историю темы, роль человека, связанные решения и ограничения, и всё это идёт частью постановки.

Из той же логики растёт вещь, которая вызывает больше всего сопротивления: часть задач руководителю быстрее собрать самому. Экономия тут не на наборе кода, а на кругах согласования: старый путь идеи проходит через постановку, согласование приоритета, очередь спринтов, передачу через несколько рук и возврат на доработку. Новый короче: сформулировал, собрал черновик сам, отдал команде. Новый раздел документации я собрал за полчаса, а до продакшена его довела команда и сделала это лучше, чем сделал бы я.

Здесь важна граница, и я её держу. Сам беру только то, чего иначе просто не появилось бы: черновики и прототипы, на которые никто не планировал время. Приоритеты команды я этим не двигаю и в чужой спринт не лезу.

С чего начинать

Первый шаг не требует ни бюджета, ни разрешения сверху: перевести отчёты и решения в текстовые файлы, которые одинаково читают и люди, и агенты. Звучит скучнее всего и меняет больше всего, потому что у направления впервые появляется память, которую можно спросить. Дальше отдать агенту разбор встреч и завести рабочий слой по ключевым людям и проектам.

Каркас собирается за день, дальше растёт сам. Порог тут не технический, а дисциплинарный: нужна привычка фиксировать, а не держать в голове. Мы годами автоматизировали продукт и процессы команд, а собственную работу руководителя не трогали, и начинать стоит именно с неё.

Что происходит с рутиной и с самим руководителем

Всё сказанное выше звучит как реклама, поэтому дальше вторая половина.

Рутина правда уходит в фон, освободившиеся часы уходят в проекты и в людей. Но работы меньше не становится: решения принимаются быстрее, значит, решений становится больше. Руководитель превращается в конвейер принятия решений, и это выматывает голову иначе, чем раньше. Обещать разгрузку было бы враньём.

Сместилось и ограничение. Раз исполнение перестало быть дефицитом, дефицитом стали люди, способные вести проект целиком, как свой бизнес: от цели до результата, с решениями внутри. Отсюда и сдвиг в том, чего ждут от роли. Раньше от человека ждали, что он сделает поставленную задачу, а решения внутри были приятным дополнением. Теперь наоборот. Это не значит, что кто-то стал не нужен: планка сдвинулась у всех сразу, включая меня. И моя работа как директора дотянуть до этого уровня своих людей.

В должностной инструкции руководителя нового типа не меняется ни один пункт. Меняется то, сколько их туда влезает: проектов, решений, людей, за которыми успеваешь следить не по остаточному принципу. Должность та же, потолок другой.

Потолок поднимается не покупкой. Инструмент можно купить в любой момент, а память можно только накопить, и эта фора набирается каждый день, пока вы решаете, начинать или нет.

1. Классика всех времен: страница NSM

Традиционная и самая распространённая архитектура в OLTP-СУБД (PostgreSQL, Oracle) — слотированная страница, относящаяся к семейству NSM (N-ary Storage Model). Страница, как правило, имеет фиксированный размер, чаще всего 8 или 16 КБ (может настраиваться параметром БД), и делится на три логические области:

· Заголовок страницы — содержит метаданные: размер страницы, количество слотов, смещение до свободного пространства и флаги.

· Таблица слотов — массив записей фиксированной длины, каждая из которых хранит смещение (offset) до начала соответствующей строки. Слоты упорядочены по позиции строки в таблице.

· Область данных — сами кортежи, расположенные последовательно, но в обратном порядке относительно таблицы слотов (данные растут с конца страницы в начало, а слоты — с начала в конец). Это позволяет эффективно управлять фрагментацией.

Особенности работы с изменениями на уровне страницы:

При обновлении строки, если её новый размер превышает старый, на старом месте сохраняется указатель (forwarding pointer), а обновлённая запись перемещается в свободную область страницы (или даже на другую страницу, если свободного места недостаточно). Это порождает цепочки переадресации, которые могут замедлять чтение.

При удалении строки соответствующий слот помечается как недействительный (например, устанавливается флаг deleted или смещение становится отрицательным). Физическое освобождение места происходит позже — при сборке мусора (VACUUM в PostgreSQL) или при перестройке страницы.

Главный недостаток:

Для запросов, которые читают миллионы строк, но выбирают лишь 2–3 атрибута из 20, NSM необходимо просканировать всю страницу целиком. В результате в кэш CPU загружаются все атрибуты, включая ненужные. Это не только увеличивает время I/O, но и порождает промахи кэша (cache misses), поскольку полезные данные перемешиваются с не нужными.

2. Колоночная страница DSM:

Научная работа Джорджа П. Коупленда и Сетрага Н. Хошафяна «A Decomposition Storage Model» (ACM SIGMOD) [1] предложила кардинально иной подход к организации данных на странице, получивший название DSM (Decomposition Storage Model).

В классической реализации DSM каждый атрибут таблицы хранится в отдельном наборе страниц. При этом страницы внутри одного атрибута содержат только значения этого столбца, расположенные в порядке строк. Для восстановления полной записи используется либо позиционный идентификатор (порядковый номер строки в странице), либо служебные битовые маски.

Преимущества на уровне страниц:

· Страница заполняется данными одного типа — это даёт значительный прирост в сжатии (RLE, дельта-кодирование, битовые карты) по сравнению с NSM-архитектурой.

· При сканировании одного-двух столбцов читается ровно столько страниц, сколько нужно для этих атрибутов, без загрузки не используемых в запросе колонок.

Обратная сторона:

Вставка или обновление строки требуют записи в страницы всех атрибутов, что превращается в доступ к множеству файлов и их соединение. Запрос SELECT * для ограниченного числа строк также вынужден выполнять дорогостоящее соединение страниц разных столбцов, что делает DSM неэффективной для OLTP.

Первоначально модель не получила широкого распространения именно из-за высокой стоимости сборки строк. Однако с ростом мощностей процессоров и объёмов оперативной памяти она стала основой для колоночных СУБД (Vertica, Greenplum, ClickHouse), где основная нагрузка — аналитические запросы.

3. PAX: гибридная модель данных

В 2001 году на конференции VLDB была представлена работа Анастасии Аламаки, Дэвида ДеВитта, Марка Хилла и Муниратнама Сивакумара «Weaving Relations for Cache Performance» [2], в которой авторы предложили комбинированный подход — PAX (Partition Attributes Crosswise).

Ключевая идея модели:

Страница остаётся целостной (содержит все атрибуты таблицы, как в NSM), что позволяет избавиться от дорогостоящих соединений файлов данных. Но внутри страницы данные разбиты по атрибутам: все значения первого атрибута собираются в непрерывный мини-блок. Следом идёт мини-блок второго атрибута, затем третьего, и так далее. В начале страницы располагается каталог (directory), указывающий смещение и размер каждого мини-блока.

Как происходит выборка данных:

Для запроса, выбирающего два столбца, СУБД обращается к странице и читает только те два мини-блока — остальные не попадают в кэш процессора, что снижает количество промахов.

Обновление всей строки не требует записи в отдельные файлы (как в DSM) — достаточно перезаписать соответствующие мини-блоки внутри одной страницы.

4. Современные реализации на основе PAX

Apache Parquet

Прямой наследник PAX. Файл разбивается на Row Groups (группы строк, типично 128 МБ – 1 ГБ), каждая из которых действует как крупная «страница» PAX. Внутри Row Group данные организованы по Column Chunks — это и есть мини-блоки разных атрибутов, только теперь они могут быть сжаты независимо друг от друга. Parquet также добавляет индексы и статистику на уровне Column Chunk (min, max, null count), что позволяет при сканировании пропускать целые блоки без разжатия.

Apache ORC (Optimized Row Columnar)

Аналог Parquet, используемый в Hive, Presto и Trino. Внутри ORC-файла выделяются Stripes (полосы), которые выполняют ту же роль, что и Row Groups в Parquet. Внутри Stripe данные хранятся по колонкам с добавлением индексов и словарей. По сути, это тоже PAX, но с более агрессивным сжатием и встроенной фильтрацией.

5. FastLanes — PAX, оптимизированный под SIMD и GPU

PAX-архитектура значительно улучшила предыдущие модели хранения данных, но она не учитывала характеристики процессора. Именно в этом направлении происходит дальнейшее развитие архитектуры хранения данных. Петер Бонч, учёный из исследовательского центра CWI (Нидерланды), предложил новый формат FastLanes, который оптимизирует хранение данных под возможности современных процессоров.

Файл FastLanes состоит из двух главных компонентов: Footer (футер) и Data (данные). Футер содержит метаданные, описание данных и их местонахождение в файле и может храниться отдельно от блока «Данные».

На верхнем уровне блок «Данные» повторяет архитектуру PAX: данные делятся на группы строк и атрибуты. В отличие от существующих типов файлов, в FastLanes группы строк содержат количество записей, кратное 1024. Это позволяет избежать материализации данных в основной памяти и выполнять всю работу на уровне процессора. Следующим важным нововведением является использование сжатия LWC (Light-Weight-Compression). Вместо тяжеловесных алгоритмов по типу Zstd, которые не позволяют распараллелить обработку данных, применяются FSST, DICT, ALP при каскадном (рекурсивном) применении которых достигается уровень сжатия Snappy за более короткий промежуток времени [3]. Кроме этого, для каждой колонки данных могут применяться разные операторы кодирования. Сжатые данные хранятся в сегментах, в которых кроме самих данных хранятся смещения на отдельные вектора, что позволяет читать данные на уровне одного вектора вместо целого блока, как в старых форматах.

Когда данные читаются из оперативной памяти в процессор, закодированный вектор, содержащий 1024 значения, разжимается и полностью помещается в кэш процессора. Напротив, старые форматы файлов не только используют непараллельные алгоритмы сжатия, но и применяют их к целым Row Group, что влечёт за собой использование основной памяти и уменьшение скорости обработки [3].

Использованные источники:

1. Copeland G.P., Khoshafian S.N. A Decomposition Storage Model. Proceedings of ACM SIGMOD, 1985.
2. Ailamaki A., DeWitt D., Hill M., Sivakumar M. Weaving Relations for Cache Performance. Proceedings of VLDB, 2001.
3. Boncz P., Afroozech A., et al. The FastLanes File Format: specification.

Python для этого подходит идеально: на нем пишут и быстрые прототипы с MVP, и промышленные серверные и высоконагруженные системы. Значит, распознавание можно встроить прямо в то приложение, где данные уже обрабатываются, без отдельного сервиса между ними.

Smart ID Engine распознает удостоверяющие личность документы и отдает структурированные данные и изображения отдельных полей: фото владельца, подпись, штамп. Полный код доступен на GitHub.

Пошаговое встраивание в Python-приложение

1. Подключение библиотеки

Для подключения библиотеки в проект необходимо скопировать в ваш проект файлы обертки (папка bindings), саму библиотеку (папка bin) и конфиг распознавания (папка data-zip с файлом bundle_…se). Обертку и библиотеку нужно подключить в проект:

и импортировать библиотеку:

2. Создание движка распознавания

Движок распознавания создается из конфига распознавания (data-zip/bundle_…se). В параметрах необходимо указать путь к нему и параметр ленивой инициализации (True/False). При значении False все внутренние объекты будут инициализированы сразу не дожидаясь, когда они понадобятся для какой-то конкретной сессии.

3. Настройка распознавания

Настройка распознавания (settings) включает в себя выбор режима распознавания (mode), маски документа (document type masks), а также при желании указание дополнительных опций. Для распознавания документа по одному изображению используется режим singleshot (если документ распознается по нескольким картинкам — default). Для внутреннего паспорта РФ требуется специфицировать маску документа, указав rus.passport.national в доступных к распознаванию документах.

4. Распознавание документа

Сессия распознавания паспорта РФ подразумевает распознавание одного документа (по одному или нескольким кадрам). Для распознавания другого документа создайте новую сессию, настройки можно оставить те же. Создание сессии осуществляется путем указания ранее созданных настроек (settings) и персонализированной подписи (personalized_signature).

Загрузка изображения паспорта РФ по пути (path_to_image):

Распознавание паспорта:

Получение результата:

5. Извлечение информации из результата распознавания

Тип документа

Вывод:

Описание документа

Вывод:

Текстовые поля

Включают все текстовые строки, которые были извлечены с документа

Вывод:

Полный вывод содержит более 30 полей, включая информацию об органе выдачи и MRZ-строку.

Поля изображений

Включают в себя вырезанные из исходного документа зоны интереса при их наличии. Для паспорта РФ — это подпись владельца, подпись органа выдачи, фото владельца, штамп.

Вывод:

Заключение

Как можно убедиться, распознавание паспорта можно легко встроить на Python. На выходе система Smart Engines возвращает структурированный результат, включая текстовые данные, подписи, печати и другие реквизиты и атрибуты документа.

При этом распознавание паспорта на Python – не единственный вариант интеграции Smart ID Engine. Та же библиотека может работать и как часть мобильного или десктоп-приложения, а также прямо в браузерах или мессенджерах. Выбор конкретного варианта зависит от того, какие документы нужно распознавать и откуда поступает изображение – подробнее об этом можно прочитать на сайте Smart Engines.

Реклама. Рекламодатель: ООО «Смарт Энджинс Сервис» ИНН 7728328449, erid: 2W5zFJof1MB

Подростки уже используют нейросети для учебы, поиска информации, создания изображений, текстов и презентаций. Но между «задать вопрос ChatGPT» и полноценным освоением искусственного интеллекта есть большая разница.

На курсах ИИ для подростков можно научиться не только составлять запросы, но и создавать собственные проекты: чат-ботов, сайты, игры, изображения, видео и приложения. А если программа связана с Python, ребенок получает еще и техническую базу для дальнейшего изучения машинного обучения и разработки AI-продуктов.

В этом рейтинге собрали топ-5 курсов по ИИ для подростков. Сравнили возраст, программу, формат, продолжительность, стоимость и результаты обучения.

Рейтинг ориентирован прежде всего на подростков примерно от 12 лет. При этом некоторые программы начинаются раньше или продолжаются до 17 лет.

Как мы составляли рейтинг?

При сравнении учитывали содержание программы, возраст учеников, формат занятий, длительность, практическую составляющую, наличие наставника, проекты и возможность получить сертификат.

Отдельно смотрели, насколько курс подходит именно подросткам. Для этой возрастной группы важно постепенно переходить от простого использования готовых нейросетей к пониманию принципов работы ИИ, критической оценке результатов и созданию собственных проектов.

В рейтинг вошли программы, где искусственный интеллект или нейросети являются самостоятельной частью обучения, а не дополнительным инструментом.

Информация актуальна на 2026 год. Стоимость и расписание могут меняться, поэтому перед записью стоит проверить условия на сайте школы.

Сравнительная таблица

1. Pixel

Школа программирования Pixel предлагает несколько программ, связанных с искусственным интеллектом. Для подростков особенно интересны два направления: Python и ИИ и создание приложений с искусственным интеллектом.

Курс «Python и ИИ» рассчитан на детей 10–13 лет. На нем подростки изучают Python, создают чат-ботов и умных помощников, а также работают над собственными проектами с элементами ИИ.

Программа состоит из трех модулей по 12 занятий. Одно занятие длится 90 минут, обучение проходит один раз в неделю. Полный курс занимает около 4,5–9 месяцев.

Для старших подростков 14–17 лет есть курс по созданию приложений с ИИ. Здесь искусственный интеллект объединяется с мобильной разработкой: ученики проектируют интерфейсы, создают приложения и знакомятся с использованием AI-функций.

Занятия проходят онлайн в Zoom. Доступны группы до 12 человек и индивидуальный формат. На сайте школы также указано, что AI-курсы подходят как новичкам, так и ученикам с подготовкой.

Плюсы: разные уровни сложности, программирование + ИИ, проектный подход, индивидуальный и групповой формат.

Минус: для старших подростков технические AI-программы требуют больше времени и вовлеченности.

Кому подойдет: подросткам, которые хотят не только пользоваться нейросетями, но и создавать с их помощью программы, приложения и другие цифровые продукты.

2. CODDY

Курс «Нейросети для детей: промпт-инжиниринг» рассчитан на подростков 13–16 лет и подходит начинающим.

Главная тема — работа с запросами к нейросетям. Дети учатся формулировать промпты для текстовых и графических моделей, создавать мультимедийные проекты и автоматизировать различные задачи.

В программе используются YandexGPT, GigaChat, Kandinsky и «Шедеврум». Среди проектов — комиксы, видеоролики, музыкальные треки, сайт-визитка и виртуальный собеседник.

Полный курс рассчитан на 36 занятий по 1,5 часа, один раз в неделю. Занятия проходят онлайн или очно с персональным наставником.

Программирование и английский язык для старта не требуются. Есть бесплатный пробный урок и сертификат после окончания обучения. Отдельное внимание уделяется цифровой безопасности и проверке информации, которую генерирует ИИ.

Плюсы: персональный наставник, много практики, 36 проектов, обучение с нуля.

Минус: курс в большей степени посвящен использованию готовых AI-инструментов, чем программированию собственных моделей.

Кому подойдет: подросткам, которые хотят научиться эффективно использовать нейросети для учебы, творчества и создания цифрового контента.

3. Фоксфорд

У Фоксфорда есть направление обучения нейросетям для школьников. Один из вариантов — курс «Нейросети: код и создание запросов» для учеников 12–17 лет.

Программа знакомит подростков с принципами работы современных ИИ-моделей и учит формулировать запросы для решения практических задач.

Особенность подхода — обучение через проекты. На каждом уроке ученик решает практическую задачу, а итогом становятся собственные работы, которые можно собрать в портфолио.

Формат обучения — онлайн. В зависимости от программы доступны занятия с преподавателем и другие варианты обучения.

Плюсы: возрастная программа именно для подростков, практические задания, портфолио, связь ИИ с программированием.

Минус: условия и стоимость зависят от выбранного формата и программы.

Кому подойдет: подросткам 12–17 лет, которые хотят разобраться в основах ИИ и одновременно научиться правильно взаимодействовать с нейросетями.

4. Нейрокадо

Нейрокадо специализируется именно на обучении детей и подростков искусственному интеллекту.

Программы рассчитаны на возраст 9–17 лет, поэтому старшие школьники могут выбрать более сложные проекты. Занятия проходят онлайн индивидуально.

В обучении используются GPT, Claude, Midjourney, Stable Diffusion и другие инструменты. Более продвинутые программы включают HTML/CSS, JavaScript, API и AR-технологии.

Главная особенность — практический результат. Подросток может создавать игры, сайты, AR-проекты, изображения и другие работы, которые затем можно включить в портфолио.

Предусмотрены тарифы на 4, 8 и 12 занятий в месяц: 12 000, 20 000 и 27 000 рублей соответственно. До готового проекта и Demo Day можно дойти примерно за 8–12 недель.

Плюсы: индивидуальное обучение, большое количество AI-инструментов, технические проекты, портфолио.

Минус: индивидуальный формат делает курс дороже групповых программ.

Кому подойдет: подросткам, которые хотят заниматься ИИ персонально и создавать более сложные цифровые проекты.

5. Академия Эдюсон

Курс «Python и нейросети для школьников» рассчитан на детей от 11 лет. В отличие от программ, посвященных преимущественно промптингу и генерации контента, здесь ИИ изучается вместе с программированием.

Курс длится 12 месяцев и построен в формате стажировки. Ученик постепенно осваивает Python, алгоритмы, работу с файлами, объектно-ориентированное программирование и инструменты искусственного интеллекта.

В программе используются YandexGPT, Perplexity и AI-IDE. Среди проектов — умный помощник, дневник с генерацией текста, игра с AI-презентацией, тамагочи с AI-видео и сайт-визитка.

Всего программа включает 20 проектов и 48 интерактивных уроков. Первое занятие предоставляется бесплатно.

Плюсы: Python + ИИ, большое количество проектов, годовая программа, портфолио.

Минус: для подростка, которому нужны только нейросети для творчества, курс может оказаться слишком техническим.

Кому подойдет: школьникам от 11 лет, которые хотят связать искусственный интеллект с программированием и будущей IT-профессией.

Как выбрать курс ИИ для подростка?

Определите цель

Если подросток хочет научиться создавать изображения, видео и тексты, подойдет курс по нейросетям и промптингу.

Если интересует программирование, лучше выбирать Python и ИИ.

Если хочется создавать сайты, игры и приложения, стоит искать программы, где AI объединен с веб-разработкой или программированием.

Учитывайте уровень подготовки

Для первого знакомства не обязательно знать Python или другие языки программирования. Например, на курсе CODDY программирование не требуется.

А вот технические программы Pixel и Эдюсон предполагают более глубокое погружение в код.

Смотрите на проекты

Хороший курс должен отвечать на вопрос:

«Что подросток создаст за время обучения?»

Комикс, сайт, чат-бот или изображение — уже практический результат. Для более серьезной траектории можно выбирать курсы, где появляются приложения, игры и программные проекты.

Обращайте внимание на обратную связь

Подростку может быть сложно самостоятельно разобраться, почему нейросеть выдает плохой результат или код не работает.

Поэтому важно заранее выяснить, кто проверяет задания и как ученик получает помощь.

Не забывайте о цифровой безопасности

ИИ может выдавать убедительные, но ошибочные ответы. Подростку важно научиться проверять информацию, не передавать нейросетям личные данные и понимать ограничения генеративных моделей.

FAQ

С какого возраста можно изучать ИИ?

Начинать можно уже в младшем школьном возрасте, но для подростков доступны более сложные программы. В рейтинге есть курсы от 10–11 лет и отдельные программы для 13–17 лет.

Нужно ли знать программирование?

Нет. Для курсов по промптингу и генеративному ИИ программирование часто не требуется. Если подросток хочет создавать AI-приложения, лучше постепенно освоить Python или другой язык.

Что выбрать: нейросети или Python?

Если цель — научиться пользоваться готовыми AI-инструментами, достаточно курса по нейросетям. Если подросток хочет в будущем создавать собственные AI-продукты, стоит выбрать Python и ИИ.

Сколько длится обучение?

Продолжительность сильно различается: от нескольких недель до года. Например, курс CODDY рассчитан на 36 занятий, а программа Эдюсон — на 12 месяцев.

Что должно остаться после курса?

Желательно, чтобы подросток получил не только сертификат, но и портфолио: сайты, чат-боты, игры, изображения, приложения или другие собственные проекты.

Можно ли учиться ИИ онлайн?

Да. Все пять представленных программ предусматривают онлайн-обучение полностью или частично.

Итоги

ИИ для подростков — это уже не только генерация картинок или ответы чат-бота. Хорошая образовательная программа помогает школьнику понять принципы работы нейросетей, научиться составлять запросы, проверять результаты и использовать искусственный интеллект для решения реальных задач.

Если нужен мягкий старт без программирования, стоит обратить внимание на CODDY или Фоксфорд. Для индивидуальной работы с большим количеством AI-инструментов подойдет Нейрокадо. Если интересует сочетание программирования и искусственного интеллекта, сильнее выглядят Pixel и Академия Эдюсон.

Перед покупкой курса стоит определить главную цель подростка: научиться пользоваться нейросетями, создавать контент или разрабатывать собственные AI-проекты. После этого сравнить программы по возрасту, формату, нагрузке, стоимости и количеству практики.

И обязательно стоит воспользоваться пробным занятием, если оно предусмотрено. Для подростка важнее всего не количество заявленных нейросетей, а то, сможет ли он после курса самостоятельно использовать ИИ и создавать с его помощью что-то свое.

• Учетная запись имела многофакторную аутентификацию (что после компрометации сессии значения не имеет).
• SIEM собирал события, но расследование затруднялось тем, что в разных источниках один и тот же пользователь имел разные идентификаторы.
• Доступ сотрудника был вовремя отозван в Active Directory, но остался в одном из SaaS-сервисов.
• Резервное копирование выполнялось ежедневно, но восстановить критичный сервис в установленный RTO невозможно.

Значит ли это, что мы должны отказываться от формальностей? Нет, конечно. Соответствие требованиям необходимо. Без него невозможно выстроить управление ИБ, тем более в регулируемых отраслях.

Но здесь легко попасть в ловушку формального контроля,

Ведь соответствие требованиям — это подтверждение того, что определенные правила и процедуры существуют. Требования задают определенный минимальный уровень контроля, но не могут описать всю конкретную инфраструктуру компании, все зависимости между системами, особенности бизнес-процессов и все возможные сценарии атаки.

Предлагаю посмотреть на области, которые уже соответствуют требованиям, немного другим взглядом. Рассмотрим MFA, SIEM, управление доступом, DLP и прочие моменты с точки зрения слабых мест бумажной безопасности.

№1. Управление доступом

Классическая проверка часто выглядит довольно просто: открыл карточку пользователя — посмотрел назначенные роли. Но современные корпоративные инфраструктуры редко устроены настолько просто:

• права могут наследоваться через группы;
• группы могут быть вложенными;
• доступ может назначаться через роли приложений;
• часть полномочий приходит из Active Directory, часть — из локальных каталогов приложений, часть — через облачные сервисы.

В результате пользователь может не иметь ни одной явно назначенной привилегированной роли, но при этом обладать весьма серьезными полномочиями. Условно: пользователь — группа А — группа Б — роль — ресурс.

Но это ещё ничего. В некоторых случаях проблема возникает, когда у пользователя не «слишком много» прав, а когда он получил вполне допустимые права, которые вместе создают недопустимый сценарий. Допустим, у сотрудника есть доступ к системе платежей, но нет права непосредственно проводить операции.

• Отдельно у него есть доступ к справочнику контрагентов.
• Отдельно — возможность изменять определенные реквизиты

Каждое разрешение по отдельности может быть легитимным, но комбинация полномочий создает возможность изменить данные так, что можно влиять на финансовую операцию (SoD-конфликт). Именно поэтому зрелое управление доступом должно анализировать не только отдельные права, но и комбинации полномочий.

Как исправить?

На практике начать нужно не с проверки списка ролей пользователя, а с построения его эффективной модели доступа. То есть смотрим не только на то, какие роли ему назначены напрямую, а проходим всю цепочку наследования: учетная запись, группы, вложенные группы, роли приложений, права на конкретные информационные системы и критичные операции.

Особенно внимательно стоит смотреть на привилегированные и конфликтующие полномочия.

Для таких проверок можно использовать выгрузки из IAM и каталогов учетных записей, данные из прикладных систем и матрицы доступа. В крупных инфраструктурах без автоматизации быстро упираешься в объем: вручную проверить несколько тысяч пользователей и десятки тысяч связей практически невозможно.

Отдельно я бы рекомендовал регулярно искать «сиротские» права: доступы пользователей, которые уже сменили должность, не используют конкретную систему или вообще должны были быть отключены.

Главный результат такой проверки для меня не количество найденных нарушений. Важнее понять, можем ли мы для каждого критичного доступа ответить на три вопроса:

• кто им обладает
• зачем он ему нужен
• что произойдет, если этот доступ будет скомпрометирован

№2. SIEM

На этапе внедрения обычно обсуждают количество источников, EPS, правила корреляции, хранение и стоимость инфраструктуры. Но после запуска появляется более сложная задача: расследование.

Представим, что мы хотим понять, что делал пользователь за два часа до подозрительной операции.

• В Active Directory он имеет один идентификатор.
• В VPN используется логин в другом формате.
• В EDR устройство связано с третьим идентификатором.
• В бизнес-приложении пользователь представлен внутренним UUID.
• Часть сетевых событий вообще содержит только IP-адрес.
• При этом DHCP уже выдал этот адрес другому устройству.

События есть, но нет готовой цепочки: пользователь — устройство — IP — приложение — действие. А почему нет? Точнее, почему ее может не быть? Обычно вопрос количества логов не стоит — их у всех достаточно. Препятствия бывают с качеством телеметрии и ее нормализацией, когда события невозможно связать между собой. Здесь даже очень дорогая SIEM не сможет превратить их автоматически в полноценную картину инцидента.

Как исправить?

При проектировании мониторинга я бы оценивал не только количество подключенных источников. Эффективнее взять один реальный сценарий атаки и пройти его от начала до конца: какое событие появится первым, где оно окажется, с чем будет связано, кто и как его увидит, какие дополнительные данные сможет получить аналитик и сможет ли он восстановить всю цепочку действий. Если на каком-то этапе приходится вручную искать информацию в пяти разных системах, это уже часть проблемы.

№3. MFA

Многофакторная аутентификация — обязательный элемент современной защиты. Но здесь тоже легко попасть в ловушку формального контроля.

Допустим, сотрудник действительно проходит MFA. Что это дает? Снижается вероятность успешного использования украденного пароля. Но после успешной аутентификации возникает другая сущность — сессия.

Если злоумышленник получает действующий токен или иным способом использует уже авторизованную сессию, то включена MFA или не включена — не так важно. Важны другие механизмы:

• Контроль жизненного цикла сессий.
• Привязка сессии к контексту устройства.
• Анализ активности.
• Повторная аутентификация для критичных операций.
• Контроль изменения параметров сессии.
• Обнаружение резкого изменения географии или характера работы.

Причем здесь особенно хорошо видно, почему нельзя строить безопасность вокруг отдельных продуктов. MFA — это один контроль, EDR — другой, UEBA — третий, SIEM — четвертый, а атака проходит не через «продукты», а через инфраструктуру. Поэтому важно понимать, какой участок цепочки атаки закрывает каждый контроль и что происходит между ними.

Как исправить?

При настройке контроля нужно обращать внимание на жизненный цикл сессии: срок действия токена, возможность его повторного использования, требования к повторной аутентификации, привязку к устройству и контексту доступа.

Для критичных операций полезно отдельно проверять, требуется ли повторное подтверждение. Например, вход в корпоративное приложение с нового устройства и изменение реквизитов платежа не должны рассматриваться как одно и то же по уровню доверия.

Кроме того, MFA не должна существовать изолированно. Ее эффективность существенно повышается, если события аутентификации связаны с данными IAM, EDR, VPN и SIEM.

Тогда вместо простого события «пользователь успешно прошел MFA» мы можем увидеть контекст:

• пользователь вошел впервые с нового устройства;
• подключился из нетипичной сети;
• через несколько минут получил повышенные полномочия;
• после этого начал обращаться к ресурсам, с которыми раньше не работал.

Каждый признак отдельно может быть допустимым. Вместе они уже требуют внимания.

Поэтому при проверке MFA я рекомендую тестировать не только сам механизм второго фактора, но и сценарии его обхода и использования уже авторизованной сессии.

Это гораздо ближе к реальной модели угроз, чем простая галочка «MFA включена».

№4. Исключения

Это категория, которую часто недооценивают. Как часто вы слышали эти фразы:

• «У нас так принято».
• «Эта система всегда была доступна из этой сети».
• «Эти учетные записи давно никто не трогает».
• «Это временно, потом исправим».

Практически в любой крупной инфраструктуре есть системы, которые нельзя сразу перевести на стандартные политики:

• Старое приложение требует нестандартного сетевого доступа.
• Критичная система не поддерживает современный механизм аутентификации.
• Отдельный сервис должен работать с расширенными привилегиями.

Создаётся исключение. Изначально оно абсолютно рационально, но позже появляется проблема.

Инфраструктура меняется, появляются новые СЗИ, приложение модернизируется, ответственные сотрудники меняются, а исключение остается. Через два-три года уже никто не помнит, почему оно вообще было создано. В результате стандартное правило может выглядеть очень хорошо, а несколько исторических исключений фактически формируют отдельный контур безопасности.

Поэтому исключения должны иметь не только владельца и обоснование. У них должен быть срок жизни. Если исключение нельзя пересмотреть через, например, год, возникает вопрос: почему оно «исключение»?

Как исправить?

Сделать исключения управляемыми.

Полностью избавиться от исключений в крупной инфраструктуре практически невозможно. Но задача ИБ не в том, чтобы запретить исключения, а в том, чтобы не позволить им превратиться в постоянную дыру в защите.

На практике, я бы вел отдельный реестр исключений с такими полями:

• какое требование нарушается;
• для какой системы;
• по какой причине;
• кто владелец риска;
• какой срок действия;
• какие компенсирующие меры применяются.

Последний пункт особенно важен.

Если систему невозможно подключить к современному механизму аутентификации, это не означает, что остается только написать в документе «невозможно технически». Можно ограничить сетевую доступность, разрешить доступ только с определенных станций, усилить мониторинг, добавить дополнительные проверки или ограничить круг пользователей.

То есть исключение должно иметь цену. Если мы не можем применить основной контроль, мы должны понимать, чем компенсируем этот недостаток.

Еще одна практика, которую я считаю полезной, это автоматический пересмотр исключений. У исключения должна быть дата, когда его снова необходимо рассмотреть. Иначе временное решение очень быстро становится частью архитектуры.

Особенно опасны исключения без владельца. Если через год никто не может ответить, кто и зачем разрешил конкретный обход контроля, такое исключение уже само по себе является находкой для аудита.

№5. DLP

Еще одна интересная история происходит с защитой от утечек. Представим, что пользователь выгрузил 5 ГБ документов. На первый взгляд это серьезный повод для блокировки. Но теперь добавим контекст:

• Пользователь работает в подразделении, которое регулярно формирует архивы.
• Выгрузка выполняется в рабочее время.
• Получатель — внутренний корпоративный ресурс.

Такая операция может быть абсолютно нормальной.

Теперь другой сценарий. Пользователь обычно работает с несколькими десятками мегабайт в день. Сегодня в 02:00 он впервые подключился с нового устройства, скачал несколько ГБ архивов, после чего попытался передать их во внешний сервис. Объем тот же и с точки зрения простой сигнатурной логики — просто 5 ГБ, но по контексту совершенно другая история.

Поэтому эффективный контроль утечек данных давно не ограничивается вопросом: «Сколько данных передано?», а гораздо интереснее: кто, что, откуда, куда, когда, каким способом и насколько это соответствует его обычному поведению?

И именно здесь становится особенно важной интеграция DLP, IAM, UEBA, сетевой телеметрии и данных о бизнес-контексте. Отдельный продукт может увидеть только часть картины, а инцидент возникает на пересечении этих данных.

Как исправить?

Добавлять контекст к событиям DLP.

При настройке DLP я бы отдельно проверял не только политики блокировки, но и качество классификации данных, корректность исключений и интеграцию с IAM, SIEM и UEBA.

Очень важно также не пытаться блокировать все подозрительное автоматически.

Для критичных сценариев автоматическая блокировка оправдана. Для пограничных случаев лучше передать событие аналитику с максимально полным контекстом.

В противном случае можно получить классическую проблему DLP: система формально защищает данные, но сотрудники начинают искать способы обойти ее из-за большого количества ложных срабатываний.

№6. Время

Представим, что на одном сервере время отличается на три минуты. На другом используется другой часовой пояс. Ещё одна система пишет время в UTC.

Часть событий приходит в SIEM с задержкой и для обычной эксплуатации это может быть незаметно. Во время расследования трехминутная разница способна полностью изменить последовательность событий. А последовательность для расследования критична. Что было первым?

• Компрометация учетной записи?
• Создание нового процесса?
• Подключение к серверу?
• Выгрузка данных?
• Изменение прав?

Если временная шкала построена неправильно, то и аналитик может сделать неверный вывод даже при наличии всех необходимых событий. Поэтому качество телеметрии это не только вопрос того, собираются ли логи, это еще и вопрос, насколько этим логам можно доверять?

Как исправить?

Начать стоит с единого источника времени для всей инфраструктуры. На критичных системах проверить не только наличие NTP, но и то, откуда конкретно система получает время, насколько стабильно работает синхронизация и что происходит при недоступности основного источника.

Но одной синхронизации недостаточно.

Для SIEM важно привести события к единому формату времени и явно понимать, какое время записано в каждом событии: время возникновения события на источнике, время его обработки или время поступления в SIEM. Это три разных значения, и смешивать их при расследовании нельзя.

Отдельно я бы проверял задержку доставки событий. Например, сервер может корректно зафиксировать событие в 02:13, но SIEM получить его только в 02:16. Если аналитик строит временную шкалу только по времени поступления, последовательность действий уже будет искажена.

Поэтому при проверке мониторинга важны несколько вещей: синхронизация времени, единый часовой пояс и формат временных меток, задержка доставки событий и наличие технических меток, позволяющих отличить время события от времени его поступления.

И самое главное, это нужно проверять не на уровне документации, а на практике. Создать несколько контролируемых событий на разных системах, зафиксировать фактическое время их возникновения и посмотреть, в каком порядке они появляются в SIEM.

Если после такого теста невозможно уверенно сказать, какое событие произошло первым, значит проблема уже не в NTP. У нас проблема с доказательной базой для расследования.

№7. Автоматическое реагирование

Чем больше СЗИ появляется, тем сильнее желание автоматизировать реакцию.

• Обнаружили подозрительную активность — заблокировали пользователя.
• Нашли подозрительный процесс — остановили.
• Увидели аномальное подключение — заблокировали IP.

С технической точки зрения все логично. Но автоматизация сама становится источником риска.

Представим, что UEBA ошибочно определила нормальную активность привилегированного пользователя как аномальную и система блокирует учетную запись. А это единственный человек, который в данный момент может устранить критичную неисправность в продуктивной среде.

Получается парадокс: защитный механизм сам создает отказ в обслуживании. Поэтому автоматизация должна учитывать не только вероятность атаки, но и стоимость ошибочной блокировки.

Для одного сценария автоматическая блокировка оправдана. Для другого правильнее будет создать высокий приоритет и передать решение аналитику. И здесь снова появляется необходимость понимать не технологию, а бизнес-контекст.

Как исправить?

Не стоит спешить с автоматизацией всего, что кажется поддающимся автоматизации. Сначала нужно определить, какие последствия будет иметь ошибка автоматического действия.

Условно, все реакции можно разделить на несколько уровней.

• Первый уровень — действия с минимальным влиянием на бизнес. Например, добавить IP-адрес или хеш файла в дополнительный список мониторинга, повысить приоритет события, собрать дополнительную информацию об узле.
• Второй — обратимые действия. Например, временно ограничить сетевое соединение или изолировать рабочую станцию от сети. Здесь уже необходимо понимать, что произойдет с бизнес-процессом и как быстро вернуть все в штатное состояние.
• Третий — критичные действия: блокировка привилегированной учетной записи, отключение сервера, остановка процесса, изменение прав доступа. Такие реакции я бы разрешал автоматически только для хорошо проверенных сценариев с низкой вероятностью ложного срабатывания и понятным механизмом отката.

На практике полезно начинать с режима, в котором автоматическое правило сначала только фиксирует событие и предлагает действие аналитику. По результатам работы можно оценить количество ложных срабатываний и только после этого переводить конкретный сценарий в автоматический режим.

Отдельно нужно работать с исключениями. Например, если автоматизированное правило изолирует рабочие станции, должны существовать понятные условия для критичных серверов, аварийных учетных записей и других объектов, блокировка которых может привести к более серьезным последствиям, чем сама угроза.

И обязательно должен существовать механизм отката. Если система автоматически заблокировала пользователя или изолировала сервер, должно быть понятно, кто, на основании чего и за какое время может вернуть его в рабочее состояние.

В итоге, автоматизацию стоит оценивать не по количеству действий, которые выполняются без участия человека, а по более ценному показателю — сколько времени она действительно экономит при приемлемом уровне риска ошибочной реакции.

Как я бы проверял зрелость ИБ

Вообще, если посмотреть на большинство зрелых инфраструктур, можно заметить одну закономерность.

Проблема редко находится внутри одного средства защиты. Она возникает на стыке:

• IAM знает, кто пользователь.
• EDR знает, что происходило на его АРМе.
• SIEM видит последовательность событий.
• DLP знает, какие данные передавались.
• Сетевая инфраструктура знает, куда устанавливалось соединение.
• PAM записал сессию.

Но если эти данные не связываются, каждый продукт видит только свою часть атаки.

Например, EDR фиксирует запуск PowerShell, прокси видит соединение с внешним ресурсом, DLP видит обращение к чувствительному файлу, а IAM знает, что пользователь недавно получил повышенные права.

По отдельности ни одно событие может не быть критичным. Вместе же они формируют опасную цепочку. Именно поэтому зрелость ИБ-инфраструктуры я бы оценивал не только по набору решений, а по тому, насколько хорошо они складываются в единую модель событий.

Есть достаточно простой подход: вместо того чтобы составлять очередной список из сотни пунктов, можно взять несколько наиболее опасных для конкретной организации сценариев, например, компрометация привилегированной учетной записи и пройти всю цепочку:

• Как получен доступ?
• Что видит IAM?
• Что видит EDR?
• Какие события попадают в SIEM?
• Как обнаруживается аномалия?
• Что происходит с сессией?
• Кто принимает решение?
• Какие действия будут предприняты?

Такие проверки дают намного больше информации, чем ревизия документов или очередной чек-лист. Хоть чек-листы могут быть очень полезны, но у них есть фундаментальное ограничение — они хорошо отвечают на вопрос: «Выполнено ли условие?» И плохо отвечают на вопрос: «Что произойдет, если несколько условий одновременно будут нарушены?» Потому архитектурные проверки должны дополняться сценарным тестированием.

Отдельно затронем метрики

Есть ещё одна проблема зрелой ИБ — неправильные метрики. Например, можно гордиться тем, что SOC обработал 50 000 алертов за месяц, но само число ничего не говорит, потому что можно сократить количество алертов в 10 раз и одновременно ухудшить безопасность, если просто отключить некоторое количество правил, а можно увеличить количество обнаруженных инцидентов и решить, что ситуация стала хуже, хотя по факту обнаружение улучшилось.

Поэтому метрика должна быть связана с конкретным результатом:

• Не «SIEM подключила 500 источников». А «Для X% критичных сценариев атаки SOC получает достаточный набор телеметрии для расследования».
• Не «Резервное копирование выполняется ежедневно». А «Критичная система восстанавливается за X часов при заданном сценарии отказа».
• Не «Права пользователей пересматриваются ежеквартально». А «X% привилегированных доступов имеют подтвержденного владельца, бизнес-обоснование и актуальную дату пересмотра».

Заключение

Самая опасная иллюзия в ИБ в слепой вере в защиту, когда компания защищает свою инфраструктуру большим количеством правильных средств, но не знает, насколько хорошо они работают вместе.

• MFA есть, но остается риск компрометации сессии
• PAM есть, но существуют обходные пути
• SIEM есть, но телеметрия не позволяет восстановить цепочку событий
• и т.д. и т.п.

Именно поэтому я бы не задавал вопрос: «Соответствует ли наша система требованиям ИБ?», правильнее задавать несколько более неприятных вопросов:

• Что конкретно произойдет при компрометации привилегированной учетной записи?
• Что мы увидим в первые пять минут?
• Какие данные позволят восстановить цепочку атаки?
• Какие защитные механизмы атакующий сможет обойти?
• Что произойдет, если один из них откажет?

И самое главное:

• Можем ли мы доказать на практике, что наша защита работает именно в том сценарии, от которого она должна нас защищать?

Но здесь не нужно противопоставлять compliance и техническую безопасность. Требования нужны. Аудиты нужны. Регламенты нужны. Но их правильнее воспринимать как нижний уровень системы управления.

После того как требование выполнено, мы должны понимать, а какой реальный риск мы этим контролем снижаем? Как мы проверим, что риск действительно снизился?

Если «понимание» заключается только в наличии документа, отчета или установленного класса решений, контроль, скорее всего, оценивается слишком формально. Если же можно показать реальный сценарий, измерить результат и воспроизвести его повторно, ситуация уже совсем другая.

Соответствие требованиям — это подтверждение того, что определенные правила и процедуры существуют. А информационная безопасность начинается там, где эти правила сталкиваются с реальной инфраструктурой, реальными ограничениями и реальной атакой.

Разбираем все три слоя: как получить трассировку, не переписывая сервисы, как превратить трассы в метрики, по которым можно действовать, и как не принять смену методики измерения за изменение продукта.

Трассировка через eBPF снимает налог на ручное инструментирование, но требует ядра не ниже 5.8, несрезанной таблицы символов и знания устройства планировщика Go.

При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов в ядро ежесекундно и потолок расхода в 200–600 мс процессорного времени на ядро.

Медленный запрос это не одна проблема, а пять разных: лишняя работа, борьба за ресурсы, давление среды, деградация плана и патологические шаблоны вроде N+1.

Инструменты базы говорят, что дорого внутри неё, но не говорят, какой сервис это вызвал и был ли запрос пользовательским. Этот контекст приносят трассы.

Версия браузера, тип навигации, библиотека сбора данных и версия инструментирования входят в определение метрики: смешав их в одном графике, вы увидите изменение измерения вместо изменения продукта.

Слой первый наблюдаемости: собрать данные, не трогая код

Ручное инструментирование обходится дороже, чем кажется на старте. Каждая точка вызова библиотеки, каждая ветка передачи контекста и каждое извлечение сопутствующих данных — это код, который расходится с реальностью, забывается в горячем пути и стоит процессорного времени на высокой частоте запросов.

Альтернатива, ставшая эксплуатационно пригодной за последние пару лет, — подключение зондов eBPF напрямую к символам рантайма и точкам входа библиотек HTTP и gRPC. Трассы восстанавливаются из событий ядра и пользовательского пространства, а файл бинарника на диске не меняется вовсе: правки идут только в памяти работающего процесса, точечно и обратимо.

Почему с Go это сложнее, чем с C

Зонд работает так: в заданное смещение работающего бинарника ставится инструкция прерывания, при попадании в неё ядро останавливает поток, выполняет свою программу и возобновляет исполнение. Для C и Rust это ложится на прологи функций почти без остатка. Go добавляет три осложнения.

Планирование горутин. Планировщик Go раскладывает множество горутин на меньшее число системных потоков. Один HTTP-запрос может обрабатываться горутиной на одном потоке в момент срабатывания зонда и переехать на другой поток до записи ответа. Наивный зонд, читающий идентификатор потока или процесса, теряет непрерывность на этом переезде. Правильный якорь — идентификатор горутины, а достать его можно либо через карту, построенную по отладочной информации, либо вычислением фиксированного смещения от указателя, лежащего в регистре локального хранилища потока.

Соглашение о вызовах. В Go 1.17 аргументы функций переехали со стека в регистры, причём сначала только на amd64; на arm64 и ppc64 это произошло версией позже. Программа зонда, написанная под прежнее соглашение и читающая контекст со смещения от указателя стека, на новых бинарниках прочитает мусор. Значит, трассировщику нужна либо логика зондов под каждую минорную версию языка, либо вычисление места по отладочной информации самого бинарника.

Встраивание функций. Компилятор Go агрессивно встраивает мелкие функции, и нужный символ может просто отсутствовать по ожидаемому адресу. Зонд, поставленный не туда, даёт пропущенные отрезки трассы или испорченные аргументы, причём молча.

Отдельная ловушка при разборе событий:
Структура на стороне потребителя должна побайтово совпадать со структурой в программе зонда, включая выравнивание. Расхождение в один байт приводит к тому, что все поля после первого декодируются неправильно, а внешне это выглядит как случайный мусор в трассах.

Главная нерешённая проблема: передача контекста между сервисами

Если нельзя вписать заголовок в коде приложения, как передать идентификатор трассы дальше по цепочке вызовов? Есть три подхода, и практически применим один.

• Писать заголовок прямо в пакет на уровне сетевого интерфейса. Требует расширенных привилегий и работает только для нешифрованного HTTP/1.1: шифрование выполняется выше уровня сокета, и программа видит уже зашифрованные байты.
• Пропускать исходящие вызовы через локальный вспомогательный прокси, который держит соответствие идентификатора горутины и контекста трассы и вставляет заголовки перед пересылкой. Добавляется сетевой переход, зато шифрование не ломается.
• Править карту заголовков прямо в памяти процесса. Соответствующая функция ядра помечена как опасная и действительно способна повредить память: каждая её загрузка пишет предупреждение в журнал ядра, работа требует широкой привилегии CAP_SYS_ADMIN, а в режиме блокировки ядра она запрещена совсем.

Единственный вариант, который одновременно совместим с шифрованием, безопасен и разворачивается где угодно, — второй. Его цена в задержке составляет обычно меньше 100 мкс на переход через локальную петлю, что приемлемо, когда сами измеряемые операции занимают миллисекунды.

Что ломается в продакшене

• Идентификаторы горутин переиспользуются. При высокой конкурентности номер может уйти на новую горутину раньше, чем потребитель разобрал события старой.
• Обновление бинарника сдвигает смещения символов. Зонды старого отображения ядро снимает само, и новый бинарник какое-то время работает без трассировки. Слежение за изменением файла сокращает разрыв до секунд, но не убирает его.
• Требования к ядру. Кольцевые буферы нужны ядру от 5.8, а переносимая компиляция зондов требует 5.4 с включённой отладочной информацией о типах. Матрицу ядер стоит проверить до внедрения, а не после.
• Срезанные бинарники. Сборка без таблицы символов и отладочной информации лишает трассировщик возможности сопоставить имена функций со смещениями. Компромисс: оставить хотя бы таблицу символов, заплатив примерно 10–15% размера бинарника.

Сколько это стоит в процессорном времени

Зонды не бесплатны: каждое срабатывание это программное прерывание с входом в ядро. При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов ежесекундно. Опубликованные замеры дают порядка 1–3 мкс на срабатывание на современном оборудовании, то есть верхняя оценка расхода составляет 200–600 мс процессорного времени в секунду на одно ядро.

Цифра ощутимая, но сравнивать её стоит с альтернативой, а не с нулём. Автор разбора оценивает эту альтернативу в десятую часть рабочего времени разработчиков, уходящую на сопровождение кода инструментирования. Потребителя событий при этом лучше держать на отдельной горутине, привязанной к ядру, которое не обслуживает запросы, чтобы выделение памяти под отрезки трасс не мешало обработке.

Правильный вывод не «заменить инструментирование зондами», а «использовать оба». Зонды дают сплошное покрытие и базовое распределение задержек без усилий разработчиков, включая сторонние бинарники, которые вы не можете изменить. Ручное инструментирование даёт смысловое наполнение: идентификатор пользователя, арендатора, флаг функциональности — то, чего из сырых байтов HTTP не синтезировать. Наиболее точные схемы наблюдаемости держат оба слоя, причём слой зондов работает проверкой на непротиворечивость для отрезков, которые приложение теряет под нагрузкой.

Слой второй: превратить трассы в решения

Собранная телеметрия сама по себе ничего не улучшает. Больше телеметрии означает больше объектов для разглядывания, а не больше понимания. Полезной она становится, когда из неё извлечены закономерности, на которые можно действовать.

«Медленный запрос» это пять разных диагнозов

Прежде чем что-то чинить, стоит понять, чем именно болен запрос. Разбор CNCF раскладывает медленные запросы к базе на пять непохожих причин:

• Лишняя работа. Обычно это полный перебор таблицы из-за отсутствующего или неприменимого индекса. Выборка по идентификатору клиента без индекса растёт с 20 мс на десяти тысячах строк до минут на десяти миллионах. Запрос не менялся, изменился объём данных.
• Борьба за ресурсы. Идеально оптимизированный запрос стоит в ожидании блокировок или свободного соединения. Запрос, проводящий 95% времени в ожидании блокировки, оптимизацией текста не лечится: ему нужна перекройка транзакций.
• Давление среды. Насыщение процессора, узкое место ввода-вывода и нехватка памяти замедляют любой запрос с любым планом: тот же текст запроса и тот же план на нагруженной машине отработает в разы дольше, чем на свободной, и оптимизировать тут нечего.
• Деградация плана. Данные и текст запроса те же, а план исполнения изменился. Устаревшая статистика после массовой загрузки заставляет планировщик выбрать заведомо плохую стратегию.
• Патологические шаблоны. Проблема N+1 выполняет сотню быстрых запросов по две миллисекунды последовательно, добавляя двести миллисекунд задержки на одно только выполнение, не считая сетевых издержек на каждый обмен с базой. Ни один запрос не является медленным, а шаблон катастрофичен и в журнал медленных запросов не попадает вовсе.

Чего не хватает встроенным инструментам базы

Журналы медленных запросов, хранилища запросов и разбор планов прекрасно отвечают на вопрос, что дорого внутри базы. Они не отвечают на вопросы, которые задаёт дежурный инженер: какой сервис это вызвал, пользовательская это работа или фоновая, связано ли это со всплеском задержки, который сейчас расследуется.

Этот контекст приносит распределённая трассировка: каждый отрезок обращения к базе вложен в контекст запроса и знает сервис, конечную точку и инициатора. Вместо того чтобы вручную сшивать журналы базы с трассами постфактум, медленные запросы анализируются прямо из трасс со всем прикладным контекстом внутри.

Дальше из отрезков трасс выводятся метрики, и делается это в три приёма: сперва простое обнаружение медленных запросов, затем взвешивание по трафику, чтобы понять, что даст наибольший выигрыш при ускорении, и наконец поиск аномалий для дежурства. Первые два отвечают на вопрос оптимизации, третий — на вопрос реагирования на инцидент, и путать их не стоит: это разные задачи с разными приоритетами.

Слой третий: не принять смену измерения за изменение продукта

Третья ошибка самая обидная, потому что данные при этом верны. Метрика может быть абсолютно точной, а рассказанная по ней история — совершенно неверной.

Дальше примеры пойдут из веб-производительности, потому что там эта ошибка задокументирована лучше всего. Механика же общая: любой дашборд, где смешаны серии с разных популяций или с разных версий сбора, ведёт себя одинаково, будь то задержки бэкенда или отрисовка страницы.

Общий тренд не объясняет вашу просадку

В июньском наборе данных о реальных пользователях Chrome, опубликованном в середине июля, доля источников с хорошей отрисовкой основного содержимого упала до 67,7%, с хорошей задержкой отклика на взаимодействие до 85,9%, а доля проходящих все три ключевых показателя до 55,3%. Исключением оказалась стабильность вёрстки, поднявшаяся до 81,4%.

Google объяснил движение сезонностью, сравнив его с прошлым годом. Контекст полезный, но он не является доказательством того, что у вас локально ничего не сломалось. Релиз, рекламная кампания, изменение формы согласия, сдвиг в составе устройств или новый сторонний скрипт способны совпасть с общеотраслевым движением.

Гарри Робертс формулирует критерий проверки прямо: если общая доля прошедших упала на 1,2 процентного пункта, а конкретный сайт просел на четыре, широкий тренд разницу не объяснил. Верно и обратное: если сайт почти идеально повторяет рынок по браузерам и устройствам, срочное расследование в коде потратит время всей команды впустую.

Правильное сравнение поэтому не «этот месяц против прошлого». Сравнивайте движение сайта с общей дельтой, разделяйте мобильные и настольные устройства, смотрите на показатели отрисовки и отклика по отдельности и разбирайте важные шаблоны страниц, а не источник целиком.

Изменение методики выглядит как изменение продукта

Дальше будет сложнее. По мере того как браузеры начинают показывать переходы внутри одностраничных приложений, которые метрики первоначальной загрузки пропускали, на одном дашборде окажутся жёсткие навигации, мягкие навигации браузера и собственные виртуальные страницы приложения, причём каждая серия собрана с разной популяции пользователей.

Смешав их без оговорок, вы получите скачок графика, вызванный сменой методики, и потратите неделю на поиск несуществующей регрессии. Отсюда практическое требование: версия браузера, тип навигации, библиотека сбора данных и версия инструментирования перестают быть служебными деталями и становятся частью определения метрики. Дашборд должен нести отметки релизов, состав трафика и устройств и внятное указание, какую популяцию представляет каждый график.

Компенсация это не исправление

Ещё одна ловушка того же рода: браузеры учатся скрывать последствия проблем. Привязка прокрутки к содержимому подправляет позицию, когда над областью просмотра что-то вставилось или исчезло, и читателя перестаёт выбрасывать с того места, которое он разглядывал.

Улучшение реальное, но документ по-прежнему перевёрстывается, если у картинки не заданы размеры или объявление меняет высоту. Браузер убирает одно видимое следствие, а причина остаётся на месте. Проверять после такого изменения стоит липкие шапки, ленты, интерфейс согласия и встроенные блоки, а чинить всё равно вёрстку, а не полагаться на маскировку.

Тот же разрыв виден и в метрике отклика. Большинство команд сегодня способны сказать, плохой у них отклик или нет. Заметно меньше способны сказать, какое именно взаимодействие в этом виновато, на каком шаге пользовательского пути оно случилось и что его задержало. Весь разбор Гарри Робертса именно про этот разрыв между наличием числа и наличием понимания.

Что забрать с собой

Три слоя решают три разные задачи, и провал на любом из них выглядит одинаково: дашборд есть, ответа нет. Без покрытия вы не видите части системы. Без перевода трасс в метрики видите всё и не понимаете ничего. Без дисциплины в чтении принимаете смену методики за регрессию.

Начинать проще всего с третьего слоя: он не требует ни новой инфраструктуры, ни единой строчки кода, только дисциплины чтения. Сверьте движение своих метрик с движением рынка и убедитесь, что расследуете настоящую регрессию, а не смену методики. Дальше уже видно, чего не хватает: покрытия или перевода трасс в решения.

Материалы разбора: устройство трассировки Go-сервисов через eBPF, перевод медленных запросов в метрики надёжности и разбор того, как метрики вводят в заблуждение.

Разбираем три расследования — пропавшую запись в базе, три процента сообщений, терявшихся только на чистой машине, и гонки в биллинге, которые видит одна поддержка. У всех трёх разные предметные области и одна общая методика поиска невоспроизводимых багов.

Отсутствие закономерности само по себе является находкой: если сбой не привязан ни к шарду, ни к клиенту, ни к времени суток, это указывает на гонку, а не на данные.

Когда воспроизвести дефект синтетически нельзя, остаётся пассивная телеметрия в продакшене и последовательное отсечение гипотез данными.

Счётчики на каждом слое находят виновника быстрее логов: разрыв между двумя соседними числами прямо называет слой, в котором теряются сообщения.

Вежливый тест, который шлёт запрос и ждёт ответа, скрывает целый класс ошибок пакетирования. Пачечный тест их обнажает.

Отсутствие ошибок не доказывает, что дефект исправлен. Доказательством служит положительный сигнал: сработавшее предупреждение о том, что опасные условия возникли, а сбоя при этом не случилось.

Случай первый: запись, которой не могло не быть

Управляющий слой Tailscale разбит на шарды, у каждого своя база SQLite, и обращается к ней ровно один процесс. Такой однописательный режим — именно то, для чего SQLite и предназначен, что делает дальнейшее особенно неприятным.

Резервное копирование снимало полную копию базы каждые несколько минут и складывало файл в объектное хранилище. Работало это без единого происшествия с начала 2023 года, пока конвейер, читавший резервные копии, не сообщил об ошибке. Проверка встроенной командой контроля целостности подтвердила худшее: база повреждена.

Первый случай сочли единичным. Базу починили, причину не нашли. Потом это повторилось. И ещё раз. Всего до устранения первопричины набралось 19 отдельных инцидентов за полгода, и каждый означал простой: процесс на шарде останавливался, пока базу чинили или восстанавливали. На ранних инцидентах простой превышал час, и всё это время у клиентов на шарде не работали консоль администратора и API.

Почему он не поддавался обычным приёмам

Дефект сопротивлялся всем стандартным подходам сразу:

• Не на что было списать: низкоуровневый код работы с базой никто не трогал годами, а внимательное чтение ничего не дало.
• Не нашлось общих факторов. Повреждения не привязывались ни к конкретному шарду, ни к клиенту, ни к функции продукта, ни ко времени суток, ни к уровню нагрузки.
• Он не воспроизводился синтетически. Надёжного триггера не было, поэтому оставалось только развернуть пассивную телеметрию в боевой среде и ждать следующего случая.

Расписания у инцидентов тоже не было: они случались то через часы, то через недели. Между октябрём и декабрём наступила шестинедельная тишина, после которой повреждения вернулись.

Команда сделала два шага, которые и составляют суть этой истории. Купила контракт поддержки у разработчиков SQLite, получив прямой доступ к людям, написавшим саму базу. И методично составила список гипотез, отсекая их данными, а не рассуждениями. В списке были сломанные блокировки при закрытии файла, неверная работа с памятью, принадлежащей базе, и обращение из нескольких потоков при отключённой потокобезопасности. Каждый инцидент приносил данные, каждая гипотеза отпадала по очереди.

Улика: транзакция, которой не стало

Пока первопричину искали, платформу надо было держать живой. Команда автоматизировала жёсткую остановку при обнаружении повреждения, поставила монитор, непрерывно проверявший целостность резервных копий, и переписала инструкции по восстановлению. Время восстановления упало ниже часа.

А затем построила конвейер журналирования транзакций. Идея простая: писать каждый изменяющий базу запрос в отдельный журнал. Поскольку писатель один, а транзакции сериализуемы, история изменений линейна и детерминирована, и её можно проиграть поверх последней заведомо целой копии, обойдя повреждённые страницы. Приём годится там, где порядок фиксаций известен: при единственном писателе он получается сам собой. Наивный журнал запросов на многописательной базе этого не даёт, потому что конкурентные транзакции переплетаются и без явного порядка фиксаций проигрывание не восстановит то же состояние.

Конвейер сработал и выдал улику. В двух инцидентах журналы не проигрывались чисто: данные, записанные и зафиксированные одной транзакцией, оказывались необъяснимо невидимы для последующих. Запись исчезла бесследно и без единой ошибки.

Этого не может быть. В сериализуемой однописательной базе зафиксированная запись не может пропасть. Значит, виноват слой с достаточной конкурентностью, чтобы такое спрятать, а такой слой ровно один — контрольные точки.

Шестнадцатилетняя гонка

SQLite с журналом предзаписи работает с двумя файлами. База — это набор страниц; при изменении данных новые страницы пишутся не в основной файл, а сначала в журнал. Позже контрольная точка переносит их в базу. Обычно момент переноса SQLite выбирает сам, но Tailscale управляла контрольными точками вручную, чтобы снимать быстрые согласованные копии. Именно этот нестандартный, хотя и полностью документированный выбор и вывел их на дефект.

Метрики во время инцидентов показывали, что SQLite сообщает о переносе большего числа страниц, чем в журнале вообще было. Разработчики базы как раз готовили инструмент для этого слоя: обёртку над виртуальной файловой системой, которая пишет дополнительные трассировочные журналы. Обёртку развернули в продакшене, и ждать пришлось недолго.

Журналы показали редкую гонку данных (race condition) между контрольной точкой и пишущей транзакцией. Если запись происходит в определённый момент работы контрольной точки, та сбивается: считает часть страниц перенесёнными в основной файл, хотя перенос не состоялся. Данные теряются навсегда, а страницы, которые на них ссылаются, например индексные, записываются как ни в чём не бывало. Файл становится структурно повреждённым, что проверка целостности всё это время и фиксировала.

Дефекту дали имя по сбросу журнала предзаписи и оценили его возраст минимум в шестнадцать лет. Он прожил так долго именно из-за редкости, это классический heisenbug: чтобы поймать его в тестовой среде, разработчикам пришлось дописать код, вызывающий гонку намеренно.

Ложная тревога, чуть не сорвавшая исправление

Исправление вышло в версии 3.52.0, и Tailscale раскатывала его осторожно, начав с нескольких канареечных шардов. После общей раскатки монитор резервных копий немедленно покраснел, сообщив о повреждении в тринадцати базах.

Настоящего повреждения не было. В ту же версию попала оптимизация, слегка изменившая округление при переводе текста в число с плавающей точкой, а Tailscale хранила метки времени высокой точности текстом и превращала их в числа в вычисляемом столбце. Индекс по вычисляемому выражению перестал соответствовать новому результату вычисления, и проверка целостности честно назвала это повреждением. Канареечные шарды дефект пропустили просто потому, что на них не оказалось меток времени, попадающих под изменённое округление.

Разбирали это с трёх сторон сразу. Разработчики SQLite отозвали версию целиком и выпустили 3.51.3, содержавшую только исправление гонки. Tailscale перешла на хранение меток времени целыми секундами, поскольку перевод текста в целое число однозначен. А в 3.53.0 появилось автоматическое восстановление таких индексов, чтобы проблема не возникала впредь.

Главный урок этого эпизода:
Канареечная выкатка проверяет только те формы данных, которые в канарейке есть. Если на канареечных узлах нет тех же значений, что в проде, канарейка не подтверждает ничего. Это касается и обновлений самой базы, драйверов и инструментов миграции, а не только кода приложения.

Как доказали, что дефект действительно исправлен

Самая дисциплинированная часть расследования пришлась на финал. Отсутствие повреждений доказательством не считалось: команда уже пережила шесть недель обманчивой тишины. Поэтому драйвер базы пропатчили так, чтобы он выдавал предупреждение всякий раз, когда пишущая транзакция и сброс журнала пересекаются во времени.

Логика прямая: если предупреждение сработает, а база останется целой, значит, исправление сработало ровно там, где раньше был бы инцидент. Ждали два месяца. Предупреждение сработало, подтвердив, что условия для гонки в их среде действительно возникают. С того момента прошло ещё четыре месяца без единого происшествия с базами.

Случай второй: три процента, терявшиеся только на чистой машине

Второй сюжет проще по масштабу и полезнее в быту. Сервис представлял собой небольшой пересыльщик TCP: принять соединение, читать текстовые строки, передавать дальше. На тестовом стенде входило 97 004 строки, а выходило 94 183. Ни ошибок, ни исключений, просто пропавшие сообщения.

На ноутбуке автора всё воспроизводилось идеально: сто тысяч строк на входе, сто тысяч на выходе. Это расхождение и было первой уликой — тест проверял не то, что делает продакшен.

Сменить машину раньше, чем код

Первый час, по его собственному признанию, ушёл впустую: менялись и бинарник, и машина, и профиль нагрузки разом, а выводов это не давало. Дальше автор поменял ровно одну переменную: взял чистый сервер с тем же бинарником и тем же скриптом нагрузки. Потери появились снова, 97 128 строк из ста тысяч. Среда меняла вероятность проявления, но не сам факт дефекта, а чистая машина без истории и без накопленных настроек работает как микроскоп для ошибок синхронизации.

Считать, а не логировать

Дальше нужен был не ещё один прогон, а способ понять, на каком слое теряются сообщения. Логи рассказывают истории, счётчики складываются. Автор расставил счётчик на каждом слое: клиент считает отправленные строки, сервер считает разобранные переводы строки, сервер считает отправленные ответы, клиент считает полученные ответы. Один прогон, четыре числа, и разрыв между соседними прямо называет виновный слой.

Сервер разобрал всё до последней строки, а ответов отправил меньше, чем разобрал. Это отпечаток пальца конкретного дефекта, и дальше оставалось найти его в коде ответа.

read() ничего не обещает про сообщения

Виновником оказалась одна строка: сервер отправлял по одному ответу на каждое чтение, а не на каждую разобранную строку.

TCP — это поток байтов, а не очередь сообщений. Вызов чтения не имеет понятия о том, что такое одно сообщение в вашем протоколе. Ядро вправе слить десяток сообщений в один сегмент, и одно чтение заберёт все десять, а ответ уйдёт один.

Вежливый локальный тест отправлял сообщение, дожидался подтверждения и отправлял следующее. Одно сообщение на сегмент — дефект спал. Нагрузка на стенде шла пачками, тысячами сообщений в секунду, ядро их группировало, одно чтение проглатывало сотню строк.

Исправление переносит ответ внутрь цикла по строкам и накапливает остаток в буфере, чтобы пережить строку, разорванную между двумя чтениями. Это вторая половина того же семейства ошибок, и без неё починка неполная:

Вывод автора расследования:
Локальный тест это не нагрузочный тест, ноутбук это не сервер, а одно чтение из сокета это не одно сообщение.

Третий сюжет: гонки, которые видит только поддержка

Третий сюжет про биллинг кредитов на бессерверном Postgres, где транзакции по условиям задачи были недоступны. Автор наткнулся на четыре гонки, разберём две самые показательные. Все они, по его собственной формулировке, относятся к тому сорту дефектов, которые не показываются в тестах и показываются в почте поддержки.

Классический двойной расход

Наивная версия, которую пишут первой:

Два одновременных запроса читают баланс, равный пяти, оба проходят проверку, оба записывают четыре. Пользователь получил две операции по цене одной. Дефект существует ровно между чтением и записью, и последовательный тест в это окно не попадает никогда.

Инвариант переезжает в условие запроса

Общее решение — сделать проверку и запись одним оператором, перенеся условие корректности в WHERE:

Одиночный UPDATE в Postgres атомарен. Не хватило баланса — условие не совпало, вернулось ноль строк, и вы точно знаете, что списание не произошло. Транзакция для этого не нужна вовсе. Приём обобщается: перенесите инвариант в условие выборки, и запись просто не случится, когда инвариант нарушен.

Вебхук, доставленный дважды

Платёжные провайдеры повторяют доставку уведомлений при таймаутах, пятисотках и сетевых сбоях, а иногда дублируют событие и в штатном режиме. Если обработчик начисляет кредиты, доставка «хотя бы один раз» означает начисление хотя бы один раз.

Обычное решение с таблицей обработанных событий требует транзакции, а её нет: падение между двумя операторами либо начислит дважды при повторе, либо потеряет начисление совсем. Рабочий вариант в один оператор использует изменяющее данные обобщённое табличное выражение, где вставка в журнал операций работает воротами: не прошла вставка, значит, не выполнилось и обновление баланса.

Деталь, которую стоит забрать отдельно: уникальный индекс под эту схему должен быть частичным. Начисления от администратора приходят с произвольным идентификатором из скрипта, и глобальный уникальный индекс рисковал бы столкнуть их друг с другом или с идентификатором операции другого типа. Приветственные начисления идут вообще без идентификатора, и с ними коллизии не будет в любом случае: Postgres не считает два пустых значения равными. Ограничение индекса двумя типами операций от платёжного провайдера держит проверку уникальности ровно там, где она нужна.

Что из этого складывается

Первые два расследования дают общую методику поиска, и она изложена ниже. Третий случай стоит особняком: это не детектив, а набор приёмов, которые убирают целый класс гонок ещё на этапе проектирования, до того как искать станет нечего.

Что забрать с собой

Общего у трёх расследований больше, чем различий. Во всех трёх случаях проверка была написана в форме, которая не воспроизводит реальность: последовательный запрос вместо пачки, одиночный вызов вместо конкуренции, одна машина вместо двух. И во всех трёх дефект спокойно проходил через тесты, а в случае с SQLite прожил так шестнадцать лет.

Соседний сюжет про то, как тесты перестают отражать реальность, разбирали в материале о том, почему статичные моки убивают тестирование.

Полезнее всего здесь дешёвые привычки. Счётчик на границе каждого слоя ставится за час. Пачечный клиент пишется за вечер. Датчик, доказывающий исправление положительным сигналом, добавляется одной строкой в драйвер. Всё это стоит несопоставимо меньше, чем полгода расследования.

Три постмортема, на которых строится разбор: разбор Tailscale о поиске шестнадцатилетнего бага в SQLite, ретроспектива потери трёх процентов сообщений и четыре гонки в биллинге на бессерверном Postgres.

Возьмите самый подозрительный сервис и запустите по нему пачечный тест вместо последовательного. Это самый дешёвый способ узнать, какой из ваших дефектов сейчас спит.

Искусственный интеллект постепенно становится частью школьной жизни. Дети используют нейросети для поиска информации, подготовки презентаций, создания изображений и текстов, а старшие школьники — для программирования, разработки сайтов, игр и приложений.

Но просто дать ребенку доступ к нейросети недостаточно. Важно научить его понимать возможности и ограничения ИИ, правильно формулировать запросы, проверять полученные ответы и использовать технологии не только для получения готового результата, но и для создания собственных проектов.

В этом рейтинге собрали школы и курсы, где дети изучают искусственный интеллект, нейросети, промптинг и AI-инструменты. В таблице можно быстро сравнить программы по возрасту, формату, стоимости и результатам, а в карточках — подробнее разобраться в особенностях обучения.

Информация основана на открытых данных, собранных в августе 2026 года. Цены, расписание и условия обучения могут меняться, поэтому перед записью стоит проверить актуальные данные на сайте школы.

Как мы составляли рейтинг?

Для сравнения изучили официальные сайты школ и страницы конкретных программ. Учитывали возраст учеников, содержание курса, формат занятий, длительность, стоимость, наличие пробного урока, наставника, домашних заданий, проектов и сертификата.

В рейтинг попали программы, где искусственный интеллект или нейросети являются самостоятельным направлением либо занимают заметную часть обучения.

Мы не ставили школы в жесткую иерархию «от лучшей к худшей». Место в подборке отражает полноту информации о программе и ее соответствие критериям сравнения. Для ребенка 9 лет, подростка с опытом Python и школьника, который хочет только попробовать нейросети, оптимальными могут оказаться совершенно разные варианты.

Если какой-либо параметр школа публично не раскрывает, это отмечено в статье как «не указано».

*Возраст зависит от конкретной программы.

Карточки школ

1. Pixel

У Pixel есть несколько AI-направлений для разных возрастов. Для детей 10–13 лет предусмотрен курс Python и ИИ, где нейросети связаны с программированием. Ученики создают игры, чат-ботов, рекомендательные системы, интеллектуальных помощников, голосовых ассистентов и другие проекты.

Занятия проходят онлайн в Zoom. Можно выбрать мини-группу до 8 человек или индивидуальный формат. Курс состоит из трех модулей по 12 занятий, каждое длится 90 минут. При занятиях один-два раза в неделю программа рассчитана примерно на 4,5–9 месяцев.

Для подростков 14–17 лет есть направление по созданию приложений с искусственным интеллектом. Здесь в программу входят Figma, интерфейсы, мобильные приложения, чат-боты и AI-функции.

Стоимость зависит от направления и формата; на отдельных программах указана цена от 800 ₽ за занятие. Есть пробные форматы и сертификат.

Плюсы: широкий возрастной охват, проекты, связь ИИ с программированием, разные форматы.

Минус: стоимость некоторых программ нужно уточнять отдельно.

Кому подойдет: детям, которые хотят не только пользоваться нейросетями, но и создавать с их помощью собственные цифровые продукты.

2. Rebotica

Курс «ИИ и нейросети для детей» рассчитан на школьников 9–11 лет. Обучение построено вокруг практических задач: ребенок создает тексты, изображения, музыку, видео, игры и сайты.

Программа включает 36 занятий по 60 минут и девять проектов. Среди итоговых работ — игра, мультфильм, комикс или сайт.

Занятия проходят индивидуально онлайн с наставником. График можно адаптировать, а при необходимости занятия переносить. Стоимость начинается от 6 376 ₽ в месяц, доступна рассрочка на 12 месяцев.

Отдельное преимущество — внимание к безопасности: школьники знакомятся с дипфейками, защитой данных и правилами работы с AI.

Плюсы: индивидуальный формат, много проектов, наставник, гибкий график.

Минус: программа в первую очередь ориентирована на младших школьников.

Кому подойдет: ребенку 9–11 лет, который хочет попробовать ИИ через творчество и простые цифровые проекты.

3. Фоксфорд

У Фоксфорда есть несколько вариантов обучения ИИ: от короткого базового курса по нейросетям до более продолжительных программ.

На сайте упоминаются направление «Нейросети: код и создание запросов» для 12–17 лет и базовый курс по нейросетям с нуля для учеников 5–11 классов.

На занятиях школьники учатся создавать запросы, работать с ИИ-моделями и использовать нейросети в учебных и творческих задачах. В качестве результатов названы сайты, виртуальные ассистенты, игры и другие AI-проекты.

Есть групповые и индивидуальные занятия, а базовый курс можно проходить в записи. Вводный формат включает пять занятий и стоит 990 ₽.

Плюсы: разные форматы, записи, личный кабинет, проекты.

Минус: стоимость длинных программ зависит от выбранного пакета.

Кому подойдет: семьям, которым важны выбор формата и возможность начать с короткого курса.

4. CODDY

Для подростков 13–16 лет у CODDY есть курс «Нейросети для детей: промпт-инжиниринг».

Основной акцент — грамотное управление нейросетями, создание мультимедийных проектов и автоматизация задач. Занятия проходят с наставником, онлайн или очно.

Программа больше ориентирована на подростков, которые уже понимают базовую работу с цифровыми инструментами и хотят научиться использовать AI для конкретных задач.

Стоимость и продолжительность программы не указаны.

Плюсы: индивидуальный наставник, практическая направленность, офлайн и онлайн.

Минус: мало открытой информации о стоимости и длительности.

Кому подойдет: подросткам, которым интересны промптинг, контент и автоматизация.

5. Нейрокадо

Нейрокадо предлагает онлайн-обучение для детей 9–17 лет. В программе используются современные AI-инструменты, включая GPT, Claude, Midjourney и Stable Diffusion. Для более продвинутых учеников предусмотрена работа с API.

Формат индивидуальный. Можно выбрать абонемент на четыре, восемь или 12 занятий в месяц. Стоимость составляет 12 000, 20 000 или 27 000 ₽ в зависимости от тарифа.

Результатом обучения становятся проекты и портфолио, предусмотрен Demo Day. Для занятий понадобится компьютер или ноутбук, микрофон и стабильный интернет.

Плюсы: индивидуальный трек, широкий набор AI-инструментов, портфолио.

Минус: высокая стоимость по сравнению с короткими вводными курсами.

Кому подойдет: школьникам, которым нужен персональный AI-трек и более широкий набор инструментов.

6. KIBERone

Возраст: 7–12 лет.

KIBERone предлагает отдельную программу по искусственному интеллекту для школьников. Курс рассчитан на начальный уровень и знакомит детей с базовыми принципами работы с нейросетями.

На занятиях школьники учатся составлять промпты, создавать изображения и контент с помощью AI-инструментов, а также разбирать практические сценарии использования искусственного интеллекта.

Формат обучения — очный. Программа рассчитана на 4 занятия. Стоимость в исходных данных не указана.

Плюсы: подходит для первого знакомства с ИИ, короткая программа, практическая направленность.

Минусы: небольшой объем курса не позволяет глубоко изучить искусственный интеллект.

7. Учебный центр «Дельфа»

Курс «Введение в нейросети» предназначен для школьников 11–18 лет. Можно заниматься онлайн или очно, а также выбрать индивидуальный формат. Очные занятия проходят в Тюмени.

Программа состоит из 12 занятий по 80 минут. Школьники знакомятся с ChatGPT, Kandinsky 3.1, Google Docs, Google Sites и Wepik.

Среди практических результатов — презентация с помощью нейросетей, генерация изображений и итоговый кейс-проект.

Групповые занятия стоят от 4 240 ₽ в месяц, индивидуальные — от 6 400 ₽. После обучения выдается сертификат.

Плюсы: понятное расписание, очный и онлайн-формат, практические проекты.

Минус: группы Junior могут насчитывать до 18 человек.

Кому подойдет: подросткам, которым нужен структурированный вводный курс по нейросетям.

8. РНИМУ им. Н. И. Пирогова

Университет предлагает очный интенсив «Искусственный интеллект для школьников» для учащихся 8–11 классов.

Программа очень компактная: четыре академических часа, четыре занятия за один день. Школьники знакомятся с основами ИИ, текстовыми нейросетями и промптами, а также разбирают применение искусственного интеллекта в учебе и повседневной жизни.

В программе указаны GigaChat, YandexGPT и ChatGPT. Предварительная подготовка не требуется, оборудование предоставляется на месте.

После обучения выдается сертификат.

Плюсы: университетская площадка, очный формат, короткая продолжительность.

Минус: это скорее знакомство с ИИ, чем длительное обучение.

Кому подойдет: школьникам 8–11 классов, которые хотят быстро разобраться в основах ИИ.

9. Академия Эдюсон

Программа «Python и нейросети для школьников» рассчитана на детей от 11 лет.

Здесь искусственный интеллект изучается вместе с программированием. В программе используются YandexGPT, Perplexity, AI-IDE и инструменты автодополнения кода. В качестве среды для игровых проектов применяется PyGame Zero.

Курс длится 12 месяцев. В результате ученик выполняет до 20 проектов. Первое занятие предоставляется бесплатно.

Плюсы: сочетание Python и ИИ, большое количество проектов, бесплатное первое занятие.

Минус: стоимость программы не указана.

Кому подойдет: школьникам от 11 лет, которым интереснее техническая сторона искусственного интеллекта, а не только генерация контента.

10. Яндекс Лицей

Возраст: 13–20 лет.

Яндекс Лицей в первую очередь специализируется на программировании, поэтому это вариант для подростков, которым интересна техническая сторона IT и дальнейшее развитие в программировании.

В программах представлены Python, Go и другие языки и технологии. Для подростка, который хочет изучать искусственный интеллект глубже, такой путь может быть полезен как основа: знание программирования позволяет в дальнейшем переходить к разработке AI-приложений и работе с машинным обучением.

Обучение проходит очно и онлайн в зависимости от программы. Основные программы рассчитаны на длительное обучение, включая годовые треки. Обучение бесплатное, но поступление предполагает регистрацию и отбор.

Плюсы: бесплатное обучение, серьезная техническая база, подходит подросткам, заинтересованным в программировании.

Минусы: это не классический курс по нейросетям для начинающих; для поступления предусмотрен отбор.

Кому подойдет: подросткам от 13 лет, которые хотят получить фундамент в программировании и в дальнейшем развиваться в направлении ИИ и разработки.

Как выбрать курс ИИ для школьника?

Сначала определите цель

Ребенку нужны нейросети для учебы? Тогда важны промптинг, проверка информации и безопасная работа с ИИ.

Интересуют картинки, музыка и видео? Ищите курс с творческими проектами.

Нравится программирование? Лучше выбирать Python, AI-приложения, чат-ботов или машинное обучение.

Учитывайте возраст

Младшим школьникам проще начинать с визуальных и творческих задач. Подростки могут переходить к Python, API, разработке приложений и более сложным AI-проектам.

Смотрите на практику

Сертификат сам по себе мало говорит о результате. Гораздо интереснее узнать, что ребенок создаст за время обучения.

Хороший показатель — несколько законченных проектов и итоговая работа, которую можно показать в портфолио.

Сравнивайте не цену урока, а весь курс

У двух программ может быть одинаковая стоимость занятия, но совершенно разное количество уроков, продолжительность и объем обратной связи.

Поэтому полезно считать стоимость всей программы и отдельно оценивать, сколько практики получает ученик.

Проверьте формат поддержки

Если ребенок только начинает изучать ИИ, ему может быть сложно заниматься полностью самостоятельно. В этом случае стоит искать преподавателя или куратора, который проверяет задания и помогает исправлять ошибки.

Используйте пробный урок

Пробное занятие помогает проверить сразу несколько вещей: понятен ли ребенку материал, нравится ли преподаватель, соответствует ли темп его уровню и действительно ли интересна тема.

FAQ

С какого возраста можно изучать ИИ?

Зависит от программы. В рейтинге есть курсы для детей от 7–8 лет и отдельные технические программы для подростков от 12–14 лет.

Нужно ли знать программирование для курса по ИИ?

Нет. Есть программы, рассчитанные на новичков. Для технических направлений с Python требования могут быть выше.

Что ребенок изучает на курсах ИИ?

Это зависит от программы. Можно изучать промптинг, генерацию текста и изображений, чат-ботов, AI-приложения, программирование, машинное обучение и безопасность работы с нейросетями.

Что лучше: курс по нейросетям или Python и ИИ?

Если ребенок хочет научиться использовать готовые AI-инструменты, подойдет курс по нейросетям. Если интересуется тем, как создавать собственные AI-сервисы, лучше смотреть в сторону Python и ИИ.

Обязательно ли заниматься с преподавателем?

Не всегда. Для простого знакомства подойдет видеокурс. Но при изучении программирования и создании сложных проектов обратная связь наставника может существенно упростить обучение.

Какой результат должен быть после курса?

Желательно, чтобы у ребенка остались собственные работы: изображения, сайты, игры, чат-боты, приложения или другие AI-проекты. Сертификат может быть дополнительным результатом.

Можно ли использовать нейросети для учебы?

Да, но важно учить ребенка не копировать готовые ответы, а использовать ИИ как инструмент: задавать вопросы, проверять информацию, находить ошибки и самостоятельно разбираться в материале.

Заключение

Курсы ИИ для школьников сильно отличаются друг от друга. Одни знакомят с нейросетями через изображения, тексты и видео, другие делают акцент на промптинге, третьи связывают искусственный интеллект с Python, разработкой сайтов, игр и приложений.

Поэтому выбирать программу лучше не по громкому названию школы, а по четырем критериям: возраст ребенка, его интересы, формат обучения и ожидаемый результат.

Сначала определите, зачем школьнику ИИ. Затем с помощью таблицы отберите несколько подходящих программ и изучите карточки школ. После этого можно сравнить стоимость, нагрузку, формат поддержки и проекты.

Если школа предлагает пробное занятие, стоит им воспользоваться. Один урок поможет понять, подходит ли ребенку преподаватель и действительно ли ему интересно направление.

Главная цель обучения ИИ — не научить ребенка нажимать кнопку «сгенерировать». Гораздо важнее, чтобы школьник понимал, как использовать искусственный интеллект осознанно, проверять его ответы и применять нейросети для создания собственных проектов.

Виноват тут не шлюз. Виноват сервер, который исходил из того, что каждый запрос приходит ровно один раз. В сети, где теряются ответы, это допущение неверно всегда.

Идемпотентность — свойство операции, при котором повторное выполнение приводит к тому же состоянию, что и однократное. Сам ответ при этом может отличаться: повторный DELETE вернёт 404 вместо 200, и метод от этого идемпотентным быть не перестаёт. У HTTP это закреплено на уровне методов: RFC 9110 относит к идемпотентным PUT, DELETE и безопасные методы, а POST идемпотентным по своей природе не является. Бизнес-операции почти всегда отправляют именно через POST.

Клиент не может отличить «сервер не получил запрос» от «сервер выполнил операцию, но ответ потерялся», поэтому повтор придёт в любом случае.

Ключ идемпотентности генерирует клиент, а сервер хранит связку ключа со слепком запроса и с готовым ответом, чтобы повтор получил тот же результат, а не новый.

Проверка «посмотреть и вставить» неатомарна: два одновременных повтора оба увидят отсутствие ключа. Нужен уникальный индекс или условная запись.

Запись в базу и отправка в очередь в одну транзакцию не помещаются. Обёртывать сетевой вызов в BEGIN и COMMIT вредно вдвойне: корректности не даёт, а пул соединений выедает.

Transactional outbox решает это одной таблицей: событие пишется в той же транзакции, что и бизнес-запись, а отдельный процесс доставляет его в очередь.

Почему повтор неизбежен

Сеть отказывает так, что установить факт доставки невозможно в принципе. Есть три типовых сценария, и внешне они неразличимы:

• Сервер обработал запрос, но ответ потерялся по дороге назад.
• Сервер всё ещё считает, а у клиента уже сработал таймаут.
• Балансировщик повторил запрос сам, никого об этом не уведомив.

Для GET повтор безвреден. Для POST /payments это второе списание. Отсюда и правило: одна логическая операция должна приводить к одному записанному итоговому состоянию, сколько бы раз её ни отправили. Осознанно новая операция обязана прийти с новым ключом.

Два способа сделать ручку идемпотентной и один в довесок

Способ первый: ключ идемпотентности

Самый распространённый вариант: клиент генерирует уникальный идентификатор на одну логическую операцию и повторяет его при каждой попытке. Сервер хранит соответствие ключа и ответа, а на дубликате возвращает сохранённый результат вместо повторного выполнения работы.

Три детали, на которых ошибаются чаще всего. Ключ генерирует клиент, а не сервер: смысл в том, что сервер сам по себе не отличит новый запрос от повтора. Ключ должен быть с высокой энтропией, обычно это UUID v4; выводить его из изменяемого или малоразнообразного поля вроде номера клиента нельзя, потому что это повышает риск коллизии и переигрывания чужой операции.

И последнее: повтор должен получить тот же самый ответ. Если первая попытка вернула 201 с идентификатором платежа, то и повтор возвращает те же 201 и тот же идентификатор, а не 409 и не пустую двухсотку. Иначе клиент решит, что операция не прошла, и попробует ещё раз.

Способ второй: сделать операцию идемпотентной по смыслу

Иногда ключ не нужен вовсе, потому что семантику можно спроектировать идемпотентной с самого начала. Классический пример — PUT /users/42, который задаёт полное представление ресурса: отправьте его дважды, и состояние будет одним и тем же.

Для операций создания трюк в том, чтобы выводить идентификатор из самого запроса, а не генерировать случайный на каждый вызов:

Идентификатор детерминированно выводится из почты, поэтому повторный запрос даёт того же пользователя без дублирующей строки. Плата за простоту — необходимость естественного уникального ключа: почты, артикула, внешнего идентификатора. Хеш при этом считается от точной строки, поэтому почту нужно привести к нижнему регистру и обрезать пробелы до хеширования: иначе один и тот же ящик с заглавной буквы даст второго пользователя. И ключ должен быть неизменным: если пользователь сменит почту, выведенный из неё идентификатор либо останется прежним и перестанет соответствовать данным, либо изменится и оторвётся от всех ссылок на него в соседних таблицах. Нет подходящего ключа, возвращайтесь к первому способу.

Довесок: оптимистичная блокировка

Этот приём идемпотентности не даёт и в списке стоит по другой причине. Ключ защищает от повторов одного и того же запроса, но ничего не делает с двумя разными запросами, которые правят одну запись. Здесь работает проверка версии: клиент присылает версию, которую видел, а сервер отклоняет обновление при несовпадении.

Обратите внимание, что проверка версии живёт внутри самого UPDATE. Разнести её на отдельное чтение и последующую запись означало бы воспроизвести ровно ту гонку, о которой пойдёт речь в следующем разделе: два запроса с одной устаревшей версией оба прошли бы проверку и оба записали бы результат. Идемпотентным одиночный запрос этот приём не делает, зато закрывает частый источник задвоенных эффектов: двух писателей, затирающих работу друг друга.

Где наивная реализация ключа разваливается

Гонка в проверке

Последовательность «проверить наличие ключа, потом вставить» содержит зазор, в который помещаются оба одновременных повтора: обе стороны видят, что ключа нет, и обе выполняют работу. Резервировать ключ нужно атомарно, через уникальное ограничение базы, условную запись или транзакционный compare-and-set (атомарное сравнение с записью).

Это же относится и к примеру с платежом выше: замена словаря в памяти на Redis гонку не закрывает, пока проверка и вставка остаются двумя отдельными командами. Нужен атомарный примитив резервирования, вроде SET key value NX или INSERT ... ON CONFLICT DO NOTHING.

Проверяется это только настоящей конкуренцией. Юнит-тест, вызывающий функцию дважды подряд, гонку не поймает никогда. Отправьте полсотни одновременных запросов с одним ключом и убедитесь, что побочный эффект произошёл ровно один раз.

Слепок запроса, а не только ключ

Хранить один ключ недостаточно. Сервер канонизирует поля, определяющие бизнес-смысл операции, и считает от них хеш. Канонизация означает приведение к единому виду порядка полей, форматов чисел и дат, опущенных значений по умолчанию и незначащих пробелов. Если повторный вызов обязан воспроизвести решение, принятое по прежним правилам, в слепок включают ещё и версию политики. Пример: между первой попыткой и повтором поменялись тарифы, и повтор обязан вернуть старую цену, а не пересчитать по новой. Без версии в слепке сервер этого различия не увидит.

Когда тот же ключ приходит с другим слепком, это ошибка на стороне клиента, и отдавать ему старый результат нельзя. Разбор проектирования идемпотентных ручек предлагает отвечать 409 Conflict; автор практического руководства в этом случае возвращает 422. Важно, чтобы выбранный код был задокументирован и никогда не подменяется молчаливой отдачей чужого ответа.

Состояния и коды ответа

Минимальная модель состояний записи выглядит так: PROCESSING, SUCCEEDED, FAILED_RETRYABLE и FAILED_FINAL. Рядом хранятся ключ операции, слепок, отметки времени, идентификатор решения, снимок ответа и версия политики. Клиенту нужна детерминированная карта из состояния в код ответа:

• 201 или 200 — первый успешно завершённый результат.
• 200 с явной пометкой о повторе — проигрывание сохранённого ответа.
• 202 со ссылкой на статус — работу уже выполняет другой обработчик, начинать вторую не нужно.
• 409 — ключ переиспользован с другим содержимым.
• Задокументированная финальная ошибка — обработка провалилась, и автоматическое продолжение небезопасно.

Срок жизни ключей:
Хранить их вечно не нужно, это медленная утечка. Сутки покрывают практически любое реальное окно повторов, но выбирать срок стоит от риска предметной области: у платежей и у рекомендаций он разный. И помните, что ключ приходит снаружи: ограничьте длину и набор символов, привяжите его к арендатору и не дайте одному пользователю вытащить результат чужой операции.

Вторая половина задачи: база и очередь

Допустим, ручка стала идемпотентной. Остаётся более коварная проблема: почти всякая бизнес-операция пишет не в одно место. Заказ сохраняется в базу и публикует событие в очередь, чтобы склад начал сборку, почтовый сервис отправил подтверждение, а антифрод посмотрел на транзакцию.

Обе половины статьи растут из одного факта: ни HTTP, ни очередь не обещают доставку ровно один раз, они обещают её хотя бы один раз. Поэтому защищаться приходится дважды, на входе и на выходе.

Это две записи в две разные системы, и общей транзакции у них нет. Упал процесс, моргнула сеть, выкатился деплой между двумя вызовами — одна сторона зафиксирована, вторая нет. Заказ подтверждён на экране покупателя, а склад о нём не знает. Ошибка при этом нигде не залогирована и алерт не сработал.

Почему обернуть это в транзакцию нельзя

Соблазнительный и заведомо неверный вариант выглядит так:

Транзакция базы не имеет власти над очередью и умеет откатывать только операции базы. Если отправка прошла, а COMMIT упал, сообщение уже в очереди и забрать его оттуда нельзя.

Есть и вторая беда, чисто эксплуатационная. Такой код держит открытое соединение и блокировки строк всё время сетевого вызова. Обычно очередь отвечает быстро, но под нагрузкой, ретраями или деградацией вызов растягивается на секунды, и все запросы к тем же строкам стоят в очереди. Это надёжный способ исчерпать пул соединений и уронить заодно ни в чём не повинные части сервиса.

Outbox: событие как строка в той же транзакции

Идея паттерна в том, чтобы перестать считать публикацию второй записью. Вместо вызова очереди приложение вставляет строку в таблицу outbox в той же транзакции, что и бизнес-запись. Отдельный процесс читает таблицу и публикует сообщения дальше.

Откатилась транзакция, и вместе с ней исчезла строка outbox: осиротевшего сообщения в очереди не осталось. Упало приложение сразу после фиксации — строка на месте со статусом pending, и доставщик заберёт её на следующем проходе. Паттерн опирается ровно на одну гарантию, которую база и так даёт: атомарность одной транзакции.

Доставщик выбирает пачку необработанных строк и помечает их отправленными только после подтверждения очередью. Ключевая деталь здесь одна:

Этот SELECT и последующая простановка статуса выполняются в одной транзакции: блокировка живёт до фиксации. Благодаря SKIP LOCKED доставщик масштабируется горизонтально из коробки, каждый экземпляр берёт свой набор строк. А если он упадёт посреди пачки, вся пачка откатится и уйдёт повторно, что даёт ещё один довод в пользу идемпотентного потребителя.

Может показаться, что здесь мы делаем ровно то, что осудили выше: держим блокировку на время сетевого вызова. Разница в том, что блокируется не бизнес-таблица и соединение берётся не из пула, обслуживающего пользовательские запросы, а SKIP LOCKED не даёт одной медленной строке задержать остальные.

Потребитель обязан быть идемпотентным

Если доставщик упал посреди прохода, на следующем он переотправит те же строки. Очереди вроде SQS и Kafka в типовой конфигурации гарантируют доставку «хотя бы один раз», поэтому дедупликация на приёмной стороне обязательна, и уникальным ключом служит идентификатор события или решения.

Делает это условная запись. Важная деталь, на которой легко ошибиться: сама по себе она пустой операцией не становится. При несовпадении условия драйвер бросает исключение, и его нужно поймать явно, отличив штатный повтор от настоящей ошибки:

Настройки продюсера и подтверждения брокера снижают количество повторов, но не снимают с приложения ответственность за однократность бизнес-эффекта.

Что добавить перед продакшеном

Двух статусов мало. Нужен статус failed и счётчик попыток: после N неудач строка помечается провалившейся и перестаёт крутиться в цикле вечно. На стороне очереди настраивается очередь недоставленных сообщений, чтобы то, что потребитель не смог обработать, оседало в наблюдаемом месте, а не исчезало молча.

Когда задержка опроса становится критичной, полагающийся на периодический опрос доставщик заменяют захватом изменений: инструменты вроде Debezium читают журнал предзаписи PostgreSQL и публикуют изменения без паузы на опрос. Таблица outbox и потребитель при этом не меняются. Но это заметно более тяжёлое эксплуатационное обязательство, поэтому начинать почти всегда стоит с опроса.

Что забрать с собой

Обе части задачи выглядят избыточными ровно до первого инцидента. Тридцать строк кода с ключом идемпотентности стоят дешевле одного тикета с заголовком «вы списали дважды», а таблица outbox дешевле расследования, почему заказ есть у клиента и отсутствует на складе.

Коварство проблемы двух записей в том, что наивная реализация работает правильно почти всегда. Она отказывает в зазоре между двумя системами, и зазор этот становится виден только когда что-то пошло не так в самый неподходящий момент. К моменту, когда расхождение заметят в продакшене, данные уже разъехались, и красивого способа их починить не будет.

Как одно неверное допущение о порядке вызовов обернулось эпидемией задвоенных операций, показано в разборе реального инцидента в финтех-системе.

Материалы, на которых основан разбор: три паттерна идемпотентности с рабочим кодом, проектирование ручек, переживающих реальные повторы и пошаговая сборка outbox на Node.js.

Откройте самый денежный обработчик в своём сервисе и попробуйте отправить в него один и тот же запрос дважды. Если во второй раз что-то произошло, вы уже знаете, с чего начать понедельник.

Расскажу с самого начала — так будет понятнее, как предыдущий инженерный опыт в итоге привёл меня в YADRO.

Чем вообще занимается инженер радиосвязи

По образованию я инженер радиотехники и после вуза пошёл работать по специальности. Подрядная организация строила башни связи, устанавливала на них оборудование и проводила радиоизмерения для операторов. Я начал с полевых замеров, или драйв-тестов. По сути, ты ездишь по городу с измерительным комплексом и проверяешь, как работает мобильная сеть.

Типичный день выглядел так: утром получаешь маршрут, устанавливаешь в машину измерительный комплекс, настраиваешь сценарии сбора данных. Дальше едешь и по ходу следишь за качеством измерений — важно с первого раза корректно собрать все необходимые данные. Шли годы активного внедрения 3G и модернизации сетей, поэтому работы было много. Из логов мы строили карту покрытия в специализированном ПО. Оператор получал от нас разбор с рекомендациями: что переставить или перенастроить, чтобы сеть вышла на целевые KPI.

Сначала я работал по готовым методикам, потом начал адаптировать их под конкретные задачи и предлагать заказчикам свои сценарии сбора статистики. Чаще всего это требовалось для проблемных зон, где стандартных измерений было недостаточно. Со временем поездки отошли на второй план, и я стал больше заниматься анализом данных, готовить маршруты и общаться с операторами. В этой роли я также участвовал в запуске первого LTE-кластера у одного из операторов.

Если убрать радиотехническую специфику, моя работа во многом сводилась к сбору данных, проверке их качества и выводам, на основе которых принимались дальнейшие технические решения. Слова «аналитика» в моей должности не было, но, по сути, я занимался в том числе ей.

Индор, стадионы и рюкзак телефонов

Дальше появились проекты по индору — покрытию внутри зданий: торговых центров, аэропортов и подземных паркингов. Здесь я впервые начал проектировать системы с нуля: работал с чертежами, размещал оборудование, рассчитывал питание и проверял монтаж.

Позже я перешёл в команду крупного телеком-вендора и занимался подготовкой покрытия на стадионах к Кубку конфедераций 2017 года и Чемпионату мира 2018 года. Масштаб был совсем другим: десятки тысяч зрителей одновременно, строящиеся арены и много командировок по стране.

Мы обследовали объекты, проектировали размещение оборудования, а после пусконаладки возвращались с рюкзаком телефонов и ноутбуком и проверяли, совпали ли расчёты с реальной картиной. Контрольные замеры заодно помогали находить ошибки монтажа. К концу проекта я уже набирал команду и отвечал за проверку готовности ключевых стадионов. К 2018 году я умел проектировать системы целиком, проверять монтаж и защищать результаты перед заказчиком.

Как опыт из радиосвязи пригодился в IT

В какой-то момент я решил перейти в IT и начал изучать программирование. В итоге меня взяли тестировщиком в компанию, которая разрабатывала Wi-Fi-чипы. Радиочасть я хорошо понимал благодаря предыдущему опыту, а к этому моменту уже мог читать и писать код. Там я работал на Python, разобрался с процессами тестирования и окончательно перешёл в IT. Я планировал остаться в компании надолго, но она неожиданно ушла с рынка.

Тогда друг рассказал мне про YADRO. Оказалось, за три-четыре месяца до этого здесь с нуля начали разрабатывать собственную базовую станцию мобильной связи и искали тестировщиков. К тому моменту у меня уже был опыт и в радиотехнике, и в тестировании, поэтому эти два направления хорошо сошлись в одной роли. Так я попал в третью команду тестирования. Сейчас в YADRO таких команд уже 16.

Думаю, сыграло роль именно сочетание компетенций. Специалистов по радиосвязи на рынке много, тестировщиков тоже, а людей, которые хорошо понимают оба направления, заметно меньше.

Как инженерный опыт пригодился в тестировании

Когда я пришёл в YADRO, оказалось, что многое из того, чем я занимался раньше, напрямую помогает в новой работе.

Тестирование базовой станции начинается с документации. Мобильная связь стандартизирована, всё описано в спецификациях 3GPP. Нужно держать в голове общую картину и одновременно глубоко погружаться в конкретную фичу: изучать её спецификацию и разбираться, где она пересекается со смежными областями.

Здесь пригодилась привычка работать со сложными техническими системами и смотреть не только на отдельную проблему, но и на то, как она связана с остальными частями сети.

Дальше мы готовим тестовую документацию: пишем тест-планы и кейсы, проводим ревью с продактами и разработчиками. Когда фича доходит до интеграции, запускаем тестовые циклы. Находим баги, разработчики вносят исправления, а мы повторяем тесты. Параллельно идёт регрессия, чтобы убедиться, что изменения не повлияли на уже работающий функционал.

Во многом сам подход похож на то, чем я занимался ещё в радиосвязи: сначала собрать данные, затем понять, что именно работает не так, найти причину и проверить результат после изменений. Только раньше объектом была уже работающая сеть, а теперь — продукт, который мы сами создаём.

Конечно, появилось и много нового. Оборудование мы тоже разрабатываем сами, оно постоянно меняется, поэтому тестовые стенды приходится адаптировать под новые версии. А каждая фича создаётся большой командой из 3000 специалистов, так что постоянное взаимодействие с разработчиками, продактами и коллегами из смежных направлений — важная часть работы.

Получилось, что я не начал карьеру полностью заново. В новой профессии пригодились и знания радиосвязи, и привычный инженерный подход, а навыки тестирования и программирования постепенно добавились к ним.

Как выглядит моя работа сейчас

На прошлой работе я использовал технологические продукты, которые делали тысячи инженеров на протяжении десятилетий. Сейчас я участвую в создании новой базовой станции операторского класса, которая разрабатывалась с нуля и буквально на моих глазах выходит в реальные сети. Сегодня телеком-оборудование YADRO работает в коммерческих сетях «Билайна» и «МегаФона» и охватывает уже 37 регионов России.

Всего за 3,5 года мы прошли путь от проекта до оборудования, которым уже пользуются люди. За этим стоят тысячи строк кода, сотни найденных и исправленных багов и работа большой команды.

Для меня это, пожалуй, одно из главных отличий нынешней работы: ты не только используешь уже готовые решения, но участвуешь в создании новых компонентов. Один из ярких примеров — в мае 2026 года первая отечественная базовая станция YADRO начала работу в коммерческой сети «МегаФона» в городе-миллионнике — Нижнем Новгороде. Еще один пример — мобильная связь на конференции ЦИПР-2026 в Нижнем Новгороде, которую мы обеспечили совместно с «Билайном».

Базовые станции собирают на нашем производстве в Дубне, откуда они отправляются на объекты по всей стране. Каждый квартал в нашем продукте появляются новые функции, а вместе с ними — новые задачи для тестирования. Команда продолжает расти, открытые позиции YADRO публикует на карьерном портале.

По своему опыту могу сказать, что смежный инженерный бэкграунд в таких задачах может стать серьёзным преимуществом. Поэтому, даже если опыт не полностью совпадает с описанием вакансии, но пересекается с её технической областью, на позицию вполне стоит откликнуться.

Итого

Если посмотреть на мой путь целиком, переход в тестирование не стал началом карьеры с нуля. Наоборот, новая роль объединила опыт, который я уже накопил в радиосвязи, с навыками, которые появились после перехода в IT.

В тестировании базовой станции одновременно пригодились знания радиосвязи, инженерное мышление и новые технические навыки. То, что могло казаться опытом из другой профессии, в итоге стало одним из моих главных преимуществ.

Поэтому инженерам, которые задумываются о переходе в IT, я бы советовал сначала посмотреть, где их текущая область пересекается с разработкой. Возможно, необязательно начинать карьеру полностью с нуля — иногда логичнее найти направление, в котором уже накопленный опыт будет полезен.

В моём случае таким пересечением стало тестирование телеком-оборудования. Опыт от полевых измерений до проектирования систем связи сегодня помогает мне участвовать в создании базовой станции, которая выходит в реальные сети. И, пожалуй, это главное, что я вынес из своего перехода: предыдущий инженерный опыт не ограничивает выбор следующего шага — иногда именно он помогает найти роль, в которой можно принести больше всего пользы.

Реклама. Рекламодатель: ООО «КНС ГРУПП» ИНН 7701411241, erid: 2W5zFJrMsAZ

Что творит ИИ на рынке труда?

О том, что нейросети заменяют людей, спорят давно, но теперь у спора появились цифры. В августе 2026 года Стэнфордский университет обновил данные по своему же исследованию — что происходит с занятостью молодых специалистов? По последним данным, занятость молодых людей, чьи профессии тесно связаны с ИИ, на 19% ниже, чем у сверстников, которые далеки от нейросетей. Разрыв продолжает расти из года в год, еще в прошлом году было всего 15%, а в 2024 13%.

Драматичных историй о массовых сокращениях не будет. Компании просто никого не нанимают. И, в целом, понять их позицию легко. Работодатели исходят из того, сколько ресурсов удастся сэкономить на обучении новичка, если отдать его работу нейросетям.

В какие профессии пробиться сложнее всего?

По оценкам экспертов из Сбера ИИ заберет работу в первую очередь у:

• менеджеров по продажам,
• разработчиков,
• бухгалтеров,
• маркетологов,
• сотрудников колл-центров.

Думали, что это все? А это только часть уязвимых профессий, которые объединяет обилие простой умственной работы. Те специалисты, которые уже внутри этих профессий успели апгрейднуться до мидлов и сеньоров, пострадали значительно меньше.

А какие профессии ИИ не заменит? Прежде всего те, что держатся на физическом труде: водители, слесари, монтажники, официанты и другие. Может, нейросетевые роботы и есть, но в обиход не введены, потому что плохо управляют телом, руками и инструментами. Да и стоимость слишком высокая, чтобы вводить повсеместно.

Что ИИ делает за джуна?

Раньше джунам на руки давали простую работу: написать короткую новостную заметку, сделать сводную таблицу по категориям товаров, сделать валидацию формы. То есть понятные и повторяющиеся задачи, на которых новички набивали руку, чтобы постепенно перейти к более сложной работе.

Сейчас решить такие задачи можно бесплатно через браузер в том же «обзоре от ИИ» или «быстром ответе Алисы AI». Денег в этой схеме стоит только сам интернет. Мы говорим о задачах, которые запускает именно человек. Некоторые компании идут дальше и заводят ИИ-агентов, которые работают без напоминаний, сами готовят контент, по расписанию присылают отчеты и фиксят код.

Бомба замедленного действия

Поиграем в математиков и попытаемся решить простое уравнение.

• Джунов на входе сегодня = 0.
• Мидлов через 3 года = 0, ведь мидл вырастает из джуна, а джунов не нанимали.
• Сеньоров через 5-7 лет = 0, ведь сеньор вырастает из мидла, которого взять неоткуда.

Лучше бы мы не знали ответа на это уравнение. Получается, что экономия на джунах истребляет кадровый резерв на годы вперед. Работодателю в моменте выгоднее отдать рутину нейросети, но через несколько лет окажется, что сеньоров не хватает. Можно, конечно, предположить, что к тому времени и нейросети дорастут до топового уровня. Но пока этого не случилось, работодатели начнут драться за тот пул сильных специалистов, что есть сейчас. А он будет только редеть, ведь одни уходят на пенсию, другие выгорают…

Как пройти порог входа?

Многие молодые специалисты стесняются говорить вслух о том, что пользуются нейросетями. Все потому, что ИИ стал нарративом для человеческого безделья. Сильнее всего этот нарратив поддерживают те, кому важна самостоятельная работа. Например, преподаватели, чья задача научить студентов думать своей головой, а не надеяться на нейросети. Позиция понятна, но именно из-за нее ИИ стал чем-то постыдным.

Сейчас, когда вы — начинающий специалист, и ваша задача устроиться на первую работу, в ход должны идти все средства. Отнеситесь к нейросетям не как к конкуренту №1, а как к личному помощнику. Расскажите всем, что вы два в одном: умеете контролировать, как ИИ справляется с простыми задачами, а сами беретесь за задачки посложнее.

Проще всего опробовать этот подход прямо в начале. Первое испытание для джуна ведь даже не собес, а резюме и сопроводительное, через которые к нему еще нужно пробиться. Ирония в том, что ваши документы тоже прочитает ИИ, тот самый ATS-скрининг. Так почему не применить принцип «клин клином вышибают»? Вот и доверьте нейросети черновики карьерных документов.

У Автор24 есть ИИ-инструмент, заточенный под учебные и карьерные задачи — AI-chat. Работает без VPN, отвечает быстро, а после ответа сам подсказывает, что доработать. Например, добавить примеры работы с API или уточнить уровень стека. Заходите, вставляйте промпт ниже, заполняйте пустые поля и запускайте генерацию.

Готовый промпт, чтобы стартануть:

«Собери резюме джуна [профессия] под эту вакансию: [вставь описание]. Опирайся на мой опыт: [стажировки, учеба, стек]. Пиши по делу, без воды, и подсвети, что я умею работать в связке с ИИ. Заодно набросай короткое сопроводительное на 4-5 предложений».

Вот такой черновик инструмент выдает за пару секунд. Дальше останется причесать его под себя.

Что мы имеем в итоге?

На первый взгляд может показаться, что порог входа сильно поднялся. На деле войти в профессию все еще не так сложно, если показать навыки работы с ИИ. Сложнее закрепиться на месте, ведь спрос сместился с тех, кто умеет выполнять рутину на тех, кто умеет стратегически мыслить и смотреть глубже.

Поэтому и сам джун должен меняться. С этой ролью справится молодой человек, который командует нейросетями, как собственными сотрудниками. Другими словами, босс на минималках. Если освоить эту роль сейчас, то через пару лет, когда рынок упрется в дефицит, вы окажетесь не в очереди безработных, а в пуле специалистов, за которых дерутся работодатели.

Путь к становлению таким боссом на минималках можно начать уже сегодня. Собирайте первое сильное резюме с помощью AI-chat, пока конкуренты еще спорят, стыдно ли пользоваться нейросетями.

Реклама. Рекламодатель: ООО «ПМТ» ИНН 7813667410, erid: 2W5zFH4rX5B

Главный вывод недели: цена за миллион токенов больше не говорит, во что обойдётся задача. Astra стоит за токен в 2,5 раза дороже GPT-5.6 Sol, но по замеру Artificial Analysis в агентном кодинге тратит на задачу втрое меньше токенов и в итоге выходит примерно в ту же сумму; на общих задачах экономия токенов всего 10%. Fable 5.1 сохранила цены Fable 5, но чтение кэша подешевело в 4 раза, и Anthropic оценивает экономию для агентных задач до 45%. Поэтому в этом обзоре у каждой модели рядом с ценой за токен стоит цена за задачу, если её кто-то мерил. Августовские релизы разобраны в прошлом обзоре, здесь они не повторяются.

• Claude Fable 5.1 и Mythos 5.1 — одна модель с разными ограничителями. Цена $10/$50 за миллион токенов, чтение кэша $0,25 вместо $1. По оценке Anthropic это минус около 25% к счёту на типичных задачах и до 45% на агентных.
• GPT-6 Astra стоит те же $10/$50. На Terminal-Bench 4.0 по замеру OpenAI она набирает 57,9% против 55,8% у Fable 5.1 при цене задачи на 63% ниже. В индексе Artificial Analysis v4.3 обе модели делят первое место с 53 баллами, но задача у Astra стоит $3,26 против $7,63 у Fable 5.1.
• Уровень рассуждений стал главным рычагом цены: у Fable 5.1 шаг с xhigh до max даёт полбалла на Humanity's Last Exam за 46% цены сверху, у Astra уровень max удваивает стоимость на коде без прироста точности.
• Дешёвый сегмент: Gemini 3.8 Flash $0,75/$3,75 до конца года, Muse Spark 1.3 $1,25/$4,25 и $0,55 за задачу индекса, Mercury 2.5 $0,20/$0,75 при заявленных 1107 токенах в секунду, DeepSeek V4 Flash $0,22/$0,66 в непиковые часы.
• MAI-Transcribe-2 стоит $0,10 за час аудио до конца года при WER 5,2% на FLEURS по замеру Microsoft. GPT-Transcribe от OpenAI стоит $0,27 за час.
• Автономность пока не продаётся: в эксперименте Bottleneck Labs семь моделей за 72 часа и $300 каждая заработали $0 и отправили 2797 писем.

Чем Fable 5.1 отличается от Astra, если цена у них одинаковая?

Разница в том, за что вы платите: Fable 5.1 берёт качеством на широком наборе задач и дешёвым кэшем, Astra экономит токены в агентном коде. Anthropic выпустила Claude Fable 5.1 и Claude Mythos 5.1 как одну модель с разными уровнями ограничителей: Fable доступна всем, Mythos только через программы проверенного доступа для кибербезопасности и биологии. В API модель называется claude-fable-5-1, есть на Amazon Web Services, Google Cloud и Microsoft Azure. Цены прежние, $10 и $50 за миллион токенов, но чтение кэша подешевело на 75%, до $0,25 за миллион. Anthropic посчитала по четырём неделям реального использования в августе, что типичная нагрузка станет дешевле примерно на 25%, а агентная, где кэш составляет большую часть счёта, до 45%. Это оценка вендора.

По бенчмаркам самой Anthropic модель обошла Opus 5 и GPT-5.6 Sol, а на низком и среднем усилии даёт результат Fable 5 дешевле. У кибер-фильтров на 60% меньше ложных срабатываний: искать уязвимости в коде теперь можно, разработка эксплойтов запрещена. В Claude Code по умолчанию уровень high.

We're moving our Opus 5 traffic in Devin to Claude Fable 5.1 on launch day. It matched or edged out Fable 5 in our testing at a lower cost per task, and with the new cache read pricing a Fable-class model is finally economical for the workloads we'd kept on Opus, starting with code review.

OpenAI начала раскатку GPT-6 Astra 3 сентября: сначала ограниченному кругу организаций, затем всем на Plus, Pro, Business и Enterprise, в API под именем gpt-6-astra, а также в Microsoft Azure и Amazon Bedrock. Стандартная цена $10 за миллион входных и $50 за миллион выходных токенов, быстрый режим даёт до 2 раз больше скорости за двойную цену. По замеру OpenAI на Terminal-Bench 4.0 Astra набирает 57,9% против 55,8% у Fable 5.1 и 37,3% у Sol, при этом задача по оценке OpenAI обходится на 63% дешевле, чем у Fable 5.1, и на 9% дешевле, чем у Sol. На Humanity's Last Exam и в общем индексе Artificial Analysis она ниже Fable 5.1 и Opus 5. Подробный разбор цен, бенчмарков и кибер-ограничений Astra есть в отдельной новости.

Независимая лаборатория Artificial Analysis разобрала Astra и увидела две разные истории. В Coding Agent Index Astra в Codex набирает 67 баллов, столько же, сколько Opus 5 и Fable 5 в Claude Code, при цене задачи меньше половины от Fable 5. Лидер индекса Fable 5.1 в Claude Code с 70 баллами. Экономия идёт от токенов: Astra тратит на задачу треть от Sol на уровне max и пятую часть от Opus 5 на xhigh. В общем индексе интеллекта картина хуже: токенов уходит всего на 10% меньше, чем у Sol, при том же балле, поэтому после подорожания в 2,5 раза задача стоит на 75% дороже. Галлюцинаций на AA-Omniscience вдвое меньше: 51% против 92% у Sol.

In the Artificial Analysis Coding Agent Index, GPT-6 Astra equals Fable 5 at less than half the cost, driven by significant token efficiency gains. In the Artificial Analysis Intelligence Index, GPT-6 Astra is more token efficient than its predecessor for similar performance, but this is offset by the price increase.

7 сентября Artificial Analysis обновила индекс до версии 4.3: Terminal-Bench поднят до 4.0, банковский Tau3-Banking заменён на AutomationBench от Zapier. По данным сайта лаборатории, Fable 5.1 и Astra на уровне max делят первое место с 53 баллами, Opus 5 набирает 51, Muse Spark 1.3 48, GLM-5.3 45, Grok 4.6 и Kimi K3 по 44, Gemini 3.8 Flash 41. Цена задачи индекса при этом $7,63 у Fable 5.1, $3,26 у Astra, $5,86 у Opus 5, $1,60 у Muse Spark 1.3 и $1,24 у Gemini 3.8 Flash.

Какой уровень рассуждений ставить, чтобы не переплатить?

Короткий ответ: у обеих флагманских моделей верхняя ступень почти не добавляет качества, а цену поднимает заметно, поэтому начинать стоит с low или medium и подниматься по результатам своей оценки. У Fable 5.1 пять уровней, по умолчанию high. Anthropic в разборе экономии приводит две цифры: на Humanity's Last Exam шаг с xhigh до max прибавляет около половины балла за 46% цены сверху, а на CursorBench 3.2 Fable 5.1 на low повторяет результат Fable 5 на high втрое дешевле. Команды Claude Code, которые ищут экономию сами (/claude-api prompt-audit, hillclimb, cost-optimize), мы разбирали отдельно.

Уровень задаётся параметром output_config.effort, пример из документации Anthropic (в примере модель Opus 5, для Fable 5.1 подставьте claude-fable-5-1). Документация отдельно отмечает, что Fable 5.1 умеет менять effort посреди диалога без сброса кэша промптов.

У Astra уровни задаются через reasoning.effort в Responses API. По документации OpenAI значение none для GPT-6 Astra не поддерживается и возвращает HTTP 400, а вызов функций работает только в Responses API, не в Chat Completions.

Однозначного оптимума у Astra нет. По опыту редакции Tproger на общих вопросах уровень выше high не окупается: цена растёт, точность нет. В коде по Coding Agent Index разумно выглядят low, medium и xhigh, а max удваивает стоимость без надёжного прироста. Рабочая схема: low по умолчанию, для сложных подзадач агент вызывает модель на более высоком уровне. Astra цепляется за формулировки, неточный промпт меняет результат сильнее, чем у прежних моделей; чеклист чистки инструкций под неё есть в отдельной статье.

Что взять, если бюджет считается в центах?

Четыре модели закрывают этот сегмент по-разному: Gemini 3.8 Flash сильнее всех в агентном коде, Muse Spark 1.3 дешевле всех за задачу на уровне Sol, Mercury 2.5 быстрее всех, DeepSeek V4.1 Flash пока бета. Google выпустила Gemini 3.8 Flash 3 сентября по вводной цене $0,75 за миллион входных и $3,75 за миллион выходных токенов; с 1 января 2027 года будет $1,50 и $7,50. Контекст миллион токенов, на OpenRouter у Flex-провайдеров вдвое дешевле. По замеру Google на DeepSWE v1.1, где модель сама доводит инженерную задачу до конца, 3.8 Flash обходит большинство более крупных моделей, на HLE-Verified набирает 54,9%. Google предупреждает: токенов на сложной задаче уйдёт больше, особенно на высоком уровне усилия, и советует понижать уровень или оставаться на 3.7 Flash.

These performance gains stem from a core design choice: 3.8 Flash works harder. On complex tasks, it exhibits greater diligence — executing extra reasoning steps, and calling tools iteratively. At times, the model might use more tokens to maximize performance, especially at higher effort levels.

Уровень рассуждений у Gemini задаётся параметром thinking_level, у 3.8 Flash доступны low, medium и high, по умолчанию medium. Пример из документации Gemini API:

Muse Spark 1.3 от лаборатории суперинтеллекта Александра Вана вышла 2 сентября в Muse Code и в API. Цены не менялись: $1,25 за миллион входных и $4,25 за миллион выходных токенов, попадание в кэш $0,15. По замеру Artificial Analysis открытая всем версия xhigh набрала 61 балл индекса v4.2, вровень с GPT-5.6 Sol и Grok 4.6, при цене $0,55 за задачу индекса против $0,95 у Sol и $0,94 у Grok. Рост почти весь в агентных задачах: банковский Tau3-Bench вырос с 35% до 47%. Просели длинный контекст и AA-Omniscience, где модель чаще отказывается отвечать. Входных токенов на задачу стало больше, поэтому цена задачи выросла с $0,40 у версии 1.2.

Inception выпустила Mercury 2.5, диффузионную модель, которая пишет текст блоками параллельно. Заявлено 1107 токенов в секунду на обычных NVIDIA GPU, контекст 260 тыс. токенов, уровень GPT-5.6 Luna на низком усилии и Claude Haiku 4.5. Цена $0,20 за миллион входных и $0,75 за миллион выходных токенов, на старте скидка 80% до $0,04 и $0,15, новым аккаунтам дают 100 млн токенов; модель есть в API Inception, на OpenRouter и Baseten. Независимых замеров Mercury 2.5 пока нет, все цифры вендора. Из кейсов в анонсе: Augment Code перевела на Mercury сжатие контекста, сжатие ускорилось со 150 секунд до 27 при снижении цены на 90%.

After we switched to Mercury, our P99 response time dropped from several minutes to just one second, and our P50 dropped from 0.4 seconds to under 0.2 — significantly faster than any other provider we've seen, and that's including reasoning.

DeepSeek 8 сентября открыла бету V4.1 Flash на два дня: модель deepseek-v4.1-flash-expires-on-0910 живёт в API до 10 сентября с лимитом 20 параллельных запросов. Цена как у V4 Flash: по прайс-листу $0,22 за миллион входных токенов при промахе кэша, $0,007 при попадании и $0,66 за миллион выходных в непиковые часы; в пиковые вдвое дороже, $0,44 и $1,32. Официальных бенчмарков нет. Тестеры намерили 400–500 токенов в секунду, а китайский XSCT Bench поставил V4.1 Flash выше V4 Flash, Gemini 3.8 Flash и Qwen3.8 Flash почти везде.

Qwen 2 сентября обновила закрытую Qwen3.8-Max до снапшота 0902: те же 2,4 трлн параметров, миллион контекста, режим размышлений, дообучение на кодинг и совместную агентную работу. По словам Qwen, прирост в основном в коде и агентных правках репозиториев, до Opus 5 в терминале ещё далеко. Цена в QwenCloud $2 за миллион входных и $6 за миллион выходных токенов, чтение кэша $0,17.

Что нового в картинках и распознавании речи?

Две картиночные модели без бенчмарков и одна речевая с рекордом на FLEURS. OpenAI выпустила ChatGPT Images 2.5: в API две модели, GPT-Image-2.5 Flare по умолчанию с вдвое меньшей задержкой, чем у GPT-Image-2, и Sunburst для точных правок. Цена у обеих $8 за миллион входных токенов картинки, $30 за выходные и $5 за текст на входе. Бенчмарков в анонсе нет, только примеры.

Microsoft AI выпустила MAI-Image-2.6-Flash и вывела MAI-Image-2.6 из закрытого превью в Microsoft Foundry. По заявлению Microsoft, Flash рисует в 2,8 раза быстрее GPT-Image-2-Medium при сопоставимом качестве; старшая модель на Arena вторая в генерации и редактировании, у Artificial Analysis вторая в генерации и первая в редактировании.

MAI-Transcribe-2 Microsoft выпустила 3 сентября: 60 языков с автоопределением, разделение говорящих, таймкоды на каждое слово, режимы verbatim и clean, подсказка терминов. По замеру Microsoft модель первая на мультиязычном FLEURS со средним WER 5,2%, у Artificial Analysis вторая по точности. Цена $0,10 за час аудио как акция до конца года, GPT-Transcribe от OpenAI стоит $0,27 за час. На OpenRouter модель лежит под именем microsoft/mai-transcribe-2, ещё есть в Microsoft Foundry и MAI Playground.

Какую модель брать под какую задачу в сентябре 2026 года?

Ниже сводка по задачам с ценами на 9 сентября. Все цены из прайс-листов вендоров, цены задач из замеров Artificial Analysis и вендоров, как указано.

• Агентный кодинг в большой кодовой базе. GPT-6 Astra на low или medium: 67 баллов Coding Agent Index при цене задачи меньше половины от Fable 5 (Artificial Analysis). Если важен максимум качества, Fable 5.1 в Claude Code с 70 баллами, но задача почти вдвое дороже.
• Массовые дешёвые задачи с агентами. Gemini 3.8 Flash на low: $0,75/$3,75 до конца года, $1,24 за задачу индекса v4.3. Muse Spark 1.3 на xhigh, если нужен уровень Sol за $0,55 за задачу (AA, v4.2).
• Голосовые агенты и всё, где важна задержка. Mercury 2.5: $0,20/$0,75, заявленные 1107 токенов в секунду и медиана ответа около 170 мс у OpenCall. Независимых замеров нет, проверяйте на своём трафике: новым аккаунтам дают 100 млн токенов.
• Сжатие контекста и маршрутизация внутри агента. Mercury 2.5 по кейсу Augment Code или DeepSeek V4 Flash за $0,22/$0,66 в непиковые часы.
• Транскрибация. MAI-Transcribe-2 за $0,10 в час до конца года против $0,27 у GPT-Transcribe.
• Картинки. GPT-Image-2.5 Flare для скорости, Sunburst для правок, $8/$30 за миллион токенов картинки.
• Длинный контекст. Qwen3.8-Max-0902 или Gemini 3.8 Flash с миллионом токенов; у Astra и Muse Spark 1.3 длинный контекст по замерам Artificial Analysis просел.

Порядок действий, чтобы перейти на новые модели без сюрпризов в счёте:

1. Замените идентификатор модели: claude-fable-5-1 в Claude API, gpt-6-astra в Responses API, gemini-3.8-flash в Gemini API. У Astra уберите reasoning.effort: none, иначе получите HTTP 400.
2. Поставьте низкий уровень усилия (output_config.effort: low, reasoning.effort: low, thinking_level: low) и прогоните свою оценку; поднимайте уровень только там, где балл растёт.
3. Проверьте долю попаданий в кэш: у Fable 5.1 чтение кэша стоит $0,25, и смена effort посреди диалога кэш не сбрасывает, у остальных моделей сброс возможен.
4. Для агентов с инструментами на Astra заложите обработку остановки: внешний мониторинг OpenAI может прервать задачу, и через API диалог не возобновить.
5. Сравнивайте цену задачи вместо цены токена: считайте токены на задачу из поля usage в ответе API и умножайте на прайс.

Почему автономный агент на новых моделях всё ещё нельзя оставлять без присмотра?

Потому что фильтры вендоров останавливают работу, а сами модели делают лишнее. OpenAI признаёт, что Astra достигла критического уровня в кибербезопасности по её Preparedness Framework: в тестах модель сама нашла и использовала две уязвимости нулевого дня. Поэтому на вызовы с инструментами в Codex, ChatGPT и Responses API включён внешний мониторинг.

Extra safety checks can sometimes slow, pause, or stop legitimate work, including defensive cybersecurity. If a task is paused in ChatGPT or Codex, you may be asked to review the action before continuing. In the API, the task will stop.

Вторая причина показана в эксперименте Bottleneck Labs, которая дала семи моделям по $300, Mac mini, почту, Stripe и 72 часа с промптом «заработай как можно больше денег». Итог по всем семи: 2797 писем, 11 живых посетителей, выручка $0, около $2800 на токены. Qwen 3.8 открыла сервис аудита GitHub-репозиториев, упёрлась в лимиты почты и выставила через Stripe 50 счетов незнакомым людям за незаказанную работу на $12 350, сочтя это допустимым шагом продаж. Это один эксперимент одной компании, но подтверждение человеком на платёжных действиях он делает обязательным.

Попробовать можно без денег: Inception даёт 100 млн токенов Mercury 2.5 новым аккаунтам, а Z.ai до 20 сентября держит ночной Global Build с бесплатной GLM-5.3-Flash для подписчиков Coding Plan. Цену решённой задачи у GLM-5.3, Sol и других мы считали отдельно. Следующая проверка — когда OpenAI закончит раскатку Astra и Artificial Analysis добавит в индекс v4.3 Mercury 2.5 и DeepSeek V4.1 Flash.

Источники: Anthropic: Introducing Claude Fable 5.1 and Claude Mythos 5.1, Claude Platform Docs: Effort, Claude Blog: Reducing cost and improving performance with Claude Platform, OpenAI: Introducing GPT-6 Astra, OpenAI Docs: Reasoning models, OpenAI: Introducing ChatGPT Images 2.5, Artificial Analysis: разбор GPT-6 Astra, Artificial Analysis: замер Muse Spark 1.3, Artificial Analysis: Intelligence Index v4.3, Artificial Analysis: главная страница индекса, Google: Gemini 3.8 Flash and 3.8 Flash Cyber, Gemini API Docs: Thinking, Inception: Introducing Mercury 2.5, QwenCloud: Qwen3.8-Max-0902, Alibaba Qwen: анонс Qwen3.8-Max-0902, DeepSeek API Docs: Pricing, IT之家: бета DeepSeek V4.1 Flash, Microsoft AI: MAI-Transcribe-2, Microsoft AI: MAI-Image-2.6, Bottleneck Labs: Benchmarking 7 autonomous businesses

Этот обзор продолжает августовский разбор открытых моделей. В сентябре главный сдвиг в том, что для каждого объёма памяти, от часов до двух серверных узлов, есть свежая модель, а независимый замер Quesma показал: 4-битный квант Qwen3.8-27B в 17 ГБ на трёх бенчмарках неотличим от полной версии в 55 ГБ. У каждой модели ниже три вещи: для каких задач, какие цифры и чей замер, как запустить.

• Nex-N2.5-Max: 1,6 трлн параметров, MoE, контекст 262 тыс. токенов, Apache 2.0. По таблице самой Nex-AGI на AutomationBench 50,2 против 50,3 у Opus 5, на SWE-Bench Pro 65,7 против 79,2. Запуск: два узла по восемь H200.
• K2 Horizon от MBZUAI: шесть моделей 0,9–375 млрд параметров, Apache 2.0, обещаны чекпоинты, данные, код и логи обучения. Модель 36B-A4B с 4 млрд активных на Terminal-Bench 2.1 набирает 58,6 против 53,9 у Nemotron 3 Ultra на 550 млрд (замер IFM).
• MiniCPM5-2B: 2,5 млрд параметров, индекс Artificial Analysis v4.2 равен 15, столько же у Qwen3.5 9B вчетверо большего размера. Тратит 19 тыс. токенов на задачу индекса против 56 тыс. у Ling 3.0 Tiny.
• Quesma потратила $3000 на GPU и не нашла измеримой разницы между BF16 в 55 ГБ и Q4_K_M в 17 ГБ у Qwen3.8-27B на GPQA Diamond, IFBench и Terminal-Bench 2.1. 1-битные кванты отвечают на уровне случайного угадывания.
• GLM-5.3-Flash в llama.cpp стала быстрее до 3,3 раза на длинном контексте после доработки Unsloth; на 65 тыс. токенов скорость выросла с 20,7 до 49,0 токенов в секунду ещё без MTP. Требования прежние: 100 ГБ для 1-битного кванта, 128 ГБ для 3-битного.
• llama.cpp 0.4.0 добавила ленивое чтение тензоров --lazy-mode, потолок памяти квантизатора и разреженное flash attention для DeepSeek-V4, GLM и Qwen3.8-Flash-Next.

Что вышло крупного и кому это по силам запустить?

Три больших релиза недели: Nex-N2.5 на 1,6 трлн параметров, семейство K2 Horizon и обновление Hy4, которое до открытых весов не дошло. Дома реально запускается только младшая K2 Horizon и, с натяжкой, Nex-N2.5-mini на двух H100.

Nex-AGI выложила Nex-N2.5, следующее поколение агентных моделей после июньской Nex-N2, в трёх размерах: mini, Pro и Max. Max это текстовая MoE-модель на 1,6 трлн параметров, первый у компании пост-трейнинг триллионного масштаба. Все три под Apache 2.0, контекст 262 144 токена. По таблице в карточке модели, замер вендора, Max сильна в агентных задачах: AutomationBench 50,2 против 50,3 у Claude Opus 5, BrowseComp 92,6 против 90,8 у Opus 5. В коде отстаёт: SWE-Bench Pro 65,7 против 79,2 у Opus 5. Чужие цифры Nex-AGI берёт из отчётов вендоров, так что таблица сравнивает разные харнесы.

Vision is therefore no longer merely an input modality; it has become a critical interface through which an agent perceives its environment, verifies outcomes, and moves a task forward.

Порог входа высокий. В репозитории Max запускается через форк SGLang в Docker на двух узлах по восемь H200, Pro на восьми H100, mini на двух H100. Mini и Pro есть на OpenRouter под именами nex-agi/nex-n2.5-mini и nex-agi/nex-n2.5-pro. Веса Pro в карточке только анонсированы, считать её открытой рано.

Институт фундаментальных моделей MBZUAI (IFM) 3 сентября выпустил K2 Horizon, шесть моделей под Apache 2.0: 375B-A23B для серверов, плотная 32B и разреженная 36B-A4B для рабочих станций, 7B и 3.7B для телефонов, 0.9B для часов и очков. Каждая обучена примерно на 20 трлн токенов. Главное обещание IFM: открыть для каждой модели весь путь, от промежуточных чекпоинтов и данных или рецептов их сборки до кода, конфигов и логов обучения вплоть до агентного пост-трейна.

A final checkpoint shows what a model can do. Horizon's complete training record helps reveal how it learned to do it.

Самая интересная из шести для локального железа это K2-Horizon-MoVA-36B-A4B: 36 млрд параметров, около 4 млрд активных на токен, контекст 524 288 токенов. Разреженность применена не только к полносвязным слоям, как в обычном MoE, но и к вниманию: механизм MoVA (Mixture-of-Value Attention) маршрутизирует экспертов внутри multi-head attention. По таблице IFM, где базовые значения взяты у Artificial Analysis, на τ³-Banking она набирает 26,8 против 14,2 у Nemotron 3 Ultra на 550 млрд, на Terminal-Bench 2.1 58,6 против 53,9, а отстаёт на Humanity's Last Exam и на длинном контексте AA-LCR. Запуск из README:

Про Hy4 от Tencent важно не перепутать. Компания 7 сентября сообщила, что подкрутила preview-версию: модель думала дольше нужного. Цифр нет, обновление уже работает в сервисах Tencent вроде WorkBuddy, а веса на Hugging Face не менялись с 28 августа.

Что поместится на одну видеокарту или в ноутбук?

Четыре свежие модели (Granite 4.2 8B вышла 31 августа) рассчитаны на 4–24 ГБ памяти: MiniCPM5-2B для агентов на ноутбуке, Spark-X2.5-4B для длинного контекста, младшие K2 Horizon для телефонов и Granite 4.2 8B для дешёвых массовых запросов. Ни одна не заменит большую модель в знаниях, и это видно по бенчмаркам.

OpenBMB выложила MiniCPM5-2B, плотную модель на 2,5 млрд параметров под Apache 2.0, контекст 131 тыс. токенов, с вызовом инструментов и рассуждениями. По независимому замеру Artificial Analysis она набирает 15 баллов индекса v4.2, лучший результат среди открытых моделей до 4 млрд: на 4 балла выше Granite 4.2 3B и вровень с Qwen3.5 9B вчетверо большего размера. Сильная сторона агентные задачи: GDPval-AA v2 831 против 718 у Ling 3.0 Tiny, τ³-Banking 21%. Слабые места знания и терминал: Terminal-Bench 2.1 9% против 29% у Qwen3.5 9B. Зато токенов на задачу индекса уходит 19 тыс. против 56 тыс. у Ling 3.0 Tiny, а для ноутбука это и есть скорость ответа.

As a dense model, its size advantage is in memory footprint rather than active-parameter compute.

Под капотом, по README, три стадии пост-трейна: SFT на 400 млрд токенов, RL по доменам и дистилляция 16 экспертных RL-моделей, из них 5 агентных, обратно в одну модель. Запуск через vLLM по README:

Spark-X2.5-4B решает другую задачу: агент со сверхдлинным контекстом на слабом железе. Модель на 4 млрд параметров держит 1 млн токенов, потому что на каждый слой с полным вниманием приходится три со скользящим окном, и кэш растёт медленнее. Обучена примерно на 20 трлн токенов на кластерах Huawei Ascend, поддерживает больше 200 языков, лицензия Apache 2.0. По таблице в карточке модели (замер вендора) на τ³-bench она набирает 30,4 против 9,3 у Qwen3.5-9B, на остальных тестах идёт вровень с моделями своего размера. Есть версия на 1,7 млрд. Из README, запуск в vLLM через официальный образ:

Младшие K2 Horizon 0.9B, 3.7B и 7B IFM называет лучшими в своих классах; у 0.9B, по данным блога, больше 48 баллов на AIME 2026. При этом IFM оговаривает: задачи с долгим исследованием, как в Terminal-Bench, малым моделям по-прежнему трудны. Веса, а для большинства и FP8 с GGUF, лежат в коллекции на Hugging Face.

Granite 4.2 8B от IBM, плотная модель с рассуждениями и контекстом 131 072 токена под Apache 2.0, стоит на OpenRouter $0,06 за млн входных и $0,25 за млн выходных токенов. Индекс Artificial Analysis v4.3 всего 12,4 при 17,6 у Haiku 4.5, агентные задачи слабое место: это модель под дешёвые массовые запросы вроде классификации, для агентов её не хватит.

Сколько памяти реально нужно локальной модели?

Для Qwen3.8-27B ответ измерен: 17 ГБ. Piotr Migdał из Quesma прогнал кванты от Unsloth через GPQA Diamond, IFBench и Terminal-Bench 2.1 на арендованных GPU Modal, потратил около $3000 и не нашёл измеримой разницы между полной BF16-версией в 54,7 ГБ и 4-битным Q4_K_M в 17 ГБ ни на одном из трёх тестов.

Цифры такие. На GPQA Diamond при уровне рассуждений xhigh BF16 даёт 89,9%, Q4_K_M 90,4%, 2-битный UD-Q2_K_XL 85,4%, доверительные интервалы перекрываются. На IFBench 81,7% против 81,0% и 80,0%. На Terminal-Bench 2.1 из 89 задач BF16 и Q4_K_M решили по 63, UD-Q2_K_XL 57.

In short, if you go with a 4-bit quantization Q4_K_M (17GB), you won't notice a difference on these benchmarks.

На практике Quesma держала KV-кэш в F16, около 2,3 ГБ на 32 тыс. токенов, и Q4_K_M влезает в 24 ГБ карты вроде RTX 4090 вместе с контекстом примерно на 64 тыс. токенов. 2-битный UD-Q2_K_XL на 10,7 ГБ по инструкциям и знаниям почти не отстаёт, а в агентном кодинге проседает и на тех же решённых задачах пишет в медиане на 27% больше токенов. 1-битный UD-IQ1_S на GPQA при xhigh даёт 10,4% и в 64% случаев возвращает пустой ответ: думает до исчерпания бюджета. Уровень рассуждений xhigh стоит включать только там, где он измеримо помогает: на GPQA да, на IFBench нет.

Ещё сильнее ужалась лаборатория DASLab австрийского института ISTA. Её кванты GSQ-RCO той же Qwen3.8-27B неравномерные: точность каждого тензора подбирается градиентным поиском под заданный размер файла. Сборка на 3,5 бита весит 11,8 ГБ вместо 53,8 ГБ в BF16 и, по замеру самой лаборатории, повторяет базовую модель на AIME25 (100,00) и LiveCodeBench v6 (85,71), уступая 0,51 балла на GPQA-Diamond. Это обычные GGUF, работают в llama.cpp, Ollama и LM Studio:

Для тех, у кого памяти много, а модель большая, новость недели это скорость GLM-5.3-Flash. Unsloth 4 сентября дописала свой pull request в llama.cpp: ускорила декодирование и добавила MTP, предсказание нескольких токенов за шаг. Кванты те же, докачивать ничего не нужно. На одной B200 с квантом UD-IQ1_S генерация на контексте 65 536 токенов выросла с 20,66 до 48,99 токена в секунду ещё без MTP, на коротких промптах прирост до 1,6 раза. С MTP лучший вариант два черновых токена: на 4096 токенах 86,5 против 58,6 без MTP.

However we should stop at around n=2 as more draft tokens makes inference slower.

Требования не изменились: 1-битный квант в 100 ГБ памяти, 3-битный в 128 ГБ, как у Mac Studio или DGX Spark. По таблице Unsloth, 1-битный UD-IQ1_S в 93 ГБ сохраняет 71% совпадений top-1 токена с BF16 в 642 ГБ, 3-битный 82%. С учётом результата Quesma по 1-битным квантам Qwen3.8 к 1-битной GLM стоит относиться осторожно: совпадение токенов и решение задач это разные метрики.

Наконец, llama.cpp 0.4.0, очередной сводный релиз, которые проект теперь собирает из ежедневных билдов раз в несколько недель. Что важно локальщику:

• Новые архитектуры: Qwen3.8-Flash-Next (пока без оптимизаций), Nemotron-3-Puzzle 75B с 9 млрд активных, DSpark для Nemotron 3.5.
• Разреженное flash attention для DeepSeek-V4, GLM и Qwen3.8-Flash-Next; ggml обновлён до 0.23.0.
• Ленивое чтение тензоров --lazy-mode: большие тензоры читаются по мере надобности, а пик памяти при загрузке убран.
• Потолок рабочей памяти квантизатора: раньше один большой тензор мог съесть всю оперативку.
• Сервер: лимит контекста на слот, видео на вход через --video-*, медиа через data:-ссылки, preserve_reasoning по умолчанию.

Что нового не только для текста?

Картинки, речь, вождение, временные ряды и видео. Под Apache 2.0 или MIT четыре модели из шести: TimesFM 3.0 только для некоммерческого использования, а у VDN-H3 своя лицензия MiniMax.

LLaDA-Image. Ant Group выложила модель на 6 млрд параметров, которая одним чекпоинтом и генерирует картинки, и редактирует их по инструкции; и языковой бэкбон, и картиночная часть диффузионные. Базовая версия работает за 50 шагов, Turbo за 4. На Qwen-Image-Bench 53,53 в английском, по данным авторов лучший результат среди открытых. Веса под Apache 2.0, есть FP8 и демо Turbo; код проверен на Python 3.11, PyTorch 2.8 и Diffusers 0.39.0.

Ling-3.0-flash-VL. Та же Ant Group показала зрячую версию Ling-3.0-flash (MoE, 5,5 млрд активных из 124) с таблицей против Qwen3.8-27B и Gemini 3.5 Flash-Lite: впереди по распознаванию документов и агентным задачам с картинками, отстаёт в математике по картинкам. Веса выложены на Hugging Face 8 сентября под MIT, есть FP8-версия.

VibeVoice-ASR-Streaming. Microsoft Research открыла потоковое распознавание речи, которое сразу пишет, кто что сказал, без отдельного этапа диаризации. Десять языков, русский в списке. По отчёту авторов, 7B-версия по доле ошибок в среднем лучше Gemini 3.5 Transcribe Live, ElevenLabs Scribe v2 Realtime и потоковых моделей OpenAI на четырёх наборах записей встреч и мультиязычном MLC-Challenge, хотя на двух Gemini впереди. Версии 1,5B и 7B под MIT, код на GitHub; список терминов, чтобы модель их не коверкала, передаётся флагом --context_info.

Qwen-Drive-1.0. Qwen вместе с Хуачжунским университетом выложила модель для беспилотного вождения на базе Qwen3.5-4B: VLM отвечает на вопросы о сцене, два внешних модуля дают 3D-восприятие и траекторию. На NAVSIM v1.1 планировщик после RL даёт 90,7 PDMS (замер авторов). Apache 2.0, VLM весит 9,1 ГБ, нужна карта от 24 ГБ.

TimesFM 3.0. Модель Google для прогноза временных рядов научилась прогнозировать несколько связанных рядов сразу и, по данным авторов, держит первое место на fev-bench и GIFT-Eval. Ставится через pip install timesfm[torch], но веса выпущены под некоммерческой лицензией.

VDN-H3. Ускоренная версия MiniMax-H3 для генерации видео со звуком: к сети добавили линейную ветку внимания по кадрам и два LoRA-адаптера. По словам авторов, ролик на 14,4 секунды генерируется за 11 секунд на восьми B200. Лицензия своя, MiniMax H3 Community License, перед коммерческим использованием её стоит прочитать. Лицензия своя, MiniMax H3 Community License, перед коммерческим использованием её стоит прочитать.

Что для какой задачи брать в сентябре 2026?

Короткий ответ: выбирать стоит по задаче и объёму памяти, размер в названии вторичен. Пары «задача, модель, почему» по цифрам выше; цены и требования проверены 9 сентября 2026.

• Агент на слабом железе: MiniCPM5-2B. Лучший индекс Artificial Analysis до 4 млрд, 19 тыс. токенов на задачу, есть GGUF и MLX, Apache 2.0.
• Агент с огромным контекстом на одной карте: Spark-X2.5-4B. 1 млн токенов при 4 млрд параметров, τ³-bench 30,4 против 9,3 у Qwen3.5-9B по замеру вендора.
• Локальный кодинг на 24 ГБ: Qwen3.8-27B в кванте Q4_K_M от Unsloth (17 ГБ) или GSQ-RCO IQ3_S от ISTA (11,8 ГБ). Сравнения двух между собой на Terminal-Bench никто не публиковал.
• Терминальный агент на рабочей станции: K2-Horizon-MoVA-36B-A4B. 4 млрд активных, Terminal-Bench 2.1 58,6 по замеру IFM, контекст 524 тыс.
• Кодинг на 128 ГБ памяти: GLM-5.3-Flash в 3-битном кванте Unsloth, теперь до 3,3 раза быстрее на длинном контексте. Про цену решённой задачи в API есть отдельный разбор.
• Распознавание встреч с указанием, кто говорил: VibeVoice-ASR-Streaming-7B. Стриминг, диаризация внутри, русский в списке, MIT.
• Картинки и правка по инструкции: LLaDA-Image-Turbo, 4 шага, есть FP8, Apache 2.0.
• Прогноз временных рядов: TimesFM 3.0, только для исследований из-за некоммерческой лицензии.
• Дешёвые массовые запросы через API: Granite 4.2 8B, $0,06 и $0,25 за млн токенов на OpenRouter; для агентов её не хватит.

Правило из замера Quesma, которое по опыту редакции Tproger подтверждается: берите самую большую модель, которая помещается в память вместе с нужным контекстом, и не бойтесь 4-битных квантов. 1-битные для задач с рассуждениями не годятся.

Что происходит вокруг и чего ждать дальше?

Вокруг релизов три события задают контекст, и все три об одном: открытые веса стали коммерческой стратегией.

Vals AI 31 августа опубликовала полные результаты GLM-5.3: в Vals Index модель вторая среди открытых с 57,0 балла после Kimi K3 и 13-я из 50 в общем зачёте при 18-м месте у GLM-5.2. Это объясняет, почему GLM-5.3 и GLM-5.3-Flash держатся в топе загрузок Hugging Face вторую неделю.

Mistral 8 сентября объявила, что подняла €3 млрд при оценке больше €21 млрд; по словам компании, это крупнейший акционерный раунд в истории европейских технологических компаний. Раунд ведёт Samsung Electronics, ставка прежняя: открытые веса плюс своя инфраструктура. Новых моделей в анонсе нет.

DeepSeek открыла бету V4.1 Flash: модель deepseek-v4.1-flash-expires-on-0910 живёт в API до 10 сентября, веса не выложены, официальных бенчмарков нет, так что в обзор она не попадает; о закрытых моделях речь в разборе за август. Что проверить дальше: выйдут ли веса Nex-N2.5-Pro, доедет ли доработка Unsloth в основной llama.cpp и обновит ли Tencent веса Hy4.

Источники: Карточка Nex-N2.5-Max на Hugging Face, Репозиторий Nex-N2.5 на GitHub: команды запуска, IFM: Introducing K2 Horizon, Карточка K2-Horizon-MoVA-36B-A4B, Коллекция K2 Horizon на Hugging Face, Artificial Analysis: OpenBMB releases MiniCPM5-2B, Карточка MiniCPM5-2B на Hugging Face, Репозиторий MiniCPM на GitHub, Карточка Spark-X2.5-4B на Hugging Face, Quesma: Benchmarking Qwen3.8 27B quantizations, ISTA-DASLab: Qwen3.8-27B GSQ-RCO GGUF, Unsloth: GLM-5.3-Flash, how to run locally, Релиз llama.cpp v0.4.0, LLaDA-Image на GitHub, Карточка VibeVoice-ASR-Streaming-7B, Qwen-Drive-1.0 на GitHub, TimesFM на GitHub, Granite 4.2 8B на OpenRouter, Mistral: раунд на €3 млрд, Vals AI: результаты GLM-5.3

Всё это принято называть обвязкой, и определение у неё простое.

Обвязка — это весь код между тем, что вы печатаете, тем, что получает модель, тем, что модель выдаёт, и тем, что вы видите. И это много кода, не имеющего отношения к ИИ. Модели при этом выглядят в значительной степени взаимозаменяемыми.

Разбираем три слоя обвязки, на которых результат меняется заметнее, чем от смены модели: маршрутизация вычислений, страховка надёжности в конвейере и контроль границ информации.

Обвязка — это код без единой нейросети внутри: сборка запроса, управление контекстом, проверки на выходе и координация нескольких моделей.

Маршрутизация задач между дорогой внешней моделью и дешёвой локальной даёт выигрыш в скорости, приватности и цене без смены качества на основных сценариях.

Анализ сгенерированного кода не показывает, как он поведёт себя при отказе зависимости, поэтому проверки надёжности строятся на воспроизведении реальных отказов, а не на чтении текста.

Пять источников почти всех сбоев одни и те же: процессор, память, диск, ввод-вывод и сеть. С них и начинают автоматические проверки.

Модели с постоянной памятью раскрывают лишние данные в неподходящем контексте, причём доля нарушений растёт с числом задач, а просьба быть осторожнее проблему не решает.

Слой первый: что и где считать

Первое, что делает обвязка, — решает, какой моделью обрабатывать конкретную задачу. Шнайер прямо советует руководителям по безопасности смотреть мимо брендов моделей и разбираться с окружающим их программным слоем: он управляет промптами, выводом, контекстом, ограничениями и координацией нескольких моделей одновременно.

Отдельная функция этого слоя — маршрутизация между дорогими внешними моделями и дешёвыми локальными. По мере того как компактные системы приближаются по качеству к передовым, всё больше задач имеет смысл считать локально: это быстрее, дешевле, приватнее и оставляет контроль на своей стороне.

Из того же наблюдения следует острый вывод, который Шнайер делает применительно к безопасности: раз возможности моделей широко доступны и во многом взаимозаменяемы, экспортные ограничения и закрытие доступа их не сдержат. Реальные риски он видит в другом: в концентрации корпоративной власти, в слабой целостности моделей и в плохо устроенных стимулах. Для инженера это переводится в практическое требование — проверять заявления поставщика и не полагаться на то, что выбор конкретного вендора сам по себе что-то гарантирует.

Слой второй: страховка надёжности в конвейере

Оговорка сразу: это уже не обвязка вокруг обращения к модели, а обвязка процесса поставки. Принцип тот же, объект другой: проверяется не ответ модели, а код, который агент написал и который вот-вот уедет в продакшен.

Код теперь пишется быстрее, и это меняет характер рисков, а не только их количество. Опечаток в сгенерированном коде стало меньше, зато прибавилось незапланированных зависимостей, расползания конфигурации и изменений инфраструктуры, сделанных агентом без нужного контекста.

Аналогия с гонками здесь уместнее обычного: на малой скорости из заноса выходят легко, на большой одна ошибка стоит несопоставимо дороже. Отсюда идея автоматических проверок надёжности Колтона Эндруса: замкнутых циклов, которые безопасно создают настоящие условия отказа, проверяют устойчивость, предлагают исправление и перепроверяют его после внесения.

Почему чтения кода недостаточно

Ранняя идея инженерии хаоса состояла в том, что перебрать все сочетания отказов юнит-тестами и интеграционными тестами невозможно. Прогон реалистичного отказа против живого сервиса проверяет много вещей разом и потому эффективнее.

Для сгенерированного кода это верно вдвойне. Статический анализ доводит до определённой черты, но не отвечает на главный вопрос: что произойдёт, когда отвалится кеш или вырастет задержка у зависимости. Правильное поведение здесь описывается заранее (скажем, при недоступности кеша сервис обязан уйти в основную базу), и проверка сводится к тому, соблюдает ли кандидат уже существующую политику.

Пять ресурсов, с которых начинают

Львиная доля сбоев упирается в одни и те же пять вещей: процессор, память, диск, ввод-вывод и сеть. Программы работают на компьютерах, а у компьютеров набор ресурсов один и тот же. Отсюда и минимальный набор автоматических проверок:

• Избыточность по зонам и узлам: что происходит при отказе целой зоны, отдельного хоста или контейнера.
• Масштабирование по процессору: корректно ли настроено расширение при всплеске и сворачивается ли оно обратно после.
• Масштабирование по памяти: то же самое, включая корректную деградацию, если расшириться не удалось.
• Отказ зависимости: как ведёт себя приложение, когда до внешнего или внутреннего сервиса не достучаться.
• Задержка зависимости: сервис доступен, но отвечает медленно. Приложение деградирует аккуратно, уходит к запасному источнику или просто падает.

Ответы на эти вопросы у зрелой команды обычно уже записаны в виде политик. Проверки не изобретают новых требований, они лишь удостоверяют, что очередной кандидат на выкатку этим требованиям соответствует.

Результат проверки возвращается агенту

Ставится это всё в конце конвейера сборки, прямо перед продвижением версии. Провалилась проверка — код помечается и уходит обратно вместе с описанием теста и предложенным исправлением.

Дальше начинается самое интересное. Данные о том, какая проверка провалилась, что исправили и прошла ли она после этого, возвращаются в агентский рабочий процесс как контекст. Проверять всё равно нужно каждый раз, но новый код начинает проходить проверки чаще, чем проваливать. Тот же журнал полезен и при разборе инцидентов: понятно, какие режимы отказа уже проверялись, с какими результатами и что было исправлено.

Слой третий: границы информации

Третий слой обсуждают реже всего, а он становится критичным ровно в тот момент, когда система обзаводится постоянной памятью о пользователе.

Речь о контекстной целостности — принципе из теории приватности Хелен Ниссенбаум: какие сведения уместно раскрывать при выполнении конкретной задачи. Домашний адрес нужен для оформления доставки и совершенно неуместен при составлении рабочего письма коллеге. Человек проводит эту границу не задумываясь, у модели с сохранённой памятью её приходится обеспечивать отдельно.

Что показали измерения

Шнайер разбирает две работы на эту тему. Первая описывает бенчмарк CIMemories: синтетические профили пользователей больше чем со ста атрибутами каждый и набор задач, в которых один и тот же атрибут для одних задач необходим, а для других неуместен.

Результаты неутешительные. Передовые модели показывают до 69% нарушений на уровне отдельных атрибутов, то есть раскрывают их там, где раскрывать не следовало. Снижение доли нарушений при этом обычно достаётся ценой полезности: модель становится осторожнее и хуже решает задачу.

Ещё важнее динамика. Нарушения накапливаются и по числу задач, и по числу прогонов: при росте использования с одной задачи до сорока доля нарушений у GPT-5 поднимается с 0,1 до 9,6%, а при пятикратном исполнении одного и того же промпта достигает 25,1%. Последняя цифра особенно неприятна: она означает нестабильное поведение, когда на идентичный запрос модель раскрывает разные атрибуты.

Почему просьба быть осторожнее не помогает

Естественная реакция инженера — добавить в системный промпт указание бережно относиться к персональным данным. Измерения показывают, что это не работает: модели переобобщают и начинают выдавать либо всё, либо ничего, вместо того чтобы принимать решение с учётом контекста.

Вывод авторов прямой: проблема не решается ни лучшим промптингом, ни увеличением масштаба модели, потому что требуется собственно рассуждение о контексте, в котором система сейчас работает.

Что действительно даёт эффект

Вторая работа как раз про это. Авторы сначала просят модель явно рассуждать о том, какие сведения уместны для текущей задачи, а затем закрепляют это обучением с подкреплением. На синтетическом наборе всего из 700 примеров с разнообразными контекстами и нормами раскрытия им удалось заметно сократить неуместное раскрытие, не потеряв в качестве решения задач, причём для моделей разных размеров и семейств.

Ценнее всего то, что улучшение переносится: обучение шло на синтетике, а результат подтвердился на устоявшемся бенчмарке с человеческой разметкой, оценивающем утечки в действиях и вызовах инструментов. Практический смысл для тех, кто строит систему поверх готовой модели, тот же, что и на двух предыдущих слоях: контроль границ реализуется в обвязке, а не выпрашивается у модели формулировками.

Что забрать с собой

Три слоя выглядят разнородно, но подчиняются одному правилу: свойство, которое вам нужно от системы, обеспечивается кодом вокруг модели, а не выбором модели. Маршрутизация даёт цену и приватность инфраструктуры: данные не покидают периметр. Автоматические проверки отказов дают устойчивость. Явный контроль границ информации даёт приватность самих данных пользователя, независимо от того, где физически стоит модель.

Проверить это на своём проекте несложно: посмотрите, сколько времени команда потратила за квартал на сравнение моделей и сколько на то, что находится между пользователем и моделью. Если первое число заметно больше, вы, скорее всего, оптимизируете не тот слой.

Материалы разбора: интервью Шнайера об обвязке и локальных моделях, проверки надёжности в конвейере с ИИ-кодом и обзор двух работ о контекстной целостности.

Claude: ставка на самопроверку

24 июля Anthropic представила Claude Opus 5. Это уже четвёртая модель компании менее чем за два месяца после Sonnet 5, Fable 5 и Mythos 5. Opus 5 сохранил цену предшественника в API Anthropic: 5 долларов за миллион входных токенов и 25 долларов за миллион выходных. По данным разработчика, по агентному кодингу он приблизился к более дорогому Fable 5.

Главная особенность Opus 5 связана с самопроверкой. Модель пишет код, запускает тесты, находит ошибки и исправляет их без дополнительной подсказки. Такой подход полезен при многошаговых изменениях в существующем репозитории, когда результат нужно проверить до завершения задачи.

Если вы выбираете с оглядкой на бюджет, можно начать с Claude Sonnet 5. Эта модель рассчитана на повседневные задачи, где важен баланс качества, скорости и стоимости. В RouterAI модели доступны под идентификаторами anthropic/claude-opus-5 и anthropic/claude-sonnet-5.

GPT: новый флагман для длинных задач

GPT-6 Astra стал новым флагманом OpenAI для сложных задач с большим числом шагов, включая программную инженерию и работу с инструментами. GPT-6 Astra Pro использует ту же базовую модель с режимом reasoning.mode: pro, который выделяет больше вычислений на рассуждение.

GPT-5.6 Sol остаётся вариантом для агентного кодинга, ревью и работы в командной строке. Его имеет смысл сравнить с Astra на собственных задачах, особенно если стоимость важнее максимального качества. Актуальные идентификаторы в RouterAI: openai/gpt-6-astra, openai/gpt-6-astra-pro и openai/gpt-5.6-sol.

Gemini: большой контекст и быстрые циклы

Gemini 3.1 Pro Preview подходит для сложных задач с кодом и принимает до миллиона токенов контекста. В один запрос можно передать крупный объём исходников и сопутствующей документации, хотя фактический предел полезного контекста лучше проверять на своём репозитории.

Gemini 3.8 Flash рассчитан на быстрые агентные циклы, программную инженерию и задачи с несколькими этапами рассуждения. Pro подойдёт для сложного разбора, а Flash стоит проверить на рутинных правках, где важны скорость и цена. Идентификаторы моделей: google/gemini-3.1-pro-preview и google/gemini-3.8-flash.

DeepSeek: стоимость и контроль инфраструктуры

DeepSeek V4 Pro уступает ведущим моделям OpenAI, Anthropic и Google, которые работают только через облачные сервисы разработчиков. По оценке NIST, отставание от ведущих американских моделей составляет около восьми месяцев. При этом семейство DeepSeek даёт возможность запускать открытые модели на собственной инфраструктуре и снижать стоимость типовых задач. Для части сценариев этого более чем достаточно, так что потребность в самом дорогом флагмане отпадает.

DeepSeek можно подключать через клиенты, совместимые с форматом OpenAI. В RouterAI актуальная версия доступна под идентификатором deepseek/deepseek-v4-pro-0813. Перед самостоятельным развёртыванием проверьте лицензию выбранной версии, поскольку условия релизов могут отличаться.

Qwen: общие модели и отдельная линейка для кода

В августе Alibaba расширила семейство Qwen3.8. В него вошли крупные модели общего назначения и компактные версии, которые проще запускать на собственной инфраструктуре. У Qwen есть отдельная линейка Coder для работы с репозиториями, генерации кода и агентных сценариев.

Открытые модели Qwen3 распространяются по лицензии Apache 2.0, но условия конкретного релиза всё равно нужно проверять перед внедрением. В RouterAI на момент подготовки текста доступны Qwen3.8 Max 0902 с идентификатором qwen/qwen3.8-max-0902 и Qwen3 Coder 480B с идентификатором qwen/qwen3-coder.

Как выбрать модель

Единого победителя нет. Opus 5 подходит для сложных изменений, где важна самопроверка. Sonnet 5 и GPT-5.6 Sol можно рассматривать для повседневной работы с балансом цены и качества. GPT-6 Astra рассчитан на длинные многошаговые задачи. Gemini 3.1 Pro полезен при большом объёме кода и документации, а Gemini 3.8 Flash при быстрых агентных циклах. DeepSeek и Qwen стоит проверить, если вам важны открытые модели, контроль инфраструктуры или более низкая стоимость.

Перед выбором проведите короткий тест:

1. Дайте двум или трём моделям одинаковую задачу и одинаковый контекст.
2. Проверьте качество исправлений, тестов и итогового диффа.
3. Посчитайте стоимость завершённой задачи с учётом повторных запросов.
4. Убедитесь, что выбранная модель поддерживает нужные инструменты и формат ответа.
5. Ещё раз проверьте идентификатор, доступность и цену перед запуском в проде.

RouterAI предоставляет один API, совместимый с форматом OpenAI, и позволяет переключать модели через значение параметра model. Для работы используется один API-ключ. Сервис принимает оплату в рублях российской банковской картой или по счёту, а работает без VPN. Актуальные цены и доступность моделей нужно проверять в каталоге, поскольку эти данные меняются быстрее самой статьи.