2025-11-13: ArchDays - ИИ и архитектура

Версия 11:46, 13 ноября 2025

Конференция Archdays проходит с 2019 года, а я на ней был в четвертый раз. Это — интересная площадка. Организаторы собирают архитекторов из крупного Enterprise, и это дает возможность заглянуть внутрь. На открытии Сергей Баранов дал ретроспективу развитие тем на конференции. Начиналось все с микросервисов, затем шло повышение уровня абстракции: архитектурные паттерны, технический долг, архитектура как экосистема в целом. А в этом году темой был ИИ, встройка которого в ИТ-ландшафт порождает много новых типов проблем — и с ними надо разбираться.

В докладах конференции много фактуры, которую не так часто показывают, например, в этом году Александр Войновский и Олег Зоткин из Газпром Нефть показали свои архитектурные схемы включения приложений с ИИ в ИТ-ландшафт. Презентации уже опубликованы, так что эти схемы можно увидеть.

А у меня — обзор докладов, среди которых я еще хочу упомянуть рассказ про ИИ на минималках Павла Кана из Greensight и рассказ Руслана Серкина о том, какие технические долги ИИ помогает разгребать, а какие — приносит. Еще был любопытный доклад Павла Кутакова из VKTech про простую архитектуру, которая, однако, не исключает масштабирования, а также доклад Сергея Баранова, посвященный экономическим последствиям архитектурных решений со множеством примеров критериев выбора. Конференция — один день, три трека, так что в обзоре всего треть докладов конференции, учитывайте это.

Но до обзора повторю то, что я писал в [отчете о Highload]: ИИ перешел из стадии создания отдельных приложений в один из элементов в архитектуры приложений. Приложений с ИИ — много, и они уже встраиваются в архитектуру предприятия регулярным образом. При этом могут быть использованы как стандартные системы, так и собственные, в том числе возможны дешевые решения, об этом был доклад. А еще использование ИИ встраивается в pipeline разработки как отдельные шаги, об этом были доклады и здесь, и на Teamlead.

Александр Войновский и Олег Зоткин из Газпром нефть. Эффективная архитектура ИИ для цифровизации производства

Этот доклад — возможность заглянуть в архитектуру крупного Enterprise и способы встройки в нее ИИ-приложений. Газпромнефть работает в этом направлении уже давно, и таких приложений много. Поэтому уже наработаны типовые схемы их встройки, включая переход от DevOps к ML-ops конвейеру и обеспечение надежности решений при непредсказуемости поведения.

Я просто выпишу те схемы, которые сам разглядывал в презентации после конференции. Схемы — сложные, так что в выступлении они не рассказаны, но они содержательные, их можно смотреть, использовать для сопоставления с другими ИТ-ландшафтами.

1. Capability map ГПН, отражающая ИТ-ландшафт
2. Применение ИИ в ИТ-ландшафте с подсветкой соответствующих квадратов
3. Мапинг проектов ИИ на карту технологий.
4. Инструментарий разработки и типовая схема фаз проекта для приложения с ИИ
5. Обзор рынка инструментов и платформ MLSECOPS
6. Архитектурные схемы приложений с ИИ, их встройки в ИТ-ландшафт

А помимо схем в рассказе был ряд практических вопросов: сопоставление RAG и дообучения с примерами (в своих проектах они используют оба варианта), правила распределения инфраструктурных ресурсов и способы оптимизации и так далее.

А теперь — краткий конспект доклада.

В начале — схема развития: Идея AI (1960-е) — Machine Learning (разные распознавалки) — Deep Learning — Generative AI (порождение текстов, рисунков, музыки) — LLM

Текущие индустриальные тренды.

• многофункциональная робототехника
• интернет вещей — датчики и прочее
• развитие биопечати
• квантовые вычисления
• кибербезопасность нового уровня
• расширенная реальность (XR) — вслед за AR и VR
• ИИ — создание моделей под конкретный бизнес, ML-ops конвейер, мультиагентные системы.

Цифровая стратегия ГПН — ответ на вызовы. И сейчас они на третьем этапа: внедрение ИИ, цифровых двойников и роботизации.

Они выделяют инженерный ИИ, который отличается от внедряемого в корпоративных функциях, где более легкие задачи. Модель бурения на 4 км — гораздо сложнее, например, подбора персонала. Этим занимаются отдельные подразделения. Направления: моделирование и проектирование, операционное управление, принятие решений.

