Привет, я Данила Трусов, директор продукта «Инферит ИТМен».
Хочу рассказать, как мы в буквальном смысле переписали три года разработки за восемь месяцев — и почему этот переход оказался не просто технологическим апгрейдом, а шагом к полной независимости продукта.
Почему вообще пришлось все переписывать
До 2022 года наши агенты для системы инвентаризации «Инферит ИТМен» прекрасно себя чувствовали в экосистеме .NET. Они стабильно решали задачи учета ИТ-активов и хорошо работали у заказчиков. Но в какой-то момент все изменилось: заказчики, особенно из госсектора, начали требовать максимальной технологической прозрачности и импортонезависимости.
Формально наш стек был рабочим, но с точки зрения инфраструктуры возникли сложности:
в закрытых контурах нужно было вручную устанавливать дополнительные библиотеки runtime;
некоторые российские дистрибутивы Linux просто не поддерживали нужные пакеты;
даже если нужные зависимости были, в изолированных сетях служба ИБ не разрешала устанавливать сторонние библиотеки.
В какой-то момент стало ясно: зависимость от внешней среды — это уже не просто неудобство, а стратегический риск. Нам был нужен полностью автономный агент, который можно запустить где угодно — без внешних SDK, библиотек и подключений к репозиториям.
Почему выбрали C++
Мы рассматривали разные варианты, но в итоге сделали ставку на C++. Причина простая — нам нужна была нативность и автономность.
C++ позволил значительно сократить количество внешних зависимостей и сделать работу агента более предсказуемой в разных окружениях. Для заказчиков с закрытыми контурами это критично: агент можно поставить и запустить без необходимости тянуть за собой тяжелые пакеты или дополнительное окружение.
Кроме того, C++ дал контроль над производительностью. В .NET часть поведения «спрятана» внутри фреймворка, а здесь все на виду: память, процессы, потоки, ресурсы. Мы смогли буквально выжать максимум из железа и убрать избыточное потребление ресурсов.
Восемь месяцев против трех лет
Когда приняли решение о переходе, началось самое интересное. Нужно было переписать три года кода за восемь месяцев. Параллельно шла разработка нового веб-интерфейса на React — вместо старого десктопного WPF.
Над проектом работали три человека: архитектор, ранее отвечавший за .NET-разработку, и два новых инженера на C++. Несмотря на минимальные ресурсы, мы успели в срок.
Секрет был в трех вещах:
готовая архитектура — модульность и иерархия агентов остались с прошлой версии;
накопленный опыт — мы уже знали, где «узкие места», и не повторяли старые ошибки;
рациональный компромисс — выбрали C++14, чтобы сохранить совместимость со старыми системами, которые до сих пор живут в корпоративных сетях.
Главные вызовы и как мы их прошли
Переписать код было полдела. Сложности начались в интеграции и инфраструктуре.
1. Безопасность и архитектура передачи данных
В закрытых контурах категорически запрещены запросы сверху вниз. Сервер не может обращаться к агентам напрямую — только принимать данные от них. Мы полностью переделали логику взаимодействия: теперь данные идут только снизу вверх. Агенты сами собирают и отправляют информацию, сервер ничего не «дергает».
Также добавили буферизацию и пакетирование, чтобы снизить нагрузку на сеть. В результате сеть не перегружена, а система стала устойчивее к сбоям.
2. Разнообразие рабочих сред
У заказчиков встречаются и современные ОС, и очень старые версии Windows и Linux.
Чтобы все это работало, агент должен быть максимально автономным в части окружения и не должен опираться на внешние библиотеки, которые могут отсутствовать в закрытых инфраструктурах. Мы добились этого за счет сокращения зависимостей и расширенной кроссплатформенной поддержки.
Проверку совместимости проводим с помощью набора тестов, которые можно запускать прямо у клиента.
Дополнительные плюсы
В обновленной системе, помимо прочего, есть несколько приятных бонусов:
устойчивость к сетевым сбоям — данные не теряются, если связь временно пропадает;
в разы меньше трафика — благодаря пакетированию и новой модели обмена;
упрощенное развертывание — теперь не требуется подтягивать тяжелые внешние компоненты, и агент легче устанавливать в изолированных средах;
гибкая модель данных — можно добавлять новые типы собираемых объектов без обновления агентов.
В итоге продукт стал лучше приспособлен к изолированным и смешанным инфраструктурам, где вместе живут разные ОС и конфигурации.
Что изменилось в результате
После перехода на C++ агент стал работать заметно быстрее и экономнее. В некоторых сценариях прирост производительности превысил 40% за счет оптимизации алгоритмов сбора и обработки данных.
Отказ от внешних библиотек позволил нам в три раза расширить список поддерживаемых ОС. Сейчас «Инферит ИТМен» работает на Windows (от 7 до Server 2022) и Linux — включая «МСВСфера», Astra Linux (от 1.7), Debian 9+, Ubuntu 18.10+, CentOS 7, Oracle Linux 8.3, Red Hat 7.4 и 8, SUSE 15.5+.
Первый крупный кейс
Одним из первых заказчиков обновленного «Инферит ИТМен» стала промышленная компания с десятками тысяч рабочих станций. Новая версия агента обработала 10 миллионов файлов в 30 раз быстрее, чем прежняя, и помогла собрать единую базу достоверных данных об ИТ-активах.
Кроме ускорения, заказчик получил сокращение нагрузки на администраторов и рост точности планирования закупок, потому что теперь данные обновляются автоматически и без ручных сборов.
Выводы
Этот проект стал для нас отличным уроком. Мы поняли, что при смене технологического стека важно не только «на что перейти», но и зачем.
Теперь мы стараемся держать баланс между инновациями, стабильностью и совместимостью.
Переход на C++ дал нам больше, чем просто новый язык. Мы стали быстрее, гибче и независимее, а еще доказали, что даже радикальные технологические развороты возможны в короткие сроки, если понимать, куда идешь.
P.S. Сейчас мы продолжаем развивать продукт, усиливаем аналитику и возможности для корпоративных клиентов. Но самое важное уже сделано — мы создали действительно независимую платформу, которая не боится ни импортозамещения, ни ограничений по инфраструктуре.
Комментарии (51)
martein
25.11.2025 06:09Читать статью нужно так: "Рынок нашего ПО схлопнулся, мы побежали в госуху, а там Astra Linux, никаких смузи-технологий, только то, что есть в гос.реестре, и мы побежали даже не на mono, а на плюсы. Аналогов нет, нам не больно бороться с плюсами, даже стали быстрее ходить на работу и веселее отлаживать наше ПО. Ничего не бойтесь, тут не страшно, не больно, всё импортозаместим, чемодан нам никто не заносил за статью. Покупайте нашу прогу для инвентаризации. Всем пока."
dantrusov10 Автор
25.11.2025 06:09Вы правильно уловили основной драйвер этого решения: смена рынка диктует смену технологий. Когда основной заказчик - госсектор, приходится играть по его правилам, а его правила - это реестр ПО, старые ОС и требования ИБ.
Siemargl
25.11.2025 06:09Кто будет поддерживать целое mono?
А еще и сертифицировать для госсектора...
eao197
25.11.2025 06:09Оно понятно, что когда родина прикажет, то и голой ж... на ежа сядешь. Но использовать С++14 в 2025-ом -- это больно. Хорошо хоть, что не С++98.
dantrusov10 Автор
25.11.2025 06:09Да, C++14 в 2025м - действительно компромисс, на который пришлось пойти из-за реалий корпоративных IT. В закрытых контурах до сих пор живут CentOS 7, старые версии Astra Linux и им подобные. C++14 - это тот максимум, который нативно можно запустить на всем этом зоопарке. Если бы взяли C++17/20, мы бы сами себе отрезали часть целевой аудитории.
eao197
25.11.2025 06:09Это все понятно. Комментарий, скорее, был вызван тем, что я бы лично сейчас на проект с C++ ниже 17-го стандарта пошел бы только если бы совсем нечего есть было бы.
Да, я понимаю, что бывают реалии когда выше С++14 не прыгнешь, но это проблемы владельцев бизнеса, а вот зачем программистам сейчас тратить свое время на старье... Вот это вопрос.
Siemargl
25.11.2025 06:09А чего такого нужного Вам в реальности добавили в С++17 ?
Я например, довольствовался бы тоже 14. Меня это все && с массой перегрузок больше раздражают избыточностью.
eao197
25.11.2025 06:09Из того, что сразу вспоминается: structured binding, if constexper, fold expression.
Удобно, что optional и variant сразу в stdlib, не нужно ничего стороннего тянуть. К variant-у в комплекте std::visit с трюком overloaded, за неимением паттерн-матчинга в языке хотя бы это.Ну и если заниматься eDSL-ем в рамках C++, то CTAD оказывается очень в тему.
Siemargl
25.11.2025 06:09Я соглашусь лишь с половиной.
С одной стороны - да, удобно.
С другой - надо развивать навык смотреть сквозь синтаксический сахар и понимать, где просто сахар, а где небесплатная абстракция.
Ну и многие нововведения приводят к сложно читаемому коду. Тот же CTAD вообще не очевиден (прекрасно дополняет SFINAE, ха =). Но это уже ближе к теме про новые стандарты....
eao197
25.11.2025 06:09Я соглашусь лишь с половиной.
Мне сейчас заплакать или возрадоваться?
Кто-то в Интернете что-то сказал о навыках, которые нужно развивать. Алилуйя.
Только вот почему ваши слова должны значить больше чем слово из трех букв, написанных кем-то на заборе, решительно непонятно.
habr_skatilsa
25.11.2025 06:09Да ты со всеми неадекватно общаешься походу, откуда такое чсв? Увиденное в блоге лысое нечто не похоже на царька
kekekeks
25.11.2025 06:09Вы бы это. Собрали бы себе свежую libc++ и линковали статически. А не занимались вот этим вот всем. Или у вас в числе целевых платформ скрепный процессор без нормального компилятора?
CatAssa
25.11.2025 06:09А мне понравился настрой статьи. Ушли от .NET монстра на божественные С++.
Я сейчас нечто подобное делаю: переписываю некоторые наши сервисы для работы под Astra/Red и т.п. Вообще, переделка полезна сама по себе - позволяет поправить колченогость прежней архитектуры и что-то соптимизировать. Ну и я просто люблю С++ :).
pavlushk0
25.11.2025 06:09"Кроме того, C++ дал контроль над производительностью. В .NET часть поведения «спрятана» внутри фреймворка, а здесь все на виду: память, процессы, потоки, ресурсы. Мы смогли буквально выжать максимум из железа и убрать избыточное потребление ресурсов." - вот так вот взяли, вжух, и всё завелось?
CatAssa
25.11.2025 06:09Наверняка были известны очевидные косяки прежней системы, которые "просто убирали".
eao197
25.11.2025 06:09вот так вот взяли, вжух, и всё завелось?
А в чем вы видите проблему?
Более интересно они с нуля все писали или брали какие-то готовые библиотеки (вроде POCO или Boost-а).
dantrusov10 Автор
25.11.2025 06:09Отличное замечание! Был не "вжух", а восемь месяцев тотального контроля над каждой мелочью, который обернулся не только плюсами, но и огромной головной болью.
Могу сказать иначе, С++ дал нам возможность взять под контроль производительность, но одновременно заставил это делать. В .NET GC, runtime и стандартная библиотека делают за тебя огромный пласт работы, часто с небольшим оверхедом, но стабильно. В C++ мы получили полную власть, а с ней и полную ответственность.
Вместо "скрытого" поведения .NET мы получили:
Свои баги в управлении памятью, которые сами же и отлавливали.
Необходимость вручную вылизывать работу с потоками и сетевыми соединениями, чтобы не было утечек и дедлоков.
Недели профайлинга и оптимизации низкоуровневых алгоритмов, чтобы добиться этих 40%.
Так что да, вы абсолютно правы, это был не магический "вжух", а долгая, кропотливая и часто нервная инженерная работа.
Kerman
--SelfContained и у вас нет внешних зависимостей. -p:PublishAot=true - и у вас на выходе бинарник как в плюсах.
dotnet add package Avaloniaи у вас кроссплатформенный UI с синтаксисом WPF, с поддержкой Native AOT и работающий на любом линуксе, где есть гуй.Guid0Fawkes
Вот тоже не понял. Именно эта часть показалась несколько притянутой за уши.
Пока выглядит так, что в процессе переезда попутно поправили какие-то ранние косяки. Ну, и просто сам по себе С++ будет производительней С#.
Kerman
А зачем складской программе быстродействие c++?
Шарп тоже компилируемый язык и даже весьма оптимизированный. Вот зачем в складской программе +20% (в лучшем случае) производительности гуя, если там всё равно в базу данных упрётся? Ну серьёзно?
А кто-нибудь подумал, за счёт чего эта производительность достигается? Вот эти все UB и отсутствие bound-check да, дают небольшой прирост. За счёт, внезапно UB и out-of-bound. Наслаждайтесь выбором, называется.
grumegargler
Ниже уже ответили на вопрос "зачем". Но на другой ноте, хотелось бы высказать мысль, что в эпоху развития ИИ, разница во времени на разработку между языками с управляемой памятью и нет, уже не кажется такой уж пропастью. Перечисленные нюансы (ub, bound-check) и до этого решались при помощи анализаторов, а с учётом, что сегодня ИИ неплохо готовит тесты, помогает в рутине и выполняет довольно сложный рефакторинг, то преимущество в скорости разработки на управляемых языках, достигаемое за счёт некоторого падения в производительности, уже не кажется таким большим. Всё-таки не стоит забывать, что c++ это пожалуй один из немногих популярных языков, где поддерживаются практически все современные парадигмы программирования, и при этом - он компилируемый. Такими свойствами, управляемые языки не обладают, и если предположить, что в будущем, значимую часть кода всё-таки будут писать агенты, то почему бы не писать на языке с приятным бонусом.
dantrusov10 Автор
Отличные комментарии, спасибо! Вы и Guid0Fawkes оба правы, и давайте разделим два этих момента.
Про .NET AOT и Avalonia — да, это мощная технология. Но на старте нашего перехода (2022-2023) Native AOT в .NET 7 был еще сыроват для продакшена в закрытых контурах. Главное же, что даже AOT-сборка содержит Runtime, а это вызывало вопросы у служб безопасности. Нативный бинарник на C++ с минимумом зависимостей был для них прозрачнее и проще для аудита.
А теперь про ваше главное замечание. Да, вы на 100% правы: значительную часть производительности и надежности мы получили не «магией C++», а за счет тотального рефакторинга.
Когда переписываешь систему с нуля, ты неизбежно:
Исправляешь «косяки архитектуры»: Старая система росла эволюционно, с накоплением технического долга. Новая изначально затачивалась под новые требования (только снизу-вверх, буферизация и т.д.).
Упрощаешь логику: вместо общих решений на вырост делаешь конкретные и эффективные под известные задачи.
Избавляешься от legacy: выкидываешь код, который когда-то был нужен для совместимости, но давно устарел.
Если переформулировать, могу сказать, что мы использовали переход на C++ как возможность полностью переосмыслить архитектуру и выкинуть весь технический долг. Сам язык дал нам контроль, но главный выигрыш — это исправление старых ошибок и новая, более эффективная архитектура, которую было бы больнее реализовывать поверх старого .NET-кода.
Kerman
Конечно содержит. А сборка на плюсах не содержит?
Получаешь кучу неотловленных багов. Предыдущая система писалась 3 года и я думаю, что все три года она обкатывалась. У вас за 8 месяцев сделан только функционал, без обкатки.
А ещё вы этим стеком неизбежно добавили все вот эти приколы плюсов вроде мемликов, UB и прочих out-of-range. Это прямо целый пласт ошибок, которых в шарпе просто нет в силу его management природы.
Я ни в чём не собираюсь вас убеждать. Просто наслаждайтесь выбором.
Kelbon
нет
Kerman
а stdlib чем вам не рантайм?
Kelbon
во-первых стд либа обычно шаред, то есть не в бинаре. Во вторых всё же есть разница между memcpy/malloc и виртуальной машиной и jit компилятором
Kerman
Рантайм шарпа тоже шаред, если не селфконтейнить и не компилить в нейтив. Здесь уже вам самим выбирать, поставлять вашу версию с дистрибом или требовать её наличие на целевой машине. Другими способами эта дилема не решается.
Во вторых, в дотнете нет виртуальной машины. jit-компилятор есть, он используется, если не комплировалось с native aot. А дальше работает скомпилированный машинный код. Без виртуализации. Без ограниченной среды. Рантайм дальше это уже просто набор библиотек.