Как появился сервис для управления проектами ЛайТимс?

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

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

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

Какие есть возможности у ЛайТимс?

Платформа объединяет:

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

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

Отечественное ПО для управления рабочими процессами

Включение LighTeams в реестр отечественного ПО стало логичным этапом развития продукта. Теперь компании могут рассматривать платформу как российское решение для организации проектной и командной работы.

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

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

Чем отличается наша CRM для бизнеса от других?

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

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

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

Подробнее о LighTeams: https://thelightech.ru/solutions/lighteams/

*Видеопересказ статьи можно посмотреть на RuTube

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

С чего всё началось?

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

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

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

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

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

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

Можно установить мониторинг непосредственно на роутер. Хороший вариант, если бы у нас стоял MikroTik, Keenetic или другое устройство, с которым хотелось бы экспериментировать. Но в офисе работает достаточно старый роутер, который при этом прекрасно справляется со своей основной задачей. Здесь действует один из фундаментальных законов системного администрирования:

Если работает — не трогай.

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

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

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

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

Я проходил курс по IoT и инженерии умного дома, где работал с ESP32, Arduino и Raspberry Pi. Параллельно изучал Go и искал проект, на котором можно было бы применить его не в учебных примерах, а для решения настоящей задачи. Кроме того, мне хотелось попробовать агентный подход к разработке на проекте, который можно целиком контролировать самому.

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

Рациональнее ли это покупки умной розетки? Определённо нет. Интереснее? Определённо да.

Первоначальный план

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

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

При этом активно сканировать или каким-либо образом нагружать офисную сеть мне не хотелось.

Задача устройства была гораздо проще: периодически сообщать наружу что-то вроде:

Я здесь. Я смог выйти в интернет. Всё в порядке.

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

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

Оставалась небольшая проблема. У меня ещё не было ни ESP32, ни Ethernet-платы. А делать что-то уже хотелось.

Железа нет — будем эмулировать

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

Заодно появился хороший повод использовать Go, который я как раз изучал.

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

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

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

Разумеется, настоящего Device у меня всё ещё не было.

Поэтому его место временно занял simulator.

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

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

На этом же этапе появился первый простой Web UI. Никаких сложных dashboard, графиков и аналитики — достаточно было обратиться к backend и показать главное: устройство сейчас выходит на связь или нет.

Так начала складываться первая версия архитектуры:

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

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

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

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

Когда приехало железо

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

Был Go backend, API для регистрации устройств и heartbeat, база данных, эмуляция устройств и первый workflow обмена данными. То есть сервер уже был готов разговаривать с устройством, которого до этого момента физически не существовало.

Оставалось, казалось бы, самое простое: заменить simulator настоящей ESP32.

Первоначальный план предполагал Ethernet. Я заказал ESP32, отдельный LAN-модуль, припаял необходимые контакты и начал собирать всё вместе.

И здесь план впервые встретился с реальным железом.

Ethernet, который не случился

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

Логика была примерно такой:

ESP32 ── Ethernet ── Router ── Internet ── VPS

Никаких проблем с качеством Wi-Fi, паролями, переподключениями и прочими особенностями беспроводной сети. Воткнул кабель — и устройство работает.

По крайней мере, так это выглядело на бумаге.

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

Вернуть его к тому моменту уже было поздно.

Передо мной возникло два варианта.

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

А можно было посмотреть на ESP32, вспомнить, что Wi-Fi в ней уже есть, и задать себе довольно простой вопрос: а зачем мне вообще сейчас Ethernet?

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

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

Питание тоже не требовало отдельной инфраструктуры: обычный блок питания и USB Type-C.

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

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

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

ESP32 подключалась к офисному Wi-Fi, выходила через него в интернет и обращалась к backend на VPS. А backend видел главное:

устройство вышло на связь.

Значит, как минимум в этот момент ESP32 была включена, офисная Wi-Fi-сеть работала, роутер имел доступ наружу, а запрос смог пройти через интернет до моего сервера.

Для исходной задачи этого было более чем достаточно.

Иногда сломанный компонент — это полезно

История с Ethernet в итоге оказалась скорее полезной.

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

Но всё это не приближало бы проект к решению исходной задачи настолько, насколько приближал один работающий Wi-Fi connection.

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

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

Шалость должна была когда-нибудь начать удаваться.

А зачем мне здесь PostgreSQL?

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

Несколько устройств, регистрация, heartbeat, хранение состояния — всё это довольно естественно привело к PostgreSQL.

На VPS первоначальная схема выглядела примерно так:

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

У меня одна ESP32. Один backend. Один небольшой VPS. Раз в несколько секунд приходит крошечный heartbeat.

Нет сложной аналитики. Нет тяжёлых запросов. Нет десятков пользователей. Нет необходимости масштабировать backend на несколько экземпляров. И ради всего этого рядом работает отдельный контейнер PostgreSQL.

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

База данных тоже может быть оверхедом

У проекта с самого начала была одна важная оговорка: это эксперимент.

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

Не было никакого смысла пытаться заранее построить её внутри маленького pet-проекта.

Поэтому PostgreSQL я убрал. Его место заняла SQLite.

Вместо двух сервисов на VPS остался один контейнер backend и persistent volume с файлом SQLite. И для текущей нагрузки этого оказалось более чем достаточно.

UI тоже не обязан быть отдельным приложением

Примерно по той же причине я не стал превращать Web UI в отдельный frontend-проект. Мне не требовались React, Vue, отдельный Node.js build, frontend-контейнер и собственный deployment pipeline. Мне нужно было открыть страницу и увидеть состояние устройства.

Поэтому UI остался обычным HTML, CSS и JavaScript, который раздаёт тот же Go backend. Получилась очень простая конструкция:

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

Сначала работающая система

Навести красоту всегда можно потом.

Добавить полноценные временные ряды. Построить графики доступности. Посчитать SLA. Подключить отдельную систему метрик. Вернуть PostgreSQL. Разделить frontend и backend. Добавить ещё несколько сервисов.

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

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

Меньше планировать идеальную систему. Больше делать работающую.

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

Когда pet-проект оказался полезен не только мне

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

ESP32 стояла в офисе, подключалась к Wi-Fi и периодически отправляла heartbeat на мой VPS. Backend сохранял данные, а через простой Web UI я мог посмотреть состояние устройства.

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

Интернет там вообще есть?

