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

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

В этой статье собрали 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 и машинному обучению для подростков.

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

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

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

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

Источники

• Stream Workflow instance events in your Worker or via the API with .subscribe() · Changelog

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

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

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

Источники

• harmonyos: Port SDL3 to HarmonyOS/OpenHarmony. by icculus · Pull Request #16281 · libsdl-org/SDL · GitHub

Более 35 экспертов Cloud.ru и других ИТ-компаний поделятся практическим опытом, представят собственные разработки и результаты их внедрения. В программе — свыше 20 докладов по трем направлениям: «Инфраструктура», «Разработка» и «Данные и ML». Участников также ждут воркшопы, технозоны и «Лаборатория карьеры».

Трек «Инфраструктура»

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

Трек «Разработка»

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

Трек «Данные и ML»

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

Отдельный доклад будет посвящен Agents Space — пространству для работы с ИИ-агентами. Эксперты на примерах покажут, как использовать агентов для решения многошаговых задач. Также участникам представят архитектуру Evolution Foundation Models. Сервис способен обрабатывать более миллиона токенов в секунду и миллиарды токенов в сутки.

Реклама. Рекламодатель: ООО "Облачные Технологии", ИНН: 7736279160, erid: 2W5zFJLaPqK

Поэтому обучение ИИ для детей становится самостоятельным направлением дополнительного образования. На курсах школьники знакомятся с нейросетями, учатся составлять запросы, проверять информацию и создавать собственные проекты с использованием 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 + ИИ. А тем, кто любит игры, можно выбрать направление, где искусственный интеллект используется для создания игровых проектов.

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

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

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

Обновление касается команд, которые используют GitHub Agentic Workflows и сгенерированный файл .github/workflows/agentic_commands.yml. Также разработчики исправили падавшую задачу Integration: CMD Tests, чтобы восстановить корректный сигнал CI.

Источники

• Release v0.89.12 · github/gh-aw · GitHub

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

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

Источники

• Release 2.31.0 · moment/moment · GitHub

Чтобы деплой прошёл без проблем, нужно подготовить воспроизводимый артефакт, проверить совместимость версий и заранее определить условия остановки или отката релиза. Подробнее об этих процессах и опыте работы с высоконагруженными системами рассказала команда 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 — пошаговой инструкции для дежурных инженеров.

Минимальный набор перед первой управляемой выкладкой

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

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

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

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

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

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

Пользователям устройств на ARM64 стали доступны нативные сборки Kiro для Windows и Linux, которым не требуется эмуляция x64. Основу редактора обновили до Code OSS 1.131.

В релизе также доработали сохранение контекста после сжатия диалогов, сообщения об ошибках MCP, надёжность Hooks и выбор региона для корпоративных профилей.

Источники

• Agent Artifacts and Native ARM64 Builds - Kiro

Реальность же такова, что универсальных платформ не существует: легкий трекер для веб-студии парализует работу промышленного холдинга, а тяжелый 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) с тестовой миграцией среза ваших реальных данных. Только работа в тестовой среде покажет истинный потенциал выбранной системы.

По данным компании, менять код или добавлять настройки не нужно. В режиме direct система сначала ищет явно заданные учётные данные провайдера, а затем нативную подписку. Режим auto работает так же, если не настроены данные AI Gateway. Режим ai-gateway подписки на хосте не читает.

Поддержка заявлена для Claude Code, Cline, Codex, Cursor, fx, GitHub Copilot, Grok Build, OpenCode и Pi, если сам агент допускает вход по подписке. Токены остаются на хосте и при необходимости обновляются там же. В совместимых песочницах harness получает заглушечные учётные данные, а настоящий токен подставляется в исходящий запрос на стороне хоста.

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

Источники

• AI SDK harness layer now supports native subscription authentication - Vercel

Для моделей Devin введено обязательное пространство имён devin/. Каталог вынесен в отдельный файл devin_models.json, который можно обновлять удалённо. Также появился CLI-инструмент fetch_devin_models для извлечения актуального списка моделей.

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

В примечаниях к релизу нет сведений о цене интеграции, лимитах сервиса Devin или доступности из России. Сравнить эти условия с конкурирующими провайдерами по опубликованным данным нельзя. Для Linux доступны обычная сборка с динамическими плагинами и переносимая сборка без них для musl и старых систем, включая OpenWrt.

Источники

• Release v7.3.0 · router-for-me/CLIProxyAPI · GitHub

Что такое 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.

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