Дальше — схемы: capability map нефтегазовой компании от поиска и нефтеразведки до сбыта, деление по доменам и места ИИ на ней. И мапинг проектов на карту классов ИИ — чтобы объяснять бизнесу что конкретно и где внедряется.

Брать ли для внедрения модель от вендора или строить свою на основе open source? У open source — плюсы, главное — безопасность, но есть проблема поддержки развития модели.

Я бы тут добавил, что развитие открытых моделей можно заказать, как заказывают развитие PostgreSQL. B это — правильно: не просто брать open source на халяву, а возвращать полученное вкладом в развитие.

Под индустриальные задачи стандартных моделей не достаточно. LLM из коробки не владеет специфической терминологией, например, не отвечает про особенности нефтедобычи при обводнении слоя (хотя научные и инженерные работы по теме она знает). Есть несколько способов доводки: дообучение, RAG и создание агента.

Поэтому арсенал средств разработки приложений дополняется инструментами работы с ИИ. Они используют много инструментов, на слайде был список по категориям: работа с признаками, разметка и тегирование, разработка моделей, безопасность, автоматизация процесса разработки, эксплуатация приложений с ML-моделями. Примеры — Lite LLM для оркестрации и выбора направления маршрутизации запроса, GoldTrace AI для цензурирования запросов и ответов, Fist для работы с признаками, она позволяет группе команд работать сообщим датасетом, и так далее.

Дальше были архитектурные диаграммы. Layer-схема пользователи — бизнес-решения — Сервисы (набор переиспользуемых функциональностей) — ML-платформа для разработки моделей, референсная архитектура приложений GenAI — функциональная архитектурная схема. И разбиралась оптимизация использования инфраструктурных ресурсов: резервирование карт, деление по ядрам и TimeSlicing, маршрутизация запросов и балансирование нагрузки, и внедрение инструментов, сервисов, библиотек, оптимизированных на GPU, которое дает рост на порядки, в 10-1000 раз.

Они ведут реестр ML-моделей, выполняют регулярный скаутинг рынка по классам технологий или запросам бизнеса. И при появлении нового — оценка по сравнению с имеющимися через ИИ-радар, например, для GenAI — по бенчмаркам качества и стоимости. Если новая модель оказывается сопоставима с используемыми, то не расширяем зоопарк, а если лучше, то идет оценка внутри: ставим, проверяем ИБ, проверяем на синтетических данных и принимаем решение.

И у них появилась новая специализация — citizen data scientist: сотрудник-не-программист использует ИИ в работе за счет low и no code инструментов работы с данными.

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

Вопросы.

• Как определяли метрики? Так же, как и с другими инициативами компании, бизнес-метрики — те же самые. А инфраструктура — отдельная программа, которая должна сделать возможным агентов, и там тоже проектные метрики.
• Когда появляются платформы? Начинается с решения конкретных задач. Тут есть консалтинговая модель зрелости, когда включается стратегический уровень, а не точечные проекты, как в начале. Платформы — на этом этапе, мы дошли. И в компании шло эволюционно: DevOps — Платформа и онтология данных — ML-ops
• Кроме архитекторов кто использует busness capability? Ответ: это — инструмент общения с бизнесом и с коллегами из других компаний.
• Сколько времени ушло? ML-ops конверйер и 1-2 линия приложений — 1.5 года, участвует департамент разработки, центр компетенций ИИ, центр компетенций инженерного ИИ. И много треков, в которых участвуют разные люди, включая ИБ и разработку, и звдвча как раз выстроить сложный процесс.
• Про модели. На слайдах были компоненты — сервис цензурирования и другие. Это из коробки или надо сделать? Ответ — зависит от пути компании. Если покупаете платформу, такие есть — то там сервисы из коробки. Если платформу делаете сами — то надо собирать.
• Сколько успешно внедренных решений? Ответ. У них есть сито гипотез, они собираются на портале, и дальше их могут отсеять до разработки через экспертную оценку бизнесом потенциальной пользы и техническим специалистов по реализуемость, тут отсев идей может быть довольно большой. Если же смотреть на те, которые прошли до этапа разработки, то больше половины доходит до внедрения.
• Управление онтологиями. JetBrains composer, Protege — их посмотрели. Сейчас есть проект, который делают на основе одной из отечественных платформ.

Павел Кан из Greensight. ИИ своими силами: реальный кейс разработки без миллионных инвестиций

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