Но примерно в этот момент у проекта появился ещё один пользователь. Вернее, сразу вся компания.

У нашей компании есть собственные разработки — в частности, LightPulse и LightTeams.

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

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

Первый остался прежним — частый heartbeat на мой backend:

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

Для LightPulse не было необходимости получать heartbeat каждые несколько секунд. Достаточно было периодического сигнала примерно раз в 30–40 минут.

Смысл этого запроса оставался тем же:

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

Значит, с очень высокой вероятностью офис сейчас онлайн.

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

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

И здесь маленький эксперимент неожиданно начал превращаться в настоящий внутренний инструмент.

Один датчик — два разных сигнала

При этом я сознательно не стал объединять два сценария в один.

Мой backend и LightPulse решали разные задачи.

Частый heartbeat нужен локальной системе мониторинга, чтобы относительно быстро заметить исчезновение устройства.

ESP32 ── 5 sec ──► VPS

Корпоративному сервису такая частота совершенно не требовалась:

ESP32 ── 30–40 min ──► LightPulse

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

И всё это по-прежнему работало по первоначальному принципу проекта:

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

Я всё ещё здесь. Интернет есть.

На этом можно было бы действительно остановиться.

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

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

Хорошо, устройство замолчало. И что дальше?

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

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

Получался мониторинг, за которым нужно мониторить.

Так появилась следующая задача: система должна сама определять проблему и сообщать о ней. На первый взгляд всё опять кажется довольно просто. Не пришёл heartbeat — устройство offline. Но здесь начались уже более интересные вопросы.

Один потерянный heartbeat ещё ничего не значит

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

Запрос может потеряться. Wi-Fi может кратковременно переподключиться. VPS может ответить чуть позже. Может произойти временная сетевая ошибка где-нибудь между Ростовом и сервером.

Само устройство при этом совершенно исправно.

Поэтому модель:

мне не подходила.

Вместо этого появился offline threshold.

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

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

Так обычный last heartbeat начал превращаться в мониторинг состояния.

Offline — это уже событие

Следующий вопрос возник практически сразу. Допустим, устройство признано offline. Через некоторое время backend снова запускает проверку.

Устройство всё ещё offline. Ещё через некоторое время — снова offline.

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

Первое обнаружение проблемы открывает connectivity incident:

Пока этот incident остаётся открытым, последующие проверки уже не создают новые.

Система знает:

Да, об этой проблеме мы уже знаем.

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

Теперь система постепенно начинала отвечать уже на другие вопросы:

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

И это уже было значительно ближе к настоящему мониторингу.

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

Представим нестабильное соединение:

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

Например:

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

Получился небольшой state machine:

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

Мониторинг должен сообщать о проблеме сам

Оставался последний очевидный недостаток. Backend теперь сам понимал, что произошёл incident. Но я всё ещё мог узнать об этом только через Web UI. Значит, пришло время уведомлений.

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

Первым реальным каналом стал Web Push. И вот здесь маленький backend, который просто принимал heartbeat от ESP32, внезапно потребовал ещё несколько вполне взрослых компонентов.

Нужно было хранить push subscriptions. Нужен был service worker в браузере. Понадобились VAPID-ключи. Нужно было корректно удалять больше не существующие subscriptions. А главное — браузерные Web Push API требуют secure context. То есть появился HTTPS.

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

Теперь у меня были ESP32, Go backend, SQLite, incident lifecycle, recovery logic, reverse proxy, TLS, service worker и push-уведомления. Кажется, умная розетка всё-таки была немного проще.

Что в итоге получилось?

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

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

ESP32 подключается к обычной офисной Wi-Fi-сети и сама инициирует все необходимые соединения. На VPS работает один контейнер с Go backend. Он же раздаёт Web UI, выполняет логику мониторинга и работает с SQLite.

Отдельно существует LightPulse, куда устройство отправляет более редкий корпоративный monitoring signal.

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

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

Что происходит при обычной работе?

После включения ESP32 подключается к офисному Wi-Fi и начинает работать как обычный клиент сети. Дальше устройство периодически отправляет heartbeat на backend:

Каждый успешно полученный heartbeat означает довольно простую вещь.

В этот момент одновременно выполняется несколько условий:

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

Офис сейчас способен выйти в интернет?

Для этого heartbeat оказалось достаточно.

Что происходит, когда связь исчезает?

Если heartbeat перестаёт приходить, backend не объявляет аварию немедленно. Он ждёт установленный timeout.

При этом backend не знает причину отсутствия heartbeat. И это важно. Устройство могло потерять Wi-Fi. Мог отключиться роутер. Мог упасть интернет у провайдера. Могло исчезнуть электричество во всём офисе. В конце концов, сама ESP32 могла перестать работать.

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

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

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

Что происходит после восстановления?

Когда связь возвращается, первый успешный heartbeat ещё не закрывает incident. Backend ждёт несколько последовательных успешных сигналов.

Это защищает систему от ситуации, когда нестабильное соединение постоянно переключает устройство между online и offline. Таким образом, вокруг очень простого heartbeat появилась небольшая модель жизненного цикла:

Второй независимый сигнал

Кроме частого heartbeat на мой backend, ESP32 периодически обращается к LightPulse. Это уже другой сценарий.

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

Simulator никуда не исчез

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

Можно запустить simulator локально, зарегистрировать виртуальное устройство и воспроизвести тот же базовый lifecycle:

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

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

А что система на самом деле мониторит?

Здесь есть одна важная оговорка. Я несколько раз называл устройство монитором интернета, но технически это не совсем точное определение. ESP32 не измеряет SLA провайдера. Не запускает Speedtest. Не анализирует packet loss. Не строит traceroute. Не проверяет каждый компонент офисной сети отдельно.

Она отвечает на гораздо более узкий вопрос:

Может ли физическое устройство, находящееся сейчас в офисе, выйти через офисную сеть наружу и достучаться до известного внешнего сервиса?

Именно поэтому отсутствие heartbeat нельзя автоматически трактовать как: провайдер снова уронил интернет.

Причина может находиться где угодно на пути:

Но для первоначальной задачи это оказалось даже преимуществом. Мне ведь хотелось знать не состояние договора с провайдером и не latency последней мили.

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

И с этим маленькая ESP32 справляется вполне успешно.

Что я вынес из этого проекта?

