Без маркетинга и успешного успеха. Только боль, костыли и суровый прод! Мой пет-проект - бот «Щёлк-ГДЗ». Это ИИ-помощник, который решает школьные задачки по фоткам, видео, гс, тг-кружкам и PDF. Под капотом Python 3.12.3, aiogram 3, aiosqlite, апи OpenRouter (модель Gemini 3.0 Flash) и Робокасса. Крутится всё это на дешёвом VPS в Нидерландах. Держит 2500+ пользователей и не падает.

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

Нейронка вместо джуна и Уроборос багов

Сразу признаюсь... С нуля я это не писал :) Синтаксис мне генерили LLM-ки. Начинал с Gemini 2.5 Pro, затем перешел на 3.0 Pro, а сейчас использую 3.1 Pro.

Многие думают, что нейронка сама напишет проект "под ключ", но это миф. Я никогда не доверял ИИ проектирование архитектуры и использовал его как продвинутый StackOverflow (скармливал конкретную задачу (например, написать SQL-миграцию) и получал кусок кода).

ИИ — это не архитектор, а джун на спидах.

Как только логика усложнялась - гемини ловил «Уроборос багов». Кидаешь баг А - он его фиксит, но появляется ошибка Б. Скармливаешь и её - фиксит, но возвращается баг А. Цикл замкнулся. Лечилось только созданием новых чатов, в которые я кидал код и писал запросы типа "Найди критические ошибки, логические дыры и баги".

Про продуктовую логику нейронка вообще не слышала. В первой версии рефералки был баг, где любой(если его аккаунта ещё нет в БД) мог написать в конце ссылки что любые 9 цифр (?start=1234567890) и получить бонусы.

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

Немного про архитектуру.

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

main.py - это точка входа с настройкой логгеров, коннетами aiohttp и запуском APScheduler

database.py - вся работа с БД

neiro.py - логика общения с апи OpenRouter (стриминг, сжатие фоток через Pillow, JSON-контекст)

states.py - классы состояний aiogram.fsm.state (например, PaymentProcess, GdzMode)

utils.py - легковесные утилиты. Например лок пользователей (защита от спама запросами):

Хэндлеры вынесены в отдельную папку handlers/:

handlers/common_handlers.py - главное меню с обработкой /start (рефералки, utm-метки).

handlers/gdz_handlers.py - сам процесс ИИ-решения (вход в GdzMode, прием фото, видео, кружочков).

handlers/pay_handlers.py - это логика платежей (Robokassa) и "Умная корзина".

handlers/tasks_handlers.py - квесты (выдача премиума за подписку на каналы спонсоров).

Сборку интерфейсов вынес в all_def.py. Не люблю, когда в хэндлерах генерится полотно текста с кнопками. Там же лежат функции склонения слов (1 запрос, 2 запроса, 5 запросов). А в settings.py лежат списки с рандомными ответами бота, чтоб казался живым.

Так же в settings.py я сделал кэширование картинок, тоесть при первом запуске бот грузит фото меню как BufferedInputFile, сохраняет file_id от Телеграма и дальше шлет картинки моментально по ID. Сервак говорит спасибо за сэкономленный трафик)

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

Диета по токенам

Хранить бесконечную историю диалогов дорого и бессмысленно. В бесплатной версии храню 10 последних сообщений (5 пар вопрос-ответ), а в преме — 30.

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

Старые фотки тупо вырезаю из JSON. Подменяю на системный промпт:

С довольно неплохой моделью (gemini 3.0 flash) это работает как часы (она честно признается, что забыла картинку, а не выдумывает что-то из воздуха).

Стриминг, FloodWait и защита баланса

Чтобы бот не выглядел тормозом, я сделал стриминг ответа от ИИ в neiro.py. Я обновляю сообщение в Телеграме чанками по мере получения их от ОпенРоутера.

Но если делать message.edit_text слишком часто, ловишь FloodWait. В итоге я выставил интервал в 0.7 секунд и обернул всё в жесткий try/except:

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

В handlers/gdz_handlers.py это выглядит так:

SQLite тащит

Почему не Postgre? Потому что для микро-SaaS с 2,5к пользователей SQLite хватает за глаза. Но в асинхронной среде она любит кидать ошибку database is locked.

Чтобы этого избежать, я включил WAL-режим при инициализации пула, разделил коннекты на db_writer и db_reader, а сложные операции доверил самому SQL.

Например, 00:00 запускается крон-таска, которая собирает огромную аналитику, начисляет всем активным юзерам +1 ежедневный запрос и сбрасывает просроченные подписки. И это всё это работает атомарно внутри database.py:

Умная корзина на APScheduler

Когда дело дошло до монетизации, всплыли две проблемы:

Первая: юзер оплатил, но забыл нажать кнопку «✅ Я оплатил» в боте. Бот ждет, юзер ждет, товар не выдается, поддержка кипит.

Вторая: юзер сформировал счёт и передумал ("брошенная корзина").

Вместе с LLM я с нуля изучил apscheduler и убил двух зайцев фоновыми задачами. Теперь в handlers/pay_handlers.py при генерации ссылки на оплату я создаю две отложенные таски:

Как это работает?

Через 5 минут срабатывает async def auto_check_payment(), которая тихо стучится в робокассу. Если статус success - бот сам начисляет запросы на баланс и радует клиента. Если статус pending - таска умирает, и в дело вступает 30-минутная таска.

Но она не шлёт спам вслепую, а лезит в БД и проверяет 3 бизнес-правила:

1. await db.has_successful_payment_recently - Не купил ли он другой товар за последние 3 часа?

2. await db.get_latest_invoice_id - А это точно самый последний сгенерированный им счет?

3. await db.can_send_agitation - Не присылали ли мы ему агитацию недавно?

Если проверки пройдены, то юзер получает сообщение: "⏳ Домашка сама себя не решит! Ты начал оформлять покупку, но оплата так и не прошла...". Это поднимает конверсию оплат.

Финал

Почему я не использую Redis для стейтов? Ответ банален: мой дешевый VPS имеет всего 1 гб оперативки. Пул aiohttp, In-Memory стейты и асинхронные таски и так жрут 70% RAM. Редис тупо не влезет.

Как говорится, работает — не трогай.

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

Готов ответить на вопросы по архитектуре и послушать советы в комментариях \(^^)/

P.s. вот ссылка на первую статью о моём проекте:

P.s. Если кто-то хочет потестить вживую(не реклама), то юз бота в тг @gdzshchelk_bot

Всё началось с безобидного, почти рутинного тикета в саппорт:

«У меня тут несколько одинаковых карт создалось. Я вроде один раз нажимал, а их штук пять висит в приложении».

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

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

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

Мы начали разбираться. Стандартный мониторинг показывал норму: дашборды зелёные, в логах тихо, метрики CPU и памяти без отклонений. При этом в базе обнаруживались дубликаты, которых быть не должно. И только тогда, когда мы внимательно посмотрели на коммунальный API Gateway, то поняли что одно изменение от другой команды поменяло идемпотентность работы endpoint-а.

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

Что произошло: хронология инцидента

Архитектура была классической: Клиент → API Gateway → микросервисы,.

Сценарий развивался почти незаметно для стандартных средств наблюдения:

1. Фронтенд: Пользователь нажимает кнопку «Выпустить карту».

2. Gateway: Запрос начинает обрабатываться в API Gateway.

3. Микросервис по созданию карт: честно выполняет работу: создаёт запись в БД и возвращает `200 OK` в Gateway.

4. Новый микросервис: API Gateway вызывает новый микросервис и получает HTTP 500 в ответ от него. Исключение возникает уже после успешного вызова нашего микросервиса, и это ключевая точка разрыва: Gateway считает весь запрос неудавшимся, а ответ нашего микросервиса теряется.

5. Клиент: получает HTTP 500

6. Реакция: Пользователь видит красную плашку ошибки и логично решает: «Не сработало, пробую снова». Более того, с точки зрения протокола HTTP - запросы, в ответ на которые пришла ошибка HTTP 500, можно пытаться отправлять опять.

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

Круг замкнулся. Эпидемия началась.

В компании такого уровня это не было предусмотрено. И это такая обидная ошибка.

Как так получилось?

Вскрылось ошибочное предположение:

«В API Gateway вызов микросервиса создания карт всегда идет последним».

Таким образом идемпотентность достигалась «формально» - ведь если создание карты завершалось с ошибкой - это точно означало что и вызов API Gateway тоже завершится с ошибкой. Сработало ложное чувство безопасности.

Ответ на вопрос “почему так было сделано?” очень простой - это было осознанное упрощение на старте. Все знали об этом, но задача на фикс потерялась в недрах бэклога на очень долгое время. Это классический пример того, как архитектурное допущение и отложенный рефакторинг годами живут в проде, пока их не вскрывает редкая последовательность отказов.-

Что потребовалось изменить

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

FAQ: Часто задаваемые вопросы

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

Блокировка кнопки решает проблему только при стабильной сети. Если запрос ушёл, сервер создал сущность, но ответ потерялся — кнопка разблокируется по таймауту, и пользователь нажмёт снова. Это не устраняет корневую причину, а лишь слегка снижает вероятность дубля.

2. Чем идемпотентность отличается от дедупликации в БД?

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

3. Как долго хранить ключи идемпотентности?

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

4. Что делать со старыми клиентами, которые не шлют request_id?

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

5. Обязательно ли делать идемпотентность для всех методов API?

Идемпотентность требуется только для методов, которые изменяют состояние системы — POST, PUT, PATCH и иногда DELETE. Методы чтения (GET, HEAD, OPTIONS) не изменяют данные, поэтому считаются идемпотентными по умолчанию.

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

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

Если метрик ещё нет, вот три косвенных признака, которые помогут заподозрить неладное:

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

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

Итог

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

Метрик на всплески повторных запросов у нас не было. А зря — это самый дешёвый способ увидеть проблему до того, как она обрушит продакшен. Системы, спроектированные на 10% нагрузки, ломаются на 60% — и обычно это становится неожиданностью для команды.

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

• Убедитесь, что все критические мутирующие эндпоинты поддерживают ключ идемпотентности.
• Настройте алерты на аномальное количество запросов на создание сущностей от одного пользователя за короткий промежуток времени.
• Проверьте, как ваш API Gateway обрабатывает ошибки — не теряет ли он ответы downstream-сервисов.
• Убедитесь, что фронтенд корректно обрабатывает не только 200, но и 500, 502, 504, не провоцируя пользователя на повторные клики без необходимости.

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

Как устроен InferSim

В основе симулятора — двухфазная схема. Сначала на целевом железе запускаются микро-бенчмарки: измеряется реальная производительность на типовых операциях внимания и матричных умножениях. Получается таблица коэффициентов Model FLOPs Utilization (MFU) — сколько процентов от теоретического максимума выдаёт конкретная карта на конкретной операции. Затем, уже без доступа к GPU, симулятор на основе этих MFU и аналитической модели вычисляет задержки. Именно такой подход даёт более точные предсказания, чем оценка по паспортной пропускной способности памяти.

Добавляем своё железо

Первым делом мы внесли в hardware/gpu.py поддержку MetaX C500 64GB. Характеристики добавляются через dataclass-экземпляры:

После этого c500 попадает в словарь gpu_map, и симулятор запускается с ключом --device-type C500 --world-size 2. Значения FLOPS и пропускной способности пришлось оценивать по косвенным источникам — производитель не публикует точных цифр. Позже планируем уточнить их через бенчмаркинг на реальном оборудовании. Таким же способом добавили Nvidia 1xH100 и A100.

Конфигурация моделей и одна болезненная ошибка

Симулятор ожидает стандартный config.json в формате Hugging Face. Для Qwen3-32B подготовили файл qwen3_32b_config.json:

Ключевой момент — правильное значение head_dim. У Qwen3-32B оно равно hidden_size / num_attention_heads = 5120 / 64 = 80. У нас ушло некоторое время, чтобы понять, почему симулятор выдаёт невалидные результаты: изначально в конфиге стояло значение 128. Пока не исправили — KV-кеш переоценивался, и метрики улетали в неадекватные цифры. После исправления всё встало на свои места.

Позже добавили поддержку Qwen3.5‑9B с её гибридной архитектурой, построенной на чередовании Gated DeltaNet и Gated Attention. Главная особенность модели в том, что около трёх четвертей слоёв не создают привычного KV‑кеша, а используют линейное внимание – компактное скрытое состояние, которое лишь обновляется с каждым новым токеном, не увеличиваясь в объёме. Это кардинально снижает расход памяти на длинных контекстах, но привносит и свою цену: на коротких дистанциях такая модель проигрывает в скорости Prefill, потому что Gated DeltaNet работает последовательно и хуже утилизирует матричные вычисления GPU.

Симулятор изначально не умел различать слои двух типов и считал весь KV‑кеш одинаково. Чтобы поддержать Qwen3.5, пришлось доработать расчёт задержек в классе HybridModel: теперь он отдельно обсчитывает full‑attention‑слои с полным кешем и linear‑attention‑слои без кеша, используя параметры num_full_attn_layers и num_linear_attn_layers из конфигурации. В директорию проекта models добавили hybrid_model.py, в котором сделали дополнительные расчёты:

Без такой дифференциации симулятор для Qwen3.5‑9B показывал E2E порядка 2 500 секунд вместо реальных нескольких секунд – та ошибка, которую мы долго отлавливали.

Визуализация и эксплуатация

Чтобы не разбирать каждый раз текстовый вывод InferSim, сделали веб-интерфейс на Streamlit. Симулятор дёргается через subprocess, результаты парсятся из stdout и визуализируются:

• тепловые карты задержек (Prefill, Decode, E2E Total) для разных длин входных и выходных токенов;
• анализ RPS с расчётом требуемой параллельности и сравнением с доступной памятью;
• информация о занятой памяти в формате «X ГБ из Y ГБ».

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

Приложение упаковано в Docker и лежит в репозитории на GitHub. Сервисы — сам Streamlit и Nginx в качестве обратного прокси с SSL-терминацией и базовой HTTP-аутентификацией. Деплой на VDS автоматизирован через GitHub Actions: собрали образ, отправили на сервер, перезапустили контейнеры. SSL-сертификаты Let's Encrypt обновляются по cron.

Что в итоге

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

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

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

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

Как они устроены и почему у них нет «ног»

Физическую часть роботов разработала команда Penn Engineering. Размер каждого устройства — примерно 200 × 300 × 50 микрометров.

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

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

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

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

Питание от света и микроскопическая электроника

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

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

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

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

Зачем нужны такие микророботы

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

Все это — на чипе с 3 КБ оперативной и 24 КБ флеш-памяти, без сетевого интерфейса, Wi-Fi или Ethernet.

Откуда там вообще чип?

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

Вместо обычного черного эпоксидного «блоба» он обнаружил маркированный микроконтроллер PUYA C642F15, позже идентифицированный как PY32F002B с ARM Cortex-M0+ частотой 24 МГц.

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

Как он вывел это в сеть?

Wi-Fi, Ethernet или даже Bluetooth в таких устройствах, разумеется, нет. Но автор воспользовался семихостингом — механизмом отладки, при котором отладчик может отправлять и принимать данные через подключенный JTAG/SWD интерфейс.

Далее он применил довольно хакерское решение: использовал pyOCD для создания telnet-порта с выходом семихостинга, затем через socat пробросил это в виртуальное TTY-устройство, поверх него поднял SLIP (Serial Line Internet Protocol). Да, тот самый, из эпохи dial-up.

После этого на Linux можно было поднять IP-интерфейс sl0 и назначить IP-адрес — теперь микроконтроллер был виден как узел локальной сети.

А веб-сервер?

В качестве TCP/IP-стека был выбран uIP — крайне легкий вариант от Contiki OS, специально рассчитанный на 8- и 16-битные микроконтроллеры.

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

Причем не просто «заработало», а заработало удивительно быстро: после оптимизации буферов и избавления от побайтной передачи, RTT упали до 20 мс, а загрузка страницы — до 160 мс.

Несмотря на сверхограниченные ресурсы (всего 3 КБ RAM, из которых почти половина уже занята сервером), автор сумел:

• организовать буферизацию и кольцевой буфер;
• запустить TCP/IP-стек и веб-сервер;
• реализовать подсчет посещений и возврат JSON-ответов;
• полностью уместить все в оставшиеся ~20КБ флеша.

Он даже добавил простую статистику: уникальный ID микроконтроллера и количество посещений со времени последнего «краша».

Зачем это все?

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

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

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

Пример Spotify, каждый раздел — это отдельные автономные приложения, склеенные в одном клиентском интерфейсе.

Рассмотрим такой подход с позиции менеджмента и разработки.

Разработка веб-приложения

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

Проект придётся сшивать из отдельных частей

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

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

В проекте можно будет экспериментировать

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

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

Проект будет сложнее деплоить

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

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

Как применять в проекте

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

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

Webpack Module Federation

Module Federation — механизм, встроенный в Webpack 5, который позволяет одному фронтенду (host) динамически загружать модули из другого фронтенда (remote) во время выполнения. Это мощный инструмент для интеграции микрофронтендов: он поддерживает разделение кода, кэширование, совместное использование зависимостей (например, React или Vue) и независимую доставку каждого модуля. Module Federation работает без необходимости использовать iframe или перекомпиляции.

Инструкция по использованию

Менеджмент

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

Один проект превращается во множество

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

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

Команды будут независимы друг от друга

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

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

Команды получают поле для удачных и не очень экспериментов

Команды могут внедрять новые технологии, не дожидаясь переписывания всего приложения: один микрофронтенд можно сделать на React, другой — на Vue или Svelte. Это даёт гибкость в найме, миграциях и экспериментах. Но чем больше технологий используется, тем сложнее следить за их использованием и труднее помнить их особенности.

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

Появляются FrontOps

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

Вывод

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

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня» отмечает, что микрофронты — не всегда удачное решение:

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

Делитесь своим опытом работы с микрофронтендами в комментариях и не забывайте сохранять наши статьи!

Сегодня их рекомендательная система экономит более $1 млрд в год, удерживая подписчиков и увеличивая время просмотра. И именно ее решил изучить разработчик на платформе BeyondIT.

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

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

Сердце системы — матричная факторизация

Ключевая технология, популяризованная ещё во времена конкурса Netflix Prize в 2006 году — матричная факторизация.

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

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

Больше, чем просто «похожие на вас»

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

Интерфейс и обложки фильмов постоянно проходят A/B-тесты, чтобы максимизировать вовлечённость.

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

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

Реакция в реальном времени

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

Инфраструктура включает Kafka, Spark, микросервисы в AWS, кэширование в памяти и edge-вычисления для минимальной задержки.

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

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

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

P.s. Это перевод зарубежной статьи. Предлагаем подискутировать о вопросе в комментариях.

Как выгорание подкрадывается к разработчикам

Через несколько месяцев после того, как вы почувствуете усталость, console.log() начнет казаться непосильной задачей, а баг, который обычно исправлялся за час, ломает изнутри.

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

И статистика это подтверждает: по данным Stack Overflow, 32% разработчиков несчастны на работе, а еще 47% выживают на автомате, не чувствуя вовлеченности. Это значит, что почти 80% специалистов находятся в зоне риска эмоционального выгорания, хотя снаружи всё выглядит стабильно.

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

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

Пятиминутная привычка, которая меняет всё

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

Формула успеха звучит так: Минимальные усилия → Последовательность → Идентичность → Восстановление связи. Начав с малого, можно постепенно вернуть уверенность и интерес к профессии.

Как работает эта практика:

1. Выберите простое действие: например, написать одну функцию или изучить один метод в документации.
2. Установите таймер на 5 минут: это снижает порог входа и делает задачу необременительной.
3. Делайте это каждый день: даже если результат минимален, регулярность формирует привычку.
4. Не ждите вдохновения: действие само по себе создает мотивацию.

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

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

Как вернуться к программированию и не выгореть снова

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

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

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

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

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

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

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

• Книги: «Атомные привычки» Джеймса Клира для понимания силы маленьких шагов.
• Курсы: платформы вроде Codecademy или freeCodeCamp для легкого возвращения к основам.
• Сообщества: нишевые Discord-серверы (например, по Python или Rust) или Reddit (r/learnprogramming).
• Трекеры привычек: приложения вроде Habitica для отслеживания прогресса.

Вместо итогов

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

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

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

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

Бонус от экспертов: как пережить выгорание и вернуться к работе

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

Елизавета Якушева, тестировщик, автор тг-канала Press F to Debug:

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

Елизавета выделяет два разных типа выгорания:

1. От самой работы — стресс, рутина, груз ответственности.
2. От постоянной учёбы и самосовершенствования — давление трендов, ощущение собственной «недостаточности», переизбыток бесполезной информации.

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

Чтобы справиться, она предлагает задать себе простой, но важный вопрос:

«Зачем я это делаю? Что будет, если я перестану?»

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

Стресс от груза ответственности решается простой мыслью: "Я здесь, чтобы выполнять работу так, как могу. Если я не успеваю что-то сделать вовремя, я умираю, у меня температура под 40, у меня отвалилась нога — вселенная не остановится, если ты возьмёшь тайм-аут в виде отпуска или day-off. Ракета не полетит в космос, и никто глобально не умрёт."

Для пет-проектов помогает осознанность: понимание, зачем ты вообще этим занимаешься.

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

Анастасия Егорова, фронтенд-разработчик, автор канала «Код и кофе»:

Анастасия комментирует технику «5-минутных привычек», описанную в оригинальной статье, и делится, как адаптировала её под свой сложный ритм:

У меня был период жизни, когда я полтора года работала на двух фуллтайм-работах… Иногда, просыпаясь зимним утром в 6:45, чтобы выйти на удалённый созвон в 7:00, я думала, что больше всего хочу уволиться со второй работы. Но нужно было работать.

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

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

Да, бывают и провальные дни — но даже тогда, по её словам, важно просто не бросить всё совсем.

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

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

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

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

Причины массового игнорирования: системные ловушки

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

Большой объем и языковой барьер

Современные соглашения напоминают юридические трактаты. Средний документ российских сервисов содержит 16,800 слов. Роскомнадзор критикует избыточность текстов, но не публикует официальной статистики. Например, документация Ozon занимает 23,700 слов — это больше, чем повесть Чехова «Дуэль» (13,700 слов). Политика Яндекс.Диска занимает 57 страниц, а условия СберБанк Онлайн — 43 страницы.

Главная проблема — язык. Юридические термины вроде «сублицензирование», «деперсонализация данных» или «арбитражная оговорка» требуют специальных знаний. Как показывает практика судебных споров и жалоб в Роскомнадзор, такие формулировки часто непонятны рядовым пользователям. Барьер усугубляется тем, что юридическая грамотность в РФ остается низкой: далеко не все россияне уверенно читают договоры.

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

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

UX-дизайн, провоцирующий спешку

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

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

Такие паттерны усиливают «эффект туннельного зрения» — психологический феномен, при котором пользователь фокусируется на цели (быстром доступе к сервису), игнорируя второстепенные элементы. Дизайнеры дополнительно стимулируют это: например, используют таймеры обратного отсчета («Осталось 00:59»), чем создают искусственную спешку. Сообщения типа «99% пользователей уже приняли условия» формируют социальное давление.

Мнимый выбор в условиях монополий

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

Почему выбор остаётся мнимым? Попробуйте использовать СберБанк Онлайн без принятия политики обработки данных. Система выдаст ошибку: «Для продолжения необходимо согласиться с условиями». Аналогично в VK: отказ от соглашения означает потерю доступа к сообщениям и группам.

Мнимый выбор — это не всегда подвох со стороны сервиса. Даже по новым европейским правилам (Digital Services Act) платформы должны давать вам «базовую версию» без персонализированной рекламы, но не обязаны работать вообще без сбора данных.

В России всё устроено схоже: если без ваших персональных данных сервис просто не сможет функционировать (например, банк или мессенджер), отказ в доступе — это не нарушение закона.

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

Евросоюз в 2024 году ввел Digital Services Act, обязывающий платформы предлагать базовую версию без сбора данных. В России аналогичные нормы в законе «О персональных данных» (152-ФЗ) начали работать только с 2025 года. У пользователя есть право отозвать согласие на обработку данных, но не все сервисы готовы сохранять функционал после отказа.

Что скрывают соглашения: реалии цифрового мира

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

Расширенный сбор данных под видом «аналитики»

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

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

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

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

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

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

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

Умные колонки с голосовыми помощниками (такие как «Яндекс.Станция» или устройства Sber) постоянно анализируют звуковое окружение для активации по ключевым словам, что создает риск случайной записи приватных разговоров.

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

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

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

Исследования подтверждают:

• Ложные срабатывания. Ассистенты активируются до 19 раз в сутки из-за фоновой речи, слов-омофонов или аудиоконтента (например, при просмотре сериалов).
• Технические уязвимости. Ученые обнаружили, что MEMS-микрофоны в таких устройствах излучают радиосигналы, которые можно перехватить FM-приемником даже через бетонные стены.
• Хранение данных. Записи голосовых команд сохраняются на серверах производителей неограниченное время. В 2019 году сотрудники Amazon признались в прослушке аудио с Echo без ведома пользователей.

Как минимизировать угрозы:

1. Отключайте микрофоны колонок физической кнопкой (если есть) при обсуждении конфиденциальных тем.
2. Откажитесь в настройках от «персонализированных ответов» и отправки аудиоданных для «улучшения сервиса».
3. Регулярно удаляйте историю запросов через приложение-компаньон (например, «Дом с Алисой»).

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

Передача прав на контент

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

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

Автоматическое продление подписок

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

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

Особую опасность представляют детские приложения, где случайные покупки происходят из-за неочевидного интерфейса. В 2024 году Федеральная торговая комиссия США (FTC) оштрафовала Epic Games (американскую компанию по разработке игр и ПО) в общей сложности на $520 млн за сложную процедуру отмены несанкционированных платежей в Fortnite (кроссплатформенной формально бесплатной игре).

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

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

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

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

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

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

Как защитить себя: стратегии для 2025 года

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

Для пользователей: цифровая гигиена

Проверяйте репутацию сервиса перед согласием

Роскомнадзор ведёт открытый реестр нарушителей закона 152-ФЗ. Например, каршеринг «Делимобиль» был внесен в список после массовой утечки номеров телефонов.

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

Жёстко контролируйте разрешения

Современные ОС предлагают инструменты для защиты:

• в Android 14 функция «Одноразовый доступ» ограничивает работу камеры/микрофона одним сеансом;
• в iOS 18 «Детальный контроль» позволяет блокировать фоновый сбор данных.

Для браузеров установите uBlock Origin — расширение блокирует скрытые трекеры, упомянутые в политиках конфиденциальности. В соцсетях отключайте «аналитику поведения» в настройках приватности — это снижает объем собираемой информации.

Требуйте отчёт о ваших данных

Статья 14 закона 152-ФЗ гарантирует право запросить у компании:

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

В случае отказа или неполного ответа подавайте жалобу через портал Роскомнадзора.

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

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

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

Сокращайте и визуализируйте соглашения

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

Внедряйте градацию согласия

Разделите запросы на данные по категориям:

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

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

Добавьте «режим адвоката»

Встройте в интерфейс кнопку «Главные риски за 60 секунд»: краткую выжимку ключевых положений. Сервис ProtonMail делает это эффективно — на странице регистрации четко указано: «Мы не храним IP-адреса и не передаём данные третьим лицам».

Будущее соглашений: нейросети и законодательство

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

ИИ-ассистенты: возможности и ограничения

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

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

Основные проблемы:

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

Законодательные изменения: новые требования

В июне 2024 года принят Федеральный закон № 123-ФЗ, вносящий поправки в 152-ФЗ.

Ключевые новации:

• запрет автоматического продления платных подписок без отдельного подтверждения через SMS или email (ст. 15.4);
• обязательное выделение условий сбора биометрических данных жирным шрифтом;
• штрафы до 3% годового оборота за сокрытие практик передачи данных третьим лицам.

Новые требования уже дают результаты.

Перспективы: стандартизация и блокчейн

ЕС разрабатывает AI Act — единый стандарт для ИИ-анализа соглашений. Эксперименты с блокчейн-реестрами условий проводят Сбербанк и Тинькофф: технология фиксирует версии документов и предотвращает скрытые изменения.

Заключение: ваша цифровая подпись — это ответственность

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

Что делать сегодня? Начните с малого. Даже беглый просмотр разделов «Данные» и «Автоматическое продление» снижает риски. Не забывайте о законе 152-ФЗ. Если это необходимо, требуйте от компаний полный отчёт о ваших данных через форму на портале Роскомнадзора.

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

Первые Wi-Fi роутеры только начинали появляться на рынке, стоили дорого и требовали сложной настройки. Их антенны выглядели как нечто футуристическое, а радиус действия оставлял желать лучшего — сигнал часто не мог пробиться через одну-две стены. Сегодня, в 2025 году, ситуация кардинально изменилась. Беспроводные технологии 4-5G и mesh-сети превратили интернет в нечто невидимое, но повсеместное, как воздух.

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

LAN 2003: эпоха проводов и первых беспроводных решений

Начало 2000-х годов было временем, когда интернет в России становился массовым явлением, но оставался преимущественно проводным. Локальные вычислительные сети (LAN) продолжали активно развиваться, предоставляя возможность объединять компьютеры и другие устройства в пределах одного здания или офиса для обмена данными и совместного использования ресурсов.

В основе этих сетей лежала технология Ethernet, которая обеспечивала пропускную способность до 100 Мбит/с в наиболее распространенном варианте Fast Ethernet, а в продвинутых решениях — до 1000 Мбит/с (Gigabit Ethernet).

Для корпоративного сектора LAN играли ключевую роль в инфраструктуре предприятий, образуя основу для работы бизнес-приложений и обмена данными между сотрудниками. Активно использовались сетевые коммутаторы (switches), которые эффективно разделяли трафик и повышали производительность сети по сравнению с устаревшими концентраторами (hubs). Развитие Gigabit Ethernet и других сетевых технологий позволяло удовлетворить растущие потребности бизнеса в скорости передачи данных.

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

Wi-Fi был редкой и дорогой опцией — первые роутеры вроде D-Link DI-604 стоили от $100 (что по курсу того времени составляло около 3000 рублей — немалые деньги для среднестатистического гражданина) и требовали сложной настройки через Internet Explorer.

Вопросы безопасности в те годы решались просто – точнее, почти никак. WEP-шифрование, использовавшееся в ранних стандартах Wi-Fi (802.11b/g), взламывалось за считанные минуты специальными программами, которые легко можно было найти в интернете. Многие пользователи вообще не заморачивались с паролями, оставляя свои сети открытыми, что приводило к частым случаям «халявного» использования соседского интернета.

Скорости передачи данных, которые сегодня кажутся смешными, тогда воспринимались как нечто революционное. Даже в продвинутых офисах гигабитные порты (1 Гбит/с) были редкостью. Загрузка фильма в HD-качестве (4–5 ГБ) могла занимать несколько часов, а о потоковом вещании в современном понимании и речи не шло.

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

Пример: Согласно исследованию аналитической компании J’son & Partners за 2005 год, в Москве только 12% домохозяйств имели широкополосный доступ в интернет, а публичные точки Wi-Fi можно было пересчитать по пальцам. В основном они располагались в дорогих отелях и нескольких продвинутых кафе в центре города.

Революция Wi-Fi и появление мобильного интернета

К 2010-м годам ситуация начала кардинально меняться. Технология Wi-Fi, получившая новый импульс развития с появлением стандарта 802.11n (обеспечивающего скорость до 600 Мбит/с), стала по-настоящему массовой. Параллельно развитие мобильных сетей третьего поколения (3G) дало пользователям первую реальную свободу от проводов.

Что конкретно изменилось в этот период

Скорость передачи данных сделала качественный скачок. Если в начале 2000-х максимальная скорость Wi-Fi редко превышала 54 Мбит/с (по стандарту 802.11g), то с 2013 года, с появлением стандарта 802.11ac, в дома пришли гигабитные скорости. Например, популярный роутер ASUS RT-AC68U поддерживал скорость до 1,9 Гбит/с, что позволяло комфортно смотреть видео в 4K на нескольких устройствах одновременно.

Вопросы безопасности тоже вышли на новый уровень. Устаревший и ненадежный WEP сменился сначала WPA, а затем WPA2. В 2018 году был представлен WPA3 — новый стандарт безопасности, закрывший многие известные уязвимости. Однако технологии принесли и проблемы — участились случаи фишинга, а взломы через уязвимости в сетях стали настоящей головной болью для специалистов по кибербезопасности.

Проблема покрытия больших площадей нашла свое решение в mesh-системах. Пионером в этой области стала компания Google с ее системой Google Wifi, представленной в 2016 году. Такие системы позволяли покрыть Wi-Fi сигналом весь дом без «мертвых зон», используя несколько взаимодействующих между собой модулей.

Конкретные цифры: Согласно данным операторов и исследований, к 2021 году общее количество Wi-Fi точек в России (включая домашние роутеры) оценивалось в десятки миллионов, при этом проникновение широкополосного интернета в домохозяйства превысило 75%, а в Москве и крупных городах достигало 90%.

Технологический прогресс затронул и частотный диапазон. Перегруженность 2.4 ГГц стала серьезной проблемой — в час пик скорость могла падать до 5-10 Мбит/с. Это подтолкнуло переход на 5 ГГц, который предлагал более чистый эфир, но требовал нового оборудования.

Рынок Wi-Fi-решений активно развивался. К 2022 году его объем достиг 5.1 млрд рублей. При этом средняя стоимость роутера упала, сделав технологию доступной массовому потребителю.

4G и 5G: как мобильный интернет перевернул все

Сети четвертого поколения (4G/LTE) совершили настоящую революцию в 2010-х годах, впервые обеспечив мобильный интернет со скоростями до 100-300 Мбит/с — быстрее, чем многие проводные домашние решения того времени.

Технология LTE стала основой для мобильного видеостриминга, такси-сервисов и других инноваций, изменивших повседневную жизнь. В России пик развития 4G пришелся на 2015-2018 годы, когда операторы развернули сети в большинстве городов-миллионников.

Однако настоящий технологический скачок произошел с появлением 5G, который предлагает не просто увеличение скорости, а качественно новые возможности.

Скорость передачи данных достигла невиданных ранее показателей. В тестовых замерах, проведенных МТС в Москве в 2020 году, 5G демонстрировал скорость до 1,2 Гбит/с. Для сравнения: средняя скорость 4G в тех же условиях составляет 100–300 Мбит/с. Это означает, что полнометражный фильм в 4K-качестве теперь можно скачать за считанные минуты.

Одним из ключевых преимуществ 5G стало радикальное снижение задержки (ping). Если в сетях 4G этот показатель обычно составляет 30–50 мс, то 5G сокращает его до 1–5 мс. Такие значения критически важны для технологий виртуальной реальности, телемедицины (особенно для удаленных операций) и облачного гейминга.

Однако внедрение 5G столкнулось с серьезными трудностями. Как отмечал «Коммерсантъ» в 2024 году, в России развертывание сетей пятого поколения значительно замедлилось из-за нехватки частотного спектра. Основные «чистые» частоты, используемые для 5G в других странах, в России были заняты спутниковой связью, военными и спецслужбами.

Есть и экономические ограничения. Капитальные затраты на развертывание 5G в 2.5 раза выше, чем для 4G при текущих частотах. Окупаемость инфраструктуры только в Москве оценивается в 25-30 лет. Эти проблемы характерны не только для России — аналогичные сложности с окупаемостью 5G фиксируют операторы в Европе и США.

Правительство РФ утвердило поэтапный план внедрения 5G, согласно которому к 2030 году технология появится в 41 городе. В 2024 году сети развернули в трех мегаполисах, в 2025 — еще в семи, а к 2030 они охватят все крупные агломерации страны. На эти цели из федерального бюджета выделено 21,5 млрд рублей в рамках проекта «Цифровые технологии».

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

Согласно статистике, сегодня почти половина мирового населения (45%) имеет доступ к среднечастотному 5G — оптимальному по сочетанию скорости и покрытия. Этот показатель продолжает стремительно расти: аналитики прогнозируют, что к 2030 году зона действия 5G охватит уже 85% жителей планеты.

Особенно впечатляют темпы внедрения в Азии. В Китае, где первые коммерческие сети 5G появились еще в 2019 году, технология сейчас доступна 92% населения. Индия, начавшая массовое развертывание позже, в 2022 году, уже обеспечила покрытие для 91% граждан благодаря агрессивной инфраструктурной программе. Эти две страны вместе добавляют около 1,5 миллиона новых 5G-пользователей ежемесячно, формируя основной драйвер глобального роста.

На начало 2025 года 5G-сети в России функционируют в ограниченном тестовом режиме. Технология доступна в отдельных районах Москвы, включая деловой центр Москва-Сити и территорию Сколково, Санкт-Петербурга (преимущественно в центральных районах), а также в инновационных кластерах — Иннополисе и томском IT-парке.

6G и будущее: технологический прорыв следующего десятилетия

Пока операторы в РФ и других странах только начинают разворачивать сети 5G, мировые технологические лидеры уже делают первые шаги в эпоху 6G.

Лабораторные испытания, проведенные учеными из Национального института информационных и коммуникационных технологий Японии (NICT), и промышленные тесты ведущих телеком-компаний Китая демонстрируют скорости, превышающие 400 Тбит/с в контролируемых условиях. Технологий шестого поколения откроют новую главу в развитии беспроводных коммуникаций. Эти тесты показали, что 6G — не просто эволюция существующих стандартов, а качественный скачок в передаче данных.

Технические особенности 6G

Основное отличие 6G от предыдущих поколений — использование терагерцового диапазона частот (от 100 ГГц до 10 ТГц). Скоростей будет достаточно для передачи 8K-видео в реальном времени или загрузки полнометражного фильма в 4K за 3-5 секунд. Для сравнения: максимальная скорость 5G в идеальных условиях не превышает 10 Гбит/с.

Интеграция с искусственным интеллектом

6G разрабатывается как «умная» сеть, где ИИ будет управлять ресурсами в реальном времени.

Компания Nokia Bell Labs уже тестирует алгоритмы, которые:

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

Безопасность и квантовые технологии

Китайские исследователи из Шанхайского университета добились значительных успехов в квантовом шифровании. В 2024-2025 годах им удалось установить защищенное соединение на расстоянии до 300 км, хотя скорость передачи оставалась низкой (порядка килобит в секунду). Эти достижения открывают перспективы для безопасной передачи данных особой важности.

Российские перспективы

По мнению экспертов, коммерческий запуск 6G в России возможен не ранее 2030 года.

Основные проблемы:

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

Потенциальные применения

Разработки в области 6G открывают путь к принципиально новым сценариям использования сетей связи:

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

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

Что мы потеряли и что приобрели

Подводя итоги 20-летней эволюции сетевых технологий, можно выделить несколько ключевых моментов.

Безусловные достижения:

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

Потери и новые вызовы:

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

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

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

Бонус — комментарии экспертов с многолетним опытом работы за границей и глубоким пониманием международного рынка труда.

Какие IT-профессии наиболее востребованы за рубежом

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

• менеджеры по продажам и работе с клиентами (13%),
• операторы колл-центров (5%),
• дизайнеры, менеджеры по маркетингу, интернет-маркетологи, художники (по 4%),
• учителя, SMM- и контент-менеджеры (по 3%),
• секретари, помощники руководителя, ассистенты (по 2%).

Программисты и разработчики заняли почётное второе место (10%). А специалисты технической поддержки и тестировщики набрали всего по 2%.

Но в исследовании образовательной онлайн-платформы «Нетология» и международного коммуникационного агентства Zecomms Agency специалист технической поддержки — наоборот, наиболее востребованная профессия за рубежом. С ним связано 17% от общего массива IT‑вакансий, что делает специалиста техподдержки абсолютным лидером по количеству открытых вакансий.

На втором месте расположился программный инженер (16%), на третьем — бизнес-аналитик (6%) и IT-консультант (6%).

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Согласно исследованию «Нетологии» и Zecomms Agency, Java признан самым популярным языком программирования — его активно используют компании по всему миру. На Java приходится более четверти всех открытых вакансий (26%) в сфере IT в Европе, США, Латинской Америке, Азии и на Ближнем Востоке.

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

На втором месте по популярности находится язык SQL, который используют для разработки баз данных и систем аналитики. На него пришлось 24% всех вакансий, бóльшая часть из них в Европе, Азии и на Ближнем Востоке.

Замыкает тройку лидеров Python (23%) — более половины открытых вакансий в Азии и на Ближнем Востоке связано именно с этим языком. Оно и неудивительно: на Python пишут модели для машинного обучения, анализа данных и автоматизации.

