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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источники

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

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

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

Почему покупка инструмента ничего не даёт

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

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

Шесть мест, где прежнее управление даёт сбой

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

Встречи. Половину планёрки съедает пересказ статусов: работу памяти делают живые люди в самое дорогое время команды.

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

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

Делегирование. Задача уходит строчкой в трекере, картина остаётся у постановщика, дальше недели переписки «я не то имел в виду».

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

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

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

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

Три операции, которые стали дефицитом

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

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

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

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

Кто такой руководитель нового типа

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

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

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

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

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

Что это дало в цифрах

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

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

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

Есть и внешний замер. Доля положительных ответов по опроснику Gallup Q12 в направлении выросла до 86,7%, плюс 6,6 процентных пункта, и сильнее всего вырос пункт «получал признание за последние семь дней», плюс 16,6. Отнести это целиком на свою систему я не могу, в тот же период менялось многое. Но выросло сильнее всего ровно то, чем она занимается.

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

Делегировать надо контекст, а не строчку

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

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

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

С чего начинать

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

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

Что происходит с рутиной и с самим руководителем

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

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

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

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

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

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

Если говорить прямо, то виз, которые реально подходят IT-специалистам, не так уж и много: O-1 (та самая «виза талантов»), H-1B, L-1 и иногда J-1 для стажировок.

Начнём с визы L-1. Она подходит тем, кто уже работает в компании за пределами США и переводится в американский офис. Виза L-1 даёт возможность иностранным компаниям переводить сотрудников со специализированными знаниями или управленческими должностями в свои дочерние структуры в США. Очень часто ей пользуются владельцы бизнеса за рубежом, которые хотят открыть филиал или запустить новый бизнес в Америке. При этом важно, чтобы зарубежная компания была реально действующей: оцениваются её обороты, прибыльность, наличие офиса, сотрудники, объём продаж, клиенты и контракты.

H-1B — одна из самых известных рабочих виз. Она позволяет американскому работодателю привезти иностранного специалиста, на позиции, требующие высшего образования. Все заявки участвуют в ежегодной лотерее, которая проходит в марте, и только отобранные кейсы идут дальше на рассмотрение. Виза выдаётся на три года с возможностью продления ещё на три. Её плюс в том, что не нужно доказывать выдающиеся достижения — достаточно профильного образования или релевантного опыта. Но важно понимать: подать на H-1B самостоятельно нельзя, петицию подаёт только работодатель. Участвовать в лотерее можно несколько раз. После выигрыша работодатель платит государственную пошлину за своего сотрудника в размере $100 000 за подачу петиции в USCIS.

И наконец, O-1 — виза талантов, то есть виза для людей с выдающимися способностями. Эта виза предоставляет максимальную профессиональную свободу: можно работать с несколькими компаниями и выстраивать более гибкую карьеру. Для IT речь идет о категории O-1 в области науки (Computer Science), и требования здесь выше, чем, например, для креативных профессий.

Для O-1 важно показать реальные достижения. Это может быть опыт работы в известных компаниях — Google, Amazon, Uber, Яндекс — и, да, такие бренды в резюме дают дополнительные очки, но это не единственный путь. У IT-специалистов часто бывают патенты на разработки, и здесь важно, чтобы имя было указано в самом патенте. Также учитывается участие в создании продуктов, которые затем патентуются, публикации в профессиональных или научных изданиях, участие в жюри конкурсов и в целом вклад в развитие индустрие индустрии инновационных продуктов.

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

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

Но это не значит, что нужно «подгонять себя» под тренд. Если у вас нет опыта в AI/ML, это не закрывает возможность получить визу талантов O-1. Если вы сильный специалист в своей нише и можете это доказать, шансы остаются высокими.

Помимо этого, достаточно много кейсов у специалистов в software development и systems engineering. Хорошо подходят product managers и особенно кандидаты на высоких позициях, таких как Chief Technology Officer. Сложнее — специалистам в области quality assurance, но и это не исключает возможность получения визы.

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

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

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

Что такое DR-план и какие задачи он закрывает

План аварийного восстановления (disaster recovery plan, DRP) — это документ, который фиксирует, что и в каком порядке нужно делать, чтобы вернуть ИТ-системы к жизни после серьёзного сбоя. В нём прописаны ситуации, от которых защищаемся, приоритеты восстановления сервисов, ответственные люди, доступы, целевые сроки и критерий, по которому аварию считают закрытой.

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

Чем DR-план отличается от резервного копирования

Резервное копирование в облако и DR часто путают. Бэкап отвечает за наличие копии данных. DR-план отвечает за восстановление работающего сервиса в заданный срок с заданным процентом потери данных.

Разницу легко понять на примере.

У компании есть резервные копии всех баз. Они лежат на отдельном хранилище, регулярно обновляются. Всё хорошо. Но в один день дата-центр становится недоступным из-за аварии на подстанции, а ИБП и ДГУ не справились с нагрузкой. Серверы выключены, доступ к ним потерян. Копии есть, но развернуть их негде — резервной площадки нет. А даже если она есть, никто не отрабатывал их восстановление, а потому доподлинно не знает, в какой последовательности поднимать сервисы, кто за что отвечает, какие пароли использовать и т.п.. Копии есть, а работающего сервиса нет. DR-план как раз и закрывает эту проблему: он описывает, как из копий собрать работающую систему в нужный срок.

Как DR-план связан с BCP

BCP (business continuity plan) — это план непрерывности бизнеса. Он описывает, как компания будет работать в кризисной ситуации в целом: куда переедет офис, как сотрудники будут связываться друг с другом, как выполнять ключевые бизнес-функции без привычных инструментов. DR-план — это часть BCP, его ИТ-составляющая.

Порядок разработки обычно такой: сначала проводится бизнес-анализ (BIA — business impact analysis) и составляется перечень критичных бизнес-процессов. Для каждого процесса определяют, какие ИТ-системы его обеспечивают. И уже под эти системы пишут DR-план. Не наоборот. Нельзя взять и описать восстановление всех систем подряд — нужно понимать, какой сервис для чего нужен и сколько компания готова за него заплатить.

Сколько стоит простой и как это меняет требования к плану

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

В июне 2026 года на Cnews были опубликованы результаты CX-исследования, проведённого на основе глубинных интервью со 180 заказчиками. У 39% компаний за последний год стоимость часа простоя значительно выросла. Ещё 35% сказали, что она осталась на прежнем уровне. 14% отметили снижение благодаря внедрению резервных систем и процедур.

Рост стоимости простоя связан с несколькими факторами:

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

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

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

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

Ещё один способ снижать потери от недоступности ИТ-систем — страхование в облаке: решение, которое помогает управлять рисками и рационально распределять финансовые потоки. Провайдер Linx Cloud предлагает собственную инфраструктуру на базе двух сертифицированных ЦОД уровня TIER III в Москве и Санкт‑Петербурге, что позволяет строить катастрофоустойчивые архитектуры с гарантированным уровнем доступности.

Как рассчитать RTO и RPO для своих систем

RTO (Recovery Time Objective) — это время, за которое система должна быть восстановлена после аварии. Считается от момента, когда принято решение о переключении на резерв, до момента, когда сервис снова доступен пользователям.

RPO (Recovery Point Objective) — это допустимый объём потери данных. Показывает, на сколько часов (или минут) можно откатить систему назад. Если RPO = 1 час, значит, при аварии допустима потеря данных, созданные не более чем за последний час. Всё, что было раньше, должно сохраниться.

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

Методика расчёта идёт от бизнеса, а не от ИТ. Сначала считают, сколько компания теряет за час простоя конкретного сервиса. Потом определяют, какой простой бизнес готов терпеть, — это и будет RTO. Аналогично с RPO: оценивается, сколько данных можно потерять без катастрофических последствий.

Пример.

Интернет-магазин с выручкой 5 млн руб. в сутки. В пиковые часы (10:00–22:00) это около 300–400 тысяч в час. Допустим, бизнес готов терпеть простой не больше двух часов — иначе убытки (денежные и репутационные) становятся критическими. Значит, RTO = 2 часа. Потеря данных за час — это потеря заказов, которые могли бы быть оформлены. Если за час через сайт проходит 30 заказов на сумму 50 тыс. руб., бизнес может с этим смириться. RPO = 1 час. Если такая потеря неприемлема, нужно снижать RPO до 15–30 минут и использовать более частую репликацию.

Матрица критичности сервисов

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

Типичные ошибки при назначении показателей

1. RTO назначает ИТ-отдел без согласования с бизнесом. Инженеры берут цифры «с потолка», исходя из того, что им кажется разумным или на что хватает существующих ресурсов. Бизнес потом удивляется, почему платёжная система простаивала четыре часа, хотя каждый час простоя стоит миллион. RTO должен утверждаться на уровне топ-менеджмента — это бизнес-решение, а не техническое. Часто после оценки стоимости обеспечения RTO со стороны ИТ, бизнесу приходится корректировать свои аппетиты и пересматривать метрику. Но в конечном итоге она точно должна согласовываться бизнесом.
2. Один общий показатель на все системы. Платёжный шлюз и система для внутренних отчётов не могут восстанавливаться за одно и то же время. Это просто-напросто сжигание бюджета расфокусировка ИТ команды. Разные уровни критичности систем — разные RTO и RPO.
3. В RTO не заложено время на принятие решения и проверку данных. В плане написано «восстановить за 2 часа», но забыли, что сначала нужно созвониться, принять решение о переключении,. Реальное время может оказаться в два раза больше, если процесс инициации восстановления не описан и не отработан..
4. Показатели ни разу не подтверждались измерением на реальном восстановлении. RTO и RPO, которые никто не проверял, — это просто цифры в документе. Без тестов они не имеют никакой ценности.

Из каких разделов состоит рабочий DR-план

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

1. Область действия и перечень охваченных систем. Чётко указать, какие сервисы, площадки и компоненты инфраструктуры входят в план, а какие — нет. Если какой-то сервис не охвачен, это должно быть написано явно.
2. Карта сервисов и зависимостей. Схема, которая показывает, как сервисы связаны друг с другом и с внешними системами. Если упадёт база данных, какие приложения перестанут работать? Если откажет внешний API, что сломается внутри? Без этой карты восстановление существенно усложняется.
3. Целевые RTO и RPO по каждому сервису. Таблица с показателями для каждого сервиса из перечня. Цифры должны быть согласованы с бизнесом и утверждены.
4. Роли, зоны ответственности, матрица эскалации. Кто принимает решение о переключении на резерв. Кто выполняет технические действия. Кто проверяет целостность данных. Кто связывается с подрядчиками. Кто информирует руководство и пользователей. Если ответственный недоступен, кто его заменяет. Схема связи при недоступности корпоративных каналов — телефоны, мессенджеры, резервная почта.
5. Критерии активации плана и лица, принимающие решения. План не активируется автоматически при любом сбое. Должны быть чёткие критерии: время недоступности, характер отказа, оценка ущерба. И конкретный человек (или группа), который принимает решение и даёт команду «переключаемся на резерв».
6. Пошаговые сценарии восстановления (runbook). Самая объёмная часть. Для каждого сценария — последовательность команд, скриншоты интерфейсов, порядок проверок. Runbook должен быть настолько подробным, чтобы по нему можно было восстановить систему даже в 3 ночи в выходной.
7. Доступы, учётные записи, ключи шифрования, места хранения резервных копий. Где лежат пароли, как получить доступ к резервным копиям, если основная площадка недоступна, какие ключи нужны для расшифровки данных. Вся эта информация хранится отдельно от основного документа, в защищённом месте, но в плане должно быть описано, как до неё добраться.
8. Процедура проверки целостности данных после восстановления. После того как системы подняты, нужно убедиться, что данные не повреждены и доступны для использования информационными системами и конечными пользователями Эта процедура прописывается для каждого типа систем отдельно.
9. Критерии завершения аварии и порядок возврата на основную площадку. Авария считается закрытой, когда все критичные сервисы работают на резервной площадке и пользователи получили доступ. Но рано или поздно нужно вернуться на основную площадку — в плане указано, как это делается, в какой последовательности и с какими проверками.
10. Контакты подрядчиков, провайдеров, вендоров с номерами договоров и SLA. Когда падает оборудование, нужно звонить поставщику, когда отказывает облако — провайдеру. В плане должны быть актуальные контакты, номера договоров и согласованные SLA по времени реакции и решения инцидентов.
11. Журнал версий и ответственный за актуализацию. DR-план — живой документ. В нём фиксируется, кто и когда вносил изменения, какая версия сейчас действует, кто отвечает за его обновление.

Сценарии аварий, которые нужно описать в плане

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

Отказ отдельного узла или дискового массива. Самый частый сценарий. Отказал один сервер или СХД . Признак: сервер недоступен, ошибки в логах хранилища. Первое действие: переключить нагрузку на другой узел в том же ЦОД. Целевой RTO: 15–30 минут. Восстановление происходит в пределах одной площадки, без переключения на резервный ЦОД.

Полная потеря площадки. Авария в ЦОД — пожар, затопление, отключение электричества, обрыв кабеля на входе. Признак: все сервисы на площадке недоступны одновременно. Первое действие: активировать резервную площадку, переключить DNS. Целевой RTO: от 1 до 4 часов в зависимости от класса сервиса.

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

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

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

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

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

Как выбрать резервную площадку и схему аварийного восстановления ИТ-инфраструктуры

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

Холодный, тёплый и горячий резерв

DRaaS как резервная площадка

DRaaS (Disaster Recovery as a Service) — модель, при которой резервная площадка арендуется у провайдера. Компания не строит собственный резервный ЦОД, а использует облачную инфраструктуру провайдера.

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

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

До подписания договора задайте провайдеру несколько вопросов:

• Какой RPO может обеспечить сервис?
• Как часто можно проводить тестовые переключения без дополнительной оплаты?
• Где физически размещены данные — в каком регионе, в каком ЦОД?
• Кто выполняет переключение — команда провайдера/ собственная команда заказчика/совместно?
• Как организована поддержка в нерабочее время и в выходные?

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

Разнесение площадок и каналы связи

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

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

Вариант размещения оборудования в ЦОД — colocation, то есть использование сторонних площадок для своих ресурсов. Задействуются виртуальные частные сети — выделенные каналы связи L2VPN.

Требования регуляторов РФ к плану восстановления

Для многих компаний DR-план — юридическое требование.

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

152-ФЗ о персональных данных. Операторы персональных данных обязаны обеспечивать восстановление данных, изменённых или уничтоженных вследствие несанкционированного доступа. Требования детализированы в постановлении Правительства № 1119 и приказе ФСТЭК № 21. Приказ ФСТЭК № 21 содержит группу мер по обеспечению доступности, включая резервирование и восстановление. Актуальная редакция приказа — от 14 мая 2020 года. С 1 сентября 2026 года вступают в силу новые меры, в том числе защита от современных угроз.

187-ФЗ о безопасности критической информационной инфраструктуры. Для значимых объектов КИИ (ЗОКИИ) предусмотрены меры по реагированию на инциденты и действиям в нештатных ситуациях, включая планирование восстановления. Поправки к закону вступили в силу 1 сентября 2025 года.

26 февраля 2026 года Правительство РФ утвердило распоряжением № 360-р единый перечень типовых отраслевых объектов КИИ. Документ насчитывает 397 типовых объектов по отраслям: банки и финансовые рынки, наука, здравоохранение, энергетика, транспорт, связь, оборонная и ракетно-космическая промышленность.

Для отдельных отраслей приняты отраслевые особенности категорирования: для атомной энергии (постановление № 4 от 16.01.2026), для банковской сферы (постановление № 92 от 06.02.2026), для науки (постановление от 07.03.2026).

Приказ ФСТЭК № 117. С 1 марта 2026 года вступил в силу приказ ФСТЭК № 117 от 11.04.2025, который обновил требования к защите информации в государственных информационных системах (ГИС). Документ распространяется не только на ГИС, но и на иные информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений. Требования включают политику информационной безопасности, подразделения защиты, цикл Деминга и новый показатель защищённости КЗИ.

ГОСТ Р 53647 (менеджмент непрерывности бизнеса). Серия стандартов, которые задают методическую рамку для управления непрерывностью. Включает практическое руководство, управление человеческими ресурсами, управление организацией в условиях кризиса. Документы действуют в настоящий момент.

ГОСТ Р 57580.1 для финансовых организаций. Стандарт содержит более 400 организационных и технических мер защиты информации для банков, страховых, клиринговых компаний и финтех-стартапов. В ноябре 2025 года Банк России разослал финансовым организациям письма, обязывающие требовать от поставщиков ИТ- и ИБ-услуг соответствия стандарту. В феврале 2026 года проведены первые проверки крупнейших финансовых организаций.

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

Тестирование DR-плана

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

Виды тестов

Разные уровни сложности — от простых до максимально реалистичных.

1. Разбор сценария на бумаге (tabletop exercise). Участники собираются и проходят сценарий устно: «что делаем, если упала база?», «кто кому звонит?», «какие команды выполняет?». Проверяются логика, последовательность действий, понимание ролей. Риска для продуктивной среды нет.
2. Восстановление одной системы на изолированном стенде. Берётся отдельный сервис и восстанавливается из бэкапов на тестовой среде. Проверяется, что бэкапы читаются, данные консистентны , восстановление проходит без ошибок.
3. Тестовое переключение группы связанных сервисов. Несколько сервисов, которые зависят друг от друга, переключаются на резервную площадку в тестовом режиме. Проверяются зависимости, порядок запуска, работа интеграций.
4. Полномасштабное учение с переводом продуктивной нагрузки. Самый сложный и рискованный вариант. Реальная нагрузка переключается на резервную площадку, пользователи работают с резервной средой. Проверяется всё: от инфраструктуры до пользовательского опыта. Риск — если что-то пойдёт не так, бизнес пострадает. Поэтому такие учения планируют на периоды низкой нагрузки и с полным планом отката.

Периодичность и критерии успешного теста

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

Критерии успешного теста:

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

В протоколе теста фиксируется фактическое время каждого шага. Не «восстановили за 2 часа», а «базу подняли за 35 минут, веб-серверы за 50 минут, проверка данных заняла 20 минут, итого 1 час 45 минут».

Что делать с результатами

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

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

Как поддерживать DR-план в актуальном состоянии

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

Внеплановый пересмотр нужен в следующих случаях:

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

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

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

Чек-лист готовности DR-плана

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

☐ Перечень всех ИТ-систем, которые должны восстанавливаться, составлен и утверждён.

☐ Для каждой системы назначены RTO и RPO, согласованные с бизнесом.

☐ По каждому сервису назначен ответственный за восстановление и его заместитель.

☐ Критерии активации плана записаны, лицо, принимающее решение о переключении, определено.

☐ Доступы, пароли, ключи шифрования хранятся в защищённом месте, порядок доступа к ним описан.

☐ Порядок действий при недоступности основной площадки прописан и проверен.

☐ Дата последних учений и их результат зафиксированы в протоколе.

☐ Дата последнего обновления плана — не старше 6 месяцев.

☐ Офлайн-копия плана существует и хранится отдельно от корпоративных систем.

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

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

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

Почему джун, мидл и сеньор ничего не значат

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

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

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

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

Из чего собирается матрица компетенций

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

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

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

Как происходит оценка и почему она субъективная

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

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

Что с этим делать разработчику:

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

Как получить повышение

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

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

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

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

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

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

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

Деньги, вилки и разброс внутри грейда

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

Как вообще назначают зарплату

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

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

Как проверить систему грейдов на входе

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

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

Итого

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

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

Timetta — российская PPM-платформа с финансовым учётом, портфелями и on-premise для крупных компаний.

GanttPRO — специализированный онлайн-инструмент для диаграмм Ганта с импортом MS Project и простым интерфейсом.

Kaiten — российский сервис для гибридного управления: Kanban, Scrum, Гант и модульная тарификация.

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

Как мы выбирали

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

Все участники проверены по официальным источникам. Цены и условия указаны по данным сайтов на лето 2026 года и могут меняться, поэтому перед покупкой стоит свериться с актуальным прайс-листом.

1. Timetta — портфели и финансы

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

Кейсы клиентов и кому подойдёт

• Проектный офис крупной ИТ-компании. В Газпром ЦПС Timetta используется как единое пространство для управления портфелем из 180+ проектов.
• Руководители проектов и финансисты. Комита ЦТ собирает трудозатраты через таймшиты и контролирует рентабельность проектов.
• Ресурсные менеджеры. В GMCS система помогла сделать прозрачной загрузку сотрудников и снизить конфликты за ресурсы между направлениями.

Что можно развернуть

Платформа покрывает полный цикл проектного бизнеса:

• проекты, программы и портфели
• диаграммы Ганта с вехами, зависимостями и критическим путём
  
• таск-трекер с бэклогом и спринтами
  
• бронирование ресурсов и загрузка сотрудников
  
• таймшиты и учёт отсутствий
• заявки на затраты, платёжные календари и процесс почасового биллинга,
• P&L-отчёты, клиенты и сделки
  
• корпоративная вики и ИИ-ассистент
  

Инфраструктура и экосистема

Timetta работает в облаке (SaaS) и в виде on-premise-развёртывания в инфраструктуре заказчика. Данные хранятся на защищённых российских серверах, система соответствует 152-ФЗ и включена в реестр российского ПО (запись № 18250 от 05.07.2023). Доступен OData API с авторизацией OAuth 2.0, готовые интеграции с 1С:УХ и 1С:ЗУП, обработчики и сценарии автоматизации.

Отзывы и репутация

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

Поддержка и каналы связи

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

Тарифы, ограничения и условия

Стоимость зависит от выбранных приложений, числа пользователей и срока лицензии. По данным прайс-листа, лицензии на отдельные приложения начинаются от 350 ₽ за пользователя в месяц (например, Timetta Expenses), до 3500 ₽ за Timetta Corp.

Для небольших команд есть отдельная бесплатная сборка Timetta Lite: тариф Free доступен без ограничения по сроку для 10 активных пользователей и теперь включает таймшиты, а для команд на 11–50 человек действует платный тариф Team — 1 490 ₽ за пользователя в месяц (подробнее — в блоге Timetta). On-premise доступен для корпоративных клиентов, стоимость рассчитывается индивидуально. Работа с юрлицами ведётся по договору с закрывающими документами.

Официальный сайт: timetta.com

2. GanttPRO — специализация на Гантах

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

Кейсы клиентов и кому подойдёт

• Менеджеры проектов среднего звена. Интерфейс заточен под планирование сроков и контроль дедлайнов без IT-отдела.
• Маркетинговые и event-команды. Удобно строить таймлайны кампаний, делиться планами с заказчиками по публичной ссылке.
• Команды, мигрирующие с MS Project. Поддерживается импорт из MS Project, что упрощает перенос существующих планов.

Что можно развернуть

GanttPRO предлагает диаграмму Ганта с зависимостями, автопланированием и критическим путём; иерархию задач и WBS; представления доски, списка, календаря, дашборда, портфеля и загрузки ресурсов; учёт рабочей нагрузки, бюджетирование и тайм-трекинг на старших тарифах; комментарии к задачам, вложения, упоминания и публичные ссылки для демонстрации планов; экспорт в PDF, PNG и Excel.

Инфраструктура и экосистема

Решение работает полностью в браузере, без установки десктопного клиента. Данные хранятся в дата-центрах Microsoft Azure в ЕС. Поддерживаются основные платежные методы, включая карты и PayPal; для компаний доступна оплата по счёту. API есть, но собственная экосистема интеграций у GanttPRO уже, чем у крупных платформ вроде monday.com или Wrike.

Отзывы и репутация

По данным GanttPRO, инструментом пользуются более 1 млн проектных менеджеров. На Capterra сервис получает высокие оценки за удобство диаграмм Ганта (около 4,8/5). Часто отмечают чистый интерфейс и быстрый старт; среди ограничений — узкая экосистема интеграций и менее глубокие отчёты по сравнению с enterprise-PPM.

Поддержка и каналы связи

Поддержка доступна через email и базу знаний. На тарифе Enterprise предусмотрен приоритетный канал поддержки и enterprise onboarding. Документация и обучающие материалы публикуются на сайте.

Тарифы, ограничения и условия

GanttPRO работает по подписке. Тариф Core стоит от $7 за пользователя в месяц при годовой оплате, Advanced — $10, Business — $17, Enterprise — $25. Бесплатного тарифа нет, но доступен 14-дневный пробный период без привязки карты. Некоторые функции, например workload management и портфели, открываются только на тарифах Business и выше.

Официальный сайт: ganttpro.com

3. Kaiten — Agile и Гант

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

Кейсы клиентов и кому подойдёт

• IT-команды и продуктовые подразделения. X5 Tech использовала Kaiten при миграции из Jira, сохранив привычный подход к задачам.
• Ритейл и производство. Сервис работает в компаниях ВкусВилл, Мегафон, Додо Пицца, технопарке «Сколково».
• Команды, которым нужен единый инструмент. В Kaiten совмещены Kanban, Scrum, Гант, документы, базы знаний и служба поддержки.

Что можно развернуть

Доступны канбан-доски с WIP-лимитами и дорожками, скрам-доски со спринтами, burndown-диаграммами и velocity; диаграмма Ганта, ресурсное планирование и зависимости между задачами; документы и базы знаний; автоматизации через конструктор правил и триггеров; AI-транскрибатор встреч и AI-помощник для оформления задач; отчёты по загрузке, lead time, block time и cumulative flow; мобильные приложения для iOS и Android.

Инфраструктура и экосистема

Kaiten работает в облаке и предлагает серверную версию на Docker для тарифа «Корпорация» (от 300 пользователей). Продукт включён в реестр российского ПО, данные хранятся в России, оплата производится в рублях. Интеграции включают Jira, Trello, Notion, Asana, ClickUp, GitHub, GitLab, Slack, Telegram, Google Календарь и Яндекс Календарь.

Отзывы и репутация

По данным сайта, сервисом пользуются более 200 тысяч компаний. Публикуются именные кейсы клиентов: Buzzolls, «Сколково», X5 Tech, «Продман», «Авиационный Консалтинг-ТЕХНО». В независимых обзорах отмечают удобный интерфейс и рублёвую оплату; ограничения — функционал для портфельного управления и глубокого финансового учёта уступает специализированным PPM-системам.

Поддержка и каналы связи

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

Тарифы, ограничения и условия

Бесплатный тариф — до 5 пользователей с базовыми функциями. Платные тарифы: «Старт» от 185 ₽ за пользователя в месяц (при оплате на 36 месяцев), до 15 пользователей, включены модули Scrum и Kanban; «Стандарт» от 430 ₽ за пользователя в месяц, до 250 пользователей, два модуля на выбор; «Бизнес» от 580 ₽ за пользователя, до 250 пользователей, шесть модулей; «Корпорация» — индивидуальная цена, on-premise, от 300 пользователей. Каждый дополнительный модуль — от 80 ₽ за пользователя. Пробный период — 14 дней со всеми модулями.

Официальный сайт: kaiten.ru

4. Redmine — open source

Redmine — бесплатная open-source система управления проектами на Ruby on Rails. Это выбор для команд, у которых есть технические ресурсы для развёртывания и настройки, и которые не хотят зависеть от вендора и регулярных лицензионных платежей.

Кейсы клиентов и кому подойдёт

• Разработческие и IT-команды. Встроенная интеграция с Git, SVN, Mercurial, CVS и гибкая система трекинга задач.
• Компании с жёсткими требованиями к данным. Можно развернуть полностью в собственной инфраструктуре и контролировать доступ.
• Бюджетные проекты. Подходит стартапам, образовательным учреждениям и НКО, готовым потратить время на настройку вместо денег на лицензии.

Что можно развернуть

Redmine поддерживает управление несколькими проектами, гибкую ролевую модель доступа, трекинг задач с кастомными полями и workflows, диаграмму Ганта и календарь, wiki и форумы для каждого проекта, учёт времени, документы и файлы, email-уведомления, интеграцию с LDAP и SCM, создание задач по email. Функциональность расширяется сотнями плагинов сообщества.

Инфраструктура и экосистема

Решение распространяется под лицензией GNU GPL v2 и разворачивается на собственных серверах или в облаке. Поддерживаются разные СУБД (PostgreSQL, MySQL, SQLite) и ОС. API доступен для интеграций, но большинство интеграций реализуется через плагины или собственную разработку.

Отзывы и репутация

Redmine существует с 2006 года и имеет активное международное сообщество. Среди известных пользователей — множество open-source проектов, компаний в сфере IT, инжиниринга и консалтинга. В обзорах отмечают гибкость и отсутствие лицензионных платежей; к недостаткам относят устаревший интерфейс и необходимость в администрировании.

Поддержка и каналы связи

Официальная поддержка сообщества: форумы Redmine, IRC-канал #redmine в сети libera.chat, неофициальный Slack. Документация включает User's Guide, Developer's Guide, FAQ и HowTos. Коммерческую поддержку и хостинг предоставляют сторонние провайдеры, цены зависят от поставщика.

Тарифы, ограничения и условия

Сам Redmine бесплатен: нет лицензионных платежей и ограничений по числу пользователей или проектов. Реальные затраты — на собственное железо или облачный хостинг, администрирование и нужные плагины. Готовые хостинговые версии от сторонних провайдеров стоят от $10–25 за пользователя в месяц, но это цена провайдера, а не вендора.

Официальный сайт: redmine.org

Сравнение по ключевым критериям

Диаграмма Ганта и зависимости. Timetta и GanttPRO предлагают наиболее зрелый Гант с критическим путём и автопланированием. У Kaiten Гант доступен как подключаемый модуль, у Redmine — базовый, но функциональный.

Управление ресурсами. Timetta выделяется ресурсным планированием, бронированием и портфельной загрузкой. GanttPRO и Kaiten дают workload-вид, Redmine требует плагинов для глубокого ресурсного учёта.

Финансы и бюджеты. Timetta — единственный из четырёх с полноценным P&L, себестоимостью и взаиморасчётами. GanttPRO и Kaiten закрывают базовое бюджетирование, Redmine — через плагины.

Гибкие методологии. Kaiten лидирует по Kanban и Scrum из коробки. Timetta поддерживает гибридные схемы, GanttPRO ориентирован на классику, Redmine гибок через настройку workflows.

Размещение данных. Timetta и Kaiten предлагают российское облако и on-premise. GanttPRO хранит данные в Azure ЕС. Redmine разворачивается где угодно, включая собственный сервер.

Стоимость. Redmine бесплатен по лицензии, но требует ресурсов на поддержку. Kaiten стартует с бесплатного тарифа и далее от 185 ₽. GanttPRO — от $7. Timetta — индивидуально, с бесплатным тарифом Timetta Lite (Free) для команд до 10 пользователей.

Выводы

Прямого универсального заменителя MS Project не существует: каждый инструмент делает ставку на свои сценарии. Для крупного проектного офиса с финансовым контролем и портфелями логичнее смотреть на Timetta. Если главное — удобная диаграмма Ганта с быстрым стартом и импортом из MS Project, выбор GanttPRO выглядит естественным. Командам, которые живут в Kanban/Scrum, но иногда нужен Гант, подойдёт Kaiten. А Redmine остаётся рабочей лошадкой для технических команд, готовых взять на себя развёртывание и поддержку.

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

Clockify — щедрый бесплатный план и низкий порог входа в платные тарифы для небольших команд.

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

TimeCamp — акцент на автоматический учёт по ключевым словам и контроль бюджетов проектов.

Everhour — встраивает таймер прямо в задачи Asana, Jira, ClickUp и других таск-трекеров.

Как мы выбирали

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

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

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

1. Timetta — учёт через таймшиты

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

Кейсы клиентов и кому подойдёт

Решение в первую очередь выбирают компании с долей ФОТ свыше 60%:

• консалтинг
• аудит
• ИТ-интеграция
• разработка ПО
• дизайн и так далее

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

Что можно развернуть

Платформа покрывает полный цикл проектного бизнеса:

• проекты, программы и портфели
• диаграммы Ганта с вехами, зависимостями и критическим путём
• таск-трекер с бэклогом и спринтами
• бронирование ресурсов и загрузка сотрудников
• таймшиты и учёт отсутствий, заявки на затраты, платёжные календари и процесс почасового биллинга, P&L-отчёты, клиенты и сделки
• корпоративная вики и ИИ-ассистент