Технически этот проект нельзя назвать особенно сложным. ESP32 отправляет HTTP-запросы. Go принимает их. SQLite сохраняет данные. Несколько простых правил определяют состояние устройства, а Web Push сообщает о проблеме.

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

У меня таких экспериментов получилось сразу несколько.

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

Первоначально в проекте появился PostgreSQL. И это было вполне нормальным техническим решением. Можно было оставить его, добавить нормальную систему миграций, вынести frontend, подготовить инфраструктуру для нескольких backend instances, добавить Redis, очередь сообщений и постепенно получить архитектуру, способную обслуживать тысячи устройств.

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

А спросить: что действительно требуется этой системе сейчас?

Ответ оказался довольно скромным:

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

Железо имеет право испортить архитектуру

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

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

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

Мне нужен Ethernet? Или мне нужен способ понять, что офис может выйти в интернет?

Если второе — встроенный Wi-Fi решает задачу уже сегодня. В результате бракованный Ethernet-модуль неожиданно оказался хорошим архитектурным ревьюером.

Иногда лучше не заходить в сеть вообще

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

ESP32 сама инициирует соединение с внешним backend. Это сильно упростило всю конструкцию. Не нужно знать внешний адрес офиса. Не нужно принимать входящие соединения. Не нужно выставлять ESP32 наружу. Не нужно отдельно решать NAT.

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

Simulator оказался важнее, чем я ожидал

Simulator появился не в результате какого-то серьёзного архитектурного планирования.

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

Поэтому я сделал виртуальное устройство и начал строить backend вокруг него. Но временное решение осталось полезным и после появления настоящей ESP32.

Это позволило разделить две вещи:

Для проверки backend мне больше не обязательно физическое устройство. Я могу запустить simulator, создать несколько виртуальных устройств, остановить одно из них, проверить offline detection, восстановить его и посмотреть lifecycle целиком.

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

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

Особенно если доставка с маркетплейса занимает дольше, чем написание первой версии backend.

Heartbeat оказался интереснее самого heartbeat

Изначально heartbeat выглядел самой простой частью проекта.

Получили запрос — устройство работает.

Но достаточно задать следующий вопрос: а что делать, если запрос не пришёл?

И сразу появляются timeout, offline threshold, incident lifecycle, recovery policy и защита от повторных событий.

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

Pet-проект — хорошее место для изучения нового

У этого проекта с самого начала была ещё одна цель.

Мне хотелось использовать его как полигон сразу для нескольких направлений.

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

Параллельно я изучал Go и хотел написать на нём что-то большее, чем учебный HTTP-сервер.

А ещё мне хотелось проверить агентный workflow разработки. Последнее в итоге стало отдельным экспериментом внутри эксперимента.

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

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

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

ESP32 либо отправляет heartbeat, либо нет. Incident либо открывается, либо нет. Push либо приходит, либо нет.

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

Иногда нужно просто остановиться

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

• Графики доступности.
• Метрики latency.
• Packet loss.
• OTA-обновления.
• Удалённую конфигурацию Wi-Fi.
• Несколько probe в разных частях офиса.
• Prometheus.
• Grafana.
• Нормальную telemetry platform.

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

Система умеет сообщить о проблеме. LightPulse получает свой периодический сигнал. Значит, в какой-то момент нужно перестать проектировать следующую версию и признать: шалость удалась.

Послесловие: а как это вообще прошивать с Mac на Apple Silicon?

Когда основная часть проекта уже заработала, осталась ещё одна довольно практическая проблема. Разрабатывать всё это я начал на MacBook с Apple Silicon. Backend здесь никаких особых сюрпризов не преподносил: Go, Docker, SQLite — обычная рабочая среда. С ESP32 всё оказалось немного интереснее.

Для разработки firmware используется ESP-IDF — официальный framework и toolchain для ESP32. Его можно установить непосредственно на macOS, настроить зависимости, Python environment, toolchain и работать локально.

Но мне хотелось другого. После экспериментов с окружением мы пришли к довольно удобной схеме: не устанавливать и не поддерживать весь ESP-IDF toolchain на основной системе, а выполнять сборку firmware внутри Docker.

Получается примерно так:

У такого подхода оказался приятный побочный эффект. Среда сборки firmware становится практически частью самого проекта. Не нужно вспоминать, какую версию ESP-IDF я устанавливал полгода назад, какие Python-пакеты потребовались, какой toolchain лежит в системе и что я когда-то добавлял в PATH.

Есть исходный код. Есть известная версия ESP-IDF. Есть контейнер. Можно воспроизвести сборку.

Но Docker умеет не всё

Здесь, правда, обнаруживается интересная особенность macOS.

Docker Desktop на Mac работает не непосредственно на ядре macOS, а через Linux VM. Поэтому привычная для Linux идея:

с USB/serial-устройствами на macOS превращается уже не в настолько очевидную историю. А ESP32 нужно не только собрать. Её ещё нужно прошить.

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

Docker отвечает за воспроизводимую среду сборки с ESP-IDF. А непосредственную работу с serial-портом можно оставить хостовой системе и использовать отдельный инструмент для прошивки. В моём случае таким инструментом стал espflash.

Получился достаточно удобный компромисс:

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

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

И ещё раз про simulator

Здесь окончательно проявилось преимущество simulator-first подхода.

Большую часть backend-разработки вообще не нужно связывать с этим workflow.

Пока я меняю API, работу с устройствами, incidents или другую серверную логику — можно использовать simulator. Docker с ESP-IDF и физическая ESP32 нужны только тогда, когда изменения действительно затрагивают firmware.

Получилось довольно удобное разделение:

Для проекта, который начинался с вопроса «есть ли интернет в офисе?», получился вполне приличный маленький development environment.

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

Шалость удалась.

Кажется, это только начало

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

Получилось ровно наоборот. Появилось ещё больше желания продолжить эксперимент.

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

Но теперь интересно попробовать сделать следующий шаг. Например, собрать уже более полноценный network probe на базе Raspberry Pi. Это будет устройство совсем другого класса.

Если ESP32 в текущей реализации в основном отвечает на бинарный вопрос «могу ли я сейчас выйти из офисной сети наружу?», то с Raspberry Pi можно будет задавать системе гораздо больше вопросов.

И здесь мониторинг уже начинает постепенно превращаться в диагностику.

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

Например:

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

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