Сколько айтишникам платят за границей

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Но ключевое — размер оклада. По данным «Профсоюза работников ИТ», медианная зарплата специалистов уровня senior в России составляет 276 362 рубля в месяц, в то время как за рубежом она равна 386 730 рублей в месяц. Российские миддлы получают 170 000 рублей, а работающие за границей — 205 142 рубля. Зарплата джунов несильно отличается, хотя «за бугром» она всё-таки немного больше: 85 000 рублей против 80 000 рублей в России.

Таким образом, зарплата IT-специалистов за рубежом как минимум в 1,5 раза больше, чем в России.

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

Где IT-кадры пользуются спросом

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

Германия. Наибольший дефицит IT-специалистов наблюдается в Германии — в 2023 году было опубликовано 103 089 вакансий. Особенно остро нехватка кадров ощущается в таких областях, как разработка программного обеспечения, Data Science, кибербезопасность и DevOps. А в 2025 году страна планирует выдать на 10% больше рабочих виз, чем годом ранее.

Нидерланды. В стране большое внимание уделяется IT-стартапам. Так, в 2024 году голландские технологические компании привлекли €3,7 млрд венчурных инвестиций — это около 5% от общего объёма капитала, вложенного в европейскую экосистему. Благодаря этому Нидерланды вошли в топ‑10 стран Европы по объёму инвестиций в технологии. Особенно быстро растёт сектор DeepTech («глубоких технологий») — полупроводники, искусственный интеллект и квантовые технологии.

Канада. Такие канадские города как Торонто, Ванкувер и Монреаль считаются настоящей IT-меккой. Здесь активно развиваются стартапы и работают подразделения крупнейших технологических компаний — Google, Microsoft, Amazon. Кроме того, для IT-специалистов есть много иммиграционных программ, например, Global Talent Stream, которая позволяет получить разрешение на работу в течение двух недель.

США. В 2023 году объём IТ-рынка США достиг $1,3 трлн и продолжает развиваться высокими темпами. В Европейском союзе он составил $1,05 трлн, в Китае — $348 млрд, в России — $36,1 млрд. Таким образом, американский технологический рынок в 36 раз больше российского, в 1,24 раза больше европейского и почти в четыре раза превосходит китайский. Это подтверждает его статус мирового лидера. Соответственно, IT-специалистов нужно много.

Куда уехать проще всего

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

• Белоруссии — 172,3 тыс. приглашений,
• Казахстана — 150,9 тыс. приглашений,
• Грузии и Турции — 69,7 тыс. и 67,8 тыс. приглашений соответственно,
• Узбекистана — 57,2 тыс. приглашений.

Самый большой рост интереса продемонстрировали китайские работодатели — он увеличился почти в шесть раз. В 2023 году количество предложений для жителей России о работе в Китае составляло всего 4,8 тыс., тогда как в 2024 году цифра достигла 27,6 тыс. предложений.

Кроме того, за год потребность в российских специалистах выросла в Сербии с 5,8 тыс. до 26,3 тыс. (+356,3%), в Турции — с 23,5 тыс. до 67,8 тыс. (+188,6%), на Кипре — с 4,6 тыс. до 12 тыс. (+160,9%), в Польше — с 4,1 тыс. до 9,0 тыс. (+119,6%) и в ОАЭ — с 19,2 тыс. до 41,7 тыс. (+117,2%).

А Европа стала лидером по количеству предложений для IT-специалистов со знанием русского языка — 3% всех IT-вакансий в регионе. На других рынках доля таких предложений не превышает 1%. Чаще всего русскоязычных специалистов ищут в Польше — 2 200 вакансий, Венгрии — 752 вакансии, Австрии — 178 вакансий, Греции — 152 вакансии.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Как IT-специалисту найти работу за границей: четыре шага

1. Зарегистрируйтесь на международных платформах

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

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

• LinkedIn — профессиональная социальная сеть, где можно искать вакансии и налаживать контакты;
• Indeed — международный агрегатор вакансий, позволяющий фильтровать их по странам, городам и отраслям;
• Relocate.me — платформа для вакансий с релокацией;
• Remote OK — площадка для поиска удалённой работы;
• WWR — сервис, где публикуют вакансии крупные зарубежные компании, например, Amazon или Google.
• AngelList Talent — каталог вакансий в иностранных стартапах.

Некоторые из них открываются только с VPN.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Удобнее всего искать вакансии зарубежных компаний через LinkedIn. По моему опыту, большинство специалистов находят работу за границей именно через эту площадку. Но есть и альтернативные варианты — например, телеграм-каналы с профильными вакансиями. Будьте готовы к тому, что придётся отправлять много откликов. В среднем на 100 откликов приходится не более 5 ответов.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

2. Адаптируйте резюме для иностранного рынка

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

Эксперты компании EP Advisory, которая помогает российским специалистам строить карьеру за рубежом, рекомендуют включать в CV разделы Name, Profile, Education, Experience, Skills & Other. Названия предыдущих компаний и занимаемые должности следует выделять, а каждый блок — разграничить чертой.

Кроме того, в некоторых странах, например, Великобритании, США и Канаде не принято добавлять фото в резюме. Такое правило стало следствием законов против дискриминации в этих странах, поэтому его несоблюдение может вызвать негативную реакцию и привести к мгновенному отказу.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

3. Обратитесь в агентство по трудоустройству

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

Вот список наиболее известных рекрутинговых агентств:

• Adecco — крупнейшее агентство с вакансиями по всему миру;
• Manpower — международная стаффинговая, аутсорсинговая и HR-консалтинговая компания из России;
• Michael Page — международная компания, которая специализируется на подборе персонала среднего и высшего звена;
• Hays — британская рекрутинговая компания, которая предоставляет услуги по подбору персонала в 33 странах мира;
• Harvey Nash — международная компания, которая специализируется на IT-аутсорсинге;
• Randstad — голландская консалтинговая компания, которая сотрудничает с ведущими зарубежными работодателями.

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

Чтобы найти работу в Лондоне, я сотрудничал с международными и британскими рекрутинговыми агентствами — Hays, Harvey Nash и Michael Page. Примерно 50% предложений приходили именно от них. Эти агентства играют важную роль на IT-рынке и обладают широкой сетью контактов с работодателями по всей Европе. Они помогали мне в поиске подходящих позиций и сопровождали на всех этапах — от первичного отклика до собеседования и подписания оффера.

4. Получите визу и разрешение на работу

Без визы и разрешения приступить к работе за границей не получится. Здесь доступны два варианта — Digital Nomad Visa или обычные рабочие визы.

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

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

Чтобы получить визу цифрового кочевника, нужно подтвердить минимальный доход (чаще всего не ниже 2000 евро в месяц) и наличие медицинской страховки. Также может понадобиться трудовой договор или договор подряда, доказывающие, что вы работаете удалённо. Сейчас Digital Nomad Visa оформляют в 66 странах, включая Португалию, Испанию, Эстонию, ОАЭ и Южную Корею.

Классические рабочие визы. Это визы EU Blue Card или виза H‑1B.

• Голубая карта (EU Blue card) — виза для работы в Европе. Чтобы получить её, нужен диплом о высшем образовании (не ниже бакалавра) и оффер с зарплатой от 48 300 евро год (43 760 евро для IT‑специалистов) на срок минимум шесть месяцев. В случае одобрения выдаётся вид на жительство, действующий до четырёх лет с возможностью продления.

• Виза H‑1B — виза для работы в США. Она также требует наличия высшего образования и оффера от местной компании. Но американское законодательство устанавливает лимит на выдачу H‑1B — 65 000 базовых и 20 000 дополнительных виз для специалистов с магистерской степенью из США. Всего 85 000 виз в год. Виза предоставляется максимум на три года с возможностью продления до шесть лет.

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

Официальное трудоустройство или фриланс

Удалённая работа на фрилансе

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

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

Официальное трудоустройство с релокацией

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

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Для оценки владения иностранными языками, включая английский, в Европе используют систему CEFR (Common European Framework of Reference). CEFR выделяет шесть уровней знания языка: A1, A2, B1, B2, C1, C2.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

• Иностранные компании активно используют Java, Python, SQL и нуждаются в программистах, умеющих писать на этих языках.
• IT-специалисты особенно востребованы в Германии, Нидерландах, Канаде и США — странах с наиболее интенсивным ростом технологического сектора.
• Проще всего уехать в Белоруссию, Казахстан, Турцию, Грузию и Китай.
• Работать за границей можно официально или на фрилансе.
• Чтобы получить оффер, следует зарегистрироваться на международных платформах для поиска работы, адаптировать резюме, оформить визу и, при необходимости, обратиться в агентство.

В мае 2024 по всему миру разлетелись скриншоты писем от HR с внезапными повышениями зарплат на 40%. Текучка кадров в сфере производства полупроводников выросла с 40% до 53%, и теперь компании дерутся за каждого специалиста.

Масштаб проблемы

169 отраслей пострадали из-за дефицита чипов — от автомобилестроения до бытовой техники. Tesla и Volvo останавливали заводы, цены на подержанные автомобили выросли на 10% за квартал. Даже стиральные машины подорожали из-за недостатка микросхем.

Но настоящая битва кипит в кабинетах бигтехов. США заблокировали экспорт технологий в Китай, Европа запустила программу на €43 миллиарда, а Азия удерживает 77% мирового производства чипов.

Технологическая война изменила ИТ-индустрию навсегда. Компании теперь не могут просто купить больше серверов — приходится искать тех, кто умеет делать софт быстрее и эффективнее. Apple создала собственные M1 и M2, Google разработал TPU, Amazon — процессоры Graviton. Каждый хочет стать независимым от поставок.

Обрушение цепей поставок

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

Мир оказался в заложниках у нескольких азиатских гигантов. Тайвань контролирует 65% мирового рынка чипов, TSMC делает процессоры для Apple, AMD и NVIDIA. Samsung доминирует в производстве памяти и накопителей.

Различные отрасли посыпались, как домино. Время ожидания полупроводников Broadcom выросло до 22 недель против 12 недель в феврале 2020. Автоиндустрия потеряла миллионы машин, дата-центры замедлили расширение, даже PlayStation 5 стали дефицитом.

США первыми объявили технологическую войну. Пошлины уже изменили процессы производства у Nvidia, Intel и AMD. Китай ответил санкциями против Micron Technology.

Ключевые игроки разделились на два лагеря. На стороне США — Intel, NVIDIA, AMD, Qualcomm. Китай развивает SMIC и вкладывает миллиарды в собственные технологии. TSMC и Samsung балансируют между сторонами, строя заводы и в Америке, и в Азии.

Национальные программы превратились в гонку вооружений. CHIPS Act выделил $50 миллиардов на американское производство. Европейская программа нацелена на производство 20% мировых чипов к 2030 году. Китай инвестирует $143 миллиарда в полупроводники.

Гонки в мире чипов

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

Техпроцессы сжимаются в размере. TSMC освоила 3-нанометровый процесс, Samsung догоняет. Каждый нанометр стоит миллиарды инвестиций и годы разработки. Apple M4 имеет Neural Engine в три раза быстрее M1, но производство одного такого чипа требует сотни инженеров.

AI-чипы стали новой золотой жилой. Intel запустила Gaudi 3, который на 50% быстрее NVIDIA H100. NVIDIA ответила платформой Blackwell с 208 миллиардами транзисторов. Qualcomm Cloud AI 100 обошел H100 по энергоэффективности — 227 запросов на ватт против 108.

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

Делать чипы стало сложнее и дороже. Современная фабрика стоит $20 миллиардов, срок окупаемости — 10 лет. Поэтому крупные компании строят собственные решения: Apple создала M-серию, Google — TPU, Amazon — Graviton.

Компании поменяли философию. Вместо покупки большего количества серверов они нанимают инженеров для оптимизации кода. Netflix использует персонализированные рекомендации и алгоритмы ранжирования для оптимизации вычислений. Meta* оптимизировала машинное обучение и уменьшила количество GPU на 40%.

Массовый переход на ARM изменил рынок. Amazon перевела часть ресурсов на собственные процессоры. Microsoft адаптировала Windows под ARM-архитектуру. Даже Intel вынуждена выпускать подобные решения.

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

*– компания признана в РФ экстремистской и запрещена.

Айтишники в центре шторма

Зарплаты разработчиков взлетели вместе с ценами на чипы. Средняя зарплата embedded-инженера выросла до $153,383, а топовые специалисты получают до $175,000 в год. Performance-инженеры зарабатывают в среднем $100,522, но спрос превышает предложение. Оптимизация под ARM-архитектуру, разработка драйверов для AI-ускорителей, программирование FPGA — навыки, за которые компании готовы переплачивать. IT-зарплаты в Северной Америке выросли в среднем до $113,211.

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

География возможностей сместилась. Калифорния лидирует по зарплатам — $126,707 в Сан-Хосе, но спрос есть везде. Даже компании из Техаса и Флориды переманивают embedded-разработчиков зарплатами в $120,000-150,000.

Системные администраторы, знающие Kubernetes и контейнеризацию, стали дефицитом. Компании переходят на микросервисы и edge-решения — нужны те, кто умеет управлять распределенной инфраструктурой.

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

Свет в конце туннеля

Эксперты расходятся в прогнозах восстановления. CEO Intel Пат Гелсингер ожидал дефицит до 2024 года, но рынок полупроводников уже показал рост на 15,2% в начале года. К 2023-му автоиндустрия в основном восстановилась, глобальное производство автомобилей выросло на 3%.

Новые фабрики меняют географию производства. Intel строит заводы в Аризоне за $20 миллиардов и расширяется в Огайо. TSMC открыла завод в Японии в феврале 2024 и планирует второй к 2027 году. Samsung инвестирует в производство в Техасе.

Европа также входит в игру. European Chips Act нацелен на производство 20% мировых чипов к 2030 году с бюджетом €43 миллиарда. Intel проектирует заводы в Ирландии и Германии, Micron строит завод в Нью-Йорке, а GlobalFoundries расширяется на Мальте.

Будущее отрасли — в диверсификации. Тайвань по-прежнему контролирует 65% производства, но объемы будут снижаться. К 2030 году США планируют удвоить свою долю в мировом производстве чипов.

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

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

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

Здесь и появляются новые роли — Technical Owner и Unit-лид. Их задача — взять на себя куски ответственности, которые раньше выпадали из поля зрения команды.

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

Technical Owner: кто это и зачем нужен

Представим ситуацию: компания разрабатывает маркетплейс на Python и React, всё вроде идёт по плану, пока менеджеры не просят срочно добавить новую систему оплаты. Они не вникают, что для этого придётся переделать схему платежей, разнести микросервисы, рискуя уронить старые заказы. Разработчики объясняют, что быстро не выйдет, но их не слышат — и в итоге проект зависает между требованиями бизнеса и возможностями команды. Именно в таких случаях нужен Technical Owner.

Кто это такой

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

Какие у него обязанности

Вот примерный список того, что делает ТО:

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

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

Чем отличается от продуктового менеджера, техлида и архитектора

Чем ТО отличается от продуктового менеджера

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

Чем отличается от тимлида, техлида и архитектора

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

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

Technical Owner (Технический владелец) ответственен за долгосрочное здоровье и развитие конкретного компонента/системы/продукта. Фокус на технической стратегии, архитектуре, надёжности и поддержке в течение всего жизненного цикла.

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

Архитектор решений определяет технологический стек и взаимодействие компонентов. Фокус на общей структуре и дизайне решения.

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

Сколько зарабатывает и какие нужны навыки, чтобы стать ТО

Если мы сейчас пойдём на hh.ru и введём в поиск Technical Owner, то, в лучшем случае, найдём только пару вакансий. Technical Owner нужен для больших продуктов в крупных компаниях, поэтому должность встречается на рыке редко и пробиться туда сложно.

Зарплата и навыки зависят от конкретной компании, её процессов и задач. Обычно это что-то на уровне топ-менеджмента. Вот пример заработной платы в одной из вакансий от Яндекс 360:

А вот так выглядят обязанности и необходимые навыки:

Вот пример ещё одной такой вакансии от компании Itransition:

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

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

Кто такой Unit-лид, зачем он нужен

Кто это такой

Юнит-лид — это руководитель, который возглавляет «юнит» – объединение нескольких команд (обычно 3-5), работающих над частью общего продукта или бизнес-направления. Он отвечает за стратегию и бизнес-результаты своего юнита.

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

Что такое юнит? Это самостоятельный бизнес-модуль, включающий несколько стримов (направлений). Каждый стрим, в свою очередь, состоит из команд по 5-10 человек. Таким образом, один юнит может объединять от 5 до 12 команд, представляющих разные IT-направления: фронтенд, бэкенд, мобайл и др.

Какие у него обязанности

Обязанности юнит-лида очень обширны и зависят от типа юнита:

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

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

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

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

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

Чем отличается от продуктового менеджера и тимлида

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

Что делает продуктовый менеджер

Продуктовый менеджер (PM или Product Owner) отвечает за конкретный продукт или его отдельные части. Его главная задача — понять, что нужно пользователям и бизнесу, сформировать требования и приоритеты, а затем воплотить эти требования в жизнь. PM постоянно держит руку на пульсе метрик, проводит A/B-тесты и собирает обратную связь.

Что делает тимлид

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

Чем занимается юнит-лид

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

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

Две другие команды отдают цены в другие сервисы, организуют скидки, интегрируют новые категории товаров и услуг в систему.

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

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

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

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

Наткнуться на вакансию юнит-лида на просторах hh.ru тоже непросто. Это новая роль, которая нужна только для сложных продуктов в крупных IT-компаниях.

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

Зарплата вполне на уровне топ-менеджмента. А вот обязанности и ожидания:

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

А вот ещё один пример обязанностей и ожиданий в другой вакансии, на этот раз от Яндекса:

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

Где и когда эти роли реально нужны (а где — нет)

Какие компании и проекты выигрывают от появления таких ролей

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

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

Сигналы, что команде пора подумать о Technical Owner или Unit-лиде

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

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

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

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

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

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

Сколько в мире людей с имплантами?

Импланты и протезы становятся всё более привычной частью жизни во всём мире.

Протезы конечностей. По оценке ВОЗ, в протезах и ортезах нуждаются от 35 до 40 миллионов человек по всему миру, но только один из десяти реально получает нужное устройство. В России, по данным Минтруда, протезы конечностей стоят у 200 тысяч человек. Мировой рынок биопротезов уже перевалил за $1,5 млрд и, по прогнозам, вырастет почти вдвое к 2030 году.

Кардиостимуляторы. Более 3 миллионов людей в мире живут с кардиостимуляторами. Каждый год медики устанавливают ещё от 600 тыс. до миллиона новых устройств, и эта цифра стабильно растёт.

Кохлеарные импланты. Более 1 млн человек по всему миру получили кохлеарные импланты — устройства, которые возвращают слух даже тем, кто не слышал с рождения.

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

Добровольно чипированные. По оценкам Government Technology, от 50 000 человек на планете добровольно вживили себе микрочипы — чаще всего для замены пропуска, банковской карты или электронного ключа. К примеру, американская компания Three Square Market (32M) в 2017 году вживила 50 сотрудникам NFC-чипы для замены пропуска и кредитки. Аналогично поступила шведская компания BioHax International в отношении 150 сотрудников.

В 2015 году менеджер российской компании Ericsson тоже вживил себе NFC-чип и использует его как визитную карточку. Энтузиаст отмечает, что более современные чипы можно использовать для оплаты в магазине.

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

Что уже умеют современные импланты?

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

Нолан Арбо: парализованный, который играет в Civilization VI

В 2016 году Нолан Арбо получил тяжёлую травму позвоночника, он оказался парализован.

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

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

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

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

Филип О’Киф: пациент с БАС, который снова в сети

Филип О’Киф — бывший банковский работник, отец семейства. В 2015 году он начал замечать слабость в руках и ногах, ему стало сложно выполнять привычные действия — писать, одеваться, работать за компьютером. Постепенно болезнь прогрессировала: Филип стал терять подвижность, речь — менее чёткая. Врачи поставили диагноз — боковой амиотрофический склероз (БАС), при котором постепенно отмирают моторные нейроны, и человек теряет возможность двигаться и говорить. Через несколько лет Филип оказался почти полностью парализованным.

Вместо сложной нейрохирургии врачи использовали чип Stentrode от американской компании Synchron. Его ввели через вену на шее: чип сам «дошёл» до нужной зоны мозга и раскрылся там в виде сеточки с 16 контактами. Второй модуль вживили под кожу на груди — он передаёт сигналы наружу. Оба устройства связали тонким проводом.

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

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

Андрей Марсаков — программист с механическим протезом руки

