Анализ и проектирование систем *

Всем привет! Меня зовут Алёна, я руководитель группы аналитики отдела Compliance и безопасности данных в Ozon. Звучит длинно, поэтому мы с командой называем себя просто датасеками — от Data Security. В информационной безопасности я почти 13 лет, из них 4,5 года в Ozon. До этого больше восьми лет работала в интеграторе и занималась в основном персональными данными и банковской безопасностью — вопросами чистого compliance. Сейчас у меня команда из 11 человек, и мы занимаемся безопасностью данных в Ozon.

Сегодня хочу поговорить об одной важной теме — аудитах безопасности данных. Речь не про пентесты, нет, у нас совсем другая история. Мы смотрим на безопасность данных — и персональных, и финансовых, и любых других данных, которые нужно защищать по требованиям закона, компании или здравого смысла. Расскажу вам о сложностях и о том, как мы с ними справлялись.

В проектах у аналитика обычно есть знакомый набор инструментов: нотации, шаблоны требований, чек-листы, правила описания процессов. Но реальная задача редко укладывается в них полностью.

За сформулированным требованием может скрываться другая потребность. При проектировании интеграции приходится одновременно учитывать производительность и отказоустойчивость. А иногда нужно разобраться в нетиповой системе, которую несколько лет дорабатывали без актуальной документации.

В таких ситуациях важнее не знание конкретного шаблона, а способность разобраться в контексте, увидеть ограничения и выбрать подход. Этому посвящена секция «Прикладные компетенции аналитика» на INFOSTART A&PM EVENT 2026.

Всем привет! Я Ольга Матушевич, преподаватель курса «Нейросети для бизнеса», а в прошлом наставница на курсе «Аналитик данных». Про то, что нейросети «отберут работу», написаны тысячи текстов и сняты сотни роликов. Про обратную сторону — какие вакансии ИИ создал и где рынок труда вырос — говорят реже и обычно без цифр. Чтобы это исправить, я собрала и обобщила данные отечественных и зарубежных источников за 2025–2026 годы и написала эту статью. К сожалению, найти зарубежные источники оказалось проще. Поэтому в статье мало конкретики «как оно сейчас в России», но много информации о мировой динамике рабочих мест или динамике конкретно в США.

Что, если нужную книгу больше не нужно искать — её можно собрать под собственный вопрос?

Я проверил эту идею на реальном корпусе: 206 длинных видео, 160 часов 56 минут и 2,15 млн слов транскриптов.

Вместо сотен summary я построил конвейер, который выделяет сущности, схлопывает дубли, отслеживает происхождение выводов, проверяет важные утверждения и понимает, когда оставшиеся источники уже не нужно читать подряд.

По ходу выяснилось, почему 9 URL могут оказаться одним источником, почему векторная кластеризация не решила задачу смысловых дублей, чем такой подход отличается от RAG и почему длинная работа ИИ-агента неожиданно начинает напоминать разработку обычной программной системы.

Но главный вывод оказался шире самого проекта: единицей работы с информацией может становиться не источник, а наш вопрос.

Корпоративную НСИ не всегда можно «сначала почистить», потому что иногда единого корпоративного объекта данных ещё нет. Разные системы могут содержать разные, но обоснованные части одного объекта. Тогда задача проекта – не выбрать самую удобную базу, а определить, где возникает каждый значимый факт, кто отвечает за его смысл, какой источник считается авторитетным и кто завершает спор. Эту неопределённость удобно разбирать через карту источников и ответственности за данные.

В этой статье я постараюсь объяснить, как работает биткоин. Без аналогий с добычей золота и прочих глупостей.

Начать стоит с того, что он вообще из себя представляет. Биткоин, это одноранговая (P2P) сеть которая формирует механизм глобального консенсуса, который позволяет всем узлам сети договориться об общем состоянии леджера и дает возможность локально проверить весь этот леджер, не доверяя никому. Это система где есть только пользователи и нет администраторов. Это permissionless система, то есть вам не нужно ничье одобрение чтобы в ней участвовать. Используется эта система для формирования глобальной системы денег. Леджер хранит всю историю транзакций за все время, формируя цепочку блоков транзакций - блокчейн.

