Тело у DELETE: риски разработки

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

1️⃣ Множественное удаление

1️⃣ Ваша ролевая модель должна предусматривать, что «можно удалить всё».

2️⃣ Нагрузка на БД. Нужно осмысленно формировать запросы и проводить нагрузочные тестирования.

3️⃣ Допустим, из 4 объектов удалились первые 2, а на 3-й не хватает прав. Что будете делать? Отдавать частичный успех (207)? Откатывать удаление? Или продолжать удалять дальше?

4️⃣ DELETE должен быть идемпотентным (по стандарту). Для вас критично, если это не так?

2️⃣ Удаление подресурсов

1️⃣ Здесь снова упираемся в права. У вас должны быть права не только на каталог, но и на его объекты и действия с ними. Бывают и такие тонкости: права на работу с объектами и каталогом есть, а на изменение конкретных связей — нет. Это не всегда очевидно до тестирования.

2️⃣ Все те же проблемы, что и при массовом удалении, если оно предусмотрено.

3️⃣ Удаление по условиям
1️⃣Удар по производительности: чем сложнее фильтр, тем тяжелее запрос.
2️⃣Есть простор для инъекций. Нужно реализовать «белый список» условий и операторов, плюс заморочиться с валидацией.

3️⃣Условия могут быть массовыми → добавляем к этому риски массового удаления.

4️⃣ Подпись операции
Здесь я совсем не эксперт, но отмечу из общей практики:

1️⃣ Возможность утечки. В заголовках (Authorization, Cookie/Set-Cookie, X-Api-Key, X-Signature) обычно можно скрыть данные настройками. А вот в теле запроса это уже на вас: или не логируете тело, или делаете белый список полей.

2️⃣ Потребуются настройки прокси, чтобы они понимали, как работать «с таким сюрпризом».

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

Ну и помним что не все SDK и сервисы работают с телом запроса у DELETE.

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

Ну а теперь у нас есть понимание: у DELETE тело может быть, но перед этим стоит семь раз подумать. Насколько это было полезно и занимательно отметь реакциями.

👍 - Да, больше таких постов
👀 - сложно и не понятно
👎🏼 - это уже давно всем известно\я могу посмотреть это в ИИ
🤡 - я читаю ради развлекательного контента, а не вот это все

У меня особая любовь к мероприятиям из Ульяновска, даже если они проходят в Питере.
#stopworking!
Речь, конечно, про Стачку 2–3 октября 2025

Я буду там лично с докладом. 👀Приготовила кое-что новенькое 👀

Нравится что «Стачка» — это мультиконференция. Можно заглянуть на секцию архитектуры, ИБ, Python, а после вернуться к аналитикам.

Я уже присмотрела для себя несколько докладов:

1️⃣ От REST к MCP: как LLM меняют принципы проектирования API и архитектуры систем
2️⃣ Воркшоп «Ресурсный баттл» от Владимира Бурмистрова
3️⃣ UX в кибербезопасности: от инженерного хаоса к понятным решениям
4️⃣ От простого API к гибкой платформе: BDUI бэкенда в Яндекс Еде
5️⃣ Прожарим риски по полной: техника MEAT в работе аналитика от Анастасии Московкиной(получится познакомиться лично!) и Натальи Леоновой

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

Агрегаты - бойцовский клуб в мире ИТ

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

Нам, системным аналитикам, это часто даётся нелегко. Целый ад терминологии.

😂Если обратиться к создателю Event Storming и его книге по методу, то там можно найти забавную рекомендацию: «Не говорите, что такое агрегаты".😂

Ха-ха, Брандолини, очень смешно. Когда я продвигала Event Storming и началась сессия с очень занятыми архитекторами (скептически настроенными), провернуть такое у меня не получилось. 😉😉 Коллеги воспринимали эту подачу как «Зачем ты тратишь наше время?».

На следующих встречах я подготовила описания агрегатов. Но и они не зашли моим программистам и архитекторам. Тогда я предложила вместе разобраться, из чего агрегат состоит: мы коснулись Value Object и Entity, корня агрегата и обсудили, почему это важно с примерами агрегатов.

