Мне эта модель быстро наскучила.

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

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

- это не убийца Telegram;

- это не презентация для инвестора с KPI и growth loops;

- это не проповедь о том, как всем теперь жить.

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

И вот здесь началось смешное.

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

Что это вообще такое

На текущем этапе это PWA-мессенджер.

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

«настоящие пацаны пишут только натив». Можете не разогреваться, я это всё уже сам себе рассказал.

Почему все равно PWA:

- мне нужен был короткий путь от идеи до живого клиента;

- мне нужен был быстрый цикл выката без ритуальных танцев с

магазинами приложений;

- мне нужен был клиент, который можно быстро ломать, чинить,

пересобирать и снова кидать в бой;

- мне нужно было что заработает на разных платформах;

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

У PWA есть реальные потолки:

- нет такой свободы по платформенным API, как у нативного клиента;

- фон, пуши и некоторые сценарии мобильной жизни работают хуже, чем

хотелось бы;

- нет нормальных VoIP-пушей (звонки работают только когда приложение

открыто), нет нормальной интеграции со списком вызовов телефона;

- по голой производительности натив его обгоняет.

И, да, Service Workers иногда ведут себя как подростки в пубертате, а iOS местами режет фоновую жизнь PWA так, будто лично обиделась на идею веб-клиента. Я в курсе. Выживаем с тем, что есть.

Но для моей задачи PWA дал главное: скорость эволюции. А в экспериментальном проекте это иногда важнее, чем стерильная идеология.

И да, работает эта штука подозрительно хорошо. Лучше, чем я ожидал, если честно.

Зачем вообще писать еще один мессенджер, когда мир и так ими забит

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

Потому что я люблю контролировать инфраструктуру, а не молиться на чужую.

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

Потому что мне скучно.

Да, это тоже важная часть правды. На обычной работе мозг периодически начинает зевать от предсказуемости. А когда ты в одиночку пытаешься собрать живой real-time-сервис, где есть сессии, доставка сообщений, поиск, синхронизация состояния, очереди и weird cases мобильной сети —

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

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

Где начинаются не разговоры про highload, а настоящая инженерная жизнь

Пока не собираешь такое сам, кажется, что мессенджер — это просто чатик.

Ну текстик, ну websocket, ну кнопка «отправить», господи. А потом начинается взрослая часть спектакля.

1. Сообщение должно не просто уйти, а дойти правильно

Самая скучная и самая дорогая ошибка — считать, что «отправил» значит

«доставил».

Нет. В реальной жизни между клиентом, сетью, сервером и хранилищем полно мест, где всё может стать интересно:

- клиент послал пакет, но сеть моргнула;

- сервер принял, но клиент не получил подтверждение;

- клиент решил, что ничего не дошло, и отправил повторно;

- внезапно у тебя уже не просто доставка, а идемпотентность,

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

дублями.

И это только один кусок.

2. Порядок сообщений — штука гораздо более капризная, чем кажется

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

Инженерная реальность куда веселее:

- локальный optimistic update на offline-first клиенте хочет быть

быстрым;

- серверная истина хочет быть правильной;

- база хочет жить в своей временной линии;

- несколько устройств одного пользователя могут в это время смотреть на

мир разными глазами.

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

3. Race condition — это когда баг уже произошел, но ты еще не знаешь, где именно тебя унизили

Race conditions — мой любимый жанр инженерного фольклора. Это когда всё прекрасно, пока ты смотришь. И ломается ровно в тот момент, когда отвлекся налить кофе.

Условно:

- один поток думает, что пользователь в онлайне;

- второй уже считает, что он отвалился;

- третий в это время честно пишет новое состояние;

- четвертый с невинным лицом отдает клиенту вчерашнюю правду.

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

4. Любая «маленькая фича» очень быстро приходит за твоей архитектурой с ножом

Захотел новую механику? Например, необычную резервацию UIN еще до регистрации? На бумаге выглядит забавно. На бэкенде начинается вечеринка:

- появляется состояние для еще не существующего пользователя;

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

- нужно думать о TTL, освобождении, гонках, повторных запросах и кривом клиентском поведении;

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

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

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

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

И тут выясняется, что в реальном мессенджере мало просто «хранить сообщения». Нужно еще:

- быстро искать;

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

- не превращать сервер в печку под нагрузкой;

- думать наперед, где потом начнется горизонтальное масштабирование, а

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

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

