Как по закону Конвея можно зафакапить внедрение DDD.

Мы пишем микросервисы. Дальше еще больше микросеврисов, затем еще и еще до того момента как общая картинка перестает умещаться в голове даже самого опытного инженера. А как мы знаем, любую архитектурную проблему можно решить дополнительным слоем абстракции. Появляется идея внедрить DDD.
DDD — не новая методология, о который мы тут не так часто говорим, но которая призвана, добавив слой абстракции (домены), снизить связанность, возвести заборы (bounded context) и открыть новые возможность масштабирования.
С помощью DDD хочется порешать сразу несколько проблем:
— Cильная связанность микросервисов.
— Отсутсвие Observability.
— Проблемы нечетких зон ответственности.
Дальше идут классические подходы к выделению доменов — задача декомпозируется, делегируется командам и те идут дизайнить свое виденье бизнес-сущностей.

В чем ту проблема? Стоит обратиться к классическому закону Конвея:
Современная его трактовка  — «Если архитектура системы и архитектура организации противоречат друг другу, победу одерживает архитектура организации» (по версии Рут Малан).

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

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

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

https://www.uber.com/en-GB/blog/microservice-architecture/
https://cleverics.ru/digital/2020/12/conways-law-importance-teams-design/

Strangler Pattern

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

Основная идея паттерна состоит в том, что вы не беретесь “переписывать” весь монолит за раз, а просто блокируете написание новой функциональности в нем.

Новые фичи начинают с точки зрения разработки стоить дороже, ведь их теперь нужно выносить в отдельный микросервис. И не просто писать новый код в новом микросервисе, но и выносить из монолита зону ответственности, в которую новая функциональность входит.
Функциональность, которая выезжает из монолита, при этом заменяется “походом” в новые сервисы. Монолит превращается в фасад.
Старый код при этом может какое-то время оставаться в монолите и даже использоваться как фолбек или дополнительная сверка работы новой логики.

Дополнительные затраты на вынос старой логики из монолита размазываются во времени и не сильно влияют на time-to-market продукта.

Через какое-то время монолит переписывается, зоны ответственности разъезжаются по микросервисам, снижается связанность.

Есть минусы/консерны у подхода, заслуживающие внимания:
— Большая фича в новой концепции может стоить очень дорого из-за того, что придется переписать большой кусок монолита.
— Можно неправильно выделить зоны ответственности из монолита, потому что будет желание “переписать поменьше”.
— Дополнительно могут возникать затраты на вынос из монолита зон ответственности, от которых ваша функциональность зависит, например, хранилища каких-то данных.

https://microservices.io/patterns/refactoring/strangler-application.html
https://serverspace.ru/about/blog/pattern-mikroservisa-strangler/
https://www.geeksforgeeks.org/strangler-pattern-in-micro-services-system-design/

Яндекс всё.

Пару недель назад я сдал бейдж. 7 лет назад я стоял у истоков Яндекс Go, мы прошли большой и тернистый путь роста от стартапа в рамках всей компании до большого энтерпрайза с 44 млн MAU. А пару недель назад я, как CTO Go New Ventures, отвечал за запуски новых стартапов, уже внутри Яндекс Go - такая спираль, которая прокрутилась на 360.
И как говорится - пришло время выходить из зоны комфорта и двигаться дальше.
Для канала - это значит новый виток. Моя новая роль, ради которой я оставил Яндекс, подразумевает еще больше свежих взглядов и смелых решений - контента, которым я хотел бы продолжать тут делиться.

Stay tuned. Если интересно продолжение персональной истории - ставьте лайк. Если нет - новый пост уже на подходе. Делитесь ссылкой на канал с коллегами @startup_architecture - рост числа читателей сильно мотивирует писать.

Антологии технологий Яндекс Такси про изнанку сервиса.

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

Кстати, местный мем: когда я 7 лет назад пришел в такси, мы решили нарисовать все микросервисы Такси на стене кухни (БЦ Аврора на Павелецкой) со всеми связями между ними. Спустя пару часов мы израсходовали всю стену и бросили эту идею. Через пару дней схема уже была outdated. Но до сих пор по чатам гуляет фотография этой стены с 20-30 микросервисами. С тех пор их количества выросло до примерно 1000 штук. Надеюсь, ни у кого похожей идеи визуализации не возникает.

https://www.youtube.com/watch?v=GR7za5CWpxA