Заметная часть обновления касается разграничения доступа. S3 API теперь определяет aws:SourceIp по непосредственному TCP-соединению и не позволяет разрешающей политике бакета отменить явный запрет из IAM. При неподдерживаемых операторах условий в политике бакета доступ не предоставляется. Также закрыта возможность перенаправить запрос к другому бакету через X-Forwarded-Host.

• Удаление IAM-политики блокируется, пока она привязана к пользователю или группе.
• Внутренний LifecycleDelete gRPC требует административной Bearer-аутентификации.
• SSRF-защита применяется к отложенным операциям получения, просмотра и удаления удалённых файлов.
• Для повреждённых носителей и копирования томов добавлены дополнительные проверки и обработка сбоев.
• Ограничено потребление памяти кэшем чтения при одновременном открытии нескольких файлов.

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

Изменения затрагивают инсталляции SeaweedFS, в которых используются S3 API, IAM-политики, FUSE-монтирование, удалённые источники данных или erasure coding.

Источники

• Release 4.47 · seaweedfs/seaweedfs · GitHub

Установщик получил изменения из нового точечного обновления, а ABI ядра обновлён до 6.12.107+deb13. Новые установочные образы появятся в стандартных каталогах Debian.

Debian 13.7 не является новой версией Debian 13. Пользователям trixie не нужно переустанавливать систему или заменять старые установочные носители: достаточно обновить пакеты через актуальное зеркало Debian. На системах, которые регулярно получают исправления с security.debian.org, объём обновления будет меньше.

Источники

• Debian -- News -- Updated Debian 13: 13.7 released

Но пользоваться нейросетью и понимать, как с ней работать, — разные вещи. Ребенку важно научиться составлять понятные запросы, проверять ответы 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 школ с ИИ для детей представлены разные подходы: от индивидуального обучения нейросетям до серьезного сочетания искусственного интеллекта и программирования.

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

Кого затронет обновление

Изменения важны для команд, которые добавляют mise.lock в репозиторий и используют его в CI. Новый формат не читается старыми версиями mise. Вместе с файлом блокировки нужно сохранять каталог .mise/locks/ или .config/mise/locks/. В нём находятся uv.lock, aube-lock.yaml и манифест, а mise.lock ссылается на записанный граф по относительному пути и SHA-256.

Существующие файлы блокировки ревизий 0 и 1 автоматически не меняются. Переход происходит после команды mise lock --upgrade. Для фиксации Python-графов требуется uv 0.12.10 или новее и опубликованные wheel-пакеты для целевой платформы.

Что ещё исправили

• Команда mise bootstrap dotfiles conflicts [PATH...] теперь показывает сравнение сохранённой локальной и полученной удалённой версий конфликтующего скрытого файла, не изменяя их.
• Настройка minimum_release_age больше не отклоняет уже зафиксированную в mise.lock версию из-за её возраста. Для незафиксированных транзитивных зависимостей npm: и pypi: ограничение сохраняется.
• Параметр history.describe_command теперь принимается из системной или глобальной конфигурации либо из переменной окружения MISE_HISTORY_DESCRIBE_COMMAND. Проектные значения игнорируются с предупреждением.
• Шаблоны скрытых файлов при mise oci build больше не могут обращаться к secret(), get_env(), exec(), read_file() и контексту окружения.

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

Перед добавлением файла mise.lock ревизии 2 в репозиторий нужно обновить mise у коллег и в CI, затем добавить сопутствующий каталог. Если записанный граф отсутствует или его контрольная сумма не совпадает, установка с --locked завершится ошибкой.

Источники

Release v2026.9.7: Lockfile revision 2 with npm and Python dependency graphs, dotfile conflict inspection · jdx/mise · GitHub

Что ещё изменилось

MCP-сервер теперь раздаёт общий каталог навыков через путь /mcp. В поставку также добавили навык phoenix-error-analysis, а во внутрипроцессной диспетчеризации MCP-инструментов исправили передачу состояния жизненного цикла приложения.

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

Источники

• Release arize-phoenix: v20.11.0 · Arize-ai/phoenix · GitHub

Обновление затрагивает проекты, которые используют Metro для разработки и сборки. В релизе исправили Fast Refresh с ленивыми сегментированными бандлами, пропуск файлов, записанных в каталог во время его обхода FallbackWatcher, ошибки сокета при записи через HttpStore и обработку выражений с Platform.OS и Platform.select.

FallbackWatcher стал экономнее: потребление RSS при обходе файлов снизилось примерно на 34%, а пиковое использование heap — примерно на 41%. Также Metro отказался от зависимости image-size в пользу встроенных парсеров, чтобы устранить предупреждения CVE.

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

Источники

• Release v0.87.1 · react/metro · GitHub