Андрей Марсаков — 26-летний программист из Екатеринбурга. Он родился без правой кисти (врождённая аплазия) и с детства привык делать всё одной рукой. Однажды решил попробовать «другую жизнь» с протезом — чтобы упростить повседневные задачи и получить новый опыт.

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

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

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

Устройство от Cortical Labs: компьютер из схем и клеток человеческого мозга

В 2025 году австралийский стартап Cortical Labs представил первый коммерческий биокомпьютер CL1. Учёные вырастили в лаборатории 800 тысяч человеческих нейронов и соединили их с обычной микросхемой. Получился гибрид: нейроны могут учиться и адаптироваться как живой мозг, а микросхема передаёт сигналы в цифровом виде.

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

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

Авторы проекта открыто заявляют: в будущем такие биокомпьютеры станут основой для продвинутых нейроинтерфейсов и гибридных ИИ — на стыке биологии и математики.

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

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

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

Обезьяна, играющая в Pong. В 2021 году Neuralink внедрили свой чип обезьяне по кличке Pager. После короткого курса обучения она смогла сыграть в аркадную видеоигру Pong: не джойстиком, а мысленным управлением. Чип фиксировал всплески нейронной активности, ИИ-алгоритмы расшифровывали их и передавали команды на экран.

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

Как ИИ помогает людям с имплантами и протезами?

Узкоспециализированные ИИ

ИИ для протезов ноги

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

ИИ для улучшения моторики рук

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

LLM в теле человека

Neuralink от Илона Маска использует Grok для работы чипа. С помощью нейроинтерфейса человек мысленно набирает текст, а модель Grok в связке с ElevenLabs воспроизводит речь. Причем ИИ обучен на старых записях разговоров пациента. Человек «думает» фразу, а Grok озвучивает.

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

Основные проблемы нейроинтерфейсов, протезов и имплантов

Стоимость и поддержка

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

Например, в 2019 году компания Second Sight заявила о поэтапном прекращении работы и в итоге обанкротилась. Компания предлагала свою продукцию слепым и слабовидящим. Стоимость одного импланта составляла $150 тыс. Пациенты после операции начинали лучше видеть, самостоятельно ходили в магазин, катались на лыжах. Однако, оказалось, что компания неправильно оценила затраты и работала в убыток, даже при таком высоком чеке. В результате она закрылась, а 350 пациентов с имплантами остались без поддержки.

Риск утечки конфиденциальных данных из «мозга»

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

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

Ученые анализировали P300-волны, которые возникают, когда человек видит что-то значимое или узнаваемое. Исследователи смогли определить личную информацию испытуемых. Точность угадывания первого знака в PIN-коде составила 20%; до 30% увеличилась точность определения банка и города испытуемого. Это, конечно, не 50% и даже не 100%, но всё равно высокий показатель.

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

Медицинские риски

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

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

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

ИИ уже среди нас, и надо быть в курсе событий. Поэтому скорее подписывайтесь на наш Нейроканал!

Может плодить новые эндпоинты или заставлять мобилку делать несколько запросов вместо одного? Каждый запрос жрёт трафик и батарею!

Элегантное решение — архитектура Backend for Frontend (BFF). Это прослойка между клиентскими приложениями и основным API, которая адаптирует данные под потребности конкретного клиента.

Основная идея backend for frontend

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

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

Следуя архитектуре BFF, вы можете создать логику для каждого типа клиента и не засорять основной API. Вместо одного эндпоинта /api/products, который пытается угодить всем, появляются слои:

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

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

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

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

«Можете добавить поле user_avatar в ответ?»

— «Это сломает мобилку».

«Тогда сделайте отдельный эндпоинт».

— «У нас нет времени».

С BFF этого диалога нет. Фронтенд-команда получает свой API и крутит его, как хочет.

Мобильное приложение съедает 10к запросов в секунду? Пишите BFF на Go. Веб-версию делает стажёр, который знает только JavaScript? Ставьте Node.js. Никто не заставляет выбирать одну технологию на все случаи жизни.

Как работает backend for frontend (BFF)

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

Архитектура взаимодействия

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

Когда мобильное приложение запрашивает список заказов, его BFF делает несколько вызовов к микросервисам:

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

Затем склеивает всё в один ответ, отбрасывая ненужные поля и добавляя вычисляемые значения.

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

Обработка и агрегация данных

BFF не просто перекладывает данные из одного формата в другой. Он выполняет бизнес-логику.

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

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

Независимость и масштабирование

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

4 ключевых преимущества BFF

Оптимизация передачи данных

Самое очевидное преимущество — экономия трафика. Приложение не тащит 2 МБ JSON с полным каталогом товаров на мобильное устройство? BFF отдаёт только нужные поля.

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

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

BFF объединяет всё в один запрос, получая данные параллельно от разных сервисов.

Упрощение фронтенда

Половина фронтенд-кода уходит на трансформацию ответов API:

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

BFF может взять эту работу на себя.

Безопасность через изоляцию

BFF создаёт барьер между клиентами и сервисами. Мобильное приложение никогда напрямую не обращается к БД пользователей или платёжке — только через свой BFF.

Можно настроить разные уровни доступа:

• мобильный BFF видит только публичные данные,
• API для партнёров работает в песочнице.

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

Независимое масштабирование

Когда приложение попадает в топ App Store, нагрузка взлетает в разы. Но страдает только мобильный BFF — веб-версия продолжает работать стабильно. Можно быстро поднять дополнительные серверы только для мобильного трафика.

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

Когда стоит использовать backend for frontend

BFF — инструмент для конкретных ситуаций.

Когда интерфейсы кардинально отличаются

Если ловите себя на мысли: «этот эндпоинт нужен только для веба» или «мобилка использует 10% полей из ответа», — пора задуматься о BFF.

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

Когда интерфейсы эволюционируют быстрее джунов

Стартапы и продукты в активной фазе развития меняют интерфейсы каждую неделю.

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

Без BFF это означает изменения в основном API, которые могут сломать другие клиенты. С BFF — правки только в одном месте.

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

Если у вас несколько фронтенд-команд, которые постоянно конфликтуют из-за API, BFF даст им свободу.

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

BFF распределяет ответственность: каждая команда поддерживает свой слой.

Когда НЕ стоит использовать BFF

Если у вас простое приложение с одним клиентом, BFF добавит лишнюю сложность. Если API уже идеально подходит всем клиентам, зачем что-то менять?

3 типичные ошибки при внедрении BFF

Дублирование логики

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

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

Избыточная сложность вместо упрощения

Пример: команда создаёт «универсальный BFF-фреймворк» с конфигурацией через YAML, поддержкой плагинов и собственным DSL. В итоге простое добавление поля в ответ требует изучения документации на 50 страниц.

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

Неправильная гранулярность

Один BFF на все мобильные платформы может быть слишком общим: iOS и Android имеют разные особенности интерфейса. Но отдельный BFF для каждой версии приложения — явный перебор.

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

Практические примеры использования BFF

Netflix

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

Spotify

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

SoundCloud

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

Заключение

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

Backend for Frontend создаёт слой между клиентами и основными сервисами. Каждый тип устройства получает API, заточенный под его потребности.

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

Ты уже программист, если читаешь это! Больше про кодинг — здесь.

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

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

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

Микросервисы: зачем они нужны и в чем их плюсы

Архитектура приложений: немного базы

Под капотом современных приложений обычно скрываются три основные части:

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

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

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

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

Масштабировать можно и монолиты, но у них всегда остается какая-то единая точка отказа — например, база данных. Особенно если это реляционная СУБД, завязанная на Oracle или PostgreSQL. Когда база достигает сотен гигабайт или даже терабайт, масштабировать такую штуку становится дорого, больно и ненадежно.

Микросервисы — панацея? Не совсем

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

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

Распространение DevOps-культуры и инструменты оркестрации

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

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

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

Проектируем микросервисы без боли: от стандартов до DDD

Стандартизация — наше все

Если каждый микросервис пишет логи в своем формате и использует свои библиотеки, получается зоопарк. Нужно, чтобы были выровнены стек и CI/CD pipeline, существовали одинаковые библиотеки логирования и формат.Микросервисы дают свободу писать на разных языках, но с ней приходит и ответственность: под каждый язык придется придумывать и поддерживать разные инструменты. А это приведет к еще большему увеличению сложности. Так что с языком тоже лучше соблюдать стандартизацию: если пишете на Java, то и решать все проблемы стоит с помощью этого языка.

При этом иногда другой язык вполне оправдан. Например, просто потому, что Java не может работать с такой высокой скоростью, какая нужна. В некоторых случаях даже на Java приходится писать особым образом, либо можно использовать C++, Go или Rust. Но это скорее исключение из правила.

Инженеры — натуры увлекающиеся и любят паттерн CV driven development, когда хочется новую технологию потрогать и внедрить у себя. А потом похвастаться этим на каком-нибудь ивенте по принципу «just because I can» («просто потому что могу»). При этом может оказаться, что бизнесу технология особо и не была нужна. Чтобы избегать таких ситуаций, необходим технологический радар — список того, что можно использовать в компании, а что нет. И исключения из такого радара должны приниматься и допускаться очень взвешенно.

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

Одна из опасностей при проектировании микросервисов — скатиться в очень мелкую гранулярность, когда логика нарезается чуть ли не по отдельной функции на микросервис (на отдельный deployment unit). Это может привести к такой сложности, которой потом будет очень трудно управлять. Такая проблема была, например, у Uber в начале их пути, и им пришлось пересматривать свою архитектуру. Избежать этого помогает Domain-driven design (DDD) — предметно-ориентированное проектирование.

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

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

DDD помогает выделить bounded context — согласованные по бизнесу участки. Они позволяют более или менее правильно нарезать большой бизнес-функционал на отдельные части.

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

Два эмпирических правила, которые касаются размера сервисов и помогают понять, правильно ли они спроектированы:

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

Внедрение микросервисов: с чего начать?

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

И вот тут возникает реальная сложность, особенно когда вы только начинаете, — глаза разбегаются. Здесь Kubernetes, здесь ELK, здесь Grafana, здесь observability, здесь всякие паттерны отказоустойчивости, CAP-теорема и прочее. Непонятно, куда бежать. И каждый день появляются новые инструменты, которые так или иначе упрощают жизнь.

Совет: задавайте себе вопрос о каждом инструменте, который вы хотите внедрить (будь то Kubernetes, OpenTelemetry с Jaeger или любой другой) — какую проблему мы решаем, втаскивая его в свою инфраструктуру? Ответ на этот простой вопрос может дать много инсайтов и просветлений.

Чтобы в первом приближении ознакомиться с темой, можно почитать материалы SRE от Google, также будут полезны статьи и книги в блоге Мартина Фаулера, в том числе Microservices Guide. Если вам нужна практика, можно попробовать пойти на тот же Udemy, где есть множество курсов по микросервисной архитектуре с хорошими рейтингами и отзывами.

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

Поддержка микросервисной архитектуры

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

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

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

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

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

Еще один хороший вопрос: как мониторить аварии? Необходимо очень быстро находить точку отказа. Для этого, собственно, и нужен observability-подход, трейсинг. Нужно смотреть, где какой RPS (число запросов в секунду), не произошло ли резкого скачка трафика, важно следить за latency (задержками).

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

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

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

• Circuit Breaker — если сервис спамит ошибками, лучше временно прекратить попытки до него достучаться. Для клиента ничего не изменится, он как получал ошибки, так и будет получать. Но, по крайней мере, можно дать системе возможность восстановиться. А еще лучше — позволить ей переключиться на какой-то резервный канал, например сходить в кэш с неактуальными данными.
• Rate Limiter — абсолютно банальная, но необходимая вещь. Нужно ограничивать входящий поток на примерно максимальном уровне от того, который ожидается. Чтобы все не развалилось, если произойдет резкий скачок трафика.
• Blue-Green Deployment — значительно снижают на продакшене количество аварий и проблем, связанных с кривыми релизами. Можно не раскатывать новую фичу сразу на все 100 подов, а выкатить ее только на 1% трафика и проверить.

И это только малая часть паттернов.

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

Как эффективно работать с инцидентами

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

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

Если на первом уровне все нормально, нужно опуститься на уровень ниже — либо на виртуалки, на которых Kubernetes развернут, либо на железки, если он развернут на Bare-metal. Недавно мы столкнулись с интересным случаем: виртуалка показывала нормальную загрузку CPU, но физический гипервизор, на котором она крутилась, был загружен на 99%. Естественно, виртуалка страдала, но уровнем выше этого не было видно.

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

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

Вообще, человеческий фактор — это отдельная боль. Все привыкли менять что-нибудь руками: заходить в виртуалки, поправлять конфиг. Чтобы такого было как можно меньше, важно вкладываться в infrastructure as a code и даже everything as a code. В идеале следует стремиться к zero access production — нулевому доступу к продакшену — и все раскатывать через Git, через конфигурации, включая политики безопасности.

Культура ответственности и изменение ролей в команде

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

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

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

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

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

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

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

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

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

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

Будущее микросервисов: тренд на AI Ops

Разработчики уже используют AI как copilot — и это очень мощный инструмент в умелых руках. Он не заменяет инженера, но сильно экономит ему время. Эту помощь от нейросетей очень хочется растянуть и на инфраструктуру, и на эксплуатацию, чтобы получить крутой AI Ops.

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

Есть прототипы — например, Big Panda или Moocsoft (который был недавно куплен Dell), но пока это точечные решения. Возможно, на горизонте 5–7 лет (скорее 5, чем 10) они станут серьезной частью индустрии и очень мощным прорывом, который упростит разработчикам жизнь.Кроме того, важно, чтобы развивались и более «приземленные» технологии: инструменты контейнеризации, оркестрации, observability, а также APM — Application Performance Monitoring.

Инженер остается в центре всего

Никакие микросервисы, Kubernetes и AI Ops не спасут, если за системой не стоит инженер, который думает головой, правильно работает руками и отвечает за результат. Важны его навыки, кругозор и культура работы. Именно такие люди превращают набор сервисов в работающий продукт. Все остальное — только инструменты.

P. S. Если интересно, как мы решаем эти задачи на практике, слушайте (и смотрите) наш подкаст «Техно.Логично» — там регулярно обсуждаем самое актуальное в IT-сфере.

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

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

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

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

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

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

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

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

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

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

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

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

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

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

До Finance.kz я работал в казахстанских финтех-проектах — bai.kz и finbee.kz. Там понял, что рынок агрегаторов в Казахстане находится в зачаточном состоянии. Пользователи мучились, сравнивая предложения банков вручную, а сами финансовые организации не умели эффективно работать с цифровыми каналами привлечения клиентов.

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

Состояние рынка: от монополии к жёсткой конкуренции

Казахстанский рынок агрегаторов финансовых продуктов переживает бум. Ещё два года назад здесь было 2-3 локальных игрока с простейшим функционалом. Сегодня ситуация кардинально изменилась — зашли зарубежные команды: vbr.kz, fintree.kz, moneypanda.com и другие.

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

Технологические вызовы: интеграция с госсервисами и банками

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

API-интеграции с банками и МФО

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

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

Интеграция с госорганами

Finance.kz интегрируется с государственными сервисами eGov и Палаты предпринимателей (ПКБ). Это позволяет автоматически подтягивать справки о доходах, данные о трудоустройстве и другие документы, необходимые для получения кредита.

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

Архитектура продукта: ставка на микросервисы

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

Backend

Основные сервисы написаны на Node.js с использованием Express.js. Для работы с базами данных используем PostgreSQL для транзакционных данных и Redis для кэширования. Очереди сообщений реализованы через RabbitMQ — это критично для обработки заявок пользователей.

Отдельно выделили сервис интеграций, который отвечает за взаимодействие с внешними API. Он построен по принципу circuit breaker — если один из банков не отвечает, это не ломает работу всего агрегатора.

Frontend

Фронтенд построен на React с использованием Next.js для серверной отрисовки. Это важно для SEO — львиная доля трафика приходит из поисковых систем по запросам типа «кредит онлайн».

Стратегия «единого окна»: от поиска до получения

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

Для этого мы реализовали несколько ключевых функций:

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

Монетизация: CPS как основа устойчивого бизнеса

Мы работаем по модели CPS (Cost Per Sale) — получаем комиссию только за успешно выданные продукты. Для кредитов это 2% от суммы, для микрозаймов — фиксированная сумма от 7 до 15 тысяч тенге.

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

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

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

Что даёт локальный подход:

• Знание рынка: мы понимаем особенности работы казахстанских банков и МФО
• Связи с регуляторами: легче договариваться об интеграциях с госорганами
• Техническая экспертиза: наша команда уже прошла путь интеграции с местными API
• Гибкая настройка продукта под изменения законодательства и требований ЦБ

Результаты и метрики

За год активного развития мы достигли:

• 150 000 уникальных пользователей в месяц
• Интеграция с 15+ финансовыми организациями
• Конверсия заявка-выдача на уровне 35-40% (против 15-20% у конкурентов)
• Средний чек по кредитам — 1,2 млн тенге, по микрозаймам — 85 тысяч

Планы на будущее: от агрегатора к экосистеме

Ближайшие 1-2 года будут критичными для всего рынка. Мы видим несколько ключевых направлений развития:

Расширение продуктовой линейки

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

Внедрение ИИ и машинного обучения

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

Международная экспансия

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

Собственные финансовые продукты

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

Уроки и выводы

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

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

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

Почему так? В 2024–2025 годах США ужесточили ограничения: VMware NSX и Cisco ACI официально заблокированы. Казалось бы, идеальный момент для отечественных решений вроде Basis SDN от «Базиса». Но сегодня их доля на рынке — не выше 3%.

Выясним, почему российские SDN, несмотря на импортозамещение, пока так и не стали массовыми, и что мешает бизнесу переходить на отечественные продукты — от дефицита специалистов до проблем с legacy-инфраструктурой. Только факты, кейсы внедрений и прогнозы на 2026–2030 годы с опорой на отчеты Ростелекома, аналитику 6Wresearch и документы OFAC.

SDN в России-2025: почему мир перешел на «сети из кода», а мы настраиваем маршрутизаторы вручную

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

Мировой контекст: SDN как новая норма

Глобальный рынок SDN к 2025 году оценивается в $12+ млрд, а темпы роста превышают 18% в год. Причины просты:

• Облака и гибридные инфраструктуры требуют гибкости, которую традиционные сети дать не могут.
• Киберугрозы теперь атакуют не отдельные устройства, а всю сеть. SDN позволяет изолировать зараженные сегменты за секунды — например, отрезать атакованный филиал до того, как он заразит головной офис.
• 5G и IoT без SDN просто не работают. Виртуальные срезы сети (network slicing) — единственный способ гарантировать приоритет критичному трафику, будь то телемедицина или беспилотники.

Но главный драйвер — экономика. Компании устали переплачивать за «умное» железо Cisco и Juniper, когда всю логику можно перенести в софт. К 2025 году 70% корпоративных сетей в ЕС и США управляются через SDN-контроллеры — просто потому, что это дешевле и быстрее.

Россия: технологический суверенитет vs. реальность

В 2024–2025 годах санкции добили то, что не успели в 2022-м:

• VMware NSX официально заблокирован для российских компаний.
• Cisco ACI и Huawei CloudFabric доступны только через «серые» схемы, но их поддержка практически не работает.
• Оборудование попало под прямые ограничения: даже нейтральные производители вроде Arista отказываются поставлять коммутаторы из-за риска вторичных санкций.

Казалось бы, идеальный момент для российских SDN-решений. Но доля отечественных продуктов на рынке — единицы. Причины такой ситуации вполне объективны:

• «Железная» зависимость. Большинство российских SDN работают только с оборудованием конкретных вендоров — YADRO, Aquarius, «Бифорком». Если у компании инфраструктура на старых Cisco или Huawei, миграция потребует полной замены «железа».
• Функциональные пробелы. Тот же Basis SDN декларирует 80% функционала VMware NSX, но ключевые фичи вроде автоматического восстановления после сбоев (self-healing) или глубокой аналитики трафика через ИИ пока в разработке.
• Дефицит экспертов. В России менее 1000 сертифицированных специалистов по SDN — против 25 000 в США и ЕС. Обучение нового инженера с нуля занимает 1.5–2 года — бизнес не готов ждать.

Спрос есть, но внедрять некому

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

При этом Basis SDN — единственное решение, которое хоть как-то закрывает дыру. Его пилоты запустили Ростелеком, СберТех и несколько госструктур. Но даже они признают: продукту не хватает открытости API и поддержки мультивендорных сред.