Они решили сделать легкие специализированные модели, заточенные под конкретные задачи, чтобы эксплуатация была дешевой. Этой цели они достигли: начинали с одной видеокарты, сейчас у них арендованы две T4A100 — продакшн и разработка, а для обучения моделей используют аренду spot-instance под конкретные задачи. Общие затраты на инфраструктуру — 100 тысяч в месяц, и она обслуживает сайты нескольких клиентов (количество я не записал).

Как это устроено, Павел разбирал на задаче создания внятного описания товара по его фото. Принцип fail fast feedback. Делают простой прототип: ты ему картинку, он дает описание, ты оцениваешь. Людям интересно поиграть с ИИ один вечер. Отправляли в общий чат компании — поиграть интересно, собирали кучу кейсов, и дорабатывали.

Основная идея — каскад маленьких моделей вместо большой, они работают быстрее и дешевле, для распознавания по фото сначала его одна модель обогащают контекстом, ставит теги. А уже другая — создает описание. Ткань по фото модель определяет плохо, но если ей подсказать, что на фото — летнее платье или красный диван, то уже приемлемо. Поэтому сначала одна модель распознает что там и обогащает, вторая создает описание, а третья — его причесывает. Бывают более длинные цепочки, есть потоки, когда один контекст отправляют в несколько разных моделей, а потом объединяют результат еще одной.

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

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

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

Для сложных задач категоризации часть проверяют люди: 100 загрузили 20 из них проверили, до того, как результат будет выкачен на продакшн сайта. А поиска по фото сразу выкатывают на фронт, он простой.

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

Специализированные модели — разные, как примеры были Vikhr models и Mulilingual-e5, а для оценки — Qwen 2.5-V. Qwen — потому что результативный тип модели, а не ассистентный, и она доступна для локального развертывания. Но он — тяжелый, на одной карте может работать не более двух инстансов, а легких моделей — одновременно 15 штук под разные задачи. Поэтому и используют легкие. НО подробнее про экономику расскажут в следующем году, потому что пока эксплуатации полгода.

В презентации — архитектурная картинка, как это все работает, вполне понятная: Airflow, ML-flow, s3 для датасетов, артефактов, и состояния spot-instance, и набор моделей. Смотрите.

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

Ресурсы видеокарты — поделены, Airflow и Kubernetes всегда сначала запускает check памяти, и только если ее достаточно, то контейнер с запуском. Если недостаточно — ждем ресурсы. Есть выделенные видеокарты на постоянной основе, и есть пул в датацентре для дообучения и оценки. Пул — spot instance — прерываемые ресурсы, которые датацентр может забрать, он непредсказуем и его доступность — разная. И они сборку контейнеров адаптировали под доступную карту, запускают образ, собранный для конкретной выделенной карты — cost optimazed deployment. Все это обеспечивает pipeline на уровне инфраструктуры: есть задачи с приоритетом, для задач клиента — вип-пропуск, остальное по запросу и квота по ресурсам. Для каждой модели есть требования по памяти и времени, это зафиксировано в пайплайне и учитывается при работе в ограниченных ресурсах. Разработка заняла полгода от идеи до модели.

Руслан Серкин из МТС Web Services. Архитектор и ИИ: Управляем старым техдолгом и создаем новый

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

ИИ может убрать второй тип долга. Способы управления сейчас: архитектурные комитеты, ADR для фиксации решений, техрадар и кодревью. Работает, но требует времени и дисциплины, ИИ тут может помочь с проверками и анализом.

Этапы развития ИИ: 2015—2020 — подсказки в IDE. 2020—2023 Copilot, обученная модель может создать функцию; сейчас рефакторинг и вайб-кодинг, и ее можно использовать для управления архитектурой.

ИИ — новый сотрудник, который работает 24/7, знает документацию и литературу, но не знает контекста работы. И первый долг, который можно разобрать с помощью ИИ- долг по незнанию. Начинающие разработчики помнят первый язык и первую базу, и используют приемы работы с ней, хотя новые технологии умеют больше. Например, есть каталог товаров, мы нормализуем и сложно храним, добавление нового атрибута вызывает боль. А PostgreSQL может хранить Json и эффективно работать с ним, ИИ это знает. Или когда есть стартап, есть команда, которая готова учиться, но времени нет, поэтому она выбирает неверные решения — ИИ может вести ревью на постоянной основе, если опытный разработчик настроит промпты и системы правил.

ИИ помогает принимать решения. ADR — инструмент, который описывает проблему и решение. Получаем сравнение инструментов в контексте проблемы и фиксируем не только решение, но и его основания. И ИИ может выступать ментором.