Flatpak Builder — инструмент для разработчиков и сопровождающих Linux-приложений: он собирает их в пакеты формата Flatpak. Версия flatpak-builder 1.4.11 вышла 12 сентября. В ней полностью отключили Git-хуки при применении патчей. Изменение связано с уязвимостью CVE-2026-86320. Также разработчики исправили проблему GHSA-484h-v688-jq5j, из-за которой источник мог выйти за пределы base_dir в режиме песочницы.

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

Что делать

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

Источники

• Release 1.4.11 · flatpak/flatpak-builder · GitHub

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

Также команда отказалась от Swagger-компонентов в клиент-серверном режиме и заменила их реестром конечных точек на Go с поддержкой OpenAPI 3.2.1. В результате размер исполняемого файла уменьшился примерно на 4 МБ.

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

Релиз Crush 0.94.1 опубликован на GitHub.

Вторая критическая ошибка, CVE-2026-87719 с оценкой CVSS 9.9, находилась в сериализаторе подписок GraphQL в GitLab EE. Аутентифицированный пользователь с доступом к Duo Chat мог получить конфигурацию Advanced Search и чувствительные учётные данные. В релиз также вошли исправления уязвимостей, позволявших выполнять код удалённо, получать доступ к CI/CD-переменным, проводить XSS-атаки, вызывать отказ в обслуживании и обходить проверки доступа.

Обновиться следует владельцам self-managed-инсталляций, работающих на затронутых версиях. GitLab.com уже работает на исправленной версии, клиентам GitLab Dedicated ничего делать не нужно. Для одиночных узлов установка патча потребует простоя из-за миграций базы данных. Многоузловые системы можно обновить без остановки при соблюдении процедуры обновления без простоя (zero-downtime upgrade).

В продакшене следует как можно скорее перейти на последний патч поддерживаемой версии. Исправленные версии: 19.3.2, 19.2.6 и 19.1.8.

Источники

• GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 | GitLab Docs

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

За контекст кодовой базы отвечает Code Context на базе Teamwork Graph: он предоставляет Rovo и агентам для написания кода защищённый доступ к информации из нескольких репозиториев. Agent Context Controls ограничивает доступ агентов к рабочим пространствам и информации. Для оценки результатов Atlassian добавляет панель использования агентов и продукт DX for Agentic Development с метриками производительности, качества, внедрения и затрат.

По исследованию Atlassian, ИИ применяют 94% опрошенных руководителей инженерных команд, но системы для его масштабирования на весь цикл разработки есть только у 6%. Отдельный анализ DX показал, что команды, чьи ИИ-инструменты использовали больше всего контекста Teamwork Graph, показывали примерно на 64% больший объём выпуска в расчёте на разработчика. Компания не приводит методику этого сравнения в анонсе, поэтому показатель стоит воспринимать как внутренний ориентир, а не универсальный бенчмарк.

Code Context постепенно открывают платным клиентам Atlassian в публичной бете. Agent loops, Standards и AI Review пока доступны в закрытом раннем доступе. Контроль контекста и панель использования агентов обещают выпустить для платных клиентов Jira в ближайшие месяцы, а DX for Agentic Development для клиентов Atlassian DX — в текущем квартале.

Источники

• We’re bringing governed agent loops to the AI-Native SDLC - Inside Atlassian

Agent Manager научился создавать и просматривать многострочные комментарии к pull request, работать с предложениями изменений, показывать одобрения и готовность к слиянию. При отправке агенту замечаний из PR-панели Kilo теперь передаёт ему указание выполнить commit и push, но каждое действие по-прежнему требует подтверждения.

В VS Code и CLI появилась команда /caffeinate с уведомлениями о том, что Kilo не даёт компьютеру перейти в спящий режим во время работы агентов. Версия для VS Code также получила системные уведомления о завершении задач, запросах ввода и разрешений, а также ошибках терминала. Обе версии поддерживают однократный импорт поддерживаемых инструкций, простых навыков и отключённых MCP-конфигураций из Claude Code.

Главное несовместимое изменение касается CLI: разработчики удалили инструмент interactive_terminal, встроенные элементы управления интерактивным терминалом и связанные API. Команды, которым нужен ввод с клавиатуры, теперь придётся запускать в отдельном терминале.

В релизе расширили возможности Kilo для длительных агентных задач и сопровождения pull request. При этом в примечаниях к версии нет сравнения с Kilo 7.5 или конкурирующими агентами, а также сведений о цене, лимитах и доступности Kilo Code в России.

Источники

• Release v7.6.0 (release) · Kilo-Org/kilocode · GitHub

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

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

