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

Меня зовут Илья Петров, я руковожу продуктом Digital Q.Sensor BI в «Диасофт». За последний год я неоднократно слышал одну и ту же фразу от разных команд — и своих, и клиентских: «нам бы сюда буквально пару графиков». И каждый раз внутри у меня загорается тревожная лампочка, потому что я примерно знаю, чем это заканчивается.

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

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

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

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

Мы в Диасофт развиваем Digital Q.Sensor BI — промышленную BI‑платформу, в которую команда продукта встраивает мультиагентные ИИ‑системы. И поэтому хорошо понимаем, почему вокруг AI‑native аналитики сегодня столько споров.

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

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

Кстати, тех, кто дочитает статью до конца, ждет бонус.

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

На связи Илья Виссарионов, директор департамента «Аппаратно‑системная платформа» компании «Диасофт».
 
Про DevSecOps написаны тонны текстов, но почти все они – про инструменты: какой SAST выбрать, куда «воткнуть» Trivy, как подружить сканеры с GitLab. Реальная проблема 2026 года в другом. Сканеры давно стоят на всех стадиях пайплайна, базы уязвимостей обновляются ежедневно, а криты все равно доезжают до заказчика. Проблема сместилась в другую плоскость: как приоритизировать, чинить и ретестить находки, когда у тебя 2000+ развертываний в день и больше сотни команд. Проще говоря – как управлять security-долгом на конвейере.

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

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

Но по мере роста инфраструктуры Kafka перестает быть просто брокером. От нее начинают зависеть функциональность микросервисов, интеграции, тестовые стенды, CI/CD‑процессы и рабочие системы. Вместе с нагрузкой растет и список вопросов: как обновлять кластеры, отслеживать очереди, устранять уязвимости и восстанавливать работу после отказа.

Меня зовут Илья Виссарионов, я директор департамента «Аппаратно‑системная платформа» компании «Диасофт», и в этой статье расскажу, как мы используем Kafka в DevOps‑инфраструктуре «Диасофта», какие проблемы обнаружили при эксплуатации под высокой нагрузкой и почему в итоге стали рассматривать брокер сообщений не как отдельный open‑source‑компонент, а как полноценную инфраструктурную платформу.

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

Меня зовут Жуйков Андрей, занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

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

В этой статье я покажу, как установить Digital Q.DataBase 18.2 на РЕД ОС 8.0.3, познакомлю с новой архитектурой СУБД и продемонстрирую подключение к каждому из поддерживаемых диалектов.

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

Я Сергей Рощупкин, занимаюсь развитием платформы управления серверами приложений Digital Q.AppServer в «Диасофт». В статье разберу реальный кейс миграции с Oracle WebLogic в крупном банке, покажу, как устроена платформа и где в ней работают ИИ‑агенты, а в конце — практические советы инженерам, которые мы сформулировали по итогам проектов.

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

Я Михаил Кулаков, в «Диасофт» занимаюсь развитием импортонезависимой платформы распределенных реестров Digital Q.Blockchain.

Про закон «О цифровых валютах и цифровых правах» написано уже достаточно, и подробных разборов по статьям хватает. Ограничусь рамкой: закон вступает в силу 1 сентября 2026 года, требования к предотвращению операций без добровольного согласия клиента – годом позже, и на финансовом рынке появляется новый профессиональный участник. Цифровой депозитарий ведет учет цифровых валют и цифровых прав по цифровым счетам и предоставляет доступ к адресам-идентификаторам, а работать в этом статусе можно только после включения в соответствующий реестр Банка России.

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

Переход крупных корпоративных систем на отечественные СУБД остается одной из наиболее актуальных задач последних лет. Однако основная сложность подобных проектов заключается не столько в переносе данных, сколько в сохранении работоспособности существующих приложений, написанных под Microsoft SQL Server и Oracle Database.

Именно поэтому развитие Digital Q.DataBase сосредоточено сразу на нескольких направлениях: расширении совместимости с зарубежными СУБД, автоматизации миграции и создании инструментов, позволяющих минимизировать объем ручной доработки приложений.

Версия 18.2 стала одним из наиболее масштабных обновлений платформы. В релиз вошли изменения архитектуры продукта, значительное развитие совместимости с Microsoft SQL Server и Oracle Database, новые возможности мастера миграции, первая версия службы построения отчётов, совместимой с SQL Server Reporting Services, а также десятки других улучшений.

Подробнее об изменениях - в этой статье.

