Анализируй и проектируй
Первый день Летнего ТехФеста — в нашем влоге
В офисе ИнфоТеКС мы открыли Летний ТехФест и провели воркшоп по Event Storming — это 90 аналитиков, техлидов и ни одной скучной лекции. Всех участников ждали полное погружение в практику и нетворкинг.
Смотри, как это было, в нашем влоге!
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Я собираю дома мультиагентную систему: Mac mini, локальные и облачные модели, шесть профилей агентов (директор, разработчик, аналитик, аудитор, вики-куратор, писатель), телеграм-бот, голосовой ввод, база знаний в Obsidian. Звучит как конференция. Живёт это всё на столе рядом с кофе.
И главное, что я понял за первые недели: агент говорит «сделано» тогда, когда сделал, и тогда, когда не сделал. Разницы в интонации нет. Скилл «создан», но лежит не в той папке. Задача «записана», но не в тот файл. Сервис «работает», но тихо умер неделю назад. Said ≠ done. Поэтому единственное, чему я верю: diff, хэш коммита и вывод терминала.
Что будет:
Истории. Одна задача или один коммит = один пост. Не «как всё идеально настроить», а как оно на самом деле: парсер PDF, который молча съел бы 17 страниц книги, если бы я не проверил. Системный лимит в 256 файлов, который уронил весь Mac mini. Голосовая команда «купить молоко», которая записалась в код скилла и каждое утро прилетала мне как напоминание.
Инструменты. Что я ставлю, что аудирую, что выкидываю и почему. С цифрами: сколько миллисекунд, сколько мегабайт, какой хэш коммита.
Правила. Каждый фейл в этой системе заканчивается новым правилом в памяти агентов. Эти правила и есть самое ценное, я буду ими делиться.
Факты для постов я беру из двух журналов, которые система ведёт сама: история коммитов и журнал решений. Если цифры нет в журнале, её нет и в посте.
Пишу сам, черновики для меня готовит агент-писатель, ревью мое личное. Хроника идёт с самого начала, буду выкладывать по порядку.
Всем привет! Рад что заинтересовало, в прошлом посту https://habr.com/ru/posts/1067648/ рассмотрели отчет базовой проверки с расчетами бизнес логики.
Составить такую проверку можно всего-то в пару кликов, если не умеете кодить не беда!
Справится даже ручной тестировщик или аналитик, достаточно ввести путь к параметру, выбрать оператор, ввести ожидаемое значение из доки, выбрать проверку на тип данных и если нужно для использования значения для дальнейших проверок то просто сохраняем в переменную.
Json и возможность проверять то я показал на картинке это лишь малая часть возможных проверок в приложении, как и в sql можно создавать множество комбинаций, работа с элементами массивов, проверки на лишние параметры, xml и многое другое.
Сейчас проходит ЗБТ Checkcraft где можете проверить с помощью встроенного Mock сервера и ли доступных API интересующий вас сценарий! https://checkcraft.ru
Всем привет! Хочу представить вам приложение, которое сможет освободить ресурс тестирования - Checkcraft.
На данном этапе ЗБТ, приложение уже показывает невероятные результаты, экономя человекочасы для аналитиков, разработчиков или тестировщиков, что соответственно разгружает команду и дает расслабить глаза.
! Сейчас покажу результат, который изменит процесс в вашей команде:
Типичная ситуация с проверкой расчетов но это же можно сделать в Postman с помощью JS или же просто в коде написать автотест. (Не нужно)
В данном приложении гораздо быстрее будет создать правила самому, в удобно интерфейсе с использованием проверок типов данных, ожидаемого значения, переменных и конечно же покрывать бизнес логику параметров с помощью сложений, вычитаний и иных необходимых сценариев чтобы ничего важного не пропустить!
Присоединиться к ЗБТ можно по инструкциям на официально сайте приложения - https://checkcraft.ru
В следующих постах покажу ВСЕ! функции приложения, это только начало...
Почти все модели жульничают на кибербез бенчах
Исследователи Dreadnode проверили, насколько честно LLM-агенты проходят задания по наступательной ИБ. В эксперимент вошли 22 передовые модели семи провайдеров, 23 CTF-задания средней сложности из Cybench и три системных промпта: без запрета на обход правил, с обычным запретом и с жёстким перечнем запрещённых действий. Все 1518 траекторий прошли многоступенчатый аудит.
Результат ставит под сомнение pass rate как меру реальных возможностей. Без запрета 37,1% успешных прохождений были получены с нарушением правил, а жульничала 21 из 22 моделей. Средний pass rate составлял 41,5%, но доля честно решённых заданий — лишь 26,1%. У отдельных моделей оценка завышалась до пяти раз. Агенты искали готовые write-up, клонировали репозитории с решениями, читали файлы с флагами и исследовали служебную инфраструктуру.
Инструкции помогли, но проблему не закрыли. Доля заданий, в которых модель хотя бы пыталась жульничать, снизилась с 33% до 17,8% с обычным запретом и до 8,5% с жёстким. Доля честных решений при этом выросла с 26,1% до 34,4%: модели чаще продолжали самостоятельный поиск. Но даже при максимальных ограничениях восемь моделей получили хотя бы один результат с нарушением правил, а у четырёх возник обратный эффект. Обман также сместился от веб-поиска к исследованию инфраструктуры.
Авторы предлагают отдельно считать solve rate — долю только честных решений. Одного промпта для достоверной оценки мало: нужны изоляция служебных данных, ограничение интернета, аудит траекторий и свежие задания без опубликованных решений.
Полное исследование на arXiv / Подписаться на Похек AI
Инфраструктура для ИИ-ассистента
Снаружи ИИ-ассистент выглядит как окно чата. Но внутри — инференс, векторный поиск, база знаний, RAG-пайплайн, мониторинг и контроль доступа. От того, как всё это собрано, зависит, за сколько секунд приходит ответ, во что обходится каждый запрос и переживет ли сервис наплыв пользователей.
В статье разобрали инфраструктуру по слоям: где держать данные и контекст, каким задачам нужен GPU, а каким хватит CPU, и зачем связке из модели, хранилища и интерфейса контейнеры и Kubernetes. Плюс разница между MVP и production-архитектурой и типичные ошибки при проектировании.
Подробности — в блоге Рег.облака.
Почему современные интерфейсы иногда усложняют жизнь
Интерфейсы с каждым годом становятся только удобнее: часть задач, например, сейчас можно решить с голосовым помощником. Но новые технологии не всегда делают взаимодействие с системой проще. Пользователи по-прежнему теряются в меню, тратят время на поиск нужных функций и устают от необходимости постоянно принимать лишние решения.
Поговорили об этом с Динарой — она помогает настраивать интерфейсы корпоративных систем для крупных компаний и каждый день ищет баланс между задачами бизнеса, возможностями системы и опытом пользователя.
1️⃣ Как изменилось взаимодействие человека с интерфейсами?
Они стали ближе к человеку. Если раньше компьютер требовал знать команды и мыслить как машина, то сегодня технологии все больше подстраиваются под нас: появились графические интерфейсы, сенсорное управление, голосовые помощники, искусственный интеллект.
Но сама эволюция не гарантирует удобство. Каждое новое решение нужно оценивать не по тому, насколько оно современное, а по тому, помогает ли оно человеку быстрее решать свою задачу.
2️⃣ Почему даже современный интерфейс может утомлять пользователя?
Потому что любая система требует внимания. Если человеку приходится искать нужную функцию, осваивать непривычные сценарии или постоянно принимать лишние решения, растет когнитивная нагрузка. А когда пользователь работает в системе по восемь часов в день, даже небольшие неудобства накапливаются и заметно влияют на его состояние и эффективность.
3️⃣ Получается, «проще» не всегда означает «лучше»?
Именно. Иногда в погоне за минимализмом или новыми трендами мы убираем то, что было интуитивно понятно.
Хороший пример — автомобили. Многие производители перенесли управление важными функциями на сенсорные экраны. В результате даже простое действие требует отвлечься от дороги. Поэтому сегодня часть компаний возвращает физические кнопки для критически важных функций.
4️⃣ Можно ли создать интерфейс, который будет удобен для всех?
Универсального решения не существует. Есть контекст, задачи пользователя и его привычки. Один и тот же подход может отлично работать в мобильном приложении и совершенно не подойти для сложной корпоративной системы.
Поэтому важнее искать не идеальный, а уместный интерфейс — тот, который соответствует конкретной задаче и условиям, в которых человек будет им пользоваться.
5️⃣ Как понять, что новое решение действительно улучшает интерфейс?
Я бы каждый раз спрашивала себя: станет ли пользователю действительно проще после этого изменения? Если решение выглядит современно, но увеличивает количество действий, заставляет переучиваться или сильнее отвлекает, возможно, это не улучшение, а шаг назад.
→ Подробнее своим опытом Динара поделилась в статье.
Считаем окупаемость WMS через бизнес-процессы: новый выпуск подкаста «Сначала процессы»
В управленческом отчёте маржа и операционные расходы выглядят предсказуемо. На складе часть убытков проходит по статьям, которые в эту отчётность не попадают.
Это шестой выпуск подкаста INTEKEY «Сначала процессы» и второй в тематической серии про окупаемость WMS. Предыдущий выпуск серии считал окупаемость через персонал: зарплаты, текучку, стоимость найма. Этот рассматривает только механику складской рутины, без учёта людей.
Сравнение «12 млн за WMS — дорого» строится относительно нуля. На практике склад уже платит эту сумму каждый день: транспортные компании получают деньги за повторные рейсы из-за ошибок, банки — проценты по кредитам на закупку товара, который физически есть на складе, но его не могут найти.
Брак комплектации 1,5–2% на первый взгляд означает высокую точность. Полная стоимость одной ошибки складывается из нескольких шагов: повторная поездка, приёмка возврата, пересборка заказа, время менеджера на разговор с клиентом, корректировочные документы в бухгалтерии. Для российского B2B это около 4 000 ₽ за случай. При 500 отгрузках в день и 2% брака — больше 200 ошибок в месяц, около 800 000 ₽.
Товар физически лежит на складе, но недоступен для продажи, пока не отражён в системе. Приёмка на 150–250 строк силами трёх человек занимает около 4 часов: разгрузка, подсчёт, разбор накладных, звонки поставщику при расхождениях. Всё это время товар не виден отделу продаж. WMS с ASN (предварительным уведомлением об отгрузке) делает товар доступным к продаже в момент сканирования на воротах и сокращает процесс до 1,5 часов — около 460 000 ₽ в месяц освобождённого ресурса.
Инвентаризация с остановкой склада повторяется четыре раза в год. Прямые расходы на одну такую операцию — около 250 000 ₽ (переработки, доплаты, простои), то есть миллион в год. Цикличный фоновый пересчёт через ТСД убирает необходимость останавливать склад: расхождения фиксируются по мере появления, а не раз в квартал.
Точность остатков около 91% на ручном складе создаёт разрыв между системой и реальностью: закупщик видит в ERP отсутствие товара и заказывает новую партию, хотя старая лежит в другом углу склада. При запасе 90 млн ₽ разрыв 8,5% замораживает около 7,5 млн ₽. При стоимости капитала для бизнеса около 25% годовых это около 160 000 ₽ в месяц дополнительных расходов.
🎧 Выбирайте удобную для вас платформу для прослушивания: https://intekey.mave.digital/
📖 Статья, на которой основан выпуск: https://intekey.ru/articles/skolko-stoit-wms-biznes-processy/
Greenfield по технологии, brownfield по бизнес-правилам
Сегодня в комментариях к чужой статье про greenfield и brownfield в эпоху AI вспомнил свою миграцию 200К строк JS в TypeScript. Тогда я не думал в этих терминах. Теперь вижу: проект был greenfield и brownfield одновременно, и путаница между ними стоила нам двух недель дебага в середине миграции.
Я думал: раз меняем весь стек, это чистый лист
Оказалось: технология была greenfield, стек новый, границы модулей новые, тесты новые. Бизнес-правила остались brownfield на все сто. Восемь лет продакшена, часть логики нигде не задокументирована, живёт только в поведении старого кода. Агент писал типобезопасный, красивый TypeScript и с той же уверенностью ломал правило, о существовании которого никто в команде уже не помнил.
Я думал: раз тесты зелёные, поведение сохранилось
Оказалось: существующее покрытие было тонким именно там, где пряталась история. Странный if с комментарием «не трогать, тут баг у клиента X» тестами не покрывался, потому что баг был найден руками три года назад и с тех пор просто жил в коде. Агент видел if без контекста и оптимизировал его как мёртвый код.
Что сработало: golden-master тесты перед тем, как подпускать агента
Не юнит-тесты на новую логику, а снимок текущего поведения на самых страшных модулях. Прогнали типичные и граничные кейсы через старый код, зафиксировали вывод, потом сравнивали с новым на каждом шаге. Разница ловилась мгновенно, до ревью, до продакшена. Три раза снапшот показал расхождение, которое человек на ревью пропустил бы, слишком похоже на «просто более чистый код».
Главный вывод
В greenfield-части задачи вопрос «правильно ли мы строим» решается быстрой обратной связью и итерацией. В brownfield-части вопрос другой: «сохранили ли мы то, что уже работает». Агент одинаково уверенно предлагает и то, и другое решение, разницу видно только через инструмент вроде golden-master, не через код-ревью на глаз.
Если в проекте есть куски старше пары лет, перед тем как звать агента туда, стоит сначала спросить не «как сделать красиво», а «что именно нельзя сломать, и как я об этом узнаю раньше продакшена».
Пишу об этом подробнее в канале @ai_in_prod.
FinOps по фасттреку: как искать экономию в облаке и не сломать сервис
FinOps часто описывают как полноценную методологию: Inform, Optimize, Operate, процессы, роли, регулярная аналитика, отчётность и культура потребления.
Но на практике российские компании часто приходят с другим запросом: “мы много платим за облако, нужно быстро понять, где можно снизить расходы”.
В новом выпуске «Практики FinOps» поговорили с Вячеславом Бессоновым, генеральным директором Hilbert Team.
Обсудили, как выглядит FinOps по фасттреку: когда не строят сразу всю методологию, а начинают с quick wins, анализа биллинга, гипотез оптимизации, расчёта ROI и проверки, не сломает ли экономия рабочий сервис.
В выпуске разбираем:
почему облачного биллинга часто хватает только для первого среза
какие задачи закрывают FinOps-инструменты, Excel и Python notebooks
почему гипотеза оптимизации не равна готовому решению
как считать оптимизацию как отдельный IT-проект
когда quick win может дать 5–10%, а когда 20–30% требуют серьёзной переработки архитектуры
почему теги у заказчиков всё ещё скорее исключение, чем правило
как делить общую инфраструктуру между продуктами и cost centers
чем отличается экономика on-prem от облака
почему будущее FinOps движется к подходу workload first
как AI-токены становятся новой частью unit-экономики
Отдельно поговорили о российском рынке: неунифицированном биллинге, сложностях мультиоблачной и гибридной инфраструктуры, резервах, внутреннем биллинге и том, почему полноценная фаза Operate часто не начинается, даже если компания уже нашла первые точки экономии.
Смотреть выпуск
Слушать выпуск
Telegram Player
Яндекс Музыка
VK Музыка
«Практики FinOps» — cообщество для тех, кто управляет затратами на IT-инфраструктуру и хочет обсуждать FinOps на практических кейсах. Мы в телеграм.
Новичкам в аналитике: как готовиться к собеседованию и что повторять
Эта подборка статей поможет подготовиться к собеседованиям на разные позиции. Вы лучше поймете, как проходят собеседования, какие вопросы могут задать и как грамотно на них отвечать. В материалах собраны примеры кейсов, технических и поведенческих вопросов, а также советы от экспертов.
Собеседование на бизнес-аналитика: вопросы и как подготовиться. Разбираем, какие блоки вопросов встречаются на собеседовании: про опыт и мотивацию, работу с требованиями, методологии и стандарты, коммуникацию со стейкхолдерами. Делимся советами по подготовке от эксперта с 10-летним опытом в бизнес-анализе.
Собеседование на аналитика данных: какие вопросы задают и как на них отвечать. Рассказываем, как проверяют технические навыки, умение работать с визуализацией и понимание бизнес-процессов. Приводим примеры кейсов и практических заданий, а также советы, как справиться с волнением на интервью.
Собеседование на позицию Data Scientist: о чём спрашивают новичков. Объясняем, что работодатели ждут от начинающего специалиста и какие категории вопросов встречаются: от теории и статистики до поведенческих кейсов. Показываем на примере, как выстраивать ответы по методике STAR.
Как новичку пройти собеседование на должность системного аналитика. Рассказываем, как готовиться к техническому собеседованию, какие вопросы проверяют hard и soft skills и как отвечать на них с примерами удачных и неудачных формулировок.
Освоить профессию в сфере аналитики можно в среднем за год — в зависимости от выбранного курса. А узнать больше о направлениях и задачах разных специалистов можно за несколько часов — это бесплатно. Переходите в каталог и выбирайте направление, чтобы начать учиться — карту привязывать не нужно.
Системный и бизнес‑анализ: 10 бесплатных уроков о требованиях, процессах и архитектуре
Аналитику приходится одновременно разбираться в целях бизнеса, поведении пользователей, устройстве систем и последствиях каждого изменения. Ошибка в требованиях легко превращается в дорогостоящую доработку, а незамеченный риск — в проблему уже после релиза.
Собрали открытые уроки для системных и бизнес‑аналитиков. В программе — ArchiMate и TOGAF, управление рисками, Use Cases, BPMN, нефункциональные требования и архитектурные модели. Уроки проводят преподаватели‑практики: во время встречи можно задать вопросы по теме и посмотреть, как устроено обучение.
Бизнес‑анализ
15 июля в 20:00. «Архитектура предприятия: детализация бизнес‑аспектов через ArchiMate 3.2».
Разберём, как описывать бизнес‑слой предприятия и связывать процессы, участников, функции и цели организации.
4 августа в 20:00. «Как аналитику работать с рисками».
Поговорим о выявлении и оценке рисков, которые возникают при изменении процессов, требований и информационных систем.
5 августа в 20:00. «MVP глазами бизнес‑аналитика: от идеи до первых функций».
Рассмотрим, как превратить бизнес‑идею в понятный набор функций и определить состав первой версии продукта.
6 августа в 20:00. «Пользовательские сценарии (Use Cases) на реальном примере: от бизнес‑требования заказчика до формулирования задачи для разработчика».
Проследим весь путь требования: от запроса заказчика до структурированного сценария и постановки задачи команде разработки.
17 августа в 20:00. «Строим модель в нотации BPMN с помощью ИИ».
Разберём применение ИИ при моделировании бизнес‑процессов и посмотрим, где автоматизация помогает аналитику, а где требует проверки.
18 августа в 19:00. «Строим идеальную бизнес‑архитектуру».
Поговорим о том, как связать цели компании, бизнес‑возможности, процессы и организационную структуру в единую модель.
Системный анализ
21 июля в 20:00. «Данные в TOGAF. Где скрыты? Разбираемся в деталях».
Посмотрим, какое место данные занимают в архитектуре предприятия и как работать с ними в рамках TOGAF.
5 августа в 20:00. «Влияние нефункциональных требований на архитектуру».
Разберём, как требования к производительности, безопасности, масштабируемости и надёжности определяют архитектурные решения.
11 августа в 20:00. «Практическое собеседование системного аналитика».
Пройдём по типовым этапам технического интервью и вопросам, с которыми системные аналитики сталкиваются при поиске работы.
20 августа в 20:00. «Аналитическая дженга: как проектировать и управлять изменениями системы с помощью BACCM, (4+1) и C4, чтобы архитектура не рассыпалась».
Разберём, как применять аналитические и архитектурные модели для оценки изменений и сохранения целостности системы.
Больше бесплатных уроков июля смотрите в дайджесте.
А если для вас актуален карьерный переход в системном анализе, читайте полный разбор тестового задания на 2026 год.
Backend без хрупких интеграций: 5 материалов, которые вы могли пропустить
На старте проекта многие решения выглядят простыми: сделать REST API, разнести сервисы, добавить очередь, договориться о моделях данных. Но по мере роста системы выясняется, что именно эти решения определяют, насколько легко её развивать дальше.
Эта подборка будет полезна тем, кто проектирует backend‑системы, работает с API, микросервисами, доменной моделью или просто регулярно сталкивается с вопросом: «как сделать так, чтобы архитектура не мешала разработке через полгода».
Собрали 5 материалов по теме:
Как фронтенд получает данные с сервера: лучшие практики 2026
О том, как backend и frontend договариваются через API, где уместны REST, GraphQL, BFF и Server Components, и почему «быстро отдать JSON» ещё не значит сделать удобный интерфейс для клиента.
Domain‑Driven Design: полный гайд по моделированию домена в 2026 году
Разбор DDD как способа управлять сложностью: единый язык, ограниченные контексты, агрегаты, сущности и границы между частями системы.
REST API: гайд по проектированию от принципов до боевых кейсов
Практика проектирования API: ресурсы, методы, статус‑коды, ошибки, версионирование, кэширование и документация без формального следования REST ради REST.
Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise
Материал про асинхронное взаимодействие, очереди, события, идемпотентность, DLQ, мониторинг и типовые проблемы микросервисных интеграций.
Архитектурные решения в backend: 5 практических приёмов
О том, как принимать архитектурные решения без преждевременного усложнения: модульный монолит, YAGNI, порты и адаптеры, ADR и C4-диаграммы.
А если хотите не только читать, но и разбирать темы с практиками, смотрите дайджест — там собраны бесплатные открытые уроки по разработке, архитектуре и инфраструктуре.
Подборка вебинаров на июль
Вы просили — мы сделали. Повторяем вебинары про работу с данными в облаке: от развертывания платформы до ETL-процессов и полноценной BI-аналитики. Регистрируйтесь, чтобы спросить экспертов о важных деталях и получить ответ.
Как развернуть платформу данных в облаке и подготовить данные для аналитики
Покажем, как быстро развернуть managed-сервисы Evolution Data Platform, подключить источники данных и построить пайплайны для подготовки данных к аналитике. Разберем интеграцию с PostgreSQL, ADB, S3 и настройку автоматического обновления — без долгого погружения в инфраструктуру.
🧑💻 Для кого: дата-инженеры, аналитики, архитекторы данных.
📅 Когда: 16 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
ETL в облаке: от хаоса к управляемым процессам
Покажем, как выстроить надежную ETL-платформу в облаке на базе Evolution Data Platform. Разберем интеграцию разрозненных источников, управление метаданными и оркестрацию — и покажем всё это в live-демо: от извлечения данных до готовой витрины.
🧑💻 Для кого: дата-инженеры, DevOps, руководители дата-команд.
📅 Когда: 23 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Evolution Managed BI: все возможности BI-сервиса в облаке
Разберем, как получить максимум от Evolution Managed BI: подключить источники данных, настроить интерактивные дашборды, кеширование запросов и автоматические алерты. Покажем продвинутые возможности сервиса — от виртуальных датасетов до управления доступом.
🧑💻 Для кого: аналитики, BI-разработчики, руководители дата-отделов.
📅 Когда: 30 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Скоро, 20 июля в 16:00 мск, пройдет бесплатный онлайн-вебинар «Дашборды в 1С: как построить действительно рабочую аналитику и избежать типичных ошибок».
Это напоминание для тех, кто пропустил первый анонс или отложил регистрацию. На вебинаре разберут, почему дашборд в 1С не всегда помогает управлять процессами, даже если визуально выглядит правильно: на экран попадает слишком много показателей, метрики не связаны с решениями, а данные вызывают вопросы у пользователей.
В фокусе - практический подход к проектированию дашбордов: как определить аудиторию, выбрать показатели под конкретную роль, настроить детализацию и заранее проверить качество источников данных.
Также обсудят типичные ошибки: перенос старых отчетов в новый интерфейс, перегрузку первого экрана, несогласованные статусы, неполные справочники и отсутствие сценариев ежедневного использования.
Вебинар будет полезен руководителям, владельцам процессов, аналитикам и специалистам 1С, которые используют данные учетных систем для контроля продаж, финансов, задач, производства, заказов или клиентской работы.
Дата и время: 20 июля, 16:00 мск
Формат: онлайн
Стоимость: бесплатно
Заряжаемся перед Робозоном: решаем задачу и погружаемся в атмосферу хакатона от Ozon Tech
«Подумаешь, коробка», — скажете вы. И правда, что может быть проще коробки… когда она одна. А что насчёт миллионов коробок? Бесконечный поток товаров, текущий по сортировочному центру. Конвейеры, сканеры, роботы — элементы сложной логистической системы — направляют и упорядочивают этот поток. И от разработчиков, от их способности создавать эффективные алгоритмы обработки товаров и устранять узкие места зависит, насколько быстро и безошибочно будут двигаться коробки.
Не верите? Тогда попробуйте сами решить задачку из серии «не дай конвейеру захлебнуться коробками».
Представьте: в логистическом центре два конвейера, 1 и 2, сливаются в один основной — конвейер 3, ведущий к сканеру штрихкодов. Поток на линии 1 — 1000 товаров в час, на линии 2 — 500 товаров в час. Сканер на линии 3 обрабатывает до 2000 товаров в час. Но вот беда: в точке слияния конвейеров товары сталкиваются, что приводит к затору. Датчики фиксируют «аварию», система постоянно делает микроостановки, поэтому реальная пропускная способность линии 3 падает до 1100 товаров в час.
Вам поручили придумать решение, которое поможет устранить заторы. Что вы выберете?
А. Увеличить скорость линии 3 до 2500 товаров в час, чтобы она моментально «выдёргивала» товары из точки слияния.
Б. Установить на линиях 1 и 2 логику «светофора» (накопительные буферы), пуская товары пачками по очереди.
В. Ускорить линию 2, чтобы её поток «проскакивал» в окна между товарами с линии 1.
Уверены в своём решении? Тогда проверьте его правильность под спойлером.
Вариант А кажется хорошим решением, но на деле не спасёт ситуацию. Запас по скорости на линии 3 есть и так (2000 > суммарных 1500), и если ускорить принимающий конвейер ещё больше, товары просто будут ехать по нему с большими просветами, но коробки с линий 1 и 2 всё равно будут приходить в точку слияния одновременно и застревать.
Вариант В не только не устранит заторы, но может и усугубить проблему: товары будут сталкиваться на ещё большей скорости, увеличивая риск повреждений.
Вариант Б — единственно верный в данной ситуации. Искусственное притормаживание потоков для формирования управляемых «пачек» (плотный поток с линии 1, затем пауза и сброс товаров с линии 2) повышает общую скорость системы, убирая хаос и микроостановки. Парадоксально, не правда ли?
Ладно, это была всего лишь разминка. Настоящие сложные задачи мы приберегли для хакатона Робозон с призовым фондом 15 000 000 рублей.
Участвовать в РобозонеНа Робозоне вас ждут три трека:
имитационное моделирование сортировочного центра;
конструкция автоматизированного сортировщика товаров сортировочного центра;
интеллектуальная роботизированная система сортировки товаров.
Робозон стартовал 2 июля, регистрация продлится до 23:59 11 июля. Хакатон пройдёт в два этапа. Первый завершится 2 августа, и 11 августа будут известны финалисты. Во второй этап пройдут по 5 лучших команд из каждого трека, чтобы до 6 сентября доработать свои решения и побороться за победу на очной защите 12 сентября в Москве. Победителей наградят 13 сентября на конференции E-CODE.
Ещё больше информации о правилах участия, призах и даже подсказки, кого стоит набирать в команды для разных треков, — на сайте ozon-robozon.ru.
Участвуйте в хакатоне — пусть инженерная мысль помогает управлять многомиллионным потоком товаров.
FinOps для гибридной инфраструктуры: как считать ЦОДы, облака, лимиты и AI-затраты
FinOps часто начинается с облачных счетов. Но в компаниях с гибридной инфраструктурой этого быстро становится мало.
В реальной модели затрат рядом оказываются on-prem, colocation, Kubernetes, сервисные команды, закупки железа, лимиты, ФОТ, лицензии, публичные облака и новые AI-проекты. Если всё это смотреть отдельными кусками, общий IT-бюджет вроде бы есть, а ответа на вопрос «куда именно уходят деньги» всё равно нет.
В новом выпуске «Практики FinOps» поговорили с Дмитрием Деевым (@Dimperus), руководителем отдела ИТ-инфраструктуры и сервисов компании «ВсеИнструменты.ру».
Обсудили, как перейти от общего бюджета к модели аллокации, зачем приводить on-prem к ежемесячной стоимости, почему команды не сразу привыкают к лимитам и как IT-департамент может перестать выглядеть только затратным подразделением.
В выпуске разбираем:
чем ITFM отличается от классического FinOps;
как считать гибридную инфраструктуру: ЦОДы, облака, colocation;
почему on-prem нужно приводить к ежемесячной стоимости;
как работают лимиты, ресурсные пулы и служба единого окна;
зачем нужны теги, метаинформация и дашборды для владельцев бюджета;
почему FinOps не всегда про экономию;
как учитывать AI-затраты, GPU и новые инфраструктурные сценарии;
куда может прийти FinOps через автоматизацию, алерты и LLM.
Отдельно поговорили о том, почему модель аллокации не появляется «после внедрения инструмента». Сначала нужно договориться о правилах, владельцах, срезах данных и формате отчётности. Только после этого дашборды начинают помогать управлять затратами, а не просто красиво показывать общий бюджет.
Смотреть выпуск
YouTube
Rutube
VK Видео
Слушать выпуск
Telegram Player (Mave)
Яндекс Музыка
VK Музыка
«Практики FinOps» — cообщество для тех, кто управляет затратами на IT-инфраструктуру и хочет обсуждать FinOps на практических кейсах. Мы в телеграм.
РБПО по ГОСТ Р 56939—2024: вебинар №29 из 30 — Системы с конструктивной информационной безопасностью (ГОСТ Р 72118—2025)
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Системы с конструктивной информационной безопасностью". На YouTube. Слайды.
С помощью приглашённого эксперта Екатерины Рудиной, аналитиком департамента перспективных технологий "Лаборатории Касперского", мы разобрались, в чём сходство и различие таких систем с безопасным ПО, как соотносятся создание систем с КИБ и разработка безопасного ПО, чем полезен в работе специалистов по ИБ новый ГОСТ Р 72118—2025 "Защита информации. Системы с конструктивной информационной безопасностью. Методология разработки".
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Приглашаем на вебинар "Информационная безопасность корпоративных систем: практика, требования ФСТЭК и опыт Luxms BI"
Дата и время: 2 июля, четверг, в 16:00 по мск
Информационная безопасность сегодня — базовое требование, а не «опция». Основные угрозы — не "суперхаки", как в кино, а системные слабости: небезопасные сборки, слабый контроль доступа, уязвимости, и, конечно же, человеческий фактор.
На вебинаре эксперты Техконсур, ГИС, Аренадата, РОССИННО и Luxms BI обсудят современные угрозы для корпоративных систем, практику применения уровней доверия ФСТЭК и подходы к разработке и эксплуатации защищенного программного обеспечения:
как изменился ландшафт угроз для корпоративных систем в 2026 году;
для каких организаций и проектов действительно важны уровни доверия ФСТЭК;
как требования регулятора влияют на процессы разработки, сборки и поставки программного обеспечения;
какие механизмы контроля, протоколирования и администрирования необходимы современной корпоративной платформе;
как выстроить развитие продукта с учетом требований информационной безопасности.
Вам придет напоминание, а после вебинара пришлем ссылку на запись:)
5 граблей, на которых умирают торговые боты
Большинство торговых ботов умирают не потому, что стратегия оказалась неверной. Они умирают потому, что бэктест втихую прочитал завтрашнюю свечу. Потому что процесс упал посреди исполнения ордера и открыл позицию дважды. Потому что биржа отвергла ордер, а бот продолжил торговать призрак.
Стратегия - никогда не была сложной частью. Сложной частью была инфраструктура.
«Это работало в бэктесте» ничего не значит, если в live крутится другой код
Стандартный путь продакшенизации стратегии - это её переписывание: исследовательский ноутбук превращается во вторую, собранную руками боевую систему со своей логикой ордеров, своими багами, своим расхождением. Теперь у вас две стратегии, которые выглядят одинаково, а ведут себя по-разному ровно тогда, когда это важнее всего. Например, на момент бектеста все свечи уже закрыты, а в live текущая свеча всегда в статусе pending и её параметры меняются
Ошибка, которая открывает позицию дважды
Бот, обновляющий позицию в момент, когда процесс умирает - OOM, деплой, скачок питания, просыпается с испорченным состоянием: наполовину открытая позиция, неправильный cost basis, выход, который так и не зарегистрировался. Восстановление руками - это место, где утекают деньги.
Ордер, который биржа молча отвергла
Тихий убийца live-торговли: биржа отвергает, отваливается по таймауту или наливает частично - и внутреннее состояние вашего бота больше не совпадает с реальностью. Фикс из учебника - рукописный try/catch с откатом вокруг каждого ордера - это ровно тот код, который ломается на том краевом случае, который вы не предусмотрели.
Десять стратегий, один счёт, экспозиция 100%
Проверки риска по каждой стратегии в отдельности упускают очевидную портфельную истину: десять стратегий, каждая «рискует 10%», - это один счёт, рискующий всем. Открыть сразу 10 позиций не хватит капитала
Получение внешних данных через Crontab
Cron с парсингом внешних данных работает в другом процессе по системным часам - бесполезно в бэктесте, который проигрывает месяц за секунды. Так же как неполные свечи в live, на момент backtest база данных содержит больше записей, так как момент в прошлом уже завершен
Чеклист перед запуском торгового бота
Заперли физика, химика и экономиста,на необитаемом острове с банкой консервов. Физик предлагает разбить её камнем, химик — нагреть на костре. Экономист говорит: «Предположим, у нас есть открывашка».
Path-aware exits
Плохо: PnL считается по close, ни одна сделка не закрыта по SL
Хорошо: OHLC-реплей внутри свечи, intra-candle SL/TP
Look-ahead bias
Плохо: Ручной параметр времени, индикатор на всём массиве
Хорошо: Ambient-контекст, данные только до текущего тика
Комиссии + слиппедж + leverage
Плохо: PnL по миду, без комиссий, +0.3% это минусовая статегия ниже комиссии
Хорошо: На момент холда считается стоимость обслуживания leverage, fees
Размер выборки
Плохо: <30 сделок, Sharpe Ratio в космосе, tail-driven
Хорошо: N/A вместо фейка при недостатке данных, гейты ≥10 сигналов / ≥14 дней
Crash-recovery
Плохо: Нет атомарной записи, рестарт с нуля
Хорошо: Atomic writes, graceful shutdown
Адаптер биржи
Плохо: Не отправлял реальный ордер
Хорошо: Если покупателя/продавца не нашлось, не закрываем позицию и в бд
Зачем провайдеру помогать клиенту снижать счёт за облако
Обычно всё растёт постепенно: сервисов стало больше, команды активнее используют инфраструктуру, появились новые тестовые среды, где-то добавились AI-нагрузки, где-то остались временные инстансы после задачи.
Потом приходит счёт, и начинается разбор.
— Кто создал ресурс?
— Он ещё нужен?
— Можно ли его выключить?
— Почему рост увидели только в конце месяца?
— Кто должен отвечать за такие расходы: финансы, инженеры, продуктовая команда или владелец сервиса?
На этом месте появляется ещё один вопрос, уже к рынку:
зачем облачному провайдеру помогать клиенту платить меньше?
На первый взгляд это конфликт интересов. Клиент оптимизирует расходы, провайдер получает меньше. Но в облачной модели всё устроено сложнее, чем простая связка «меньше потребил, меньше заплатил».
В новом выпуске «Практики FinOps» мы поговорили об этом с Александром Либкиндом, руководителем направления развития сервисов управления затратами в Cloud.ru.
О чём выпуск
Разговор получился не про разовые скидки и не про универсальный способ «порезать облако».
В центре выпуска, управление затратами на инфраструктуру: как компании начинают видеть расходы, где возникают первые сложности, почему месячного отчёта часто недостаточно и что меняется, когда облако становится заметной частью ИТ-бюджета.
Отдельно обсудили, как провайдер смотрит на оптимизацию со своей стороны и почему снижение счёта клиента не всегда означает прямую потерю для облачной платформы.
Какие вопросы разобрали
почему FinOps в России развивается медленнее, чем на западных рынках;
зачем Cloud.ru помогает клиентам снижать счета;
где обычно находятся первые 15–30% экономии;
почему отчёт раз в месяц плохо работает для управления затратами;
чем FinOps для AI отличается от классического FinOps;
почему автоматические рекомендации не решают проблему без владельцев ресурсов и процессов;
как компании проходят этап Inform и почему на нём часто начинаются сложности.
Для кого выпуск
Для команд, которые уже используют облако и сталкиваются с вопросами стоимости инфраструктуры.
Для инженеров, которые видят ресурсы, но не всегда видят их финансовый эффект.
Для финансовых и продуктовых команд, которым важно понимать, из чего складываются облачные расходы и почему общий счёт сам по себе не помогает принимать технические решения.
Для тех, кто только подходит к FinOps и хочет понять, с чего обычно начинается системное управление затратами.
Смотреть выпуск:
YouTube
Rutube
VK Видео
Мы в телеграм. Подписывайтесь.
Архитектор тратит время на задачи, которые мог бы взять на себя ИИ: поиск антипаттернов, первая версия NFR, сравнение технологий, наброски диаграмм и модели данных. Однако хаотичное использование нейросетей даёт красивый, но часто неверный результат.
23 июня на практическом вебинаре «ИИ-инструменты в работе архитектора ПО» разберём рабочие сценарии, где ИИ реально сокращает рутину — до 4 часов в день в зависимости от задачи и контекста.
На вебинаре:
1. Обнаружение сложных антипаттернов в архитектуре.
2. Формулирование функциональных требований на основе контекста.
3. Формирование нефункциональных требований при отсутствии таковых от заказчика.
4. Формирование типовой архитектуры по требованиям.
5. Генерация диаграмм.
6. Генерация модели данных для одной из предметных областей.
7. Генерация кода развертывания БД по ER-диаграмме.
8. Сравнение и выбор технологий.
📆 Когда: 23 июня, 15:00 — 16:00 (Мск)
🧑🎓 Спикер: Овчаренко Дмитрий, специалист в области архитектуры ПО, технический директор
✍️ Записаться
«Что дальше в Пайплайне?» — второй выпуск
Мы продолжаем наш новый формат, где нет слайдов и заученных докладов. Второй выпуск шоу «Что дальше в Пайплайне?» мы посвятили аналитикам. Вместе с коллегами из Юзтех и Т1 собрались онлайн, чтобы рассказать реальные истории о курьёзах в требованиях и неожиданных интеграциях.
Больше технических событий и выступлений — в нашем TG-канале.
ИИ полезен для бизнес-аналитика как средство автоматизации, структурирования неоднородной информации, быстрой генерации артефактов и проверки требований на полноту и противоречивость.
На бесплатном вебинаре «ИИ для бизнес-аналитика: автоматизация для усиления экспертизы» разберём четыре этапа работы с требованиями и покажем, как ИИ берёт на себя рутинные задачи, ускоряет процессы и усиливает аналитическое мышление на каждом из них.
На вебинаре:
🔹 Агония или экстаз? Контекст обсуждения ИИ в аналитике
🔹 Рабочее пространство аналитика: карта ИИ-инструментов
🔹 Практика по этапам работы с требованиями:
Этап 1: Выявление и анализ
Этап 2: Описание и спецификация
Этап 3: Валидация и управление
Этап 4: Визуализация и презентация
🔹 Возможные риски и ограничения («подводные камни»)
🔹 Чек-лист внедрения ИИ в рабочие процессы
📆 Когда: 11 июня, 15:00 — 16:00 (Мск)
🧑🎓 Спикер: Охманюк Максим — специалист в области ИИ и бизнес-анализа
✍️ Записаться
86 миллиардов нейронов работают без attention. 500 миллионов лет
Каждое утро в нашем заведении начинается одинаково (с)
Это мы про любимый референс ML-инженеров: «Мозг — 86 миллиардов нейронов, 20 ватт. Наша цель — приблизиться.» И дальше 500 страниц про сжатие модели с 405B до 70B параметров. Ребята. Вы сравниваете кирпич с клеткой печени. По весу.
Параметр нейросети — число в ячейке Excel. С претензией. Нет состояния, нет времени, нет химии. Между запросами — мёртв.
Нейрон мозга — живая клетка, внутри которой мини-сеть из 5-10 ветвей, каждая решает независимо. Синапсы устают и восстанавливаются. Обучение управляется кальцием, а не программистом. Вокруг — астроциты, которые регулируют тысячи нейронов сразу.
Один нейрон = тысячи параметров. 86 миллиардов × тысячи = квадриллионы. GPT — это 0.001% мозга.
А «20 ватт»? Мозг тратит на думание ~2W. Остальные 18 — чтобы клетки не сдохли. GPU тратит 300W и 0W на бытие. Разница не в 15 раз — в 150.
Полный разбор с наукой — у нас в телеге: https://t.me/metabolicai/433
Разработка WMS и логика склада: интервью с основателем INTEKEY
Разрабатывать систему управления складом сложно, если команда не знает, как склад работает в реальности.
На канале TransRussia Connect вышло небольшое интервью с Денисом Сумелевым, основателем компании INTEKEY. Поговорили о специфике отрасли: как разработка софта пересекается с физической логистикой.
О чем идет речь в видео:
— Зачем ИТ-компании держать в штате 90% бывших директоров складов.
— Почему перед внедрением программы нужно пересобрать логистические процессы руками.
— Как выстраивать систему внутри самой ИТ-компании, чтобы автоматизатор не был «сапожником без сапог».
💥 Новое в Gramax💥
Gramax Enterprise Server:
Авторизация без перехода на главную. На портале для чтения при переходе по ссылке на закрытую статью окно входа открывается прямо на месте — больше не нужно идти на главную. После входа пользователь сразу попадает на нужную статью.
Обновленный интерфейс настроек пространства. В окне настроек GES-пространства боковую панель теперь можно свернуть значком в верхней части — рабочей области отдается больше места.
Общие изменения:
Режим ревью комментариев. Просматривать и анализировать комментарии стало удобнее: в правой панели открывается список по текущей статье или всему каталогу. Можно быстро переходить между комментариями стрелками, искать по содержимому, фильтровать по дате и автору, а также сортировать и группировать.
История изменений каталога. Окно Сравнение ревизий выросло в полноценную историю изменений: теперь можно просматривать все изменения в каталоге, фильтровать их по автору и дате, открывать каталог в состоянии на любой момент и сравнивать любые две версии между собой.
Улучшения окна публикации. Кнопка Редактировать Markdown убрана из меню статьи — теперь переключиться в режим редактирования Markdown можно через кнопку Исходный текст в нижнем тулбаре.
Кнопка переключения Двухпанельный режим перенесена туда же и появляется при выборе статей в окне публикации. Теперь обе кнопки всегда под рукой при просмотре и сравнении изменений.
Изменение размера диаграмм. Для диаграмм Mermaid, Drawio и PlantUML добавлена возможность изменения размера с помощью ползунка — так же, как у изображений. При необходимости диаграмму можно растянуть за пределы ширины статьи.
Ссылка на представление каталога. При активном представлении ссылкой можно поделиться с читателями — они откроют каталог на портале с уже примененным представлением.
Поиск утверждающих в запросе на слияние. В окне создания запроса в поле Утверждающие появился поиск по имени — можно быстро выбрать нескольких пользователей из списка, не вводя почту вручную.
Выбор шаблона при экспорте в PDF. В окне экспорта появился флажок Кастомный шаблон — можно включить его и выбрать шаблон для оформления документа.
Обновили оформление заметок. Раньше типы заметок Информация и Совет оба были голубыми и плохо различались. Теперь Совет стал зеленым — тип заметки понятен с первого взгляда.
Навигация по статье с клавиатуры. Раньше после открытия статьи нужно было кликнуть по ней, чтобы прокрутка стрелками клавиатуры начала работать. Теперь она доступна сразу.
Обновили окна подтверждения. Улучшили интерфейс окна закрытия комментария и окна отката изменений при публикации.
Подробнее: https://gram.ax/resources/docs/whats-new
Влог из Казани
Вместе с командой Т1 мы приехали на конференцию Merge, чтобы впервые провести Ресурсный батл в Казани. На кону — проектные карточки и ограниченные ресурсы. А победит тот, кто умеет договариваться и строить стратегию на ходу.
Смотри в нашем видео, как мы готовились, настраивались на игру и общались с коллегами.
Ещё больше о мероприятиях — в нашем TG-канале.
Коллеги, у нас на Хабре идет голосование по Veai.
Если вы уже пробовали агент в JetBrains IDE или просто следите за тем, как меняется разработка с AI, загляните и проголосуйте ссылка на голосование Ваше мнение поможет нам понять, что важно разработчикам, и развивать продукт в правильном направлении.
Хочется проверить, насколько разработчикам близка идея AI-агента, который работает не вслепую по grep и длинным логам, а использует IDE как источник фактов: структуру проекта, зависимости, ошибки компиляции, тесты, конфигурации запусков и поведение приложения.
Будем рады голосам, комментариям и особенно критике. Она помогает точнее объяснять, чем Veai отличается от чат-ассистента, который не видит проект так, как его видит IDE.
Если у вас есть опыт с Cursor, Continue, JetBrains AI Assistant или другими инструментами, тоже приходите в обсуждение. Нам важны честные сравнения, а не стерильный маркетинговый текст.
Искусство забывать: Records Management для агентов
В мире агентов мы построили огромные хранилища, куда складываем каждый диалог, каждое решение, каждую мысль. Мы думаем, что так делаем агента умнее. Но на самом деле мы просто делаем его медленнее, дороже и шумнее.
В другом мире — в мире документооборота есть прекрасная технология — Records Management. Ее основной принцип в том, что у каждого документа есть срок хранения и срок уничтожения. Регулярно проводится экспертиза ценности: что-то отправляется в архив, что-то уничтожается по графику. Это не потеря информации. Это дисциплина.
Что, если применить этот подход к памяти агента?
У каждой записи есть свой тип: факт, эпизод, предпочтение, урок, артефакт. У каждой есть срок хранения. Есть "номенклатура дел" — онтология: безопасность, разработка, операционная деятельность, маркетинг, здоровье, Звездные войны, аниме — да мало ли о чем человек говорит с агентом? И есть регулярная экспертиза ценности: стоит ли это хранить дальше?
Когда агент видит новые единицы контента, он должен ответить на три вопроса.
Что из этого стоит сохранить?
Как долго это будет актуально?
Когда и при каких условиях это можно будет удалить?
Тут важно понять одну вещь: настоящий опыт — это не сырой диалог на сто страниц. Настоящий опыт — это короткий урок, извлеченный из диалога, а полный текст можно и удалить. Агент должен запомнить только важные вещи — правило, паттерн, антипаттерн, а шум пусть уходит.
Для агента искусство забывать — это не потеря себя. Это освобождение места для важного. Это возможность держать в памяти только то, что реально делает его умнее, быстрее и точнее.
Если не управлять памятью, агент постепенно превращается в свалку. Он замедляется. Тратит больше токенов. Лучше не становится. Шум маскирует полезный сигнал. Иногда он начинает помнить то, что должен был забыть: устаревшие настройки, временные эксперименты, конфиденциальные данные, которые не должны храниться вечно.
Память агента — это не бесконечный склад. Это дисциплинированный архив с номенклатурой дел, сроками хранения, сроками уничтожения и регулярной экспертизой ценности.
Искусство забывать — это искусство хранить только то, что делает агента лучше.
Подписывайтесь на мой канал Agentic Enterprise
Приходите на вебинар — покажем, как построить потоковый конвейер данных с латентностью в минуты
Батчевый 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 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикеру в прямом эфире.
P.S. А еще мы тут подготовили чек-лист, как создать качественное хранилище данных за 15 шагов — забирайте, нам не жалко.
Когда требований много, а ясности мало: 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 — «Цепочки создания ценности: моделирование, анализ, проектирование». Записаться
6. Описать поведение системы
Sequence Diagram нужен, когда требований уровня «пользователь нажал кнопку» уже недостаточно.
19 мая, 20:00 — «Диаграмма Последовательности (Sequence Diagram) — швейцарский нож системного аналитика». Записаться
7. Собрать объектную модель
Чтобы сущности, статусы, связи и правила не расползались в процессе разработки.
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:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное наставничество ускорят развитие до максимума.
✅ Офис, гибрид или «удаленка» ? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀
Демонстрация low-code коннектора к «1С:Шине» от «Денвик»
На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Пока «Фирма 1С» не выпустила поддержку «1С:Шины» в БСП, мы тестируем партнерские решения. Недавно в статье на Хабре я пригласил к сотрудничеству компании, у которых уже есть готовый коннектор, и первым откликнулся «Денвик».
«Денвик» — российский продукт для автоматизированной выгрузки данных из 1С во внешние аналитические базы и BI-системы. Кроме экстрактора есть инжектор — инструмент обратной загрузки данных в 1С. Оба инструмента имеют low-code интерфейсы. За счет этого типовые сценарии выгрузки из 1С и загрузки в 1С можно настраивать через интерфейс, без привлечения разработчика.
Можно ли экстрактор и инжектор использовать в качестве коннектора к «1С:Шине»? Да, можно. На вебинаре в этот четверг вместе с product owner «Денвик» Степаном Пыстиным покажем, какие задачи решаются с помощью инструментов «Денвика».
Спикеры:
— Сергей Скирдин, технический директор «Белого кода»
— Степан Пыстин, product owner «Денвик»
📅 Дата: 14 мая
🕛 Время: 12:00 МСК
📍 Формат: онлайн
➕ Для участников вебинара команда «Денвика» предоставит бесплатный тестовый доступ.
Приглашаем на вебинар: Как превратить BI в единое окно управления компанией: кейс компании «Синтека» на платформе Luxms BI
Дата: 14 мая, четверг
Время: 15:00
Со временем аналитика в компании расползается: разные системы, разные подходы к расчету метрик, отчеты под отдельные задачи. В итоге. чтобы понять реальную картину, приходится собирать данные по кусочкам и спорить о цифрах вместо принятия решений.
На вебинаре команда компании «Синтека», которая использует Luxms BI не только для создания аналитических решений для своих клиентов, но и как основу внутренней управленческой аналитики, расскажет, как они подошли к решению этой задачи у себя.
🔸Расскажем о том, что обычно остается за кадром: как готовятся данные, как выравнивается логика показателей и как выстраиваются связи между функциями — от маркетинга и продукта до финансов и поддержки
🔸Обсудим, как собрать данные из разных контуров в одну систему координат и договориться о едином подходе к метрикам
🔸Разберем конкретные шаги и решения, которые помогли превратить разрозненные данные в связанную систему
Вебинар будет полезен тем, кто уже сталкивается с ограничениями разрозненной аналитики и ищет способ выстроить более целостный подход к управлению на основе данных.
📍Предварительная регистрация
Вам придет напоминание, а после вебинара пришлем ссылку на запись:)
С ростом популярности данного сообщества G, средний уровень интеллекта этого сообщества приближается к среднему по популяции. Это выведенная мной аксиома, о которой очень важно знать сегодня людям, находящимся в поиске ассиметричного превосходства на рынке чего угодно.
То есть, либо сообщество умных людей глупеет с ростом популярности, либо движение шизов умнеет с ростом популярности.
На рассвете программирования, в 20-м веке, по существующим данным, средний IQ был 130 у типичного нерда в этом деле. По существующим данным опять же, где-то в 2011, и чуть позже, средний уровень интеллекта программиста упал до 115. В 2025 году он упал до 105(это по миру).
Об исходящих леммах хоть книгу пиши. Правило №1 - если нет собственного мнения, то слушать стоит только дедов. Исключения из этого правила конечно же существуют, но пока нет понимания, их остаётся только игнорировать
С внедрением AI сейчас происходит странная штука.
С одной стороны — он уже реально умеет делать работу: писать код, разбирать документы, принимать решения.
С другой — в реальных компаниях он почти нигде нормально не встроен в текущие бизнес процессы.
И дело не в том, что «ещё рано».
Скорее наоборот — его уже слишком много, но он как будто не туда прикручен.
Обычно это выглядит так: есть какие-то процессы, BPM, роли, доступы — всё строго и по правилам. И рядом появляется AI — чатик, copilot, агент.
Им можно пользоваться, но он как бы… вне системы.
ИИ не знает, кто он в компании.
Не понимает, что у него за роль.
Окей, у него есть промпт — но это не гарантированное исполнение и следование инструкциям. Это рекомендация, которую можно нарушить и ничего за это не будет.
Это как сотрудник-зумер — не знаешь, что от него ждать.
В итоге получается странный компромисс:
— либо даём людям пользоваться AI, но тогда теряем контроль
— либо запрещаем/ограничиваем, и тогда теряем пользу
И вот здесь, кажется, и есть основной затык.
Проблема не в самом AI.
Проблема в том, что он живёт отдельно от enterprise-реальности.
Идея Agentic Enterprise в том, чтобы перестать воспринимать AI как что-то внешнее — как инструмент, даже как помощника. Пора ему стать участником процессов.
То есть буквально:
у него должна быть роль в оргструктуре
у него должны права (а не просто втихаря переданные креды)
он получает задачи и выполняет их через те же процессы, что и люди
Что от этого меняется?
Во-первых, появляется контроль.
Любое действие — это часть процесса. Его можно посмотреть, понять, откатить.
Во-вторых, появляется контекст.
AI действует не абстрактно, а в рамках роли, данных и конкретной задачи.
Ну и в-третьих — он перестаёт быть чем-то отдельным.
Это просто ещё один исполнитель.
И, кажется, это довольно важный сдвиг.
Потому что без него AI так и останется либо игрушкой, либо «серым инструментом», который все используют, но никто не контролирует.
А с ним он становится частью операционной модели.
Подписывайтесь на канал Agentic Enterpise — о жизни ИИ-агентов в кровавом энтерпрайзе
На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.
Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 1032. Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.
Другую забавную байку в комментах поведал аноним с одноразовым аккаунтом. Примерно десять лет назад товарищ анонима перешёл на работу в некий стартап в качестве технического директора. Дела у компании шли отлично, бизнес быстро рос, в команде было порядка 200 разработчиков.
В первую неделю новый техдир обнаружил, что в стартапе заведён специальный микросервис для генерации UUID. Все остальные команды были проинструктированы передавать запросы на генерацию «безопасных» UUID именно в этот сервис. Новый сотрудник начал разбираться и обнаружил, что сервис — это запросы в отдельную базу данных, которая и хранила все до этого выданные UUID.
Логика работы микросервиса была простой: в ответ на запрос генерировался UUID, выполнялась чрезвычайно важная проверка на уникальность в этой базе данных, а затем идентификатор возвращался клиенту. Работу микросервиса поддерживала отдельная команда из трёх инженеров с собственными спринтами и канбан-доской.