Если по-человечески то биткоин это просто глобальная универсальная книга бухгалтерского учета, где навсегда фиксируются все взаиморасчеты, где нет возможности смухлевать, отменить или оспорить перевод или создать деньги из воздуха.

Биткоин это не первая попытка создать систему такого рода, но ему первому это удалось. Биткоин решил две ключевые проблемы, которые до этого не удавалось решить никому.

Для понимания его устройства стоит начать стоит с криптографических примитивов, из которых он собран. Как только у вас будет понимание того, как каждый из них работает, понять устройство биткоина будет гораздо проще.

В его составные части входит:

Почему одни идеи превращаются в востребованные продукты, а другие так и остаются красивыми презентациями — или мемами про очередной B2B AI SaaS? Часто проблема не в технологии и не в качестве реализации. Команда может отлично сделать то, что пользователю на самом деле не нужно.

В IT легко начать с готового ответа: «сделаем экспорт», «добавим ещё один экран», «автоматизируем этот сценарий». Дизайн-мышление предлагает на время отложить решение и сначала разобраться, какую проблему мы вообще пытаемся решить.

Меня зовут Лера, я технический писатель в Авито. Я продолжаю разбирать книги, идеи из которых помогают по-новому посмотреть на работу, команды и создание продуктов. Сегодня поговорим о книге Тима Брауна «Дизайн-мышление в бизнесе».

Для айтишников здесь есть вполне практичная польза. Чем сложнее и дороже разработка, тем важнее раньше понять, правильную ли задачу мы вообще собираемся решать. Дизайн-мышление не учит писать код или проектировать системы — оно помогает не потратить месяцы на качественную реализацию идеи, которая изначально никому не была нужна.

Исправное устройство успешно обновилось, доказало своё здоровье, а через два перезапуска откатилось на старую прошивку. Причина оказалась вообще не в обновлении: в тот раз наш бэкенд отвечал три минуты вместо одной.

У нас парк ARM‑устройств: удалённое обновление ядра, A/B‑слоты, автоматический откат. Казалось бы, схема известная, готовые движки есть, документация написана. Сам движок действительно поехал за неделю. Потом полтора месяца мы выковыривали дефекты, которые не падали, ничего не писали в лог и не ловились обычными тестами.

Ниже — семь самых поучительных случаев. И у всех одна форма: каждая проверка утверждала больше, чем на самом деле доказывала.

Устройство говорило «обновился», проверив доставку обновления, а не его применение. Или: «я здоров, братан, проверяй», глядя на факт запуска, а не на работу прошивки. Или: «версия 0.0.17», потому что это было написано в манифесте бэкенда, а не потому, что именно эта версия реально крутилась на железе.

В итоге — как с нашим правительством: свою работу оценили на отлично, а эксперимент, очевидно, неудачный.

На входе у нас вакансия, на выходе — проверенный контакт в одной из трёх кампаний. Между ними: дубли, таймауты, catch-all, неоднозначные SMTP-ответы и окно, в котором процесс может упасть после передачи контакта, но до сохранения статуса. Показываю, как мы расставили дешёвые и дорогие проверки и почему выбрали at-least-once.

Есть класс ошибок, которые невозможно найти простой сверкой. Не потому, что данные хорошо спрятаны, а потому, что искомого состояния нет ни в одной системе. Оно собирается на лету из двух правильных половинок, каждая из которых по отдельности абсолютно валидна.

Хочу рассказать про случай, где в одном стартапе мы искали причину две недели, но при этом мониторинг всё это время показывал, что всё в порядке, и формально он был прав.

Благодаря искусственному интеллекту код удешевился. Но ошибочные архитектурные решения остаются такими же дорогими, как и раньше.