Мы в Диасофт несколько лет назад начали строить Digital Q.DevOps — внутренний конвейер сборки, тестирования, доставки и развёртывания, — и сейчас через него проходит больше 2000 развёртываний в сутки. На прошлой неделе собрали внутренний митап с разработчиками, тестировщиками и DevOps-инженерами, чтобы честно разобрать, что в продукте получилось, что до сих пор болит, и куда мы движемся.

Что важнее при выборе СУБД: выручка разработчика или реальные возможности продукта?

На российском рынке долгое время ответ фактически сводился к рейтингам продаж. Но ситуация постепенно меняется. Исследование ЛАНИТ стало одной из первых попыток сравнить отечественные СУБД не по финансовым показателям, а по техническим характеристикам — от совместимости и миграции до безопасности и администрирования.

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

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

Меня зовут Жуйков Андрей, в Диасофт я занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

Импортозамещение СУБД перешло из разряда регуляторных требований в практическую плоскость: компаниям нужно менять платформы без остановки бизнеса. Типичная проблема — огромная экосистема вокруг MS SQL, PostgreSQL или Oracle с тысячами процедур, отчетов и интеграций. Ручной перенос такого объема (например, 900 тысяч строк кода) занимает месяцы и несет риски, при этом даже автоматизация не исключает доработок.

Даже с автоматизированными средствами конвертации большинство проектов миграции СУБД требует доработок и тестирования, поэтому ключевым требованием становится сохранение существующей логики приложений. Digital Q.DataBase решает эту задачу через воспроизведение функциональности популярных СУБД и поддержку их диалектов SQL, что позволяет переносить системы быстрее без масштабной переработки прикладного слоя.

В новой версии Digital Q.DataBase существенно переработана архитектура продукта. Вместо единого монолитного решения СУБД получила независимые модули, воспроизводящие функциональность PostgreSQL, Microsoft SQL Server и Oracle Database. Это упрощает установку, сопровождение и обновление системы, а также позволяет использовать только те компоненты, которые действительно необходимы в конкретном проекте.

В этой статье покажу, как установить Digital Q.DataBase 18.2 на Astra Linux 1.8, познакомлю с новой архитектурой продукта и продемонстрирую подключение к каждому из поддерживаемых диалектов.

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

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

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

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

Это Андрей Ловлин, руководитель команды «Фабрика данных. Платформа» компании Диасофт. В предыдущей статье мы рассказывали про S3 Архипелаг – слой хранения для нашей «Фабрики данных» (Digital Q.DataFactory). Сегодня речь пойдет о другой задаче: построение конвейера интеллектуального распознавания документов, загружаемых в нашу «Фабрику данных».

PDF-файлы, сканы, фотографии договоров – все это накапливается в организациях годами. Для построения RAG-систем и работы с LLM эти данные необходимо извлечь из неструктурированных документов и преобразовать в структурированный формат. Задача, на первый взгляд, тривиальная. На практике – не совсем.

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

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

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

На связи Илья Шуйков, руководитель продукта «Фабрика данных» компании Диасофт.

В прошлой статье мы рассказали, зачем понадобилось строить свое объектное хранилище, и как устроен S3 Архипелаг изнутри. Теперь — практика: берем дистрибутив и разворачиваем рабочее хранилище.

Разрозненные ИТ-системы остаются одной из причин, почему бизнес-процессы буксуют: CRM не получает данные из ERP, внешние сервисы падают из-за несогласованных форматов, а интеграции превращаются в долгий ручной труд. Чем больше систем, сервисов и данных использует компания, тем важнее иметь управляемый интеграционный слой, который помогает бизнесу развиваться без хаоса в обмене данными. Связать системы в единую управляемую архитектуру помогают интеграционные платформы — например, Digital Q.Integration.

Собрали главные новости платформы за последнее время.

Обычно разговор об аналитике в HR начинается с благих пожеланий: «Давайте оцифруем компетенции», «Построим дашборд удовлетворенности». Заканчивается это часто стандартно: выгрузкой Excel‑таблиц из ЗУПа, ручным копированием резюме из Outlook в папку «Кандидаты — зима — 2025(финальная версия)2» и бесконечными правками.

В этой статье мы посмотрим на HR‑данные как на продукт: со своей архитектурой, контрактами и ответственными за результат. Поговорим о том, как построить пайплайн, который в реальном времени показывает не абстрактную статистику, а реальную динамику бизнес‑процессов.

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

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

Помните, как вы внедряли Jira, Asana или Trello? Казалось, что это и есть цифровая зрелость: задачи поставлены, коммуникация прозрачна, все удобно.

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

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

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