Разработчики перевели проекцию lm_head для chunked_nll с FP32 на BF16 и тензорные ядра. Раньше операция без пользы создавала тяжёлую копию весов и выполнялась по более медленному пути. В тестах авторов изменение ускорило отдельный расчёт в шесть раз, а пропускная способность обучения разных моделей выросла в 1,2–1,69 раза.

Обновление важно разработчикам, которые дообучают языковые модели через SFT, DPO, KTO, GRPO и дистилляцию. В trl.losses перенесли исходный код fused linear losses из Liger-Kernel. При этом для режима use_liger_kernel по-прежнему требуется установленный liger-kernel. Также добавили поддержку vLLM 0.28.0 и изменили поведение синхронизации весов vLLM: при несовместимости она завершается ошибкой, а не зависает.

Кому нужно проверить совместимость

Из TRL удалены PPOTrainer, PPOConfig и модели-обёртки с value head. Активных пользователей это почти не затронет: импорт PPOTrainer перестал работать ещё в версии 1.10, поэтому проекты с PPO уже должны быть закреплены на старом выпуске.

Перед обновлением также стоит проверить зависимости: теперь нужны peft версии 0.13.0 или новее и deepspeed не ниже 0.18.6. Кроме того, разработчики прекратили поддержку vLLM 0.19.0.

Источники

• Release v1.13.0 · huggingface/trl · GitHub

Нейросети становятся привычным цифровым инструментом для школьников. Дети используют их для создания изображений и текстов, подготовки презентаций, поиска идей и учебных проектов. При этом простого знакомства с 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 для создания собственных проектов.

В комплект входит конфигурация Developer Knowledge MCP Server. Через неё агент может получать актуальные сведения из официальной документации Google для разработчиков.

Кого затронет выпуск

Плагин предназначен для разработчиков, которые используют ИИ-агентов при настройке проектов и инфраструктуры Google Cloud. Установку поддерживают Antigravity CLI, Claude Code и Codex CLI.

Почему это важно

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

В качестве примера Google описывает первоначальную настройку проекта и аутентификацию. В этом сценарии агент проверяет доступность CLI и существующие проекты или организации, учитывает рекомендации IAM, составляет план работы и предлагает выполнить его до изменения ресурсов. Для внедрения стоит установить пакет из Google Agent Skills и проверить этот сценарий на используемом агенте до разрешения операций с ресурсами.

Источники

• Introducing the Google Cloud Developer Plugin for AI Coding Agents | Google Cloud Blog

Связки react.Bind и react.Callback работают как мост между серверной логикой и интерфейсом. Например, изменение React-слайдера обновляет состояние Python-приложения, а новое значение возвращается в компонент без отдельного REST API или вручную написанной синхронизации.

Обновление рассчитано на организации с готовыми библиотеками React-компонентов, дизайн-системами и фирменными виджетами. Они смогут использовать эти наработки в приложениях trame без полной переработки фронтенда. На старте заявлена поддержка обычных HTML-элементов, MUI, удалённого рендеринга через trame-rca и локального VTK-рендеринга через trame-vtklocal.

Для новых проектов без существующей React-кодовой базы мало что изменится. Vue.js остаётся стандартным и наиболее полным клиентом trame, а Kitware не обещает полного равенства возможностей двух экосистем.

Источники

• Trame v4: Your React Investment, Now Driven by Python

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

Администраторам Copilot Enterprise может потребоваться разрешить новую модель в политиках организации. После этого она появится в списке моделей Copilot Chat в VS Code и на github.com. Доступность сервиса из России в публикации не уточняется.

Источники

• MAI-Code-1-Flash deprecated - GitHub Changelog

По заявлению DeepSeek, модель превосходит V4-Pro по производительности, стоимости, скорости и общему времени выполнения задач. Компания ссылается на тесты нескольких сторон, но в анонсе не приводит их список и методику, поэтому независимо оценить сравнение по опубликованному тексту нельзя.

Разработчикам потребуется проверить используемые идентификаторы моделей. V4-Flash и V4-Flash-Vision-Exp выведены из эксплуатации, а их прежние API-имена пока перенаправляются на V4.1-Flash. С 04:00 UTC 14 сентября такой же временный маршрут включат для deepseek-v4-pro, он сохранится до выхода V4.1-Pro.

Компания также заявляет о сокращении KV-кэша относительно прошлого поколения: ему требуется четверть прежнего объёма HBM и одна восьмая объёма SSD. DeepSeek снизила тарифы API с 10 сентября, однако конкретные суммы в анонсе не указаны. Вне пиковых часов действует скидка 50%. Лимиты API и условия доступности сервиса из России источник не уточняет.