Тогда вместо сообщения «офис offline» со временем можно будет получать более полезную диагностику: «Офис не может выйти в интернет: локальный gateway доступен, DHCP-конфигурация сохранена, DNS-запросы не проходят, внешний узел по IP доступен» или «Устройство не видит даже gateway — вероятнее всего, проблема находится внутри локальной сети».

Это уже совсем другой уровень проекта.

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

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

Наоборот.

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

Так что шалость действительно удалась.

Просто, похоже, она ещё не закончилась.

Весь проект я вынес в открытый репозиторий на GitHub — ESP32 S3 Network Monitor.

Кратко:

• TaskIQ — async-first очередь задач для Python, удобна с FastAPI.
• Поддерживает sync и async задачи, несколько брокеров, встроенный scheduler.
• Celery зрелее и лучше подходит для Django/Flask.
• TaskIQ — для новых async-проектов; миграция с Celery оправдана не всегда.

Если приложению нужно отправить письмо, обработать изображение или выполнить запрос к внешнему API, такие операции обычно выносят в очередь задач (task queue). Благодаря этому сервер быстро отвечает пользователю, а сама задача выполняется в фоновом режиме.

Годами дефолтным выбором для этого в Python был Celery. Он проектировался до широкого распространения asyncio, и основная модель по-прежнему синхронная — async в Celery 5+ поддерживается частично.

TaskIQ — более молодой распределённый менеджер задач, изначально ориентированный на async/await. Он поддерживает и синхронные, и асинхронные задачи. В статье разберём, как устроен TaskIQ, чем он отличается от Celery на практике, что показали наши бенчмарки на TaskIQ 0.12.x, и когда переход имеет смысл.

Что такое TaskIQ

TaskIQ — это современный Python task-queue, ориентированный на async/await. Он изначально заточен под asyncio и под фреймворки вроде FastAPI, поддерживает несколько брокеров сообщений (Redis, RabbitMQ, NATS, ZeroMQ) и в целом настраивается проще, чем Celery.

Основные возможности:

• async/await — API рассчитан на асинхронный код; sync-задачи тоже поддерживаются (thread/process pool).
• Несколько брокеров — Redis, RabbitMQ, NATS, ZeroMQ; community: PostgreSQL, SQS, YDB, Kafka.
• scheduler — встроенный планировщик (cron, interval schedules, dynamic scheduling через Redis).
• Dependency Injection — TaskiqDepends() (как в FastAPI), переиспользование зависимостей между HTTP и задачами.
• retry — SimpleRetryMiddleware или SmartRetryMiddleware (middleware, подключается явно).
• Мониторинг — Prometheus (taskiq[metrics]) и OpenTelemetry (taskiq[opentelemetry], 0.12+).
• acknowledgements — --ack-type (when_saved по умолчанию), per-task ack_type, manual через Context.ack().
• type casts — автоматический парсинг аргументов по type hints (Pydantic, dataclasses).

Как устроен TaskIQ

Схема выполнения задачи выглядит так:

Приложение → Broker → Worker → Result Backend

Приложение отправляет задачу через kicker (.kiq() — сокращение для .kicker().kiq(...)). Kicker позволяет менять broker, labels, task_id и timeout на лету. Перед отправкой обязателен await broker.startup() — без этого поведение не определено. Результат — через TaskiqTask.wait_result().

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

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

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

Какие задачи лучше подходят для TaskIQ

TaskIQ лучше всего подходит для IO-bound и сетевых задач. Благодаря асинхронной архитектуре воркер не простаивает во время ожидания ответа от API, базы данных или другого внешнего сервиса. Пока одна задача ожидает завершения операции ввода-вывода, event loop может переключиться на выполнение других задач, что позволяет эффективнее использовать ресурсы.

Memory-heavy задачи TaskIQ не «лечит» сам по себе: async не снижает потребление RAM. Такие задачи имеет смысл выносить в отдельные воркеры или process pool и контролировать лимиты памяти на уровне инфраструктуры.

С CPU-bound задачами ситуация иная. Вычисления упираются в GIL и могут блокировать event loop. Для sync CPU-задач используйте --use-process-pool; для async — отдельные воркеры/очереди, чтобы тяжёлые задачи не мешали IO-bound.

Основные возможности TaskIQ

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

Поддержка нескольких брокеров

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

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

Декларация задач

В TaskIQ задачи описываются декоратором @broker.task — подход похож на Celery. Декоратор регистрирует sync или async функцию как задачу. Sync выполняется в thread pool (IO) или process pool (CPU, флаг --use-process-pool).

```python from taskiq_redis import ListQueueBroker, RedisAsyncResultBackend broker = ListQueueBroker(url="redis://localhost:6379/0").with_result_backend( RedisAsyncResultBackend(redis_url="redis://localhost:6379/1") ) @broker.task async def send_notification(user_id: int) -> None: ... # await send_notification.kiq(user_id) # CLI: taskiq worker myapp.broker:broker myapp.tasks --workers 2 --max-async-tasks 10 ```

При объявлении задачи можно указать дополнительные параметры:

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

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

Также TaskIQ поддерживает механизм shared broker. Он позволяет собрать задачи из разных частей проекта и использовать единый брокер без жёсткой привязки каждой задачи к конкретному экземпляру конфигурации.

Worker

Worker — это компонент, который получает задачи из очереди и выполняет их. TaskIQ предоставляет несколько CLI-параметров для управления его поведением.

По умолчанию --fs-discover ищет задачи в файле tasks.py. Если задачи организованы внутри отдельных пакетов, шаблон поиска можно изменить вручную.

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

Scheduler

TaskIQ включает TaskiqScheduler: cron (LabelScheduleSource), interval schedules (schedule_by_interval) и dynamic scheduling через ListRedisScheduleSource. Запуск: taskiq scheduler module:scheduler.

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

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

Основные параметры Scheduler в таблице ниже.

Важно: scheduler не выполняет задачи — только ставит их в очередь через broker. Worker выполняет. Запускайте один экземпляр scheduler; несколько инстансов могут продублировать задачи. Для timezone — поле cron_offset в расписании.

Интеграция с FastAPI

TaskIQ интегрируется с FastAPI через пакет taskiq-fastapi. Вызов taskiq_fastapi.init(broker, "myapp.main:app") подключает брокер к приложению.

Брокер нужно явно стартовать и останавливать. Предпочтительный способ — lifespan FastAPI:

@asynccontextmanager async def lifespan(app: FastAPI): await broker.startup() yield await broker.shutdown() app = FastAPI(lifespan=lifespan)

