Хабравчане, всех рада приветствовать! Меня зовут Акманова Елизавета, я ведущий аналитик ГК «Юзтех». В своих статьях я стараюсь затрагивать темы, которые считаю важными, и обязательно с опорой на личный практический опыт.

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

ДИСКЛЕЙМЕР

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

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

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

Привет, Хабр! Я Наталья Самсонова, фулстек-аналитик в ГК «Юзтех». Последнее время работаю пресейл-аналитиком в продуктовой команде. Несколько десятков встреч с клиентами в этом качестве позволили мне заметить значительную разницу в целеполагании заказчиков в проектах заказной и продуктовой разработки. О чем конкретно речь и почему это важно при выборе интеграционной платформы — рассказываю в статье.

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

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

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

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

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

Привет, Хабр! Я Розанна, работаю в ГК «Юзтех» ведущим сетевым инженером безопасности. В этой статье поделюсь примером переноса конфигураций NGFW Palo Alto на UserGate. Статья будет полезна  сетевым инженерам и администраторам NGFW, ИТ-архитектором и руководителям проектов, а  также системным интеграторам.

В этой статье разберем как перенести конфигурацию с ПАК Palo Alto ПАК 3020 версии 9.1.16-h3 на UserGate D500 версии 7.2.0.76784R, учитывая различия в архитектуре, механизмах политики безопасности и подходах к управлению трафиком.  

Хабр, всем привет! С вами Лиза Акманова, ведущий аналитик ГК «Юзтех».

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

Привет, Хабр! Меня зовут Виктор Прусаков, я ведущий разработчик в команде DSML в ГК Юзтех и уже четыре года занимаюсь data science. Эта статья написана по мотивам моего выступления на AIConf и посвящена системе машинного зрения, способной распознавать наличие СИЗ, опасные действия и перемещение персонала в зонах риска. Модульная архитектура с гибким ядром обеспечивает быструю кастомизацию решения под производственные задачи, что критично для реализации концепции нулевого травматизма.

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

Агентный ИИ: от чат-ботов к автономным системам

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

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

Две архитектурные траектории:

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

Тренды — это про то, как изменится работа с архитектурой и безопасностью в ближайшие годы, как трансформируются подходы к разработке и само мышление инженеров.тМы попросили экспертов ГК «Юзтех» поделиться своим взглядом на ИТ-тренды 2026 года.

3… 2… 1 — поехали. Ждём горячее обсуждение в комментариях.

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

Для организации волшебной сказки для детей и взрослых команда Деда Мороза готовится целый год. Круглый год главный волшебник получает письма с заветными желаниями, к декабрю можно насчитать уже миллиарды запросов на подарки. Наш Дед Мороз «идет в ногу» с современными технологиями, поэтому у него есть секретные ИТ‑системы для автоматизации волшебных процессов, построенных на магическом open source‑коктейле, включающем заморского оленя Рудольфа — Apache NiFi, с отечественными patch‑подковами и упряжкой компонентов ручной работы талантливых мастеров.

Центр управления новогодним волшебством «хо‑хо»

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

Всем привет! Я Игорь Голиков, ведущий разработчик ГК “Юзтех”.  В данной статье хочу рассказать о метриках памяти в VMware vCenter, в том числе как получить скрытые метрики. 

Статья может быть полезна SRE/DevOps и администраторам VMware vCenter, заинтересованным в получении «гостевых метрик» виртуальных машин, тем, кто хочет обосновать снижение выделенной виртуальным машинам памяти и сократить расходы без риска для производительности.

На одном из наших проектов возникла необходимость отслеживать использование памяти в гостевой ОС на виртуальных машинах под управлением VMware vCetner и формировать рекомендации по увеличению/уменьшению памяти выделенной виртуальной машине (rightsizing). Стандартные метрики памяти, доступные через vSphere Web Services API, не позволяют оценить объём памяти, используемой гостевой ОС.

Метрика (производительности) — это количественный показатель, который отражает состояние или поведение системы во времени (CPU, память, диск, сеть и т.д.).