Когда есть несколько команд и большой ландшафт, и каждая ведет свои ADR, получается долг непоследовательности: город, в котором отдельный дом прекрасен, а вместе ужас. Одна команда сделала кэширование в памяти, другая кэширование на redis, а третья — redis, но с другой библиотекой, и каждое решение осознанно. Но в результате devops должен знать три подхода к мониторингу, а при смене команды разработчикам надо изучать конкретные решения. Или команды пилят монолит, который хранил настройки в appsettings.json, и один сервис использует переменные окружения, а второй — consul.

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

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

ИИ — ментор по требованию. Он может читать код и порождать описания, он может анализировать связи по коду, порождать или сопоставлять с диаграммой.

Инцидент. Оформление заказов тормозит, в runbook написано — смотри payment gateway. А, оказывается, там месяц назад включили антифрод, тормозит он, но runbook не поправили, который тормозит. ИИ — не забывает. ИИ — штурман при инциденте, живая документация.

Три способа, которые можно применять: ассистенты в IDE, анализ кода, RAG-фреймворки.

Но за любой инструмент надо платить, и использование ИИ порождает новые проблемы.

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

Отдаем ИИ задачу построения курьеров. Сначала все неплохо, а потом ломается, и внутри у нас неясная матрица с весами, что делать — непонятно. А надо, например, добавить доставку на самокатах. Тут нужны объясняющие модели, визуализация и гибридные подходы.

Долг слепого контекста. Спроектируй архитектуру на 15 микросервисов. И в предложении — модная архитектура с шаблонами. Не адекватная задаче и неподъемное для команды. Нужен паспорт команды с навыками, бюджеты, стратегические цели, Роль переводчика с неформального бизнес-языка на понятный ИИ.

Архитектура против культуры. ИИ предлагает Kubernetes Knative. Для стартапа — идеально, а в enterprise — у нас большая бюрократия и ограничения. И это надо рассказать ИИ, включая модели ведения проектов с ролями, которые приняты. Роль антрополога.

Сверхоптимизация. ИИ знает задачу и оптимально исполняет. Но не закладывает маневры для изменений. Вы проектируете соцсеть, где 95 % — чтение ленты. Делаем денормализацию в базе PostgreSQL, и триггер для материализации в Redis. А тут бизнес просит показ по условиям, это уже не встроить. Нужно сценарное планирование возможного развития, и просим архитектуру с учетом этих сценариев. Стратегия и риск-менеджер.

Сверхэффективный нерасширяемый протокол. Умный датчик от батарейки — передаем поверх UDP 13 байт без заголовков. И все хорошо, пока не надо будет расширяться. И надо заложить сценарии развития, проанализировать стандартные.

Долг сверхоптимизации. 2023 — поиск через elastic search, а в 2025 — векторные базы для ИИ, на 80 % точнее. И тоже самое может происходить из-за новой версии ИИ. Надо легко менять блоки, например, поиск отделять от системы. ADR становится машиной времени, надо прогонять ADR спрашивать, что, возможно, устарело и пора готовиться к изменениям.

От умных ассистентов в 2023 к агентским системам в 2025 из множества систем. И интерфейсы к ИИ должны быть гибкими, абстрагирование интеллекта.

ИИ нас не заменит, но нас точно уволят, если мы не начнем адаптироваться. Архитектор — куратор ИИ. И риск-менеджер.

Что делать? Начать использовать уже сегодня. Быть бдительным и прагматичным. Инвестируйте в человеческие навыки, правильно задавайте вопросы. Каждый выберет для себя, как правильно работать.

Денис Бесков. Полная технология проектирования архитектуры информационных систем для бизнеса

Денис работал архитектором до 2008, потом ушел в управление продуктами, а сейчас вернулся в архитектуру. Появилось много нового, у всех сложное и по-разному. И он попробовал построить общую схему проектирования архитектуры, а для каждой стадии — указать современные практики. Ему помогал GPT5 Pro, анализируя источники — набор книг, стандартов, статьи экспертов и открытая документация, в презентации большой список.

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

