Весь мир хайпует на AI и я очень хотел, чтобы на ArchDays появились выступления о практических применениях AI/LLM в архитектурной функции или хотя бы в каких-то других аспектах SDLC. И знаете с чем столкнулся?

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

И вот решил написать сюда, на широкую публику, - есть у кого-нибудь успешные кейсы, в первую очередь в архитектуре, во вторую - на любой практике SDLC, которые можно было бы оформить в метод или практику или паттерн?

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

10 Best Software Engineering Books of All Time:
https://www.mostrecommendedbooks.com/lists/best-software-engineering-books?id=2

The Scrum Guide Expansion Pack
Updated: June 11, 2025
Authors: Jeff Sutherland, John Coleman, Ralph Jocham
https://scrumexpansion.org/scrum-guide-expansion-pack/

Честная статья про жизнь архитектора по мотивам выступления на archdays

https://scrumtrek.ru/blog/technical-excellence/15789/arhitektor-ozhidaniya-i-realnost/

Во время аудита арх. функции у заказчика родилась фраза:
«Производительность должна быть высокой» — это не требование, это – молитва
:)

13 июля (вс) в 18:00 мск проведём вебинар на тему «CAP-теорема в реальном мире на примере баз данных и реальных систем»

Разберем эволюцию баз данных и пару примеров на основе задач из System Design Interview с применением этих знаний. Вебинар будет продолжением доклада Андрея на System Design, спикер дополнит большим количеством примеров на основе задач из интервью.

▫️План вебинара:
1. Эволюция баз данных
2. Как индустрия отвечала на проблему масштабирования?
3. CAP-теорема и PACELC
4. Что такое распределенные транзакции и Distributed SQL?
5. Разберем разные компромиссы на примере разных настроек ScyllaDB, а затем рассмотрим их на примере двух типичных задач с технических собеседований

▫️Кому будет полезен вебинар:
Разработчикам, техлидам, тимлидам, аналитикам и менеджерам разработки, которым интересно лучше разбираться в распределенных системах и понимать компромиссы, которые нужно делать при проектировании.

▫️Ведущий вебинара — Андрей Манаков
— Работает инженером-программистом около 13 лет
— Имеет опыт в различных областях, включая разработку для десктопа, мобильных устройств и веба
— В последние 10 лет основная сфера интересов — распределённые системы
— В настоящее время занимается разработкой инфраструктуры для машинного обучения в Sharechat
— В свободное время пишет посты о распределённых системах и базах данных в своем блоге

👥 У всех слушателей будет возможность задать вопросы в режиме реального времени

Регистрация обязательна

Прекрасная история :)

Плять, 4 часа вся система была в дауне.

Какой-то клиент через апишку наобновлял данных... оно триггернуло тяжелые вебхуки. Прям мегабайты джейсона.

Раббит кластер начал задыхаться. Система обнаружила что кьюшки заполняются, и триггернула scale up.

Все нахер заскейлилось и открыло овердохуа коннекшенов к раббиту.

Раббит перестал принимать новые коннекшены и вообще отказался даже UI показывать.

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

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

4 часа танцев с бубном, поддержкой, енфорсинга scale down, увеличения кластера...

Ожили... первый раз такое. Было и миллион месседжей в памяти переживали. А тут на 600к умер. Размер месседжа решает 🥲

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