В рамках Timetta доступны приложения: Timetta Projects, Timetta Finance, Timetta Resources, Timetta Timesheets, Timetta Clients, Timetta Tasks, Timetta Expenses и Timetta Wiki.

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

Инфраструктура и экосистема

Система поставляется по модели SaaS или on-premise для установки на собственные серверы. Предусмотрены готовые интеграции с «1С:Зарплата и управление персоналом» и «1С:Управление холдингом», открытый API, а также авторизация через корпоративные каталоги (SSO/AD). Данные хранятся в дата-центрах Yandex Cloud на территории России, резервные копии сохраняются 30 дней.

Отзывы и репутация

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

Поддержка и каналы связи

Техническая поддержка работает по электронной почте support@timetta.com с регламентированным временем ответа в течение часа. Документация размещена на сайте в разделе timetta.com/ru/docs. При внедрении возможна помощь инженеров вендора, включая миграцию данных из других систем.

Тарифы, ограничения и условия

Функции учёта рабочего времени вынесены в отдельное приложение Timetta Timesheets. Лицензии на него начинаются от 524 ₽ за пользователя в месяц с регрессионными скидками.

Недавно компания выпустила новую сборку Timetta Lite: она доступна бесплатно для команд до 10 активных пользователей без ограничения срока и теперь включает таймшиты. Для 11–50 пользователей предусмотрен платный тариф Team — 1 490 ₽ за пользователя в месяц. Подробности о релизе — в блоге Timetta. Мобильное приложение находится в разработке, а пока доступна адаптированная мобильная версия в браузере.

Официальный сайт: timetta.com

2. Clockify — бесплатный старт

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

Кейсы клиентов и кому подойдёт

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

Что можно развернуть

• веб-приложение, десктопные клиенты (Windows, macOS, Linux), мобильные приложения iOS/Android и расширения для браузеров
• таймер, ручной ввод, таймшиты, календарь, автотрекер, Pomodoro, обнаружение простоя, интеграции с внешними сервисами
• в платных тарифах — киоск, биллинговые ставки, инвойсы, утверждение таймшитов, отпуска, бюджеты, GPS и скриншоты

Инфраструктура и экосистема

Clockify работает в облаке AWS, сертифицирован по ISO/IEC 27001, соответствует SOC 2 Type II и GDPR. В Pro-плане доступен выбор региона хранения данных. Интеграции охватывают более 80 приложений; есть публичный API и вебхуки.

Отзывы и репутация

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

Поддержка и каналы связи

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

Тарифы, ограничения и условия

Бесплатный план включает неограниченный трекинг, проекты и клиентов, но ограничен пятью пользователями. Платные тарифы при годовой оплате: Basic — $3,99, Standard — $5,49, Pro — $7,99, Enterprise — $11,99 за пользователя в месяц. Все платные планы можно протестировать в течение семи дней.

Официальный сайт: clockify.me

3. Toggl Track — минималистичный трекер

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

Кейсы клиентов и кому подойдёт

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

Что можно развернуть

• веб, десктоп (Windows, macOS, Linux), мобильные приложения iOS/Android и браузерные расширения
• таймер, ручной ввод, офлайн-трекинг, автоматическое обнаружение простоя, Pomodoro, личные и командные цели, более 100 интеграций, API и вебхуки
• встроенного инвойсинга нет — данные выгружаются или передаются через интеграции

Инфраструктура и экосистема

Toggl Track сертифицирован по ISO/IEC 27001, поддерживает 2FA и SSO, заявлено соответствие GDPR. Производитель декларирует доступность 99,9%, однако SLA в публичных источниках не публикуется.

Отзывы и репутация

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

Поддержка и каналы связи

Доступны база знаний, community-форум и email-поддержка. Приоритетная поддержка по email открывается на Premium, персональный менеджер — на Enterprise. Телефонной поддержки нет.

Тарифы, ограничения и условия

Бесплатный план рассчитан на команды до пяти пользователей и включает неограниченные проекты и клиентов. Платные планы: Starter — от $9, Premium — от $18 за лицензию в месяц, Enterprise — индивидуальные условия. Есть 30-дневная пробная версия.

Официальный сайт: toggl.com/track

4. TimeCamp — автоматический контроль

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

Кейсы клиентов и кому подойдёт

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

Что можно развернуть

• веб-приложение, десктопный агент, мобильные приложения и расширения
• таймер, таймшиты, keyword-based автоучёт, attendance и overtime, отпуска, бюджеты и сметы, биллинговые ставки, инвойсинг, утверждение таймшитов и ролевая модель
• интеграции с Asana, Trello, Jira, Monday, ClickUp, Wrike и другими инструментами

Инфраструктура и экосистема

Штаб-квартира компании находится в ЕС (Польша), обработка данных ведётся в соответствии с GDPR. Для бизнес-клиентов доступно соглашение DPA. Для организаций от 50 пользователей предлагаются on-premise и private SaaS на основе годового Ultimate-тарифа.

Отзывы и репутация

Публичная агрегированная оценка или число клиентов в официальных источниках не раскрыты.

Поддержка и каналы связи

Поддержка доступна по email help@timecamp.com и через базу знаний на сайте. На Enterprise плане заявлен приоритетный support с SLA.

Тарифы, ограничения и условия

Бесплатный план доступен для неограниченного числа пользователей и включает проекты, таймшиты и приложения. Платные тарифы при годовой оплате: Starter — $3,99, Premium — $6,99, Ultimate — $9,99 за пользователя в месяц, Enterprise — по запросу. Все платные планы можно протестировать 14 дней.

Официальный сайт: timecamp.com

5. Everhour — бюджеты проектов

Everhour встраивает учёт времени непосредственно в популярные таск-трекеры: кнопка таймера появляется рядом с задачей в Asana, Trello, Jira, ClickUp и других инструментах. Это снижает переключение контекста и упрощает контроль бюджетов.

Кейсы клиентов и кому подойдёт

Решение подходит агентствам, продуктовым командам и консалтинговым компаниям, которые уже ведут задачи в Asana, Jira, Monday или ClickUp. Минимальное отвлечение сотрудников — основное преимущество для команд, привыкших работать внутри одного инструмента.

Что можно развернуть

• работа через веб-приложение и расширение для Chrome, которое добавляет элементы управления в интерфейс таск-трекера
• таймер, ручной ввод, бюджеты проектов в часах и деньгах, счета на оплату, отслеживание расходов, планирование ресурсов, отчёты с экспортом CSV/PDF, SSO и гибкие права доступа

Инфраструктура и экосистема

Everhour — облачный SaaS. Нативные интеграции охватывают Asana, Trello, Jira, ClickUp, Monday, Basecamp, GitHub, Notion, Linear, а также Slack, Google Calendar, QuickBooks, FreshBooks, Xero и другие сервисы. Мобильных и десктопных приложений нет, офлайн-режим не поддерживается.

Отзывы и репутация

На официальном сайте указан рейтинг 4,7 из 5 на платформе G2. Детальная методология или число отзывов не раскрыты.

Поддержка и каналы связи

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

Тарифы, ограничения и условия

Бесплатный план рассчитан на команды до пяти мест. Платный Team — $8,50 за место в месяц при годовой оплате, минимум пять мест. Тариф Custom для крупных организаций рассчитывается индивидуально. Пробный период — 14 дней.

Официальный сайт: everhour.com

Сравнение по ключевым критериям

Бесплатный тариф: у Timetta — Timetta Lite до 10 активных пользователей, теперь с таймшитами; Clockify и Toggl Track ограничивают 5 пользователями; TimeCamp позволяет неограниченное число пользователей; Everhour — до 5 мест.

Минимальная цена: Timetta — от 524 ₽ за модуль Timesheets; Clockify и TimeCamp — от $3,99; Everhour — $8,50; Toggl Track — $9.

Автоматический трекинг: реализован в TimeCamp по ключевым словам и в Clockify/Toggl Track через десктопные агенты; Timetta и Everhour ориентированы на ручные таймшиты и таймеры.

Биллинг и инвойсы: встроены в Timetta, Clockify (с Standard), TimeCamp (Ultimate+) и Everhour; Toggl Track предлагает только отчёты с возможностью экспорта.

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

Вывод

Для российских проектных компаний с жёсткими требованиями к учёту экономики и локализации данных логичнее смотреть на Timetta. Если приоритет — минимальная цена или бесплатный старт, стоит протестировать Clockify или TimeCamp. Toggl Track удобен для быстрого учёта без лишних настроек, а Everhour — для команд, которые уже работают в Asana, Jira или ClickUp. Перед выбором стоит проверить, какой формат трекинга привычен команде: ручные таймшиты, автоматический контроль или встроенные кнопки в задачи.

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

Какие варианты у меня были

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

1. Уйти на грейд выше в другую компанию. Самый популярный ход на рынке. Ты выходишь наружу сеньором и заходишь в новую контору уже принципалом и получаешь рост в деньгах. Но насколько часто вы видите высокооплачиваемые экспертные роли в IT в последнее время, добавьте сюда текущее состояние экономики, и возможно узкую специализацию компаний, где такие вакансии всё-таки есть. Плюс сейчас всех активно возвращают в офис и в гибрид, а заодно сужают географию найма.
2. Взять три мидловые работы вместо одной сеньорской. Схема известная всем, и на удалёнке она какое-то время работала прекрасно. Но в сутках 24 часа, из которых надо ещё спать и есть. Заработать так действительно можно, но развиваться нельзя вообще: ты не углубляешься нигде, а весь день бегаешь от пожара к пожару и чинишь то в одном месте, то в другом. Через год у тебя больше денег и те же навыки, что были.
3. Завести пет-проект. Совет, который в такой ситуации дают чаще всего. Отнимает немного времени, приносит немного денег, разгружает голову. Я свой проект завёл и до сих пор не бросил, вещь полезная. Но проблему потолка он не решает, потому что пет-проект остаётся хобби с монетизацией. Ты по-прежнему разработчик, только уже для себя. Ты не разговариваешь с клиентами, не считаешь экономику, не собираешь команду и не отвечаешь за деньги, потому что денег там мало и потерять их не страшно.
4. Уйти в вайбкодинг. Я попробовал и довольно быстро поймал себя на неприятной мысли, что стал оператором конвейера: агенты пишут, я проверяю. Заодно шутка про «не наберём джунов подешевле, а лучше заменим их агентами» перестала быть шуткой, и это скорее повод побыстрее выйти из категории людей, которых можно так заменить.

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

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

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

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

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

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

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

Как я нашел главную проблему — люди вокруг

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

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

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

Почему я пошёл на Физтех

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

Дальше я нашёл программу МФТИ. У Физтеха есть кафедра технологического предпринимательства, которую он делает вместе со Сколково, а у кафедры есть онлайн-магистратура, которую называют ТехПред.

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

Про сам вуз. Физтех называют русским MIT, и по нагрузке он до сих пор считается одним из самых тяжёлых в стране. Среди основателей, преподавателей и выпускников есть нобелевские лауреаты. Среди выпускников хватает и учёных, и предпринимателей: физтехи стоят за ABBYY, Revolut, Veeam и другими технологическими компаниями. С 2020 года МФТИ возглавляет российский рейтинг предпринимательских университетов и бизнес-школ.

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

Иллюзия гениальности

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

Разбор проектов на программе ведёт Вячеслав Чикин, заместитель заведующего кафедрой технологического предпринимательства МФТИ+Сколково и серийный предприниматель. В интервью «Почему ваш пет-проект ещё не бизнес, а вы не предприниматель» он формулирует это так:

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

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

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

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

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

Дружба и бизнес после 30

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

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

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

Доступ к экспертизе

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

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

Системное мышление ведёт Анатолий Левенчук, директор по исследованиям русского отделения INCOSE и автор учебников по системноинженерному мышлению. Управление проектами читает Григорий Ципес, главный консультант компании IBS и вице-президент Ассоциации управления проектами. Коммерциализацию разработок ведёт Владимир Антонец, доктор физико-математических наук из Института прикладной физики РАН, который организовал первый в стране региональный технологический инкубатор. Юридическую часть закрывает Роман Янковский, автор «Закона стартапа».

Команда из своих

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

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

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

Как поступить

• Сроки. Приём заявлений идёт с июня по август 2026 года включительно, обучение начинается 1 сентября. Форма очная, занятия дистанционные, учиться четыре семестра.
• Порядок действий. Сначала разобраться в программе. Дальше оставить контакты в форме на сайте и, по желанию, уточнить, будет ли лично вам польза от этого обучения. Потом подать заявление на сайте МФТИ, пройти собеседование и сдать вступительное испытание. Вся информация и форма заявки на techpredonline.ru.
• Деньги. Есть образовательный кредит с господдержкой по ставке 3% годовых, который дают без подтверждения доходов. Есть оплата по семестрам, 445 500 рублей за семестр. Есть оплата работодателем, в том числе через корпоративные программы обучения и развития, и для корпоративных руководителей это часто самый быстрый путь, потому что бюджет на развитие сотрудников есть почти везде, просто про него редко спрашивают.

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

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

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

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

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

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

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006213, erid: 2W5zFJHUfX7

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

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

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

Без базы оценить код нечем

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

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

Хороший пример того, как это осваивают с нуля, есть в Roistat. Генеральный директор компании Наталья Арсланова Рассказала об этом в очередной встрече цикла “Беседы в МФТИ” кафедры технологического предпринимательства. Наталья по образованию управленец, написанием кода никогда не занималась. Когда фаундер принёс новость про вайбкодинг, он ничего объяснять не стал, а скинул статью с Хабра со словами «разберешься». Два дня ушло на сопротивление, потом она села и сделала. Через тот же путь прошёл весь топ-менеджмент, причём попытки купить готовый курс уперлись в то, что нормальных курсов по вайбкодингу тогда не существовало, и учились все по одной статье. Сейчас вайбкодит большая часть сотрудников. Арсланова говорит, что первый полученный результат затягивает сильнее любой игры, и на этом эффекте люди в тему и въезжают.

Половина работы теперь в самой задаче

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

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

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

За результат всё равно отвечаешь лично

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

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

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

Как выбрать, чему учиться

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

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

Отдельно стоит смотреть на программы, где учиться нужно сразу на своём проекте. Предпринимательству по учебникам не научишься, поэтому в онлайн-магистратуру той же кафедры технологического предпринимательства МФТИ приходят люди в среднем около 35 лет и приносят готовый контекст: свой стартап, спин-офф внутри компании или проект в корпорации, за который они отвечают. Заявления в магистратуру принимаются до 15 августа, обучение стартует 1 сентября, для поступления нужно пройти собеседование. Программа по семестрам и условия есть на techpredonline.ru.

Что будет с образованием дальше

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

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

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

Итого

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

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

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006213, erid: 2W5zFJBmp6d

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SQLite тащит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Финал

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

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

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

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

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

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

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

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

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

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

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

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

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

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

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

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

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

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

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

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

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

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

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

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

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

Заключение

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

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

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

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей page object сломал и почему Android отвалился после правки для iOS.

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

Как говорил один мой коллега, перефразируя классическое “вам шашечки или ехать”:

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

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

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

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

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

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

Общие Page Objects звучат красиво на бумаге: пишем один раз, используем для обеих платформ. А на практике…

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

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

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

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

Локаторы: работай с тем, что дают

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

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

Координаты - костыль? Да. Но иногда единственный вариант. Когда у тебя кастомный контрол без accessibility-свойств, а разработчик говорит «это декоративный элемент», ты либо тыкаешь по координатам, либо не тестируешь.

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

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

Что поменялось на практике

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

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

Приложение простое, пара экранов, стандартные контролы, минимум кастомного UI.

UI реально идентичен на обеих платформах. Бывает, наверное.

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

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

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

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

Дело не в вопросах от HR и не в том, как часто вас дергают опросами 360. А в том, что удовлетворенность измеряют как настроение, хотя это метрика с формулой и порогом, после которого принимают решения.

Что измеряет eNPS и как читать диапазоны

eNPS строится на одном вопросе: готов ли сотрудник порекомендовать компанию знакомым как место работы. Ответ дают по шкале от 0 до 10, и на основе балла респондента раскладывают по трем группам.

• Самые критичные сотрудники обычно ставят от 0 до 6 баллов. Это сотрудники, у которых накопилось достаточно претензий к условиям, процессам или руководству, чтобы транслировать недовольство за пределы компании.
• Пассивные сотрудники ставят 7 или 8 баллов. Явного негатива нет, но нет и мотивации защищать бренд работодателя перед кем-либо.
• Амбассадоры (промоутеры) компании ставят 9 или 10 баллов и готовы рекомендовать компанию без каких-либо противоречий.

Формула расчета: доля промоутеров минус доля критиков, в процентах. Результат укладывается в диапазон от -100 до +100.

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

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

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

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

Чем ESI отличается от eNPS

eNPS показывает общую лояльность сотрудников к компании, а ESI оценивает конкретные условия работы:

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

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

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

Поэтому ESI редко измеряют отдельным опросом. Вопросы обычно добавляют в eNPS-анкету. В результате HR получает один отчёт с двумя уровнями данных:

1. общий уровень лояльности;
2. оценки факторов, которые на него влияют.

Зачем сравнивать результаты с текучестью

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

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

Дальше разберём, из чего состоит рабочий опрос.

Из чего состоит рабочий опрос

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

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

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

Какие темы включить

Опрос обычно делят на несколько блоков:

1. Оплата, грейды и дополнительные льготы.
2. Работа с руководителем: постановка задач, обратная связь и поддержка.
3. Содержание работы: интерес к задачам, нагрузка и самостоятельность.
4. Карьерный рост и развитие внутри компании.
5. Команда и атмосфера.
6. Корпоративная культура и мероприятия.
7. Условия труда: офис, удалённая работа, доступы и ИТ-поддержка.

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

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

Периодичность: годовой опрос и пульс-опросы

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

Внеплановый опрос запускают после крупных изменений:

• слияния компаний;
• смены стратегии;
• перестройки процессов или пакета льгот.

В таких ситуациях прошлые данные уже могут не отражать текущее состояние команды.

Для чего нужны пульс-опросы

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

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

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

Что происходит после опроса

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

В следующий раз они заполняют анкету формально. Из-за этого данные перестают показывать реальное состояние команды.

После опроса нужно закрыть цикл:

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

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

Кто отвечает за изменения

HR собирает данные, рассчитывает eNPS и ESI и сравнивает результаты с текучестью по департаментам, а за изменения отвечают руководители процессов:

• тимлиды;
• руководители отделов;
• топ-менеджеры.

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

Когда нужен отдельный технический инструмент

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

• сравнивать eNPS и ESI с текучестью по департаментам;
• передавать данные пульс-опросов во внутреннюю HRM-систему;
• строить BI-дашборд с динамикой по кварталам и командам.

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

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

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

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

Редакция Tproger недавно была нескольких таких ивентах и на партнёрском дне Диасофт пообщалась с членом правления Диасофт и директором по работе с партнёрами Александром Сахаровым. Мы поговорили о том, почему агентская разработка в её нынешнем виде — тупик, как строить эффективные AI-процессы разработки, почему фреймворк теперь важнее модели и что нового в AI-обновлении платформы Digital Q.

Digital Q — российская low-code экосистема разработки от «Диасофт» с готовым «заводом» инструментов для сборки корпоративных приложений: от проектирования бэкенда, дизайна интерфейсов до DevOps. В мае 2026 года вышла AI-driven версия, где искусственный интеллект встроен в саму платформу — он проектирует архитектуру, генерирует код, фронтенд и бизнес-процессы по человекочитаемой спецификации, оставляя разработчику работу с замыслом, а не с рутиной.

AI добрался до фундамента

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

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

А шум — это вера, что AI всё решит сам по себе. Что можно купить лицензии Copilot, посадить за них разработчиков и они вам начнут производить продукты в десять раз быстрее. Нет, не начнут. Точнее, начнут, но счета вас очень неприятно удивят.

От агентов к AI-native платформе

Агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native

— Вы на сцене показывали, как обновился Digital Q с декабря. Что конкретно поменялось за эти полгода?

— В декабре, на зимнем партнёрском дне, мы представили платформу Digital Q.GPT — на ней можно реализовывать агентский workflow. Интеграция со всеми LLM-моделями, экосистема построения агентов, мультиагентные системы. На тот момент это было супер актуально.

К маю выяснилось, что этого недостаточно. За последние шесть месяцев все — Anthropic, Google, Gartner, Amazon, Сбер на ЦИПР — пришли к одному и тому же выводу: агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native, то есть AI вшит в саму экосистему разработки, а не прикручен сбоку отдельными агентами.

— А что плохого в агентах?

— С агентами ничего плохого, они нужны. Плохо, когда вся разработка строится только вокруг них. Если кто-то хочет писать агенты — пожалуйста, в Digital Q.GPT весь функционал остался: workflow, мультиагентные системы, всё это работает. Но это уже не центральная история. Центральная история теперь — единая экосистема, в которую AI встроен на каждом этапе процесса.

Три способа потерять деньги на AI

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

— Давайте про антипаттерны. Вы на сцене перечислили целый список — что точно делать не надо. Какой из них самый болезненный?

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

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

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

— Как можно решить эти проблемы?

— Главный тезис: фреймворк важнее модели. Они это называют harness, мы называем экосистема разработки. Есть термины IDP — Integrated Development Platform, IDE — Integrated Development Environment. Суть одна. Ваш фреймворк должен быть локально у вас, весь контекст — локально у вас, модели должны быть взаимозаменяемые. Тогда вы можете переключаться между ними и управлять стоимостью.

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

Как теперь устроена разработка

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

— Раньше был один контур: ТЗ — постановка — кодирование — тестирование — релиз. Долго, последовательно. Цифровая трансформация это ускорила: годы превратились в кварталы и месяцы. Но всё равно один линейный процесс.

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

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

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

— Это та же мысль, что и про вендорлок, по сути?

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

— Вернёмся к Digital Q. Как она теперь устроена? Если разобрать на компоненты — что там лежит?

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

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

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

— Почему вы так настойчиво возвращаетесь к теме денег? Ведь все маркетинговые материалы AI-вендоров обещают именно экономию.

— Потому что это самая опасная иллюзия сейчас. Uber, пытаясь сэкономить на разработчиках, потратил больше трёх миллиардов долларов на AI-генерацию кода. Японская компания за несколько месяцев потратила 500 миллионов долларов вместо тех людей, которых сократили. Долларов, не рублей. И это уже не теория, это свежие кейсы 2025–2026 годов.

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

— И как вы с этим боретесь технически?

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

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

— Расскажите про демо с CRM. Вы показывали, как из 400-страничного ТЗ получается работающее приложение. Это правда один день двух человек, или там есть нюансы?

— Один день двух человек — это правда. Нюансы есть, конечно. Главный: это не black box, который сгенерил вам что-то непонятное. Это полностью оснащённый артефактами IT-проект. Можно пойти и сдать любому госзаказчику по ГОСТу. Полная документация — техническая, пользовательская, финансовая. Полный набор описанных бизнес-процессов. Полный набор тестов, включая тесты на уязвимости.

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

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

— А фронтенд?

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

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

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

— Вы говорили, что AI-агенты теперь работают не только в коде, но во всех ролях — от аналитика до девопса. Как это устроено?

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

Фишка нашей платформы в том, что мы все роли оснастили всеми агентами из коробки. Не надо ничего собирать самому. Скачали Digital Q, поставили, производите ПО.

Что доступно прямо сейчас

С июля начинаем публиковать обновлённую версию. Можно скачать, развернуть, запускать.

— И эта экосистема действительно доступна партнёрам?

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

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

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

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

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

Если такого человека нет — никакая AI-генерация вас не спасёт. Будет только дороже и хуже.

— Какой главный совет тем, кто только сейчас задумывается о собственной AI-трансформации разработки?

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

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

Бонус: чек-лист «AI-разработка без иллюзий»

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

Чего точно не стоит делать:

— Сажать команду на одну LLM-модель — это вендорлок, и он будет дорожать;

— Разрешать разработчикам неограниченно гонять самую дорогую модель;

— Использовать AI только в кодировании, без интеграции в остальной процесс;

— Накупить разных инструментов и надеяться, что они потом «как-нибудь соберутся»;

— Сокращать разработчиков в расчёте на «бесплатные» токены.

Что стоит сделать:

— Держать экосистему разработки и весь контекст локально;

— Зашить в платформу переиспользование кода — половину нового модуля собирать из готового;

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

— Разделить процесс на два контура — замысла (где работает человек) и исполнения (где работают агенты);

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

Реклама. Рекламодатель: ООО «Диасофт», ИНН 7715560268, erid: 2W5zFJRM88q

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

Главный риск: обмануться быстрой победой

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

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

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

Спроектируйте архитектуру раньше, чем напишете первый экран

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

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

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

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

Сначала бэкенд и контракт, потом клиенты

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

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

AI-тесты не заменяют ручное тестирование и фокус-группу

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

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

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

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

Как собрать AI-driven команду под такой проект

За три месяца сложилось понимание оптимального состава для подобного проекта:

• 1 архитектор — человек, который понимает, как обеспечить стабильность многопользовательского сервиса под нагрузкой;
• 2 продакт-инженера — берут на себя и проработку пользовательских сценариев, и собственно вайбкодинг;
• UX/UI-дизайнер;
• QA-инженер.

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

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

Что в итоге

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

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

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

Данные: кандидаты не против AI — они против того, как его применяют

Начнём с масштаба. По данным SHRM Talent Trends 2025, доля AI в HR-процессах за год почти удвоилась — с 26% до 43% рабочих сценариев. Это говорит о том, что AI в найме больше не эксперимент, а новая норма.

Проблема в том, что кандидатский опыт за этой скоростью не поспевает. Свежий отчёт Greenhouse 2026 Candidate AI Interview Report (опрошено 2 950 активных соискателей в пяти странах) рисует довольно мрачную картину:

• 63% кандидатов проходили AI-интервью за последний год — рост на 13% всего за полгода;
• 38% уже снимались с процесса найма именно из-за AI-интервью, ещё 12% готовы уйти, если их обяжут его проходить;
• 51% из тех, кто всё-таки прошёл AI-интервью, не получили никакого результата — их либо проигнорировали, либо они всё ещё ждут ответа;
• 34% после AI-интервью стали хуже относиться к компании;
• 70% вообще не предупредили заранее, что их будет оценивать AI.

Отдельно стоит гостинг (ghosting) — внезапное молчание компании, когда кандидату просто перестают отвечать. По данным, которые приводит Fortune, в 2026 году с ним столкнулись 53% соискателей, это трёхлетний максимум (против 48% в 2025 и 38% в 2024). И связывают этот рост напрямую с AI: инструменты позволяют кандидатам рассылать отклики пачками, рекрутеров заваливает и они просто не отвечают тем, кому отказ пришёл автоматически. Классическая петля обратной связи: чем больше автооткликов, тем больше автоотказов.

Мы решили проверить это на своей аудитории

Чтобы не опираться только на публичные отчёты, мы провели два анонимных опроса в наших Telegram-каналах: один про главную боль в AI-найме (2 633 голоса), второй — про влияние на отношение к компании (2 273 голоса).

Результаты близки к мировыми. Раздражает хотя бы что-то в AI-найме 90,7% опрошенных — вариант «меня это не раздражает» выбрали лишь 9,3%. Две главные боли идут вровень: невозможно достучаться до живого человека (30,4%) и шаблонный отказ без объяснения причин (30,2%). То есть сильнее всего бьёт не сама технология, а дегуманизация — ощущение, что тебя обрабатывает конвейер, а не рассматривает человек.

И, что важнее, это конвертируется в ущерб бренду. Отношение к компании после плохого AI-опыта меняется у 82,4% (не меняется только у 17,6%). А 22,2% готовы активно отговаривать знакомых от взаимодействия с такой компанией. Почти каждый четвёртый кандидат превращается в канал антирекламы.

Ключевой вывод из всех цифр один, и его хорошо сформулировали в Greenhouse: только 19% кандидатов хотят меньше AI в найме. Люди не против автоматизации — они против того, как её внедряют: без предупреждения, без объяснений и без возможности достучаться до человека.

Как компания «переAIивается»

Чтобы показать, как это выглядит в динамике, соберём обобщённый сценарий. Компания «Хоризон» — вымышленная, но ни один поворот в её истории не выдуман: за каждым стоит реальный публичный прецедент.

Эйфория. Поток откликов вырос в разы, рекрутеры тонут, «Хоризон» покупает систему автоскрининга. Первый год — восторг: время до шортлиста падает, стоимость найма снижается. Именно на этом успехе компании и «переAIиваются», он выглядит как повод автоматизировать всё подряд.

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

Автоотказы приводят к судебному иску. Чтобы разгрузить рекрутеров, «Хоризон» включает критерии автоматического отказа. Так поступила iTutorGroup: её софт автоматически отклонял женщин от 55 лет и мужчин от 60, отсеяв больше 200 квалифицированных кандидатов. Вскрылось случайно: кандидатка подала две одинаковые анкеты, отличавшиеся только датой рождения, и приглашение на собеседование получила только с более «молодой» версией резюме. Итог — 365 000 долларов по мировому соглашению с EEOC, первому в истории по AI-дискриминации в найме. И урок для каждого HR-отдела: даже когда дискриминацию автоматизирует технология, ответственность всё равно несёт работодатель.

Doom loop и системный риск. Опыт кандидата иногда схлопывается ещё до конвейера. Как в деле против Workday: истец подал больше сотни заявок через платформу и получил отказы по всем, причём часто в течение минут, иногда посреди ночи. Так он заподозрил, что решение принимала машина. В мае 2025 суд разрешил вести иск как коллективный, от лица потенциально сотен миллионов соискателей, а по собственным данным компании за спорный период через её инструменты было отклонено 1,1 млрд заявок. Workday обвинения отрицает и настаивает, что её инструменты не принимают решений о найме, но в июне 2026 суд в Калифорнии позволил части претензий двигаться дальше. Суть здесь в том, что ответственность может лечь и на вендора, а не только на конкретного работодателя.

Где «Хоризон» теряет не деньги, а бренд. Кандидаты, отсеянные «за секунды в два часа ночи», редко идут в суд — они пишут отзывы и предупреждают знакомых. Это ровно то, что показал наш опрос: 82,4% меняют отношение к компании, 22,2% отговаривают других. Юридический иск довольно редкое явление, а репутационные потери — ежедневное и почти неизбежное.

Найм в «Хоризон» сломал не сам AI, а три конкретные вещи: решения без человека, отказ без объяснения причины и полное исчезновение живого контакта. По сути, компания автоматизировала не рутину, а именно те точки, где кандидат ждёт человека.

Чек-лист: где AI работает, а где вредит

Если свести все прецеденты и данные вместе, станет понятно, что граница проходит не по технологии, а по тому, ждёт ли кандидат в этой точке человека. Там, где взаимодействие и так безличное, AI должен выступать ассистентом, оптимизировать процесс. Риск начинается там, где AI перестаёт помогать человеку и начинает принимать за него решения — именно эти сценарии привели к судебным искам из кейсов выше, и 22,2% готовых к антирекламе в нашем опросе.

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

AI помогает:

• Написание и оптимизация текстов вакансий;
• Первичный парсинг и сортировка резюме — как один из сигналов, а не как решение;
• Планирование, перенос интервью, напоминания;
• Ответы на типовые вопросы о вакансии и статусе заявки;
• Черновики писем, которые редактирует человек.

AI вредит:

• Автоматический отказ без проверки живым рекрутером;
• Отказ без внятной причины;
• AI-видеоинтервью «с роботом» как единственный этап;
• Полное отсутствие человека на всём пути;
• Анализ мимики и эмоций — запрещён EU AI Act с февраля 2025 года.

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

Фреймворк «Human-in-the-loop»: алгоритм советует, человек решает

Хорошая новость: кандидаты сами подсказывают, как надо. В том же отчёте Greenhouse они называют, чего им не хватает: раскрытия факта использования AI (44%), понятного объяснения, что именно AI оценивает (39%), возможности запросить человека вместо робота (46%), гарантии, что человек проверяет оценку AI до решения (38%), и доказательств, что систему проверяли на предвзятость (29%). Это, по сути, готовое ТЗ на здоровый процесс.

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