1. Определение логических компонентов. Это же делают аналитики, группируя требования по логическим компонентам. Есть 4 подхода: от процессов, от модели данных, от use case и от ограниченных контекстов.
2. Моделирование границ и окружения. С4 context или контекстная диаграмма.
3. Выбор архитектурного стиля, или набора стилей, на рынке десятки.
4. Определение архитектурных характеристик. QAW — воркшоп к заказчикам. Нужны для выбора стиля.
5. Определение физических компонентов — system design, модули, брокеры, базы данных и так далее.
   1. Enterprise system design (Фаулер и другие)
   2. Internet system design (амазон, google и другие)
   3. Микровервисная архитектура
   4. Data engeneering
6. Фиксация архитектурных решений — ADR или arc42.
7. Моделирование состава системы — c4 container или component или аналоги
8. Рассмотрение архитектурных альтернатив — для стиля для физических компонентов и так далее.
9. Оценка компромиссов — ATAM/CBAM
10. Проверка работоспособности решения. Proof of Concept, Fitness test
11. Сборка макета решения с помощью ИИ (GenAI). Это — альтернатива оценки, как часть проверки работоспособности.
12. Исследование домена — Event storming или Domen storytelling
13. Социальное проектирование команды — team topologies
14. Интересы стейкхолдеров — для выявления архитектурных характеристик. Возлагают на аналитиков, но те не выясняют.
15. Стратегирование архитектуры — до моделирования домена, может, вообще не надо разрабатывать, а можно купить готовое. Wardley mapping.
16. Выбор участника оргразвития — почему занимаемся именно этой областью, для этого нужна карта — Capability mapping

Инсайты.

• solution и decision в русском путаются
• Модель состава c4 излишне физична, там сразу физически поставляемые отчуждаемые части, это плохо стыкуется с логическими моделями Нила и Форда.
• Паттерны проектирования решают архитектурные задачи, которые формулируются неявно и достаются как «кот из мешка». Согласованность длинной транзакции — не было такой задачи, ее архитектор придумал. И в этом проблема: надо ли эту задачу решать вообще и зачем?
• ADR фиксируют решения нечетких задач.

У него получилась целостная картинка, и есть гипотеза, что она вам поможет. Но в том, что получилось — дыры: security, инфраструктуры, нет связи с другими инженерными процессами (design, deploy). Есть идея создать свод знаний. BoK не решают.

Еще в схеме нет блока защиты архитектуры. Архитектор предложил — а надо же доказать команде. Но тут вопрос границ: насколько защита входит в проектирование. Входит в коммуникации.

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

Вопрос: где граница между работой архитектора и системного аналитика? Ответ: по RUP аналитик готовит требования и ограничения и может предлагать варианты решений, а архитектор рассматривает как набор входной информации, которые он как-то принимает во внимание, все это перерабатывает и принимает решения. При этом коллективные архитекторы — редкость, даже работа парой.

Екатерина Рудина из Лаборатории Касперского. Не это ли центр? Как строить архитектуру безопасности и где искать безопасность архитектуры

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

Рассказ начался со ссылки на Эберхарда Рехтина, работал с безопасностью в авиации и авионике и прорабатывал понятие безопасной архитектуры. У него есть мысль о том, что наиболее интересные проекты — те, кто никогда раньше не делал.

Например, первый полет на Луну, или атомный проект. И дальше был рассказ про архитектуру первых атомных реакторов — чикагской поленницы (она проработала 35 минут, без охлаждения и биозащиты) и клинтонская поленница (она работала лет 20). В ней бруски графита, урана и регулирующие стержни кадмия лежали горизонтально. У наших конструкторов описание было, и оно не нравилось, потому что стержни кадмия могли деформироваться при нагреве, и это блокировало движение. Поэтому наш Ф-1 был с вертикальным расположением. Чтобы наблюдать за тем, что наверху — поставили перископ, стержни поднимались через систему блоков и была система безопасности — топор, чтобы перерубить канаты.

В 2011 на атомной станции в Джорджиа (США) был инцидент. Была предусмотрена передача данных из промышленного сегмента в офисный. Инженер поставил обновления, в результате затер данные в промышленном контуре, система интерпретировала это как потерю охлаждающей жидкости и остановила реактор. Остановила штатно, но второй реактора это время не работал, шла перезагрузка топлива. В результате — несколько часов без энергии. Правильная архитектура не должна была позволить затереть данные в промышленном контуре. Архитектор должен выдать требования по безопасности и способы их обеспечения.

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

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

Доменная архитектура — похожа на техническую, корни — не в информационных моделях, а в прикладных областях, в частности — в авионике. Принцип: на базе одной системы должны реализовать архитектуру, которая не отличима от распределенной системы, то есть сети. Когда придумывали — не было виртуалок, они появились позднее. И появилась система MILS — ARINC653. Правила взаимодействия между доменами определяются политиками безопасности, а они ограничены правилами топологии.