1. Мусор на входе - мусор на выходе. AI анализирует данные и здесь очень большая проблема. Сейчас же только ленивый не идет в AI и с чем сталкивается сразу на входе? Либо данных нет, либо они в ужасном состоянии, либо они с огромными пробелами, разбросаны, в итоге мы получаем фрагментированный и непригодный контекст. Если раньше можно было отложить на второй план управление тех долгом, не уделять должного внимания документации, то теперь, если вы хотите получить преимущество от использования AI, придется эти долги отдавать, иначе он выдает какую-то глупость. А отдать этого долг AI никак не помогает, у него просто нет входной иформации. И вот мы начинаем проводить event storming, архитектурые воркшопы, архитектурную базу знаний (структуру документации), чтобы ее можно было начать использовать с AI и только после этого (не совсем только) получить значительный эффект.
2. Для архитектуры очень важен бизнес-контекст, а он обычно тоже слабо описан. Структурированное описание бизнес-требований, с метриками и бизнес-архитектурой тоже становятся достаточно важными. Еще очень важным становится качественный discovery-цикл. AI может прекрасно обрабатывать со всех сторон результаты интервью клиентов, но если интервью проведено плохо – ничего не поможет, поэтому навык проведения интервью (а тут уже AI особо не поможет) тоже достаточно важен. Опрос AI в некоторой роли тоже не сильно помогает, потому что у каждой компании свой контекст, который публично не транслируется за пределы компании того, с кем проводите интервью.
3. Все-таки AI в ближайшее время на заменит архитектора, политику никто не отменял. Он даст гипотезы, подсказки, кучу материалов, но окончательное решение, валидация и ответственность будет все равно за архитектором, поэтому развитие архитектурных скилов критически важно (да, и навык критисеского мышления становится еще более важным, потому что AI порой выдает очень уверенно и обоснованно чепуху). Сильного архитектора, если у него в материалах порядок и у бизнеса в материалах порядок AI действительно очень сильно усиливает, проверено.

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

Книга "Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture"

Совсем недавно, вот буквально в марте, вышла новая книга на тему Identity & Access Management. Я уже писал, что интересных книг про IAM знаю совсем немного, поэтому, конечно, обрадовался такому событию.

Книга аффилирована с компанией Curity, ее авторы как раз там и работают. Поскольку ранее я уже отмечал свое положительное впечатление о качестве публикуемых компанией материалов, к книге изначально тоже подходил с определенными надеждами =)
Также у Gary Archer, одного из авторов, очень достойные ответы на Stack Overflow, не раз их встречал.

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

В книге четыре принципиальных части:
📚 Part I. Introducing Cloud Native OAuth
📚 Part II. Securing APIs with Tokens
📚Part III. Operating Cloud Native OAuth
📚Part IV. Securing API Clients

Собственно, их и намереваюсь рассмотреть, начав с первой.

#book #iam_general #oauth

[1/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”

Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.

Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».

Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.

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

Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.

В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).

Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.

Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.

Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.

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

Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.

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

Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.

(продолжение см. ниже)

#book #iam_general #oauth.

Дима Дзюба всем передает привет:

«В своем докладе на ArchDays 24 "Enterprise governance c доставкой в продукт" я рассказывал про инструменты AaaC, которые мы разрабатываем и применяем в Beeline. Я обещал, что мы начнем их выкладывать в Opensource. И вот, с некоторым опозданием, мы начали выкладывать наши инструменты. Первым выложили плагин к Visual Studio Code для работы с архитектурой в нотации Structurizr DSL https://github.com/tech-beeline »

Мы продолжаем набор спикеров на конференцию ArchDays!

Это первая в РФ конференция по архитектуре, получившая достаточно серьезное признание за 6 лет проведения.

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

Уверен, компаниям участников этого чата есть чем поделиться.

Конференция пройдет 7 ноября в Москве, подаваться на сайте: http://archdays.ru

Если нужны пояснения, то можно написать мне в ЛС.

Сегодня опубликуем первые включенные в программу выступления

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

Почему именно сейчас?
Я скоро выпущу статью о проблемах, с которыми сталкиваемся не только мы в свете последнних событий, но и в целом мир, а именно – решения становятся сложнее, риски нарастают, технологии меняются, подходы к работе тоже меняются.

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

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

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

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

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

А позже я сюда напишу еще, уже более конкретных вещей.

Спасибо,
Сергей Баранов

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

Иногда выводил из на один слайд, получается впечатляюще.

Но теперь я нашел ещё более ужасающую картинку.

Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).

Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.

Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.

Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/

Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.

Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.

Получится очень прагматично.