Вывод: мир уже живет в эпоху «сетей как кода», а Россия только учится настраивать контроллеры. Без массовых инвестиций в R&D (Research and Development, научные исследования и разработки) и образование разрыв будет расти. К 2030 году мы рискуем остаться с SDN «на бумаге», пока глобальные игроки перейдут на следующую ступень — IBN (intent-based networking) — сеть, основанную на намерениях с полной автономией ИИ.

Свои SDN: роскошь или необходимость?

Блокировки лишили российские компании доступа к обновлениям и техподдержке. Санкции против YADRO и других производителей сетевого оборудования усугубили проблему: даже если «железо» физически есть, его нельзя масштабировать без лицензий. Сложность в том, что технологический суверенитет нельзя купить — его нужно строить.

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

В 2025 году термин «импортозамещение» уже не вызывает иронии. Сегодня российский бизнес столкнулся с простым фактом: зарубежные SDN-решения либо недоступны, либо работают с перебоями.

Компании, которые в 2024-м надеялись на «серые» поставки VMware NSX, теперь тратят на 40% больше на поддержку устаревших версий.

Basis SDN — пока единственная рабочая альтернатива. Разработка «Базиса» и Angie Software изначально создавалась под санкционные реалии:

• полная независимость от зарубежного ПО — даже гипервизор работает на KVM;
• поддержка российского «железа» (YADRO, Aquarius) без необходимости доработок;
• цена ниже VMware NSX до его ухода с рынка.

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

Преимущества, которые оценит даже скептик

Рассмотрим подробно плюсы перехода на отечественные программно-определяемые сети.

Централизованное управление: оптимизация времени и расходов

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

Так работает Basis SDN:

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

Микросегментация: безопасность без головной боли

В 2025 году кибератаки стали точечными: злоумышленники не ломают всю сеть, а ищут слабые звенья — бухгалтерию, базы данных, IoT-устройства.

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

• финансовые системы можно отрезать от общего трафика, даже если они используют те же коммутаторы;
• доступ к данным регулируется не только логинами, но и контекстными правилами (например, запрет копирования файлов после 18:00);
• в случае атаки зараженный сегмент автоматически блокируется — без остановки всей сети.

Совместимость: работает здесь и сейчас

Типичная претензия к российскому ПО — «а вот у Cisco…». Но Basis SDN уже сегодня поддерживает:

• Astra Linux и «Альт» — без костылей в виде дополнительных драйверов;
• оборудование YADRO, БСТ, Aquarius — с гарантией обновлений;
• облачные платформы на базе KVM и отечественных гипервизоров.

При этом система не требует полного отказа от legacy-инфраструктуры. Например, можно оставить старые коммутаторы Cisco, но управлять ими через SDN-контроллер — это вдвое дешевле, чем менять все железо.

Рыночные перспективы: куда движется отрасль

Объем рынка SDN в России пока относительно невелик, но к 2031-му прогнозируют его рост до 32 млрд.

Основные драйверы:

• Госсектор: с 2024 года все госкомпании обязаны использовать «третьи ключи шифрования» — без SDN это нереализуемо.
• Телеком: Ростелеком и МТС тестируют SDN для 5G-сетей — ручное управление таким трафиком уже невозможно.
• Средний бизнес: облачные CRM и ERP требуют гибких сетей, а аренда VMware NSX теперь недоступна.

Вывод: свои SDN — это про выживание

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

При этом:

• Basis SDN — не идеален, но это практически единственное рабочее решение;
• без микросегментации скоро не получится пройти даже базовый аудит ФСТЭК;
• гибридные облака без SDN превращаются в кошмар админа.

Те, кто внедрит российские SDN сейчас, через 2–3 года получат снижение затрат на 25–40% по сравнению с теми, кто цепляется за «серые» Cisco и Huawei. Остальные рискуют остаться с сетью, которую некому и нечем администрировать.

Проблемы отечественных SDN: почему российские «сети из кода» пока не взлетели

Однако в 2025 году российские SDN-решения пока далеки от совершенства. Basis SDN от «Базиса» и аналоги от VK Tech («Спрут») — первые ласточки, но их внедрение сталкивается с тремя группами проблем: технологическими, экономическими и рыночными. Разберем каждую.

Технологические вызовы: когда железа много, а экспертов нет

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

Дефицит экспертизы. Для разработки конкурентоспособного SDN нужны специалисты высшего уровня, которых в РФ катастрофически не хватает.

Функциональные пробелы. Basis SDN декларирует 80% функционала VMware NSX, но критичные фичи вроде автономного восстановления после сбоев или глубокой аналитики трафика через ИИ появятся не раньше 2026 года. Для корпоративных клиентов это риск: например, без self-healing атака на один сегмент может парализовать всю сеть.

Совместимость с legacy-инфраструктурой. Большинство российских SDN работают с оборудованием YADRO, Aquarius или «Бифорком». Если у компании стоят старые Cisco или Huawei, миграция потребует полной замены «железа» — а это +30–50% к бюджету проекта.

Пример: В 2024 году Ростелеком-ЦОД пытался интегрировать Basis SDN с унаследованными коммутаторами Juniper. Проект забуксовал — пришлось докупать российские аналоги, что увеличило сроки внедрения на 4 месяца.

Экономические и регуляторные барьеры: санкции vs. окупаемость

Высокая стоимость разработки. Создание Basis SDN обошлось в сотни миллионов рублей. Для сравнения: бюджет VMware NSX превышает $1 млрд, но его распределяют на глобальный рынок. Российским вендорам приходится компенсировать затраты за счет узкой локальной аудитории.

Давление санкций. С июня 2024 года США запретили ИТ-консалтинг и облачные услуги для российских компаний. Это ударило по поддержке гибридных инфраструктур. Стало невозможно заказывать аудит сети у зарубежных вендоров, а облачные платформы вроде VMware Cloud Foundation недоступны даже через «серые» схемы.

Долгая окупаемость. По прогнозам «Базиса», Basis SDN окупится за 2–3 года. Но малый бизнес не готов ждать — ему нужны решения здесь и сейчас.

Рыночное недоверие: почему бизнес не верит в свои SDN

Культ «проверенных» зарубежных решений. Даже санкционные Cisco ACI и VMware NSX остаются в топе запросов у российских интеграторов.

Причины:

• Документация. У Cisco — 500+ страниц детальных мануалов, у Basis SDN — 80, и половина на уровне «как включить контроллер».
• Сообщество. Для VMware NSX есть 1000+ готовых скриптов на GitHub, для Basis SDN — меньше 50.

Низкая осведомленность малого бизнеса. Опрос бизнес-лаборатории «КРОК» показал: 60% компаний с оборотом до 1 млрд руб. считают SDN «дорогой игрушкой для корпораций». При этом они не знают, что микросегментация в Basis SDN снижает риски утечек на 40% — но об этом не пишут в СМИ.

Российские SDN не смогут конкурировать с зарубежными, пока:

• не сократится разрыв в экспертизе — нужны образовательные программы уровня Cisco Networking Academy;
• не появятся гарантии долгосрочной поддержки — например, госсубсидий на 5–10 лет;
• не изменится восприятие рынка — тут нужны кейсы уровня «Сбербанк полностью перешел на Basis SDN».

Сейчас Basis SDN остается нишевым продуктом для госсектора и Ростелекома.

Кейсы и перспективы: где российские SDN уже работают и куда движутся

В 2025 году российские SDN-решения перестали быть лабораторными проектами — они постепенно внедряются в реальную инфраструктуру. Но масштабы пока несопоставимы с зарубежными аналогами.

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

Basis SDN: первый крупный кейс — «Ростелеком-ЦОД»

В мае 2025 года «Базис» завершил пилотное внедрение своего SDN-решения в дата-центрах Ростелекома.

Проект показал:

• Сокращение времени настройки VLAN с 4 часов до 15 минут за счет централизованного управления.
• Микросегментация финансовых сервисов — изоляция платежных систем снизила риски атак на 40% по данным внутреннего аудита.
• Совместимость с оборудованием: 70% старых коммутаторов Cisco удалось интегрировать через шлюзы на базе KVM, хотя изначально Basis SDN разрабатывался для российского «железа» YADRO и Aquarius.

Потенциальные рынки: где российские SDN могут закрепиться

В июне 2025 года «Базис» анонсировал партнерство с телеком-оператором в ЮАР.

Причины интереса:

• Цена: $15 000 за контроллер против $30 000 у VMware NSX.
• Санкционная нейтральность: в Африке нет давления на использование российского ПО, а китайские аналоги (например, ZTE SDN) проигрывают в функционале.

Планируются поставки в Бразилию (интеграция с облачной платформой на базе OpenStack) и Казахстан (совместный проект с «Казтелеком»).

Согласно прогнозам, к 2031 году объем рынка SDN в РФ вырастет в 2-3 раза, но 80% спроса будет приходиться на госсектор и госкомпании.

Малый бизнес пока остается в стороне. Проблема в том, что Basis SDN ориентирован на крупные внедрения. Для малого бизнеса нет «облегченных» версий — аналогов Cisco ACI Essentials.

Рекомендации: как сделать российские SDN массовыми

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

Кадры — основа всего. Чтобы ускорить подготовку специалистов, нужно:

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

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

Госсектор стал основным драйвером спроса на отечественные SDN, но для массового внедрения нужны меры, стимулирующие переход коммерческих компаний. Опыт Китая показывает, что субсидии на 50% затрат при миграции с VMware/Cisco резко увеличивают долю локальных решений.

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

Одна из главных претензий к Basis SDN — слабая интеграция со сторонними платформами. Для сравнения: VMware NSX поддерживал свыше 200 приложений, а у российского аналога их на порядки меньше.

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

Итоги: отечественные SDN требуют долгосрочной стратегии

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

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

Жизнеспособность у проекта есть. Basis SDN закрывает 80% базовых потребностей бизнеса: микросегментация, централизованное управление, совместимость с российским «железом». Но критичные функции вроде автономного восстановления сетей появятся только к 2026 году.

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

Что может сделать каждый:

• Тестировать. «Базис» активно привлекает IT-комьюнити к доработке Basis SDN. Участие в пилотах — способ повлиять на развитие продукта.
• Развивать open-source. Проекты вроде OpenDaylight и OpenStack — основа для российских SDN. Чем больше контрибьюторов, тем быстрее сократится разрыв с зарубежными аналогами.
• Требовать документирования. Одна из главных претензий к Basis SDN — скудные мануалы. Если разработчики увидят запрос от сообщества на детальные гайды, они быстрее их выпустят

Главный вывод: SDN — не просто технология, а новая сетевая парадигма. Россия может занять в ней свое место, но для этого нужны не точечные успехи, а системные изменения.

Больше инфоповодов — в нашем тг-канале.

Почему «тормоза» — это не всегда про код

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

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

Вот что тормозит, когда код ни при чём:

Архитектура

• Цепочки вызовов: каждый хоп — +latency.
• Синхронные зависимости: завис один сервис — тормозят все.
• Общие ресурсы: shared state, глобальные очереди, блокировки.

Базы данных

• Нет индексов или плохой план запроса.
• N+1-запросы — особенно при неосторожной ORM.
• Частый доступ к одним таблицам — гонка за IO и блоки.
• Нет шардинга или репликации в масштабируемой нагрузке.

Сеть

• Высокая задержка между регионами (особенно multi-cloud).
• Потери пакетов, DNS-проблемы, нестабильность.
• Отсутствие connection reuse: TLS-handshake на каждый вызов.

Очереди и брокеры

• Один медленный потребитель тормозит всех.
• Нет защиты от от backpressure или дедупликации.
• Неправильные batch- и ack-настройки.

Аллокаторы и GC

• Фрагментация памяти, нагрузка на GC.
• Финалайзеры, слабые ссылки, плохо настроенный heap.

Конфигурации

• Маленький пул соединений — пул заканчивается, запросы ждут.
• Агрессивные retry-политики — система перегружается.
• CPU throttling в Kubernetes — контейнеру не хватает ресурсов.

Сериализация и форматы

• Перегруженные JSON/Protobuf.
• Вложенные base64 + gzip + JSON — боли сериализации.

Почему bottlenecks остаются невидимыми до продакшена

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

• мало данных,
• нет конкуренции за ресурсы,
• нет распределённой нагрузки.

В проде начинается хаос. Рассмотрим на конкретных примерах:

• На деве — 2 запроса в секунду, в проде — миллион. Кто-то запустил маркетинговую рассылку, аналитик тащит big report, а клиент ретраит ошибки.
• Архитектура «в лоб»: всё синхронно, каждый сервис вызывает по цепочке десяток других. Пока нагрузка мала — все живет. Как только одно звено не выдерживает — перестает жить.
• Иллюзия масштабируемости: до 100 пользователей — всё окей, на 1000 — каскадная деградация.
• «Невидимая боль» между сервисами: каждый по отдельности быстрый, но блокирует друг друга на базе.

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

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

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

На уровне клиента

• Тяжёлые бандлы. Огромный JS, куча аналитики, трекеры — и вот страница загружается 8 секунд на старом телефоне.

• Чрезмерные запросы. После загрузки — 10 fetch в секунду. API захлёбывается, браузер — тоже.

• Нет кеша. Даже статичные справочники каждый раз грузятся заново.

• Лаги рендеринга. Бэкенд дал ответ за 100ms, но интерфейс лагает — сложные таблицы, графики, reflow.

На уровне API Gateway / BFF

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

На уровне Backend / бизнес-логики

• Цепочки вызовов. Один сервис вызывает другой, тот — ещё один… И так далее.
• Ограниченный пул соединений — сервис готов работать, но все worker-ы ждут ресурсы.
• Логика в цикле по данным — N+1-запросы, сериализация, дублирование работы.

На уровне базы данных / кэша

• Full table scan. Работает быстро на 1000 строках. Умирает на 10 миллионах.

• Локи и гонка за ресурсы. Один UPDATE лочит строку, остальные ждут.

• Кэш не промахивается, но и не помогает — stale данные, повторные чтения, инвалидация не работают, как ожидалось.

На уровне внешних сервисов (API, брокеры, платёжки)

• Без timeout и fallback. Внешний API залип — вы вместе с ним.
• QPS-лимиты. Вы не знали, а вас уже зарейт-лимитили.
• Нестабильная сеть. DNS тормозит, соединения рвутся, задержки скачут между регионами.

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

Есть архитектурные паттерны риска, которые часто приводят к тормозам через полгода. Во-первых, общий ресурс на всех: один Redis, один Kafka-топик, одна таблица. Пока нагрузка маленькая — ок. Потом начинается бойня за доступ. Во-вторых, микросервисный монолит: формально разделены, но живут как один. Масштабировать невозможно. В-третьих, цепочки вызовов: 5–6 сервисов на путь одного запроса. Один подвис — и вся цепочка тормозит.

Базы данных: когда даже SELECT тормозит всё

В бэкенде одна из самых коварных фраз — «ну это же просто SELECT, что с ним будет». Ответ — сначала ничего. Но со временем появляется 10 миллионов строк, и ваш innocuous SELECT превращается в full scan, который лочит диск, ест CPU и тормозит всё, что движется.

Типичная ситуация: в таблицу пишут JSONB без нормализации и индексов. Пока строк мало — жить можно. Но при росте объёмов каждый запрос превращается в медленное последовательное чтение. Это не просто «долго», а начинает мешать соседним транзакциям: подгружаются stale данные, вытесняется кэш, система начинает проседать вся — вплоть до API.

Отдельная ловушка — смешение OLTP и OLAP нагрузки. Днём — INSERT и UPDATE от клиентов, ночью — фоновая аналитика, высчитывающая отчёт за год с десятком JOIN и чтением всей таблицы. Если все запросы идут в один инстанс, происходит конкуренция за ресурсы: аналитика сбивает кеш, вызывает блокировки, а продакшн-метрики начинают сыпаться.

Как понять, что тормоза идут из базы, а не из бэкенда?

Вот несколько типичных признаков:

• Бэкенд «висит» на запросах к базе — в логах видно, что приложение ждёт результат запроса (долгий await, query(), findMany() и т. д.).

• Latency растёт, а CPU и память в норме — сервис сам по себе не перегружен, но ответ приходит медленно.

• В базе фиксируются медленные запросы — например, SELECT или JOIN занимают секунды, хотя раньше проходили за миллисекунды.

Чтобы подтвердить гипотезу, можно:

• Включить логирование SQL-запросов с таймингом;
• Посмотреть трейс: если шаг DB заметно длиннее остальных — это тревожный сигнал;
• Запустить EXPLAIN ANALYZE на типовые запросы и проверить, где зарыта сложность.

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

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

На что здесь стоит обратить внимание:

• Количество и характер обращений. Один пользовательский запрос не должен порождать десятки обращений к базе. Планирование кэшей, агрегаций, prefetch, нормализация — всё это часть архитектуры.
• Уровень абстракции над данными. ORM может быть удобным, но часто скрывает десятки неэффективных SELECT’ов. Нужно понимать, какие запросы реально идут в базу, и не превращать каждый use case в потенциальный bottleneck.
• Стратегия хранения и агрегаций. Если вы пытаетесь на лету агрегировать 100 миллионов строк без шардинга и партиционирования — тормоза неизбежны. Архитектура должна учитывать нагрузку, частоту агрегаций, структуру данных.

Очереди и событийные системы: скрытые замедления

Событийные архитектуры и очереди вроде Kafka или RabbitMQ часто воспринимаются как универсальное средство от всех проблем: «Сделаем асинхронно — и всё полетит». Но это не серебряная пуля. Очередь не решает проблему — она её откладывает. А иногда сама становится bottleneck’ом.

Типовые ситуации, когда очередь тормозит систему:

• Медленные консьюмеры. Очередь принимает сообщения с высокой скоростью, но обработчики не успевают, и начинается накопление беклога. В результате задержки накапливаются, SLA летит, а вы только недоумеваете, почему всё так тормозит.
• Неправильный размер batch’ей. В Kafka и аналогах размер и частота batch'ей критичны. Слишком большие — ждём, пока соберётся партия. Слишком маленькие — тратим ресурсы на лишнюю загрузку и пересылку. В итоге получаем либо высокую задержку, либо низкую производительность.
• Неравномерное партиционирование. Если сообщения распределяются по партициям неравномерно, то часть узлов будет простаивать, а часть захлёбываться под нагрузкой. Одна горячая партиция может стать bottleneck’ом всей системы.
• Проблемы с retry. Если нет чёткой стратегии повторных попыток, логирования и DLQ (dead-letter queue), битое событие может крутиться в системе бесконечно, тормозя всё остальное. Также если что-то пошло не так и включились retry-механизмы, задержка может вырасти в разы. Особенно если есть backoff или дедлоки.

Почему «асинхронно» ≠ «мгновенно»

Асинхронность — это не про скорость, а про отложенность. Событие отправлено — но когда оно будет обработано, никто не знает. Через секунду, через минуту, через час?

Типичные причины задержек в асинхронной обработке:

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

Что происходит, когда очередь переполнена — и почему это тяжело заметить

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

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

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

• Глубина очереди (в Kafka — consumer lag, в RabbitMQ — queue.messages_ready или queue.messages): показывает, сколько сообщений накопилось и ждёт обработки.
• Publish rate: сколько сообщений в секунду публикуется.
• Processing rate: сколько сообщений в секунду обрабатывается.
• Утилизация ресурсов воркеров (CPU, memory, I/O).
• End-to-end latency: сколько времени проходит от публикации события до его обработки.

Есть самые частые причины накопления сообщений:

1) Медленные потребители, которые не успевают обработать весь поток сообщений.
2) Шумная архитектура: 10 сообщений там, где можно было обойтись и одним.
3) Неправильное масштабирование брокера (например, неправильно выбранный ключ партиционирования в Kafka).

API и микросервисы: где тормозит взаимодействие

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

Что тормозит в микросервисах?

Много лишних вызовов

Один пользовательский запрос вызывает лавину внутренних HTTP/gRPC-запросов. Каждый из них — это:

• сетевые задержки (latency),
• сериализация/десериализация данных,
• ретраи при сбоях,
• риск таймаутов и обрывов.

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

Цепочка зависимостей

Классика жанра: заказ зависит от оплаты, оплата — от биллинга, биллинг — ещё от трёх микросервисов.

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

Нет fallback'а и таймаутов

Если вызов к нужному сервису не отвечает, а у вас нет fallback'а или таймаута — всё встаёт. Особенно плохо, если вызов синхронный и блокирует поток.

