Анализируй и проектируй
Tinder — это хороший пример system design задачи, где нужно быстро формировать ленту кандидатов, учитывать геолокацию и пользовательские предпочтения, а также надёжно обрабатывать свайпы и совпадения. В статье разберём архитектуру такого сервиса и узкие места, которые появляются при росте нагрузки.
В предыдущих частях рассматривались аспекты публикации сообщений, ребалансировки консьюмер групп и масштабирования чтения, а также проектирования консьюмеров. Эта часть посвящена базовой структуре сообщений, неподходящим сценариям использования Kafka и гарантиям записи.
Продолжаем серию публикаций «Адаптивное администрирование Sigla Vision». Часть наших подходов будет полезна и другим ИТ-специалистам, которые развивают или сопровождают аналитические системы — особенно те, что хранят метаданные во внешних СУБД.
В этой статье подробно разберем объектную модель BI-системы. Она помогает лучше понимать работу системы, следить за ее состоянием и контролировать изменения.
В предыдущей статье «Адаптивное администрирование Sigla Vision» мы посмотрели на BI-систему «из коробки» глазами тех, кто ее сопровождает: объяснили, зачем нужны дополнительные данные о работе системы и для чего создавать объектную модель, привели примеры задач, где она используется.
Тема нынешней статьи — основа всего нашего дальнейшего опыта работы с Sigla Vision.
Обычно аналитик долго пишет ТЗ, когда пытается делать три вещи одновременно: понять задачу, спроектировать решение и оформить это всё в документ. Это как сервировать праздничный стол, не решив, что будете готовить, и параллельно искать рецепт в интернете. В голове разные интеллектуальные процессы смешиваются в одну кучу и возникает ступор.
На связи Ольга, бизнес-аналитик в Outlines Tech. Расскажу, как я погружаюсь в новую задачу, чтобы составить техническое задание за 30 минут. По моей методике 80% работы над ТЗ — понять и договориться, 20% — зафиксировать всё в документ. Так не придётся торопиться и придумывать текст с нуля или вносить правки на ходу.
Большинство продуктовых дискуссий о ценности заканчиваются на «пользователю станет удобнее». Это не ценность, а ее отсутствие, прикрытое словом «ценность».
Разбираю на живом кейсе T&S Циана, как разложить это слово на пять координат, и какая асимметрия вылезает за 5–6 часов работы.
Александр Козуб. CPO в финтехе. В симптомах вижу систему.
В статье рассмотрим, почему эволюционная архитектура и модульный монолит превосходят современные архитектурные подходы. Обсудим, в каких случаях стоит отказаться от микросервисов, как документировать архитектурные решения с помощью ADR и какие методы помогают спасать проекты.
Проект автоматизации склада согласован. Бюджет выделен. Поставщик решения уже выбран или находится в шорт‑листе. Запуск намечен на следующий квартал. Следующий квартал наступает, и дата сдвигается снова. Потом ещё раз. Потом появляется новый блокирующий фактор, который выглядит абсолютно объективно.
Для этого явления есть название — синдром вечного пилота. Это состояние, при котором WMS, роботизация или другая складская автоматизация формально есть в планах компании, но де‑факто не движется с места уже год, два, три. Склад работает «как всегда»: объёмы растут, персонала не хватает, а стоимость операционных ошибок постепенно становится привычной строкой в P&L.
Привет, Хабр! С вами команда Russtech — разработчики IT-решений ведущего российского оператора рекламы вне дома Russ. 13-14 марта 2026 года компания RWB (Объединенная компания Wildberries & Russ) совместно с Национальным исследовательским ядерным университетом «МИФИ» провела командный хакатон на территории университета. Студенты решали бизнес‑задачи из сферы рекламы вне дома, создавали прототипы цифровых инструментов и представляли свои наработки экспертному жюри. Рассказываем, как это было.
Сейчас рынок складской роботизации во многом строится на китайских роботах и готовых аппаратных решениях. И в этом нет ничего плохого: у китайских производителей сильная инженерная база, большой выбор техники и понятная экономика.
Но у такого подхода есть важная особенность, о которой часто вспоминают уже после покупки. За последние несколько лет мы не раз сталкивались с ситуацией, когда заказчик в попытке сэкономить фактически приобретает дорогой металлолом.
Логика на старте понятная:
Привет, Хабр! Меня зовут Данила Ляпин, я Senior Data Scientist в Яндексе и автор курса «Специалист по Data Science» в Яндекс Практикуме.
В современном мире анализа данных пользу библиотеки Pandas трудно переоценить — она используется везде экспертами любого уровня: от стажёров до техлидов, а последние годы это де-факто стандарт в аналитике.
У Pandas есть огромная экосистема с большой базой знаний и интеграциями в различные библиотеки (тут и встроенная визуализация от matplotlib, и переход к данным в numpy формате, и много чего ещё). Практически каждый разведывательный анализ данных начинается с таких слов, как: read_csv, describe, head, isna().sum().
Но объём данных растёт ежегодно, память дорожает, а пайплайны усложняются. Чтобы загрузить локально большой датасет и обработать его, приходится не один раз словить "kernel crashed". И вот на этом моменте самое время поговорить про Polars, потому что там с этим как раз всё в порядке (и не только с этим :-)
Статья о том, как решить проблему «забывчивости» LLM между AI-сессиями разработки. Рассматривается причина деградации контекста и предлагается практический подход с использованием ai_readme файлов и агентских хуков, которые принудительно возвращают модель к важным инструкциям. Материал ориентирован на опытных промт-инженеров и показывает, как повысить стабильность и качество генерации кода в реальных больших проектах и при больших контекстных окнах.
Почему одни User Story работают как часы, а другие становятся источником бесконечных багов и ночных звонков? За годы работы в FinTech собрал коллекцию типичных ошибок, из‑за которых команды теряют драгоценное время. В статье — живые кейсы, наглядные диаграммы, разбор INVEST и практики Three Amigos, которые снижают число дефектов. Рассмотрим, как превратить сырую идею в зрелую User Story с чёткими критериями приёмки и нефункциональными требованиями.
Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».
Локально всё работает идеально: политики ловят нарушения, логи пишутся, система стабильна.
В проде Kubernetes‑кластера — теряются события, появляются дубли, а дедупликация ломается от одного скрипта.
Разбираю реальные проблемы, с которыми мы столкнулись при интеграции Tetragon и eBPF в реальный ИБ продукт, и почему Kubernetes ломает наивные предположения.
Agile и системная инженерия часто описывают так, будто это два несовместимых подхода.
С одной стороны — короткие циклы, быстрые гипотезы и готовность менять решение по мере появления новых фактов. С другой — требования, архитектура, интерфейсы, верификация, эксплуатация, риски и все то, что не помещается в backlog.
На практике сложные системы плохо живут в любой из крайностей. Если опираться только на жесткую последовательность этапов, команда слишком поздно узнает, как система ведет себя в реальности. Если опираться только на короткие итерации без дисциплины описаний и решений, наблюдения быстро теряются, а изменения начинают расходиться между собой.
Именно поэтому выход ISO/IEC/IEEE 24748-10:2026 выглядит важным событием. Это первая редакция стандарта из серии 24748, полностью посвященная systems engineering agility. Документ не предлагает «внедрить Scrum в системную инженерию», а задает стратегические аспекты гибкости и рекомендации по их выбору и применению.
Главная мысль стандарта, на мой взгляд, звучит так: agility в системной инженерии — это не набор ритуалов, а стратегическая рамка, делающая жизненный цикл отзывчивым к неполному знанию и изменяющейся операционной среде.
Если вы видели «С этим товаром покупают…», «Попробуйте этот урок дальше» или ощущали необычную точность автоподбора треков в музыкальных сервисах — вы сталкивались с рекомендательной системой.
Но стоит ли конкретному бизнесу вообще её строить? И если да, то с чего начать, чтобы не потратить впустую месяцы инженерного времени на «чёрный ящик», который никто не понимает?
Эта статья написана мной РУКАМИ (не «ИИ») и основана на моём выступлении‑вебинаре для инженеров, предпринимателей и продуктовых специалистов. Я не ML исследователь и не публичный спикер — я фулстек‑разработчик, который создавал и поддерживал рекомендательные системы в разнообразных коммерческих проектах.
Целевая аудитория — все, кому интересна эта тема.
Меня зовут Андрей Рыжик, я разработчик BI в компании «Белый код». Это четвёртая статья из серии, в которой мы изучаем российские BI-системы с поддержкой ETL для клиентов из малого и среднего бизнеса с бюджетом 1,5-2 млн рублей. Сегодня разбираем Biplane24.
Понимание данных прошло эволюционный путь от структуры хранения информации до ключевого элемента в конкурентной борьбе. Сегодняшние информационные технологии, такие как: искусственный интеллект, машинное обучение, предиктивная аналитика, рекомендательные технологии, существуют благодаря большим данным, анализу данных и стремительному развитию вычислительной техники.
Раньше все было иначе. Изначально данные рассматривались как составной, но обязательный элемент компьютерной программы, наряду с командами и алгоритмами. Постепенный функциональный рост софтверных программ от приложения до программного обеспечения, программной системы, информационной системы и корпоративной информационной системы менял взгляд на данные. Уходя от рассмотрения данных только лишь в контексте нормализации данных и СУБД, акцент последовательно перешел к вопросам миграции данных, поддержания их качества и, наконец, бизнес‑процессу управления данными.
В этой статье мы поговорим о том, как работать с мировыми финансовыми данными через Yahoo Finance и как получать котировки с российских площадок — Московской биржи и Тинькофф Инвестиций.
С чего начинается Родина для искусственного интеллекта? С датасета на русском языке? С гигантских кластеров H100, закупленных по параллельному импорту? С вывески корпорации на фасаде модели, архитектуру которой придумали в Google? Родина начинается с отказа от вероятностей. С собственных чертежей. С опоры на национальную научную школу.