Под этот запрос у меня лежит не молитва, а вполне конкретная опора: partial GIN index по выражению`(content->>'text') gin_trgm_ops`.Иначе такая красота очень быстро превращает сервер в отопление стойки за счет тупого перебора JSONB.

А вот так тот же самый функционал очень часто пишут новички — вроде работает, пока данных смешно мало:

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

На реальном объеме истории в проде разница здесь может быть уже не в процентах, а на порядок и выше. То есть это очень быстро превращается не в «чуть-чуть быстрее», а в 10x+, а дальше всё зависит от размера истории, доли текстовых сообщений, партиций и того, насколько сильно вы любите мучить PostgreSQL.

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

6. Очереди, ретраи и backpressure — это не украшения, а повод спать чуть спокойнее

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

То есть нужны:

- очереди (Kafka, или что вы там предпочитаете);

- повторные попытки (retry-логика);

- backpressure;

- вменяемая реакция на временную деградацию (graceful degradation);

- circuit breaker чтобы какой-нибудь маленький и вроде бы некритичный сервис не мог каскадно положить бы всю инфраструктуру;

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

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

Интерфейс я подсматривал у Telegram. И да, специально

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

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

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

Моя любимая инженерная шалость: UIN-рулетка до регистрации

Тут я, конечно, немного похулиганил.

Я сделал резервацию UIN еще до этапа регистрации. То есть можно зайти, поймать красивый номер, а уже потом решить, нужен тебе вообще этот зоопарк или нет.

С человеческой стороны это фан, ностальгия и немного ICQ-вайба.

С серверной стороны это пачка вопросов:

- как хранить состояние для «почти-пользователя»;

- как не раздать красивые номера слишком щедро;

- как не дать мимо проходящему ботнету выгрести пул;

- как освобождать резервы и не плодить мусор;

- как не застрелить логическую целостность ради красивой игрушки.

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

Про безопасность — без дешевой магии и без сказок для инвестора

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

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

- транспорт закрыт современным TLS 1.3 (который на текущий момент, март 2026, взломать прямым криптографическим методом практически невозможно);

- клиент живет как PWA в браузерной песочнице, какая уже сама по себе имеет ряд уровней защиты;

- поверх этого я стараюсь не творить откровенной дичи;

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

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

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

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

Почему я вообще тащу это именно на TProger

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

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

- где архитектура выглядит спорно;

- где логика доставки сообщений может начать чудить;

- где PWA упрется в реальные ограничения платформы;

- где резервация UIN создает лишнюю поверхность атаки;

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

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

Мне не нужен хор в духе «вау, круто».

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

Вот ему я и пишу.

Что я от вас хочу

По сути — честной драки, но умной.

- Хотите проверить, как это переживает плохую сеть — отлично.

- Хотите посмотреть, как выглядит поведение в edge-cases — вообще прекрасно.

- Хотите понять, насколько легко читается логика протокола — давайте.

- Хотите найти баг в порядке сообщений, в кеше, в подтверждениях, в резервации UIN, в клиентском поведении — тем более.

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

Мне это полезнее, чем аплодисменты.

И да: я не заявляю, что построил новый и единственно верный мессенджер.

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

Что можно делать прямо сейчас

- Если вы параноик или устали от мейнстрима и навязанных решений — держите это как запасной канал связи.

- Если вы соскучились по временам красивых UIN — приходите ловить UIN-номер.

- Если вы любите sniff, разбор трафика и сетевые игры — смотрите что идет по проводу.

- Если у вас профессиональная привычка первым делом искать edge-cases — вот, собственно, ради вас всё это и принесено.

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

Что дальше

Планы без корпоративной шелухи, но вполне понятные:

- дальше допиливаю PWA-версию;

- нативные Android и iOS-клиенты — в планах, но пока не в приоритете;

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

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

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

Итог

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

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

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

Если хотите просто еще один канал связи — пожалуйста.

Если хотите посмотреть и проверить, насколько крепок мой цифровой эксперимент, — тем более пожалуйста.

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

Добро пожаловать.

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

PS:

Меня там можно найти по нику IGRYM или по UIN 10001. Также есть внутренняя группа для первых пользователей (Early Birds, доступна на экране списка чатов через «+» вверху экрана)

Ссылки:

- Приложение: https://beta.plumb-app.ru/

- Телеграм-канал с новостями проекта: https://t.me/plumb_channel

- Телеграм-группа обсуждения: https://t.me/plumb_group

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

Давайте же вместе найдем то самое направление в IT и Digital, которое зажжет огонек в глазах вашего школьника.

Создание игр и виртуальных миров

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

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

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

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

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