Дополнительные возможности TaskIQ

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

Dependency Injection

DI через TaskiqDepends() — по аналогии с FastAPI. Зависимости можно переиспользовать между HTTP-handlers и задачами (с учётом ограничений: Request в задаче — mock, не тот же объект, что в handler).

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

State и Context

TaskiqState — shared state воркера: инициализируется в @broker.on_event(WORKER_STARTUP) (connection pools, clients). Из задачи доступен через Context (TaskiqDepends()).

Context также даёт requeue() и reject() — вернуть задачу в очередь или отбросить без повторного выполнения. Manual ack — через await context.ack() (требует AckableMessage у broker).

Smart Retry

Smart Retry — middleware (SmartRetryMiddleware), подключается явно к брокеру. Автоматически возвращает неуспешные задачи в очередь с настраиваемым backoff и jitter. Не включён по умолчанию.

В TaskIQ можно настроить:

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

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

Для простых сценариев есть SimpleRetryMiddleware — фиксированное число повторов без backoff. SmartRetryMiddleware — для production: jitter, exponential backoff, кастомный schedule source.

Pipeline

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

Например:

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

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

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

Метрики и мониторинг

TaskIQ поддерживает Prometheus (taskiq[metrics]) и OpenTelemetry (с 0.12+). Через middleware отслеживаются:

• количество выполненных задач и ошибок;
• время выполнения;
• состояние очередей и ресурсы воркеров (OTel).

Тестирование задач

Для проверки логики задач TaskIQ предоставляет in-memory broker. Он позволяет запускать задачи без подключения Redis, RabbitMQ или другого внешнего брокера. Это удобно для юнит-тестов: разработчик может проверить работу бизнес-логики, обработку ошибок и сценарии выполнения задач без дополнительной инфраструктуры.

Для тестов — InMemoryBroker: тот же интерфейс, без сети. Типичный паттерн: подмена broker по ENVIRONMENT=pytest. Задачу можно вызвать как обычную async-функцию или через .kiq() + wait_result(). Для fire-and-forget — await_inplace=True или broker.wait_all(). С FastAPI — taskiq_fastapi.populate_dependency_context().

Практические рекомендации для работы с TaskIQ

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

• Разделяйте задачи по типу нагрузки — отдельный брокер для CPU-bound, отдельный для IO-bound (cpu_tasks.py, io_tasks.py).
• Оборачивайте задачи в try-except и подключайте SmartRetryMiddleware. Для Redis используйте taskiq-redis (Streams/ListQueue) и настраивайте --ack-type (when_saved, when_executed, manual). Надёжность зависит от брокера и ack-политики, а не только от «Redis vs RabbitMQ».
• Используйте async/await везде, где это возможно, а не только в отдельных задачах.
• Настройте мониторинг — Prometheus или OpenTelemetry плюс структурированные логи.
• Вызывайте await broker.startup() в клиенте и broker.shutdown() при остановке.
• Настройте timeouts для долгих задач: @broker.task(timeout=30) или .kicker().with_labels(timeout=30).kiq().
• Для sync CPU-bound — --use-process-pool; для sync IO — thread pool (default).
• --max-prefetch имеет смысл только с брокерами, поддерживающими ack.
• Установите uvloop — TaskIQ подхватит его автоматически, если пакет есть.

Ограничения TaskIQ

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

Меньше production-кейсов, чем у Celery

TaskIQ активно развивается (документация на taskiq-python.github.io заметно выросла), но community и production-историй всё ещё меньше, чем у Celery (~2.2k vs ~28k stars на GitHub).

• меньше готовых решений для нестандартных edge cases;
• меньше battle-tested примеров из крупных prod-систем;
• часть архитектурных решений придётся валидировать своими нагрузочными тестами.

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

Scheduler не сохраняет состояние между перезапусками

У встроенного планировщика TaskIQ есть ограничение: он не хранит информацию о предыдущих запусках между перезапусками.

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

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

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

Scheduler работает только в одном экземпляре

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

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

TaskIQ vs Celery

Celery — один из самых популярных инструментов для выполнения фоновых задач в Python. Проект существует более 15 лет, имеет большое сообщество, множество интеграций и активно используется в production-системах, особенно в проектах на Django.

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

TaskIQ появился позже и изначально создавался с учетом современных асинхронных подходов Python. Его основная идея — нативная работа с async/await и удобная интеграция с асинхронными фреймворками.

Основные отличия TaskIQ и Celery привёл в таблице ниже.

Производительность TaskIQ и Celery

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

Наибольшая разница наблюдается в IO-bound сценариях: запросах к API, работе с внешними сервисами и другими операциями ожидания. Это связано с async-first архитектурой TaskIQ — пока одна задача ожидает ответа, воркер может выполнять другие операции.

Для CPU-bound задач преимущество меньше, поскольку такие операции ограничиваются особенностями Python и GIL (Global Interpreter Lock). Асинхронность не ускоряет сами вычисления, поэтому прирост зависит от конкретной архитектуры выполнения.

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

Отдельно стоит учитывать влияние дополнительных компонентов. Например, при использовании TaskIQ Admin производительность может снижаться из-за дополнительной нагрузки от мониторинга и middleware. Поэтому перед внедрением в production рекомендуется проводить собственные нагрузочные тесты.

Когда выбирать Celery и TaskIQ

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

Стоит ли мигрировать с Celery на TaskIQ

Если задачи уже вынесены в отдельные функции, технический переход умеренный, но это не «замена декоратора»: нужно сменить .delay() → .kiq(), настроить broker startup/shutdown, Celery Beat → TaskIQ Scheduler, retry через middleware. Миграция оправдана не всегда.

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

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

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

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

Во многих проектах используется один и тот же брокер — например Redis или RabbitMQ. Поэтому широкий выбор брокеров TaskIQ не всегда становится решающим преимуществом.

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

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

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

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

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

BPMN (Business Process Model and Notation) — это способ показать бизнес-процесс в виде простой схемы. Вместо длинных описаний используются блоки, стрелки и значки, которые помогают быстро понять, что происходит, кто за что отвечает и в каком порядке выполняются действия.

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

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

Где применяется BPMN

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

Чаще всего BPMN применяют в таких задачах:

• Анализ процессов. Сначала рисуют, как процесс работает сейчас (AS IS), а затем создают схему того, как он должен работать после изменений (TO BE). Например, показывают, как сейчас обрабатываются заявки клиентов и как этот процесс можно ускорить.
• Разработка информационных систем. Диаграмма помогает заранее понять, как будут взаимодействовать пользователи, сайт, приложение и другие сервисы. Это снижает вероятность ошибок во время разработки.
• Документирование. BPMN используют в регламентах, инструкциях и при обучении новых сотрудников. Вместо нескольких страниц текста достаточно одной понятной схемы.
• Проектирование новых процессов. Перед внедрением нового процесса его можно нарисовать и обсудить со всеми участниками. Так проще заметить ошибки и согласовать логику до начала работы.

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

Основные элементы BPMN-диаграммы: участники, действия и потоки

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

Пулы и дорожки: кто участвует в процессе

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

Пул (Pool) — это участник процесса. Им может быть компания, клиент, банк, курьерская служба или любая внешняя система.

Внутри пула находятся дорожки (Lanes). Они показывают роли или отделы. Например: «Клиент», «Менеджер» и «Бухгалтер». Благодаря этому сразу видно, кто выполняет каждое действие.

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

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

Действия и потоки: как выполняется процесс

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

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

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

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

События в BPMN

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

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

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

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

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

Специальные действия и циклы в BPMN

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

Выполнение бизнес-правила

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

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

Цикл по объектам

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

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

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

Развилки (шлюзы): как процесс может идти по разным сценариям

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

Основные виды шлюзов:

• Исключающий (XOR) — выбирает только один вариант. Например, если заявка одобрена, её отправляют в работу. Если нет — отклоняют.
• Параллельный (AND) — запускает несколько действий одновременно (после оформления заказа клиенту приходит уведомление, а на складе сразу начинают собирать товар).
• Шлюз по событиям (Event-based Gateway) — ждёт, какое событие произойдёт первым. Например, клиент подтвердит заказ или закончится время ожидания.
• Неисключающий (OR) — может запустить сразу одну или несколько веток. Например, заявку одновременно отправляют в бухгалтерию и юридический отдел, если для этого выполняются нужные условия.

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

Когда стоит использовать BPMN

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

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

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

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

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

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

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

Зачем компании собственный сайт в 2026 году?

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

Какие есть типы сайтов?

Выбор зависит от того, какую задачу сайт должен решать:

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

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

Что важно при создании сайта?

Базовый уровень — это защищённое соединение (SSL и HTTPS). Если сайт собирает заявки, заказы или любые персональные данные, он должен соответствовать требованиям 152-ФЗ: корректная политика обработки данных, согласие пользователя и правильно настроенные формы.

Скорость сайта влияет и на поведение пользователей, и на позиции в поиске. Оценивается она через метрики Core Web Vitals:

• LCP — как быстро появляется основной контент.
• INP — насколько быстро сайт реагирует на действия.
• CLS — «прыгает» ли интерфейс при загрузке.

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

Проверку обычно проводят через PageSpeed Insights и Lighthouse.

API и интеграции

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

Аналитика и масштабирование

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

На каких платформах можно разработать сайт?

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

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

CMS для корпоративных сайтов:

• WordPress — самая популярная CMS в мире. Подходит для корпоративных сайтов, блогов, каталогов и небольших интернет-магазинов. Большое количество готовых тем и плагинов позволяет быстро запустить проект, но для стабильной работы системе требуется регулярное обновление и техническая поддержка.
• 1С-Битрикс — одна из самых популярных CMS в России для бизнеса. Подходит для корпоративных сайтов, интернет-магазинов и крупных проектов. Отличается широкими возможностями, развитой экосистемой и удобной интеграцией с продуктами 1С.
• NetCat — российская CMS для корпоративных сайтов, каталогов и интернет-магазинов. Ценится за высокую производительность, гибкость и удобную административную панель. Часто используется в коммерческих проектах и государственных организациях.
• MODX — CMS для проектов с нестандартным дизайном и структурой. Даёт разработчикам больше свободы при создании сайта, но требует более высокой технической квалификации.
• Joomla — универсальная CMS, которая подходит для корпоративных сайтов, информационных порталов и сообществ. Сегодня используется реже, чем WordPress, но остаётся хорошим выбором для отдельных задач.
• Drupal — система для крупных корпоративных порталов, образовательных проектов и государственных сайтов. Отличается высокой безопасностью и гибкими настройками прав доступа, однако требует опытной команды разработчиков.

CMS для интернет-магазинов:

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

Фреймворки для индивидуальной разработки:

• Laravel — один из самых популярных PHP-фреймворков для создания сложных веб-проектов, личных кабинетов, CRM и нестандартных сервисов. Позволяет реализовать практически любую бизнес-логику.
• Ruby on Rails — фреймворк, известный высокой скоростью разработки MVP и веб-сервисов. Часто используется стартапами и SaaS-проектами.

По данным рынка CMS в 2026 году, WordPress остаётся лидером и используется более чем на 40% всех сайтов в мире.

Кому нужны сайты?

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

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

Базовые функции сайта:

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

Сколько стоит разработка сайта и интернет-магазина?

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

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

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

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

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

С чего начать путь?

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

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

• UX/UI-дизайн;
• программирование;
• тестирование;
• запуск.

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

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

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

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

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

Какие бывают мобильные приложения?

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

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

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

Миллион рублей на запуск приложения: достаточно ли этого?

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

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

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

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

Функционал базового мобильного приложения

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

В базовый функционал входят:

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

Как устроена работа над проектами изнутри?

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

Приложение для бронирования (картинг-центр)

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

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

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

На этапе аналитики команда собирает и формализует требования, проектирует пользовательские сценарии (User Flow), продумывает архитектуру решения и подготавливает техническое задание. На эти задачи уходит от 50 до 71 часа.

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

Самым трудоёмким этапом становится backend-разработка — от 159 до 233 часов. Специалист реализует:

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

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

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

Дополнительно в проекте участвует DevOps-инженер, который настраивает серверную инфраструктуру, CI/CD и рабочие окружения. На эти работы требуется от 18 до 29 часов.

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

Мобильный интернет-магазин

Второй пример — мобильное приложение для розничной сети. Проект включает каталог товаров, разделы с акциями и новинками, карту лояльности с QR-кодом, отображение магазинов на карте, push-уведомления и публикацию приложения в App Store и Google Play.

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