В книге Влада Хононова «Изучаем DDD» определение всё же есть. Но какое! См. фото. А потом ещё 8 страниц поясняющего текста.

😬😬Господа Хононов и Брандолини знают толк в извращениях.😬😬

Для тренингов я пыталась найти объяснения попроще. Пока что мне более-менее нравятся материалы:

Статья где про агрегаты рассказывается через их антипаттерн

Короткое определение от Мартина Фаулера.

Подробная статья (по стилю похожа на Хононова, но, на мой вкус, удачнее).

Но в целом поиск продолжается. Поэтому интересно, вы уже проходили этап понимания агрегатов в контексте DDD и Event Storming? Поделитесь, как у вас прошло. Может, у вас есть более удачные материалы?

Для завтрашнего же воркшопа, я пересмотрела свою подачу этой информации. Стало определенно проще и доступнее. Поэтому если хотите разобраться жду вас на тренинге Event Storming и System Design.

#EventStorming #СистемныйАнализ #DDD #агрегат

🎉EventStorming — это вечеринка! 🎉

Скажу очевидное: сегодня суббота и нужно отдыхать. Но я только что закончила вести тренинг по EventStorming и всё ещё на этой учебно-рабочей волне. Поэтому хочу поделиться с вами забавным ресурсом по методике.

Это презентация Альберто Брандолини. Того самого, кто продвигает EventStorming. Посмотрите, как она сделана: часть слайдов он рисовал от руки (ну или его дизайнер). Красиво, просто, доступно и смешно.

И да, он буквально начинает свой рассказ с мысли:

«EventStorming — это вечеринка!»

Так что проводить EventStorming в субботу оказалось очень символично. Всем вечеринок, коллеги! 🎊

😱Шок просто😱 Результатом прошедшего тренинга стало, пусть и с болью и переживаниями, понимание: почему на Event Storming действительно не стоит говорить об агрегатах!

Господин Брандолини прости мои шутки над тобой!

Одновременно очевидно почему нам, системным аналитикам, так хочется их обсуждать и свести к ER-диаграммам. Здесь всё просто: сущности, из которых потенциально может состоять агрегат, для нас понятная и знакомая часть работы А вот бизнес-контексты в понимании Event Storming - нет.

Здесь собаку и зарыли:

1) Часть людей на сессии будет чувствовать себя лишними.
2) Снова уйдём от бизнеса в сторону техники. А это нарушает главную задачу синхронизацию бизнес-экспертов и разработчиков.

И да, потенциальные агрегаты вполне можно выделить без того, чтобы обсуждать, что это такое!

Это отлично вяжется и с моей практикой: мы агрегаты вообще не выявляем.

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

А раз это стартап, то можно подглядеть у них фреймворки и идеи. Но с фокусом на ИТ)

🔍 Поиск проблем

Jobs To Be Done — знакомая многим аналитикам техника.
Event Storming — разбор процессов и рутины, но с вовлечением всей команды. Подходит для лидов и менеджеров.
5 Whys — простой инструмент для индивидуальной работы.
* Техника MEAT для прожарки проблем (подсмотрела прямо сегодня у Насти

Работа со страхами

1 Почему изменения часто терпят неудачу — Kotter
2 Роль эмоций в сопротивлении изменениям

📊 Критерии успеха

1) если хотите познакомится с международной практикой оценки ИТ отрасли то есть сложная книга Accelerate: The Science of Lean Software and DevOps
2) то о чем рассказывала, метрики ИТ команд от Atlassian все что можно использовать + ваша фантазия

💡 Продажа идеи

1) Любимое: Лифтовые презентации.
2) Книга Сделано, чтобы прилипать (Chip и Dan Heath). Ближайшее время сделаю обзор.
3) Как правильно выбрать время и язык продажи - кратко об этом говорила, здесь больше

🚀 Внедрение