Есть набор требований: разделение ресурсов, правила междоменной коммуникации, реализация политики безопасности, управление памятью, планирование исполнения, обработка ресурсов при исполнении, минимальная обработка прерываний и так далее. Распределенный MILS — пражское метро, австрийская система управления критическими коммуникации в аэропорту.

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

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

1. Определение функциональной архитектуры и консервативная оценка рисков. Что вы хотите от безопасности и какой ущерб важен. АЭС: 300+ функций безопасности и 2000+ функций нормальной эксплуатации, оценка рисков и группировка их.
2. Расчет доменов и зон безопасности. Определение доменов, которые реализуют функцию. В идеале функция попадает в одну зону безопасности, но есть компоненты, которые неоднозначно позиционируются, и не всегда их получается разрезать. Есть стандарты, которые определяют уровни, но разные стандарты могут противоречить друг другу.
3. В компонентах — детальная оценка рисков. На основе знаний, что такое безопасность и как нарушитель проводит атаки. Протоколы взаимодействия, способы изоляции, наполнение зон компонентами, поверхность атаки зон и сценариев — дерево атак. Техники, доступные определенным видам нарушителей. Дальше уточняется возможность атаки на технической реализации, и проверяем, как работает архитектурное решение. Дерево обрезается, остаются сценарии, где работаем со средствами защиты.

В презентации — реальная 4-уровневая схема безопасности реактора, правда заблюренная и искаженная. От реактора — только однонаправленная передача от датчиков — стоит дата-диод. А выше — промышленные файерволы.

Безопасная архитектура вообще — это нонсенс, надо оговаривать конкретные опасности. АЭС — радиационная защита плюс выработка энергии. Автомобиль — безопасность для людей, и отдельные критерии для тех, кто внутри, для пешеходов, и для других автомобилей. Безопасная архитектура безопасна не только для самой системы, но и тех систем, которые ее интегрируют. Для систем отличительное свойство — эмерджентность. И устойчивость систем — эмерджентное свойство.

Касперский Automotive Secure Gateway. Автомобиль — сеть компов на колесах. Важно обеспечить безопасную работу внутри отдельных частей автомобиля, при том, что есть голосовое управление, интеграционные подключения к телеметрии, системы обновления прошивок и так далее. В одной проверке нашли уязвимость в вики автопроизводителя, и из нее смогли перейти в телеметрию системы автомобиля. Есть автомобили с плоской архитектуры, и там много проблем, чтобы защититься от перепрошивки от владельца автомобиля или автопарка.

Архитектурное проектирование больше искусство, но придумывать архитектуру безопасности научились.

Дмитрий Ионов. Архитектурные принципы как способ управления архитектурой

Это рассказ о том, как в корпоративном мире Архитектор с помощью принципов архитектуры огораживает свою поляну между бизнесом и командами разработки. Это — сложная и противоречивая позиция. В короткую заказчик хочет быстро и дешево, и команды часто хотят того же, но в результате в какой-то момент оказывается, что быстро и дешево уже не получается, потому что софт превратился в сложную запутанную конструкцию, которая рассыпается. И тогда зовут архитектора. Бывает, что архитектора зовут с самого начала, наученные предыдущим опытом. Бывает, что команды думают про архитектуру и долговременные фокусы, но не могут это объяснить бизнесу, и тому кажется, что команды плохо работают.

Архитектор — медиатор этого конфликта. Есть аналогия. Человек разговаривает с тренером: «Мне надо больше зарабатывать, чтобы лучше жить», а тренер отвечает: «Если будешь заниматься спортом, правильно питаться — у тебя улучшится качество жизни, будешь лучше соображать и, вероятно, сможешь больше зарабатывать. Но где взять денег — не знаю».

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

И начинается все с формирования архитектурных принципов. Это делают с сверху и снизу. Из миссии компании, целей и задач — вынимаем понятия. Если есть стратегическое видение и стратегия трансформации — ознакомьтесь. А снизу — смотрим на ландшафт, опрашиваем специалистов: какие проблемы, чего не хватает.

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

Архитектурные требования — уже из утвержденных принципов, на основе технических соображений, чтобы выстраивать новые системы и интеграции. Однозначной трассировки принципы — требования нет, это нормально. Но важно, чтобы они были в одном документе, и можно было объяснить логику.