Время от времени я спорю сам с собой о том, какие аспекты программной инженерии остались особенно важными в наше время, когда ИИ бегло пишет код. Вывод, к которому я прихожу, не понравится многим опытным разработчикам. Паттерны реализации, на усвоение которых мы потратили годы, стремительно обесцениваются. Но что насчёт умения структурировать системы в духе правильного проектирования? Это умение становится всё более, а не менее востребованным.

Давайте объясню это на конкретном примере. Система электронных продаж, написанная на Java — как раз такая штука, с которой большинство бэкендеров сталкивались хотя бы раз на протяжении карьеры.

Недавно я написал свою систему распределённой обработки задач. Сначала это был учебный проект. Мне хотелось лучше разобраться в очередях задач, координации воркеров, блокировках строк в PostgreSQL, retry‑механизмах и планировании фоновых задач.

Когда основная функциональность была готова, я понял, что не знаю, как система ведёт себя под нагрузкой.

Поэтому вместо того, чтобы добавлять очередную фичу, я решил провести простой эксперимент. Взять одинаковый набор задач и постепенно увеличивать количество воркеров.
Первые результаты выглядели именно так, как я ожидал. А потом масштабирование внезапно остановилось.

Увеличение количества воркеров с 16 до 32 практически не дало прироста производительности, а при 64 воркерах ситуация стала ещё интереснее: задачи, которые должны были выполняться около 0.5 секунды, начали занимать больше секунды.

Первой моей мыслью было, что я упёрся в PostgreSQL.
Оказалось, что нет.

Отчёт пользователя вскрыл утечку между диалогами в query-провайдере ядра — 6 из 6. Что ещё в 3.6.0: AS2/EDI, общий Kestrel, Camel-паритет.

Год стек рос на наших собственных задачах: мы писали то, что нужно было нам, и проверяли на своей проде. С весны им начали пользоваться посторонние люди — и характер входящих сообщений изменился. Вместо «а поддерживаете ли вы X» приходят разборы: воспроизведение, номера строк в наших исходниках, обходные пути, которые человек уже написал у себя, пока ждал ответа.

Это самое ценное, что может ...

Спойлер: нет, я не про пандемию

Всем привет! На связи Саша Петрушин, я руковожу группой разработки в центре разработки и машинного обучения компании «Инфосистемы Джет».

Недавно я нашёл старый черновик статьи, которую так и не опубликовал с 2020 года — про фронт личного кабинета крупного портала. Перечитал и вспомнил, насколько это было круто и адово.

Дисклеймер: в этой статье – теория, как проект мог измениться в 2026 году. ИИ-агенты — это другие требования к информационной безопасности. Используйте их разумно.

В марте, в разгар локдауна, я пришёл в команду пятым разработчиком: Angular 1.4 с Backbone, переписывание на React, виджеты, 2400+ сценариев подачи заявлений. Потом мы расширили команду до двадцати фронтендеров.

В общем, поностальгировал по команде и ощущению «мы же это реально сделали».

А после задался двумя вопросами.

Как бы я решал ту же задачу сейчас?

И что вообще изменилось в реальной экономике поставки продукта за последние пять с лишним лет?

Привет! Меня зовут Алиса, и сейчас я руковожу командой разработки продукта «Штурвал». У нас работает около пятидесяти человек:  инженеры,  безопасники,  девопсы, фронтендеры, бэкендеры на Go и тестировщики, которые ломают всё, что мы строим. Но сегодня я хочу рассказать не о них. Сегодня балом правят аналитики. И под катом объясню, почему. 

На старте почти любого проекта бизнес-аналитик оказывается в одной и той же ситуации. Бизнес говорит: «клиент может иметь несколько договоров», «договор относится только к одному клиенту», «товар идентифицируется артикулом».