1) Книга *Accelerate* (там тоже много про практики внедрения).
2) И снова сборник гайдов от Atlassian.


Не бойтесь быть авторами среды вокруг себя, приносить изменения и искать способы их внедрять
А если вы уже:
Успехами можете поделиться под этим постом)

Стачка 2025: ИИ, джуны, воркшопы и отличное комьюнити DevAnalyticsConf

Добралась до дома и начинаю серию постов про Стачку 2025:

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

На Стачке 2025 докладов при ИИ было больше чем кофе (как и на большинстве конференций этого года). Еще прошлым летом на другой конференции был всего 1 доклад, а в этом через один и даже секция аналитиков заканчивалась круглым столом «ИИ vs Аналитик — кто выживет в будущем?»

😬 Что это значит для нас?😬 Если в прошлом году ещё можно было игнорировать ИИ, то теперь это уже профессиональное отставание. Даже если у вас NDA, решения есть и на Стачке об этом тоже говорили.

При этом, честно, ничего по-настоящему нового в докладах об ИИ лично я не услышала. Всё примерно вокруг: «как облегчить рутину с помощью ИИ».

Стачка гостеприимно открыта для разных уровней. 🔥Как участников, так и спикеров. 🔥Это о больном. Помню, когда-то пришла на профконференцию и ушла в ужасе! Я не поняла ничего. Здесь не так.
Стачка открывает двери для начинающих спикеров. Доклад от джуна о болях отсутствия QA, хоть и не принес новых знаний, но погрел атмосферой и напомнил что кто-то сейчас проходит свой особенный путь в анализе.

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

Стачка определённо запомнится большим количеством воркшопов. Это тот редкий случай, когда я разрывалась не между докладами, а между практическими сессиями. Отличился программный комитет родной секции DevAnalyticsConf и аналитики - именно от них было больше всего воркшопов. Представляете, Конкуренция была такой, что не всем желающим спикерам удалось провести свои воркшопы.

🍷 конечно, комьюнити. около 300 спикеров, куча общения, посиделки в барах, афтерпати, 🍷афтерпати после афтерпати🍷
Отдельное спасибо Ольге и Владу если бы я знала, что они приготовили нам столько активностей, не планировала бы вечера заранее💜

🤪Еще Стачка это крутой тайминг🤪 Всё начиналось и заканчивалось строго по расписанию. У меня даже закралась мысль: не из РЖД ли организаторы?

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

Спасибо Стачке за атмосферу и повод выбраться в Питер.

#stopworking #стачка2025

Как я чуть не подралась с участником за 2 балла или Ресурсный баттл

Самым запоминающимся на Стачке для меня стал «Ресурсный баттл» от Владимира Бурмистрова и Станислава Доброхотова

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

Перчинка: в игре были и победители, и проигравшие.

Я достаточно быстро вспомнила, что у меня в близких друзьях бывший коллектор, и это стало основой для стратегии. А ещё азарт и оптимизм. И да, за 2 балла я торговалась как могла (а я вообще-то не умею). В итоге это привело нас с последнего места на второе, что считаю успехом😐

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

Теперь про мысли:

1️⃣ Некоторые люди с самого начала готовы пойти у вас по головам, других для этого нужно прижать. Неприятно, надеюсь, что в реальной работе такое всё же проявляется меньше.

2️⃣ Некоторые ресурсы ценны не сами по себе, а тем, что могут являться предметом торга. Но периодически они просто отправляются в утиль.
И да, иногда мы занимаем именно такие должности, потому что на нас был ресурс. А ещё это неэкологично, но продумано.

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

4️⃣ В целом, каким бы крутым специалистом ты ни был, действовать приходится вслепую, на основании предположений. Чем больше ты можешь учесть нюансов, тем меньше у тебя неопределённость.

5️⃣ И да, если брать ровно столько сколько тебе нужно, то шансы выполнить задачу быстрее и прогнозируемо как будто выше, но победить нет.

Из минусов, не хватило возможности потом побольше обсудить происходящее.