Курсы на зимних каникулах в этом направлении:

«Создание игр и основы программирования для детей 8-11 лет: Minecraft, Python, Blender» в школе программирования «Пиксель»

В программу входит создание игры на Python в стиле Minecraft и 3D-моделирование в Blender. Дети будут создавать собственные локации по мотивам Minecraft, населять их объектами и персонажами, программировать простые взаимодействия. Итогом станет свой собственный небольшой, но полностью рабочий игровой мир, в который можно пригласить друзей.

Зимний онлайн-лагерь школы программирования «Пиксель» рассчитан на 5 дней, по 2 урока в день. Огромное преимущество курсов в этой школе — большое количество программ (всего их около 20) и то, что каждая программа сочетает в себе по два направления. Например, есть курсы с 3D-моделированием и разработкой игр, 2D-дизайном и созданием игр в визуальных средах, проектированием сайтов в Figma и созданием 3D-игры в Unity — и многие другие. Такие курсы будут особенно интересны детям, которые еще не определились со своим направлением в IT или хотят попробовать себя в новых сферах.

Курс «99 ночей в зимнем лесу» для детей от 7 до 14 лет в Компьютерной Академии ТОП

Здесь дети займутся графикой и 3D. Они смоделируют новогоднего оленя в Tinkercad и создадут собственную игровую локацию, сгенерируют стикерпак для Telegram с помощью ИИ, нарисуют вексельный костер в 3D-редакторе MagicaVoxel.

Этот курс также длится 5 дней. Кроме него у Академии ТОП есть еще один пятидневный курс «Зимние IT-каникулы: спасаем Новый год» и бесплатный мини-интенсив на один день «Создание новогоднего сайта на Tilda».

Цифровое творчество — рисунок, анимация, видео

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

Курсы в списке подойдут юным визуалам и творцам, а именно тем, кто:

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

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

• Цифровая иллюстрация. Техники рисования на графическом планшете или в программах. Как работать со слоями, подбирать палитру, создавать цельные картины или стикеры.
• Создание 2D-анимации. Волшебство оживления картинки. Дети узнают, что такое раскадровка, ключевые кадры и плавные переходы. Как заставить нарисованного героя махнуть рукой или улыбнуться.
• Основы видеомонтажа и цветокоррекции. Как из разрозненных видео склеить цепляющую историю? Что такое «цветовой круг» и как с его помощью создать нужное настроение в видео? А это уже навыки продюсирования контента.

Онлайн-курсы на зимних каникулах в этом направлении:

Онлайн-лагерь «Марафон видеоблогеров» для детей 7-12 лет в школе «Лидерландия»

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

«Блогинг и цифровая графика: Figma+Scratch (создание блога и мультфильма)» в школе программирования «Пиксель»

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

Программирование и веб-технологии

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

Это направление — находка для юных аналитиков и исследователей, а именно для тех, кто:

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

За короткий интенсив ребенок прикоснется к самым востребованным инструментам IT-индустрии и создаст свои первые рабочие проекты:

• Основы языков программирования Python или JavaScript. Дети узнают, что такое переменные, условия, циклы — не в теории, а сразу применяя их для оживления своих проектов.
• Верстка сайтов (HTML/CSS). Как устроены сайты. Как сделать так, чтобы страница была не только информативной, но и красивой, и отлично выглядела на любом устройстве.
• Создание интерактива. Самый волнующий момент — «оживление» страницы или создание полезной программы. Это может быть интерактивная викторина на сайте, простой чат-бот или мини-игра.

Курсы на зимних каникулах в этом направлении:

«Веб-разработка HTML/CSS и программирование на Python: создание сайта по интересам и создание игры» в школе «Пиксель»

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

Вторая часть курса — создание игры на Python. Python — один из самых понятных и при этом мощных языков, именно поэтому путь в IT часто начинается с него. На интенсиве дети изучат его основы, работая над графической игрой.

Бесплатный мастер-класс для детей «Программируем на Python» в школе «Тетрика»

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

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

1. Определите интерес — обязательно вместе с ребенком.

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

1. Проверьте расписание и нагрузку.

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

1. Узнайте про итоговый проект.

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

1. Выясните технические требования.

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

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

Почему пет-проекты остаются самым понятным способом войти в IT

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

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

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

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

Как работают петы для разных грейдов:

• Для начинающих и мидлов пет-проекты — понятный маркер потенциала. Публичный репозиторий с живой историей коммитов показывает процесс мышления. Это сигнал инициативности и самостоятельности.
• Для middle-разработчиков активный проект говорит о зрелости и желании расти, а также о способности мыслить архитектурно и предлагать решения с нуля. Часто именно такие проекты помогают вырасти до роли тимлида.
• Для senior-уровня личные проекты могут быть признаком глубокой вовлечённости и лидерских качеств. Однако в некоторых компаниях это может вызвать вопросы о приоритетах и рисках отвлечения от основных задач — здесь всё зависит от контекста.

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

Как выбрать идею пет-проекта

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

Признаки «живой» идеи

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

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

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

Где искать идеи

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

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

Работа в команде даёт дополнительный ресурс — внутренние боли, на которые не хватает рук. Даже простой internal tool с внятным UX может стать ценным проектом.

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

Форматы пет-проектов, которые реально прокачивают

«Витринные» проекты против реальных

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

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

Типы проектов, которые чаще приводят к офферам

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

Тип проекта — бот, API, open-source-библиотека или мини-продукт — не так важен. Ключевые критерии:

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

Такие проекты легко оценить и привести как аргумент на собеседовании.

Форматы, которые развивают

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

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

Что убивает пет-проекты

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

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

Привычные ошибки, которые мешают доводить до результата

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

Как правильно выстроить пет-проект

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

С чего начать — минимальная версия

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

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

Приоритеты: фичи, архитектура, документация

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

• Сложность реализации (1–3 балла)
• Ценность/интересность (для вас или проекта в целом)

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

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

Тестирование и фидбэк на ранних этапах

Ранняя обратная связь спасает от лишней работы и блуждания в идеях.

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

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

Как масштабировать своего «питомца»

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

Первый шаг — техническая «чистка»: сделать код читаемым, удалить хаос и лишнее, добавить минимальную структуру, тесты, README с инструкциями. Если проект нужно устанавливать, должны быть чёткие шаги запуска и список зависимостей. Интерфейс — со скриншотами, демо и понятным user flow. Для API — список эндпоинтов и структура запросов. Логику полезно визуализировать в виде диаграмм.

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

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

Советы по масштабированию

1. Вести осмысленные разговоры с потенциальными пользователями, экспертами и теми, кто решал похожие задачи — это поможет понять, что действительно ценно, а что мешает.
2. Оценить масштабируемость: проект может быть полезным на малом масштабе, но рушиться при росте.
3. Определить вектор: B2B или B2C, чёткий портрет потребителя. Без этого презентация будет размыта.
4. При планах на инвестиции — предварительная оценка рынка, прогноз доли и гипотеза роста.
5. После подготовки — выход «в поле»: участие в отраслевых событиях, акселераторах и деловые знакомства.

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

Что дальше: превращаем проект в карьеру

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

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

Когда стоит показывать проект миру

1. Если он открыт на GitHub, уже доступен. Активно рассказывать о нём лучше после минимальной упаковки: README, описание, структура, работающая ключевая функция.
2. Для продвижения себя как продуктового специалиста, поиска команды или инвестиций нужно полноценное оформление: описание, демо, фидбэк, проработанная аудитория и сценарии применения.
3. Для портфолио или аргумента на собеседовании достаточно, чтобы проект был рабочим, логичным и понятным.

Удачи в петах!

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

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

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

Ненадёжный код

Для начала определимся, что же считать ненадёжным кодом? На самом деле ответ зависит от решаемой задачи, правил и процессов, принятых в компании:

• Код, который не прошел CI, review и т.п.
• Код из ненадёжного или неизвестного источника.
• Закрытый (проприетарный) код.
• Код, содержащий уязвимости.
• Код, использующий запрещенные функции.
• Любой код, который написал коллега:)

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

Уровни изоляции кода

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

Уровень 1: тот же процесс

Запуск внешнего кода в адресном пространстве процесса приложения.

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

Примером может служить использование интерпретаторов скриптов (Rhino, IronPython, Jython и т.п.), визуальных языков программирования (workflow-движков) или подключение модулей расширения (плагинов).

Способов защиты на этом уровне не так много. Пожалуй, самым эффективным выступает (self-sandboxing), при котором приложение делает самозапрет на доступ к некоторым ресурсам системы. Например, сразу после инициализации — самозапрет на доступ к файловой системе.

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

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

Уровень 2: отдельный процесс

Запуск внешнего кода на той же машине, но в отдельном процессе ОС.

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

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

Уровень 3: отдельная машина

Запуск внешнего кода на отдельной машине — песочнице.

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

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

Использование песочницы

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

Пересоздание или переиспользование песочницы

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

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