Наносервисы

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

Вместо бизнес-логики система начинает заниматься оркестрацией — координирует сама себя.

Кэш и CDN: почему «ускорители» тоже могут тормозить

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

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

Невалидные или слишком агрессивные стратегии

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

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

Перегрузка кэша

Когда кэш настолько загружен, что сам по себе начинает тормозить — это уже не помощь, а вред. Такое часто случается с Redis, Memcached или in-memory решениями, особенно если они:

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

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

Кэш-миссы и лавины запросов

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

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

Несогласованность кэшей

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

Вычисления и память: что не так с аллокацией

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

Частые и крупные аллокации

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

Сборка мусора — это не бесплатная операция: она останавливает выполнение программы. Частые GC-паузы создают «плавающую» производительность, когда всё работает быстро, но время от времени подвисает даже на секунду.

GC-паузы

Автоматическое управление памятью — благо, но оно же и ловушка. В языках вроде Go, Java или Python невозможно точно контролировать, когда сработает сборщик. Даже задержка в 50 миллисекунд может ощутимо ударить по RPS или нарушить real-time обработку.

Некоторые компании придумывают обходные пути. Так, в Twitch использовали технику memory ballast для Go-приложений, чтобы стабилизировать поведение GC и избежать всплесков пауз.

Синхронные и блокирующие операции

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

Классический пример — однопоточный web-сервер, который просто ждёт ответ от другой системы. Или библиотека, использующая mutex.Lock() в горячем участке, из-за чего десятки горутин встают в очередь.

Ограниченные ресурсы и очереди

Даже в многопоточном приложении можно легко создать узкое место. Например:

• доступ к объекту синхронизирован через mutex или RW-lock;

• пул соединений имеет жёсткий лимит;

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

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

Однопоточные горячие участки

Даже в многопоточной архитектуре может оказаться, что 80% времени тратится в одном месте, которое не масштабируется — например, в процессе сериализации, расчёта или шифрования. Иногда этот участок реализован однопоточно (особенно в Node.js, Python или старом Go-коде) и становится главным тормозом системы. Под высокой нагрузкой это становится особенно заметно.

Что делать: подход к поиску и устранению bottlenecks

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

Шаг 1. Зафиксировать симптомы и контекст

Важно понять, что именно «тормозит» и в каких условиях. Типовые вопросы:

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

Пример: пользователи жалуются, что отчёты стали строиться дольше. Вчера — 5 секунд, сегодня — 20.

Шаг 2. Проверить очевидные метрики

Начинаем с того, что уже доступно в мониторинге:

• латентность API (p50, p95, p99);
• загрузка CPU, использование памяти и диска;
• глубина очередей и backlog;
• паузы GC;
• кэш hit/miss ratio.

Если латентность растёт, а CPU загружен на 20%, это может указывать на проблемы в синхронных вызовах, аллокации или неэффективной работе кэша.

Шаг 3. Сузить область через трейсинг и логирование

Чтобы выяснить, не «тормозит» ли другой сервис, используйте распределённый трейсинг (Jaeger, OpenTelemetry, Sentry Performance) или логирование таймингов внутри запроса.

Пример (Go, обёртка для http.RoundTripper):

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

Шаг 4. Воспроизвести нагрузку

Если проблема зависит от объёма данных, воспроизведите реальный сценарий или нагрузку:

• используйте инструменты вроде k6, Locust, Artillery;
• проверьте реальные условия (например, отчёт за 30 дней, а не за 3).

Если латентность растёт нелинейно, это может быть признаком N+1-запросов, неоптимального SQL или проблем с аллокацией.

Шаг 5. Подтвердить проблему профилированием

Если есть подозрение на перегрузку CPU или утечку памяти, используйте профилировщики:

• Go — pprof;

• Java — JFR, VisualVM;

• Node.js — clinic.js, chrome://inspect.

Пример (Go, локальный pprof):

Профиль покажет, где тратится CPU, как распределяются аллокации, как часто запускается GC и в каком коде.

Шаг 6. Оптимизировать, перепроверить и зафиксировать

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

• кэшировать внешний вызов;

• заменить тяжёлую сериализацию (например, на easyjson в Go);

• убрать блокирующую операцию;

• перейти на batch-обработку.

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

Итоги: как не попасть в архитектурную ловушку

Bottleneck’и возникают даже в самых технологичных проектах. Это не всегда следствие «плохого кода» — куда чаще они появляются из-за архитектурных просчётов: недооценили нагрузку, не предусмотрели масштабирование, сделали ставку на неправильное решение.

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

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

Думайте об объёмах и росте

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

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

Без данных вы работаете вслепую. Любой анализ будет превращаться в гадание: виноват код или Redis, где тормозит — непонятно. С самого начала следите за ключевыми метриками: latency, очереди, GC, hit/miss в кэше, ошибки. Это не «доработка потом», а часть живой системы.

Проектируйте с учётом деградации

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

Не усложняйте архитектуру без повода

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

Bottleneck’и — это не баг, а симптом. И хороший архитектор — это не тот, кто устраняет тормоза, а тот, кто их не допускает.

Больше боли коддеров — тут.

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

Любая работающая сложная система неизменно оказывается производной простой работающей системы.

Позволю себе внести важные уточнения.

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

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

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

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

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

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

• Выбор технологии на основе только её популярности. («Так принято в лучших домах!», «Kafka справится с любой задачей» и т.п.)
• Ориентация на скорость, обоснованная амбициями или ощущениями. («Некогда думать — надо действовать!», «Мир сам себя не захватит!»)
• Неоправданное и/или преждевременное усложнение. («У меня нет задач, нужно придумать что-то интересненькое», «У меня скучные задачи, нужно добавить драйва», «Я предусмотрел обработчик на случай вторжения инопланетян!» и т.п.)
• Неоправданное расширение технологического стека. («CV-Driving Development», «Решил попробовать», «Мне так удобней» и т.п.)

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

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

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

P.s. Если вам интересна данная тематика, присоединяйтесь к моей новостной ленте в Telegram или здесь. Буду рад поделиться опытом. 😉

Монолитная архитектура

Исходная схема:

• Backend: Spring Boot
• Frontend: Angular

Так как у меня уже был арендованный VDS, я зарегистрировал домен у одного известного провайдера, а хостил сайт уже на VDS сервере. Для простоты интегрировал Angular-сборку в Spring Boot как статику через frontend-maven-plugin. Всё собиралось в один JAR. Почему так? Ранее уже был такой опыт, и я решил пойти этим путем.

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

• Отсутствие SSR в Angular негативно влияло на SEO;
• Ошибка в Angular ломала Maven-сборку;
• Сложно поддерживать и масштабировать.

Переход на микросервисы

Было принято решение разделить фронтенд и бэкенд на отдельные сервисы и использовать микросервисный подход с SSR для Angular:

Новая структура:

• Backend: Spring Boot
• Frontend: Angular Universal (SSR)
• Инфраструктура: Docker Compose, Nginx, HTTPS

Docker, Nginx и запуск

Создана базовая структура docker-compose.yml:

И соответствующий Nginx:

После запуска проект открывался по IP, но появилось множество проблем:

• Дублирование API-префиксов: /api/api/endpoint → Решение: корректировка proxy_pass и URL в Angular
• Редиректы на POST: Spring добавлял лишние слеши → Решение: правильные аннотации и настройка Nginx
• 405 Method Not Allowed → Решение: использовать @PostMapping
• Docker-сети → Решение: задать общую сеть в docker-compose.yml

Безопасность: HTTPS, SSL, CORS