Источники

• DeepSeek | Introducing DeepSeek-V4.1-Flash: smarter, faster, more efficient.

На связи команда облачного провайдера 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

Для программиста, который уже работает с агентами, это готовая замена самодельным файлам с инструкциями и длинным описаниям задачи в чате. Вместо «сделай мне функцию экспорта» агент получает конституцию проекта, спеку с пользовательскими историями, технический план и список задач в репозитории, и каждый шаг можно прочитать и поправить до того, как появится код. За год к базовой цепочке добавились команда сверки кода со спекой, расширения для багфикса и оценки идей, пресеты под стандарты команды и бандлы под роли. Spec Kit при этом не единственный репозиторий такого рода в топе GitHub: за ту же неделю звёзды собирали ещё десять проектов про агентов, от скиллов и надстроек над Claude Code и Codex до локального инференса и управления Blender; они разобраны во второй части.

• Spec Kit 1.0.0 вышел 21 августа 2026 года, текущий релиз 1.0.6 от 10 сентября; между ними шесть патч-релизов.
• Ставится через uv или с PyPI, командой specify init подключается к проекту под любой из более чем 30 агентов.
• Цепочка из шести слэш-команд: constitution, specify, plan, tasks, implement, converge; последняя сверяет код со спекой и дописывает недостающие задачи.
• Расширение bug ведёт исправление по шагам «оценить, починить, проверить», assess разбирает идею до решения «делать» или «не делать».
• Мейнтейнер пишет, что 1.0 больше не обещает стабильности API: ломающие изменения агент теперь переносит сам.
• Среди набравших звёзды за неделю: ponytail (135 тысяч, режет объём кода агента на 54% в замере автора), ECC (256 тысяч), skills (259 тысяч), humanizer (46 тысяч), archify (57 тысяч), HyperFrames, MiniMind, Magnitude, SGLang и blender-mcp.

Что такое Spec Kit и как он работает?

Spec Kit это утилита specify на Python плюс набор markdown-шаблонов и скриптов, которые она раскладывает в проект. После specify init в каталоге агента (например, .claude/ или .github/) появляются слэш-команды или скиллы с префиксом speckit, а в .specify/ лежат шаблоны документов. Дальше вся работа идёт внутри привычного агента.

Базовая цепочка описана в README репозитория и состоит из шести шагов. /speckit.constitution один раз на проект фиксирует принципы: стек, стиль, что запрещено. /speckit.specify превращает описание задачи в спеку с требованиями и пользовательскими историями, /speckit.plan пишет технический план под выбранный стек, /speckit.tasks режет план на задачи, /speckit.implement их выполняет. Замыкает цикл /speckit.converge: команда сравнивает кодовую базу со спекой, планом и задачами и дописывает в список то, что ещё не сделано. Шаги implement и converge повторяются, пока converge не сообщит, что всё сошлось.

Есть три необязательные команды. /speckit.clarify вытаскивает недосказанное из спеки вопросами, её рекомендуют запускать до плана. /speckit.analyze ищет расхождения между спекой, планом и задачами после tasks и до implement. /speckit.checklist генерирует чек-листы качества требований, в документации их называют «юнит-тестами для английского языка». Команда /speckit.taskstoissues, которая раскладывает задачи в GitHub Issues, в релизе 1.0.5 помечена как уходящая из ядра в отдельное расширение github-issues; пока она работает.

Что изменилось к версии 1.0?

Год назад Spec Kit был набором шаблонов под несколько команд и несколько агентов. К 1.0 вокруг ядра выросла система настройки из четырёх слоёв. Внизу ядро с встроенными командами и шаблонами, выше расширения, которые добавляют новые команды, ещё выше пресеты, которые переписывают шаблоны ядра и расширений, а на самом верху локальные правки конкретного проекта в .specify/templates/overrides/. Шаблоны разрешаются во время выполнения сверху вниз, побеждает первое совпадение.

Два расширения идут в комплекте и включаются по желанию. specify extension add bug добавляет цепочку из трёх команд для исправления ошибок: assess проверяет диагноз по отчёту, fix чинит именно найденную причину, test подтверждает, что исходный симптом исчез. Авторы объясняют это тем, что агент, который прыгает от баг-репорта сразу к патчу, часто чинит не то. Расширение assess работает ещё до спеки: intake, research, define, shape, decide, на выходе документированное решение «делать», «нужны уточнения» или «не делать». Идею с решением «делать» можно передать в /speckit.specify.