System Design Master Template.
https://medium.com/javarevisited/how-to-crack-system-design-interviews-in-2022-tips-questions-and-resources-fcad05e2dab

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

PS: если у вас есть другие полезные макеты по теме, поделитесь в комментариях.

Если хочется копнуть глубоко в тему архитектуры, то вот большой репозиторий с актуальными концептами системного дизайна:
https://github.com/ByteByteGoHq/system-design-101

Software Architecture and Design Trend 2023.

Наткнулся на исследование архитектурных трендов 2023 года. Почему это важно, если год почти закончился? Чтобы технологиях или практика стала инструментом большинства, она должна пройти через все стадии жизненного цикла продукта (по Роджерсу). То, чем пользуются сегодня только инноваторы, завтра может стать стандартом индустрии. Поэтому важно смотреть на то, какие технологии и практики в этом году вошли в стадии Innovators и Early Adopters.

Innovators:
— LLM или большие языковые модели окажут значительное влияние: от помощи в понимании архитектурных компромиссов до расширения возможностей нового поколения low-code и no-code разработчиков.
— Software Supply Chain Security или Безопасность цепочки поставки ПО.
— Design for Sustainability — нацеленность на снижение углеродный след (как часто лично вы задумываетесь? Что по утилизации ресурсов?)
— GraphQL Federation
— Policy as Code
— HTTP/3
— dApps — децентрализованные приложения.

Early Adopters или получающие распространение:
— Design for Portability получает все большее распространение (такие платформы как Dapr ориентированы на то, чтобы дать архитекторам возможность еще больше абстрагироваться от деталей реализации).
— Data-Driven Architecture — архитектура, управляемая данными.
— Architecture as a Team Sport — архитектурура больше не задача “Архитекторов”, а командная работа. Широкое признание ADR как способ работы команды над архитектурой приложения.
— WebAssembly (Server-side and Client-side)
— Design for Security
— Design for Resilience
— Design for Observability
— Micro Frontends
— AsyncAPI
— Workflow and Decision Automation Platforms
— Low Code / No Code

https://www.infoq.com/articles/architecture-trends-2023/
https://danielfoo.medium.com/software-architecture-and-design-trend-2023-f55ecfbcfcc0

What’s next?

В октябре прошлого года я оставил Яндекс позади. Наверное, пришло время сформулировать продолжение...
Я, в роли технического директора, присоединился к очень крутой команде AI-Center Тинькофф.

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

GPT как оркестратор микросервисной архитектуры?

Мы знаем, что GPT-модели могут писать SQL-запросы или код. Новая парадигма — А что если GPT будет формировать пользовательский флоу в архитектуре нашего сервиса?

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

Что если мы опишем базовые функции нашего сервиса и дадим GPT возможность самому конструировать пользовательские сценарии?

Я решил сделать сервис заказа еды. У меня есть несколько функций системы, про которые я рассказываю ассистенту:
- make_order([{item, count}])
- cancel_order…
Дальше я прошу ассистента обслужить пользователя — GPT может самостоятельно составить цепочку вызовов, которые нужно совершить для того, чтобы понять, что хочет пользователь, и сходить в нужные сервисы.
GPT выступает как замена части бизнес-логики приложения, отвечающей за формирование пользовательского пути по вашей архитектуре.
Просто посмотрите пример.

Такое становится доступным благодаря подходу RAG (Retrieval-Augmented Generation), когда обученной на большой базе знаний модели (GPT) на вход подсовывают динамический контекст (описание сервиса заказа еды). Если хочется начать углубляться — можно начать отсюда: https://habr.com/ru/articles/779526/

Как вы используете GPT-ассистентов? Спрашиваете советы или строите поверх системы и продукты?

Подход Change Data Capture как способ реактивного взаимодействия сервисов.
https://habr.com/ru/companies/yandex_cloud_and_infra/articles/754802/

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

Для решения подобных задач на помощь приходит подход Change Data Capture (CDC) или “Захват изменения данных”.

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

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

С применением этого подхода можно реализовать несколько популярных паттернов, таких как CQRS (чтобы развязать потоки чтения и модификации данных) или Strangler (чтобы распилить монолит на микросервисы).

Какую функциональность можно реализовать с помощью этого подхода:
— Репликация (Другая БД? DWH?)
— Обновление и инвалидация кэшей
— Экспорт данных в поисковые движки (Elastic?)
— Аудит изменений в БД
— Передача состояния другим сервисам