Чтобы сайт открывался по имени с панели провайдера для моего домена, значения DNS-сервера оставил без изменений (провайдер предоставляет их бесплатно), а для ресурсной записи @ и www указал ip адрес своего хостинга. Так как провайдер домена бесплатно предоставил SSL-сертификаты (Let's Encrypt), то как я их интегрировал:

Скачал с панели провайдера и перенес на хостинг такие файлы:

domain.crt — сертификат

domain.key — приватный ключ

ca_bundle.crt — цепочка доверия

Добавил в Nginx такую запись для HTTPS:

Но при обращении к сайту по https конечно же возникли ошибки. А именно: в логах Nginx были ошибки на SSL_CTX_use_PrivateKey_file. Оказалось формат был PKCS#7, а требовался PEM. Конвертировал через OpenSSL:

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

К тому же всегда следует проверять логи Nginx (error.log), там могут находится ответы на вопросы, почему сайт не работает.

На стороне Spring Boot были CORS-проблемы, решено так:

Атаки ботов и защита

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

45.155.205.213 - - [01/Jan/2023:04:12:11 +0000] "GET /wp-login.php HTTP/1.1" 404 153

Добавлен фильтр в nginx.conf:

Финальная конфигурация

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

docker-compose.yml

nginx.conf

Dockerfile backend

Dockerfile frontend

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

Когда бизнес затребовал систему для обработки транзакций в реальном времени с пиковой нагрузкой в 50 тысяч операций в секунду, я понял, что серые будни enterprise инженера наконец станут весельем. Наш сервис должен был не просто работать — он должен был дышать под давлением, сохраняя отклик в пределах 10 мс. Не все проблемы в мире можно решить горизонтальным масштабированием, и одним из камней преткновения стала Java, а точнее — её «мусор».

Выбор GC: G1, Shenandoah или ZGC?

Первое, с чем столкнулась наша команда, — продолжительные STW-прерывания при нагрузке. Изначально использовали G1GC как «дефолтный» выбор для баланса между latency и throughput. Но под нагрузкой 80% CPU даже G1 не справлялся: пиковые паузы достигали 400 мс, что для платежей было неприемлемо.

Мы устроили мозговой штурм с performance-инженерами. Варианты:

1. Shenandoah — низкие паузы, но требуется больше CPU.

2. ZGC — субмиллисекундные паузы даже на терабайтных хипах, но тогда (на старте проекта) он был экспериментальным в OpenJDK 11.

3. Ручная настройка G1 — максимизировать предсказуемость через MaxGCPauseMillis и InitiatingHeapOccupancyPercen.

После недели тестов на стенде с имитацией пиковой нагрузки (JMeter + Gatling) и профилирования через async-profiler, выбор пал на ZGC. Его паузы не превышали 2 мс даже при 32 ГБ куче, а алгоритм «цветных указателей» позволял масштабироваться без блокировок. Риск? Да. ZGC был новым, но его поддержка в последних LTS-версиях и тесты убедили нас.

Тонкая настройка и проклятие «тихих» утечек

С ZGC мы выставили:

1. -Xmx48g (с запасом для избежания частых аллокаций),

2. -XX:SoftMaxHeapSize=40g (чтобы ZGC активнее возвращал память ОС),

3. -XX:+UseLargePages (снижение overhead на page faults).

Но через месяц нагрузочного тестирования обнаружили «ползучее» увеличение потребления памяти. Performance-команда, анализируя дампы через Eclipse MAT, нашла проблему: кэш данных транзакций в Apache Ignite не учитывал soft-ссылки, накапливая объекты. Вместо ConcurrentHashMap перешли на `Caffeine` с политикой expiry после 10 секунд, что снизило давление на GC.

Команда performance-инженеров: алхимики метрик

Работа с perfomance-инженерами напоминала лабораторию безумных ученых. Каждый параметр JVM, каждый HTTP-эндпоинт тестировался через JMH, а Grafana-дашборды визуализировали следующее:

1. GC pauses (ZGC собирал статистику через -Xlog:gc*),

2. Allocation rate (до 1.5 ГБ/сек в пиках),

3. CPU utilization (наши самописные RateLimiter’ы съедали 15% ресурсов).

Совместно мы написали скрипты на Python, которые автоматически подбирали -XX:ConcGCThreads и -XX:ParallelGCThreads в зависимости от нагрузки на CI/CD стендах. Это сократило время настройки на 70%.

Продакшн: огненное крещение

После релиза первые дни мы мониторили всё: New Relic для трейсинга медленных методов, Prometheus для сбора JVM-метрик. ZGC не подвел — 99-й перцентиль отклика оставался на уровне 12 мс. Но однажды ночью мы получили алерты по потреблению CPU. Оказалось, фоновый процесс генерации отчетов создавал миллионы временных объектов. Решение: выделили его в отдельный микросервис с выделенным пулом памяти и CMS (ему хватало).

Итоги

Через полгода система обрабатывала 55k операций/сек с пиковыми паузами GC в 1.8 мс. Главные уроки:

1. GC — не серебряная пуля. Даже ZGC требует понимания аллокаций в коде.

2. Performance-инженеры — ваши лучшие союзники. Их взгляд со стороны JVM спас нас десятки раз.

3. Документировать всё. Наши конфиги и скрипты настройки GC стали стандартом для других команд банка.

Теперь, когда я вижу, как сервис работает без перебоев, вспоминаю те бессонные недели с дампами и тестами… и понимаю: это того стоило. Ведь в мире highload каждая миллисекунда — это деньги. Или, как говорят у нас в банке, «миллисекунда — миллион».

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

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

Носители информации: эволюция

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

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

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

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

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

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

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

Затем пришли дискеты, и мир узнал, что такое «портативность» в цифровом смысле. Если кассеты были еще слегка похожи на предыдущее поколение (массивные бобины), то флоппи-диски уже вполне выглядели как технология из будущего. Первые модели хранили жалкие 80 КБ, но к 1980-м емкость выросла до 1.44 МБ — достаточно для текстовых документов и простейших программ. Правда, надежность оставляла желать лучшего: магнитные диски боялись пыли, влаги и просто времени.

Оптические носители, такие как CD и DVD, стали следующим шагом. Они предлагали куда больший объем (от 700 МБ до 4.7 ГБ) и теоретически — вечное хранение данных. Правда, на практике царапины, солнечный свет и некачественные болванки приводили к быстрому обнулению файлов. Но главный минус — эти диски нельзя было просто так перезаписать. CD-RW и DVD-RW решили проблему, но их распространение было медленным: люди уже начали привыкать к тому, что данные можно копировать бесконечно.

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

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

Как хранили и передавали информацию до флешек и облаков

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

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

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

Магнитная лента появилась задолго до кассет — первые бобинные магнитофоны использовались еще в 1940-х, но они были громоздкими и дорогими. Все изменилось в 1963 году, когда компания Philips представила компакт-кассету — небольшой, удобный и, что важно, дешевый формат. В отличие от винила, кассеты можно было записывать повторно, носить с собой и даже ронять без катастрофических последствий.

К 80-м годам кассеты стали основным способом слушать музыку. Их продажи в США достигли пика в 442 миллиона штук в 1990 году, но затем началось стремительное падение — CD-диски предлагали лучшее качество звука и отсутствие изматывающей перемотки. Однако кассеты не исчезли полностью: даже в 2012 году в Штатах продали 13 миллионов штук, в основном благодаря автолюбителям, чьи старые машины были оборудованы кассетными магнитолами. В России формат держался примерно до середины 2000-х, после чего кассеты почти исчезли из обихода.

Пока аудиокассеты правили балом в музыке, VHS делал то же самое с видео. Этот формат, появившийся в 1970-х, быстро вытеснил конкурентов (например, Betamax от Sony) благодаря простоте и доступности. Видеомагнитофон стал почти обязательным устройством в каждом доме, а прокат кассет — целой индустрией.

Но у VHS были свои причуды:

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

Несмотря на это, VHS формат продержался до начала 2000-х, пока его не вытеснили DVD, а затем и стриминговые сервисы.

Магнитная лента использовалась не только для музыки и фильмов — в 1980-х она стала первым массовым носителем данных для домашних компьютеров. Владельцы ZX Spectrum и Commodore 64 загружали программы с аудиокассет, подключив магнитофон к компьютеру. Процесс напоминал шаманский ритуал: нужно было выставить правильный уровень громкости, надеяться, что маг не зажует ленту, и ждать несколько минут, пока игра загрузится (если, конечно, в середине не возникала ошибка, заставляющая начинать все сначала).

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

Казалось бы, эпоха магнитной ленты бесповоротно миновала, но это не совсем так. В дата-центрах до сих пор используют ленточные библиотеки (например, LTO), потому что они дешевы, энергоэффективны и отлично подходят для долгосрочного хранения больших объемов данных. Современные картриджи LTO-9 вмещают до 45 ТБ информации — это в тысячи раз больше, чем могла предложить кассета 1980-х.

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

Флоппи-диски (дискеты): 1,4 Мб славы

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

Флоппи-диски, или просто дискеты, стали символом компьютерной революции 1980-1990-х: они были везде, их боялись потерять, ими обменивались, как сейчас ссылками, и их регулярно проклинали, когда на экране возникало сообщение «Диск не отформатирован».

Первая дискета, представленная IBM в 1971 году, была 8-дюймовой и вмещала смехотворные по современным меркам 80 КБ данных. Она создавалась как альтернатива перфокартам — более надежная и удобная, но по-прежнему громоздкая. К середине 1980-х индустрия перешла на 5,25-дюймовые гибкие диски, а затем и на 3,5-дюймовые, которые стали стандартом. Последние, кстати, были не такими уж «гибкими» — прочный пластиковый корпус защищал магнитный диск внутри, хотя слово «флоппи» (от английского floppy — «гибкий») так и осталось в названии.

Объем памяти рос медленно: если в 1984 году дискета на 3,5 дюйма хранила 720 КБ, то к 1987-му — уже 1,44 МБ. Этого хватало для текстовых документов, простых программ и даже некоторых игр. Microsoft Word 2.0, выпущенный в 1991 году, умещался на одной дискете, а его современный аналог требует около 4 ГБ — в 3000 раз больше.

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

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

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

Любопытно, что следы дискетной эпохи до сих пор встречаются в цифровом мире. Буква «A:\» в Windows, которая изначально обозначала дисковод, осталась в системе как дань традиции. Иконка «Сохранить» во многих программах до сих пор изображает флоппи-диск, хотя большинство современных пользователей и в руках-то его никогда не держали.

К началу 2000-х дискеты начали стремительно исчезать. В 2011 году компания Sony, последний крупный производитель, прекратила их выпуск. Но, как это часто бывает, технология не умерла полностью.

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

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

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

Сиди и Дивиди: эпоха лазерного ренессанса

В конце 1990-х дискеты уже выглядели архаично, а облачных хранилищ еще не существовало. На сцену вышли оптические диски — сначала скромные CD на 700 МБ, после — DVD на 4,7 ГБ, а затем и Blu-ray с их 50 ГБ. В определенный период записать фильм на болванку считалось технологическим подвигом. Нужно было также красиво написать название на внешней стороне специальным маркером.

Изначально компакт-диски создавались для музыки — первый коммерческий CD выпустили в 1982 году с записью альбома ABBA «The Visitors». Объем в 650 МБ (74 минуты аудио) выбрали не случайно: разработчики из Sony и Philips хотели, чтобы на один диск целиком поместилась Девятая симфония Бетховена. К концу восьмидесятых большинство звукозаписывающих компаний перешли на CD-формат.

Когда технологию адаптировали для компьютеров (CD-ROM), эти же 700 МБ стали стандартом для софта, игр и даже операционных систем, например, Windows 95.

Запись CD представляла собой сложную процедуру . Программа Nero Burning ROM с ее интерфейсом, напоминающим кабину пилота, требовала идеально настроенного буфера записи. Ошибка «Buffer underrun» означала, что диск испорчен, а 30-50 рублей за болванку (по меркам 2000-х — немалая сумма) летели в мусорку.

Когда в 1996 году появились DVD, их емкость в 4,7 ГБ казалась фантастической. Почему не 5? Все просто: инженеры Sony и Philips изначально планировали 5 ГБ, но пришлось пожертвовать частью объема ради совместимости с форматом CD. Впрочем, даже 4,7 ГБ хватало для фильмов в приличном качестве — пиратские копии расходились быстрее, чем студии успевали считать убытки.

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

В середине 2000-х разгорелась война форматов высокой четкости: Blu-ray от Sony и HD DVD от Toshiba. Технически Blu-ray был лучше — большая емкость (50 ГБ против 30 ГБ у HD DVD), но исход противостояния решил не этот фактор. Sony, которая владела киностудией Columbia Pictures, обеспечила Blu-ray эксклюзивными релизами. А когда за синий формат неожиданно выступила индустрия фильмов для взрослых (на тот момент — один из главных драйверов продаж любых носителей), судьба HD DVD была предрешена.

К 2010-м оптические диски начали сдавать позиции. Скорость интернета росла, стриминговые сервисы набирали популярность, а производители ноутбуков массово отказывались от дисководов. Последний гвоздь в крышку гроба забила Apple, выпустив в 2012 году MacBook Pro без CD-привода — тогда это казалось смелым шагом, а сегодня воспринимается как норма.

Но диски не исчезли полностью. Blu-ray до сих пор используют для фильмов в 4К, а некоторые госструктуры предпочитают архивные DVD — они дешевы и, в отличие от флешек, не подвержены спонтанному размагничиванию. Да и любители ретро-техники продолжают охотиться за редкими релизами игр на CD — например, оригинальная Half-Life на диске сегодня стоит дороже, чем в Steam.

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

Почему все это исчезло

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

Три причины краха:

• Первая и главная — объем. В 1990-х 1,44 МБ дискеты хватало для текстовых документов, но уже к началу 2000-х этого было недостаточно даже для одной MP3-песни. CD на 700 МБ казались спасением, но и они быстро устарели, когда размеры софта перевалили за гигабайты. Современные игры и видеофайлы просто не поместились бы на десятках дисков, которые пришлось бы таскать с собой.
• Вторая причина — скорость. Загрузка программы с кассеты занимала минуты, запись DVD — десятки минут, а копирование файлов с дискеты напоминало медитацию. Когда на смену пришли USB-накопители с их мгновенным доступом к данным, терпеть эти задержки стало невозможно.
• Наконец, надежность. Магнитные ленты размагничивались, дискеты боялись кофе и магнитов, а царапины на CD превращали их в елочные украшения. Потерять данные было проще, чем сохранить — особенно если учесть, что резервные копии требовали такого же ненадежного носителя.

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

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

Что мы потеряли и что приобрели

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

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

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

Флешки, SD-карты и облака: вы находитесь здесь — что дальше

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

Твердотельные накопители, основанные на кремниевых чипах, приближаются к физическим пределам. Производители научились упаковывать данные невероятно плотно — современные 3D NAND-чипы содержат до 200 слоев памяти. Однако закон Мура (формулирующий неизбежность технологического прогресса) хотя и универсален, имеет определенные физические ограничения: стоимость новых фабрик по производству микросхем измеряется десятками миллиардов долларов.

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

Будущее, которое уже тестируют в лабораториях:

• ДНК-хранилища. В 2017 году гарвардские ученые записали на ДНК кишечной палочки GIF-анимацию и изображение. Технология CRISPR позволяет редактировать геном, превращая его в биологический жесткий диск. Пока процесс дорогой и медленный, но потенциал огромен: один грамм ДНК может хранить 215 петабайт данных — эквивалент 14 тысяч современных SSD.
• Молекулярные диски. Исследователи из Университета Брауна (Провиденс, США) создали прототип накопителя, где информация кодируется органическими молекулами. Метод напоминает древние глиняные таблички, только вместо клинописи — бинарный код из присутствия или отсутствия конкретных молекул.
• Кварцевые кристаллы. Технология «5D-памяти» использует фемтосекундные лазеры для записи данных в кварцевое стекло. Такие носители выдерживают температуру до 1000°C и могут хранить информацию миллиарды лет. В 2018 году Илон Маск отправил в космос Tesla с кварцевым диском, содержащим трилогию А. Азимова «Основание».
• Арктические архивы. На Шпицбергене уже работает «Арктический мировой архив», где данные хранятся на специальной пленке в стальных контейнерах. Туда поместили исходники GitHub, цифровое искусство и даже конституции некоторых стран — на случай глобальной катастрофы.

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

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

Основные инструменты и технологии

Статьи, с которых стоит начать, если хочется обновить стек или разобраться в новых подходах:

ТОП 60 лучших инструментов для разработки ПО в 2025 — Собрали шестьдесят лучших инструментов для разработки программного обеспечения в 2025 году. От трекеров и редакторов до библиотек и фреймворков.

Топ 11 трендов, которые нужны айтишнику в 2025 году — Представляем одиннадцать ключевых трендов в IT, которые будут актуальны в 2025 году. Краткий гид по технологиям, которые будут на слуху.

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

Инструменты и фреймворки QA, которые (не) нужно знать — о том, что реально используется в тестировании.

Что изучать начинающему разработчику на C# — рассматриваем языки, среды и подходы, которые пригодятся новичкам. Рекомендуем, с чего начать изучение C# и какие темы освоить в первую очередь.

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

Базы, API, DevOps и CI/CD

Набор инструментов и практик, которые помогут масштабироваться и не выгорать:

Топ-10 инструментов DevOps, которые упростят вашу жизнь и избавят от ночных релизов — must-have решения для DevOps-команд.

PostgreSQL vs. ClickHouse vs. DuckDB: какую опенсорс базу выбрать для аналитики в 2025 году? — Сравниваем три популярные опенсорс СУБД для аналитики: возможности, производительность и кейсы использования.

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

Разворачиваем инструменты CI/CD: практики от DevOps-инженеров — Делимся практическими советами по развертыванию инструментов CI/CD от профессионалов.

Как автоматизировать простые задачи с помощью скриптов? — Гайд по быстрой автоматизации без боли.

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

AI-инструменты и нейросети

Что может помочь вам уже сейчас — от подсказок до генерации кода:

Топ-5 ИИ-инструментов для программистов в 2025 году — Самые полезные AI-ассистенты по мнению редакции.

DeepSeek или Claude: какая нейросеть напишет код, за который не стыдно? — Сравниваем возможности нейросетей DeepSeek и Claude в контексте генерации качественного кода.

Edge AI: как работают нейросети на устройствах с ограниченными ресурсами — Объясняем, как нейросети работают на устройствах с ограниченными ресурсами и где это применимо.

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

Утилиты, лайфхаки и неожиданно полезные штуки

То, что экономит время, силы и нервы:

11 сайтов, экономящих время, которые нужны каждому разработчику — Подборка must-have ресурсов.

7 библиотек для анимаций на React — Обзор популярных библиотек для создания анимаций в React: от простых эффектов до сложных переходов.

30 самых полезных библиотек Python для веб-разработки в 2024 году — Подборка тридцати полезных библиотек Python, которые пригодятся веб-разработчикам в 2025 году.

7 программ для шифрования данных — Базовая кибер-гигиена для всех, кто работает с пользовательскими данными.

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

5 ETL для обработки данных из Python-ботов — Представляем пять ETL-инструментов, которые помогут автоматизировать сбор, трансформацию и загрузку данных от Python-ботов

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

Немного философии

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

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

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

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

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

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Но правда в том, что это решение подходит далеко не всем компаниям. В 90% ситуаций микросервисная архитектура (она же MSA) — избыточность, а не необходимость. Это не просто сложно, а очень сложно. Микросервисы требуют мощной инфраструктуры, глубоких знаний DevOps, тонкой настройки мониторинга и отказоустойчивости. И самое главное — они редко нужны на старте проекта.

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

Почему все говорят про микросервисы

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

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

Маркетинг на волне хайпа

Разработчики инструментов в этой сфере хорошо зарабатывают на своих продуктах.

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

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

Ориентированность на резюме

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

Это создает порочный круг:

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

Факт. Несмотря на универсальность микросервисов, далеко не все гиганты перешли на такой формат работы. Например, GitLab и Spotify до сих пор работают на монолитах.

Завышенные ожидания по проекту

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

Что происходит на практике:

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

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

Нужны ли вашему проекту микросервисы

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

Чтобы понять, стоит ли внедрять в ваш проект микросервисы, ответьте на три важных вопроса.

Действительно ли ваш проект настолько масштабен?

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

Сразу проверьте себя:

• Если ваш сервис — это один API, который обслуживает 5 конечных адресов, микросервисы вам не нужны.
• Если вы не можете четко объяснить, какие части системы могут жить автономно (например, платежи без каталога товаров), значит, у вас монолит. И это нормально.

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

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

Действительно ли вам необходимо масштабировать части приложения автономно?

Типичный аргумент за микросервисы: «У нас нагрузка только на платежи, а не на каталог — выгодно масштабировать их по отдельности». На самом деле 99% стартапов никогда не сталкиваются с такой нагрузкой, где это критично. Кроме того, современные облака (AWS, GCP) умеют масштабировать отдельные модули монолита.

Пример. Команда разбила HR-систему на 10 микросервисов. В итоге форма подачи заявок зависела от сервиса сотрудников, который в свою очередь зависел от сервиса отделов. При пиковой нагрузке (раз в месяц) все равно масштабировали все сервисы сразу.

Если вы не Amazon — вам, скорее всего, хватит вертикального масштабирования (+1 сервер) или модульного монолита.

Есть ли у вас услуги, связанные с транзакциями?

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

Вот как это выглядит:

1. Платежный сервис списал деньги.
2. Инвентарный сервис не ответил (упал или залагал).
3. Теперь у пользователя списаны деньги, но заказ не создан.

Микросервисы создают проблемы согласованности. В монолите вы обновляете данные одной транзакцией, в MSA это стоит в 10 раз дороже.

7 причин не лезть в микросервисы

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

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

Сложность съедает пользу

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

На практике получается следующее:

• Kubernetes (или иной подобный инструмент) становится источником проблем. Вместо написания кода вы теперь разбираетесь, почему поды (базовые строительные блоки) не стартуют, настраиваете контроллеры, обновляете Helm-чарты. Это занимает 30-50% рабочего времени.

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

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

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

Микросервисы не лечат плохой код

У вас есть монолит — большой, тяжелый, с запутанными зависимостями. И вот вы решаете: «Давайте разобьем это на микросервисы!» В теории звучит отлично: каждый сервис — маленький, независимый, аккуратный.

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

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

Нужна подготовленная команда

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

• Без полноценного DevOps или SRE-инженера вы быстро утонете в бесконечной настройке и мониторинге. Это не та работа, которую можно взвалить на бэкендера — она требует специфических знаний и постоянного внимания.
• Когда сервисов становится много, появляется новая головная боль — согласование контрактов между командами. Кто за что отвечает? Как тестировать изменения? Что делать, если один сервис ломает другой? Без четких договоренностей и CI/CD-культуры это превращается в хаос.
• В большинстве стартапов два бэкендера, один стажер и горящие сроки. Они едва успевают пилить фичи, не то что разбираться с продвинутыми практиками DevOps.

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

Деньги тратятся быстрее

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

• Без профессионального DevOps-инженера (а хорошие специалисты стоят дорого) ваш «распределенный рай» быстро превратится в ад. Кто будет настраивать Kubernetes, разбираться с падающими подами и оркестрировать логи?
• Базовый мониторинг вроде Prometheus + Grafana — это только начало. Когда сервисов станет много, вам понадобятся системы трассировки и еще десяток инструментов, каждый из которых требует времени и денег.
• Главная скрытая цена микросервисов — время инженеров. В монолите проверка занимает минуты. В мире микросервисов вам сначала придётся поднять пол-инфраструктуры, чтобы просто удостовериться, что код вообще работает.

Для проектов с нагрузкой меньше 100k пользователей микросервисы обходятся в 2-3 раза дороже монолита. И это без учета скрытых затрат — нервов, задержек и упущенных возможностей.

Отладка микросервисов — это головная боль

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

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

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

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

Легкого масштабирования не будет

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

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

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

Когда микросервисы все же нужны

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

Вот три реальных ситуации, когда MSA имеет смысл.

Независимые продукты под одной крышей

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

Здесь микросервисы — не прихоть, а необходимость.

Огромные масштабы

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

Технический стек из разных компонентов

Иногда часть системы логичнее писать на Go (где важна скорость), часть на Python (для ML), а часть оставить на JVM (для legacy).

Микросервисы позволяют:

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

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

Итоги

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

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

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

Shodan API: Поиск уязвимостей в интернете за минуты

Shodan — поисковая система для интернет-устройств. В отличие от Google, который индексирует веб-страницы, Shodan сканирует открытые порты, сервисы и устройства, подключённые к интернету. Это делает его мощным инструментом для исследователей безопасности, разработчиков и системных администраторов.

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

Как Shodan API экономит время разработчикам?

Ручной аудит серверов и интернет-устройств может занять недели, а то и месяцы, но Shodan API позволяет:

• Быстро находить уязвимые устройства и сервисы
• Проверять, какие технологии и версии ПО используются на серверах
• Получать статистику по открытым портам, SSL-сертификатам и угрозам
• Отслеживать новые уязвимости в реальном времени

Для DevOps, SOC-аналитиков и специалистов по информационной безопасности это возможность автоматизировать рутинные проверки и защитить инфраструктуру от потенциальных атак.

Как использовать Shodan API?

Shodan API предоставляет удобные методы для работы с данными через REST-запросы. Рассмотрим основные возможности.

Поиск открытых сервисов и устройств

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

Ответ покажет список IP-адресов, страну расположения серверов и используемые версии ПО.

Получение информации об IP-адресе

Допустим, вы хотите узнать, какие сервисы запущены на конкретном IP. Используем команду:

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

Поиск устройств по версии ПО

Чтобы найти все серверы с устаревшей версией OpenSSH, можно выполнить запрос:

Это полезно для поиска серверов, подверженных атакам из-за старых версий ПО.

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

Abstract API: Быстрая проверка IP, валидация email и работа с геоданными

Abstract API — сервис, предлагающий набор API для работы с IP-адресами, валидацией email, проверкой телефона, распознаванием валют и многим другим. Это универсальный инструмент для веб-разработчиков, аналитиков и специалистов по безопасности.

Как Abstract API экономит время разработчикам?

Вместо того чтобы искать разные API для работы с геоданными, email-валидацией и IP-адресами, можно использовать Abstract API. Это экономит часы на интеграцию и позволяет быстро решать задачи, такие как:

• Определение страны и города пользователя по IP

• Проверка подлинности email перед регистрацией

• Конвертация валют в реальном времени

• Валидация телефонных номеров

Abstract API помогает автоматически фильтровать спам-регистрации, защищать системы от ботов и улучшать пользовательский опыт.

Как использовать Abstract API?

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

Определение геолокации по IP

Можно быстро определить страну, город и провайдера пользователя:

Валидация email-адреса

Проверяем, является ли email настоящим, одноразовым или корпоративным:

Что нужно помнить? Бесплатная версия ограничена числом запросов в месяц. А данные по IP-геолокации иногда могут быть неточными (зависит от провайдера).

Zyte API: Интеллектуальный ротационный прокси для веб-скрейпинга без блокировок

Zyte API — мощный API для веб-скрейпинга, который не только обходит блокировки и капчи, но и автоматически структурирует полученные данные. Он объединяет в себе прокси-серверы, обработку JavaScript-страниц и инструменты парсинга, что делает его одним из самых удобных решений для сбора данных с веб-ресурсов.

Как Zyte API экономит время?

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

• Автоматическая обработка JavaScript-страниц (открывает динамически загружаемые сайты, как Selenium).

• Обход капч и блокировок (использует интеллектуальные прокси).

• Автоматическое структурирование данных (не просто HTML, а уже готовая JSON-структура).

• Интеграция с Python и REST API (работает с любыми языками программирования).

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

Как использовать Zyte API?

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

Использование Zyte в curl

Допустим, нужно скачать HTML-страницу сайта example.com:

Что нам ответят:

Интеграция с Python

Для начала нужно установить клиент:

Код для парсинга и получения данных:

Автоматический парсинг данных

Zyte API умеет не только загружать HTML, но и автоматически извлекать полезные данные. Например, спарсить цену, название и описание кроссовок в интернет-магазине (ну или любого другого товара).

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

Common Crawl API: Бесплатная база данных для веб-скрейпинга и анализа интернета

Common Crawl — не просто API, а целый архив интернета, содержащий огромные объемы веб-данных, собранных с 2008 года. В отличие от стандартных API для веб-скрейпинга, Common Crawl предоставляет доступ к готовым копиям страниц, что значительно ускоряет анализ веб-контента и снижает нагрузку на исходные сайты.

Как Common Crawl API экономит время?

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

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

• Исторические данные (можно анализировать, как изменялся контент сайтов за годы).

• Отсутствие блокировок и капч (данные уже собраны, вам не нужно бороться с защитами сайтов).

• Возможность массового анализа веба (идеально для NLP, машинного обучения и SEO-исследований).

API и данные Common Crawl полезны для исследователей, дата-аналитиков, SEO-специалистов и разработчиков.

Как использовать Common Crawl API?

Common Crawl предоставляет данные в формате WARC (архивные копии страниц) и WET (чистый текст без HTML). Доступ осуществляется через Amazon S3, но также можно использовать API Common Crawl Index для поиска нужных URL.

Поиск веб-страниц через API

Допустим, нам нужны все страницы, содержащие example.com:

Вот такой ответ может быть:

Получение текста страницы из архива

После получения ссылки на WARC-файл можно скачать его и распаковать:

Ну и затем извлечь текст:

Анализ больших объемов данных с AWS

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

Пример SQL-запроса в AWS Athena для поиска страниц с «machine learning»:

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

GitHub API: автоматизация работы с репозиториями, пользователями и кодом

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

Как GitHub API экономит время?

Вместо ручного управления репозиториями и кодом через интерфейс GitHub можно автоматизировать эти процессы с помощью API:

• Автоматизация деплоя и CI/CD (создание и управление GitHub Actions).

• Мониторинг активности в репозиториях (новые коммиты, запросы на вытягивание, проблемы).

• Управление пользователями и организациями (добавление разработчиков, управление доступом).

• Анализ кода и метрик (подсчёт строк кода, статистика участников).

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

GitHub API полезен для DevOps-инженеров, разработчиков, владельцев проектов и аналитиков.

Как использовать GitHub API?

GitHub API работает через REST-запросы и возвращает данные в формате JSON. Для авторизации можно использовать токен личного доступа (PAT) или OAuth.

Получение информации о пользователе GitHub

Допустим, мы хотим узнать данные о пользователе natasharostova:

Как нам могут ответить:

Создание нового репозитория через API

После выполнения запроса появится новый репозиторий new-repo.

Поиск репозиториев по ключевому слову

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

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

MuleSoft API: Универсальный коннектор для интеграции сервисов

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

Как MuleSoft API экономит время?

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

• Интегрировать разные системы (CRM, ERP, базы данных, облачные сервисы) без сложного кодинга.

• Автоматизировать обмен данными между приложениями (например, между Salesforce и SAP).

• Обеспечивать безопасность API с помощью встроенных инструментов управления доступом.

• Создавать микросервисную архитектуру, где API работают как модули.

API полезен для DevOps-инженеров, архитекторов ПО, разработчиков корпоративных решений и интеграторов.

Как использовать MuleSoft API?

MuleSoft поддерживает REST и SOAP API, а также интеграцию через готовые коннекторы.

Создание API с помощью Anypoint Platform

Anypoint Platform — облачная среда MuleSoft, в которой можно управлять API.

Пример запроса к API через MuleSoft:

Подключение к базе данных через DataWeave

DataWeave — это язык MuleSoft для трансформации данных. Он позволяет легко преобразовываться в нужные форматы.

Это правило конвертирует XML-ответ базы данных в JSON.

Важно помнить, что бесплатные возможности платформы ограничены. Также сервис требует обучения: для работы с DataWeave и Anypoint Platform нужно разбираться в интеграции API.

JSONPlaceholder API: бесплатный фиктивный REST API для тестирования и создания прототипов

JSONPlaceholder API — бесплатный REST API, предназначенный для тестирования, создания прототипов и обучения разработчиков. Он предоставляет фиктивные данные (пользователей, публикаций, комментариев и т. д.), которые можно использовать при разработке клиентских и серверных приложений без необходимости развёртывать собственный бэкенд.

Как JSONPlaceholder API экономит время?

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

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

• Не требует регистрации или API-ключа.

• Поддерживает стандартные HTTP-методы (GET, POST, PUT, DELETE).

• Полностью совместим с популярными библиотеками и фреймворками (Axios, Fetch API, jQuery и др.).

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

Как использовать JSONPlaceholder API?

JSONPlaceholder предоставляет несколько ресурсов, которые можно запрашивать с помощью HTTP-запросов.

Получение списка пользователей

Простейший GET-запрос возвращает список тестовых пользователей:

Получение списка постов

Можно запросить список фиктивных публикаций:

Добавление нового поста

Можно отправить POST-запрос, чтобы имитировать создание записи:

Обновление записи

Для изменения существующей записи можно использовать PUT-запрос:

Что нужно помнить? Данные статичны — они не сохраняются между запросами. Запросы POST, PUT и DELETE не изменяют реальные данные. А само API предназначено только для тестирования, а не для использования в рабочей среде.

Почему модульность кода — не тренд, а необходимость

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

Без модульности всё разваливается

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

• Код становится слишком большим, чтобы его можно было легко понять. Если в начале у вас был один файл на 500 строк, то через год в проекте уже тысячи файлов, десятки зависимостей, а изменение одной строчки может вызвать неожиданный каскад ошибок.
• Любые изменения могут нарушить работу всего, что угодно. Монолитный код, в котором всё взаимосвязано, делает проект хрупким: добавляя новый функционал, разработчик может случайно затронуть совершенно неожиданные части.
• Тестирование становится сложнее. Если компоненты системы зависят друг от друга, их невозможно тестировать по отдельности, а значит, каждая ошибка требует длительного анализа.
• Новые разработчики тратят недели на разбор чужого кода. Чем больше в коде скрытых взаимосвязей, тем дольше человеку приходится разбираться, как что работает.

Модульность решает множество проблем

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

Упрощает сопровождение кода

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

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

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

Снижает количество багов, связанных с зависимостями

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

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

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

Делает тестирование проще и быстрее

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

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

• Юнит-тесты проверяют конкретные модули без запуска всей системы;
• Интеграционные тесты оценивают взаимодействие между модулями;
• Тестирование становится параллельным — можно одновременно проверять разные модули.

Основные принципы модульного кода

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

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

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

Если один модуль отвечает сразу за несколько задач, это приводит к нескольким проблемам:

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

Если нарушить SRP:

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

• Валидирует данные заказа;
• Вычисляет стоимость;
• Обрабатывает оплату;
• Отправляет email-подтверждение.

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

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

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

SRP особенно полезен в ситуациях, где код часто меняется и развивается:

• В API и микросервисах — каждый сервис выполняет одну задачу, что упрощает поддержку;
• В UI-компонентах — разделение логики интерфейса (рендеринг, обработка данных) помогает избежать громоздких компонентов;
• В бизнес-логике — SRP делает код более гибким и адаптируемым под новые требования.

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

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

Связность (coupling) — степень зависимости одного модуля от другого. Что происходит при высокой связности?

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

Пример плохой высокой связности:

Здесь OrderProcessor напрямую создаёт экземпляр PaymentProcessor, что делает их жёстко связанными. Если нам понадобится заменить Пеймент на другую реализацию (например, добавить поддержку PayPal), возникнут трудности.

Но как уменьшить связность? Нужно использовать инъекцию зависимостей (Dependency Injection) и разделять интерфейсы и реализации:

Теперь OrderProcessor не зависит от конкретной реализации PaymentProcessor. Можно легко подставить другую реализацию, например, PayPalPaymentProcessor или StripePaymentProcessor, без изменений в основном коде.

Перейдем к когезии (cohesion). Это степень связанности логики внутри одного модуля. Если модуль выполняет слишком много разрозненных задач, его сложно понимать и поддерживать. Что происходит при низкой когезии?

1. Код выглядит хаотично — внутри одного модуля встречается разнородная логика, которая не должна быть связана.
2. Повышенный риск багов — разные части модуля зависят от несвязанных данных, что усложняет отладку.
3. Сложность изменений — разработчику приходится разбираться в неочевидных взаимосвязях.

Например:

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

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

Пример высокой когезии:

Теперь UserManager отвечает только за управление пользователями, а EmailService занимается отправкой писем. Логика каждого модуля цельная и легко расширяется.

Как достичь слабой связности и высокой когезии?

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

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

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

Чистый интерфейс — это API модуля, которое:

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

• Не перегружено лишними методами;

• Стабильное — изменения API минимально затрагивают пользователей.

Плохой пример:

Этот метод делает слишком много:

• Сохраняет пользователя,
• Отправляет email,
• Логирует активность,
• Обрабатывает override от администратора.

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

Пример чистого API:

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

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

• Ясно определяет, какие входные данные он принимает;
• Гарантирует ожидаемый результат;
• Защищается от некорректных данных.

Пример контракта в коде:

Здесь чётко определено:

• Если сумма заказа ≤ 0, метод выбросит ошибку.

• Если плата прошла успешно, метод вернёт PaymentResult.Success = true.

Как проектировать чистые интерфейсы?

• API должен быть понятен без чтения документации;

• Чем меньше точек входа, тем проще сопровождать код;

• Если метод принимает bool-флаги, вероятно, его стоит разбить на несколько методов;

• Лучше сделать API чуть менее удобным, но не ломающим обратную совместимость.

Простота в тестировании: возможность заменить модули заглушками и писать юнит-тесты

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

Когда код монолитный и сильно связан, тестирование становится головной болью:

• Один тест может затрагивать десятки зависимостей;

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

• Каждый новый баг ломает кучу тестов, потому что код слишком взаимозависимый.

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

Можно заменять реальные модули заглушками (моками, стабами, фейками)

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

Пример без модульности:

Здесь OrderService жёстко завязан на PaymentProcessor, и в тесте мы не сможем подменить его заглушкой.

Пример с модульностью:

Теперь мы можем подменять IPaymentProcessor тестовой заглушкой:

В тесте вместо реального PaymentProcessor подставляем FakePaymentProcessor

Легко писать юнит-тесты для отдельных частей кода

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

Пример юнит-теста с моками:

Здесь мы проверяем, был ли вызван метод ProcessPayment(), но не запускаем реальную оплату.

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

Модульность позволяет запускать только нужные части системы. Например, можно тестировать API без базы данных, заменяя её на memory-версию.

Пример тестирования API без реальной базы:

Здесь TestDbContext — in-memory база, которая не трогает продовые данные.

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

Как правильно разбивать код на модули?

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

Думайте о модулях с самого начала

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

• Какие ключевые бизнес-объекты в проекте (например, «Пользователи», «Заказы», «Оплата»);
• Какие у них чёткие границы (UserModule не должен отвечать за Payments);
• Какие взаимодействия между ними (какие API вызывают друг друга).

Пример проектирования модульной системы (возьмем e-commerce):

В интернет-магазине можно выделить такие модули:

• UserModule — управление пользователями;
• CatalogModule — товары и категории;
• CartModule — корзина покупок;
• OrderModule — оформление заказов;
• PaymentModule — платежи.

Каждый модуль должен иметь своё API и не лезть в чужие данные напрямую.

Как делать НЕ надо:

Здесь OrderService вмешивается в чужие модули (работает с UserRepository и PaymentService). Это создаёт жёсткую связанность.

Как надо:

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

Выделяйте независимые модули по принципу «Один модуль = одна ответственность»

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

Хорошая практика — модули по бизнес-областям (например, UserModule, OrderModule, PaymentModule)

Пример:

Каждый модуль самодостаточен:

• В user хранятся все файлы, связанные с пользователями;
• В order — всё, что касается заказов;
• В payment — логика работы с платежами.

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

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

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

Пример с хорошими контрактами:

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

Не усложняйте: модульность ≠ миллион мелких файлов

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

Как НЕ надо:

Зачем так делать? Теперь, чтобы просто добавить новый API-метод, нужно создавать новый файл.

Как лучше:

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

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

Это моя первая проба пера, так что не судите строго. Сегодня мы разберем одну из самых интересных и, на первый взгляд, сложных тем в JavaScript — Event Loop (или цикл событий). Если вы когда-нибудь задумывались, как браузер умудряется выполнять множество задач одновременно, не зависая при этом, то вы попали по адресу.

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

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

Поехали! 🚀

Как работает Event Loop и из чего состоит

Структура Event Loop

Основная цель Event Loop — циклическое выполнение задач, которые делятся на две категории:

1. Синхронные задачи — выполняются немедленно;
2. Асинхронные задачи — добавляются в очередь и выполняются позже.

Макрозадачи и микрозадачи

Одним из ключевых аспектов работы event loop выступают макрозадачи (macrotasks) и микрозадачи (microtasks). Они представляют собой две очереди задач, которые имеют различный приоритет выполнения.

• Макрозадачи. Выполняются после завершения текущей синхронной задачи. Примеры:Синхронный код; таймеры (setTimeout, setInterval); события пользовательского интерфейса (например, клики мыши); сетевые запросы (например, fetch или XMLHttpRequest).
• Микрозадачи. Выполняются сразу после завершения текущей синхронной задачи, но перед началом следующей макрозадачи. Примеры:Промисы (Promise.resolve(), Promise.reject()).MutationObserver.async/await).

