Анализируй и проектируй
Первый день Летнего ТехФеста — в нашем влоге
В офисе ИнфоТеКС мы открыли Летний ТехФест и провели воркшоп по 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 база данных содержит больше записей, так как момент в прошлом уже завершен