Обязательный административный шаг — утверждения архитектурных принципов. Принципы должны быть однозначно понятны. Утверждение минимум на уровне CTO. Применение принципов — для внутренней разработки, для закупки и конкурсных процедур, для внедрения систем.

Часто первая реакция на принципы «это же очевидно». Но при этом на практике их не придерживаются, это как со здоровым питанием или занятиями спортом. И есть задача — не допустить нарушения. А если когда-то надо отойти — надо понимать зачем мы делаем. Наиболее часто отходим, когда делаем транзитную архитектуру, временное решение.

Когда может не работать?

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

Когда приходите в новую компанию, где надо выстраивать архитектурную компетенцию — подход можно использовать как методологию и как способ настройки коммуникации, и повысить управляемость ИТ_ландшафта. При старте нового проекта — направление выстраивание системы и ее структуры.

И был конкретный кейс. Миссия компании — комфорт и уют в домах. Профессионализм, эффективность, надежность и развитие. Есть цели и задачи цифровой трансформации.

Из нее получаются принципы. Каждый расшифрован и трассирован на миссию, ценности и стратегию цифровой транформации.

• Превосходство принципов — вся архитектура должна идти согласно принципам. Следствие — централизованное управление, надо создать комитет.
• Открытость сервисов: сервисы компании должны быть открыты для использования конечным потребителям.
• Безопасность данных
• Однозначность и унификация
• Интеграционная независимость
• Наименьшие полномочия
• Гибкость решений как устойчивость к изменениям
• Независимость бизнес-процессов от технологий реализации.
• Качество услуг
• Версионная политика — устойчивость по обратной совместимости
• Монторинг и аудит
• Польза переиспользования
• Импортонезависимость

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

Дальше из этого архитектурные требования, они конкретны. Если отдельный интеграционный слой — реализуем шину, брокер сообщений и ETL. И шаблон для обмена через шину.

Когда нужен анализ системы — берем первые два столбика с принципами и документацию, и описываем соответствие. Например, для облачного сервиса — нет безопасности данных, особенно если иностранная компания, а в датчиках есть GPS-позиция. Поэтому систему не берем.

Второй кейс — проект разработка софта, там пришлось поработать с целями. Требований больше, они более конкретны.

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

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

В целом, в методологии Дмитрия этих проблем нет: архитектор должен представить свое видение, он должен основывать принципы на целях и миссии бизнеса. Но это — не подсвечено, а тут часть встречаются проблемы, которые оборачиваются против самого архитектора.

А еще важно регулярно проверять, способствуют ли принципы достижению тех целей, ради которых они приняты, или они лишь замедляют работу. В докладе Сергея Баранова было много кейсов, как принципы архитектуры приводят к неоправданно дорогим решениям.

Павел Кутаков из VKTech. Сжатие технологического стека, или анти-Highload

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

Рассказ начат со схемы типичной архитектура сервисного приложения, собранная из современных средств в расчете на рост. Применяем CQRS и Event Sourcing: Три сервиса бизнес-логики, Command API — Кафка — Command processing — PostgreSQL, из которого читаем, RabbitMQ для внутренних сообщений, Mongo для лога команд, ElasticSearch и ColumnStore GreenPlum, схему смотрите в презентации. Может показаться, что Кафка и RabbitMQ вместе — это чересчур, но я реально видел такие корпоративные архитектуры. Итого получается 25 объектов эксплуатации, из них только 6 — наша бизнес-логика — мы же наши сервисы поднимаем в двух экземплярах на всякий случай. И это — не подъемно для маленькой команды.

Можно ли сохранить гибкость? Может, потому что все это умеет PostgreSQL.

• Документная база — Json, для поиска — версии индексов. И можно реализовать Mongo-протокол для внешних систем. FerretDB. И DocumentDB у Микрософта — расширение PostgreSQL.
• Очередь — делаем без проблем в реляцонке. select for update skip locked — взять первый незаблокированный.
• Аналитическая система, колоночное хранение. Встроенного нет, но есть TimescaleDB и Citus. B эффективно копировать таблицу в другую с поколоночным хранением — там не вдвое ovrhead. А еще pg_duckdb.
• Полнотекстовый поиск встроен, но медленно. И есть расширение paradedb.

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

При реализации в бизнес-логике обязательно используем паттерн Repository, чтобы можно было реализацию на PostgreSQL легко поменять.