Задача: найти метрику, показывающую объем памяти, потребляемой гостевой ОС и процессами в Linux системах с установленными Guest Tools.

Требования к метрике:

Привет, Хабр! На связи Евгений Аверьянов, директор интеграционной платформы USEBUS AI-Code. В первой статье мы разобрали, почему попытки собрать шину из подручных средств или жить по сценарию интеграций «точка–точка» — это путь к росту затрат, хаосу и зависимости от уникальных специалистов. В этой статье мы разберем практический интеграционный кейс одного крупного вертикально-интегрированного холдинга, какой путь мы вместе проделали и каких результатов достигли.

Поехали!

Привет! Меня зовут Елена Поплоухина. Я отвечаю за развитие сообщества тестировщиков в ГК “Юзтех”. В этой статье я расскажу, как нам удается на протяжении нескольких лет поддерживать вовлеченность участников комьюнити.

Приветствую Хабр! Меня зовут Наталья Самсонова, я — системный аналитик с большим опытом работы на пресейлах. Успех оценочной (пресейловой) стадии проекта зависит от глубины понимания болей бизнеса и выявления соответствующей проблемной зоны в ИТ‑ландшафте компании. В статье мы поговорим о связях бизнес‑идей и ИТ‑основы для них, причинах взаимного влияния и совместного развития.

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

Согласно исследованию McKinsey, 70% инициатив в области цифровой трансформации терпят неудачу. Одной из ключевых причин является неверный архитектурный подход (источник). 

Архитектурные проблемы могут выражаться по-разному, например:

Коллеги, привет! Я, Акманова Елизавета, ведущий аналитик ГК Юзтех, продолжаю делиться своим опытом в проекте, связанным с распиливанием монолита на микросервисы микрофронты. В первой части мы подробнее познакомились с данной концепцией и теперь понимаем ее сильные и слабые стороны. В текущей части посмотрим на алгоритм перехода от одной архитектуры к другой. Вперед! 

Привет, Хабр!

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

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

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

Поехали!

Привет, Хабр! На связи Евгений Аверьянов, директор продукта USEBUS AI-Code в ГК «Юзтех». За годы работы в интеграциях я видел, как компании, начиная с небольших стартапов, проходят по всем кругам интеграционного ада — от «велосипедов» и «костылей» до «самопальных» платформ. В этой статье разберёмся, какие бывают подходы к интеграции, где скрываются боли компаний, и почему современному бизнесу важно не изобретать десятиколёсный монстр‑велосипед, а строить прозрачный ИТ‑ландшафт на понятных, масштабируемых и главное централизованно-управляемых решениях.

Разбираемся вместе, поехали!

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

Всем привет, с вами Анастасия Жилкина, системный аналитик ГК Юзтех. На данный момент работаю в команде, которая занимается реализацией и развитием онлайн-оплат на сайте. В этой статье хочу рассказать о процессе ревью документации, который мы внедрили в команде, и о том, какие ощутимые плюсы это дало как в качестве итоговых решений, так и в командной работе в целом.

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

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

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

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

Функции и возможности

MidJourney:

Меня зовут Роман Ремизов. Я — системный аналитик ГК Юзтех. В рамках цикла статей «Хроники архитектурного дизайна» я делюсь своей экспертизой о разных автоматизированных банковских системах (АБС) и о том, что нужно знать перед тем, как приступить к архитектурному дизайну.

Данная статья, как и другие статьи этого цикла (первая статья доступна по следующей ссылке: [ссылка на статью Хроники архитектурного дизайна (Часть 1)]; вторая статья доступна по следующе ссылке: [ссылка на статью Хроники архитектурного дизайна (Часть 2)]; третья статья доступна по следующе ссылке: [ссылка на статью Хроники архитектурного дизайна (Часть 3)]), написана с допустимым уровнем конкретики и соблюдением NDA. Напомню: все банки разные и на других проектах могут преобладать иные как архитектурные, так и программные решения.

В этой статье мы обсудим работу с транзакциями на примере использования PostgreSQL.

Привет! Меня зовут Нина Полторакова, я ведущий специалист по тестированию в ГК «Юзтех». 

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

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

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

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

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