Анализируй и проектируй
Привет, Хабр! Продолжаю серию статей по проектированию и разработке отказоустойчивой микросервисной системы сокращения ссылок.
Если вы только присоединились, рекомендую ознакомиться с предыдущими частями:
Новый алгоритм может уверенно выигрывать A/B‑тест и не показывать ожидаемого эффекта после запуска, если эксперимент учитывает только пользователей, но игнорирует общий ресурс. В статье разбираемся, как работают switchback‑эксперименты, почему стандартный анализ даёт ложные выводы и как корректно оценивать результаты.
В комментариях к «Карточному домику из GPU» читатель бросил пруфы: GPU, на которых обучают ИИ-модели, живут от полутора до трёх лет — а в отчётности облаков значатся шесть. Я проверил по первоисточникам — вышло жёстче, чем я писал. Сколько карта живёт на самом деле, что о ней записано в бухгалтерских отчётах и куда она попадает потом — с цифрами.
Обычный день, любимый сервис и рандомная проверка: делюсь своим рабочим кейсом. Как из обычной проверки сервиса, который работал без замечаний, выросла целая задача на дедупликацию данных. Расскажу, в чём была разница между одинаковыми записями, как я искала «ту самую» среди десятков похожих и почему не стоило выбирать поваром Рафаэля только за то, что он последним заходил на кухню.
Всем привет! Я Аня Мавлютова, технический менеджер продуктов Data Governance в Платформе данных в Т-Банке. Работаю в компании больше девяти лет. Начинала свой путь с дата-инженера, последние три года занимаюсь продуктами, которые помогают нашим пользователям работать с данными многократно быстрее и удобнее. В моей зоне ответственности продукты каталога метаданных Data Detective, инструменты Data Quality и сервис управления разметкой чувствительных данных.
В эпоху AI ценность данных компании сильно возросла, на них направлено более пристальное внимание. Процессы operate и observability над данными получили большой фокус: если нет уверенности, что сегодня данные построились в качественном виде, то задачу точно нельзя отдавать агенту. Данных становится в разы больше, поэтому очень важно как можно раньше отлавливать проблемы и ошибки в данных, если они возникли, чтобы предотвратить их увеличение в зависимых процессах.
В статье расскажу, как мы прошли путь от 11 длительных ручных шагов до автоматизации через AI-агента. Почему отказались от low-code-подхода, как работает распознавание intent и почему выбрали агентскую архитектуру вместо цепочки промптов. Спойлер: решение оказалось смелее, чем мы планировали в начале.
Как разобраться в неоднозначных требованиях, согласовать изменения с заказчиком и удержать проект в рамках ресурсов? Эти задачи станут темами INFOSTART A&PM EVENT 2026 — конференции для аналитиков и руководителей проектов 1С, которая пройдет 12–14 ноября в Санкт‑Петербурге.
Программа сформирована: опубликованы принятые доклады и практические активности. Практические форматы займут 70% программы, выступления с разбором проектного опыта — 30%.
В программе пять секций:
В предыдущей статье было описано, как массово находить документы за выбранный период, отменять их проведение и помечать на удаление. Частая задача, а штатных средств для ее решения в программе нет. Мной была создана внешняя обработка, которая в несколько проходов последовательно удаляет доступные ей зависимости между документами, отменяет их проведение и устанавливает пометки удаления.
Однако при испытании обработки на базе с документами производства выяснилось, что существует отдельная группа объектов, с которой такой универсальный алгоритм не справляется. Проблемы возникли с завершенными этапами, производственными операциями, сменными заданиями, а при ремонтах — с отраженными в этапах расходах материалов и работ.
Документы оказались накрепко связаны между собой в замкнутые цепочки: один документ не желает меняться, пока не изменится второй, а второй — пока не изменится первый. Для разрыва таких цепочек понадобилась еще одна — «Производственная обработка».
Рабочее название прототипа: Tender Semantic Engine (TSE)
Если фрагмент оказался неправильным ответом на один вопрос, сначала стоит проверить, не является ли он правильным ответом на другой.
Задача, которая только кажется простой
Я разрабатываю настольную систему для работы с тендерами. Один из ее модулей должен читать комплект закупочной документации и переносить в карточку тендера конкретные условия: порядок оплаты, аванс, срок и место поставки, гарантию, обеспечение, штрафы и другие обязательства сторон.
Обычно один комплект состоит из договора, технического задания, спецификаций, приложений и Excel-таблиц. В текущем контуре обрабатываются Word, Excel и PDF с текстовым слоем. Сканированные документы и OCR пока рассматриваются как отдельная задача.
Сначала кажется, что достаточно регулярных выражений, ключевых слов, классификатора или современной LLM. Но основная проблема не в том, чтобы найти предложение со словами «поставка», «оплата» или «гарантия». Нужно понять, какое действие оно выражает и к какому условию относится числовое значение.
На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Мы много лет занимаемся интеграциями с 1С и другими корпоративными системами. И всё чаще видим ситуацию, когда обмены работают, но любое изменение превращается в отдельный проект: нужно выяснить, какие системы затронет новая логика, где выполняются преобразования и почему данные в разных базах перестали совпадать.
Обычно проблема не в конкретном обмене. Интеграции создавались постепенно, под разные задачи, и со временем между ними накопились зависимости, которые никто не проектировал как единую архитектуру. На примере задач из нашей практики разберу, в какой момент такой подход начинает ограничивать развитие ИТ-ландшафта и когда стоит задуматься об отдельном интеграционном слое.
Когда корпоративное хранилище данных становится слишком сложным, проблема постепенно перестает быть только технической. Сложно не только загрузить данные. Сложно понять, откуда взялся конкретный показатель, изменить расчёт, добавить новый отчет и просто объяснить сотрудниками компании, как все это работает. В нашем случае корпоративный DWH исторически развивался именно таким образом. В результате мы получили систему, которая выполняла свою работу, но становилась все сложнее для анализа, развития и сопровождения.
В статье расскажу, почему мы не стали просто оптимизировать старую систему, как построили новый контур на ClickHouse и XLTable и что произошло после перехода.
Вайб-кодинг уже стал привычным способом разработки: человек описывает задачу обычным языком, а ИИ помогает писать и уточнять код. Но до кода обычно появляются требования, карта процесса и техническое задание. Если этот этап выполнен поверхностно, модель лишь быстрее создаст решение не той задачи.
Для работы аналитика точнее подходит термин вайб-спекинг — диалог с ИИ, в котором исходная идея постепенно превращается в спецификацию: с границами доработки, объектами конфигурации, исключениями, рисками и критериями приёмки.
Главное условие здесь — контекст. Универсальная языковая модель может хорошо оформить документ, но не обязана знать устройство конкретной версии конфигурации 1С. Поэтому полезность ответа зависит не только от промпта, но и от того, есть ли у агента сведения о метаданных и типовых механизмах системы.
В статье разберём, какие задачи можно делегировать такому помощнику и где его выводы всё равно должен проверять специалист.
LLM, агенты, RAG, MCP, Skills, память, промты и harness часто обсуждают по отдельности. Из-за этого одни и те же слова понимают по-разному, а возможности модели путают с возможностями всей системы. В статье я собираю эти понятия в единую схему, показываю связи между ними и на примере RSS-разбора объясняю, как формализация процесса, инструменты, память и контроль делают работу ИИ-системы более управляемой и стабильной.
Мне давно было любопытно разобраться, как в RTB (Real Time Bidding — аукционная закупка рекламы в реальном времени) устроена хайлоад часть. Задача выглядит сложной: от площадок идет поток запросов на покупку рекламы (бид-реквестов), на стороне рекламного движка есть каталог рекламных объектов (кампаний и баннеров в них) со своими таргетингами, и на каждый входящий запрос надо успеть найти подходящие объекты, посчитать ставку и ответить. На весь обмен с биржей дается порядка ста миллисекунд, и в них должно поместиться все сразу — сеть в обе стороны, разбор запроса, подбор объекта, расчет ставки, сборка ответа. То есть на сам подбор остается еще меньше времени.
А еще такая система должна быть подвижной в обе стороны по нагрузке. Трафик у поставщиков не постоянен, он гуляет и в течение суток, и от поставщика к поставщику, так что держать максимальный конфиг под пиковую нагрузку круглосуточно нет смысла. Значит нужна возможность добавлять и убирать мощности, понимая при этом, сколько пропускной способности дает каждая добавленная единица. Спроектировать такое — интересная инженерная работа. Ну это я, как продакт работающий в этой сфере, так считаю :-)
В каждой компании где я работал с рекламными движками (DSP – Demand Side Platform) были свои кастомные решения, свое легаси – не везде можно найти обоснование каждому решению, поэтому мне всегда было интересно, как это устроено у других. Так что я решил разобраться, какие вообще бывают решения — чтобы лучше понимать возможности и ограничения, с которыми имеют дело мои разработчики. Это важно, потому что от выбора хранилища напрямую зависит сколько трафика мы физически способны обработать не отъехав, и что случится (а точнее что мы можем быстро сделать), если завтра нужно будет попросить у поставщика (в рекламе он называется SSP - Supply Side Platform) вдвое больше.
С помощью AI сегодня каждый может навайбкодить приложение за считанные часы. Но чтобы превратить его в рабочий PoC, нужно решить ряд архитектурных, инженерных и организационных задач. Именно они занимают гораздо больше времени и требуют уже других навыков.
В статье разберём типовую архитектуру современного AI PoC на примере моего пет-проекта и ответим на вопрос: если AI умеет писать код, зачем все еще нужен инженер?
В этой части нашего техно-триллера решил поговорить про календари, почту и адресные книги. Здесь, как и в мессенджерах, прямо сейчас активно разбивают Vendor Lock-in через стандартизацию открытых протоколов и антимономопольные суды. И одновременно, на наших глазах формируется новый узел вендор-лока, и стартует новая борьба, теперь за контекст для корпоративного ИИ. В 2026 году Big Tech начинает продавать бизнесу уже не просто почту и календари, а социальный и когнитивный граф, который мгновенно испаряется при любой попытке миграции. Сможет ли связка открытых протоколов JMAP + Matrix (MSC4496) обеспечить бизнесу владение собственным семантическим контекстом?
Обе мои предыдущие статьи про этот сайт с кейсами CS2 заканчивались списком того, чего в нём нет: платежей, депозита предметов, кейс-баттлов, рефералки, KYC. Список закрыт — и почти всё сложное в нём свелось к одному вопросу: что происходит, когда несколько человек одновременно двигают одни и те же деньги. Батл на четверых в одной транзакции, порядок блокировок, из-за которого не случается дедлок, PgBouncer под Prisma и правило чтения с реплики, которое нельзя выразить типом.
Этим летом я проходила собеседование на продакта в компанию, у которой есть свой мессенджер. Среди этапов был System Design, и к нему надо было подготовиться.
Просто изучать архитектуру мессенджера мне было скучно. Ну и я решила заодно забацать себе курс. Чтобы были объяснения, схема, вопросы, можно было потыкать и проверить, что запомнила. В общем, подготовка к собесу немного разрослась. Ахахах.
Получился базовый курс с интерактивным тренажёром по архитектуре мессенджера. Может, кому-то, кто тоже готовится к собеседованиям, пригодится, конечно же бесплатно.
Агент завершил запуск, вернул корректный формат и прошёл автоматическую проверку. Почему этого всё ещё недостаточно для приёмки — и какие отдельные гейты нужны между completion и решением человека.
В одном из проектов мы развернули рабочую версию управленческой аналитики на сервере. Данные приходили из нескольких внутренних систем, часть доступа была организована через API смежной команды, а сверху уже строились витрины и дашборды. Первую версию показали руководству, получили согласование и перешли к дальнейшему развитию.
На этом месте легко поставить мысленную галочку напротив пункта «BI внедрён». Сервер работает, отчёт открывается, цифры можно фильтровать, пользователи получили ссылку. Формально результат есть.
Но через некоторое время платформа обновилась, и часть уже созданных дашбордов потребовала восстановления и переработки. Параллельно продолжали меняться источники, уточнялись показатели, появлялись новые запросы. Отчёт, который вчера был правильным, сегодня мог не обновиться, потерять связь с источником или просто перестать соответствовать процессу.
Я не считаю эту ситуацию особенностью конкретной BI-системы. В нашем случае использовалась Visiology, но похожий сценарий возможен с Power BI, DataLens, Metabase и практически любым другим продуктом. Причина обычно находится не в одной кнопке и даже не в самой платформе. Проблема в том, что дашборд воспринимают как итог внедрения, хотя на самом деле это только пользовательский интерфейс большого контура.
После публикации начинается не завершение проекта, а эксплуатация. И именно в этот момент становится видно, построили мы BI как организационный продукт или просто положили на сервер несколько красивых отчётов.
В предыдущем материале про Орбис я обещал разобрать игровые механики, которые делают эту игру неповторимой в своем разнообразии. Уникальными расами, юнитами и скиллами тоже можно удивить — с точки зрения атмосферы и креативности тут все в порядке. Но принципиально игровая техника «тактического звена» похожа на другие игры. Тут я хотел сделать акцент на глобальные процессы, которые влияют на сюжет и делают его динамичным, а порой и непредсказуемым. Я не встречал стратегий AAA-класса с похожим многовариантным сюжетом. Обычно в играх сюжетная линия идет по плану, максимум слегка разветвляется, а динамика есть следствие относительно линейной ветки развития технологий.
В большинстве 4X-стратегий игровой мир представляет собой статичную доску. Игрок может вырубить лес под ферму или прорыть канал, но в целом мир остается безучастным декоративным фоном для сражения различных фракций.
В модификации Orbis (на базе Civilization IV: Beyond the Sword) разработчик Ahwaric и команда Fall from Heaven II превратили саму карту и физику мира в нестабильную, разрушаемую систему. Здесь планета Эребус (Erebus) может заболеть, покрыться адом или вымерзнуть до экватора — и за этой экологической катастрофой стоит прозрачная математическая модель.
Разбираем, как три системных механики Orbis — Счетчик Армагеддона, климатическое оружие и магическая логистика — создают уникальную военную драму.