Пресеты ставятся командой specify preset add и меняют форму, а не набор возможностей: например, требуют в спеке трассируемость под регуляторику, добавляют обязательный этап проверки безопасности в план, переставляют задачи так, чтобы тесты шли первыми, или переводят весь процесс на другой язык. Бандлы собирают расширения, пресеты, шаги и рабочие процессы в один версионированный набор под роль: продакт-менеджер, аналитик, исследователь безопасности, разработчик. Ставится бандл одной командой specify bundle install, каталог бандлов у проекта свой, поверх пользовательского и встроенного. В релиз-нотах 1.0.x рядом с исправлениями регулярно идут обновления расширений сообщества, например Jira Mirror в 1.0.2, и правки в загрузчике бандлов.

Список агентов вырос до более чем 30. Для части из них, включая Claude Code, Codex CLI, Copilot и Devin, команды ставятся как скиллы, а не как файлы промптов, и вызываются как /speckit-specify или $speckit-specify, в зависимости от агента. Для остальных остаётся режим слэш-команд; переключатель --integration-options="--skills" есть у тех, кто поддерживает оба.

Почему 1.0 больше ничего не обещает?

Ведущий мейнтейнер проекта в записи к годовщине прямо говорит, что единица в номере версии здесь только число. Раньше мажорная версия была страховкой от стоимости изменений: ломающее изменение означало ручной обход всех мест вызова по гайду миграции, и семантическое версионирование превращало эту стоимость в сигнал. Теперь, по его словам, адаптация к ломающему изменению это одно предложение агенту, который правит места вызова быстрее, чем автор успевает описать их в changelog. Поэтому 1.0.0 у Spec Kit значит «хорошее место, чтобы начать», а не обещание замороженной формы. Это заявление проекта о себе, и для команд, которые встраивают Spec Kit в CI и внутренние инструменты, оно означает, что пинить версию всё равно придётся: за три недели после 1.0.0 вышло шесть патч-релизов.

Как установить и с чего начать?

В README рекомендуют менеджер uv, альтернатива pipx. Установка идёт с привязкой к тегу релиза, тег с ведущей буквой v, либо из PyPI, где пакет specify-cli обновлён до 1.0.6. Проверить, не вышла ли новая версия, можно командой specify self check.

Ключ --integration принимает имя агента из списка интеграций, например copilot, claude, codex, cursor-agent или gemini; полный перечень выдаёт specify integration list. Дальше запускается сам агент в каталоге проекта, и цепочка начинается с /speckit.constitution.

Кому это не нужно?

Spec Kit не единственный инструмент такого рода. Kiro от AWS делает то же самое внутри собственной IDE на базе VS Code, у Tessl это CLI и MCP-сервер к разным ассистентам, а сам фреймворк на момент разбора был в закрытой бете; в разборе трёх подходов на сайте Мартина Фаулера Spec Kit выделяют как самый агентонезависимый: это markdown и скрипты в репозитории, которые легко править. Обратная сторона та же: спека, план и задачи это документы, которые кто-то должен читать, и для правки в одну функцию цепочка из шести команд избыточна. Авторы и сами пишут в README, что не каждое изменение проходит полный цикл: небольшие исправления идут обычным путём через issue, pull request, ревью и тесты.

Какие ещё репозитории про ИИ-агентов набирали звёзды на этой неделе?

Подборку из десяти репозиториев, которые «за неделю разом собрали звёзды», опубликовал 10 сентября японский аккаунт So AInsight; прирост за неделю там не приведён, поэтому ниже суммарное число звёзд на 11 сентября по данным GitHub. Половина списка про то же, что и Spec Kit: как заставить агента работать по процессу, а не по настроению; остальное про инференс, обучение и управление другими программами.