Основным преимуществом пересоздания песочницы выступает стабильность получаемых результатов. К недостаткам относится медленный запуск и перерасход ресурсов. На пересоздание песочницы уходят десятки секунд или даже минут, следовательно, большая часть ресурсов будет тратиться именно на это. Существует множество техник ускорения пересоздания, благодаря которым можно сократить время запуска. Прежде всего, сюда можно отнести backup/restore (snapshot песочницы, базы данных и т.п.). Также если поток задач небольшой и ресурсы позволяют, можно попробовать организовать пул песочниц и создавать их заранее.

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

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

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

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

Например, шаги установки и настройки ПО; шаги CI/CD-конвейера; рендеринг изображения на GPU; интенсивные вычисления. Все эти задачи, скорее всего, придётся исполнять последовательно.

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

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

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

Управление песочницами

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

Оркестрация

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

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

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

• Отслеживание доступности песочниц. Поскольку хотелось бы, чтобы количество песочниц менялось в зависимости от нагрузки на систему, придётся отслеживать их доступность. Это прямая обязанность оператора песочниц, которую можно выделить в отдельный discovery-сервис (например, на базе Netflix Eureka), либо реализовать как часть приложения с использованием инфраструктурных механизмов (например, Kubernetes API). Важно отметить, что оператор песочниц не имеет отношения к бизнес-логике приложения.

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

• Неопределённость результата, если нет ответа от песочницы. Песочница может быть недоступна по различным причинам, включая не только проблемы с сетью, но и падения песочницы из-за ненадёжного кода. К сожалению, в общем случае эта проблема не имеет решения, так как делать повторные запуски (retries) может быть опасно. Всё, что остаётся, это использовать таймауты и откладывать неуспешную задачу на потом.

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

Для отслеживания нагрузки на песочницы экземпляр приложения ориентируется на количество задач в каждой из доступных песочниц. Предположим, что было принято решение увеличить количество экземпляров приложения. Этот экземпляр исполняет 5 задач в двух песочницах (3 процесса в одной и 2 в другой). Известно, что каждая песочница может вынести максимум 4 параллельных задачи.

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

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

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

• Для контроля количества исполняемых задач в песочнице использовать распределённый счётчик (например, на базе Redis). Проблема в том, что распределённый счётчик имеет латентность и на момент запуска задач может выдать устаревшее значение. Кроме того, в системе появляется еще один инфраструктурный компонент, который не несёт бизнес-пользы.

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

Кстати, после доклада на TechLeadConf 2025 мне задали интересный вопрос: Можно ли при балансировке нагрузки на песочницы учитывать не только количество исполняемых задач, но и процент загрузки CPU, памяти и прочих ресурсов? Если у кого-то возник такой же вопрос, то отвечу, что это не имеет смысла, поскольку ситуация в песочнице может поменяться мгновенно. Полученный практический опыт и нагрузочное тестирование показали, что простой подсчёт задач работает эффективно.

Самоорганизация

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

Ключевой момент в архитектуре — это появление двух очередей: очередь задач на исполнение (Task Queue) и очередь результата их исполнения (Result Queue). Все поступающие задачи приложение направляет в первую очередь, а результаты — во вторую. Дополнительно появляется роль агента — микросервиса, который исполняется в рамках узла песочницы и координирует исполнение поступающих задач.

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

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

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

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

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

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

Запуск процесса ОС

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

• Как ограничить права доступа к ресурсам. Самое простое решение — запуск процесса от имени пользователя с ограниченными правами (на доступ к ресурсам ОС).

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

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

Рассмотрим варианты ограничения ресурсов процесса ОС.

Ограничение ресурсов процесса

Ресурсы процесса могут быть ограничены на трех уровнях:

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

• Лимиты контейнера. Программные лимиты, задаваемые выбранным инструментом контейнеризации (cgroup, Docker, Bubblewrap, ProcessSandbox и т.п.).

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

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

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

Например, для использования cgroup или Docker внутри Kubernetes-контейнера нужно эскалировать привилегии контейнера, что в общем случае небезопасно в контексте исполнения ненадёжного кода. Более того, практика показала, что легковесных rootless-средств, предоставляемых ОС, вполне достаточно, чтобы снять большую часть рисков. В частности, Linux API позволяет не только лимитировать CPU и память, но и блокировать доступ к некоторым возможностям самой ОС. Например, можно наложить фильтр, который запретит вызов определённых системных функций.

Проблемы жёсткого лимитирования