На практике принцип держится на трёх опорах:

• Объяснимость: вы должны уметь сказать, почему кандидат А оказался выше кандидата Б, причём сказать это самому кандидату, а не только себе;
• Аудируемость: должна быть возможность проверить, что живой рекрутер видел и подтвердил рекомендацию AI, а не проштамповал её вслепую;
• Тест на предвзятость: систему нужно регулярно проверять на демографические перекосы и другие отклонения, иначе повторится история Amazon, где модель годами воспроизводила состав команды, пока это не всплыло.

Про прозрачность. Стоит ли открыто говорить кандидатам о том, какие этапы автоматизированы? Обычно это воспринимают как риск, хотя это наоборот хороший сигнал от работодателя кандидатам. Раз 70% кандидатов узнают об участии AI уже постфактум, то честное «вот здесь у нас работает машина, а здесь — человек» само по себе выделяет работодателя на общем фоне и повышает уровень доверия кандидатов.

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

Что в итоге

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

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

Хотите провести свой опрос или разместить материал? Пишите нам.

С практической точки зрения проект на**й не нужен. Есть GitHub, GitLab и куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Почему не JSON

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

Подергал JSON туда-сюда пару дней и понял: не варик.

1. Конкурентный доступ. Два юзера одновременно коммитят — один перезаписывает файл другого.
2. Целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии.
3. Версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Вывод: JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор SQLite и схема БД

Выбрал SQLite, потому что:

• Не надо поднимать отдельный сервер
• Целостность данных на уровне движка (транзакции, foreign keys, rollback)
• Всё в одном файле — скопировал и унёс

Сущности:

• users — telegram_id, username, current_project_id
• projects — owner_id, name, thread_id (каждый проект живёт в своём треде канала)
• files — filename, current_version, флаг modified (файл изменился и готов к коммиту)
• file_versions — мясо. Каждая версия файла с полным содержимым. Привязана к file_id и опционально к commit_id
• commits — сообщение, время, ссылка на проект
• commit_files — связка коммитов с версиями файлов (many-to-many, чтобы поддержать ветки)

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

В коде вместо голых кортежей из SQL — датаклассы:

Маркдауновый ад

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

На практике Telegram использует свой диалект Markdown, где куча служебных символов: _ * [ ] ( ) ~ > # + - = | { } . !

Попытка 1: заэкранировать всё подряд. Результат: код превращается в кашу. Вместо def __init__- получается def |_|_init|_|_ — уже не запустишь, и в канале выглядит как говно.

Попытка 2: не экранировать вообще. Telegram шлёт на**й с ошибкой «can't parse entities».

Попытка 3: экранировать только то, что реально ломает разметку. Выяснилось, что порядок важен. Сначала экранируем точки и подчеркивания, потом обратную косую черту. Но и это не панацея — последовательности типа \*

после экранирования превращаются в \\*, и Telegram снова недоволен.

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

Попытка 5 (финал): забил на Markdown и перешёл на HTML. Telegram умеет его принимать. Да, он не такой красивый, но зато предсказуемый:

Никаких точек, подчеркиваний, обратных слешей. Просто экранируем три символа — и код летит как надо.

Security by design

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

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

Как так вышло? В таблице projects с самого начала было поле owner_id. При создании проекта я писал туда telegram_id владельца. Все запросы к БД фильтруются по этому полю:

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

Команды: от семи до двух десятков

Изначально казалось, что команд будет немного. Но...

Жизнь рассудила иначе.

• База: /start, /init, /use, /list, /ls, /commit, /log, /status
• Удаление: /rm, /rmproject + подтверждение
• Игнор: /ignore, /ignored, /unignore
• Ветки: /branch, /branches, /checkout
• Диффы и просмотр: /diff, /cat

Итого — уже под два десятка. И это не предел.

Простота > абстракции

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

Если завтра появится вторая реализация — тогда и буду делать интерфейс. А пока это просто оверхед.

В GitGram:

• Хочешь понять, как работает add_file — идёшь в database.py и читаешь 10 строк кода.
• Хочешь увидеть обработчик /commit — открываешь bot.py и смотришь.

Никаких AbstractMinerShieldEventProcessor, BaseGitGramManager, InterfaceProviderFactory.

Код должен быть тупым. Чем тупее — тем проще его читать и отлаживать.

Что дальше

В планах:

• Докрутить коллаборацию (несколько человек над одним проектом)
• Приватные репозитории
• Кодспейс прямо в боте (да да знаю я сошёл с ума и бла бла бла..)

Итог

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

На практике GitGram ни к чему. Но сама задумка — Git в Telegram — это же так прикольно. Просто посмотреть, можно ли такое вообще запилить.

Если хочешь поучаствовать

• GitGram
• Чат для хардкорных: @sandbox_hardcore — вся сырая разработка, факапы и обсуждения (без цензуры)

Подписывайся на мой TГ-канал — там я публикую все свои эксперименты, код и приглашаю к обсуждению. Только факты, мат и никакой политоты.

SafeLine WAF — это бесплатный инструмент, который я лично тестировал.

Это полностью open-source решения, продукт с действительно бесплатной Community Edition, где ключевые функции не урезаны.

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

Что он делает:

Защищает веб-приложения от SQL-инъекций, XSS-атак, командных инъекций, CSRF, SSRF, атак включения файлов и других угроз из списка OWASP Top 10. Также поддерживает защиту от CC/DDoS-атак, управление ботами и может работать как шлюз аутентификации.

Почему он:

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

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

Некоторые показатели, которые стоит учитыват

1. Уровень обнаружения - SafeLine (Balanced) (71.65%), ModSecurity (Level 1) (69.74%), Cloudflare (Free) (10.7%)
2. Уровень ложных срабатываний - SafeLine (Balanced) (0.07%), ModSecurity (Level 1) (17.58%), Cloudflare (Free) (0.07%)
3. Точность - SafeLine (Balanced) (99.45%), ModSecurity (Level 1) (82.20%), Cloudflare (Free) (98.40%)

Сбалансированный профиль SafeLine обнаруживает более 70% атак, при этом блокируя легитимный трафик ошибочно всего в 0.07% случаев. Это именно тот уровень настроек по умолчанию, который можно использовать в промышленной среде без постоянного ручного контроля.

Установка выполняется одной командой

После запуска он разворачивается как набор Docker-контейнеров: Tengine (форк Nginx) используется в качестве reverse proxy, отдельный сервис отвечает за семантический анализ, PostgreSQL хранит конфигурации и логи, а удобная веб-панель администратора работает на порту 9443.Community Edition поддерживает до 10 сайтов, чего достаточно для большинства личных проектов и небольших бизнес-сценариев.

Сайт: https://cyberserval.tech/landing/safeline

GitHub: github.com/chaitin/SafeLine (более 21 тыс. звёзд)

Лицензия: GPL-3.0 / MIT (Community Edition)

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

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

RUNIT by AGIMA — ежегодный фестиваль IT и спорта, который проводится в Москве летом. Впервые он прошел в 2018 году и собрал около сотни сотрудников AGIMA и их друзей, а уже в 2025 году в фестивале приняло участие 10 тысяч IT-специалистов. В этом году фестиваль пройдёт 5 июля в Мещерском парке.

Хотелось узнать, что бег и спорт делают с человеком по-настоящему — куда заводят, какие решения подсказывают, какие оставляют впечатления и воспоминания, над чем потом смеёшься. Получилось честно и местами неожиданно. Героев в этой статье четверо: Алексей Озеров (IT_One), Сайыына Колесова (КРОК), Млада Николаева (AGIMA) и Алексей Лосев (БФТ-Холдинг). Дальше — их дистанция, от старта до финиша.

Старт: «Сайыына, зачем тебе это?»

Почти у всех бег начинался с чужой компании — буквально.

Сайыына Колесова впервые побежала на RUNIT by AGIMA в 2024-м, в разгар адаптации в новой компании, когда записывалась подряд на все активности: «Мне показалось, что будет клёво большой командой в одинаковых футболках пробежать свои дистанции. Раньше я завидовала тем, кто приходит на забеги со своей командой, тоже хотелось быть частью такого драйвового сообщества». Воодушевившись, она выбрала десять километров — и до сих пор об этом жалеет, потому что дистанция далась непросто: «Я бежала и думала: «Сайыына, зачем тебе это?».

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

Для Алексея Озерова фестиваль — вообще точка отсчёта. «Это особенный для меня забег, с него начался мой беговой путь. Два года назад я пробежал здесь свои первые пять километров и чуть не умер. Год назад тут же была первая десятка». Следующая цель Алексея тоже привязана к фестивалю: первый в жизни полумарафон он хочет пробежать именно на RUNIT by AGIMA.

Стена: не всё так просто

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

Стена Алексея Лосева показалась мне особенно суровой. Он бегает ультратрейлы, и его главная история — «Золотое кольцо» под Суздалем с титульной дистанцией 110 километров. Первая попытка закончилась сходом на девяносто четвёртом километре. Со стороны — обидно, оставалось чуть-чуть. Но он принял это решение как человек, привыкший смотреть вдолгую: «В тот год дистанция была сто пятнадцать километров, каждый давался тяжело. Я решил сойти, чтобы не только вернуться, но и продолжать участвовать в таких событиях долгие годы». Он вернулся через два года подготовки.

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

У Млады Николаевой, которая помимо бега занимается пауэрлифтингом и тайским боксом, была своя стена — жара на петербургском полумарафоне «Северная столица». После первой в жизни половинки (прим. полумарафон, 21 километр) она шла за личным рекордом: «Питер, плоско, лето — что может пойти не так? Ответ: всё».

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

Передышка: футбол, халявные футболки и первое место

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

Самая киношная — у Алексея Озерова, и она про футбол. «Во время легендарного чемпионата Европы, когда наша сборная обыграла Голландию 3:1, я работал в приёмной комиссии Бауманки. После той игры мы на радостях гуляли всю ночь, а утром напрямик пришли в кабинет приёмной комиссии, обвесили его флагами и с раскрашенными в цвета российского флага лицами весь день принимали документы у будущей технической элиты страны».

У Сайыыны Колесовой — история о том, как она случайно стала спортсменкой. Она долго считала себя человеком неспортивным и физкультуру терпеть не могла, пока тётя — тренер по лёгкой атлетике — не отдала ей ворох командных футболок со сборов. «Я ходила в этих халявных футболках на физру, и однажды физрук без объяснений перевёл меня в другую группу. А там оказались университетские легкоатлеты с особой программой. Тренеры, видимо, решили, что футболки мои по праву и я из какой-то сборной. Не спросили, к счастью». Так она «вступила в атлеты», сдала нормативы не хуже других, начала сама ходить в зал и бегать по утрам, доехала до соревнований в Германии: «Ну короче, с тех пор я на спорте».

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

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

Второе дыхание: что изменил спорт

Самое интересное начинается, когда спрашиваешь не «что спорт дал», а «что поменял».

У Алексея Лосева два таких открытия, и оба выросли прямо из его гонок. Первое — про то, как браться за неподъёмное: «Сложную задачу начинаешь решать, сделав один шаг». Тот самый шаг из лагеря волонтёров, перенесённый в кабинет. Второе он усвоил на финишном отрезке, когда силы кончились и в одиночку он уже не укладывался в лимит: «Я зацепился за группу других участников, вцепился зубами и „рюкзаком“ продолжил с хорошим темпом». Так была закрыта сложнейшая гонка его жизни — не в одиночку. Отсюда вывод: «Сверхдостижений можно добиться только с командой единомышленников».

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

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

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

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

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

Финиш: разные награды

А вот на финише наши герои расходятся — и это, пожалуй, то самое честное и неожиданное.

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

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

Млада на том же финише чувствует другое и подбирает неожиданное для человека со штангой и боксёрскими перчатками слово — умиротворение. «Это не всегда эйфория с фанфарами. Иногда это тихое ощущение: «Я справилась». И оно мне очень дорого».

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

Почему RUNIT by AGIMA

Любопытно, что почти никто из них не говорит про секунды в протоколе.

«Это возможность увидеть коллег с другой стороны, позитивный формат и классная программа», — говорит Лосев, которому есть с чем сравнивать. Озеров привязан к фестивалю историей: здесь он начинал и здесь же хочет взять первый полумарафон. Колесова не скрывает мотивации и формулирует её очень обаятельно: «Меня привлекают коллеги. Они заманивают вкусняшками и пивом, и я не против — побегу с ними куда угодно, сколько угодно, возможно даже в +30. Фестиваль даёт почувствовать наше единство».

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

RUNIT by AGIMA пройдёт 5 июля в московском Мещерском парке. В программе — дистанции от детских 200 метров до полумарафона 21,1 км, командные зачёты и эстафеты, а после финиша — фестиваль с музыкой, фудкортом и зонами для своих.

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

Я попросил героев закончить фразу «бег научил меня тому, что…».

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

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

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

Откуда берётся желание всё бросить

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

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

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

Где заканчивается норма

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

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

Откуда злость на коллег

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

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

Как наблюдать за собой

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

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

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

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

Итого

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

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

Почему инфраструктура начинает привлекать больше, чем фичи

С фичами всё прозрачно: написал код — увидел результат на экране. Быстрая и понятная обратная связь. Но со временем замечаешь, что проблемы повторяются. Приложение тормозит не из-за плохого кода, а потому что на один экран уходит пять-шесть сетевых вызовов. Логика на клиенте. Хочешь что-то изменить — готовь релиз, проходи App Store Review и жди недели, пока обновление дойдёт до всех.

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

Возвращаться к фичам стало неинтересно. В инфраструктуре задачи сложнее, результат измеряется метриками — latency, error rate, скорость релизов, — а влияние на всю систему, а не на один экран.

Что Android даёт для инфраструктуры — а чему учиться с нуля

Мобильный бэкграунд оказался не балластом, а преимуществом. Я понимал ограничения изнутри. Backend-инженер может прочитать, что мобильные сети ненадёжны, память ограничена, а батарея — критичный ресурс. Но прочитать и прочувствовать — разное. Я годами наблюдал, как приложение “захлёбывается” на устройствах среднего сегмента. Знал, что 60% пользователей сидят именно на таких. Видел, как баг, который мы починили за день, продолжает висеть у людей неделями — просто потому, что они не успели обновиться.

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

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

Чему пришлось учиться с нуля? Операционному мышлению. В Android ты выпускаешь релиз — и он либо работает, либо нет. Если крашится, починишь в следующей версии. В инфраструктуре нет «следующей версии». Если gateway падает, всё приложение ложится для миллионов пользователей прямо сейчас.

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

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

Этому в мобильной разработке не учат.

Как я учился: пробелы, сроки и смена мышления

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

Учился итеративно, не пытаясь объять необъятное сразу. Gateway начинался как простой прокси. Затем добавили агрегацию ответов, потом — конфигурационные определения экранов. Каждый такой шаг вынуждал осваивать следующий уровень: circuit breakers, стратегии повторов, observability, планирование мощностей.

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

Что означает «выдающийся уровень» в инфраструктуре

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

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

Затем — миграция живой системы, где права на ошибку практически нет. Приложение нельзя выключить или отрепетировать в реальном масштабе. Остаётся только постепенный перевод трафика: shadow mode → 1% → 5% → 25% → 50% → 100%, с автоматическим откатом при любом росте ошибок. И всё это — пока миллионы пользователей активно работают с продуктом, не подозревая, что под капотом идёт замена двигателя на ходу. Такой уровень дисциплины и инструментации приходит только с практикой.

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

Почему путь в инфраструктуру доступнее, чем кажется?

Карьерные траектории в инфраструктуре редко бывают чётко описаны. Здесь нет готового чек-листа в духе «диплом по Computer Science, пять лет в бэкенде, обязательное знание Kafka и Kubernetes». С одной стороны, такая неопределённость пугает. С другой — именно она и делает этот путь более доступным, чем принято думать.

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

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

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

Мобильный бэкграунд как преимущество архитектора

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

Я помнил, как ощущается медленный экран на устройстве среднего сегмента. Помнил, что случается, когда API возвращает слегка неправильные данные и приложение падает при парсинге. Помнил то чувство, когда баг уже в проде, а ты ждёшь App Store Review и ничего не можешь исправить.

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

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

Коротко: что делать, если думаете о переходе

• Найдите промежуточный шаг. Не прыгайте сразу в бэкенд. Начните с задач на стыке: оптимизация API, инструменты для мобильных разработчиков, улучшение сетевого слоя.
• Используйте мобильный контекст как рычаг. Вы понимаете то, о чём бэкенд-инженеры только догадываются. Говорите об этом вслух.
• Учитесь измерять невидимое. В инфраструктуре результат — это метрики: latency, error rate, скорость релизов. Учитесь рассказывать историю через цифры.
• Проектируйте под отказ, а не тушите пожары. Senior-уровень — это определить, что сломается и кто за это отвечает, до того, как оно сломается.
• Не ждите разрешения. Путь не размечен, но он открыт. Начните с малого — и двигайтесь туда, где задачи становятся интереснее.

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

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

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

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

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

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

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

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

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

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

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

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

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

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

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

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

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

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

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

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

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

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

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

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

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

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

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

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

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

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

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

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

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

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

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

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

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

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

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

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

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

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

Пример: как тот же сервис мигрировали со второй попытки

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

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

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

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

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

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

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

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

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

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

Компромиссы, к которым нужно быть готовыми

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

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

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

Когда Strangler Fig особенно оправдан

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

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

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

Когда модернизацию лучше не делать

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

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

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

Что получает команда

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

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

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

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

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

Попытка №1. Путь в лоб: Классы и интерфейсы

Самый очевидный способ - создать родительский класс с переменными, а языки сделать его наследниками. Но это просто… фиаско. Даже если не писать from/toJson, процесс выглядит так:

1. Объявил переменную в родителе.
2. Прописал её в конструкторе.
3. Повторил то же самое для всех дочерних классов (всех языков).

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

Попытка №2. Стандарт (ARB/JSON)

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

Почему я от него окончательно отказался? Когда данных становится реально много (десятки языков, тысячи строк), ты попадаешь в ловушку: тебе нужно эту махину либо целиком держать в памяти, либо постоянно подгружать и парсить. Ради смены одного слова на кнопке заставлять девайс ворочать тяжелые JSON-ы в рантайме - так себе затея для производительности.

Попытка №3. Таблицы и костыли

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

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

1. Добавляю строку в таблицу.
2. Запускаю генератор.
3. Он лепит «родительский» файл.
4. После Freezed генерит toJson, fromJson…

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

Красный флаг для программиста

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

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

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

Эволюция лени: почему Enum победил интерфейсы

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

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

Попытка №4. Рекорды (Records)

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

Идеальный костыль: Enum

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

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

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

А здесь мы будем говорить по делу.

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

Реализация

Принцип разделения:

• enum Strings → типизированный контракт (что существует).
• translator → источник данных (откуда берётся текст).

Структура файлов - минимальная. Никаких внешних зависимостей:

Ядро - strings.dart

Весь контракт локализации в одном enum. Два режима - хардкод switch и серверный кеш - за одним и тем же

. Даже сообщения об ошибках локализации — сами локализованы:

Список языков - languages_enum.dart

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

Хотите грузить с сервера? Одна строка + loader. И

- тоже одна строка, потому что

уже является registry:

Переводчик - i18n/russian.dart

Как это выглядит в жизни (и почему я перестал хардкодить) Я намеренно не привожу здесь код оберток виджетов или конкретных стейт-менеджеров. Всё это - чистая «вкусовщина». Для работы системы нужен лишь элементарный вещатель событий (Notifier), повешенный на метод смены языка.

Но главное - это мой ежедневный флоу. Сейчас, чтобы добавить строку в UI, я просто вызываю нужный мне ключ: Strings.someKey(). Без контекста, везде.

А если ключа еще нет? Я тупо иду в Strings и добавляю одну строчку в Enum. Всё.

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

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

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

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

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

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

За это редкое совмещение твёрдых и гибких навыков компании готовы платить в среднем от 380 000 рублей в месяц.

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

Ловушка вчерашнего сеньора

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

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

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

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

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

Чтобы переход из технаря в управленцы не напоминал прыжок без парашюта, Академия Эдюсон запустила курс «Руководитель группы в ИТ (Team Lead в IT)».

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

Всё это — на реальных кейсах и опыте практикующих экспертов из «Яндекса», «Газпромбанка», Coca-Cola и Ozon, в гибком онлайн-формате и с удостоверением о повышении квалификации в конце.

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

Возьмите карьеру в свои руки. Переходите по ссылке и записывайтесь на обучение: https://eduson.academy/team-lead-it. Вводите промокод ТПРОГЕР при оформлении заявки и забирайте максимальную скидку 65%, а в подарок — второй курс на выбор.

Реклама. Рекламодатель: ООО «Эдюсон» ИНН 7729779476, erid: 2W5zFHCBgwB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

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

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

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

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

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

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

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

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

Команда должна знать, кто к ней пришёл

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

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

На старте лучше узнать:

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

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

Наставник

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

Первые задачи

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

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

Отдельно про ТЗ. В тикете почти никогда нет полного контекста. Часть вещей считается само собой разумеющейся, часть обросла локальным сленгом. Сделаете задачу — появится дополнительный контекст, который никто не упомянул, и придётся переделывать. Мотивация падает именно здесь.

Что помогает:

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

Атмосфера

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

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

Три месяца

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

Как выглядит нормальный ритм:

• Еженедельные one-to-one с руководителем — задачи, сложности, обратная связь
• Встреча с HR через две недели — как адаптируетесь, всё ли понятно, нужна ли дополнительная поддержка
• Итоговая встреча через три месяца — что получилось, что нет, что дальше

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

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

На что смотреть

Три признака, что онбординг нормальный:

• Техника пришла до первого дня, доступы открыты, HR на связи.
• Есть наставник и план на три месяца.
• Вас представили команде — не попросили познакомиться самому.

Три красных флага:

1. Нет наставника вообще.
2. Нет плана задач даже на первый месяц.
3. HR исчез после первого дня и больше не появлялся.

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

1. Как я утонул в генерациях
2. Экзамен вместо «прыжков» по сервисам
3. Небольшой технический конвейер
4. Зачем цифры важнее впечатлений
5. Простой тест на форматы
6. Как ведут себя Riverflow, Flux и Seedream
7. Отчёты, артефакты и спокойная аналитика
8. Сценарий «восемь формулировок»
9. Зрелый подход к выбору AI

В прошлой статье я рассказывал, как собрал тестовый стенд для AI‑генерации. Теперь — про то, как превратил его в живой процесс с разными сценариями и метриками.

1. Как я утонул в генерациях

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

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

2. Экзамен вместо «прыжков» по сервисам

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

3. Небольшой технический конвейер

Реализация получилась до обидного простой. Node.js, TypeScript, запуск через tsx. Список моделей вынесен в отдельный конфиг, API-ключ лежит в .env, а команды запуска выглядят вроде npm run test:niche или npm run test:collage-2x2-eight-prompts. Я взял творческий хаос и сложил его в аккуратный pipeline.

Дальше всё происходит автоматически: запускаешь тест — и один и тот же набор задач последовательно проходит через всех кандидатов. Мой вклад заканчивается на нажатии Enter.

4. Зачем цифры важнее впечатлений

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

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

5. Простой тест на форматы

Возьмём самый базовый пример — проверка соотношения сторон. Формулировка элементарная: закат над горами, три варианта — 3:4, 1:1 и 16:9. Казалось бы, минимальный уровень адекватности. Но нет.

Достаточно пробежать глазами столбец со статусом. Три запроса — три быстрых проверки «на глаз». Там, где на 3:4 и 16:9 горит FAIL, модель откровенно игнорирует задачу и рисует квадрат или удобный для себя формат. И это при том, что промпт простейший: не сложная сцена, не коллаж — всего лишь «закат, горы и нужная рамка».

6. Как ведут себя Riverflow, Flux и Seedream

Если посмотреть на результаты, riverflow-v2-pro аккуратно соблюдает все три формата. Но за эту аккуратность приходится платить временем: портретная картинка генерируется около 360 секунд. Шесть минут — роскошь, если у вас в руках горящий дедлайн. Упрощённая версия, riverflow-v2-fast, выдаёт правильные форматы за секунды и остаётся в адекватных рамках по времени — это уже инструмент для реальных задач.runware+2

С моделями Flux история другая. Почти вся линейка black-forest-labs стабильно промахивается по нестандартным форматам: колонка «Соотношение» упорно показывает 4/3 или 1/1, хотя в запросе чётко указано «16:9, wide landscape». Относительно ровно ведёт себя только flux.2-max, который хотя бы честно выдаёт квадрат, но проблемы с другими соотношениями никуда не деваются.github+1

Seedream-4.5 от Bytedance, напротив, поражает скоростью: ответы прилетают за 7–8 секунд, но модель регулярно игнорирует заданный формат и возвращает квадрат 2048×2048. Для макета, привязанного к конкретным пропорциям — сторис, постера или баннера — такая «быстрота» только ломает всю вёрстку.eachlabs+1

7. Отчёты, артефакты и спокойная аналитика

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

Особенно сильно это помогает в задачах, где критична композиция: нужна ровная сетка 2×2 или 3×3 без самодеятельности в духе «я тут чуть подвину, так красивее». Это как раз те случаи, когда от сервиса нужна дисциплина, а не внезапные художественные «инициативы».

8. Сценарий «восемь формулировок»

Отдельный пласт наблюдений даёт сценарий «восемь формулировок» (collage-2x2-eight-prompts). Суть задачи не меняется, контент остаётся одним и тем же. Я варьирую только подачу: где-то пишу запрос грубо и коротко, где-то — щадяще и структурно, местами добавляю лишний контекст.

На этом месте становится видно, как модель реагирует не на саму тему, а на стиль запроса. Одна и та же нейросеть спокойно выдерживает строгое техническое ТЗ и проваливается при формулировке «сделай красиво, сам понимаешь». После таких тестов по-другому относишься к промптам: начинаешь формулировать точнее, понимая, какая модель как «слушает» текст. И внезапно исчезают загадки в духе «почему здесь получилось, а там всё развалилось».

9. Зрелый подход к выбору AI

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

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

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

Что он делает

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

Запрос "проблемы с авторизацией" найдет запись про "token refresh rotation", хотя слова совершенно разные. Работает через эмбеддинги и косинусное расстояние, скоро выйдет фича с анализом смысловой корреляции при поиске.

Подключение

Шаг 1: регистрация

Заходим на coally.cortexally.ai, создаем аккаунт. Получаем API ключ.

Шаг 2: подключение к агенту (Claude, Cursor и др.)

Одна команда в терминале:

claude mcp add coally-nexus --transport sse https://coally.cortexally.ai/sse --header "Authorization: Bearer ВАШ_КЛЮЧ"

Перезапускаем Claude Code. В списке MCP-инструментов должен появиться coally-nexus.

Cursor, Windsurf, VSCode

Заходим в настройки Cursor -> Settings -> MCP -> Settings (значок шестеренки) или создаем/редактируем файл `.cursor/mcp.json` в корне проекта (или в домашней директории для глобального подключения):

Файл `~/.codeium/windsurf/mcp_config.json` для Windsurf или соответствующее меню для VSCode и других его форков.

Перезапускаем IDE|Agent. Готово.

Первая сессия

После подключения агент при первом взаимодействии проиндексирует проект автоматически. Если нет - попросите: "проиндексируй этот проект через CoAlly".

Что происходит при индексации: сканируется дерево проекта, находятся конфиги, важные воспоминания, memorybanks и др., все это эмбеддится и сохраняется как контекст.

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

Что получаем

На вопрос "что вчера делали по задаче авторизации? какой статус бага с токеном и сколько времени потребуется на доработку" Агент достает из CoAlly записи: "вчера в Cursor поправили ротацию токенов, причина была в TTL, затронули два файла. Могу сразу продолжить и на основе коммитов ... исправить точечно флоу, время на исправление — N минут."

Если работаете в команде - еще полезнее. Контекст коллеги тоже доступен. Его экспертиза и навыки также постепенно приобретают цифровую версию. Не нужно ждать стендап или писать в Slack.

Ограничения

Агенты иногда игнорируют инструкции и не сохраняют контекст. Бывает. Можно просить явно.

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

Бесплатный тариф - 2 проекта. Для личного использования хватает. Для команд - тарифы Team и Enterprise.

Эксперты Centicore Group собрали чек-лист из 12 пунктов, которые реально работают при выборе интегратора, а когда у вас станет вопрос подрядчика – вы можете воспользоваться этим списком.

1. Опыт в вашей индустрии

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

Что проверять:

1. Портфолио с проектами в вашей сфере. Нужны конкретные кейсы: что делали, какой стек, какие результаты.
2. Понимание специфики. Если интегратор сразу задаёт правильные вопросы про ваши бизнес-процессы — хороший знак. Если предлагает типовое решение без погружения в специфику — советуем искать дальше.
3. Измеримые результаты. Везде понятные показатели: на сколько сократили время обработки заявок, сколько проект занял по времени, какая команда специалистов и к чему в итоге пришли.

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

2. Что по техстеку и обновлениям

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

На что смотреть:

1. Соответствие вашему контуру. Если у вас закрытый on-premise, а подрядчик умеет деплоить только в публичные облака — вам не по пути.

2. Релевантные сертификаты и лицензии. Если делаете финтех — нужен опыт прохождения PCI DSS. Если работаете с госсектором или персональными данными — ищите подрядчика с лицензиями ФСТЭК и ФСБ.

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

4. Геополитические и санкционные риски. В 2026 году для российского рынка это один из ключевых рисков. Что здесь нужно проверять:

• Зависимость от иностранных облаков и компонентов.
• Отдельно open-source библиотек и фреймворков с высокой санкционной уязвимостью.
• Наличие у подрядчика плана «Б» на случай новых ограничений (альтернативные поставщики, российские облака, on-premise).
• Опыт работы с проектами, которые уже проходили через санкционные ограничения.

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

5. Отношение к ИИ-инструментам и low-code решениям. В 2026 году почти все интеграторы так или иначе используют ИИ (Cursor, GitHub Copilot, Claude, внутренние агенты). Важно понимать политику компании. Что проверять:

• Есть ли у подрядчика регламент использования ИИ-инструментов (что разрешено, что запрещено, как проверяется код, сгенерированный ИИ).
• Насколько активно они применяют low-code/no-code платформы и как это влияет на качество и поддержку решения.
• Готовы ли они комбинировать ИИ + ручную разработку или полностью полагаются на «ИИ всё сделает».
• Есть ли у них экспертиза по prompt engineering и проверке качества ИИ-генерируемого кода.

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

3. Насколько гибкие в разработке

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

Что важно:

1. Подход к кастомизации показывает философию компании. Если подрядчик сразу говорит о готовом решении и предлагает подстроить бизнес-процессы под него — это провал для специфичных задач. Подбор решения под клиента, а не наоборот — признак зрелого подхода.
2. Работа с изменениями — реальность любого проекта. Требования меняются в процессе, это нормально. Agile не на словах, а на деле означает готовность пересмотреть приоритеты, адаптировать бэклог, обсуждать изменения.
3. Понимание бизнес-задачи отличает хорошего интегратора от посредственного. Технари часто зацикливаются на том, как реализовать, забывая спросить, зачем это нужно. Вопрос о том, какую проблему решает функция, должен звучать чаще, чем обсуждение технологии.

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

4. Прозрачность процессов

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

Как оценить прозрачность:

1. Структура коммуникации определяет скорость решения вопросов. Кто ваш контакт — менеджер без технической экспертизы или техлид команды? Как быстро получаете ответы? Есть ли прямой доступ к разработчикам для обсуждения технических деталей?
2. Регулярная отчётность — это не бюрократия, а инструмент контроля. Демо каждый спринт, доступ к таск-трекеру вроде Jira, понимание прогресса в реальном времени. Компании с 24/7 поддержкой обычно имеют настроенные процессы коммуникации и реагирования.
3. Документация показывает зрелость процессов. Если подрядчик не может показать примеры технической документации, процессов разработки, архитектурных решений — это тревожный звонок.
4. Совпадение ценностей и корпоративной культуры. Технические навыки важны, но если ценности не совпадают — проект будет постоянным источником конфликтов. Попросите пообщаться не только с техлидом, но и с 1–2 разработчиками, которые будут работать над проектом. Задайте вопросы про их реальный опыт работы в компании. Что проверять:

• Отношение к удалённой работе и овертаймам (есть ли культура «гореть на проекте» или уважают work-life balance).
• Прозрачность внутри компании (как принимаются решения, насколько открыто руководство общается с командой).
• Отношение к качеству vs скорость (готовы ли отказываться от «быстрых костылей» ради долгосрочного результата).
• Корпоративные ценности: как компания относится к клиентам, к сотрудникам, к этике в разработке.

Красные флаги:

1. Вам говорят, что всё хорошо, но конкретики нет. Нет демо, доступа к репозиторию, промежуточных результатов. А потом в день дедлайна выясняется, что половины функционала нет. Нормальная практика — давать клиенту видимость работы: задачи, коммиты, тесты.
2. Проводите демо результатов каждые 1-2 недели. Так будете видеть рабочий код, сможете проверить функционал, задать вопросы напрямую техлиду. Ошибки дешевле исправлять на ранних этапах, чем в продакшене.
3. Команда говорит одно на собеседовании, а на деле — жёсткий overtime, токсичная культура и «мы просто кодим, а менеджеры решают».

5. Команда и культура разработки

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

Что проверять:

1. Квалификация разработчиков определяет скорость и качество работы. Соотношение мидлов и сеньоров в команде показывает, кто будет делать архитектурные решения, а кто — рутинные задачи. Если в команде только джуны под управлением одного сеньора — это риск.
2. Текучка кадров — критический показатель стабильности. Высокая текучка означает проблемы: либо с зарплатами, либо с управлением, либо с атмосферой. Всё это отразится на вашем проекте.
3. Практики разработки видны в деталях. Code review, автоматизированное тестирование, CI/CD — это страховка от багов в продакшене. Спросите, как организован процесс: делают ли ревью кода, какое покрытие тестами, как часто деплоят.

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

6. Пост-интеграционная поддержка

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

На что смотреть:

1. Гарантии и доработки. Что будет, когда система упадет из-за архитектурной ошибки вендора? Условия фикса багов и доработок после релиза должны быть зафиксированы в контракте.
2. Контроль ответственности. Должно быть четко расписано, где заканчивается зона ответственности интегратора и начинается зона ваших админов, девопсов или первой линии поддержки.
3. Документация и передача знаний. Подрядчик обязан выгрузить не только исходники, но и актуальную документацию: ADR (архитектурные решения), схемы инфраструктуры, регламенты развертывания.

Юридическая и договорная часть. Условия расторжения договора и стратегия. Кто владеет кодом и данными после завершения проекта. Штрафы за срыв сроков и SLA. Право на аудит кода и инфраструктуры.

7. Безопасность и комплаенс

1. Проверяйте сертификаты и стандарты: ISO 27001 по информационной безопасности, соответствие ФЗ-152 о персональных данных, отраслевые стандарты вроде PCI DSS для платёжных систем.
2. Пентесты, аудит кода на уязвимости, шифрование данных, управление доступами — всё это должно быть в процессе по умолчанию.
3. Убедитесь, что контракт чётко прописывает, кому принадлежит код, как защищаются ваши данные, какие санкции за утечку.

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

8. Реальные кейсы и рекомендации

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

1. Соблюдение сроков — классический больной вопрос IT-проектов. Уложились ли в первоначальные оценки? Если были задержки — как объясняли и решали?
2. Работа с изменениями — насколько гибко подрядчик реагировал на новые требования? Были ли конфликты по поводу доп.функционала?
3. Качество коммуникации — как быстро отвечали, насколько понятно объясняли технические вещи, был ли прямой контакт с командой?
4. Пост-поддержка — что происходило после запуска? Быстро ли реагировали на проблемы? Помогли ли с развитием продукта дальше?

9. Финансовая прозрачность

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

На что смотреть:

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

Красные флаги:

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

10. Масштабируемость решения

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

1. Проектирование под рост бизнеса отличает стратегическое мышление от тактического. Хороший интегратор спросит о ваших планах: сколько пользователей сейчас, сколько планируется через год, через три года. И заложит архитектуру с запасом.
2. Постепенное расширение функционала дешевле полной переделки. Модульная архитектура, микросервисы, API-first подход — всё это позволяет добавлять новые возможности без переписывания существующего кода.
3. Управление техническим долгом. Любая разработка накапливает технический долг: быстрые решения, костыли, устаревшие зависимости. Профессионалы планируют рефакторинг, выделяют время на улучшение кода, следят за обновлениями библиотек.
4. Vendor lock-in и технологическая независимость. Хороший интегратор не строит систему так, чтобы вы навсегда зависели от его экспертизы, конкретного облака или проприетарного инструмента. Проверяйте: на каких лицензиях работает стек, можно ли сменить подрядчика без переписывания системы, кто владеет кодом и есть ли возможность развивать продукт силами инхаус-команды.

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

11. Скорость и качество коммуникации

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

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

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

12. Репутация на рынке и стабильность

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

Что оценивать:

1. Время на рынке — один из положительных сигналов, но не гарантия. Компании с опытом 8+ лет, как правило, пережили кризисы, накопили экспертизу и выстроили процессы. Но возраст сам по себе не означает качество: проверяйте кейсы, репутацию и стабильность команды, а не только дату основания. Стартапы могут быть инновационными — просто риски у них другие.
2. Финансовая устойчивость проверяется косвенно: по масштабу проектов, количеству офисов, размеру команды.
3. Участие в профессиональных мероприятиях показывает открытость. Компании, которые выступают на конференциях, пишут статьи, делятся опытом, обычно уверены в своей экспертизе. Это также помогает проверить репутацию через знакомых в индустрии.
4. Партнёрские отношения с крупными вендорами — ещё один индикатор.

Проверка на негатив:

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

Как использовать чек-лист

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

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

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

Если верить статистике, сейчас ежедневно создается около 402,74 миллионов терабайт данных.

Согласитесь, довольно внушительная цифра.

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

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

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

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

Вот почему мы подыскали аналог Nextcloud – ownCloud. В отличие от более функционального Nextcloud, ownCloud заточен исключительно на работу с файлами. И при этом он поддерживает подключение облачного объектного хранилища S3. Поэтому для нас в сравнении Nextcloud vs ownCloud выбор был очевиден.

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

Что может ownCloud

Для начала – буквально несколько слов об ownCloud и его возможностях.

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

OwnCloud позволяет:

1. получать доступ к данным из любой точки мира и хранить файлы на собственном сервере – под вашим полным контролем;
2. синхронизировать данные между устройствами – доступ к файлам возможен с компьютеров (Windows, macOS, Linux), смартфонов (iOS, Android) и через браузер, изменения на одном устройстве мгновенно появляются на всех остальных;
3. делиться файлами и папками по ссылке, настраивая права доступа, пароли и срок действия ссылок;
4. совместно работать с документами, отслеживать историю изменений и возвращаться к любой предыдущей версии файла.

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

Сегодня ownCloud используют компании (Philips, Nationwide, Zeppelin и др.) в самых разных сферах (IT, машиностроение, медицина и т. д.).

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

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

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

Для каких задач мы используем ownCloud и S3

1. Централизованное управление материалами

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

В итоге каждый член команды может видеть версии файлов (это важно для правок), нет хаоса в почте и мессенджерах.

2. Безопасное взаимодействие с подрядчиками

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

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

3. Долгосрочный архив креативов и отчетов

По закону (152-ФЗ в РФ или GDPR в Европе) компания обязана хранить персональные данные клиентов, а также отчеты о рассылках и рекламных акциях на протяжении определенного времени.

Для решения этой задачи мы настроили правило: файлы старше 90 дней автоматически перемещаются в S3 Glacier (холодное хранилище) – этот класс снижает стоимость хранения, а если, например, юристу понадобится скачать какой-нибудь отчет спустя 2–3 года, он просто выгрузит его из ownCloud буквально за 5–10 минут.

Теперь – в деталях и по шагам о том, как начать использовать ownCloud в связке с S3.

Как развернуть ownCloud и подключить S3

OwnCloud удобно использовать с объектным хранилищем S3 – таким образом можно:

1. масштабировать систему – S3 расширяется автоматически и не имеет ограничений по объему и количеству размещаемых данных и файлов;
2. оптимизировать затраты – можно платить не за дорогую конфигурацию виртуального сервера с большим объемом диска, а лишь за фактически занимаемое место, по модели pay as you go (оплата по мере потребления);
3. повысить надежность хранения – за счет встроенной в S3 тройной репликации данных (файлы хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности данных).

Итак, разберем, как настроить связку ownCloud и S3.

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

Для размещения ownCloud в нашем примере создадим виртуальный сервер на базе готового решения Docker.

Можно подключиться к серверу по SSH или с помощью терминала в панели управления.

Для размещения файлов создайте бакет объектного хранилища S3. Реквизиты доступа к нему будут в карточке бакета в панели:

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

Затем вставьте в файл docker-compose.yml следующее содержимое с помощью любого текстового редактора:

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

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

1. ownCloud_DOMAIN и ownCloud_TRUSTED_DOMAINS – укажите домен (так как ownCloud будет размещен за обратным прокси, указывать рабочий порт здесь не требуется);
2. ADMIN_USERNAME – логин администратора;
3. ADMIN_PASSWORD – пароль администратора.

Обратите внимание! Изменение ADMIN_USERNAME и ADMIN_PASSWORD уже после развертывания контейнеров не возымеет эффекта. Изменить пароль администратора вы можете в настройках пользователя в веб-интерфейсе.

Далее необходимо указать параметры подключения к S3.