1. skills, 259 тысяч звёзд. Скиллы Мэтта Покока, автора Total TypeScript, из его рабочего каталога .agents: небольшие, составные, под любую модель. В README автор прямо противопоставляет их Spec Kit, GSD и BMAD: те, по его словам, забирают процесс себе и делают ошибки в нём трудноразрешимыми.
2. ECC, 256 тысяч. Надстройка над Claude Code, Codex, OpenCode и Cursor с циклом «план, тест, реализация, ревью из свежего контекста, проверка, память, улучшение». Репозиторий под MIT, у автора есть платная версия ECC Pro как GitHub App для приватных репозиториев от $19 за место в месяц.
3. ponytail, 135 тысяч. Скилл, который заставляет агента думать «как самый ленивый сеньор»: перед кодом пройти лестницу из семи вопросов, от «нужно ли это вообще» до «есть ли это в стандартной библиотеке». Автор замерил на Claude Code и репозитории full-stack-fastapi-template по 12 тикетам: минус 54% строк, минус 22% токенов, минус 20% стоимости против агента без скилла; ранние цифры «на 80–94% меньше кода» он сам признал завышенными из-за некорректной базы.
4. archify, 57 тысяч. Скилл для Cursor, Claude Code, Codex CLI и OpenCode: агент описывает систему типизированным JSON, Node.js-компилятор превращает его в самодостаточный HTML с интерактивной схемой архитектуры, последовательности или потока данных, экспорт в PNG, SVG и WebM. Умеет сравнивать два снимка архитектуры до и после изменения.
5. humanizer, 46 тысяч. Скилл на чистом markdown, который переписывает текст агента так, чтобы в нём не было характерных следов машинного письма, без изменения смысла; ставится через npx skills add blader/humanizer или как плагин Claude Code.
6. HyperFrames, 49 тысяч. Проект HeyGen: пишешь HTML, получаешь видео. Рассчитан на агентов, которым нужно генерировать ролики с диаграммами и озвучкой без съёмки; TypeScript, Apache 2.0, Node 22 и новее.
7. MiniMind, 61 тысяча. Учебный проект: обучить языковую модель на 64 млн параметров с нуля на чистом PyTorch. Заявленные «2 часа» и «3 юаня» это оценка автора для одного прохода предобучения и дообучения минимальной версии на одной RTX 3090 и аренда GPU на это время; в репозитории полная цепочка от предобучения до DPO, GRPO и агентного RL, плюс версии с картинками и диффузией.
8. Magnitude, 4 тысячи. Локальный движок инференса: профилирует машину (Mac, NVIDIA, AMD или только CPU), подбирает подходящие модели, скачивает, настраивает и запускает их. Единственный проект списка с числом звёзд в тысячах, а не десятках тысяч.
9. SGLang, 36 тысяч. Зрелый фреймворк раздачи больших языковых и мультимодальных моделей под нагрузкой, существует с января 2024 года; в список попал, судя по всему, из-за очередного всплеска интереса, а не как новинка.
10. blender-mcp, 28 тысяч. MCP-сервер и аддон, через которые любая модель управляет Blender: создание сцен, моделирование и расстановка объектов по текстовому запросу. Сторонний проект, к Blender Foundation отношения не имеет, о чём README предупреждает отдельно.

Общий знаменатель списка тот же, что у Spec Kit 1.0: скиллы и надстройки, которые фиксируют процесс работы агента в репозитории, стали отдельной категорией инструментов, и у неё уже есть внутренняя полемика. Spec Kit и ECC предлагают полный цикл, skills и ponytail дают отдельные небольшие правила, которые сочетаются с чем угодно. Что выбирать, зависит от размера задачи: для мелких правок цепочка из шести команд избыточна, для новой функции с несколькими файлами спека и план окупаются тем, что их можно прочитать до кода.

Что смотреть дальше у Spec Kit: вынос /speckit.taskstoissues в расширение github-issues и следующие патч-релизы: между 1.0.1 и 1.0.6 паузы были от нескольких часов до десяти дней. Раздел экспериментальных целей из README никуда не делся, сроков по 1.1 или 2.0 GitHub не называет.

Источники: GitHub: репозиторий github/spec-kit, Релиз Spec Kit v1.0.0, Релиз Spec Kit v1.0.6, Manorrock: Spec Kit Turns One — and Ships 1.0.0, Документация: поддерживаемые агенты, Martin Fowler: Understanding Spec-Driven Development: Kiro, Spec-Kit, and Tessl, So AInsight в X: десять ИИ-инструментов, собравших звёзды на GitHub за неделю, GitHub: mattpocock/skills, GitHub: affaan-m/ECC, GitHub: DietrichGebert/ponytail, GitHub: tt-a1i/archify, GitHub: blader/humanizer, GitHub: heygen-com/hyperframes, GitHub: jingyaogong/minimind, GitHub: magnitudedev/magnitude, GitHub: sgl-project/sglang, GitHub: ahujasid/blender-mcp

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

Есть классическая проблема: изолированные процессы — хорошо для надёжности, но хочется иногда позвать функцию из соседа, как будто она лежала в той же библиотеке. Стандартные 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.

• CVE-2026-75650 — некорректная нейтрализация специальных элементов в шаблонизаторе Adobe Commerce и Magento
• CVE-2026-81963 — уязвимость обработки ссылок в Microsoft Windows
• CVE-2026-85880 — переполнение буфера в куче Microsoft Windows
• CVE-2026-86218 — внедрение статического кода в N-able N-central

