Создатель Sphinx — о 25 годах в инженерии, провале бизнес-модели и жизни внутри Авито
Новый выпуск подкаста AviTalk — разговор с Андреем Аксёновым, автором поискового движка Sphinx и руководителем группы инфраструктуры поиска в Авито.
Sphinx появился в 2001 году — тогда Андрей хотел просто сделать поиск по сайту с текстами песен, а готовых решений не было. Движок оказался лучше того, что было на рынке, и в итоге превратился в один из самых известных open source-проектов российского IT, который лёг в основу поиска Авито.
Но путь от хобби-проекта до инфраструктурного продукта оказался куда менее романтичным, чем принято рассказывать на конференциях.
В выпуске: почему сильная технология сама по себе не бизнес, как Sphinx врос в Авито, что значит 25 лет работать над одним проектом — и какие ошибки Андрей признаёт как руководитель.
Ведёт выпуск Виктор Раев, руководитель разработки юнита Services Base.
Приходите на вебинар — покажем, как построить потоковый конвейер данных с латентностью в минуты
Батчевый ETL раз в сутки перестает справляться, когда бизнесу нужна аналитика в режиме, близком к реальному времени. Как перейти на потоковую обработку без лишней сложности в инфраструктуре?
Разберем это на вебинаре по Evolution Data Platform. Будет полезно дата-инженерам, которые проектируют конвейеры, аналитикам и BI-специалистам, которым важно работать с актуальными данными, а еще архитекторам и руководителям дата-отделов.
На вебинаре расскажем и покажем:
как проектировать архитектуру конвейера под near real-time: когда брать микробатчинг в Managed Spark Streaming, а когда хватит классического батча;
зачем нужен Managed Trino как единый слой запросов поверх «горячих» и «холодных» данных — и как это убирает дублирование логики;
как партиционировать данные по времени в Object Storage, чтобы запросы не тормозили;
как управлять схемой через Managed Metastore, когда структура потока меняется;
как настроить дашборд в Managed BI с автообновлением и алертами на отклонения;
как измерять латентность конвейера — от генерации события до появления на дашборде.
На практической части соберем реальный сценарий: оконная агрегация транзакций в Managed Spark Streaming, оркестрация через Managed Airflow, витрина в Object Storage, ad-hoc запросы через Managed Trino без копирования данных, дашборд с обновлением раз в две минуты.
📅 Когда? 21 мая в 11:00 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикеру в прямом эфире.
Когда требований много, а ясности мало: 10 уроков для аналитиков
У системного и бизнес‑аналитика часто ломается не один навык, а весь маршрут: бизнес формулирует задачу через боль, разработка ждёт точных сценариев, стейкхолдеры спорят о приоритетах, а требования распадаются на противоречивые документы, схемы и комментарии в тасках.
Собрали 10 открытых уроков, которые помогают пройти этот путь по порядку: от понимания бизнес‑задачи до процессов, объектной модели, архитектурного языка и согласования решений.
Подборка подойдёт бизнес‑аналитикам, системным аналитикам, продактам, тимлидам и всем, кто работает с требованиями, процессами, интеграциями и постановкой задач для разработки.
1. Сначала понять бизнес‑модель
Если не ясно, как продукт создаёт ценность, требования быстро превращаются в список пожеланий.
21 мая, 20:00 — «Формирование бизнес‑модели продукта на примере Business Model Canvas». Записаться
2. Проверить проблему через пользователей
Кастдев помогает отличать реальную потребность от мнения самого громкого стейкхолдера.
3 июня, 19:00 — «Про кастдевы с интерактивом / исследование потребителей в теории и на практике». Записаться
3. Описать процессы и требования визуально
Чтобы бизнес, аналитик и команда смотрели на одну картину, а не спорили о терминах.
14 мая, 18:00 — «Графическое описание бизнес‑процессов и требований». Записаться
4. Разобрать AS IS и TO BE
Полезно, когда нужно не просто «автоматизировать», а понять, где хаос, где контроль и что именно должно измениться.
3 июня, 20:00 — «AS IS хаос или TO BE контроль: как построить единую автоматизированную финансовую модель на основе неидеальных, разрозненных данных». Записаться
5. Найти, где создаётся ценность
Value Stream помогает увидеть, какие этапы процесса действительно важны, а какие только тормозят движение задачи.
Чтобы сущности, статусы, связи и правила не расползались в процессе разработки.
2 июня, 20:00 — «Объектная модель без боли: как превратить хаос требований в стройную архитектуру». Записаться
8. Говорить с разработкой и бизнесом на одном языке
C4 помогает показывать систему на нужном уровне детализации: без лишней абстракции и без перегруза техническими деталями.
4 июня, 20:00 — «C4 для системного аналитика: строим единый язык между бизнесом и разработкой». Записаться
9. Вовлекать стейкхолдеров
Даже сильное решение может застрять, если заказчик, пользователи и команда по‑разному понимают цель.
17 июня, 20:00 — «Заказчик vs Стейкхолдер: как вовлечь бизнес в проект». Записаться
10. Связать аналитику с эффектом для бизнеса
Хорошая аналитика должна влиять на скорость, прозрачность, качество и деньги, а не только на документацию.
4 июня, 20:00 — «Операционная эффективность в IT: как находить скрытую прибыль в процессах разработки». Записаться
Если вы только входите в анализ — начните с бизнес‑модели, процессов и требований. Если уже ставите задачи разработке — выбирайте Sequence Diagram, объектную модель и C4. Если работаете с изменениями и согласованиями — смотрите уроки про стейкхолдеров, AS IS / TO BE, цепочки ценности и операционную эффективность.
P. S. А если нужен не разовый урок, а полноценный маршрут развития, загляните в каталог курсов OTUS по аналитике и анализу: там собраны программы по системному и бизнес‑анализу, работе с требованиями, процессами и данными.
Говорят, что ближе к лету активность найма в ИТ-отрасли ослабевает. Но только не в SSP SOFT.
Про нас как работодателя: компания SSP SOFT работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. По размеру компании — мы «средний бизнес» с числом сотрудников около 500 человек, и с проектами федерального уровня.
Рабочие места у нас в московском офисе, который открылся в 2025 году в ЦАО у самой Красной площади. А еще бывают вакансии в департамент разработки в Томске и почти всегда на «удаленку» из любой точки России.
Работа в SSP SOFT — это сложные и интересные проекты, поддерживающая атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента.
Горячие вакансии мая (больше 10 позиций в Москве): 1️⃣ Бизнес аналитика 2️⃣ Дата Инженера 3️⃣ Системного аналитика 4️⃣ Automation QA Engineer (Java) (инженера по автоматизации тестирования, язык Java) (на остальные вакансии см. ссылку ниже, перейдя на ХХ-ру)
Что предоставляет кадровая политика SSP SOFT: ✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины. ✅ Центр компетенций и личное наставничество ускорят развитие до максимума. ✅ Офис, гибрид или «удаленка» ? Есть все варианты. ✅ Время — ваш ресурс. Мы его уважаем.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС руководителю службы найма (или на почту job@ssp-soft.com). Не забудьте добавить «секретную фразу» в сопроводительное письмо: «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀
Почему биткоин-миксеры вообще появились и почему вокруг них столько споров
Одна из самых популярных иллюзий о Bitcoin – это “анонимная криптовалюта”. На практике Bitcoin скорее наоборот: это один из самых прозрачных финансовых инструментов. Все транзакции навсегда остаются в публичном блокчейне, а история движения средств, связи между адресами и сами переводы могут анализироваться годами спустя. Именно из-за этой прозрачности вообще появились биткоин-миксеры.
Если сильно упростить, миксер - это механизм, который пытается разорвать очевидную связь между отправителем и получателем средств. Пользователь отправляет монеты, они смешиваются с другими транзакциями, а затем выводятся уже через другие адреса и в другой последовательности. Главная идея здесь не “спрятать Bitcoin”, а усложнить отслеживание происхождения конкретных монет и финансовой истории пользователя.
Когда Bitcoin начал становиться популярнее, многие быстро поняли одну неприятную особенность публичного блокчейна: если адрес оказался связан с личностью, дальше уже можно анализировать баланс, историю операций, связи между кошельками и движение средств. Для части пользователей это стало вопросом не криминала, а обычной финансовой приватности. Никому не хочется, чтобы любой сервис, контрагент или случайный человек мог видеть всю историю операций по одному адресу.
Проблема в том, что инструменты приватности быстро начали использовать не только обычные пользователи. Миксеры стали активно применять скамеры, ransomware-группы, взломщики и схемы по отмыванию средств. Именно здесь и начался главный конфликт вокруг подобных сервисов. С одной стороны, приватность - нормальный запрос для любой финансовой системы. С другой - те же инструменты оказались удобны для сокрытия происхождения украденных средств. История с Tornado Cash только усилила этот спор и превратила его уже не просто в крипто-дискуссию, а в глобальный вопрос о границе между приватностью и контролем.
По сути, биткоин-миксеры стали прямым следствием самой архитектуры публичного блокчейна. Bitcoin создавался как децентрализованная система без центрального контроля, но одновременно оказался слишком прозрачным для мира, где финансовая приватность всё ещё остаётся важной. И именно поэтому вокруг миксеров до сих пор столько споров, как и внутри криптоиндустрии, так и далеко за её пределами.
Почему стейблкоинов так много и чем они отличаются
Стейблкоин - это не просто «цифровой доллар». Это общий термин для разных моделей токенов, которые пытаются держать стабильную цену, но делают это разными способами. Поэтому стейблкоинов много: у каждого свой механизм, свои риски и свой сценарий применения.
Самый понятный тип это фиатно-обеспеченные стейблкоины. Они привязаны к обычной валюте, чаще всего к доллару. Примеры: USDT, USDC, TUSD, USDP. Их плюс простая логика, высокая ликвидность, удобство для переводов и торговли. Минус - приходится доверять эмитенту и его резервам.
Есть криптообеспеченные стейблкоины. Классический пример - DAI, но сейчас важно учитывать, что его экосистема постепенно мигрирует в USDS. Такие модели интересны тем, что они ближе к DeFi и меньше зависят от банковской системы, но зато сложнее устроены и сильнее зависят от состояния залога и рыночной ликвидности.
Есть товарно-обеспеченные стейблкоины, например PAXG и XAUT. Они привязаны не к доллару, а к золоту. Такой формат подходит тем, кто хочет держать в токене не валюту, а реальный актив.
Отдельная категория - это алгоритмические стейблкоины: FRAX, AMPL, sUSD. Их цена удерживается не резервами в классическом смысле, а через алгоритмы, стимулы и автоматическую балансировку. Это самая рискованная и спорная модель, потому что при потере доверия ломается и сама стабильность.
Именно поэтому стейблкоинов так много: они решают разные задачи. Одни нужны для платежей и трейдинга, другие для DeFi, третьи для хранения стоимости, четвертые как эксперимент с новой денежной архитектурой.
Если совсем коротко: все стейблкоины выглядят одинаково снаружи, но внутри это разные механизмы - фиат, крипта, товар или алгоритм.
Как выбрать безопасный криптообменник: краткий чек-лист без иллюзий
Когда пользователи ищут обменник, чаще всего смотрят на курс. Если цифра выглядит лучше - значит “выгодно”. Проблема в том, что безопасность почти никогда не видна на первом экране. И именно поэтому ошибки чаще происходят не после обмена, а в момент выбора.
Ниже краткий чек-лист, который помогает отсеять рискованные варианты ещё до первой операции.
1. Прозрачность условий
Если итоговая сумма становится понятна только в процессе или “после подтверждения”, это плохой сигнал. В нормальном сценарии пользователь заранее понимает, сколько спишется и сколько придёт.
2. Предсказуемость курса
Важно не только число на экране, а то, фиксируется ли курс и в какой момент. Если итог может “поплыть” без понятных правил, то это уже зона риска.
3. Комиссии и скрытые потери
Даже при хорошем курсе итог может ухудшаться за счет комиссии сети, внутренней комиссии сервиса или спреда. Сравнивать нужно не витрину, а результат.
4. Скорость и тип обработки
Автоматическая обработка и понятные статусы - нормальный сценарий. Если процесс завязан на ручные действия и “ожидание оператора”, появляется дополнительная неопределенность.
5. Поведение интерфейса
Странные редиректы, неожиданные шаги, изменение условий по ходу оформления - всё это чаще сигнал не про дизайн, а про риск.
6. Требования по ходу процесса
Если дополнительные проверки или ограничения появляются внезапно на финальном шаге, это ломает сценарий и повышает вероятность проблем.
7. Лимиты и ограничения
Несовпадение суммы с правилами сервиса - частая причина ситуаций “деньги отправлены, но не зачислены”. Эти вещи лучше проверять до, а не после.
8. Отзывы и агрегаторы
Отзывы могут помочь, но сами по себе ничего не гарантируют. У любого популярного сервиса будут и положительные, и негативные оценки. Проблема в том, что пользователь чаще смотрит на среднюю оценку, а не на детали. При этом гораздо полезнее обращать внимание не на “5 из 5”, а на повторяющиеся сценарии в отзывах: задержки, изменение условий по ходу обмена, проблемы с зачислением или поддержкой. Если одни и те же жалобы встречаются регулярно, это уже не случайность, а паттерн.
9. История сервиса и цифровой след
Полезно посмотреть, как сервис выглядел раньше и как менялся со временем. Если сайт появился недавно, часто меняет формат работы или почти не имеет истории - это дополнительный фактор риска.
Социальные сети, форумы могут дать дополнительные ответы, но сами по себе не являются гарантией надежности. Важно не наличие просто присутствия для галочки, а насколько регулярно обновляется информация, есть ли последовательность в коммуникации и нет ли явных разрывов в истории проекта, а если есть то какая была этому причина.
10. Риск транзакции и предварительная проверка
В некоторых случаях до перевода имеет смысл проверить адрес или транзакцию на риск, особенно если речь идёт о незнакомой стороне или крупной сумме. Это не гарантирует полной безопасности, но позволяет заранее увидеть потенциальные проблемы, которые могут повлиять на дальнейшую обработку средств.
11. Поддержка и реакция
Важно не наличие чата, а то, как быстро и по делу отвечают. Это становится критичным, если что-то пошло не по плану.
12. Тестовый прогон
Если сервис новый или сумма чувствительная, небольшая тестовая операция почти всегда дешевле, чем разбираться с последствиями. Если упростить, безопасный обмен - это не тот, где “лучший курс”, а тот, где весь процесс предсказуем: от ввода суммы до финального зачисления.
И наоборот: чем больше в сценарии сюрпризов, тем выше шанс, что проблема возникнет не в блокчейне, а ещё до него.
Присоединяйся к офлайн-митапу MWS для системных аналитиков 🎙️
На встрече вместе с экспертами из МТС Web Services и Orion soft поговорим про тренды в системном анализе, актуальные вызовы профессии и опыт внедрения ИИ.
В ходе дискуссии обсудим:
Как развивается роль системных аналитиков и ждет ли нас трансформация профессии?
Что нужно понимать системному аналитику при внедрении ИИ в архитектуру решений.
Какую рутину уже можно отдать ИИ, а где результат все еще нужно внимательно проверять руками?
📅 Когда: 14 мая (четверг) в 18:00 по мск
📍 Где: офлайн в офисе МТС в Москве (м. Технопарк) + онлайн-трансляция.
👉 Количество офлайн-мест ограничено, успевай зарегистрироваться, чтобы пообщаться с экспертами вживую.
Почему цена почти доходит до TP, но разворачивается
Будущее это вероятностная функция от прошлого. ATR это чистая функция от прошлого. Разница в том, что в вероятностной функции есть коэфициент случайности и точно прогнозировать можно только лучший и худший случай
Именно по этому цена не доходит до TP, если высчитать его на индикаторах. Либо TP слишком низкий и не окупает fees. Верным решением для вероятностной функции будет прогнозировать лучший и худший случай на лету
//@version=5
strategy("Стратегия с TP по ATR")
...
tpPrice = entryPrice + atrMultTP * atr // Это не работает
Выходить из позиции при просадке PNL на заранее известный процент статистически предсказуемо.
listenActivePing(async ({ symbol, data }) => {
const peakProfitDistance = await getPositionHighestProfitDistancePnlPercentage(symbol);
const currentProfit = await getPositionPnlPercent(symbol);
if (currentProfit < 0) {
return;
}
if (peakProfitDistance < TRAILING_TAKE) {
return;
}
await commitClosePending(symbol, {
id: "unknown",
note: str.newline(
"# Позиция закрыта по trailing take",
),
});
});
Тут есть разница: в отличие от классического trailing take где выход из позиции ставится на цену, которая каждый раз разная, отклонение PnL - постоянная величина
Что проверять перед любым крипто-переводом: короткий anti-fail чеклист
Большая часть проблем с крипто-переводами возникает не из-за “сложности блокчейна”, а из-за слишком бытовых ошибок.
Не ту сеть выбрали. Скопировали адрес, но не сверили хвост. Забыли про memo/tag. Отправили “впритык”, а после комиссии сумма стала ниже минимального порога. Итог всегда один: деньги вроде бы отправлены, но дальше начинается нервный квест. Парадокс в том, что большинство таких ошибок можно поймать за 30–60 секунд до отправки.
Ниже короткий anti-fail чеклист, который реально стоит прогонять перед любым крипто-переводом, особенно если сервис новый, сумма чувствительная или вы работаете в спешке.
Первое: сеть.
USDT в ERC-20, TRC-20, BEP-20 и других сетях визуально выглядит как “тот же USDT”, но на практике это разные маршруты. Ошибка здесь одна из самых дорогих и самых частых.
Второе: адрес.
Недостаточно просто вставить адрес в поле. Стоит хотя бы сверить первые и последние символы. Ошибки буфера, подмена адреса вредоносным ПО и банальная спешка - классика.
Третье: связка “актив + сеть”.
Многие проверяют только монету или только сеть. Но ошибка часто возникает именно в комбинации: актив может быть правильный, а маршрут нет.
Четвёртое: комиссия и итоговая сумма.
Если перевод идёт “впритык”, комиссия может сделать сумму ниже минимального порога зачисления. На экране кажется, что всё ок, а по факту деньги зависают или требуют ручной разбор.
Пятое: минимальная сумма зачисления.
Во многих сервисах маленький перевод технически доходит в сеть, но не зачисляется автоматически. Пользователь видит успешную транзакцию и не понимает, почему баланс не пополнился.
Шестое: memo, tag или дополнительный идентификатор.
Для некоторых активов одного адреса недостаточно. Если пропустить это поле, перевод может пройти в сеть, но не привязаться к аккаунту без ручной поддержки.
Седьмое: тестовый перевод.
Самый скучный совет, но самый дешёвый. Если сервис новый, сеть непривычная или сумма ощутимая, то сначала лучше отправить небольшую часть, а уже потом основную сумму.
Если упростить всё до одной мысли, то крипто-перевод это не место, где стоит доверять автопилоту. Одна минута проверки почти всегда дешевле, чем потом разбираться, куда “ушли” деньги и почему они не дошли туда, куда должны были.
Недавно залип на тему рынков предсказаний где люди ставят на исход событий, а в итоге получается некое “коллективное мнение” в цифрах.
Сначала относился скептически, но потом задумался: если человек рискует деньгами (или хотя бы чем-то), он ведь будет думать чуть внимательнее, чем просто “мне кажется”.
Посмотрел ради интереса разные платформы, включая одну под названием Globet Market и там довольно наглядно видно, как меняется вероятность событий со временем.
Иногда это выглядит логично, а иногда как чистая реакция толпы.
И вот не понимаю до конца: это реально более точный способ оценки или просто красиво оформленная версия “угадайки”?
Представьте, что вы 20-летний попаданец-инженер в 1970-й год.
Место "попадания" - по вашему выбору. Можно, например, в Fairchild Semiconductor. То есть паспорт у вас есть, язык вы знаете и даже рабочее место на момент попадания за вами есть.
По правилам, ставки на спорт (моментальные выигрыши, лёгкий вывод денег и т.д.) делать нельзя, как и играть на бирже или курсе валют. Плюс, у вас нет полного стека технологий в голове, кроме того, что есть прямо сейчас, при чтении этих строк. Но вы примерно представляете грядущую конъюнктуру.
Как бы вы провели следующие 50 лет, если задаться целью к 2020 году стать самым богатым бизнесменом в сфере электроники и/или IT-технологий?
Если вы были в эфире (или после просмотра записи) — пожалуйста, заполните анкету обратной связи. Это позволит подготовить для вас другие интересные и полезные мероприятия: https://forms.gle/juvvvxPQEoVMZuz37
Инструментов на базе ИИ и сценариев их использования с каждым днем становится все больше. Поэтому легко запутаться, где ИИ действительно ускоряет работу, и как вообще использовать его так, чтобы получать нужный результат, а не набор разрозненных фактов.
Часто вопрос не в самих инструментах, а в том, как их применять в конкретных задачах. Если смотреть шире, ИИ может помочь увидеть слабые места в процессах, найти точки роста и повлиять на эффективность бизнеса.
Мы поговорили с Полиной, бизнес-аналитиком в команде Скорозвон, и задали ей несколько вопросов: где ИИ полезен на практике, какие результаты удалось получить и какие инструменты стоит попробовать.
1️⃣ Где ИИ помогает в работе аналитика?
Чаще всего — в рутине. По данным исследований, до 60% времени аналитик тратит на задачи вроде создания отчетных документов, генерации гипотез и промптов, анализа больших данных и проведения исследований.
Это как раз те вещи, которые можно частично или полностью поручить ИИ: он может собирать и структурировать данные, помогать с гипотезами, создавать черновики документов.
При этом ИИ — это не просто «нажал на кнопку и получил результат». Он ускоряет работу, но все равно результат нужно проверять и дорабатывать.
2️⃣ Где ИИ уже приносил заметный результат в вашей команде?
Один из ярких кейсов — анализ диалогов в колл-центре. Робот успешно находил «теплых» лидов, но конверсия в покупку оставалась низкой.
Мы подключили анализ диалогов с помощью LLM и выяснили, что корректно работали только около 7% операторов.
Ошибки у них были довольно базовые, но их сложно заметить без детальной аналитики:
не знали о звонках робота
сбрасывали звонки клиентов или вызывали негатив
повторно проводили идентификацию
работали с плохим оборудованием
LLM помог быстро проанализировать большой объем диалогов и собрать это в понятную аналитику.
3️⃣ Что изменилось после этого?
После таких изменений корректность работы операторов выросла до 90%. Плюс мы закрыли скрытое ожидание клиента — он хотел качественную аналитику, а не только цифры.
А еще:
итоговая конверсия увеличилась примерно в 1,5 раза
выручка по проекту выросла в 2 раза
С точки зрения личной эффективности я теперь экономлю до 20 часов в месяц на прослушке диалогов и могу анализировать до 100диалогов в час.
То, что раньше требовало большой команды или долгой ручной работы, сейчас можно сделать гораздо быстрее.
4️⃣ Какие задачи еще можно отдать ИИ в работе аналитика?
Помимо анализа данных:
подготовка презентаций
написание текстов
проведение исследований
сбор и структурирование данных
оформление документации
Это не заменяет аналитика, но сильно упрощает старт и ускоряет процесс.
5️⃣ Какие инструменты тебе показались полезными?
Из того, что я использовала в работе:
GigaChat — хорошо справляется с исследованиями на российском рынке
SkyWork.ai и Gamma — помогают быстро собрать презентацию и структуру доклада
НейроЭксперт — удобно работать с файлами и базой знаний
Ассистенты для генерации промптов от Naumen — чтобы не просто перефразировать промпт, а уточнить задачу через вопросы и сделать его точнее
Кастомные агенты с использование Claude Code — чтобы автоматизировать процесс и сократить ручную работу
6️⃣ Есть ли риски или ограничения, о которых важно помнить?
Да, и об этом часто забывают. Перед использованием данных важно:
уточнять у клиента, что является конфиденциальной информацией
обезличивать данные
проверять результаты
ИИ может сильно ускорить работу, но ответственность за итог все равно остается на аналитике.
5 человек, 1 300 дашбордов, 2 200 пользователей в месяц. Как не сойти с ума
В Уралсибе self-service BI вышел на масштаб, который сложно представить: 12 000 датасетов, 200+ разработчиков в разных бизнес-блоках, 1 000 потоков данных обновляются каждый день. И всё это поддерживает команда из пяти человек.
При таком масштабе неизбежно появляются дубли, забытые дашборды, сломанные компоненты, разработчики, которые не знают о существовании друг друга, и пользователи, которые всё ещё спрашивают «а зачем BI, если есть Excel?».
Как с этим справляться? Семён Юников расскажет про систему, которую они выстроили: автоматические рассылки разработчикам с рекомендациями по их же объектам, кастомный каталог дашбордов с ИИ-поиском, геймифицированный марафон на 80 разработчиков, после которого количество сломанных компонентов сократилось вдвое. И да, заставки на корпоративных ноутбуках с надписью «Ты ещё в Excel? Переходи в FineBI» тоже часть стратегии.
Когда у тебя 50 отчётовв FineReport, 100+ дашбордов в FineBI, и никто не знает, откуда берутся данные
Знакомая история: дашборды живут своей жизнью, новый сотрудник открывает отчёт и не понимает, что значит «ТО 5 руб.», а когда что-то ломается, полдня уходит на то, чтобы пройти по цепочке ETL и найти, где именно.
В Галамарте решили это системно: подключили дата-каталог DataHub к продуктам FanRuan. Как именно это сделали, какие стены пришлось пробить и чего не нашлось ни в одной документации, расскажет Дмитрий Конюхов на FineDay Online.
Что получили на выходе:
— бизнес-глоссарий, где каждый термин привязан к формуле, источнику и конкретным дашбордам
— lineage от витрины до сырых данных — в одном окне, за пределами FanRuan
— возможность за секунды найти, в каких из 100+ дашбордов используется нужнаяметрика
— базу для self-service: аналитики переиспользуют существующие датасеты вместо создания новых
Встраивание вычислений в PostgreSQL: PL*, extensions, а теперь и WASM
В рамках выступления на PG BootCamp Russia 2026 Дмитрий Дорофеев, главный конструктор Luxms, рассказал о том, как сегодня развивается встраивание вычислений в PostgreSQL: от классических процедурных языков (PL/pgSQL, PL/Python и других) до новых возможностей с использованием WebAssembly (WASM).
В PostgreSQL исторически поддерживается несколько десятков языков программирования. Если этого недостаточно, можно воспользоваться готовым расширением из огромной экосистемы либо написать своё. Прогресс не стоит на месте, и теперь для выполнения стороннего кода в PostgreSQL можно использовать WASM.
На примере Luxms BI я расскажу, как мы автоматически генерируем Swagger-документацию прямо внутри PostgreSQL с помощью open-source технологий и WASM.
Вебинар «BI + ETL + КХД за 1,5 млн: как Modus закрывает весь стек корпоративной аналитики»
21 апреля в 12 по МСК приглашаем на вебинар, на котором эксперты ИТ-интегратора «Белый код» расскажут, как малому и среднему бизнесу внедрить BI-систему за 1,5 миллиона рублей.
Одна из задач, с которой к интегратору приходит малый и средний бизнес, — внедрение BI в рамках ограниченного бюджета. При этом есть жесткие требования, например, единая экосистема BI + ETL, без «зоопарка» инструментов, а также нативная работа с 1С как основным источником данных.
На вебинаре специалисты поделятся практикой внедрения в сегменте МСБ, а также ответят на вопросы.
Вы узнаете:
Почему BI сам по себе не решает проблему разночтений в данных
Какие организационные изменения нужны, чтобы аналитика начала работать
Modus ETL: как устроена загрузка и обработка данных
Modus BI: аналитический портал без лишней сложности
Структура проекта за 1,5 млн рублей: стоимость лицензий, этапы проекта и результат
Спикеры вебинара
Андрей Рыжик, product owner BI-направления компании «Белый код»
Наталья Лобанова, коммерческий директор компании «Белый код»
📌Дата и время: 21 апреля 12:00 МСК (онлайн)
Участие бесплатное, требуется предварительная регистрация.
Почему “лучший курс” часто оказывается самой дорогой ошибкой
В криптообмене и цифровых переводах пользователи часто ориентируются на самый очевидный показатель, это курс.
Логика понятна: если в одном месте курс выше, а в другом ниже, значит выгоднее там, где цифра выглядит лучше. На практике именно здесь и начинается одна из самых частых ошибок.
Проблема в том, что «лучший курс» почти никогда не существует отдельно от условий, по которым этот курс вообще доступен. Пользователь видит красивую цифру, но не всегда замечает всё, что идёт рядом: комиссии, скрытые ограничения, ручную обработку, задержки, минимальные суммы, требования к верификации, плавающий итог или просто неочевидный порядок расчёта.
В итоге человек выбирает не самый выгодный сценарий, а самый привлекательный заголовок.
Особенно часто это происходит там, где пользователь сравнивает сервисы по агрегатору, таблице или просто по первым цифрам на экране. Визуально разница может выглядеть как очевидная выгода, но после оформления заявки выясняется, что реальный результат уже другой.
Иногда «лучший курс» ломается на комиссии, которая появляется позже. Иногда на спреде между заявленным и финальным расчётом. Иногда на том, что деньги приходят дольше, чем ожидалось, и пользователь теряет не на цифре, а на времени.
Есть и более неприятный сценарий: курс сам по себе хороший, но путь к нему слишком хрупкий. Например, заявка обрабатывается вручную, окно фиксации короткое, правила обновляются в процессе, а любое отклонение по сумме или времени уже меняет итог.
С точки зрения интерфейса всё выглядит честно: цифра показана. Но с точки зрения пользователя это часто превращается в когнитивную ловушку. Он уже увидел «выгоднее» и перестал смотреть на остальное.
Поэтому в финансовых и криптосценариях цена ошибки почти всегда выше, чем кажется. Пользователь сравнивает курс как витрину, хотя по факту ему нужно сравнивать весь маршрут операции: что спишется, сколько дойдёт, когда дойдёт, при каких условиях и насколько предсказуем будет итог.
Именно здесь появляется главный парадокс: иногда курс чуть хуже на старте, но итоговая операция оказывается выгоднее, быстрее и спокойнее. А иногда «лучший курс» на экране это просто самый дорогой способ ошибиться.
Если смотреть шире, проблема не в самом курсе. Проблема в том, что пользователь принимает решение по одному параметру в сценарии, где значимы сразу пять или шесть.
Поэтому «лучший курс» в цифровых переводах — это не гарантия выгоды, а всего лишь одна из переменных. И без контекста она часто работает против самого пользователя.