Поедет ли этот комбайн? Модель интернет-магазина, клиент делает 10 поисков и делает корзину, финансы — TPC-C тест. Для него картинка полного и сжатого стека. У PostgreSQL есть pgbench — ему подготовили скрипт, который моделирует бизнес-транзакцию на хорошо заполненной базе: 100к товаров, поиск над ними, 100 м документов, 100к покупателей что-то уже купили — 100к заказов на 1 м товаров. Результат: 8-ядерный PostgreSQL держит 90 заказов в секунду — с 5 поисками товара каждый и оформлением. При том, что реальная нагрузка у Visa — 300 платежей в секунду, а x5 — 400 покупателей в секунду, а в строительных гипермаркетах — 2 в секунду. Итого получаем вполне приличное быстродействие, которое держит хорошую нагрузку.

PostgreSQL дает единую точку отказа, но кластерный вариант обеспечивает переключение 20 секунд, а дополнительно читающую нагрузку можно выносить на реплики.

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

Сергей Баранов. Экономические последствия архитектурных решений

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

• Гибкая конфигурируемая интеграция, которая обошлась в 2 млн, при том, что простое жесткое решение было в 10 раз дешевле. Да, она сокращала время на одно изменение с 4 часов до одного, но эксплуатация показала, что за два года было всего три изменения — деньги на ветер. И простой расчет показывает, что в принципе окупаемость была бы достигнута только при потоке 2-3 изменений в неделю — а это явно не ожидалось.
• Очередь: Postgres + polling или RabbitMQ/Kafka
• Нужно ли шардирование по регионам?
• Rest или GraphQL

И заключение. Архитектура — инвестиционное решение, обычная альтернатива: простое против гибкого. Чем позднее изменяешь — тем дороже, поэтому оценивайте стоимость погружения, стоимость задержки, технический долг. И немного рекомендаций — как объяснять все это бизнесу и команде.

Валерий Казьмин из cloud.ru. ArchPlatform: Как построить эффективную платформу управления архитектурой

Обычная ситуация с архитектурой выглядит примерно так.

• Архитекторы у нас не очень.
• ИТ-ландшафт никто не знает, там сотни серверов.
• Эффективность решения бизнесу неясно, он просит снижать косты вдвое.
• Архитекторы не знают ландшафт — долго меняется
• Инвестиции не туда и результат неизвестен
• Каждый архитектор делает свое
• Бизнес считает, что архитектура средненькая
• Бизнес хочет что-то делать с архитектурой, потому что она не вывозит рост бизнеса.

Что с этим делать? Нужна трассировка от бизнеса до инфраструктуры, хорошая интеграция и адекватный задачам уровень DataQuality (4-5 часто лишний). Если вы — стартап, то хорошо бы все это закладывать с самого начала. И он рассказывал, как это устроено в cloud.ru с архитектурными схемами.

Cloud. Бизнес продает ресурсы. Инфраструктура — она хорошо типизирована — железо, платформы. Возможности инфраструктуры с потребностями бизнеса расходятся.

ArchPlatform — система, которая интегрирована с ИТ-ландшафтом: данные по инфраструктуре, репозиторий кодов, аритектурные документы, вики и так далее. Конфигурация модели через UI или API, ETL-движок, Validation engine. Портал работы с пользователями, аудит и логирование, BI и визуализация.

Слои данных: hardware, Infrastructure — виртуализация, Платформы (БД и Кафки), Application. Схема данных. Nакая схема отрисовывается lля каждой новой услуги.

Зачем нужен DataQuality? Объем такой, что следить за корректностью описаний не успеваем, поэтому их надо автоматизированно проверять. ИИ тут не помощник, ему на вход нужны адекватные данные, потому что он вашу инфраструктуру не видит. Платформа берет потоки данных от процессов — инциденты, логи изменений, и сопоставляет их со схемами, фиксируя несоответствия. Используют AirFlow, Apache superset для визуализации и ряд других средств.

Что получили?

• Метрики актуальности архитектуры, любое изменение в железе влечет метрики
• Упростили требования к архитекторам — они работают на уровне схем, рассчитывая на их адекватность.
• Начали искать аномалии и тренды, у них 16 м объектов, глазами проблемы не видны

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

Ушли от субъективной оценки архитектора — его работу можно оценить. И полная прозрачность и понимание. И бизнес больше понимает, чем архитекторы заняты, бизнес стал больше доверять. И мы можем мониторить архитектуру, смотреть возможности бизнеса.