https://habr.com/ru/companies/yandex_cloud_and_infra/articles/754802/
https://en.wikipedia.org/wiki/Change_data_capture

ArchGPT — Архитектура с помощью GPT.

Давно думал, как подступиться к этому вопросу — как заставить GPT дизайнить архитектуру? Чтобы получше, чем качество уровня рандомного человека с улицы.
Пока не наткнулся на интересную статью https://www.accidental-architect.com/archgpt

Идея в следующем — если мы можем представлять нашу архитектуру как “код” (в статье приводится пример с моделью С4 — способ записи архитектуры системы в виде “контекст-контейнер-компонент-код”), то GPT может отлично понимать такой формат.

Тогда задача системного дизайна сводится к задаче “кодогенерации”, которую GPT умеет решать. В статье, например, приводится пример с тем, что GPT спросили, как перейти с json на protobuf. Модель подсказала, какие изменения в каких системах это повлечет, и как изменится сам документ архитектуры.

В дополнение получаем новый тип интерактивной документации.

Если подумать, как правильно прикрутить RAG, можно делать совсем интересные вещи.

Сборник постов с паттернами и подходами к построению системного дизайна.

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

Application architecture:
— Domain Driven Design (DDD)
— Как по закону Конвея можно зафакапить внедрение DDD
— Симптомы распределенного монолита

Обеспечение консистентности данных:
— Materialized View
— Целостность данных в микросервисах
— Кэширование
— Event Sourcing
— Event-based Microservices: обработка ошибок
— Saga

Querying:
— API Composition / API Gateway
— CQRS (Command and Query Responsibility Segregation)
— GraphQL

Reliability:
— Circuit breaker
— Rate limiting с Congestion Control

Deployment:
— Sidecar: Библиотка VS Сервис VS Сайдкар
— Plug-in Архитектура
— Consistent hashing
— Шардирование по географии - плохое решение

Refactoring:
— Strangler Pattern

Cell-based Architecture.
https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/why-to-use-a-cell-based-architecture.html

Согласно последнему отчету об архитектурных трендах от infoq, набирает популярность подход Cell-based Architecture или Клеточная Архитектура. О нем сегодня и поговорим.

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

Рассмотрим пример классической микросервисной архитектуры:
— Есть микросервис A, обрабатывающий весь пользовательский трафик, состоящий из сотен инстансов, развернутых в разных локациях. Он ходит в микросервис B.
— Микросервис B, тоже сотни инстансов, использует базу данных, также шардированную по локациям.
Проблемы: возникает много долгих кросс-дц запросов, проблемы в одном микросервисе или базе приводят к невозможности обработать весь пользовательский трафик.

Клеточная архитектура предлагает одно из возможных решений:
Выделить инстансы микросервисов A, B и шарды данных в отдельные ячейки таким образом, чтобы они end-to-end обслуживали один пользовательский регион или один продуктовый сценарий.

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

Для продолжения углубления советую статью VK про их вариант адаптации подхода:

https://habr.com/ru/companies/vk/articles/807685/
https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/why-to-use-a-cell-based-architecture.html
https://github.com/wso2/reference-architecture/blob/master/reference-architecture-cell-based.md
https://habr.com/ru/companies/otus/articles/808205/

Bulkhead.
https://en.wikipedia.org/wiki/Bulkhead_(partition)

Поговорим сегодня о кораблях. Когда готовил прошлый пост про Cell-Based Architecture наткнулся на новый термин — “Переборка” или “Bulkhead”.

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

Интересно наблюдать как инженерные решения из оффлайнового мира перекочевывают в IT — Bulkhead Pattern или Cell-Based Architecture.

https://bool.dev/blog/detail/bulkhead-pattern
https://ru.wikipedia.org/wiki/Переборка
https://news.1rj.ru/str/startup_architecture/96
https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead

InfoQ Software Architecture and Design Trends Report - April 2024
https://www.infoq.com/articles/architecture-trends-2024/

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