Кого это касается

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

Требования директивы BOD 26-04 распространяются на гражданские федеральные ведомства США. Российские пользователи и хостинги под действие директивы не попадают, но могут быть технически уязвимы, если эксплуатируют соответствующее ПО.

Что делать сегодня

Администраторам следует сверить перечень установленного ПО с новыми позициями KEV и приоритизировать устранение найденных уязвимостей с учётом риска. BOD 26-04 также определяет, в каких случаях гражданские ведомства федеральной исполнительной власти США должны проверять, не была ли система скомпрометирована до установки исправления. CISA рекомендует всем организациям устранять уязвимости с учётом риска и отдавать приоритет уязвимостям из KEV.

Источники

• CISA Adds Four Known Exploited Vulnerabilities to Catalog | CISA

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

Что проверить разработчикам

• Обновить сборочное окружение до Xcode 27 RC и проверить приложение на новых версиях операционных систем.
• Указать в App Store Connect наличие функций социальных сетей, если они есть в приложении или игре. Это связано с новыми настройками родительского контроля Time Allowances.
• Проверить оформление страницы через новый инструмент предварительного просмотра. Apple также добавила заголовки продуктовых страниц и материалы для поисковой выдачи.

macOS 27 отказывается от Intel

macOS 26 станет последней версией с поддержкой компьютеров Mac на Intel и Rosetta. macOS 27 будет работать только на Apple silicon. Чтобы ограничить приложение такими устройствами, в настройках архитектур сборки Xcode нужно оставить только arm64, затем пересобрать проект и повторно отправить сборку.

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

• Приложения для iOS и iPadOS потребуется собирать с iOS 27 и iPadOS 27 SDK или новее.
• Минимальным требованием для tvOS станет tvOS 27 SDK или новее.
• Приложения для visionOS потребуется собирать с visionOS 27 SDK или новее.
• Для watchOS потребуется watchOS 27 SDK или более новая версия.

Источники

• App Store submissions now open for the latest OS releases - Latest News - Apple Developer

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

Программа включает более 20 экспертных докладов в четырех тематических блоках:

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

Участники также смогут принять участие в интерактивных воркшопах и посетить технологическую выставку с более чем 20 стендами от Selectel и партнеров мероприятия: CURATOR, Arenadata, Deckhouse, DDoS-Guard, Кибердом и других. Также можно будет получить экспертные консультации по вопросам развития IT-инфраструктуры и выбора продуктовых решений.

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

О компании Selectel

Selectel — крупнейший независимый провайдер сервисов IТ-инфраструктуры в России.

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

Продукты компании позволяют бизнесу отказаться от капитальных затрат на собственную IT-инфраструктуру, обеспечить её масштабируемость и высокую производительность. Selectel работает на рынке с 2008 года, на сегодняшний день у компании более 44 000 клиентов. Подробнее на сайте: selectel.ru

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

Подростки уже используют нейросети для учебы, поиска информации, создания изображений, текстов и презентаций. Но между «задать вопрос 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, перевод медленных запросов в метрики надёжности и разбор того, как метрики вводят в заблуждение.

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

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

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

Источники

• Fresher features, faster fixes: The two-week release cycle is here | Blog | Chrome for Developers

Check Point Research обнаружила канал в июне 2026 года и опубликовала исследование 8 сентября 2026 года.

Контейнеры ChatGPT не имели прямого доступа в интернет и не могли обращаться друг к другу, но использовали общий внутренний JFrog Artifactory для загрузки зависимостей. Доступные контейнерам операции позволяли записывать данные в свойства объектов и читать их из другого аккаунта. Исследователи назвали этот механизм «общим буфером обмена».

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

По сообщению Check Point Research, к завершению отчёта межаккаунтный канал уже был недоступен. OpenAI подтвердила, что обнаруженный исследователями внутренний экземпляр Artifactory был выведен из эксплуатации.

Кого это касалось

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

Почему это важно и что проверить

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

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

• Проверить список подключённых к ChatGPT приложений и отозвать ненужные разрешения.
• Для оставшихся интеграций включить режим Always ask, если он доступен.
• С осторожностью использовать чужие общие диалоги и пользовательские GPT, особенно при подключённых рабочих сервисах.
• Обратить внимание на отметки об обращении ChatGPT к Gmail и другим приложениям, если пользователь не запрашивал такое действие.

Источники

• The Shared Clipboard Inside the Sandbox: Cross-Account Data Leakage in ChatGPT - Check Point Research

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

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

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

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

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

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

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

Управляющий слой 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, разработкой сайтов, игр и приложений.

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

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

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

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