• ownCloud_OBJECTSTORE_BUCKET – имя бакета S3;
• ownCloud_OBJECTSTORE_ENDPOINT – эндпоинт хранилища (например, https://s3.ru1.storage.beget.cloud);
• ownCloud_OBJECTSTORE_REGION – регион (ru1 для Beget);
• ownCloud_OBJECTSTORE_KEY – Access key бакета;
• ownCloud_OBJECTSTORE_SECRET – Secret key бакета.

Сохраните файл.

Остается лишь добавить файл конфигурации для Caddy – обратного прокси, через который пользователи будут получать доступ к ownCloud.

Создайте директорию config:

После чего создайте в ней файл конфигурации Caddyfile. Добавьте в него следующее содержимое, указав вместо ownCloud.betutorial.ru ваш домен ownCloud:

Обратите внимание! Caddy выпустит SSL-сертификат на домен автоматически.

Все запросы к домену будут проксироваться в контейнер ownCloud_server.

На этом настройка конфигурационных файлов завершена, можно запускать контейнеры:

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

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

Выполните вход со стандартными доступами.

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

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

Теперь проверим работу объектного хранилища – перейдем на главную страницу и загрузим файлы:

Файлы также появились и в объектном хранилище:

Обратите внимание! Файлы, которые вы удалите в ownCloud, будут перемещены в корзину и останутся в S3. Для их полного удаления очистите корзину ownCloud.

Чтобы делиться паролями с новыми пользователями, необходимо настроить отправку почты в ownCloud, сделать это можно в разделе Settings>General.

В нашем примере мы настроим отправку через SMTP:

После указания данных введите тестовый email и нажмите “Send email”. Если отправка успешна, вы получите уведомление об этом:

А на почтовый ящик поступит письмо:

На этом настройка завершена – можно начинать работать с файлами, используя связку ownCloud и S3.

Заключение

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

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

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

Однако недавно проект получил второе дыхание. Разработчик Александр Тишов (Amro) — создатель CMS Seditio и основатель веб-студии «Авего» — выпустил Denwer SE (Second Edition). Это не просто обновление, а полный реинжиниринг с сохранением классической философии: портативность, скорость работы и привычная структура каталогов.

В этой статье разберём, что изменилось под капотом, почему панель управления переехала с Perl на Python, как работает автоматический HTTPS с собственным корневым сертификатом и зачем нужен зоопарк версий PHP от 5.6 до 8.5.

Краткий экскурс: от Denwer 3 до Denwer SE

Оригинальный Denwer (сокращение от Джентельменский Набор Веб-разработчика) появился в начале 2000-х. Он представлял собой связку Apache + PHP + MySQL, упакованную в самораспаковывающийся архив. Главные фишки:

• Виртуальный диск (по умолчанию Z:), который монтировался через subst.
• Автоматическое создание виртуальных хостов по именам папок в home.
• Консольные exe-файлы (Run, Stop, Restart) без графического окна.

Проблемы оригинала:

• Управление на Perl — медленно, тяжело поддерживать в Windows.
• Только 32-битные компоненты.
• Невозможно быстро переключать версии PHP или БД.
• Отсутствие нормального HTTPS (только самоподписанные сертификаты с ошибками в браузере).
• Поддержка прекратилась в 2016 году.

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

Архитектура: Python вместо Perl

Denwer SE — панель управления написана на Python и скомпилирована в один EXE-файл (через PyInstaller).

Внутри служебной папки denwer\ лежат:

• DLL-версия Python — интерпретатор, который использует основной исполняемый файл.
• Скомпилированные модули .pyd — в том числе GUI на базе Tcl/Tk для оконного интерфейса и системного трея.
• Минимальный набор библиотек для управления службами, правки hosts и генерации сертификатов.

Это даёт несколько преимуществ:

• Портативность — панель ищет соседние папки home и usr, поэтому каталог со стеком можно переносить куда угодно без переустановки.
• Скорость — Python-скрипты запускаются быстрее, чем Perl, особенно на холодном старте.
• Читаемость кода — разработчику проще поддерживать и расширять функционал.

Полный переход на x64

Оригинальный Denwer навсегда остался 32-битным, что в современных реалиях просто неприемлемо. Denwer SE собирается исключительно под x64:

• Apache (версия 2.4.x) — 64-битный.
• Все модули PHP (от 5.6 до 8.5) — Thread Safe x64.
• MySQL / MariaDB — 64-битные сборки.

Системные требования — Windows 7/8/10/11 (x64). Для работы компонентов потребуются Microsoft Visual C++ Redistributable (VC11, VC12, VC14, VC15). Разработчик положил установщики этих пакетов в папку vcredist\ — при необходимости можно доустановить вручную.

Структура каталогов: преемственность и гибкость

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

Главный конфиг — usr\configuration.txt. В нём задаются пути без жёсткой привязки к букве диска, например:

При старте панель монтирует виртуальный диск (по умолчанию Z:) и динамически подставляет путь через переменную subst_drive.

Управление версиями PHP и БД без танцев с бубном

В Denwer SE встроен менеджер версий. Вы просто выбираете из выпадающего списка нужную версию PHP (например, 8.3 или 5.6) — панель сама правит конфигурацию Apache.

Как это работает под капотом:

В папке usr/local/apache/php лежат подкаталоги php5.6, php7.4, php8.3 и т.д..

В каждом из них есть файл php-denwer.conf— шаблон для подключения модуля к Apache. При выборе версии этот файл копируется в conf/extra/httpd-denwer.conf, который затем включается в основной httpd.conf.

Если вы хотите добавить свою сборку PHP (например, PHP 8.4-rc), достаточно:

• Распаковать x64 Thread Safe версию в отдельный каталог внутри php\.
• Создать php-denwer.conf по образцу.
• Убедиться, что все DLL от VC++ установлены.

Аналогично для баз данных: переключение между MySQL 5.7 и MariaDB 11.8 происходит через тот же интерфейс. В каталоге СУБД может лежать файл db-denwer.conf, который при старте копируется в my.ini.

HTTPS, который не бесит: локальный Root CA

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

Denwer SE решает проблему элегантно — он создаёт собственный корневой центр сертификации (CA) и подписывает им сертификаты для всех ваших локальных доменов.

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

1. При первом запуске (если найден OpenSSL) панель генерирует ключи denwer-ca.key и сертификат denwer-ca.crt в папку usr/local/apache/conf/cert/denwer-ca/.
2. Для каждого виртуального хоста (папки в home/) автоматически создаётся сертификат в conf/cert/<domain>/.
3. Все сертификаты хостов подписаны локальным CA.

Чтобы браузер доверял им, нужно один раз установить denwer-ca.crt в хранилище «Доверенные корневые центры сертификации» Windows. Для этого в панели есть специальная кнопка (требует прав администратора).

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

Удобства для разработчика (DX)

В версии 1.2.4 добавили несколько фич, которые экономят время каждый день:

• Лог с таймштампами — каждая строка в окне панели имеет префикс [чч:мм:сс]. Теперь видно, сколько секунд сервер поднимается и где возможны задержки.
• Прямой доступ к php.ini и my.cnf — рядом со списками версий появились кнопки, открывающие конфигурацию именно активной версии.
• Автоматическое ведение hosts — панель в реальном времени сканирует home/, находит новые домены и прописывает их в C:\Windows\System32\drivers\etc\hosts. Журнал добавляемых записей сохраняется в usr\AddedHosts.txt. При остановке стека лишние строки удаляются.
• Для смены версии PHP или базы данных панель требует полной остановки всех служб. Вы нажимаете «Стоп», меняете версию в списке, затем «Старт» — и стек поднимается уже с новыми настройками. Автоматический перезапуск без вашего участия работает только для Apache: когда вы добавляете новый домен в папку home/, панель сама переписывает vhosts.conf и перезапускает веб-сервер, не трогая БД.

Почему не Open Server или Docker?

Этот вопрос закономерно возникает у всех, кто видит очередной локальный веб-сервер. Ведь есть уже давно Open Server Panel, Laragon, XAMPP, а для продвинутых — Docker. Зачем ещё один?

Open Server — мощный и удобный комбайн с десятками версий PHP и настройками «на века». Но он разворачивается в системе не портативно: создаёт папки в ProgramData, пишет в реестр, а запуск может занимать 5–10 секунд. Denwer SE, напротив, полностью переносим: скопировал папку на флешку или в облачный каталог — и всё работает. Запуск стека — буквально 1–2 секунды, что критично, когда вы десятки раз за день перезапускаете сервер для тестов.

Docker — индустриальный стандарт для изоляции и воспроизводимости окружений. Но для локальной разработки простого сайта он часто избыточен. Вам нужно разобраться в образах, контейнерах, пробросе портов, volume’ах и docker-compose.yml. А в Denwer SE вы просто создали папку в home/ — и готово. Никакой работы с командной строкой, никакого потребления гигабайт ОЗУ на фоновую службу Docker Desktop.

Laragon — быстрый, портативный, поддерживает не только PHP, но и Node.js, Python, Go. Но он ориентирован на современные фреймворки, особенно Laravel. Denwer SE же сделан для тех, кто вырос на классическом Денвере: виртуальный диск Z:, папка home/имя_домена/www, минимум настроек. Не нужно переучиваться — просто распаковал и работаешь как 10 лет назад, но с новыми версиями PHP и HTTPS.

Как начать пользоваться Denwer SE

1. Скачать архив с официального сайта автора.
2. Распаковать в любое место, например C:\web\DenwerSE\.
3. Запустить DenwerSE.exe — если нет прав администратора, попросит их для монтирования диска и правки hosts.
4. Нажать «Запустить» — появится виртуальный диск Z:, а в системном трее иконка.
5. Создать папку сайта — например, home\myproject.local и положить туда index.php.
6. Открыть в браузере http://myproject.local/ (или https://myproject.local/). HTTPS будет работать сразу после установки корневого сертификата (кнопка в панели).

По умолчанию пароль к MySQL/MariaDB — пустая строка (пользователь root). При желании его можно сменить через phpMyAdmin.

Заключение

Denwer SE — это не просто ностальгический проект. Это действительно современный инструмент, который доказывает, что концепция «локального сервера в одну папку» всё ещё актуальна. Отказ от Perl в пользу Python, менеджер версий PHP/БД, нормальный HTTPS, портативность и мгновенный запуск — всё это делает его отличным выбором для быстрого прототипирования, тестирования легаси-кода или обучения веб-разработке.

Если вы устали ждать, пока Open Server применит настройки, или не хотите разбираться в Docker Compose — попробуйте Denwer SE. Вероятно, он напомнит вам старые добрые времена, но уже без боли устаревших технологий.

• Автор проекта: Александр Тишов (Amro), разработчик CMS Seditio.
• Лицензия: Freeware.
• Совместимость: Windows 7/8/10/11 x64.

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

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

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

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

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

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

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

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

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

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

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

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

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

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

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

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

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

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

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

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

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

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

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

Мультиустройство: один пользователь, несколько конвертов

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

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

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

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

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

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

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

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

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

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

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

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

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

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

Как устроен InferSim

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что в итоге

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

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

Альтернативой выступают гибридные архитектуры, в которых традиционное внимание чередуется с более экономичными механизмами: Mamba‑2, Gated DeltaNet. Разработчики этих моделей заявляют о радикальном снижении потребления памяти и повышении пропускной способности без потери качества. В данном материале рассматриваются три открытые гибридные модели — NVIDIA Nemotron‑Nano‑9B‑v2, Bamba‑9B‑v2 (IBM) и Qwen3.5‑9B (Alibaba) — и сравниваются с референсной плотной моделью Llama 3.1 8B.

Методика моделирования

Моделирование проводилось для одного ускорителя NVIDIA H200 с 141 ГБ видеопамяти при типичной нагрузке: 4096 входных токенов и до 256 выходных. Рассчитывались следующие метрики: память на один экземпляр с учётом весов, оверхеда и KV‑кеша (Instance VRAM); полное время ответа (E2E Latency); пропускная способность одного экземпляра в запросах в секунду (RPS per replica); требуемый объём памяти на единицу пропускной способности (VRAM/RPS); максимальное число параллельных запросов, ограниченное исключительно памятью. Расчёты верифицировались с помощью расширенного симулятора InferSim и по данным публичных бенчмарков.

Результаты

Особенности производительности моделей

Разница на порядок по KV-cashe у Nemotron обусловлена архитектурой. Модель содержит 56 слоёв, из которых лишь четыре используют полноценное внимание с KV‑кешем, а остальные 52 — сверхбыстрые Mamba‑2‑блоки. Mamba‑2 работает как рекуррентная сеть: вместо хранения растущей таблицы ключей и значений для каждого токена она обновляет компактное скрытое состояние фиксированного размера. В результате для запроса длиной 4096 + 256 токенов KV‑кеш Nemotron занимает около 68 МБ — примерно в восемь раз меньше, чем у Llama. Именно поэтому модель способна удерживать в памяти почти 2000 одновременных запросов; узким местом становится не память, а вычислительная мощность GPU.

Архитектура Qwen3.5 построена на чередовании Gated DeltaNet и Gated Attention. Большинство слоёв использует механизм линейного внимания, который подобно Mamba‑2 оперирует скрытым состоянием постоянного размера, не порождая тяжёлого KV‑кеша. Однако у этого подхода есть обратная сторона: Gated DeltaNet работает последовательно, послойно обновляя внутреннее состояние, и плохо утилизирует матричные вычисления GPU. На коротких дистанциях классический Attention с его эффективным матричным умножением способен загрузить видеокарту почти полностью, тогда как GDN‑слои проигрывают в чистой скорости. В результате TTFT у Qwen3.5 для 4096 токенов составляет 1.86 с против 1.32 с у Llama. На очень длинных контекстах (100K токенов и выше) ситуация меняется: классический KV‑кеш становится тормозом, а Gated DeltaNet продолжает работать с прежней эффективностью.

О качестве и специализации моделей

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

Llama 3.1 8B — референсная плотная модель. Показывает 69.4% на MMLU и 72.6% на HumanEval. Это проверенный универсал для задач, где важна предсказуемость и стабильность, а не максимальная производительность.

Nemotron‑Nano‑9B‑v2 позиционируется как математик и кодер. По данным NVIDIA, модель достигает 72.1% на AIME25, 97.8% на MATH500, 64.0% на GPQA Diamond и 71.1% на LiveCodeBench. Эти результаты делают её сильнейшим вариантом для задач, требующих точных вычислений и генерации корректного кода.

Qwen3.5‑9B является универсальным «эрудитом». Модель превосходит GPT‑OSS‑120B по MMLU‑Pro (82.5%) и GPQA Diamond (81.7%), а также показывает 83.2% на HMMT. Высокое качество на широком спектре тестов позволяет использовать её в сценариях, где важны широкий кругозор и точность ответов.

Bamba‑9B‑v2 — быстрый универсал, превосходящий Llama 3.1 8B по среднему баллу OpenLLM v2. Она не специализируется на одной задаче, но обеспечивает хорошее качество при заметно более высокой скорости.

Рекомендации

• Для чат-ботов и потоковой обработки с высокой пропускной способностью оптимален Nemotron‑Nano‑9B‑v2 — он в полтора раза быстрее Llama и примерно на 30% эффективнее использует память (VRAM/RPS 45.8 против 65.0 ГБ·с).
• Для саммаризации, аналитики документов и агентных систем, где во главе угла широкий кругозор и качество ответа, лучше подходит Qwen3.5‑9B.
• Bamba‑9B‑v2 занимает промежуточную позицию: она даёт заметный прирост скорости при сопоставимом с Llama объёме памяти и может использоваться как универсальный инструмент.

Заключение

Большие языковые модели по‑прежнему требуют значительных вычислительных ресурсов. Однако прогресс в архитектурах — Mamba‑2, Gated DeltaNet — шаг за шагом снижает стоимость владения: на одном H200 теперь можно обслужить заметно больше клиентов, чем год назад. Выбор модели перестаёт быть гаданием по маркетинговым обещаниям и превращается в инженерную задачу с чёткими метриками.

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

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

Вместо введения: контекст и герои обзора

Долгое время в Яндекс 360 для работы с документами использовались редакторы Р7 офис. Они никуда не делись и по-прежнему работают. Не так давно Яндекс начал развивать и собственные редакторы. Осенью 2025 года они вышли из стадии бета-тестирования и медленно стали обрастать функциями.

Поскольку познакомиться с ними довольно просто — достаточно переключить соответствующий ползунок в разделе «Документы» в Яндекс 360, — я это и сделал. Заодно стало интересно посмотреть, как новые редакторы Яндекса выглядят на фоне Р7 офис и Google Docs, которые для многих давно стали привычной точкой отсчёта.

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

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

Если же говорить о Р7 офис, как о другом участнике этого сравнения, то его логика иная. Это скорее попытка дать пользователю более классический офисный опыт: с широким набором функций, несколькими вариантами использования и более серьёзной совместимостью с привычными офисными форматами (DOCX, XLSX, ODT и пр.). ИИ-ассистент также имеется в текстовом редакторе. Пользоваться Р7 можно в браузере, в виде приложений для Windows и Linux, на мобильных устройствах, а при желании и развернуть у себя на сервере. Функциональность здесь ощутимо шире, чем у новых редакторов Яндекса.

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

Простота, минимализм и всё, что из этого следует

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

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

Но лёгкость — вещь приятная ровно до того момента, пока не начинаешь искать функции, к которым привык.

Например, меню «Файл» в новых редакторах Яндекса на момент тестирования выглядело очень скромно: фактически там доступны только «Скачать» и «Печать». Документ можно выгрузить в DOCX или XLSX, либо в PDF. И здесь особенно заметно, насколько по-разному устроены конкуренты.

В Р7 офисе список экспортируемых форматов ощутимо шире: можно сохранять в OpenDocument, RTF, EPUB, PDF, JPG и не только.

Google Docs, хотя и хранит документы в собственном формате, тоже позволяет скачать их в DOCX, XLSX, PDF, RTF, EPUB, а в некоторых случаях — и в Markdown.

Что умеют текстовые редакторы — и чего в них пока нет

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

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

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

И в Google Docs:

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

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

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

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

Таблицы: базовые и сложные сценарии

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

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

Для проверки я открыл старый тестовый XLSX-файл, который когда-то специально собирал как пример таблицы с непростым форматированием. Так его демонстрирует Р7 офис, вполне корректно.

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

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

После нажатия кнопки “Понятно” редактор визуализирует таблицу следующим образом:

Однако, как я упоминал раннее, в редакторах Яндекса сохранена возможность переключиться на редакторы Р7 офис. Для этого достаточно зайти в настройки Яндекс 360 и в строке «Перейти на новый редактор» сдвинуть бегунок влево, сделав его серым.

Тогда моя тестовая табличка откроется уже в редакторе Р7 офис в изначально задуманном виде.

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

Немного спорта: кто и как ведёт себя на больших файлах

Пара слов о скорости работы. Для теста я взял файл с текстом романа «Война и мир» — 1918 страниц. Ничего особенно экзотического в этом документе не было: текст, таблицы, несколько чёрно-белых иллюстраций. Но объём, мягко говоря, не маленький.

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

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

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

Ещё один тест: как редакторы переживают чужую вёрстку

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

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

Р7 офис показал все элементы, но порядок местами поплыл: например, часть шапки на первой странице съехала относительно ожидаемой позиции.

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

Это важный момент, потому что он хорошо показывает текущую специализацию продуктов. Когда документ простой и создаётся с нуля прямо в редакторе — всё более-менее хорошо. Когда же в редактор попадает уже готовый файл с чужой сложной вёрсткой, вопрос совместимости начинает играть куда большую роль.

И совсем простой табличный тест

После больших файлов и непростого форматирования захотелось проверить что-нибудь совсем базовое. Я взял простую таблицу: в одном столбце арифметическая прогрессия, в другом — такая же, но со смещением, а в третьем — обычный ВПР. Ничего героического, один из тех примеров, на которых обычно проверяют самые базовые табличные сценарии.

Google Docs справился мгновенно. Единственный нюанс — для суммирования диапазон пришлось задать вручную или сначала выделить.

Р7 офис тоже с задачей справился, но работал заметно степеннее: некоторые действия занимали несколько секунд. Это не катастрофа, но ощущается.

Редактор Яндекса тоже сумму в итоге посчитал, хотя сначала озадачил меня другим: по какой-то причине встать на позицию ниже последнего значения в одном из столбцов у меня не получилось, как будто таблица там просто заканчивалась и дальше ничего не существовало.

В итоге считать пришлось в другом месте. Посчиталось — уже хорошо, но осадок, как говорится, остался.

Что по совместной работе?

В Р7 офис доступны режимы комментирования, чтения, редактирования, можно установить пароль и срок действия для внешней ссылки. И есть чат для участников совместного редактирования — чтобы написать коллегам сообщение, даже не нужно выходить из редактора. Такой возможности у редакторов Яндекса, как и у Google, нет.

Яндекс позволяет делиться файлами, редактировать их в реальном времени и настраивать права доступа. Пока роли ограничиваются только двумя вариантами — «только просмотр» и «редактирование». Если у вас есть Яндекс 360, доступны будут некоторые дополнительные настройки безопасности — можно установить пароль, срок действия ссылки и запретить скачивание.

А такие сценарии доступны в Google Docs, всего три и все по делу:

Выводы

У всех трёх решений оказались довольно разные роли.

Google Docs по-прежнему выглядит самым зрелым и предсказуемым веб-редактором из этой троицы. Это тот случай, когда сервис уже давно стал отраслевой нормой: не идеальной во всём, но очень понятной и привычной. Особенно если важна совместная работа, история изменений и в целом проверенный интерфейс.

Р7 офис — вариант для тех, кому нужен более широкий функционал, больше форматов, более серьёзные сценарии совместной работы и в целом ощущение классического офисного приложения, а не только браузерного редактора. Но вместе с этим приходится принимать и его особенности: более тяжёлый интерфейс и не самую быструю работу в ряде сценариев. C ноября прошлого года здесь уже также доступны ИИ-инструменты, но пока только для работы с текстовыми документами, а именно корректуры текста, выделения ключевых мыслей, перевода на различные языки и т.д. Следует отметить, что сравнение ИИ-ассистентов в отечественных офисных решениях заслуживает отдельного материала, так как сказать там точно будет о чем.

Новые редакторы Яндекса выглядят как попытка пойти в другую сторону и предложить более понятный инструмент для повседневной работы. И в этом есть своя логика. Однако на текущий момент это всё ещё сырой продукт, который пригодится для самых базовых сценариев: простой текст, лёгкая таблица, быстрый доступ в браузере. Но как только речь заходит о сложном форматировании, тяжёлых файлах, сводных таблицах или о проверке орфографии с историей изменений, редакторы Яндекса начинают откровенно "спотыкаться". И пока одним из главных конкурентных преимуществ служит интеграция Алисы AI: для части пользователей она может оказаться полезнее, чем редкие офисные функции.

Поэтому ответ на вопрос «что выбрать» здесь не универсальный. Если важны сложные документы, форматы и более богатый офисный функционал — логичнее смотреть в сторону Р7. Если нужны ИИ-инструменты, простота и современный интерфейс — у Яндекса есть вполне понятный сценарий применения. Если нужен проверенный веб-стандарт совместной работы — редакторы от Google всё ещё остаются ориентиром, хотя, будучи российским пользователем, надеяться на безопасность данных или легально оплачивать их уже не получится.

Около семи вечера начали падать транзакции. Не все - примерно 15%. Команда сразу занялась разбором: логи, метрики, трейсы. Стандартный процесс. Проблему нашли и починили за 40 минут. По меркам платёжки - нормально.

Но пока мы разбирались, в поддержку пришло 300 тикетов. Три сотни «что происходит», «у нас не проходят платежи», «когда заработает». Саппорт ничего не знал - он ждал, пока инженеры выплывут из логов. Клиенты ждали саппорт. Всё это время тишина с нашей стороны читалась как безразличие.

Проблему починили за 40 минут. Разгребали тикеты три дня.

Почему молчание хуже, чем «мы знаем о проблеме»

Есть простая психология: человек переносит неопределённость хуже, чем плохие новости. Если транзакция не прошла и нет никакой информации - клиент начинает строить сценарии. Деньги потерялись. Сервис умер. Нас кинули. Он пишет в поддержку. Потом пишет ещё раз. Потом оставляет отзыв.

Если транзакция не прошла, но есть страница

с записью «Повышенное время отклика платёжного шлюза. Investigating. 19:12» - большинство людей закрывают вкладку и ждут. Не все. Но большинство.

Мы это проверили. После того как поставили нормальную страницу статусов, количество тикетов во время инцидентов упало примерно в три раза. Точнее - на 67% по среднему за квартал. Это не магия, это просто информация в нужный момент.

Что мы пробовали до этого

Расскажу честно, через что прошли, потому что это типичный путь.

Шаг первый: Telegram-канал. Завели канал «Статус сервиса». Писали туда когда что-то падало. Работало ровно до тех пор, пока кто-то не забыл написать. А потом написал через два часа когда уже всё починилось. Клиенты не понимали что происходило. Доверие к каналу упало быстро.

Шаг второй: статус в шапке сайта. Зелёный кружок когда всё хорошо. Ручной - кто-то должен был его менять. Понятно куда это ведёт: кружок всегда зелёный, потому что некогда, потому что забыли, потому что «сейчас разбираемся, потом обновим».

Шаг третий: Atlassian Statuspage. Это уже нормальный инструмент. Он решил проблему. Но у него есть два неудобства для русскоязычного рынка: оплата в долларах (что в 2022 стало практической проблемой) и серверы за пределами России (что для ряда клиентов принципиально с точки зрения регулирования).

Как устроен нормальный incident workflow со страницей статусов

Я говорю «нормальный» - имею в виду тот, который не требует героизма от дежурного инженера в 2 ночи.

Всё начинается с мониторинга. HTTP/TCP-проверки каждую минуту на все критичные эндпоинты: API, веб, база, очереди. Когда что-то падает - автоматическое создание инцидента и уведомление команды. Это не новость, большинство так и делают.

Новость в том, что параллельно с уведомлением команды - автоматическое обновление публичной страницы статусов. Не «кто-то должен написать туда», а именно автоматически. Клиент видит «Degraded performance» раньше, чем успевает написать в поддержку.

Дальше инженер работает по стандартному процессу: Investigating - Identified - Monitoring - Resolved. Каждый статус обновляется на странице. Клиенты, подписавшиеся на уведомления, получают апдейты в Telegram или email. Поддержка может в один клик скопировать ссылку на инцидент и отправить клиенту вместо объяснений.

После разрешения - postmortem прямо на странице. Клиенты видят что случилось, почему и что сделано чтобы не повторилось. Это, как ни странно, повышает доверие сильнее, чем если бы инцидента не было совсем.

Что важно при выборе инструмента

Несколько технических вещей, на которые стоит обратить внимание.

Uptime самой страницы статусов. Она должна быть на отдельной инфраструктуре. Если ваш основной сервис упал и страница статусов на той же инфраструктуре - вы получили идеальный шторм: сервис не работает и статус показать невозможно.

Собственный домен.

вместо

. Это доверие и брендинг.

Telegram-уведомления. Для российской аудитории это важнее email. Люди читают Telegram, а не почту, когда ищут статус сервиса в панике.

Локализация данных. Если работаете с персональными данными российских пользователей - вопрос где физически хранятся данные о ваших инцидентах становится юридическим, а не техническим.

Мы в Flaree делаем страницу статусов именно для таких случаев - серверы в России, Telegram из коробки, оплата в рублях. Сейчас открыт ранний доступ, первые 50 команд получают 3 месяца Pro бесплатно: flaree.ru

Что в итоге

Страница статусов - это не инструмент для больших команд. Это инструмент для любого сервиса, у которого есть клиенты и бывают инциденты. То есть для всех.

Настройка занимает 15 минут. Первый же инцидент, который клиенты узнают из статусной страницы раньше, чем напишут в поддержку - окупает это время с запасом.

P.S. Если у вас уже есть страница статусов - напишите в комментариях какой инструмент используете. Интересно что прижилось у разных команд.

Но реальность 2026 года диктует свои условия. Использовать Jira через серые схемы оплаты, без официальной поддержки и с риском блокировки облака — это игра в русскую рулетку, в которую крупный бизнес играть не готов.

Хорошая новость заключается в том, что российский рынок систем управления разработкой совершил качественный скачок. Если несколько лет назад российский аналог Jira часто представлял собой базовую канбан-доску, то сегодня заказчикам доступны зрелые платформы. Современные решения способны справляться с Enterprise-нагрузками, поддерживать масштабируемые фреймворки (такие как SAFe или LeSS) и оркестрировать сложные процессы CI/CD.

В этой статье мы проведем объективный обзор топовых аналогов Jira, представленных на российском рынке. Мы сравним их функциональные возможности, удобство миграции, ценовую политику и поможем определить, какая замена Jira оптимально подойдет под задачи вашей команды

Почему команды ищут замену Jira в 2026 году

Помимо очевидных ограничений, связанных с доступом к сервисам Atlassian из России, существуют и глубокие архитектурные причины, побуждающие ИТ-директоров рассматривать альтернативные решения:

1. Перегруженность системы. Инструмент, созданный 20 лет назад как баг-трекер, оброс таким количеством плагинов и настроек, что для управления им нужен отдельный штат администраторов.
2. Зависимость от плагинов (Франкенштейн-архитектура). Чтобы настроить нормальный учет времени (Tempo), диаграммы Ганта (Structure) или управление тестовыми сценариями (Zephyr), нужны сторонние плагины. Они стоят денег, часто конфликтуют друг с другом после обновлений и не всегда дружат между собой.
3. Слабый фокус на продуктовый подход. В Jira вы живете в парадигме «Проектов». Если над одним большим продуктом работает 10 команд, вам придется городить сложную иерархию проектов и эпиков, чтобы просто понять, кто что делает.
4. Требования информационной безопасности. Для государственного сектора, финансовой отрасли и промышленных предприятий критически важно размещать данные внутри собственного защищенного контура (On-premise) и использовать программное обеспечение из Реестра отечественного ПО.

Таким образом, альтернативы Jira сегодня выбирают не только из соображений импортонезависимости, но и ради получения более современного пользовательского опыта (UX), монолитной архитектуры без избытка плагинов и наличия необходимого функционала «из коробки».

Топ-10 аналогов Jira для российского рынка

Рассмотрим десять наиболее заметных решений на рынке, чтобы понять их позиционирование и целевую аудиторию.

1. SimpleOne SDLC

SimpleOne SDLC — это аналог Jira для команд разработки. Комплексная Enterprise-платформа для управления всем жизненным циклом разработки ПО (Software Development Life Cycle), а не просто трекер задач. Решение изначально спроектировано под потребности крупного бизнеса и продуктовой разработки. В основе архитектуры платформы лежит «Продукт», что позволяет эффективно выстраивать работу множества команд.

Для кого: средний и крупный бизнес, корпорации, банки, финтех, а также компании, внедряющие масштабируемые Agile-фреймворки (например, SAFe).

Соответствие Jira

• Полная поддержка продуктовой иерархии: Портфель -> Продукт -> Модуль -> Эпик -> Фича -> История -> Дефект/Задача;
• Нативные Agile-инструменты (Scrum, Kanban), управление спринтами и бэклогом;
• Возможность настройки сложных рабочих процессов (workflow) визуальными средствами;
• Наличие встроенного функционала, который в Jira требует плагинов: учет трудозатрат, ресурсное планирование, готовые дашборды (Burndown, CFD, Velocity).

Миграция из Jira

Отработанный процесс автоматизированного переноса данных. Мигрируют пользователи, статусы, проекты, задачи с сохранением истории изменений, комментарии и вложенные файлы. Возможна бесшовная миграция с Jira на On-premise серверы заказчика.

Плюсы

• Low-code платформа: в отличие от жесткой архитектуры классических трекеров, в SimpleOne бизнес-аналитики могут изменять логику, формы и интерфейсы с помощью визуальных конструкторов;
• Глубокая интеграция с ITSM: процессы разработки и технической поддержки (Service Desk) функционируют в единой среде. Инцидент, зарегистрированный в поддержке, конвертируется в задачу для разработчиков в один клик;
• Продуктовый подход: структура платформы оптимальна для управления сложными продуктами, над которыми работают десятки кросс-функциональных команд;
• Соответствие требованиям РФ: включено в реестр отечественного ПО.

Минусы

• Избыточный функционал и высокий порог входа для небольших стартапов (до 15 человек);
• Для получения максимальной отдачи от системы требуется определенный уровень зрелости процессов разработки в компании.

Тарифы

Стоимость рассчитывается индивидуально в зависимости от масштаба внедрения (Enterprise-модель лицензирования, On-premise или SaaS).

2. Kaiten

Один из ведущих российских визуальных трекеров задач. Kaiten делает ставку на обеспечение максимальной прозрачности процессов с помощью продвинутых Канбан-досок и системы рабочих пространств.

Для кого: Agile-команды, продуктовые студии, ИТ-компании среднего размера, маркетинговые подразделения.

Соответствие Jira

• Полноценная поддержка Scrum (спринты, бэклог, оценка в Story Points) и Kanban (WIP-лимиты, классы обслуживания);
• Иерархия задач реализуется через гибкие связи между карточками (эпики, истории);
• Встроенный модуль работы с документами (альтернатива Confluence).

Миграция из Jira

Реализован автоматизированный импорт данных из Jira, включая задачи, комментарии и структуру досок.

Плюсы

• Уникальная система пространств: на один экран можно вывести доски нескольких смежных команд, что идеально для выявления узких мест в общем потоке создания ценности;
• Современный UX/UI: интуитивно понятный и «легкий» интерфейс, в котором приятно работать;
• Быстрый старт: минимальное время на обучение сотрудников, команда может начать работу в первый же день;
• Импортонезависимость: система включена в реестр ПО РФ.

Минусы

• Ограниченные возможности для построения сложной, нестандартной бизнес-логики (workflow) по сравнению с Enterprise-платформами;
• Отсутствие глубокого функционала для финансового и ресурсного управления сложными портфелями проектов.

Тарифы

От 185 руб./пользователь/мес (до 15 пользователей). Тариф стандарт (до 250 пользователей) — 430 руб./пользователь/мес. Доступен бесплатный тариф с базовыми функциями и On-premise версия для корпоративных заказчиков.

3. YouGile

YouGile — это инновационный гибрид классического таск-трекера и корпоративного мессенджера. Философия системы строится на том, что все рабочие коммуникации должны происходить строго в контексте конкретной задачи.

Для кого: небольшие и средние ИТ-команды, digital-агентства, студии веб-разработки, где критически важна скорость коммуникации.

Соответствие Jira

• Базовый функционал представлен Agile-досками (колонки и стикеры);
• Присутствуют инструменты учета времени, контроля дедлайнов и базовой отчетности;
• Отсутствует строгая иерархия эпиков и продвинутое управление спринтами «из коробки» (реализуется преимущественно через систему тегов).

Миграция из Jira

Доступен базовый импорт (задачи, исполнители), однако перенос сложной структуры и кастомных полей потребует ручной настройки.

Плюсы:

• Контекстное общение: полноценный чат внутри каждой задачи — эффективное решение проблемы потери информации в разрозненных мессенджерах;
• Максимальная простота: интерфейс не перегружен лишними функциями, что способствует быстрому внедрению;
• Бесплатный старт: полноценное бесплатное использование для микро-команд численностью до 10 человек.

Минусы

• Не подходит для управления сложной продуктовой разработкой (отсутствуют модули управления релизами, CI/CD интеграции, учет технического долга);
• Слабые возможности для автоматизации бизнес-процессов.

Тарифы

Облачная версия — бесплатно до 10 пользователей, далее от 594 руб./мес за пользователя. Доступна коробочная версия (On-premise).

4. ПланФикс

Гибкая платформа-конструктор для настройки рабочих процессов. ПланФикс позволяет бизнес-пользователям самостоятельно смоделировать необходимую среду: от простой CRM до аналога сложного ИТ-трекера.

Для кого: команды и компании любого масштаба, располагающие ресурсами бизнес-аналитиков, готовых инвестировать время в детальную настройку системы под уникальные процессы.

Соответствие Jira

• Изначально система не специализируется на разработке ПО, но ее гибкость позволяет настроить Scrum-доски, спринты и бэклоги;
• Поддержка любых кастомных полей, статусов и сложных сценариев автоматизации;
• Наличие учета времени и диаграмм Ганта.

Миграция из Jira

Реализуется через импорт CSV-файлов или настройку интеграции через открытый API. Готового автоматизированного коннектора для миграции не предусмотрено.

Плюсы

• Исключительная гибкость: платформа-конструктор позволяет настроить автоматизацию любой сложности без использования программного кода;
• Единое цифровое пространство: возможность органично объединить управление разработкой, CRM и Service Desk в одном интерфейсе;
• Экономичность: конкурентоспособная и прозрачная ценовая политика.

Минусы

• Высокий порог входа: система представляет собой «чистый лист», требующий вдумчивого проектирования и длительной настройки;
• Интерфейс может восприниматься как перегруженный;
• Отсутствие готовых нативных интеграций с репозиториями кода (требуется настройка через webhook).

Тарифы

Поставляется по модели SaaS. Стоимость от 366 руб./пользователь/мес (при годовой оплате). Доступна бесплатная версия для микро-команд (до 5 человек).

5. TeamStorm

TeamStorm — это российская система управления разработкой, позиционируемая как наиболее близкая по логике работы и интерфейсу замена Jira.

Для кого: ИТ-подразделения и команды разработки, ищущие прямую альтернативу продуктам Atlassian с минимальным периодом адаптации сотрудников.

Соответствие Jira

• Поддержка классической иерархии: Эпик, История, Задача, Дефект, Подзадача;
• Организация рабочего пространства через «Пространства» и «Папки»;
• Управление спринтами, бэклогами, поддержка оценки задач в Story Points;
• Встроенный модуль базы знаний (аналог Confluence).

Миграция из Jira

Вендор предоставляет специализированные инструменты для бесшовного переноса данных из Jira.

Плюсы

• Привычный пользовательский опыт (UX): интерфейс и логика работы максимально приближены к связке Jira + Notion, что снижает затраты на переобучение ИТ-команд;
• Производительность: высокая скорость отклика интерфейса даже при работе с большими массивами данных;
• Безопасность: наличие в реестре отечественного ПО и возможность установки в закрытый контур.

Минусы

• Экосистема готовых интеграций со сторонними DevOps-сервисами пока уступает зарубежным аналогам;
• Ограниченный функционал для управления портфелями проектов на уровне Enterprise.

Тарифы

Облачная (SaaS) и On-premise версии. Стоимость от 500 руб./пользователь/мес.

6. Comindware

Comindware — это платформа для управления бизнес-процессами (BPMS) на базе Low-code архитектуры. Предназначена для комплексной цифровой трансформации крупных предприятий.

Для кого: средний и крупный бизнес (Enterprise), где процессы разработки ПО необходимо интегрировать с другими сложными корпоративными процедурами (закупки, документооборот, согласования).

Соответствие Jira

• Возможность настройки трекинга задач любой степени сложности;
• Гибкое управление маршрутами (workflow) и использование графовой базы данных для построения сложных связей между объектами;
• Управление неструктурированными процессами (Case Management).

Миграция из Jira

Осуществляется через API или путем импорта/экспорта данных в рамках комплексного проекта внедрения.

Плюсы

• Максимальная адаптивность (Low-code): бизнес-процессы можно модифицировать и перестраивать прямо «на лету» без остановки работы системы и кодинга;
• Масштаб автоматизации: возможность построения единой платформы для оцифровки процессов всей компании, а не только ИТ-отдела;
• Корпоративная безопасность: полноценное развертывание на серверах заказчика (On-premise).

Минусы

• Не является специализированным трекером для ИТ-команд (отсутствуют нативные интеграции с CI/CD);
• Интерфейс требует адаптации пользователей;
• Внедрение представляет собой масштабный ИТ-проект, требующий участия квалифицированных аналитиков.

Тарифы

Лицензирование по количеству пользователей, расчет стоимости владения (TCO) предоставляется по запросу.

7. Битрикс24 (Scrum/Задачи)

Битрикс 24 — это популярный корпоративный портал, объединяющий инструменты коммуникации, CRM и модуль управления задачами с поддержкой методологии Scrum.

Для кого: малый и средний бизнес, а также ИТ-подразделения внутри не-ИТ компаний, где приоритетом является работа в единой среде с отделами продаж и маркетинга.

Соответствие Jira

• Наличие инструмента «Скрам»: бэклог, управление спринтами, оценка в Story Points, эпики, диаграмма сгорания задач;
• Поддержка Канбан-досок, диаграмм Ганта, учета времени;
• Инструменты автоматизации (роботы) для изменения статусов задач.

Миграция из Jira

Реализуется с помощью специализированных приложений из встроенного маркетплейса.

Плюсы

• Комплексный подход (Всё-в-одном): чаты, видеозвонки, задачи, документы, календарь и CRM доступны в едином, привычном интерфейсе;
• Доступность и поддержка: систему можно развернуть за один день, а на рынке присутствует широкая сеть партнеров-интеграторов для любой доработки;
• Гибкое ценообразование: оптимальное соотношение цены и функциональности, особенно для небольших команд.

Минусы

• Модуль Scrum не обладает достаточной глубиной для сложной Enterprise-разработки (управление релизами, техническим долгом, глубокая интеграция с репозиториями);
• Многообразие не-ИТ функций портала может перегружать интерфейс для профильных разработчиков.

Тарифы

Гибкая линейка: от бесплатных облачных тарифов до коробочных версий (On-premise) для корпоративного сектора. Стандартный облачный тариф (до 50 пользователей) — 4893 руб./мес за всех пользователей.

8. WEEEK

WEEEK — это современная мультисервисная платформа для командной работы. Сочетает в себе функционал таск-трекера, базы знаний и CRM-системы.

Для кого: продуктовые команды, стартапы, маркетинговые агентства, отдающие предпочтение современному дизайну и удобству использования (в стиле Notion).

Соответствие Jira

• Управление задачами в форматах списков, Канбан-досок и календаря;
• Встроенная база знаний для ведения документации;
• Отсутствует поддержка сложных JQL-запросов и многоуровневых кастомных workflow.

Миграция из Jira

Возможна загрузка данных через файлы, однако готового коннектора для автоматического переноса всех связей между задачами нет.

Плюсы

• Эстетика и современный UX/UI: продуманный дизайн, в котором командам действительно приятно и комфортно работать ежедневно;
• Универсальность: платформа успешно заменяет сразу несколько узкоспециализированных сервисов (например, связку Trello + Notion + простую CRM);
• Доступность: наличие полнофункционального бесплатного тарифа для микро-команд.

Минусы

• Не ориентирован на сложную инженерную разработку (отсутствуют глубокие аналитические отчеты по релизам и интеграции с Git);
• Функционал находится в стадии активного развития.

Тарифы

Облачная версия от 199 ₽/мес за пользователя. Доступна бесплатная версия для команд до 5 человек.

9. Directum Projects

Directum Projects — это корпоративная система управления проектами, исторически развившаяся из мощной платформы электронного документооборота (СЭД).

Для кого: крупный бизнес, государственный сектор и промышленные предприятия, где проектное управление тесно связано с формализованным документооборотом и строгими регламентами.

Соответствие Jira

• Поддерживает визуализацию на Agile-досках (Scrum/Kanban);
• Основной упор сделан на классическое каскадное управление (Waterfall), мощные диаграммы Ганта, ресурсное планирование и работу с проектной документацией.

Миграция из Jira

Выполняется проектной командой в рамках внедрения системы.

Плюсы

• Синергия с документооборотом: глубокая, нативная интеграция с системами электронного документооборота (СЭД Directum);
• Управление по PMBOK: профессиональный инструмент для проектных офисов (PMO), обеспечивающий контроль сроков, вех и бюджетов.

Минусы

• «Корпоративный» интерфейс может потребовать адаптации со стороны Agile-команд разработчиков;
• Система менее сфокусирована на специфике гибкой продуктовой разработки ПО.

Тарифы

Преимущественно On-premise поставки. Корпоративное лицензирование (ориентировочно от 7400 ₽ за пользователя в год).

10. Мегаплан

Мегаплан — это широко известная на российском рынке CRM-система, оснащенная развитым модулем управления задачами и поручениями.

Для кого: малый и средний бизнес, ищущий надежную систему для контроля исполнительской дисциплины и ведения клиентской базы в едином контуре.

Соответствие Jira

• Иерархия: задачи, подзадачи, чек-листы;
• Диаграммы Ганта для визуального планирования сроков;
• Инструменты учета рабочего времени и планирования загрузки сотрудников;
• Отсутствует специализированный ИТ-инструментарий (спринты, эпики, интеграции с репозиториями кода).

Миграция из Jira

Доступен базовый перенос данных через экспорт/импорт CSV-файлов.

Плюсы

• Стабильность и простота: легкость внедрения, простота освоения пользователями и высокая стабильность работы;
• Связка процессов: возможность в одном окне интегрировать процессное управление с продажами (CRM) и финансами;
• Мобильность: качественное и полнофункциональное мобильное приложение.

Минусы

• Не является профильным инструментом для разработчиков ПО; не подходит в качестве полноценной замены Jira для ИТ-подразделений;
• Сложности при масштабировании на крупные кросс-функциональные ИТ-проекты.

Тарифы

Доступны облачная (SaaS) и коробочная версии. Базовый тариф — 315 руб./мес за пользователя при покупке на год. Расширенный тариф (с бо́льшим функционалом) — 630 руб./мес за пользователя.

Сравнительная таблица: Jira vs российские аналоги

Мы свели ключевые функции для ИТ-разработки в единую таблицу. Вместо простых галочек «есть/нет», мы описали уровень реализации каждой функции, чтобы вы могли наглядно оценить, какие аналоги Jira лучше всего закроют ваши потребности.

Таблица наглядно демонстрирует: для гибких Agile-команд отлично подходят легкие решения вроде Kaiten, но если вам нужна полноценная замена Jira для Enterprise-разработки с жесткими воркфлоу, глубокой интеграцией с кодом и продуктовой иерархией, ближе всего к оригиналу стоят специализированные системы — SimpleOne SDLC и TeamStorm.

Балльная оценка готовности систем заменить Jira (для ИТ-разработки)

Чтобы дать вам быстрый срез, мы оценили системы по 10-балльной шкале именно в контексте разработки программного обеспечения и близости к методологии Jira.

Примечание: Низкий балл не означает, что система плохая. Он лишь показывает, что решение (например, YouGile, WEEEK или Мегаплан) сфокусировано на других задачах (коммуникация, продажи, универсальный трекинг) и не является прямым аналогом Jira для хардкорной инженерной разработки и управления релизами.

Критерии выбора аналога Jira в 2026 году

Выбор системы трекинга задач — стратегическое решение. Ошибка на этом этапе приведет к необходимости перестраивать процессы управления в будущем. При оценке решений рекомендуем обращать внимание на следующие аспекты:

1. Масштаб и поддерживаемая методология. Для небольших команд (до 10-15 человек), работающих над внутренними проектами, оптимально подойдут легкие решения вроде Kaiten или YouGile. Для крупных ИТ-департаментов (от 100 разработчиков), создающих сложные продукты и применяющих фреймворки масштабирования (SAFe), необходимы платформы Enterprise-уровня (например, SimpleOne SDLC), поддерживающие сложную продуктовую иерархию «из коробки».
2. Глубина кастомизации процессов. Если ваши процессы требуют сложной логики переходов статусов (например, задача переходит в тестирование только после согласования техлидом и заполнения обязательных полей), выбирайте платформы на базе Low-code, позволяющие настраивать workflow без программирования.
3. Интеграция с процессом разработки. Полноценный аналог Jira должен бесшовно интегрироваться с вашими репозиториями (GitLab, GitHub). Автоматическая смена статусов задач на основе коммитов существенно повышает прозрачность разработки.
4. Безопасность и варианты развертывания. Для компаний финансового сектора и организаций с государственным участием обязательным требованием является наличие On-premise версии и включение продукта в Реестр отечественного ПО.

Как мигрировать с Jira на российский аналог: пошаговый план

Процесс миграции с Jira требует тщательного планирования. Рекомендуем придерживаться следующего алгоритма:

Шаг 1: Аудит текущей конфигурации Jira.

Проанализируйте используемый функционал. Выявите устаревшие кастомные поля, неиспользуемые статусы и отключенные плагины, чтобы не переносить накопленный «технический мусор» в новую систему.

Шаг 2: Маппинг сущностей.

Составьте таблицу соответствия терминологии. Например, тип задачи Issue Type «Bug» в Jira должен соответствовать типу «Дефект» в новой системе.

Шаг 3: Тестовый перенос (Пилотный запуск).

Выберите один репрезентативный проект и осуществите его перенос в новую систему (используя встроенные инструменты импорта или API). Проверьте корректность переноса вложений, комментариев, авторов задач и связей между ними (например, blocks/depends on).

Шаг 4: Настройка ролей и бизнес-логики.

Воспроизведите утвержденные маршруты движения задач (workflow) и настройте ролевую модель доступа в выбранной платформе.

Шаг 5: Обучение проектных команд.

Проведите установочные сессии для разработчиков и менеджеров продуктов, продемонстрировав принципы работы с бэклогом и создания дефектов в новом интерфейсе. Подготовьте краткие памятки (Cheatsheets).

Шаг 6: Финальная миграция и заморозка Jira.

Переведите Jira в режим «только чтение» (Read-only) перед выходными. За выходные выгрузите «дельту» (изменения, произошедшие с момента тестового переноса) и импортируйте ее в новую систему. В понедельник утром команда начинает работать в новом трекере.

Чек-лист: 10 вопросов перед заменой Jira

Перед тем как подписать договор с новым вендором, задайте эти вопросы себе и интегратору:

1. Какие функции и плагины Jira мы используем реально, а какие были установлены «на всякий случай»?
2. Обладает ли предлагаемый аналог готовым инструментом (скриптом или коннектором) для импорта данных из Jira (пользователи, история статусов, вложения)?
3. Насколько прозрачна модель ценообразования: оплата взимается за пользователей, проекты или отдельные модули? Предусмотрены ли скрытые платежи?
4. Способна ли новая система обрабатывать наши объемы данных (десятки тысяч задач) без деградации производительности?
5. Включает ли стоимость лицензии базовую техническую поддержку и помощь в процессе миграции?
6. Сможем ли мы беспрепятственно экспортировать свои данные (например, в форматах CSV/JSON) при необходимости смены системы в будущем?
7. Имеет ли вендор подтвержденные кейсы миграции с Jira в компаниях сопоставимого с нами масштаба?
8. Поддерживает ли система «из коробки» нативные интеграции с нашим ИТ-стеком (Git, системы CI/CD, корпоративные мессенджеры)?
9. Соответствует ли архитектура решения требованиям безопасности (ФЗ-152, Реестр Минцифры, возможность On-premise)?
10. Каков реалистичный срок внедрения системы «под ключ» для команды нашего размера?

Заключение

Поиск ответа на вопрос «чем заменить Jira» в 2026 году — это не проблема дефицита, это проблема выбора. Российский рынок предлагает отличные альтернативы, которые давно переросли стадию «импортозамещения ради галочки».

Если вам нужен просто наглядный и быстрый инструмент для Agile-команды, смело смотрите в сторону Kaiten. Если ваша разработка тесно завязана на другие бизнес-процессы компании — вам помогут ПланФикс или ELMA365.

Но если вы крупная продуктовая компания, где сотни разработчиков пишут код, а ИТ-директору нужна прозрачная связь между техдолгом, релизами и инцидентами из техподдержки — вам нужны Enterprise-решения. Платформы вроде SimpleOne SDLC предлагают не просто трекер, а архитектуру, изначально заточенную под масштаб, продуктовый подход и гибкость Low-code настройки, что делает их, пожалуй, наиболее полноценной заменой Jira для серьезного бизнеса на сегодняшний день.

FAQ

Какие российские аналоги полностью заменяют Jira?

Полностью (со всеми тысячами плагинов) скопировать Jira невозможно и не нужно. Но по покрытию базового и продвинутого функционала для разработки (Scrum, Kanban, бэклог, релизы, Git) лучшими российскими аналогами Jira считаются SimpleOne SDLC, TeamStorm и Kaiten.

Сложно ли перенести данные из Jira в российский аналог?

Большинство зрелых российских трекеров уже разработали встроенные утилиты или API-скрипты для миграции. Перенос базовых задач (названия, описания, статусы) обычно проходит гладко. Сложности могут возникнуть при миграции специфических кастомных полей, скриптов автоматизации (ScriptRunner) и данных из редких плагинов.

Сколько стоит переход с Jira на российский аналог?

Совокупная стоимость складывается из двух составляющих: стоимости лицензий на новое ПО (от 400-500 руб/мес за пользователя в облачных версиях до миллионов рублей за Enterprise On-premise решения) и стоимости самого проекта миграции (услуги бизнес-аналитиков и системных интеграторов по настройке процессов и переносу данных).

Какой аналог Jira лучше для скрам-команд?

Для небольших скрам-команд (до 30 человек), которым нужна максимальная визуализация досок и быстрый старт, отлично подойдет Kaiten или YouGile. Для крупных кросс-функциональных скрам-команд в Enterprise-сегменте, работающих над сложными продуктами (например, по SAFe), более мощной альтернативой станет SimpleOne SDLC, так как он поддерживает сложную продуктовую иерархию и связку с ITSM.

Сколько времени занимает миграция с Jira на российский аналог?

Для небольшой команды (до 50 человек) с простыми процессами переезд можно осуществить за 1-2 недели. Для корпорации (500+ пользователей), где нужно перенести сложные воркфлоу, обучить сотрудников и провести интеграции с внутренними системами, проект миграции может занять от 2 до 6 месяцев.

Есть ли альтернативы Jira с хорошими AI-функциями?

Да, российские вендоры активно внедряют ИИ. Искусственный интеллект в современных аналогах (например, на платформе SimpleOne) умеет классифицировать новые задачи, подсказывать операторам решения на основе базы знаний (RAG) и помогать в создании кратких резюме по длинным обсуждениям в тикетах.

Реклама. Рекламодатель: ООО «СИМПЛ 1», ИНН 9725013892, erid: 2W5zFFxmVEH

77% сотрудников, использующих ИИ, говорят: работы стало больше, а не меньше. 71% — выгорание. Upwork Research Institute.

88% burnout rate у «самых продуктивных» ИИ-юзеров. Они в 2 раза чаще увольняются. Те, кто лучше всех выглядит на дашборде, — ближе всех к двери.

Осознанная аналитическая мысль работает на ~10 бит/с (Zheng & Meister, Neuron 2025). ИИ увеличил очередь на ревью на 98%. Биологический потолок никуда не делся.

Только 22% сеньоров уверены в ИИ-коде, который выкатывают (Qodo). 59% разработчиков в целом коммитят код, который не понимают полностью (Clutch, 800 профи).

Выгорание повышает риск сердечно-сосудистых заболеваний на 21%. Верхний квинтиль — +79% к риску ишемической болезни. Метаанализ на 26 916 участников, 2024.

Денис Стецков — инженерный лид, ведёт блог techtrenches.dev. Статья «The Human Cost of 10x: How AI Is Physically Breaking Senior Engineers» за пару дней набрала на Hacker News оживлённое обсуждение — сеньоры узнают себя в описании и добавляют своих деталей. Автор собирает под один тезис данные из UC Berkeley, Upwork, Neuron, GitHub Octoverse, Faros AI, METR, Qodo, GitClear и старой работы Bainbridge «Ironies of Automation» 1983 года. Получается не манифест против ИИ, а попытка честно посчитать арифметику.

Workload creep: ИИ не сокращает работу, он её интенсифицирует

Workload creep — это когда объём и границы работы ползут вверх без официального пересмотра планов и ожиданий. В феврале 2026 UC Berkeley опубликовали результаты восьмимесячного полевого исследования в 200-человечной tech-компании — 40+ глубинных интервью. Вывод, ради которого стоит прочитать оригинал: ИИ не уменьшает объём работы, он его интенсифицирует через три механизма.

• Task expansion: у каждого расширяется скоуп, потому что ИИ делает возможным «ещё вот это». Раньше вы делали три задачи — теперь формально можете пять, и вам их молча накидывают.
• Blurred boundaries: ИИ-промптинг просачивается в обед, дорогу домой, вечер — «ну это же не работа, я просто спросил у Claude». В итоге 14 часов думающего времени в сутки вместо 8.
• Implicit pressure: когда коллеги на глазах делают больше с ИИ, ожидания поднимаются для всех. Даже если ваши — не поднялись, то в голове они поднялись уже.

Upwork Research Institute (опрос апреля-мая 2024) квантифицировал: 77% сотрудников, использующих ИИ, говорят, что инструменты либо снизили их продуктивность, либо добавили нагрузку — минимум по одному из пунктов. 71% рапортуют выгорание. А теперь главная находка, ради которой стоит не закрывать вкладку: рабочие с самыми высокими показателями ИИ-продуктивности выгорают сильнее всех. 88% burnout rate у «самых продуктивных». Они в два раза чаще увольняются. Тот, кто лучше всех выглядит на вашем дашборде, — ближе всех к тому, чтобы уйти.

Честный контраргумент, который в оригинале не разобран: возможно, люди, которые берутся за всё подряд, выгорают в любой среде — ИИ просто дал им больше «всего». Статистика корреляционная, не причинно-следственная. Но даже в этой версии вывод остаётся: система, которая поощряет «делать больше» без оглядки на человека, получает выгоревших сильнее всего.

Мозг обрабатывает 10 бит в секунду. Это биология, а не характер

В декабре 2024 года Чжэн и Майстер опубликовали в Neuron работу с неприятным для индустрии выводом. Сенсорные системы собирают данные на скорости около миллиарда бит в секунду. А вот осознанная аналитическая мысль — та самая, которой вы делаете code review — работает на скорости примерно 10 бит в секунду. Рабочая память при этом удерживает около 4 чанков информации одновременно.

Поверх этого — классическое исследование SmartBear и Cisco (Best Kept Secrets of Peer Code Review): эффективность обнаружения дефектов резко падает, когда скорость ревью превышает ~500 строк в час, и качество заметно проседает после первого часа непрерывной работы. Это не про «собраться и потерпеть» — это про то, что после часа когнитивная точность мозга физически падает.

Теперь посмотрите, что ИИ сделал с очередью на ревью. GitHub Octoverse 2025 показывает 43,2 млн смердженных PR в месяц — рост 23% год к году. Faros AI проанализировала 10 000+ разработчиков и зафиксировала главное: с ИИ-помощью мерджат на 98% больше PR. PR review time +91%, размер PR +154%. И каждый из этих PR ложится на стол сеньору.

Джуниоры генерят гораздо больше кода с ИИ-инструментами, но сам объём насыщает пропускную способность сеньоров по ревью.

В марте 2026 мейнтейнер OCaml отклонил 13 000-строчный ИИ-сгенерированный PR целиком — у команды не было пропускной способности его разбирать. И это уже не отдельные истории, это статистика. Ранее METR показала, что опытные разработчики с ИИ-инструментами на самом деле работают медленнее, хотя чувствуют себя быстрее. Зазор между ощущением и реальностью — самый опасный вывод из всей этой серии исследований: вы не можете починить то, чего не чувствуете.

Почему экспертность делает только хуже

В 1983 году Лизанн Бэйнбридж опубликовала в Automatica эссе «Ironies of Automation». Основной тезис: чем более сложной становится автоматизация, тем более требовательной становится остающаяся человеческая роль. После автоматизации в работе человека остаётся самое неоднозначное, самое сложное, хуже всего инструментируемое. Microsoft Research в 2024 подтвердила это для генеративного ИИ: ИИ-системы могут делать сложные задачи ещё сложнее, оставляя пользователю ту же или бо́льшую когнитивную нагрузку.

Механизм асимметричный. Когда вы пишете код сами, вы выгружаете уже существующую в голове модель. Мышление уже сделано до того, как пальцы коснулись клавиатуры. Когда вы ревьюите ИИ-код, вам нужно реконструировать чужой ход рассуждений по артефакту, произведённому системой, которая не имеет понятия о вашем бизнесе. Это фундаментально более тяжёлая операция.

Clutch опросили 800 разработчиков: 59% используют ИИ-код, который не понимают полностью. Для джунов это ещё допустимо, для сеньоров — нет. Их работа — ловить то, что выглядит правильным, но не является. Отчёт Qodo даёт распределение по стажу: уверенность в ИИ-коде у сеньоров — всего 22%. Боль с контекстом: 41% у джунов против 52% у сеньоров. То, что все остальные сгружают в «когнитивный оффлоадинг», сеньор обязан не сгружать — это его работа. Он впитывает всю ту когнитивную цену, которую сняли с себя все остальные.

Тело записывает всё

Когнитивный ущерб — это половина истории. Вторую половину собирает тело. Computer Vision Syndrome — синдром компьютерного зрения (на tproger.ru про это есть отдельный разбор — про туннельный синдром, близорукость и выгорание у айтишников) — затрагивает 74% пользователей экранов в периоды увеличенной нагрузки, и тяжесть цифрового напряжения глаз сильно растёт вместе с ростом когнитивной нагрузки. ИИ-интенсифицированное ревью — это не просто «больше часов перед экраном»: каждый час становится физически более разрушительным, потому что вы не просто смотрите в монитор, а упираетесь в него со всей остротой внимания.

Метаанализ 2024 года на 26 916 участников: выгорание повышает риск сердечно-сосудистых заболеваний в среднем на 21%. Отдельное проспективное исследование Toker et al. 2012 (8838 участников, Psychosomatic Medicine) показало для верхнего квинтиля по выгоранию +79% к риску ишемической болезни сердца. Крупнейшее IT-исследование: метаболический синдром у 32% долго сидящих программистов — вдвое больше, чем в общей популяции.

Плюс сон. Пережёвывание рабочих задач после работы напрямую ломает качество сна. Когда вы закрываете ноутбук, мозг не выключается — он проигрывает PR, который вы не досмотрели, зависимость, которую флагнули, но не успели отследить. Больше ревью днём → хуже сон ночью → хуже решения утром → больше rubber-stamped PR → больше багов в проде → больше стресса. Цикл замыкается. Ломается — обычно человек.

Дашборд лжёт

GitClear (компания-вендор инструментов для анализа качества кода — к выводам стоит относиться с оглядкой на конфликт интересов) проанализировала 211 миллионов изменённых строк и показала неприятный тренд. Code churn за период массового внедрения ИИ-ассистентов вырос с ~3% до ~7–8%. Дублированный код в статистике вырос в несколько раз. Агрегированные цифры по росту багов и логических дефектов Стецков приводит со ссылкой на GitClear — но сам отчёт GitClear закрыт за формой лидогена, независимо верифицировать их нельзя.

Faros AI на тех же 10 000+ разработчиках: несмотря на +98% смердженных PR с ИИ, компании целиком не показали никакого измеримого улучшения ни по throughput, ни по качеству. То есть индивидуально PR больше, а на уровне компании — ничего не изменилось, кроме количества людей с burnout.

CEO компании Sonar (той самой, что делает SonarQube) писал про скрытую опасность точно: ИИ-модели всё лучше избегают очевидных багов и простых security-дыр, но структурные дефекты сейчас составляют больше 90% всех проблем. Вы засыпаете в ложном чувстве безопасности: простые проблемы решены, а сложные прячутся под чистым на вид кодом, который проходит все автоматические проверки. А люди, которые умеют их находить, закопаны под потоком, превышающим их когнитивную пропускную способность by design.

Что делать прямо сейчас, если узнали себя

Три практических шага, которые не требуют согласования с руководством и которые можно начать делать с завтра.

1. Поставьте верхний лимит на количество PR в день — 3–5, в зависимости от их размера. И держите его жёстко. Лучше пусть PR полежит в очереди день, чем вы отревьюите его в режиме rubber stamp в 19:00 с пустой головой.
2. Явно разделите время на «генеративное» и «review-only». Мозг переключается между написанием и ревью дорого: каждый свитч стоит 15–25 минут на возврат в контекст. Лучше два полутора-часовых ревью-окна в день, чем пять размазанных между всем остальным.
3. Считайте часы перед экраном как физическую нагрузку, а не как «ничего же не делаю». Вам нужны паузы, прогулки, нормальный сон и понимание, что 9 часов плотного ревью — это как тренировка на стадионе для того, кто к ней не готовился.

Если вы технический руководитель — проверьте у себя пару уязвимых мест. Технические лиды сами выгорают на ревью так же, как сеньоры, плюс несут отдельный груз ответа за дашборды, которые не показывают выгорание команды. Второе: у вас есть политика на максимальный размер PR на ревью? Если нет — это вопрос времени до первого человека, которого придётся выписывать из строя.

Что с этим делать командам

Это перекликается с темой переосмысления code review как процесса обучения, а не только отлова багов. Главная развилка, которую автор формулирует в финале: ИИ увеличил спрос на сеньорскую инженерную экспертизу на 76–98%. Предложение сеньоров — не сдвинулось. Более того, индустрия массово увольняет сеньоров с 2022 года (сотни тысяч), и pipeline, производящий новых, ломается теми же инструментами, что создают спрос. Формула не сходится.

Если вы технический руководитель, из статьи вытекает несколько неудобных вопросов к себе. Сколько времени сеньоры из вашей команды физически тратят на ревью за ИИ — и это измеряется? Дашборд с количеством смердженных PR этого не видит, он видит только throughput. Есть ли у вас политика на максимальный размер PR на ревью и на максимальное количество в день? Без этого «просто больше code review» — это вопрос времени до первого выгоревшего сеньора с диагнозом. Как выглядит разгрузка? Если ответ «увеличим штат» — откуда возьмутся эти сеньоры при текущем рынке, и не те же ли это люди, которых вы только что уволили в прошлой оптимизации?

У ревью-инженера в 2026 году нет версии выбора, где он не отвечает за результат. Доверился ИИ-PR — твоё имя на коммите. Перепроверил всё руками — твой сон и твоё сердце. Индустрия должна это считать.

Если вы сеньор и узнаёте себя — стоит прочитать оригинал целиком: там больше деталей по исследованиям и меньше выводов-обобщений, чем в этом разборе. Автор собирает ответы от читателей для follow-up статьи. Комментарии на HN тоже стоят того: половина треда — это другие сеньоры, рассказывающие свои версии той же истории.

Сегодня компании режут бюджеты, закрывают проекты и ищут способы делать то же самое, но дешевле. В 2026 году это видно и по количеству вакансий, и по тому, как растут зарплаты — или не растут.

Рост есть, но вы его не почувствуете

Зарплаты в IT формально растут — цифры в отчётах положительные. Но рост составляет 5–7% в год, и это примерно совпадает с инфляцией. То есть денег на счёте стало больше, а купить на них можно примерно столько же, сколько год назад.

Раньше всё было проще: пришёл к руководителю, сказал что мониторишь рынок и хочешь повышения — и в большинстве случаев получал его. Потому что нанять нового человека стоило дороже и дольше, чем поднять зарплату текущему. Сейчас этот аргумент не работает.

Если сейчас сотрудник придёт к руководству за повышением и не будет при этом суперзвездой с уникальной эффективностью — его могут просто не услышать. Более того, в некоторых случаях человека могут сократить, чтобы найти кого-то дешевле, хоть и с меньшим опытом.

Это уже происходит, когда опытные разработчики соглашаются на зарплаты ниже рыночных, лишь бы не потерять место.

Поиск работы тоже изменился. Если раньше нормальный оффер находился за две недели, то сейчас этот же процесс занимает 3–4 месяца. Кандидаты стали соглашаться на условия, от которых раньше отказывались: нет ДМС, нет удалёнки — ладно, главное чтобы компания платила вовремя и не закрылась через полгода. Рынок стал рынком работодателя.

Кто в плюсе: 1С и всё, что связано с импортозамещением

На фоне общей стагнации есть один сегмент, который чувствует себя лучше всех — и это не AI-разработка, не DevOps и не облака — а 1С. Специалисты по 1С в 2026 году получают прибавку 15–20% в год. Это в три раза выше среднего по рынку, и по наблюдениям рекрутингового рынка — лучший год для этого направления за всю историю.

Почему так происходит — понятно, если разобраться в том, откуда берутся деньги. Бюджеты на импортозамещение выделяются отдельно от всего остального. Переход на российское ПО — законодательное требование с конкретными сроками. Деньги под это уже заложены, и срезать их в середине года гораздо сложнее, чем заморозить, например, маркетинговый проект или разработку нового продукта.

Пока другие направления оптимизируют бюджеты и пересматривают приоритеты, разработчики и проекты на 1С закрывают один проект интеграции и сразу берут следующий — очередь не заканчивается.

Кого сокращают и почему

Если коротко, нас сокращают, потому что бизнес выбирает более дешёвое и менее технологичное решение прямо сейчас вместо окупаемого через несколько лет.

Простой пример: заказчик отказывается от автоматизации колл-центра и оставляет живых операторов в регионе. Автоматизация была бы выгоднее в долгосроке, но деньги нужны сейчас — и дешёвый колл-центр выигрывает. Разработчики сложных систем остаются без задач, а операторы поддержки получают больше нагрузки.

Расслоение внутри самого IT при этом только усиливается: зарплаты растут у тех, кто много знает и много работал и тех, кому повезло с проектом, а массовые позиции стагнируют. Рынок становится предсказуемым: каждый человек в команде должен приносить результат, который видно и который можно посчитать.

География больше не определяет зарплату

В IT заметного разрыва между регионами пока нет, и причина простая — удалёнка никуда не делась. Да, компании всё чаще зовут людей в офис хотя бы пару дней в неделю, но этого недостаточно, чтобы создать серьёзный разрыв между Москвой и остальными городами. Максимум 20% — и то это скорее редкие случаи, чем правило.

Два разработчика одного уровня, один в офисе в Казани, другой на удалёнке в том же часовом поясе — получают примерно одинаково. Потому что работодателю важно не где вы сидите физически, а насколько вы пересекаетесь с командой по времени и что за проект. Если проект финансируется и входит в приоритетное направление — город значения не имеет.

Три вопроса, которые нужно задать себе прямо сейчас

Смотреть на общую статистику по отрасли сейчас бесполезно — она слишком размытая, чтобы из неё что-то вывести про себя лично. Полезнее задать три конкретных вопроса про то, над чем вы работаете прямо сейчас.

1. Является ли ваш проект обязательным для бизнеса?

Не полезным, не интересным, не перспективным — именно обязательным, таким, без которого бизнес не может функционировать или выполнить регуляторные требования. Экспериментальные продукты и внутренние инструменты замораживаются первыми — именно потому, что их отсутствие не останавливает работу компании.

2. Проект связан с переходом на российское ПО?

Если да — вы в той части рынка, где бюджеты защищены и не зависят от квартальных результатов компании. Если нет — лучше оценить, насколько реально переориентироваться на это направление через повышение квалификации именно в тех стеках, где бюджеты не урезаются.

3. Насколько легко вас заменить?

Есть ли на рынке люди с похожим набором компетенций, но дешевле, и можно ли вашу задачу закрыть автоматизацией за разумное время. Стратегия «переждать» в текущих условиях не работает, потому что стагнация зарплат в массовых сегментах может длиться долго, а рынок не вернётся к прежней динамике автоматически — только тогда, когда макроэкономическая ситуация позволит компаниям снова вкладывать в развитие.

Итог: рынок пытается нормализоваться

То, что происходит — не обвал и не кризис. Это возврат к ситуации, когда зарплата определяется тем, что ты реально умеешь и насколько это нужно бизнесу прямо сейчас. Несколько лет до этого рынок был аномальным: компании перебивали офферы друг у друга даже за слабых специалистов, потому что людей просто не хватало. Сейчас это закончилось, и работа всё равно есть — просто условия стали жёстче.

Зарплатная гонка перешла в гонку навыков. Побеждает не тот, кто громче просит повышения, а тот, кого сложно заменить. И цена ошибки в выборе направления стала выше — если сидите на проекте, который могут заморозить в любой момент, лучше разобраться с этим сейчас, а не когда придёт уведомление.

Точечный рост будет — там, где дефицит нужных людей и защищённые бюджеты: импортозамещение, интеграция российского ПО, направления, которые бизнес не может себе позволить остановить. Общего подъёма не будет, но у тех, кто попал в правильную нишу и приносит измеримый результат — возможности есть.

Портфолио — что это?

Портфолио — это подборка твоих наилучших работ с описанием результатов. Единого стандарта оформления нет, потому что у каждой специальности свои особенности. К тому же, это творческий процесс, и каждый упаковывает кейсы так, как считает нужным. Главное, чтобы на выходе получилось убедительное портфолио для работодателя.

Нужно ли портфолио всем? Нет, портфолио нужно только тем, у кого есть осязаемый результат: дизайн, код, фотография, тексты или цифры.

Обязательно ли иметь портфолио? Такой обязанности ни у кого нет, но при общении с работодателем это уже стало хорошим тоном.

Зачем включать учебные работы в портфолио?

Когда опыта нет, а выходить на рынок пора, учебные проекты становятся единственным аргументом. Резюме заполняют все, но этого мало. Чтобы тебя заметили, рекомендуется написать сопроводительное письмо к портфолио. Сейчас автоматизированные системы проверяют не только резюме, но и текст письма на наличие ключевых слов. Только если алгоритм одобрит твой отклик, HR увидит портфолио.

Какие работы можно включить?

В портфолио можно включить:

• дипломные работы,
• курсовые,
• творческие зачеты,
• лабораторные работы,
• исследования.

Не нужно вставлять дипломные фолианты целиком, их никто не будет читать. Отсеки лишнее и оставь только выжимку с основной информацией.

Важно, чтобы проекты были структурированы. Каждый блок должен иметь четкое название. Также, если посмотреть на качественный пример портфолио студента, можно заметить, что работы там чаще всего расположены в хронологическом порядке, чтобы была видна динамика твоего роста.

И самое главное, не бойся добавлять в портфолио для поиска работы неидеальные проекты. Никто не ждет от студентов работ уровня сеньора. Работодателю важно видеть твой потенциал и подход к работе.

Что лучше не включать?

Портфолио не должно стать архивом твоих работ. В нем должно быть собрано только лучшее. Есть еще несколько рекомендаций о том, что лучше не добавлять:

• Проекты не по теме. Если ты откликаешься на вакансию дизайнера, то твои лабораторные по основам безопасности жизнедеятельности будут совсем не в тему.
• Недоделки. Проекты, брошенные на полпути, создадут о тебе впечатление несерьезного человека. Уж лучше один доделанный, чем пять незавершенных.
• «Средненькие» проекты. Оставляй только то, что имеет вес. Слабые работы размывают впечатление о портфолио.
• Чужое авторство. Не включай работы, в которых твой вклад был минимальным. Если проект был командным, четко пропиши свою роль и внесенный вклад, чтобы не присваивать чужие заслуги.

Меньше, но лучше! Когда отсеешь все лишнее и оставишь только сильные проекты, можно переходить к тому, как выполнить оформление портфолио для работы.

Как правильно оформить портфолио?

Оформление для разных сфер может разительно отличаться, но при первом составлении лучше опираться на понятную структуру. Пункты ниже помогут понять, что включает в портфолио успешный кандидат. Тем не менее, ничего не мешает тебе менять порядок разделов по своему усмотрению и адаптировать их под конкретные задачи.

Обложка

«Встречают по одежке…». Видел когда-нибудь портфолио дизайнеров на Behance? Они точно знают, что без цепляющей обложки на проект никто не кликнет. И не важно, какого профиля ты специалист. В эпоху переизбытка контента каждому нужно уметь выделяться.

Информация об авторе

Простое копирование описания из резюме может сделать портфолио слишком сухим. Лучше составить новый текст в свободном формате. Расскажи о своих интересах или профессиональных целях живым языком, чтобы работодателю было проще погрузиться в портфолио.

Фотография

Портфолио прикрепляется не к госуслугам, поэтому необязательно делать фото, как на паспорт. Старайся соблюдать единый стиль и прикреплять фотографию в стилистике портфолио.

Примеры работ

Иногда работы так хорошо оформлены в отдельных файлах, что переносить их в портфолио не хочется. Кажется, что процесс будет муторным и результат будет выглядеть хуже оригинала. Сразу возникает соблазн просто вставить на проект и надеяться, что работодатель на неё кликнет.

В реальности тратить время на переход по ссылкам от незнакомого человека никто не станет. Заинтересовать работодателя с первых секунд можно только готовым проектом перед глазами. Оптимально будет включить в портфолио от 3 до 10 лучших работ.

Контакты

Как и с примерами работ, контакты должны быть сразу перед глазами. Выходить за пределы портфолио и искать твой ник в телеграме — процесс энергозатратный. Так работодатель может ненароком отвлечься на чужое портфолио, в котором по закону подлости окажутся ссылки на все мессенджеры и социальные сети.

Укажи актуальный номер телефона, адрес электронной почты. Добавь ссылки на мессенджеры и все доступные способы быстро связаться с тобой. Чем меньше усилий нужно прилагать для того, чтобы написать тебе сообщение, тем выше твои шансы на получение оффера.

Где разместить портфолио?

Выбор площадки напрямую зависит от твоей специальности. Одной платформы часто не хватает, потому что интерфейс везде ориентирован под разные цели.

• Behance. Дизайнеры и иллюстраторы чаще выбирают этот ресурс для подачи визуального материала и оформления красивых кейсов.
• GitHub. Программистам больше подходит этот сервис, где можно опубликовать чистый код и показать структуру проекта.
• Telegram. Этот формат удобен тем, что интерфейс мессенджера изначально ориентирован на чтение текстов. Поскольку это популярное приложение, обратная связь по твоему портфолио придет быстро. Работодателю проще написать тебе в личные сообщения, чем составлять письмо на электронную почту.
• Tilda. Подойдет тем, кто хочет выделиться среди кандидатов. В этом конструкторе можно бесплатно создать сайт на неограниченный срок без платных подписок. Такой формат позволяет гибко оформить портфолио и удобно сгруппировать работы.
• PDF-файл. Иногда проще всего отправить проект напрямую при отклике на вакансию. Главное помнить про удобство того, кто будет смотреть твои работы.

Теперь ты знаешь, что делать со всеми проектами, которые накопились за время учебы. Хорошие вузовские наработки могут стать твоим главным аргументом при устройстве на первую работу. Помни, что стесняться отправной точки не нужно. Портфолио будет постоянно видоизменяться вместе с твоим опытом. Со временем ты будешь не только добавлять новые работы, но и удалять неактуальные. Главное, с чего-то начать.

Если в процессе не хватает примеров или сложно собрать кейс в цельную историю, можно дополнительно разобраться с помощью консультаций от Автор24.

ИИ показал хорошие результаты в решении типичных задач, но столкнулся с ограничениями в сложных и нестандартных ситуациях. Это привело к пересмотру первоначальных планов — вместо полного замещения сотрудников компании стали искать компромисс между автоматизацией и человеческим участием.

Началась тихая, но вполне масштабная операция по возврату уволенных специалистов.. Этот процесс не означает отказ от технологий, но демонстрирует более взвешенный подход к их внедрению. Компании осознали, что эффективность работы зависит от грамотного распределения задач между людьми и машинами.

Хроники бумеранга

Статистика показывает, что первоначальные ожидания бизнеса от автоматизации были завышены. Вместо безвозвратного замещения людей алгоритмами рынок труда столкнулся с феноменом «бумерангового найма» — возврата ранее уволенных сотрудников. Тренд подтверждается глобальными исследованиями и указывает на более сложный характер интеграции искусственного интеллекта.

Статистическое подтверждение тренда

Аналитики компании Visier, изучив данные о трудоустройстве 2,4 млн сотрудников из 142 международных компаний, пришли к выводу: часть уволенных работников впоследствии возвращаются к прежнему работодателю.

В исследовании отмечают, что этот показатель стабильно рос в течение 2025 года, особенно в подразделениях, активно внедрявших ИИ. Аналитики связывают это с тем, что многие руководители начинали сокращениям, толком не разобравшись, в решении каких конкретно задач новые технологии смогут помочь.

Экономическая неэффективность массовых сокращений

Глубинной причиной этого тренда стала низкая отдача от инвестиций в ИИ. Исследование Массачусетского технологического института (MIT) «The GenAI Divide: State of AI in Business 2025» демонстрирует фундаментальную проблему: 95% компаний не получили ощутимой прибыли от своих вложений в генеративный ИИ. Многие проекты зависали на стадии пилотов, так и не выходя в промышленную эксплуатацию.

Смена приоритетов бизнеса

Осознание этих реалий заставляет компании пересматривать кадровую стратегию. Аналитики Forrester в отчете «Прогнозы 2026: будущее труда» приводят красноречивые цифры: 55% работодателей уже сожалеют о решениях об увольнениях, принятых под предлогом внедрения ИИ.

В связи с этим 57% специалистов, отвечающих за инвестиции в ИИ, ожидают увеличения численности персонала в ближайшие годы. Примечательно, что лишь 10% компаний упорно отказываются менять курс и возвращать сотрудников.

Влияние на рынок труда

Воздействие ИИ-решений на занятость неоднородно. Исследование профессора НИУ ВШЭ Ларисы Смирных, охватившее почти 1800 российских предприятий, показало, что в среднем внедрение ИИ приводило к сокращению занятости на 0,79 процентного пункта.

Однако на малых предприятиях сокращение составило 1,26 п.п., на крупных — 2,08 п.п., а предприятия среднего размера, напротив, увеличили численность работников на 2,96 п.п.. Это доказывает, что эффект зависит от сочетания структурных и финансовых факторов конкретного бизнеса.

Косвенные эффекты и кризис воспроизводства кадров

Параллельно с возвратным наймом развивается и другой тренд — сокращение входных позиций для новичков. Исследование Stanford Digital Economy Lab выявило, что с момента запуска ChatGPT занятость молодых специалистов в профессиях, подверженных автоматизации, снизилась на 13%.

Опросы показывают, что 42% организаций заморозили найм на позиции начального уровня в IT-сфере. Это создает «профессиональную пропасть» — разрыв между академическим образованием и реальной практикой, что может привести к кризису воспроизводства кадров в будущем.

Реальные кейсы: кто и почему возвращает сотрудников

Истории замены и возврата оказались сложнее примитивной схемы «робот занял место человека». Компании столкнулись с тем, что эффективное использование ИИ требует не устранения человеческого фактора, а его интеграции с технологиями.

Amazon и цена ошибки

История Amazon показательна. Осенью 2024 года ИИ-система, заменившая часть DevOps-инженеров, стала причиной катастрофического сбоя в AWS (многофункциональный облачный сервис). Длительный простой десятков крупных интернет-платформ наглядно продемонстрировал — алгоритмы не справляются с нештатными ситуациями.

После инцидента компания начала тихий возврат ключевых специалистов — для создания систем контроля и аварийного реагирования.

McDonald's: 260 наггетсов вместо бургера

Голосовой ИИ от IBM в drive-in сетей McDonald's должен был ускорить прием заказов. Система анализировала историю покупок и предлагала клиентам персональные варианты. Но что-то пошло не так. В 2024 году соцсети наполнились роликами с ошибками алгоритма. ИИ добавлял бекон к мороженому, предлагал девять порций чая вместо булочки и выставлял счета на 260 наггетсов.

После публичного провала сеть отключила систему в сотнях закусочных. Технология не справилась с шумным окружением и человеческой речью. Провал стоил компании сотни миллионов долларов.

Российский подход: адаптация через переобучение

В России компании демонстрируют стратегию осторожной интеграции, делая ставку на трансформацию должностей вместо их ликвидации. Исследование TAdviser показывает, что доля крупных российских компаний, использующих AI-решения, выросла с 28% до 43% за 2024-2025 годы.

При этом массовых сокращений не последовало. Внутренние программы переподготовки, такие как «Академия ИИ» в «Сбере», через которую прошли тысячи работников, стали показательным ответом на вызовы автоматизации. Стратегия компаний сместилась с замены людей на усиление их возможностей с помощью алгоритмов.

Изначально банк запланировал три волны увольнений на 2025 год с целью сокращения издержек и увеличения прибыли. Вторая волна, по заявлению компании, напрямую связана с внедрением AI-ассистентов. Алгоритмы брали на себя рутинные задачи тестировщиков, разработчиков и руководителей команд.

Но катастрофических сокращений не последовало. Банк начал создавать новые подразделения поддержки AI-продуктов. Часть уволенных сотрудников получила предложения вернуться на измененных условиях. Не как исполнители, а как наставники алгоритмов.

Где ИИ действительно преуспел, а где провалился

За два года активного внедрения искусственного интеллекта в бизнес-процессы сформировалась четкая картина его реальных возможностей и ограничений. Вопреки первоначальным ожиданиям, ИИ оказался эффективным инструментом для решения конкретных классов задач, но не смог стать универсальной заменой человека.

Сферы эффективного применения ИИ

Наибольшую результативность алгоритмы демонстрируют в областях с четко определенными правилами и большими объемами структурированных данных:

• обработка типовых тикетов технической поддержки увеличивает скорость ответа на 30-50%;
• генерация шаблонного кода стала рутинной практикой, особенно в мобильной разработке где преобладают типовые архитектурные паттерны;
• первичный анализ данных и построение базовых отчетов перешли в зону ответственности ИИ;
• автоматическое тестирование стандартных сценариев освободило QA-инженеров от рутины.

Инструменты типа GitHub Copilot успешно справляются с созданием стандартных функций. Время на написание повторяющегося кода сокращается в среднем на 35-40%. Алгоритмы эффективно обрабатывают большие массивы информации, выявляя очевидные зависимости и аномалии.

Области, требующие человеческого участия

Наиболее значительные провалы ИИ связаны с задачами, требующими понимания контекста и работы с неструктурированной информацией:

• работа с legacy-системами остается сложнейшей проблемой — алгоритмы не способны понять контекст десятилетних накоплений;
• сложная техническая поддержка, где необходимо выявить неочевидную причину сбоя, требует человеческого опыта и интуиции;
• принятие решений в условиях неопределенности остается прерогативой человека;
• управление командами и проектами требует эмоционального интеллекта и учета межличностной динамики;
• задачи, требующие творческого подхода, также остаются за человеком.

Специалисты способны сопоставить разрозненные факты, используя фоновые знания и понимание системных взаимосвязей. ИИ эффективно обрабатывает данные в рамках заданных параметров, но неспособен к стратегическому мышлению при недостатке информации.

Опыт компаний показывает, что наиболее эффективной моделью становится симбиоз человеческого интеллекта и искусственного, где каждый фокусируется на своих сильных сторонах.

Почему сокращения оказались убыточными — экономический аспект

Платформа Orgvue провела расчет полной стоимости увольнений. Результат озадачил финансовых директоров. На каждый сэкономленный доллар на зарплатах компании несли $1.27 скрытых расходов.

В анализ вошли:

• выходные пособия и страховые выплаты;
• потеря продуктивности в переходный период;
• затраты на рекрутинг новых сотрудников;
• удар по бренду работодателя;
• расходы на дообучение оставшегося персонала.

Для российских компаний добавилась специфическая проблема — многим из них требуется сохранять численность штата для соответствия регуляторным требованиям. Это приводит к ситуациям, когда формально сотрудники остаются, но их реальные обязанности сводятся к контролю ИИ.

Новые профессии на стыке человека и алгоритма

Рынок труда демонстрирует адаптивность в ответ на распространение ИИ. Вместо массового сокращения штатов формируется сегмент гибридных специальностей, требующих сочетания предметной экспертизы и технологической грамотности. Согласно исследованию hh.ru, зарплаты в этих направлениях выросли на 20-45% за 2024-2025 годы, отражая дефицит квалифицированных кадров.

Промпт-инженеры стали одной из самых востребованных профессий. Эти специалисты формулируют запросы к ИИ таким образом, чтобы алгоритм понимал контекст и выдавал релевантные результаты. В их обязанности входит не только составление текстовых команд, но и тестирование различных подходов к взаимодействию с нейросетями, оптимизация промптов под конкретные бизнес-задачи.

AI-тренеры обучают нейросети на внутренних данных компаний. Профессионалы в этой области должны глубоко понимать специфику производства и уметь передавать эту экспертизу алгоритмам. Они работают с разметкой данных, валидацией результатов обучения и постоянной донастройкой моделей под изменяющиеся требования.

Интеграторы моделей занимаются внедрением готовых ИИ-решений в существующие бизнес-процессы. Специалисты обладают уникальной комбинацией навыков — понимают и технологические аспекты работы алгоритмов, и операционную деятельность компаний. Они адаптируют решения под конкретные рабочии процессы и отвечают за бесперебойную работу систем

Этики ИИ обеспечивают корректное и безопасное использование искусственного интеллекта. Профессия возникла после нескольких громких скандалов, связанных с дискриминацией алгоритмов. Специалисты разрабатывают этические стандарты, проводят аудит систем на предмет предвзятости и следят за соблюдением нормативных требований.

Формирование этих профессий свидетельствует о переходе от противостояния человека и алгоритма к их продуктивному сотрудничеству. Компании все чаще рассматривают ИИ не как инструмент замены сотрудников, а как возможность перераспределить человеческие ресурсы на более сложные и творческие задачи.

Фундаментальные ограничения: почему ИИ не заменит человека в ближайшем будущем

Алгоритмы работают с паттернами, но не понимают смысла. Они анализируют данные, но не обладают сознанием, эмпатией, моральными суждениями и творческим мышлением.

Когнитивные барьеры:

• отсутствие здравого смысла — ИИ не понимает очевидных для человека вещей;
• хрупкость моделей — при столкновении с нестандартными данными выдают абсурдные результаты;
• неспособность к настоящему творчеству — только комбинация существующих паттернов;
• отсутствие эмоционального интеллекта — не могут сопереживать и понимать чувства.

ИИ может симулировать эмпатию, анализируя тон голоса или выбор слов. Но он не способен по-настоящему сопереживать, чувствовать боль, радость или любовь. Это делает его бесполезным в ситуациях, требующих человеческого участия.

Российский рынок труда: трансформация, а не замена

В 2025 году российский рынок труда демонстрирует осторожный подход: несмотря на активное внедрение технологий, он развивается по пути трансформации и сотрудничества, а не массового замещения сотрудников.

Экономический контекст и кадровый дисбаланс

Ситуация на рынке труда в целом неоднозначна. Исследование «Актион Кадры и HR» показывает, что более 40% российских компаний не исключают сокращений штата в 2025-2026 годах. Основными причинами называют высокую ключевую ставку, удорожание кредитов и общую экономическая неопределенность.

При этом существует острый дефицит квалифицированных кадров в промышленности, строительстве и IT — здесь работодатели готовы повышать зарплаты для привлечения специалистов. Это противоречие объясняется нехваткой сотрудников с конкретными, востребованными навыками.

Внедрение ИИ: осторожность и прагматизм

В сравнении с западными компаниями российские действуют более сдержанно. Они фокусируются на точечной автоматизации в ключевых секторах, где можно быстро получить измеримый результат:

• Упор на эффективность. Генеративные модели стали базовым инструментом в финтехе, промышленности и медицине. При грамотном использовании они увеличивают производительность труда до 20%, а снижение издержек достигает 15%.
• Ограниченное использование в HR. Только 38% компаний применяют генеративный ИИ для скрининга резюме, что говорит о предпочтении человеческого контроля в ключевых процессах управления талантами.
• Сдвиг в IT-найме. В IT-сфере наблюдается профицит кандидатов начального уровня (джунов), в то время как дефицит высококвалифицированных senior-специалистов сохраняется. Индекс конкуренции на одну вакансию достигает 12.5 резюме, но для позиций senior-уровня он составляет всего 2.5.

Барьеры на пути автоматизации

Несколько ключевых проблем мешают российскому бизнесу провести тотальную автоматизацию:

• Недоверие и дефицит компетенций. 43% компаний отмечают недоверие к ИИ как к технологии, а в 40% организаций просто не хватает специалистов, способных с ним работать.
• Сопротивление изменениям. Сотрудники на всех уровнях — от рядовых специалистов до топ-менеджеров — часто сопротивляются внедрению новых технологий, опасаясь неопределенности.
• Технологическое отставание и гибридные решения. Необходимость адаптации западных ИИ-решений к местным реалиям и отставание российских аналогов вынуждают компании искать сложные гибридные подходы, что замедляет процесс.

Вместо тотальных увольнений в России происходит постепенное изменение должностных обязанностей. Бизнес перестраивает процессы — рутинные задачи делегируются алгоритмам, а за человеком сохраняются функции, требующие критического мышления, управления и творческого подхода. Это приводит к изменению профессиональных профилей и необходимости постоянного обучения сотрудников.

Государство и регуляция: запаздывающая реакция

Правительство усиливает меры поддержки компаний, заинтересованных в переподготовке кадров и интеграции ИИ во все ключевые процессы.Звучат слова о важности технологического суверенитета и этических стандартах внедрения.

Власти в первую очередь заинтересованы в социальной стабильности и сохранении занятости населения на стандартном уровне. Рост безработицы на фоне развития моделей — момент политически невыгодный.

Что делать специалисту: практические выводы

Стратегия «возьми готового, используй, замени» оказалась нежизнеспособной. 71% сотрудников уходят из компаний из-за низкой зарплаты, 57% — из-за стресса и перегрузок. В новых условиях компании стали больше ценить персонал, но и специалистам стоит позаботиться о своем будущем.

Как сохранить ценность на рынке:

• развивать мягкие навыки — эмпатию, адаптивность, гибкость управления;
• осваивать ИИ как инструмент, а не конкурировать с ним;
• фокусироваться на задачах, требующих человеческого понимания контекста;
• инвестировать в непрерывное обучение, особенно в смежных областях.

Успешные компании создают экосистему долгосрочной лояльности. Развитие сотрудников и забота об их благополучии становятся главными конкурентными преимуществами в борьбе за таланты.

Трансформация рабочих мест: реалии и перспективы симбиоза человека и ИИ

Сценарий массовых увольнений из-за искусственного интеллекта не оправдался. Вместо этого рынок труда переживает сложную трансформацию, где технологии не столько заменяют людей, сколько перекраивают саму структуру профессий и требуют новых навыков.

Масштабы воздействия: от апокалиптических прогнозов к реальным цифрам

Исследования показывают значительный, но не катастрофический потенциал автоматизации. Ученые из Массачусетского технологического института (MIT) с помощью инструмента «Индекс айсберга» смоделировали влияние ИИ на почти 1000 профессий.

Результаты показывают, что современные системы теоретически могут заменить задачи, эквивалентные 11,7% всей рабочей силы США. Однако авторы подчеркивают, что экономические препятствия, затраты на внедрение и необходимость человеческого контроля сдержат тотальную автоматизацию в обозримом будущем .

Этот вывод перекликается с настроениями бизнес-лидеров. Опрос Forbes Research 2025 AI Survey демонстрирует, что 94% руководителей по всему миру ожидают сокращения менее 5% рабочих мест в течение следующих двух лет. Более того, 59% полагают, что ИИ в конечном итоге создаст новые профессии, а не ликвидирует существующие.

В России потенциал автоматизации оценивается примерно в 11 миллионов эквивалентов занятости. Речь идет в первую очередь о перераспределении задач, а не об исчезновении профессий как таковых .

Два пути развития: почему будущее за усилением, а не за автоматизацией

Аналитики и историки технологий выделяют два принципиально разных сценария развития ИИ в экономике:

• Путь автоматизации. Фокус на полном замещении человеческого труда. Эта концепция, популярная венчурными инвесторами и частью техногигантов, ведет к росту неравенства и потенциальной социальной нестабильности, что подтверждается предыдущими волнами цифровизации и роботизации .
• Путь усиления. Ставка на создание новых задач и инструментов, расширяющих человеческие возможности. ИИ может предоставлять специалистам — от айтишников и учителей до сантехников и электриков — больше возможностей, позволяя браться за более сложные и ценные задачи.

Текущая практика показывает движение по второму пути. Внедрение ИИ становится корпоративным трендом, но не приводит к массовым чисткам.

Новый ландшафт профессий: что происходит на рынке труда

Профессии не исчезают массово, но интенсивно трансформируются. Этот процесс имеет несколько четких проявлений:

1. Рождение гибридных специализаций. Рынок создает спрос на интеграторов моделей, специалистов по безопасности ИИ, AI-тренеров и промпт-инженеров. Эти профессионалы, обладающие навыками работы с алгоритмами, могут получать на 20% больше, чем их коллеги без такого опыта .
2. Перераспределение задач внутри профессий. ИИ берет на себя рутинные операции, освобождая время людей для более сложных задач. В результате меняются должностные инструкции, а не состав персонала. Исследование Microsoft показывает, что ИИ может выполнять до 98% задач переводчика, 91% задач математика и 81% задач журналиста, но это не делает сами профессии ненужными — оно меняет их суть.
3. Устойчивость «человеческого» в работе. Даже самые продвинутые алгоритмы сталкиваются с фундаментальными ограничениями. Группа ученых из США и Австрии объясняет это «вложенностью навыков». Продвинутые профессиональные умения опираются на широкий спектр базовых — логику, математику, эмпатию, анализ рисков, работу в условиях неопределенности. Создать такую многослойную систему в цифровой среде пока невозможно. ИИ не обладает интуицией, ценностями и эмоциональной вовлеченностью.

Итоги

Самые успешные компании 2025 года — не те, кто массово уволил сотрудников, а те, кто нашел компромисс между эффективностью алгоритмов и живой экспертизой. Машины не забирают работу — они меняют её содержание. Успех в новой реальности зависит от готовности к непрерывному обучению и способности выстраивать эффективное сотрудничество с ИИ, в котором за человеком остаются стратегия, творчество, этическая оценка и конечная ответственность.

Теперь предстоит самое важное – показать себя в живом разговоре. Здесь не помогут аккуратные таблицы навыков и выученные формулировки: проверяют не только знания, но и то, как вы мыслите и общаетесь.

Только не бойтесь!

Я и моя команда экспертов школы системного анализа провели десятки собеседований с кандидатами. Мы видели, какие ошибки совершают даже сильные специалисты, и какие детали решают исход встречи. В этой статье я расскажу, как представить себя HR-у и будущему руководителю с лучшей стороны – чтобы выбрали именно вас.

Перед собеседованием: системная подготовка

Подготовка к собеседованию – это уже проявление системного мышления. Вы должны не просто выучить «что отвечать», а понять, как устроен сам процесс интервью. У него, как у любой системы, есть цели, роли и связи.

Интервьюер хочет снизить риск ошибки найма: понять, подойдете ли вы под задачи и культуру компании. Вы – показать, что умеете анализировать, уточнять и принимать решения.

Перед встречей я рекомендую сделать короткий анализ контекста:

Важно! Интервьюер мгновенно чувствует, когда кандидат не изучал компанию. Даже два предложения про продукт показывают, что вы умеете готовиться. Для аналитика это обязательный навык.

Во время интервью: как говорить и как слушать

Хорошее собеседование системного аналитика похоже одновременно и на прием у психолога, и на экзамен. Вас не просят пересказать теорию – вас испытывают как человека и профессионала в своей специальности.

Говорите спокойно, без спешки. Если вопрос сложный, сделайте паузу и структурируйте ответ:

1. Контекст – «На прошлом проекте мы…»
2. Действие – «Я проанализировала процесс и нарисовала схему…»
3. Результат – «Это помогло бизнесу сократить время согласования».

Такой ответ читается как мини-кейс и сразу показывает, что вы мыслите системно. Если вопрос звучит неясно, уточняйте. Например:

«Правильно ли я понимаю, речь о функциональных требованиях или о взаимодействии с пользователем?»

Это не слабость – это профессиональное поведение. Интервьюер видит, что вы не боитесь уточнять, а значит, не будете строить систему на догадках. Более того, такие уточнения помогают задать тон разговору и показывают ваше умение управлять коммуникацией. Они формируют доверие: собеседник видит, что вы не просто отвечаете на вопросы, а действительно слушаете и анализируете суть задачи.

О чем чаще всего спрашивают

На интервью аналитика почти всегда затрагивают эти три блока. Они не существуют отдельно – именно по этим аспектам интервьюер оценивает вашу зрелость как специалиста. Ни один из них не решает исход собеседования в одиночку – важно показать целостное мышление и умение соединять практику, анализ и коммуникацию.

Технический

На этом этапе интервьюер оценивает, насколько уверенно вы работаете с инструментами системного анализа: UML, BPMN, REST, SQL и другими. Вас могут попросить объяснить, как описать интеграцию CRM с ERP или спроектировать API.

Кейсовый

Здесь проверяют ваше умение анализировать и структурировать задачи. Интервьюер предложит практическую ситуацию: например, бизнес внезапно меняет требования или заказчик просит добавить новую функцию. HR и ваш будущий руководитель захотят узнать, как вы отреагируете, как сориентируетесь в ситуации, какое решение предложите — и чем это будет аргументировано.

В данном кейсе, например, следует помнить, что покорное согласие с запросом заказчика — не всегда верное решение. Если есть наилучший вариант — аргументируйте и продвигайте его: так вы покажете, что заинтересованы в конечном результате проекта.

Кроме того, важно не спешить с решением, а задать уточняющие вопросы, определить проблему и предложить шаги, как ее исследовать и согласовать.

Поведенческий

Этот блок показывает, как вы реагируете на неопределенность и стресс. Вас спросят о конфликтах, ошибках или сложных коммуникациях в команде. Например: «Как вы действуете, если разработчик не согласен с вашим решением?» Здесь важно показать спокойствие, способность слушать, аргументировать и искать решение, а не победу в споре.

Вот краткий ориентир:

Как производить впечатление зрелого аналитика

На собеседовании оценивают не только содержание, но и форму вашей речи. Даже простые фразы можно сказать по-разному:

Неверно: «Я всегда правлю требования, если считаю их некорректными.»

Верно: «Если вижу противоречие, я сначала обсуждаю его с заказчиком и фиксирую решение.»

Во втором случае вы показываете не самоуверенность, а зрелый процесс мышления. Помните, вас слушают не как студента, а как будущего коллегу. Поэтому лучше говорить на языке партнера, а не ученика.

Важно! Хороший аналитик – это человек, который умеет оставаться логичным даже в неловких ситуациях. На собеседовании это проявляется сильнее, чем в любом тестовом задании.

После собеседования: что сделать обязательно

Если встреча прошла успешно – поблагодарите интервьюеров. Если нет – все равно поблагодарите и проанализируйте опыт. Это не просто вежливость, а профессиональный подход: вы фиксируете результат итерации и формируете обратную связь, как после ретроспективы проекта. Даже краткое письмо вроде «Спасибо за уделенное время, разговор был полезен» оставит о вас впечатление зрелого специалиста.

Советую вам сразу после интервью записывать три пункта:

• Какие вопросы вызвали затруднение;
• Что удалось особенно хорошо;
• Что стоит пересмотреть в следующем ответе.

Такой разбор занимает не больше десяти минут, но дает эффект накопления опыта. Через несколько собеседований вы начнете видеть закономерности: какие темы повторяются, где теряете уверенность, на какие типы вопросов реагируете спокойнее.

Это позволит не только лучше готовиться, но и понять собственные сильные стороны. Со временем интервью перестают казаться стрессом – превращаются в тренировку аналитического мышления и навык ведения профессионального диалога.

Вместо заключения

Собеседование – это мини-модель будущей работы. Здесь, как и в проекте, есть цель, участники, артефакты и неопределенность. Если вы умеете уточнять, структурировать и держать разговор логично – вы уже действуете как системный аналитик.

Я часто повторяю своим студентам: «Не нужно казаться идеальным кандидатом. Достаточно быть тем, кто умеет думать.»

В следующей, третьей части серии мы разберем, как распознать плохую компанию и не попасть туда, где системный анализ подменяют хаотичными задачами и бесконечными совещаниями.

Чжан был не айтишник. Он консультировал школьников и их родителей по поступлению в вузы, построил на этом империю с оборотом в сотни миллионов юаней и стал, наверное, самым узнаваемым «учителем» в Китае. Типичный 奋斗逼 (фэньдоу би) — «задрот по жизненному успеху», если переводить мягко, «раб собственных амбиций», если честно. Парень из нищего уезда в Маньчжурии, который вкалывал по 16 часов в сутки, в 2023-м уже попадал в больницу с сердцем, но продолжал. Три дня назад выложил пробежку на 7 км. Вчера — всё.

Я не из образования. Я из IT. И когда я прочитал эту новость, первая мысль была не «какой ужас», а «ну да, кто следующий». Потому что в китайском IT люди живут точно так же. Так вот — давайте я расскажу, как именно.

Это был один из китайских IT-гигантов — какой именно, говорить не буду, но вы точно о нём слышали. В первый рабочий день мне сказали: «Выбери себе 花名 (хуамин)». «Цветочное имя», прозвище, которое заменит твоё настоящее имя во всех корпоративных системах. Навсегда. Мой тимлид был «Западный Ветер» (西风). Архитектор — «Одинокий Меч» (孤剑). HR — «Маленькая Фея» (小仙女). Я выбрал что-то из комиксов, потому что мне было 23 и казалось, что это круто.

Через полгода я понял, что когда архитектор «Одинокий Меч» пишет в DingTalk «[мой ник], твой PR — мусор», это звучит как плохой фанфик. Но система хуамин не причуда. Ты не знаешь, мидл перед тобой или VP, пока не загуглишь его ник во внутренней вики. Ты споришь с «Западным Ветром», а не с «начальником отдела Чжаном». В этом весь смысл.

Привет, Tproger. Я фулстек из восточного Китая, поработавший в паре «дачан» (大厂, так у нас называют техгигантов) и нескольких стартапах. В России учился 4 года, Mass Effect прошёл на русском раньше, чем на мандарине, а баги комментирую матом — спасибо общаге ИТМО. Работаю на стыке двух IT-миров и хочу рассказать о вещах, которых вы не найдёте ни в одной подборке «Top 10 facts about Chinese tech».

Хуамин: когда твой CEO — «Ветер со Свободных Холмов»

Система прозвищ распространена повсюду. В ByteDance используют английские имена (один мой бывший коллега, серьёзный бэкенд-архитектор, ходил как «Banana»). В Xiaomi предпочитают номера: основатель Лэй Цзюнь — просто «1 号» (Номер Один). В Huawei в ходу воинские звания и кодовые обозначения проектов.

Зачем? Три причины, и все не те, что вы подумали:

1. Анти-иерархия. Видишь ник «Облачный Журавль» — и не понимаешь, джун это или директор. Порог для того, чтобы написать вопрос или возразить, становится ниже. Теоретически. На практике все всё равно знают, кто есть кто, но ритуал «мы тут все равны» работает как смазка.
2. Безопасность. В компании на 250 000 человек утечка реального имени = утечка данных. Хуамин — ещё один слой изоляции.
3. Принадлежность. Твой хуамин — это посвящение. Как гильдейский тег в MMORPG. После увольнения хуамин «уходит на пенсию», и никто другой его уже не возьмёт. У Джека Ма хуамин «风清扬» (Фэн Цинъян) — мастер меча из романа Цзинь Юна. Этот ник навечно закреплён.

Когда я рассказываю это русским коллегам, они смеются. Но подумайте: у вас в компании вы обращаетесь к тимлиду «Дмитрий Сергеевич» или «Дима»? А если бы он был «Тёмный Феникс» — стали бы вы стесняться сказать ему, что его код — отстой?

«996» умер. Да здравствует «大小周»

О режиме «996» (9 утра — 9 вечера, 6 дней) слышали все. В 2021 году Верховный суд КНР признал его незаконным. Победа? Ну, так себе.

На смену пришёл «大小周» (да сяо чжоу), «большая-маленькая неделя»: одну неделю работаешь 6 дней, следующую — 5. По бумагам компромисс, а в жизни «маленькая неделя» часто означает «ты работаешь из дома в субботу, просто без камеры».

Мой обычный день в стартапе в Шэньчжэне (не придумано):

• 9:30 — приходишь в офис. Раньше можно, но на тебя посмотрят странно: «зачем пришёл так рано, хочешь выслужиться?»
• 10:00 — дейли-стендап. Стоя. Буквально. Многие команды собираются у доски стоя, чтобы никто не затягивал
• 12:00-14:00 — обед и «午休» (ушюй, послеобеденный сон). Не шутка. В китайских офисах реально спят после обеда. У кучи разработчиков под столом лежит раскладушка или спальный мешок. В некоторых «дачан» есть отдельные комнаты для сна. Это не лень, а культурная норма тысячелетней давности
• 14:00-18:00 — собственно работа. Самое продуктивное окно
• 18:00-19:00 — бесплатный ужин в офисе. И вот тут ловушка: еда начинается в 18:00, и если ты уходишь до неё — значит, «ушёл рано». Бесплатная еда — якорь, который держит тебя на месте
• 19:00-21:00 — «добровольная» переработка. Кавычки, потому что уходить в 19:00 формально можно, но когда весь опенспейс полон — ты будешь «тем, кто уходит первым». Есть термин «摸鱼» (мо юй, «гладить рыбу») — имитация работы, когда на самом деле сидишь в Douyin
• 21:30 — вызываешь DiDi (китайский Uber) домой. Компания оплачивает такси после 21:00. Ещё один «золотой наручник»

Молодые разработчики всё чаще говорят «躺平» (тан пин, «лежать плашмя»), китайский quiet quitting. Самые радикальные практикуют «摆烂» (бай лань, «гнить на месте») — делать абсолютный минимум. Работодатели в ответ вводят больше метрик. Гонка вооружений, из которой никто не выходит победителем.

Собеседования: вход через ад

В России, насколько я понимаю, на собесе дают задачку на алгоритмы, говорят о проектах и обсуждают паттерны. В Китае всё масштабнее.

Фильтр номер ноль — твой вуз. Китайские университеты делятся на категории «985» (топ-39) и «211» (топ-112). Не из «985» — в ByteDance, Tencent, и подобные «大厂» тебя не позовут даже на скрининг. Как если бы в России без диплома МФТИ тебя не рассматривали вообще, без вариантов. Есть жаргон: «学历查三代» — «проверяем образование на три поколения назад». Смотрят вуз, школу и даже результат гаокао (единый экзамен).

Само интервью:

1. 3-5 раундов по 60-90 минут каждый. Задачи на уровне LeetCode medium-hard, от руки, на доске или в shared editor без автодополнения
2. «Красно-чёрное дерево» как религия. На собесах реально просят реализовать его от руки. Не потому что это нужно на проекте. Потому что «если знаешь — значит, готовился серьёзно». Культурный маркер, а не техническая необходимость
3. Системный дизайн для мидлов и выше. «Спроектируй WeChat» — реальный вопрос, который задают с серьёзным лицом
4. «八股文» (багувэнь, «восьмичленное сочинение») — шуточное название стандартного набора вопросов: HashMap internals, JVM garbage collection, TCP three-way handshake, Redis persistence. Отсылка к экзамену на чиновника в древнем Китае: формализованный ритуал, где важна не глубина понимания, а каноническая форма ответа

Одна деталь, которая шокирует: в Китае на собесе часто спрашивают возраст. После 35 лет найти работу в «дачан» практически нереально. Называется «35岁危机» (кризис 35 лет). Не городская легенда — из-за этого 34-летние сеньоры массово уходят в менеджмент, фриланс или открывают кофейню. Я не шучу про кофейню, это буквально мем и реальность одновременно.

Стек: знакомый, но в параллельной вселенной

Китайские разработчики пишут на тех же языках, но живут в другой экосистеме.

Фронтенд. Vue значительно популярнее React. Создатель Vue Эван Ю — китаец, документация была на мандарине с первого дня, и этого хватило, чтобы Vue стал стандартом. Ant Design и Element Plus — UI-библиотеки по умолчанию. Ещё есть мини-программы (小程序), приложения внутри WeChat, Alipay, Douyin — отдельная платформа с 400+ млн DAU. Для них нужно учить фреймворки вроде Taro или uni-app. Целый мир, о котором за пределами Китая почти не слышали.

Бэкенд. Java — абсолютный король, Spring Boot — стандарт. Но есть нюанс: одна из крупных компаний выпустила свой набор Java-библиотек (Guidelines, Druid, Nacos, Sentinel), который фактически стал стандартом для всей индустрии. Go стремительно растёт, особенно в инфраструктурных командах.

Мобилка — зоопарк. Google Play в Китае не работает. Вместо одного стора — десяток: Huawei AppGallery, Xiaomi Store, Oppo Store, Vivo Store, Tencent MyApp... У каждого свой процесс ревью, свои SDK для пушей, свои специфические баги. Android-разработка в Китае — это тестирование на 20+ устройствах с кастомными прошивками. Если вы думали, что фрагментация Android — это проблема, вы просто не работали на китайском рынке.

ИИ — свой космос. ChatGPT заблокирован. Вместо него — Tongyi Qianwen, ERNIE, GLM, Doubao. Для кодинга — CodeGeeX, Tongyi Lingma. А в марте 2026 весь Китай сошёл с ума от OpenClaw, open-source ИИ-агента, ради настройки которого тысячи людей стояли в очереди у офиса Tencent. Бабушки. Стояли в очереди. Чтобы настроить ИИ-агента. Не технологический прорыв, а культурный тектонический сдвиг.

Вместо GitHub — Gitee. 12+ миллионов разработчиков. Куча хороших open-source проектов живёт только там и никогда не попадёт на Hacker News.

Зарплаты: большие числа, но контекст решает

Примерные зарплаты для Пекина / Шанхая / Шэньчжэня (юаней в месяц, до налогов, 2025-2026):

Джун (1-2 года опыта): 15 000 — 25 000 ¥, это примерно 190 000 — 315 000 ₽. Скорее всего, стартап с «996» в комплекте.

Мидл (3-5 лет): 30 000 — 50 000 ¥ (380 000 — 630 000 ₽). Плюс бонусы, итого 14-16 зарплат в год.

Сеньор (5+ лет): 50 000 — 80 000 ¥ (630 000 — 1 010 000 ₽). Но на горизонте маячит кризис 35 лет, о котором выше.

Архитект / тимлид: 80 000 — 150 000 ¥ (1 010 000 — 1 900 000 ₽). В «дачан» к этому добавляются RSU, которые могут удвоить общий доход.

Звучит жирно, но контекст всё портит. Аренда однушки в приличном районе Шанхая — 7 000-12 000 ¥. Ипотека в Пекине — отдельный жанр ужасов.

Бонусы. В крупных компаниях «базовая» зарплата — только часть дохода. В хороший год могут заплатить 15-18 зарплат, в плохой — 13. Разница для одного разработчика — 100 000+ юаней. И зависит это не только от тебя, а ещё от рейтинга...

Forced Ranking: голодные игры в офисе

Во многих «дачан» используют принудительное ранжирование. Каждый квартал всю команду раскидывают по категориям:

• 3.75+ — «звезда». Повышение, бонус, RSU. Процентов 10 команды
• 3.5 — «хороший солдат». Норма. Большинство
• 3.25 и ниже — «красная зона». Два таких квартала подряд — увольнение

Фишка в том, что если в команде 10 человек и все работали нормально — кто-то всё равно получит 3.25. По квоте. Коллеги превращаются в конкурентов. Для этого есть слово: «内卷» (нэйцзюань, involution) — бессмысленная гиперконкуренция, где все бегут быстрее, но финишная черта отъезжает вместе с тобой.

Нэйцзюань — наверное, главное слово китайского IT в 2020-х. Все перерабатывают не потому, что работы много, а потому что все вокруг перерабатывают. Замкнутый круг.

AI взорвался — и «дачан» сошли с ума

Всё, что выше — это фундамент. Дальше про то, что творится прямо сейчас, потому что ИИ-бум в Китае — это уже не тренд, а землетрясение.

Фронтенд режут. Не сокращают — режут. В начале 2026-го одна крупная e-commerce платформа объявила: фронтенд-отдел упраздняется, все вливаются в «AI-фулстек-команду». Отдельной фронтенд-структуры больше нет. И это не единичная история. По моим знакомым в нескольких «дачан» — чистых фронтенд-вакансий стало процентов на 40 меньше за год. Хотят «фулстека с AI-навыками». Кто не вписался — добро пожаловать на рынок, где таких уже сотни.

Увольнения под соусом «оптимизация через ИИ». Формулировка у всех одинаковая: «AI позволяет маленьким командам делать то, что раньше делали большие». Красиво, пока ты не тот, кого «оптимизировали». Волна прошла по всем крупным конторам на стыке 2025-2026. Причём летят не только джуны. Мидлы, отдельные сеньоры — тоже. В одной компании, где у меня есть знакомые, за квартал вырезали целые направления. На бумаге — «реструктуризация». В курилке все всё понимают.

OPC — новое модное слово. В каждом втором китайском IT-чате сейчас обсуждают «OPC» — One Person Company, «компания из одного человека». Один разработчик + набор ИИ-агентов = полноценная команда. Местные власти уже раздают гранты: в Шэньчжэне до 2 миллионов юаней субсидий, в Шанхае строят целые «OPC-парки». Для корпораций это читается однозначно: «Зачем нам десять человек, если один с Cursor и парой агентов закроет больше половины задач?»

А оставшимся — не легче. Вот что реально злит. Тех, кто пережил сокращения, не похлопали по плечу и не отпустили работать спокойно. На них повесили задачи уволенных коллег. Плюс новая обязанность: «внедряй AI в свой процесс и отчитывайся». В спринтах появились KPI по «AI-утилизации» — какой процент кода написан с помощью ИИ, сколько задач автоматизировано. Не дотянул — минус в рейтинг. В тот самый рейтинг, из-за которого тебя могут выкинуть через квартал.

Сидишь, тянешь работу за троих, параллельно разбираешься с промпт-инжинирингом, а над головой всё тот же forced ranking. Только острее. Потому что теперь рядом с тобой стоит штука, которая не болеет, не просит 16-ю зарплату и не уходит в декрет.

В общем чате один бывший коллега написал: «以前怕被年轻人替代，现在怕被一条prompt替代» — «Раньше боялись, что заменят молодые. Теперь боимся, что заменит промпт».

Вещи, которые существуют только в китайском IT

Раскладушка под столом — часть офисной мебели. В некоторых компаниях выдают стандартные спальные мешки с логотипом. Звучит дико, но после двухчасового 午休 к этому привыкаешь за неделю.

Красные конверты (红包, хунбао). Перед лунным Новым годом начальство раздаёт денежные подарки. Размер зависит от твоего рейтинга. Ещё один повод не попадать в «красную зону».

WeChat = всё. Рабочие чаты, код-ревью, согласование дизайнов, заказ обеда, вызов такси, перевод денег коллеге, оплата в магазине. Представьте, что Telegram, Сбер, Jira и Delivery Club слили в одно приложение. Вот это WeChat.

«Программист-крестьянин» (码农, манун). Так китайские разработчики называют сами себя. Буквально: «кодовый крестьянин». По духу похоже на «тыжпрограммист», только с привкусом горечи.

Внутренние объявления в формате TikTok. В одной из крупных компаний важные решения иногда оформляют как 60-секундные вертикальные видео в рабочем мессенджере. Серьёзные архитектурные решения. В вертикальном видео. Я до сих пор не уверен, как к этому относиться.

Советы тем, кто смотрит на восток

Учите мандарин. Хотя бы базу. Английский в китайском IT знают хуже, чем в русском — это я вам говорю как человек, который видел обе стороны. Даже 你好 и 谢谢 в переписке радикально меняют к вам отношение.

Разберитесь в китайских ИИ-инструментах. DeepSeek, Tongyi, ERNIE — не клоны ChatGPT. У них свои сильные стороны, особенно при работе с китайскоязычными данными.

Готовьтесь к скорости. Китайские заказчики ждут MVP за две недели. «Нам нужно подумать об архитектуре» — фразу, которую не любят слышать.

Не игнорируйте Gitee и китайский open-source. Там попадаются отличные проекты, которые никогда не доберутся до первой страницы Hacker News.

Помните про разницу в коммуникации. «Да» не всегда значит «да». Молчание — не согласие. «Посмотрим» — обычно значит «нет». Это не попытка обмануть, а другая модель общения. К ней нужно просто привыкнуть.

Мой хуамин давно «ушёл на пенсию». Но каждый раз, когда русские коллеги спрашивают «а как в Китае?», я понимаю, что двух миров, которые я знаю, не хватит на один ответ. Если хотите продолжения — пишите в комментариях: разберу найм в конкретных «дачан», расскажу, как OpenClaw меняет фриланс, или объясню, почему в Китае фронтендер после 30 — уже «старик».

Откуда берётся хейт

Ещё год назад в IT набирали всех подряд — рынок рос, люди были нужны срочно, сейчас компании оптимизируют штат и выбирают лучших, но нанимать лучших по-прежнему не получается. И дело здесь не в рекрутерах.

Главная проблема — рассинхрон. Техлид ищет специалиста под конкретную задачу, HR цепляется за стандартный набор навыков из заявки и приводит формально подходящих кандидатов, заказчик всех бракует. Через несколько месяцев берут наименее неподходящего — он не справляется, его увольняют, а цикл повторяется.

Именно из этого и вырастают странные фильтры, отчётность по числу встреч вместо результата и репутация эйчаров как людей, которые ничего не понимают.

Что происходит на стороне нанимателя

Чаще всего рассинхрон возникает из-за недосказанности — привычки работать в своём контуре.

Несоответствие опыту

Нанимающий менеджер пять–семь лет работает в одном отделе, где Python-разработчик по умолчанию сам пишет тесты — для менеджера это базовое требование, очевидное настолько, что он не вносит его в заявку. HR приводит сильных специалистов — менеджер отказывает всем и искренне не понимает, в чём проблема.

Похожая история с зарплатами

Команда работает пять лет, индексации были минимальные. Менеджер ищет сеньора с семилетним опытом на 200 тысяч — потому что столько получает его текущий отдел. На рынке такие специалисты стоят 300–500 тысяч. Менеджер не верит аналитике и предлагает поискать через агентство.

Непонятные критерии

Ещё сложнее ситуации, когда менеджер не может назвать реальные критерии отбора. Он заворачивает кандидатов с идеальными резюме, а HR не понимает что не так. Иногда всё проще: заказчик хочет закрыть позицию конкретным человеком, но сказать об этом открыто не может — и бракует остальных, пока не проведёт нужного. Отдельная история — кривые заявки: менеджер копирует чужую вакансию, название должности и функционал не соответствуют ни рынку, ни реальной задаче. Все ищут одно, а нужно другое.

По опыту рекрутеров, такое происходит примерно в каждом пятом найме. У некоторых заказчиков — в каждом первом.

Почему рекрутер стал детективом

Параллельно с проблемами нанимателей вырос отдельный рынок кандидатов, которые рисуют опыт. В индустрии их называют “волчарами” — по названию движения, где такие практики продают как курсы.

Одни делают это грубо и палятся быстро. Другие готовятся основательно и вскрываются только через несколько месяцев после выхода на работу: первое время им помогает кто-то извне, потом схема разваливается. Для компании это потеря бюджета и времени, для самого кандидата — несколько шагов назад в карьере.

Опытный рекрутер проверяет это через конкретику: спрашивает, какой проект делал кандидат, на каком стеке, как строилась команда, кто был руководителем. Рынок не настолько большой — при желании можно связаться со знакомыми из упомянутой компании и уточнить детали. Ещё один маркер — закрытые чаты, где собираются те, кто покупает схемы накрутки опыта. Присутствие кандидата в таком чате уже становится основанием для отказа, особенно если чат платный.

Отдельная история — кандидаты, которые проходят собеседование с ИИ-суфлёром. Ставят микрофон, включают голосовой ввод и прописывают нейросети промт: “Отвечай за меня на вопросы”. Это видно: у любой модели есть задержка, ответы получаются формально правильными, но без подробностей, когда вопросы идут быстро один за другим в формате блиц-звонка по видео, суфлёр просто не успевает. В западных компаниях уже появился стандартный приём: попросить кандидата ответить на вопрос с закрытыми глазами. Пора наверное тоже попробовать.

Где косячит сам рекрутер

Рекрутеры тоже ошибаются, и чаще всего по банальным причинам.

Самое типичное — формализм. Рекрутер видит резюме, которое закрывает требования по списку, и отправляет кандидата к заказчику без проверки главного: адекватен ли человек вообще. Или наоборот — пытается продать кандидата с пятью годами опыта, когда заказчик просил семь.

Иногда рекрутер слишком верит в кандидата и в скрининге сглаживает острые углы — человек что-то сделал не так, но очень понравился, и в отчёте это замалчивается. Заказчик тратит время, а претензия всё равно прилетает рекрутменту.

Есть и системная проблема: когда горят KPI, рекрутер закрывает глаза на красные флаги и отправляет кандидата дальше — вдруг получится. Не получается, а когда обман вскрывается на финальном этапе, отвечает за это рекрутмент.

Был конкретный случай: рекрутер долго общался с кандидатом. Вроде норм, но решил, что человек слабоват: не горят глаза, не умеет себя продать. Отказали. Через месяц этот же кандидат вышел на эту же должность, но через другое агентство. Оказалось, что наш рекрутер просто не задал уточняющих вопросов по стеку, а кандидат был интровертом и сам не похвастался. Мы потеряли деньги, заказчик потерял месяц времени. А всё потому, что рекрутер решил поиграть в психолога вместо того, чтобы проверить харды.

Сколько стоит не договориться

Банковская оценка стоимости найма одного сотрудника — 500–900 тысяч рублей, для проблемного найма это не отражает реальности.

Механика потерь выглядит так. Внутренние рекрутеры месяц ищут кандидатов — все получают отказ, причины непонятны. Подключают агентство — ещё месяц, результат тот же. Позицию начинают вести несколько рекрутеров параллельно, накапливаются часы на отчёты и перепроверки. Тем временем в команде не хватает рук: спринты растягиваются, копится технический долг. В крайних случаях деньги на автоматизацию уже выделены, людей под неё уже сократили, а разработчиков для внедрения так и не наняли — работу делать некому.

Наём с ошибкой в профиле или в коммуникации занимает в два-три раза больше времени и обходится в три-четыре раза дороже обычного. Если считать потери от простоя бизнеса — суммы становятся совсем другими.

Как это чинится

Самый быстрый способ выйти из тупика — поговорить с заказчиком 15 минут голосом. Переписка растягивается на недели и не передаёт нюансов, разговор вскрывает реальные требования за один звонок.

Для внутренних HR важнее всего выстроить доверие: заказчик не должен воспринимать рекрутера как внутреннего контролёра. Когда доверие есть, заказчик приходит и говорит открыто, что ему нужно — пусть даже это звучит странно. Это всегда лучше, чем молчаливые отказы и угадывание критериев.

Когда причина отказов понятна, проблему можно решать. Иногда за нежеланием рассматривать определённых кандидатов стоит конкретный негативный опыт в прошлом или дискомфорт менеджера, которому неловко руководить более старшим коллегой. Такие вещи разбираются в разговоре за 10 минут.

Бывают и совсем нестандартные ситуации. Был заказчик с иррациональными фильтрами по национальности — молча отклонял кандидатов без объяснений. При этом нужный стек на рынке был сконцентрирован именно среди тех, кого он отклонял. Вышли на разговор, заказчик признал, что это личные установки, не связанные с работой. Читать мораль не стали — перестроили коммуникацию так, чтобы часть отбора проходила через его подчинённых. Работа пошла.

Рекрутер, который разбирается в задаче бизнеса, а не просто показывает резюме — это другой уровень работы. Понять, зачем бизнесу этот человек, какую конкретную проблему он закрывает — и только потом искать.

Centicore Group специализируется на подборе IT-специалистов для продуктовых и аутсорс-команд. Компания работает с позициями любого уровня сложности — от джунов до архитекторов и CTO.

Конференция будет полезна всем, кто работает с ИИ. Владельцам бизнеса и топ-менеджерам — CEO, CIO, CTO, CDO, которые хотят получить измеримый результат от внедрения технологий, а также инженерам, архитекторам и DevOps-специалистам, которым предстоит интегрировать модели в существующую инфраструктуру.

О чем расскажут на конференции

Программа разделена на два параллельных потока, чтобы участники могли выбрать трек под свои интересы и задачи.

Для бизнес-аудитории: окупаемость, риски и стратегия

Спикеры расскажут, как компании принимают решения о внедрении ИИ и переводят проекты из разряда экспериментов в работающие инструменты. Ключевые темы:

• Финансы и риски: сколько реально стоит внедрение ИИ-агентов и с какими подводными камнями можно столкнуться.
• Дорожная карта: как составить роадмап внедрения ИИ на базе платформенных решений, чтобы не потерять деньги и время.
• Управление знаниями: как использовать большие языковые модели, чтобы перестать терять экспертизу внутри компании.
• Масштабирование: как построить агентскую платформу и поставить внедрение ИИ-проектов на поток.
• Хайп или реальность: способен ли вайбкодинг заменить классические инструменты разработки?

Для технических специалистов: железо, код и безопасность

В техническом треке — инженерная реальность и особенности работы с вероятностными системами. Участников ждут доклады про:

• Инфраструктуру: как выбрать серверное железо под разные ИИ-нагрузки и почему инференс классических моделей и LLM — это два разных мира, которые приходится сочетать на одной платформе.
• Разработку: чем SDLC для вероятностных систем отличается от классического и почему «просто написать код» больше недостаточно.
• Безопасность: как обеспечить безопасное использование генеративных технологий в рабочих процессах.

Что еще будет

На площадке конференции развернется технологическая выставка с интерактивными зонами, где можно будет познакомиться с продуктами Selectel и партнерами компании. Для тех, кто не сможет приехать, организуют онлайн-трансляцию.

Участие бесплатное, но нужна регистрация. С подробной программой можно ознакомиться на сайте мероприятия. Количество мест ограничено.

Реклама. Рекламодатель: АО «Селектел» ИНН 7810962785, erid: 2W5zFGwFjd3

Почему студент с искусственным интеллектом, как обезьяна с гранатой? Как обезьяна, случайно оказавшаяся с оружием в руках, студент без глубокого понимания принципов работы искусственного интеллекта может запустить процессы, последствия которых будут непредсказуемы и необратимы.

Главная мысль здесь не в том, что студент «глуп» или «опасен сам по себе», а в том, что мощный инструмент в руках человека без системного понимания превращает ошибку в масштабируемое событие. Если раньше незнание ограничивалось локальной неудачей — неверно решённой задачей, плохим кодом, неработающим проектом, — то с ИИ цена непонимания резко возрастает. Искусственный интеллект способен автоматизировать, ускорять, тиражировать и легитимизировать решения. Поэтому ошибка студента уже не остаётся частной: она может быть встроена в код, в продукт, в учебный процесс, в управленческое решение и потом многократно воспроизводиться, оставаясь внешне «умной» и убедительной.

Ещё глубже этот тезис можно раскрыть через проблему снятия когнитивной ответственности. ИИ удобен тем, что снимает с человека часть интеллектуальной нагрузки. Но вместе с нагрузкой он нередко снимает и привычку сомневаться. Студент начинает не исследовать, а принимать; не проверять, а компилировать; не строить понимание, а собирать правдоподобные ответы.

К сожалению не всем присущ осмысленный подход к применению технологий. Всему виной человеческая лень. Именно она толкает студентов на то, чтобы не разбираться в материале, а пытаться переложить всю работу на алгоритмы. Вместо того чтобы использовать нейросети как инструмент для анализа, проверки гипотез или поиска новых идей, многие начинают превращать его в «костыль», подменяющий собственное мышление.

Непредсказуемость последствий связана не только с техническими сбоями, но и с тем, что студент может не видеть социальных эффектов своих действий: утечки данных, дискриминационных выводов, фабрикации источников, ложных рекомендаций, академического мошенничества, автоматизации вредных практик. То есть речь не о том, что «ИИ плох», а о том, что без культуры ответственности любая умная система становится ускорителем хаоса.

Новый лучший друг каждого студента?

С момента появления искусственного интеллекта в нашей жизни подход ко многим вопросам изменился. Я замечаю, что все реже пользуюсь поиском и все чаще задаю вопросы ChatGPT, все реже выбираю реальную фотосъемку и все чаще создаю новую аватарку в нейросети, все реже читаю длинные статьи от начала до конца и все чаще прошу нейросеть коротко пересказать их суть и выделить главное в формате саммари.Кажется, что я такая не одна, ведь по опросу коммуникационного агентства FAVES Communications, проведённому в октябре 2025 года, почти 52% россиян сегодня ориентируются на ответы искусственного интеллекта при поиске через «Яндекс» и Google, причем 43% признают, что доверяют полученной информации и советам (РБК, Публикация компании FAVES Communications)

Сложно переоценить влияние искусственного интеллекта на нашу жизнь и, конечно, это не могло не оказать воздействия на сферу образования. Сейчас школьники и студенты активно используют искусственный интеллект для своей учёбы. Теперь не нужны ни знания, ни ГДЗ, ни Google, ни Википедия. Чтобы написать доклад или сочинение нужно вбить запрос в нейросеть и сразу получить готовый документ с главами и оформлением по ГОСТ. Не нужно умеет решать примеры, можно сфоткать задачу на листке, вбить её в искусственный интеллект и за секунды получить верный ответ. Современные школьники студенты делают через искусственный интеллект практически всё задания, домашки, доклады, даже пишут курсовые и дипломы.

Конечно, в связи с ростом искусственного интеллекта меняются и появляются технологии и отслеживающие его. Сдать курсовую или диплом полностью сгенерированные нейросетью не так просто. Антиплагиат теперь не только отмечает текст который вы взяли из других источников, но и ставит красный значок на вашей работе, если находятся сгенерированные элементы. За это можно получить наказание в виде незачета или отчисления. Есть только один момент. Каким образом он это определяет пока не ясно и неоднократно были случаи того что этот «чудесный антиплагиат» ставил знак сгенерированного и подозрительного документа даже на полностью написанные человеком тексты.

Меры борьбы с искусственным интеллектом приняли и в Высшей Школы Экономики, где студент может использовать нейросети в своих работах, но ему необходимо оправдать это использование, то есть написать в каких моментах и с какой целью в данной работе был применен искусственный интеллект. А если комиссия или преподаватели посчитают текст за сгенерированным и не увидят объяснение причин, то работу аннулируют и не будут проверять.

Почему университеты вводят такие ограничения? Не потому, что боятся технологий, а потому, что защищают сам смысл образования. Для вуза важно не только то, какой текст сдал студент, но и то, кто именно произвёл мысль, аргументацию и вывод.

Генеративный ИИ разрушает эту прозрачность: работа может выглядеть сильной, хотя реальный вклад автора в неё минимален. Поэтому в ВШЭ запрещают не искусственный интеллект как таковой, а его скрытое использование. Формальное основание — академические нормы университета: ИИ можно применять, но только с обязательным раскрытием, где, как и зачем он использовался. Если же преподаватель видит признаки машинной генерации, а студент этого не указал, работа может быть аннулирована, потому что в глазах университета это уже не технологическая помощь, а нарушение принципа самостоятельности и академической честности.

А есть ли плюсы?

Эксперты подчеркивают, что синергия человека и искусственного интеллекта способна значительно повысить качество как принимаемых решений, так и творческой деятельности. Интеграция современных инструментов в повседневную работу человека может не только оптимизировать процессы принятия решений, но и открыть новые горизонты для решений сложных задач, тем самым увеличивая общую производительность (Redefining Cognitive Domains in the Era of ChatGPT: A Comprehensive Analysis of Artificial Intelligence’s Influence and Future Implications - PMC).

Есть свои плюсы и в сфере образования. При правильном подходе LLM могут стать незаменимыми персональными помощниками и наставниками. В сфере обучения и саморазвития ИИ способен адаптироваться к индивидуальному уровню каждого учащегося, оперативно предоставляя обратную связь и подбирая релевантные материалы, что способствует более эффективному усвоению знаний (AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking)

А что насчет преподавателей?

Искусственный интеллект меняет сферу образования изнутри, меняются все процессы. Нейросети упрощают работу педагогов, избавляют их рутинных задач и бюрократии и оставляют время и ресурс на самое важное — живое взаимодействие с учениками, развитие критического мышления и творческого потенциала каждого ребёнка. Меняется и наполнение занятий, учителя и преподаватели меняют формат уроков и дополняют их интерактивными элементами при помощи нейросетей.

Нейросети действительно могут снимать часть рутины, но не в магическом режиме «нажал кнопку — и школа работает сама». По данным UNESCO, в вузах и образовании ИИ уже используют для подготовки занятий, поддержки оценивания и административных задач; Microsoft и OpenAI в своих материалах для педагогов тоже прямо называют типовые сценарии: черновики планов уроков, квизы, рубрики, варианты обратной связи, адаптацию материалов под разный уровень учеников.

Нейросети упрощают работу педагога не потому, что «учат вместо него», а потому, что берут на себя часть черновой подготовки. Учитель может за несколько минут получить не готовый идеальный продукт, а основу: план урока, варианты заданий для сильных и слабых учеников, тест с ответами, рубрикатор оценивания, шаблон письма родителям, конспект по новой теме или набор интерактивных упражнений. Меняется и само наполнение занятий: вместо одного стандартного объяснения для всех преподаватель может быстро собрать несколько версий материала — короткую, углублённую, игровую, дискуссионную или встроить в урок квиз, кейс, ролевой сценарий или симуляцию.

При этом, большинство образовательных организаций остаются консервативными в вопросах новых технологий и не готовы уступать свои рабочие задачи роботам и искусственному интеллекту.

Риски и опасности

Мой младший брат освоил нейросети раньше, пока учился в школе и страшно представить какое поколение вырастет из них. Его ровесники и он сам вообще перестали делать домашнее задание и задачи на уроках сами. А зачем, если есть искусственный интеллект, который решит все за секунду?

Но вместе с удобством пришла и новая проблема — молодые люди всё меньше напрягают мозг, всё чаще доверяют машине и всё реже испытывают радость собственного открытия. Учителя жалуются, что детям трудно формулировать мысли, обосновывать ответы и рассуждать без цифровой подсказки. Замглавы администрации президента Максим Орешкин отмечает, что традиционные домашние задания для школьников практически утратили смысл из-за развития технологий искусственного интеллекта. Парадокс в том, что искусственный интеллект, созданный для расширения возможностей человека, постепенно лишает его практики мышления, если не научить пользоваться им осознанно и с умом.

У подрастающего поколения навыки самостоятельного решения задач не формируются: дети копируют ответы ИИ для домашних заданий, теряя практику логики и анализа. Без цифровой грамотности они слепо верят моделям, рискуя дезинформацией, а привязанность к виртуальным собеседникам тормозит эмпатию и живое общение.

10 лет назад ГДЗ были в основном складом готовых ответов. Ребёнок брал уже существующее решение, переписывал его и чаще всего оставлял следы: одинаковые формулировки, типовой ход решения, несоответствие своему обычному уровню, привязка к конкретному учебнику или номеру задания. Учитель хотя бы примерно понимал, с чем имеет дело: перед ним списанный ответ.

На уровне мотивации почти ничего не изменилось: и десять лет назад, и сейчас часть школьников хочет не понять материал, а как можно быстрее сдать работу. ИИ — это уже не склад, а машина по производству правдоподобия. Он не просто даёт готовое решение, а подстраивает его под запрос: может переписать другим стилем, упростить, усложнить, сделать «как будто писал восьмиклассник», добавить ошибки, изменить структуру, даже сымитировать рассуждение. То есть если ГДЗ помогали списать, то ИИ помогает скрыть сам факт списывания.

Вполне возможно, что массовое использование ИИ студентами и школьниками — это не столько бунт против учёбы, сколько адаптация к системе неадекватной нагрузки? Когда образование превращается в конвейер дедлайнов, отчётов, презентаций и формальных заданий, ученик начинает оптимизировать не мышление, а выживание. В этом смысле нейросеть становится не источником проблемы, а самым удобным ответом на неё. Она позволяет быстро производить тот объём учебного продукта, который система требует, но не успевает осмыслять. ИИ здесь выступает как зеркало: он показывает, сколько в современном образовании осталось настоящего понимания, а сколько — ритуальной занятости.

Пессимистический прогноз предупреждает, что в течение ближайших десяти лет неконтролируемое и чрезмерное использование LLM может привести к постепенному ослаблению некоторых когнитивных функций у людей. Основной риск – это «когнитивная лень» и утрата навыков вследствие постоянного облегчающего воздействия ИИ, когда человек привыкает получать готовые решения без усилий. Исследователи уже фиксируют тревожные тенденции: чрезмерное доверие результатам, выданным ИИ, способно притуплять критическое восприятие и аналитику, высказывается обеспокоенность по поводу сужения кругозора и творческого мышления.

В начале 2025 года в Media Lab Массачусетского технологического института было проведено исследование, в рамках которого студенты были разделены на три группы и выполняли задание по написанию серии коротких эссе. Первая группа выполняла работу самостоятельно, вторая использовала поисковую систему Google, а третья – языковую модель ChatGPT. В процессе работы проводилась запись электроэнцефалограммы (ЭЭГ) каждого участника.

Анализ данных, полученных на ограниченной выборке, выявил, что участники, использовавшие ChatGPT, продемонстрировали минимальную мозговую активность, наихудшие результаты по лингвистическим и поведенческим показателям, а также выраженную тенденцию к снижению когнитивной нагрузки по мере написания каждого последующего эссе. При повторном выполнении задания без использования искусственного интеллекта, участники демонстрировали ухудшение памяти относительно ранее написанных текстов и снижение активности ритмов, что свидетельствует об ослаблении глубокой памяти.

В противоположность этому, студенты, работавшие без использования искусственного интеллекта, демонстрировали повышенную нейронную активность и удовлетворение от процесса. У них наблюдалась активация областей головного мозга, отвечающих за творческое мышление, процессы запоминания и семантическую обработку информации.

У третьей группы лиц было зафиксировано формирование так называемого когнитивного долга – накопившегося дефицита глубокого обучения, который негативно влияет на способность к критическому анализу и повышает восприимчивость к манипуляциям и поддающимся стереотипным убеждениям.

Получается, что большинство новых технологий направлены на, чтобы сделать нашу жизнь проще, но из-за этого мы становимся ленивее и страдает наш мозг, творческое мышление и когнитивные функции.

Этические и правовые аспекты

Технологии уже радикально меняют учебный процесс, а вот нормы, правила и культура обращения с ними заметно отстают. С одной стороны, искусственный интеллект обещает персонализированное обучение, снижение нагрузки на преподавателей и расширение доступа к качественному контенту, с другой — обостряет старые проблемы академической честности, неравенства и защиты данных и параллельно рождает новые типы злоупотреблений, вроде «делегирования» всего процесса обучения машине.

Особое внимание следует уделить академической добросовестности и набирающей обороты тенденции «цифрового плагиата». Работы, созданные с использованием генеративных моделей, формально представляются уникальными, однако они не отражают ни трудозатрат, ни глубокого понимания автора, что обесценивает саму концепцию оценивания как способа проверки усвоения учебного материала. В ответ на это образовательные учреждения принимают различные меры: от прямых запретов и попыток обнаружения текстов, созданных искусственным интеллектом, до более продуманного подхода, при котором использование нейросетей интегрируется в учебные задания как допустимый инструмент, а критерием оценки становится не сам факт применения ИИ, а уровень критического осмысления и личный вклад обучающегося.

Правовое регулирование в данной сфере пока носит фрагментарный характер, особенно в Российской Федерации. Специального законодательства, которое бы целенаправленно регулировало использование ИИ именно в образовании, в настоящее время не существует. Поэтому применяются существующие правовые нормы: Федеральный закон «Об образовании», законодательство о персональных данных, нормы об авторском праве и отдельные нормативные акты, связанные с национальной стратегией развития искусственного интеллекта до 2030 года.

Это приводит к тому, что многие виды деятельности фактически подпадают под действие законодательства (например, сбор и анализ учебной статистики платформами ИИ или генерация учебных материалов), однако участники образовательного процесса не в полной мере осознают свои права и обязанности, особенно в случаях ошибок, допущенных алгоритмами, или утечек конфиденциальных данных.

На стыке этических и правовых аспектов постепенно формируется ключевая идея: нейросети не упраздняют роль преподавателя и обучающегося, а значительно повышают ответственность за использование технологий. Если рассматривать ИИ исключительно как инструмент для ускорения текущих процессов, система образования рискует усугубить существующие недостатки и несправедливости, просто в более автоматизированном и менее явном формате.

Вывод

В фокусе всей дискуссии об искусственном интеллекте в образовании — не технологии, а человек и качество обучения. Нейросети одновременно усиливают лучшие практики (персонализацию, доступность, автоматизацию рутины) и обостряют слабые места системы — неравенство, академическую нечестность, зависимость от готовых ответов и уязвимость персональных данных.

По моему мнению важно использовать искусственный интеллект с умом, не подменять им свое мышление, а использовать как новый ресурс, который помогает мыслить и обучаться быстрее. Было бы ошибкой впадать и в крайности и демонизировать инструмент. Калькулятор не убил математику, а поисковые системы не уничтожили исследовательское мышление. Искусственный интеллект — это ресурс, и, как любой ресурс, он усиливает то, что уже есть. Если есть мышление — он ускоряет его. Если мышления нет — он маскирует его отсутствие, причём временно. Настоящий вызов не в том, чтобы запретить студентам пользоваться ИИ или разрешить без ограничений. Вызов в том, чтобы научить работать с ним так, как работает хороший специалист: задавать правильные вопросы, проверять ответы, спорить с машиной, а не слепо ей доверять. Не отдавать мышление на аутсорс, а использовать новый инструмент для того, чтобы мыслить глубже и быстрее.

Главный вывод: искусственный интеллект в школе и вузе должен работать как инструмент развития мышления, а не как сервис по обходу усилий и ответственности. Главное, что надо понять — использовать новые технологии нужно осознанно, использовать искусственный интеллект, как помощник, а не замену собственным мозгам.

Почему штат стал дорогим

Реальная стоимость штатного разработчика — это зарплата, увеличенная в 2–3 раза. Зависит от компании и включает в себя налоги, страховые взносы, ДМС, HR, офис и административную нагрузку. Backend-разработчик с зарплатой 220 000 ₽ обходится компании примерно в 565 000 ₽ в месяц. Заморозка проекта на два месяца — это 1,1 млн рублей на «пустых» зарплатах, ошибка найма — ещё 3–6 зарплатных циклов на повторный поиск.

В последние пару лет выросла фискальная нагрузка: часть льготных тарифов страховых взносов для МСБ отменяется, ставка поднимается с 15% до 30% в части зарплат выше МРОТ. Каждый следующий разработчик в штате дорожает по регуляторным причинам.

Отдельный вопрос — скорость. Закрытие вакансии middle-разработчика занимает в среднем 58 дней, senior — 73 дня (с учетом отработки на предыдущем месте). При этом каждый третий кандидат отказывается от оффера на этапе согласования: нашел предложение лучше, не сошлись по зарплате или формату работы. Через внешнего партнёра готовый специалист появляется за 24–72 часа, и если не подошёл, заменить его можно без процедур трудового кодекса.

Какие модели пришли на замену

Специалист в аренду. Компания привлекает конкретного разработчика через партнёра. Формально он в штате партнёра, фактически работает под управлением заказчика. Скорость старта — 24–72 часа. Оптимально, когда нужно быстро закрыть нишевую специализацию: 1С, iOS, DevOps. Минус — нет командной синергии, вовлечённость ниже штатной.

Выделенная команда. Партнёр формирует полноценную команду под проект, на нём административная нагрузка, команда работает как штатная. В среднем такое сотрудничество длится около полутора лет. Пример: e-commerce перед праздниками добавил команду на четыре месяца — мобилки, backend, QA, тимлид, — а после сезона сократил до поддержки.

Крупные финтех-компании идут дальше, в том числе передают целые направления мобильной разработки, от проектирования архитектуры до поддержки после релиза. Партнёр несёт ответственность за конечный продукт, а не за отдельные задачи по ТЗ.

Технологический консалтинг. Партнёр анализирует потребности бизнеса, предлагает стек и методологию, строит процессы, интегрирует свою команду с внутренней и передаёт знания. Такие запросы актуальны для крупного бизнеса, где простая аренда ресурсов не покрывает масштаб задач.

Гибридная модель. Ядро — штатные специалисты: архитекторы, тимлиды, ключевые разработчики; расширение под пики и проекты за счёт внешней команды. Опять же хорошо подходит для больших компаний, и уже активно реализуется на рынке.

Как строить карьеру с учётом этих моделей

Советы, которые помогут адаптироваться вне зависимости от выбора карьерного пути

Считайте бизнес-ценность, а не технологии. Не «Я знаю React», а «Я сократил время загрузки страниц, что дало +3% конверсии». В штате и в выделенной команде одинаково ценят тех, кто влияет на метрики.

Разберитесь в экономике моделей. Если вы middle или senior — вы можете работать в штате, в выделенной команде, через технологический консалтинг или в гибридной схеме. У каждого формата своя экономика: разная ставка, разные условия, разные переговорные позиции. Изучите партнёров тех компаний, в которые вы хотели бы попасть.

Стройте публичный след между проектами. В штатной работе вас знают коллеги. В проектной занятости каждый контракт начинается с нуля, поэтому GitHub-портфолио, статьи и выступления становятся способом отличиться и доказать свою экспертизу.

Осваивайте то, что пересекается с вашим стеком. Рынок смещается к гибридным ролям: backend-разработчик с пониманием DevOps, аналитик с навыком автоматизации. Чистая специализация уступает пересечению компетенций.

Чего ждать

Объём штатного найма продолжит уменьшаться, этот год принесёт новые реструктуризации и сокращения в IT-отделах. Одновременно провайдеры выделенных команд и специалистов ожидают роста доходов на 19–24% в ближайшие три года.

Есть мнение, что ИИ ускоряет этот сдвиг, и нейросети позволяют на 30–50% сократить бюджет на типовых IT-позициях. Тот же объём задач закрывается меньшим количеством людей более высокого грейда. Спрос смещается туда, где автоматизация пока буксует: архитекторы, DevOps, ML-инженеры, специалисты по безопасности.

Рынок взрослеет и со стороны провайдеров: агентства начинают конкурировать не только зарплатой, но и условиями — соцпакет, обучение, менторинг становятся нормой, а не исключением.

Мы в Centicore Group выстраиваем выделенные центры компетенций, где специалисты работают как часть продуктовой команды заказчика. Если вы хотите работать над интересными проектами в среде, где ценят экспертизу, — посмотрите наши открытые позиции.