— Cell-Based архитектура как попытка увеличить надежность больших и сложных систем и снизить затраты с помощью разделения микросервисной архитектуры по пользовательским сценариям и зонам доступности. Подробнее в прошлом посте. В качестве инноваторов — Roblox, Slack, DoorDash.
— Privacy engineering. Компании меняют свой майндсет с реактивного подхода в следовании законам о пользовательских данных, например GDPR, на более проактивный подход и закладывают все требования в начальном проектировании. Кажется, что в России с законами о ПД происходит та же смена майндсета.
— Social-technical architecture. Более конкретный подход пришел на замену немного невнятному “Architecture as a Team Sport”. Смысл его в размывании роли архитектора. Больше компаний приходит к тому, что архитектурные решения должны принимать все, кто причастен к созданию и поддержке систем.
— LLM стремительно проходит адаптацию, и еще больше компаний ищут применение, которое может стать геймченджером в конкретной индустрии. Скорее всего, у вас тоже в продукте есть стрим про то, как можно использовать LLM. При этом дальше чатботов и RAG дело мало у кого доходит.
— Platform architecture я бы объединил с Low/No code и подчеркнул, что последние годы идет нескончаемый тренд на понижение планки входа в IT. Затраты на разработку всегда были большими, это большой и сочный кусок PnL, вокруг которого постоянно появляются и исчезают новые платформенные решения. Рано или поздно все будем писать на JS.

Отчет — https://www.infoq.com/articles/architecture-trends-2024/
Подкаст — https://www.infoq.com/podcasts/infoq-architecture-trends-2024/
Отчет за 2023 — https://news.1rj.ru/str/startup_architecture/88

Как Netflix обеспечивает высокую доступность stateful системам.

Вышла очень интересная статья Нетфликса о доступности в распределенных stateful системах. Всем рекомендую к прочтению.

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

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

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

https://www.infoq.com/articles/netflix-highly-reliable-stateful-systems/

@startup_architecture

Как работает Apple Intelligence под капотом.

10 июня 2024 года на конференции WWDC 2024 Apple анонсировала свою AI платформу. В качестве искусственного интеллекта выступает платформа с оркестратором, инференсом (исполнением) легких моделей на устройстве и даже интеграцией с OpenAI. Давайте разбираться с архитектурной точки зрения.

— Большую часть инференса стараются делать прямо на устройстве, куда интегрируется модель вроде OpenELM 3B — семейство “эффективных” моделей, которые Apple анонсировала в начале этого года. По качеству они, конечно, уступают LLM, но базовые сценарии на телефоне будут покрываться.

— За решение исполнять ли запрос пользователя на устройстве или отправлять на сервера Apple отвечает центральная часть системы — Оркестратор. Он определяет, потянет ли встроенная модель запрос. Если нет, то отправляет на бэкенд на более умную модель (LLM) или даже в OpenAI.

— Функциональность App Intents Toolbox позволяет Siri взаимодействовать с приложениями по определенным контрактам, предоставляя разработчикам возможность "интегрироваться" в ассистент. Как обычно, нужно задекларировать в коде поддерживаемые “интенты” и Siri будет понимать, как с вашим приложением нужно обращаться. По схеме не очень понятно, как именно выглядит сценарий обработки пользовательского запроса, но все указывает на то, что это концепция тулов в RAG схеме.

— Semantic Index, скорее всего, векторная база данных прямо на устройстве. Она необходима для реализации RAG, с помощью которого Siri начинает что-то знать не только о вещах, на которых обучена модель, но и о реальном мире (а также о том, что хранится на самом телефоне).

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

Пост написан на базе статьи с медиума и официального анонса Apple, там сильно больше интересной информации.

@startup_architecture

Как вы знаете, я сейчас руковожу разработкой в AI-Центр Т-Банка. Мы делаем очень крутые AI first продукты и платформы. Мне часто говорят, что тут одни ML-задачи, это совсем не так. Немного расскажу.

Технологически все выглядит примерно так — у нас микросервисы. Мы пишем на Python и Golang. Используем как стандартные PG, Redis и прочее, так и специфические вещи вроде векторных БД (см. Milvus). Решаем крутые инженерные задачки вроде как гонять огромные потоки аудио через микросервисы с минимальной задержкой. Или что такое LLM-платформа и как ее построить таким образом, чтобы можно было на базе этого создавать продукты с минимальным TTM.

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

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

А еще куча всего: голосовые технологии, компьютерное зрение, рекомендательные платформы.

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

И если что, помимо ML-инженеров, мы в поиске как сильных backend и mobile инженеров, так и руководителей разработки. Если чувствуете в себе силы или есть вопросы — заходите ко мне в личку @skogorev.