Эти формулировки понятны предметным экспертам, но в таком виде их не передашь архитектору данных или команде разработки — для них это еще не техническое задание. Неясно, где здесь сущность, а где значение, что будет идентификатором, какие ограничения критичны, а какие можно оставить на уровне процессов.

На этом шаге аналитик становится переводчиком между двумя мирами. Нужен промежуточный слой — формальное, проверяемое описание предметной области. Таким слоем часто становится концептуальная модель данных: она помогает согласовать термины между бизнесом и ИТ, зафиксировать правила до проектирования таблиц и API, увидеть противоречия и пробелы в требованиях, отделить смысл данных от будущей технической реализации.

Меня зовут Вадим Скляров, я бизнес-аналитик проектного офиса МТС Медиа. В этом материале расскажу, почему для этой задачи я выбрал ORM2 в качестве инструмента концептуального моделирования, какие приложения есть на рынке, почему в итоге понадобилось собственное SPA-приложение и чем оно оказалось полезным.

Распределенная система может сломаться так, что по отдельности все ее части будут выглядеть исправными.

Представим обычную оплату заказа: сервис отправил запрос платежному провайдеру, тот списал деньги и вернул успешный ответ. На обратном пути соединение оборвалось. Для платежной системы операция завершена, а сервис заказа получил тайм-аут и не знает, произошло списание или нет.

Самое очевидное решение — повторить запрос. И получить второе списание.

В монолите подобные ситуации встречаются реже: операция обычно проходит внутри одного процесса или одной транзакции, поэтому место сбоя проще определить. В распределенной системе между началом и концом одной бизнес-операции могут быть несколько сервисов, брокер сообщений, разные базы данных и внешний API (интерфейс программирования приложений). У каждого компонента при этом свое состояние и свое представление о том, что уже произошло.

Так, проверки «отправили запрос — получили ожидаемый ответ» здесь недостаточно. Интереснее проверить, что будет, если ответ задержится или потеряется, запрос придет повторно, события поменяются местами, а один из сервисов восстановится после нескольких минут простоя.

В таких ситуациях проявляются ошибки, которые сложно увидеть на happy path (позитивном сценарии). Ниже разберем, как их воспроизводить и что проверять, чтобы отказ одного компонента не превращался в некорректное состояние всей системы.

Почему распределенную систему нельзя тестировать как обычное приложение

Возьмем простой пример — оплату заказа в интернет-магазине.

За год экспериментов мы выяснили, что традиционное обучение почти не повышает adoption, а количество пользователей ещё ничего не говорит о бизнес-эффекте. Агенты могут написать от 80 до 99% кода, а могут за 12 часов разрушить архитектуру проекта. Мини-команда из двух разработчиков и бизнес-эксперта с помощью ИИ может сделать интеграционный сервис так же быстро, как команда из пяти человек, но Lead Time при этом может остаться прежним.

Внедрение подхода показало, что написание кода больше не главное узкое место. Теперь всё упирается в качество спецификаций, доступный агенту контекст, интеграции и способность команды перестроить привычный процесс работы.

В статье расскажем, как трансформируются роли и команды, какими метриками измерять реальный прогресс, где теперь находится узкое горлышко и что нужно построить вокруг агентов, чтобы превратить отдельные удачные эксперименты в системный результат.

Автоматизация в n8n может собраться за полчаса, а через несколько месяцев превратиться в процесс, который страшно менять.

В статье — 9 ошибок проектирования и внедрения, из‑за которых такие сценарии становятся хрупкими, дорогими в поддержке и плохо передаются другим.

Двенадцать лет незнакомые люди ставили друг другу баллы от 1 до 10. В базе накопилось 24 миллиона оценок от 110 тысяч человек из 232 стран. Мы залезли в собственный PostgreSQL и нашли четыре вещи, которых не ожидали: провал на девятке, разрыв в 1,14 балла в том, как мужчины оценивают мужчин, разброс по странам в 2,4 балла и падение щедрости по ходу сессии.