В Node.js также есть event loop, но с небольшими различиями. Например, там используются дополнительные очереди для работы с файловой системой и сетью.

Схема приоритетов выполнения:

1. Сначала выполняется текущий синхронный код;
2. Затем выполняются все микрозадачи в очереди Microtask queue до тех пор, пока очередь не станет пустой;
3. После этого выполняется следующая макрозадача из очереди Macrotask queue и т.д.

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

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

Вложенные промисы и микрозадачи

Порядок вывода:

1. Start
2. First promise
3. Second promise
4. Timeout 1
5. Promise in timeout

Объяснение:

• Сначала выполняется синхронный код (console.log('Start')).
• Затем выполняются микрозадачи (микротаски) — это цепочки промисов.
• После завершения всех микрозадач выполняются макрозадачи (например, setTimeout).

Асинхронные функции и генераторы

Порядок вывода:

1. Async start
2. Main thread
3. Generator timeout
4. After generator

Объяснение:

• Функция asyncFunction начинает выполнение, но останавливается на await, пока не завершится промис, созданный генератором.
• Синхронный код продолжает выполняться (console.log('Main thread')).
• Когда таймер завершается, event loop обрабатывает завершение промиса и продолжает выполнение asyncFunction.

Взаимодействие с DOM и таймерами

Порядок вывода:

1. Initial timeout
2. Button clicked
3. Timeout after click

Объяснение:

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

Рекурсивные промисы и рекурсия

Порядок вывода:

1. Outside recursion
2. Recursive 3
3. Recursive 2
4. Recursive 1

Объяснение:

• Вызов recursivePromise(3) запускает цепочку промисов и таймеров.
• Синхронный код (console.log('Outside recursion')) выполняется первым.
• Event loop последовательно обрабатывает каждый вызов рекурсии, начиная с самого глубокого уровня.

Параллельные сетевые запросы и обработка результатов

Порядок вывода:

1. Starting fetches
2. Fetched data from ... (в случайном порядке)
3. All data fetched: [...]

Объяснение:

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

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

Лайфхаки для понимания Event Loop

Используйте визуализацию

Используйте инструменты вроде Chrome DevTools или онлайн-симуляторов Event Loop, чтобы видеть порядок выполнения задач.

Создайте шаблоны

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

Регулярно практикуйтесь

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

Изучите документацию

Изучите официальную документацию по JavaScript и спецификации ECMAScript для более глубокого понимания.

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

В этой статье мы разберём основные подходы к работе с REST API в Java и рассмотрим популярные библиотеки для реализации retry-механизмов. Я также поделюсь собственным опытом внедрения повторных вызовов с экспоненциальным увеличением задержки между попытками.

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

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

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

Использование RetryTemplate с RestTemplate в Spring

RestTemplate — удобный HTTP-клиент в Spring Framework. Хотя он считается устаревшим, его всё ещё активно используют в существующих проектах. Чтобы повысить отказоустойчивость запросов, можно добавить механизм повторных попыток (retry) с использованием RetryTemplate из Spring Retry.

Пример: RestTemplate + RetryTemplate

Использование WebClient с механизмом повторных попыток (retry)

WebClient — современный HTTP-клиент в Spring WebFlux, который поддерживает асинхронные запросы и реактивные потоки. В отличие от RestTemplate, он рассчитан на неблокирующую работу и уже имеет встроенный механизм повторных вызовов.

Пример: WebClient + retryWhen

Использование HttpClient (Java 11+) с механизмом повторных попыток

Начиная с Java 11, стандартная библиотека HttpClient предоставляет мощные возможности для отправки HTTP-запросов, включая асинхронную обработку и гибкие настройки повторных попыток (retry).

Пример: HttpClient с механизмом повторных вызовов

Реализация механизма повторных вызовов (Retry) в gRPC

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

gRPC — высокопроизводительный RPC-фреймворк от Google, основанный на HTTP/2 и использующий бинарный формат данных (Protocol Buffers). Он поддерживает стриминг, асинхронные вызовы и механизмы автоматического повторного запроса при сбоях.

В gRPC механизм retry можно настроить с помощью параметров retryPolicy, передаваемых в ServiceConfig:

Использование gRPC с retry повышает устойчивость микросервисов и делает систему более отказоустойчивой.

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

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

Шаг 1. Определяем цели и мотивацию

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

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

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

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

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

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

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

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

Шаг 2. Развиваем навыки

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

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

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

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

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

Рассмотрим ключевые софты, которые стоит развить.

Коммуникация

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

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

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

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

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

Как преодолеть барьеры в общении?

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

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

Ответственность

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

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

Мы используем гибкие методологии, но главный принцип – давать людям то, что им нужно. Заказчику – уверенность в результате. Ему не интересны технические детали вроде новых микросервисов и покрытых тестами API, ему важно понимать, какую бизнес-ценность это несет. Если изменение неочевидно, важно объяснить его эффект: например, шаблон микросервиса ускорит будущие разработки, а e2e-тесты снизят риски багов.

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

Пунктуальность

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

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

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

Проактивность

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

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

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

Другие навыки и умения

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

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

Шаг 3. Обучаемся менеджменту

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

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

Это примерный список для ориентира:

• «Эффективный руководитель» — Питер Друкер. Книга рассказывает о том, как и чем должен заниматься руководитель, какие правила соблюдать, чтобы добиваться результата в любом деле.
• «45 татуировок менеджера» — Максим Батырев. В формате жизненных историй и конфликтных ситуаций рассказывает о том, как сформировать характер и личность руководителя.
• «Привычка работать вместе» — Твайла Тарп. Опыт успешной коммуникации в команде на примерах из разных сфер.
• «Пять пороков команды» — Патрик Ленсиони. Книга о том, как преодолеть недоверие, безответственность и безразличие к результату работы.
• «Мотивация» — Макс Эггерт. Ценный справочник, полный советов и инструментов, необходимых в работе менеджера.
• «Карьера менеджера IT-проекта» — Гэйл Лакман Макдауэлл и Джеки Баваро. Практическое руководство по ведению проектов и подготовке к собеседованию на позицию ИТ-менеджера.

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

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

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

Шаг 4. Переходим на желаемую должность

Советуем следовать конкретному плану:

1. Установите сроки. Переход в менеджеры — дело не одного дня. Процесс займет несколько месяцев, при этом форсировать события точно не стоит.
2. Согласуйте переход в менеджеры с руководством компании. Если в вашей фирме не заинтересованы в подобной инициативе, поищите вакансии в других организациях. В целом хорошие управленцы в ИТ-отрасли нужны всегда.
3. Определите свои сильные и слабые стороны. Подумайте, что можно сделать, чтобы нивелировать недостатки и выработать качества, без которых руководителю не обойтись.
4. Найдите ментора из числа опытных управленцев вашей компании. Научитесь у него всему, что он знает, особенно в плане взаимодействия с исполнителями и руководством.
5. Договоритесь о собеседовании на позицию менеджера. Если вы действуете внутри компании, вести беседу будет гораздо проще. Помните главное: собеседование — не экзамен, работодатель не делает вам одолжений, а тоже заинтересован в ответственных и активных работниках.

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

Шаг 5. Работаем над вызовами

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

• Длительные согласования. Чем больше заинтересованных в проекте сторон (стейкхолдеров), тем сложнее. Готовьте документы, инструкции и самого клиента заранее. Все, что нужно предоставить с вашей стороны, должно быть предоставлено. Помогайте заказчику всем, чем можете, и будьте на связи, чтобы в любой момент ответить на вопросы.
• Частые переносы встреч. Клиенты бывают занятыми и иногда откладывают встречи. Проблему можно решить только одним способом — договориться, выбрав нужные слова, и вежливый, но решительный тон.
• Предложение от заказчика переделать функционал. То есть по сути обнулить результат уже проделанной работы. Задача менеджера в такой ситуации — оценить целесообразность решения. Возможно клиент руководствуется пользовательским опытом, но может быть и так, что это его сугубо личное мнение. В последнем случае придется собрать фактический материал и спокойно объяснить заказчику, с какими издержками придется столкнуться.

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

1. Норман Бейтс («Психо»)

Почему Python?

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

Его путь в IT

Норман начинал как сисадмин в семейном мотеле "Бейтс". Ручное управление серверами быстро ему надоело — ну сколько можно делать одно и то же? Он начал писать скрипты на Python, автоматизируя бэкапы, мониторинг и деплой. Затем подсел на Docker и Kubernetes, завернул всю инфраструктуру в контейнеры и настроил CI/CD пайплайны.

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

Но позже выяснилось, что он сделал это под влиянием своего "второго я", не осознавая последствий.

2. Майкл Майерс («Хэллоуин»)

Почему C?

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

Его путь в IT

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

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

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

3. Пеннивайз («Оно»)

Почему JavaScript?

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

Его путь в IT

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

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

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

4. Гостфейс («Крик»)

Почему Ruby?

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

Его путь в IT

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

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

5. Кожаное лицо («Техасская резня бензопилой»)

Почему C++?

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

Его путь в IT

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

Коллеги знают: если нужно что-то спаять, запрограммировать и заставить работать — это к нему. Хотя он не особо разговорчив и может показаться грубоватым.

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

6. Акула («Челюсти»)

Почему Go?

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

Ее путь в IT

Начинала с Java, но быстро поняла, что Go лучше подходит для ее целей. Стала экспертом в микросервисной архитектуре, разворачивая кластеры, способные обрабатывать миллионы запросов в секунду. Ее код оптимизирован на все 100%, как и она сама в погоне за добычей.

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

7. Существа из «Тихое место»

Почему Rust?

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

Их путь в IT

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

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

8. Сара Фир («Улица страха»)

Почему Kotlin?

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

Ее путь в IT

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

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

9. Джейсон Вурхиз («Пятница, 13-е»)

Почему Java?

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

Его путь в IT

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

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

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

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

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

ВЫБЕРИ имена студентов ГДЕ оценка равна пяти.

Переведём на английский (SQL):

Давайте напишем запрос для поиска тех у кого оценка ниже пятёрки:

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

• =  (равно)
• < (меньше)
• > (больше)
• <> (не равно)

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

Часто вам может понадобиться выбрать строки отвечающие нескольким условиям одновременно. Для этого нужно запомнить ещё одно слово на английском – AND. Это слово переводится как союз И и может применяться для объединения условий. Например для того чтобы найти отличников по физике нужно в запросе объединить два условия score = 5 и course = ‘Физика’.

Если нам достаточно выполнения одного из нескольких условий то их нужно соединить союзом ИЛИ – по английски OR. Например чтобы найти студентов изучающих одну из точных наук (физику или математику) напишем запрос:

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

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

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

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

Первые два из этих слов это SELECT (ВЫБЕРИ) и FROM (ИЗ).

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

Для примера рассмотрим таблицу студентов (students) из трёх колонок: имя студента (name), курс на котором он занимается (course) и оценка (score).

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

В результате выполнения этого запроса мы получим следующий результат:

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

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

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

а можем просто использовать символ * вместо списка колонок:

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

Итак если вы дочитали до конца эту статью вы уже можете написать простейший запрос на языке SQL и пройти первые два теста на сайте SQLtest.online и затем прейти к следующему мини-уроку этого курса.

Ошибка 1. Нет четких границ между слоями приложения

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

Можно выделить три базовых уровня:

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

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

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

Ошибка 2. Игнор масштабирования с первого дня

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

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

Например:

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

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

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

Ошибка 3. Преждевременное усложнение архитектуры

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

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

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

Что можно делать:

• Запускать монолит на FastAPI или Django, а не дробить на микросервисы до появления реальных узких мест.
• Использовать Postgres без брокеров событий, пока не появятся требования к масштабированию.
• Добавлять кэш Redis точечно, когда видна реальная нагрузка, а не вслепую кэшировать каждый запрос.

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

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

Ошибка 4. Непродуманная работа с зависимостями

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

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

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

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

Например, при работе с Python удобным подходом будет использование Poetry: можно зафиксировать версии зависимостей в pyproject.toml, автоматически создавать lock-файл, следить за актуальностью библиотек и легко пересоздавать окружение. Если проект запускается на CI/CD, можно установить точные версии и сразу выявить, где обновление ломает тесты.

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

Ошибка 5. Нет стратегии управления состоянием

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

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

Чтобы избежать хаоса, управление состоянием нужно продумать заранее:

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

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

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

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

А какие ошибки допускаете вы? Делитесь в комментариях или в тг-канале Веб-страница.