Оверинжиниринг в архитектурных решениях.

Overengineering — это процесс разработки решения, которое усложнено таким образом, что не представляет ценности или могло бы быть реализовано проще. Если совсем простыми словами, то это когда можно сделать просто, но делается сложно.
Есть очень много причин, почему люди начинают оверинжинирить — это и неправильная формулировка ФТ и НФТ, и неправильные фокусы (например, на платформенность всего и вся), и даже незрелость команды.

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

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

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

— Какую бизнес-проблему мы решаем? Правильно ли, что эту проблему нужно решать именно такими ФТ и НФТ, а не на другом уровне/другой системе? Как еще можно решить эту бизнес-проблему?
— Правда ли, что текущие ФТ и НФТ решают бизнес-задачу? Не могут ли они быть более слабыми/более сильными, что сильно упростило бы решение или снизило стоимость решения?
— Правда ли, что исходя из контекста и ограничений по срокам, выбрано самое оптимальное техническое решение? Какие решения мы не рассмотрели совсем?
— Сколько новых точек отказа появляется в системе? Можно обойтись без них?
— Сколько новых сущностей/абстракций появляется в системе? Можно ли обойтись без них?
— Правда ли, что в компании/соседней команде нет решения, которое можно заиспользовать? Правда ли, что есть весомые аргументы не использовать уже готовые решения?
Если есть что добавить — пишите в комментариях.

https://www.mindtheproduct.com/overengineering-can-kill-your-product/

Топ-10 угроз безопасности приложений, основанных на LLM и генеративном ИИ (OWASP Foundation).

С ростом популярности решений на базе LLM и генеративного ИИ растет и количество потенциальных уязвимостей. Как первые сайты на php упускали из расчета, что пользователь может ввести логин "; DROP TABLE USERS". Так и сейчас — продукты на основе ИИ растут быстрее, чем исследования в области безопасности таких решений.

Некоммерческая организация OWASP Foundation выпускает "OWASP TOP-10" — это отчет, составленный группой экспертов по безопасности со всего мира, об известных проблемах безопасности приложений с акцентом на 10 самых важных. На них ссылаются создатели основных стандартов кибербезопасности и такие организации, как MITRE, PCI DSS и DISA.

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

ТОП-10:

— Prompt Injections: попытка злоумышленников переопределить изначальный Prompt, что может привести к несанкционированным ответам.

— Insecure Output Handling: неправильная очистка или обработка данных, генерируемых ИИ, что приводит к таким уязвимостям, как cross-site noscripting или утечке информации.

— Training Data Poisoning: подразумевает подделку данных, используемых для обучения моделей, что искажает их поведение.

— Denial of Service: атаки, которые перегружают системы с моделями, делая их недоступными для пользователей, например, путем использования ресурсоемких операций.

— Supply Chain Vulnerabilities: жизненный цикл приложения на базе LLM может быть скомпрометирован уязвимыми компонентами или службами.

— Sensitive Data Leakage or Information Disclosure: непреднамеренное раскрытие конфиденциальной информация системами ИИ из-за недостатков в обработке данных или контроле доступов.

— Insecure Plugin Design: плагины LLM могут иметь небезопасные входы и недостаточный контроль доступа.

— Excessive Agency: возникает из-за чрезмерной функциональности, разрешений или автономии, предоставляемых системам на основе LLM, что приводит к непреднамеренным последствиям.

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

— Model Theft: подразумевает несанкционированный доступ к моделям под капотом приложения.

https://genai.owasp.org/llm-top-10/
https://education.securiti.ai/certifications/ai-governance/controlling-data-inputs-and-outputs/attacks-against-generative-ai-systems-owasp-top-10-for-llms/

Привет всем!
Давно не писал. Есть несколько причин.

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

Второе. В ТБанке я сильно сфокусировался на построении продуктов и платформ на базе AI (буквально моя зона ответственности). Индустрия развивается очень быстро: если ещё вчера все делали Single Prompt Applications, то сегодня модно строить мультиагентные архитектуры, всё больше приближая нас к AGI.

Теперь про канал и его позиционирование. Хочу открыть новую главу. Он по-прежнему будет про технические вещи, но с акцентом на то, что у меня сейчас в фокусе — AI. В ближайшее время я, скорее всего, переименую его. Давайте начнём с первого поста.

А пока и держите трейнспоттинг с моего рабочего места офиса на Белорусской.