Рассмотренные выше способы лимитирования задают жёсткие границы (hard limit), нарушение которых замедляет исполнение процесса, либо приводит к его принудительному завершению. При этом поведение наблюдаемого процесса и системы сильно варьируется в зависимости от того, какой лимит был превышен. Например, превышение по использованию CPU может привести к троттлингу (throttling), приостановке работы или принудительному завершению; превышение по использованию памяти заканчивается принудительным завершением со стороны ОС (OOM Killer) либо самостоятельным падением процесса (с ошибкой Out Of Memory).

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

Такой подход имеет несколько преимуществ.

• Точное определение причин принудительного завершения. Жёсткие лимиты чуть выше мягких, благодаря чему для исполняемого кода создаётся иллюзия отсутствия каких-либо лимитов. Между тем, если лимиты всё-таки нарушаются, процесс всё равно будет завершен (либо со стороны приложения, либо гарантированно со стороны ОС). Но подобный дополнительный контроль со стороны приложения оставляет для него гораздо больше шансов понять причину принудительного завершения наблюдаемого процесса.

• Возможность гибкого лимитирования ресурсов. Приложение (или агент), ответственное за запуск наблюдаемого процесса, может обратиться к средствам ОС (в частности, к Linux API) и гибко настроить параметры запуска и исполнения. Как минимум, жёстко определить лимиты по CPU и памяти; наложить ограничения на объем I/O; создать запрет на вызов некоторых системных функций (например, запрет использования сетевых операций или файловой системы) и т.п.

Такой подход я назвал watchdog и в целях иллюстрации реализовал его в виде .NET-библиотеки ProcessSandbox. Помимо прочего, на странице проекта подробно рассмотрена проблематика контроля и анализа поведения процесса ОС со стороны прикладного кода.

Итоговая схема лимитирования может выглядеть так, как показано на рисунке ниже. Вместо тяжеловесных инструментов контейнеризации используется легковесный rootless-инструмент (watchdog) на базе средств ОС и только.

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

Многоконтейнерные поды

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

Несмотря на всю заманчивость данной идеи, она несёт ряд недостатков.

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

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

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

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

Образ для песочницы

Основные моменты, которые следует учесть при создании (Docker) образов песочниц:

• Заменить init-процесс на tini, чтобы не превысить лимит по PIDs.

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

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

Инфраструктура исполнения

Основные моменты, которые следует учесть при настройке инфраструктуры исполнения:

• Обеспечить быстрый (пере)запуск песочниц. Нужно быть готовым к тому, что песочницы будут падать. Если речь идет о Kubernetes, то улучшить время запуска может подходящая настройка Image Pull Policy. При этом лучше не использовать тег `latest`, а указывать конкретную версию или хэш-код образа, чтобы не тратить время на попытки определения последней версии при каждом запуске.

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

• Установить лимиты на ресурсы узла. В Kubernetes для каждого контейнера нужно указать, как минимум, лимиты по CPU и памяти. Значения лимитов лучше всего определить в ходе нагрузочного тестирования или путём сбора метрик приложения.

Заключение

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

Я постарался показать последовательность шагов по направлению к целевой архитектуре, которая будет отвечать требованиям бизнеса и справляться с ненадёжным кодом. Если вам интересна данная тематика, подписывайтесь на мой Telegram-канал Архитектоника в ИТ (@arch_and_dev). Буду рад поделиться опытом.

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

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

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

Что же он умеет и чем полезен?

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

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

Долго кодили? Какие технологии использовали? Какой хостинг выбрали? Как собираетесь раскручивать?

Разработка первой версии заняла около 2х недель, большая часть которых, как и полагается, ушла на игру в Risen и распитие пива. По большей части у нас всё стандартно: PHP на бекенде, немного JS и Bootstrap на фронтенде. В качестве библиотеки для рендеринга графиков было решено выбрать flot.js — она, конечно, старая, но имеет большое комьюнити, много плагинов, функций и поддержку ишака старых браузеров.

В качестве хостинга решено было выбрать Rixis Cloud Hosting из-за его дешевизны (от 15 рублей в месяц), производительности и, самое главное, отзывчивой технической поддержки, которая всегда идет навстречу.

Из-за активной фазы разработки до серьезной раскрутки руки пока не дошли, но паблик SMMщики  c удовольствием бесплатно разместил о нас несколько публикаций, что дало нам первых пользователей.

Я не администратор сообщества, мне не нужны все эти ваши модные штуки и паблики ВКонтакте, мне не интересен ваш сервис. Что мне делать?