Backend-разработчик проектирует архитектуру решения, реализует серверную логику, регистрацию и авторизацию пользователей, систему лояльности, управление контентом, push-уведомления, административную панель и интеграцию с картографическим сервисом. На эти задачи требуется от 118 до 196 часов.

Мобильный разработчик реализует:

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

Общий объём работ составляет от 116 до 180 часов.

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

Монетизация мобильных приложений

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

Бесплатная модель с платными функциями (freemium)

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

Подписка

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

Реклама внутри приложения

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

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

Влияние визуала и карточки приложения

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

Сама публикация приложений в Google Play, RuStore и App Store часто оказывается сложнее, чем кажется на первый взгляд. Каждая площадка предъявляет собственные требования к сборке, безопасности, оформлению карточки и процессу модерации. Ошибки на этом этапе могут привести к отклонению приложения или задержке релиза.

Иконка приложения

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

Скриншоты в карточке

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

Адаптация карточки (ASO)

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

Можно ли сделать больше за те же деньги?

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

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

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

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

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

Разработчики уровня Senior умеют оценивать результат работы AI и направлять его в нужное русло. По опыту индустрии, такие специалисты повышают свою продуктивность на 40–50% при грамотном использовании ИИ-инструментов.

Искусственный интеллект также позволит сократить время и трудозатраты на рутинные процессы QA. Он ускоряет создание и поддержку тест-кейсов, уменьшает объём ручного регрессионного тестирования, помогает раньше находить ошибки и нестандартные сценарии и легко встраивается в CI/CD-процессы. В результате релизы выходят быстрее, а нагрузка на команду тестирования снижается, без потери качества продукта.

Почти половина (около 41%) всего кода в мире создается с помощью искусственного интеллекта. Новая мода на программирование с AI называется — vibe coding.

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

Скорость действительно впечатляет! Команды сообщают о сокращении сроков выполнения задач более чем на 50%, а небольшие команды из 2–5 разработчиков — до 68%. Но вместе со скоростью появляется новая проблема.

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

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

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

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

Кто использует вайб-кодинг сегодня

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

Популярность подхода продолжает расти. По прогнозам, к 2026 году до 40% новых SaaS MVP будут создаваться преимущественно с помощью вайб-кодинга. Это позволяет быстрее проверять гипотезы, запускать прототипы и сокращать затраты на разработку на ранних этапах проекта.

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

В каких отраслях ИИ сейчас популярно?

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

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

Риски и последствия, которые могут быть после разработки с помощью ИИ

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

Исследование State of Vibe Coding 2026 зафиксировало: AI-сгенерированный код содержит в 1,7 раза больше серьёзных ошибок и почти в 3 раза больше уязвимостей безопасности по сравнению с кодом, написанным опытными инженерами вручную.

40% junior-разработчиков признаются, что хотя бы раз отправляли в продакшен AI-сгенерированный код, который понимали не полностью. А в опросе 18 CTO по итогам 2025 года 16 из них сообщили о production-катастрофах, напрямую вызванных AI-сгенерированным кодом.

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

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

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

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

ИИ — инструмент в руках опытного разработчика

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

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

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

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

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

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

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

Почему роль Senior-разработчиков растёт, а не падает

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

Опытные инженеры с 3+ годами стажа сообщают о росте продуктивности на 40–50% при работе с AI — против нестабильных результатов у джунов.

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

Как правильно использовать AI-инструменты в программирование и не потерять контроль над качеством?

Большинство разработчиков используют AI для прототипов и экспериментов.

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

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

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

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

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

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

Что происходит с рынком тестирования в 2025–2026 годах?

По данным аналитиков рынка, уже около 40% компаний используют ИИ в тестировании — и это только начало. Примерно 80% команд разработки будут интегрировать AI-инструменты в QA-процессы в ближайший год.

Также на пике популярности новый класс систем — AI/ML/LLM-решения, поведение которых принципиально отличается от обычного ПО. Их нельзя проверить традиционными методами QA: они не выдают детерминированный результат.

Однако развитие автоматизации и искусственного интеллекта не означает отказ от ручного тестирования. В 2026 году на ручное тестирование будет приходиться около 62,5% рынка, тогда как доля автоматизированного тестирования составит 37,5%.

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

Что говорят исследования про использование ИИ в автоматизации тестирования?

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

По сравнению с традиционной автоматизацией результаты выглядят так:
- точность выявления дефектов вырастает примерно с 76% до 90%;
- полнота тестового покрытия — с 82% до 95%;
- время разработки и выполнения тестов сокращается примерно на четверть.
Общая стоимость тестирования при этом также снижается до 25%

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

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

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

Какую часть работы автоматизирует ИИ в тестировании?

QA-задачи съедают в среднем 25% IT-бюджета компании. Большая часть этих затрат — не на сложные задачи, а на рутину:

• написание тест-кейсов;
• прогон регрессии;
• починку сломанных тестов после обновлений UI;
• разбор логов.

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

Ниже расписали задачи, которые можно передать ИИ.

Кому нужен искусственный интеллект в тестирование?

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

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

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

• создание автотестов ускоряется в 3–5 раз;
• тесты можно запускать в 8–20 раз чаще без расширения команды;
• нагрузка на QA-специалистов снижается на 15–20%;
• стабильность продукта повышается;
• расходы на разработку и исправление ошибок могут сократиться до 28%.

Тестирование AI-моделей: когда ваш продукт сам использует ИИ

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

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

При тестировании AI-решений важно проверять несколько ключевых параметров:

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

Именно поэтому для AI-, ML- и LLM-решений применяются отдельные методики тестирования, которые учитывают особенности работы моделей и помогают выявлять проблемы ещё до выхода продукта в продакшен.

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

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

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

Рынок IT-аутстаффинга

Данные SkillStaff подтверждают устойчивый спрос на внешних специалистов в ИТ. В ближайшие три года компании планируют наращивать затраты на все форматы привлечения: разработка на аутсорсе, штатные разработчики и IT-аутстаффинг показывают ожидаемый рост в диапазоне 17–23% ежегодно. При этом IT-аутстаффинг стабильно держится в середине — около 18% роста в год, — что говорит о зрелом и предсказуемом спросе, а не о хайповом всплеске.

Если смотреть по отраслям: лидером по доле аутстаффинга в IT-затратах оказался ритейл (26%), тогда как в телекоммуникациях этот показатель минимален (8%). Аутстаффинг востребован там, где бизнес быстро меняется и нужна гибкость в наборе команды — без долгосрочных обязательств по штату.

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

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

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

Например, в LighTech мы помогаем заказчику сформулировать требования к команде ещё на этапе онбординга — и подбираем специалистов уровня Middle+ и Senior, которые встраиваются в рабочие процессы с первого дня.

Какие роли могут быть в команде IT-аутстаффинга?

Frontend-разработчики

Фронтенд-разработчики отвечают за всё, что пользователь видит и с чем взаимодействует в браузере или приложении: интерфейсы, анимации, адаптивную вёрстку. Они работают с JavaScript, TypeScript, React, Vue и другими фреймворками, умеют интегрировать API и следят за производительностью клиентской части.

Когда нужен frontend-специалист:

• У вас есть рабочий бэкенд, но нет качественного пользовательского интерфейса.
• Нужна доработка или редизайн существующего веб-приложения.
• Требуется специалист по конкретному стеку — например, только React или только Vue.

Backend-разработчики

Backend — это «двигатель» любого цифрового продукта. Бэкенд-разработчик строит серверную логику, проектирует базы данных, создаёт API и обеспечивает безопасность передачи данных. Работает на Python, Node.js, Java, Go, PHP и других языках в зависимости от требований проекта.

Когда нужен backend-специалист:

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

iOS-разработчики и Android-разработчики

Нативные мобильные разработчики создают приложения под конкретные платформы — iOS или Android. iOS-разработчики работают со Swift и Objective-C, используют возможности экосистемы Apple и обеспечивают высокую производительность приложений на iPhone и iPad.

Android-разработчики используют Kotlin и Java, учитывают особенности разных устройств и версий ОС, а также работают с Android SDK и Google Play.

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

Когда нужны мобильные разработчики для Android и iOS:

• Запускается новое мобильное приложение под iOS или Android.
• Требуется поддержка и развитие существующего приложения.
• Нужна высокая производительность, офлайн-режим или интеграция с функциями смартфона.
• Планируется публикация и сопровождение приложения в App Store или Google Play.

Flutter-разработчики

Flutter — кроссплатформенный фреймворк от Google, позволяющий создавать приложения сразу для iOS, Android, web и desktop из единой кодовой базы. Такой подход помогает быстрее запускать цифровые продукты, поддерживать единый интерфейс на разных платформах и оптимизировать затраты на разработку.

Когда нужен Flutter-разработчик:

• Нужно запустить приложение одновременно под iOS и Android.
• Важно сократить сроки и стоимость разработки.
• Требуется единый интерфейс и логика для всех платформ.
• Нужен MVP или быстрый запуск нового цифрового продукта.

UX/UI-дизайнеры

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

Когда нужен UX/UI-дизайнер:

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

QA-инженеры

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

QA-специалисты работают как с ручным тестированием, так и с автоматизацией: Selenium, Cypress, Appium — в зависимости от стека проекта.

Когда нужен QA-инженер:

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

DevOps-инженеры

DevOps-инженер выстраивает CI/CD-пайплайны, управляет облачной инфраструктурой (AWS, GCP, Azure), настраивает мониторинг и обеспечивает надёжность развёртывания. Без сильного специалиста даже хорошо написанный код может стать причиной даунтаймов и потерь.

Когда нужен DevOps-инженер:

• Настройка и поддержка CI/CD (GitHub Actions, GitLab CI, Jenkins).
• Контейнеризация и оркестрация (Docker, Kubernetes).
• Мониторинг и алертинг (Prometheus, Grafana, Datadog).
• Управление облаком и оптимизация затрат.

Системные аналитики

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

Когда нужен системный аналитик:

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

Бизнес-аналитики

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

Когда нужен бизнес-аналитик:

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

Продакт-менеджеры (Product Manager)

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

Когда нужен Product Manager:

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

Проджект-менеджеры (Project Manager)

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

Когда нужен Project Manager:

• Проект выходит за рамки работы 1–2 специалистов.
• Команда не укладывается в сроки.
• Нужно выстроить процессы и контроль задач.
• Требуется единая точка коммуникации между заказчиком и командой.

Как понять, каких специалистов нужно подключить

Ответ зависит от стадии проекта и задач.

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

Аутстаффинг VS Аутсорсинг

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

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

Иногда задачи в проектах выглядят очень просто… Пока ты не начинаешь их делать.

У нас был проект с уже внедрённым поиском на OpenSearch. Всё работало: индексы, фильтры, кастомная логика запросов — даже своя «мини-ORM» над поиском, через которую фронтенд отправлял сложные query.

И в какой-то момент пришло решение: «Давайте просто заменим OpenSearch на TypeSense.»

Спойлер: это никогда не бывает «просто».

Почему решили менять OpenSearch на TypeSense

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

Главная проблема: нельзя ломать фронт

Самое важное ограничение — фронтенд не должен заметить никаких изменений.

То есть API остаётся тем же, структура запросов остаётся той же, поведение поиска остаётся тем же. А внутри — полностью другой движок.

Что это означало на практике

Мне нужно было брать запросы, заточенные под OpenSearch, трансформировать их, отправлять в TypeSense и возвращать результат в прежнем формате. По сути — написать полноценный адаптер между двумя разными мирами.

Где всё пошло не по плану

Ожидание: «Ну там клиент поменять и пару запросов поправить».

Реальность:

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

Например: в OpenSearch — гибкий DSL, который позволяет строить запросы практически любой сложности. В TypeSense — упор на простоту и скорость, с намеренно ограниченным синтаксисом. И просто «переконвертировать JSON» не работает — нужно переосмыслить логику запросов целиком.

Что пришлось реально переписать

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

Сжатые сроки и немного боли

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

Где реально помог ИИ

Без ИИ-ассистента я бы эту задачу не закрыл в срок. Серьёзно.

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

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

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

Как это выглядело на практике

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

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

Аналогия (жизненная)

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

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

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

Выводы

1. Замена поискового движка — это не замена клиента, это замена архитектуры.

2. Разные search engines — это разные философии, а не просто разный синтаксис.

3. Самое сложное — сохранить поведение 1:1 без изменений на стороне потребителя.

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

Главная мысль

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

Итог

Да, я сгорел. Да, это было сложно. Но без ИИ это было бы в разы дольше и болезненнее. А время, как известно, — это деньги.