Системный анализ | Ольга Пономарева

Пишите сопроводительные через ИИ?

Мы решили провести эксперимент и проверить, что из этого получится

Цель эксперимента показать и подсветить то, что бездумные сопроводительные через ИИ - не улучшают вашу ситуацию по поиску работы

Эксперимент:
Мы взяли реальное резюме системного аналитика и подходящую вакансию на hh.ru

Отдали всё ИИ и попросили написать сопроводительное, которое повысит вероятность приглашения на собеседование (с промтом)

На первый взгляд получилось хорошо: опыт, цифры, инструменты, но потом мы перечитали письмо ещё раз и поняли, что вакансию ИИ почти не использовал, несмотря на промт

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

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

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

👌 - если бездумно писали сопроводительные через ИИ
🔥 - если писали сопроводительные сами или действительно адаптировали под вакансию

Есть сервис поиска товаров в интернет-магазине. При запуске системы было определено НФТ:

Время ответа поиска — не более 500 мс для 95% запросов

На старте в каталоге было около 200 тыс. товаров, нагрузка составляла около 100 RPS. Требование выполнялось с большим запасом — среднее время ответа было около 150 мс. Через год каталог вырос до 15 млн товаров, а количество пользователей увеличилось. Нагрузка на поиск достигла 1500 RPS.

Функциональность не менялась: пользователь может искать товары по названию и применять разного рода фильтры. Но теперь 95-й перцентиль ответа составляет 2,8 секунды. При этом база данных не падает, запросы выполняются корректно, данные актуальны

➡️ Задание:

Предложите, какие изменения в архитектуре или реализации вы бы рассмотрели, чтобы вернуть время ответа к требуемым 500 мс

Важно: не нужно сразу называть конкретную технологию. Сначала определите узкое место и причину деградации

Давайте пока сделаем как быстрее, а к архитектуре вернёмся потом

Знакомо?

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

24 сентября в 19:00 мск, в День системного аналитика, проведём вебинар о том, как говорить с бизнесом об архитектуре на понятном ему языке — через сроки, деньги и риски

На вебинаре разберём:

— как показать, что технический долг — это не абстрактная проблема разработчиков, а конкретные потери для бизнеса
— как обосновать время на архитектуру и рефакторинг, когда от команды ждут новые фичи «ещё вчера»
— как связать архитектурные решения с time-to-market, стоимостью изменений и рисками инцидентов
— как постепенно мигрировать с монолита на микросервисы с помощью паттерна Strangler Fig — без остановки бизнеса
— как системному аналитику стать медиатором между бизнесом и технической командой и помочь им договориться

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

P.S. в честь Дня системного аналитика во время вебинара откроем приятные бонусы на курс «Архитектура.Хард». Расскажем о них только участникам эфира 🙂

➡️ Зарегистрироваться тут

Внутренним API тоже нужна обратная совместимость?

Буквально недавно перед одним из наших экспертов стояла задача доработать метод API таким образом, что он потерял обратную совместимость со своей прежним видом (добавили path параметр)

С одной стороны всё просто: API принадлежит одной команде, можно быстро договориться, а при необходимости одновременно обновить фронты и бэки

Но ситуация была неоднозначная

🟢 Позиция «Выкатим все одновременно и нормально»
Внутренние API не обязаны жить вечно. Если контракт используется несколькими сервисами одной команды, можно синхронно внести изменения, быстро обновить потребителей и удалить старую версию.
Полная обратная совместимость здесь может только замедлять развитие: появляются лишние версии, временные поля и поддержка устаревших сценариев

🔴 Позиция «правила должны быть как для внешних, так и для внутренних API»
Внутренний API это тоже контракт. Про некоторых потребителей мы могли забыть, команды меняются, зависимости не всегда очевидны, а синхронное обновление всех сервисов часто невозможно.
Это проблема особенно если сервисы разворачиваются независимо и если нашли баги в одном и откатываем релиз, то и второй сервис тоже должны откатить. Поэтому нужны версионирование, правила изменения контрактов и период миграции

А как у вас: внутренний API можно менять свободнее или обратная совместимость должна быть обязательным правилом для всех интеграций?

Любимая ситуация аналитика: технически всё работает, а по факту нет 🌚

Kafka не упала. Сообщение пришло в правильном формате. Обработчик честно сделал свою работу

Но пока OrderPaid был в пути, заказ уже успели отменить. И если такой сценарий заранее не согласовали, бизнес-решение фактически принимает обработчик

В карточках разобрали, как обычная задержка сообщения ломает весь процесс 👆

Как бы вы обработали OrderPaid после CANCELLED: проигнорировали событие, запустили возврат или отправили на ручную проверку? Пишите в комментариях 👇

1 сентября мы немного намекнули, что планируем новый формат про поиск работы и подготовку к собеседованиям с помощью ИИ

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

Немного предыстории:

1️⃣Сейчас многие системные аналитики ищут работу или планируют начать в ближайшее время

2️⃣ИИ можно использовать далеко не только для того, чтобы «улучшить резюме». С ним можно творить крутые вещи!

3️⃣Мы провели много кастдевов и регулярно видим одну и ту же ситуацию:

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

Рынок сейчас действительно непростой. Но если постоянно откладывать поиск, лучше он от этого точно не станет

☀️В связи с этим появилась идея соединить обучение и тот самый пинок, которого многим не хватает

Сделать практикум-челлендж, в котором будут:

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

То есть можно будет не только узнать, как использовать ИИ, но и наконец начать применять всё это к своему резюме, вакансиям и собеседованиям

Теперь хотим понять: вам вообще нужен такой формат или мы сами слишком увлеклись этой идеей? 😁

Поучаствовали бы в таком практикуме?

🔥- Да, хочу именно челлендж с заданиями
❤️- Да, но мне достаточно занятий и записей
👌- Возможно, сначала хочу увидеть программу и цену

А если есть вопросы, хотите что-то другое или вам безумно понравилась эта идея, что смайликов не хватает - напишите об этом в комментарии 👇

Первая неделя "Архитектуры.База". Что мы заметили с кураторами курса

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

❗️Ребята часто понимают архитектурную идею, но теряются, когда нужно объяснить, почему выбрали именно такое решение
Например, несколько раз встречала ответы в духе "здесь лучше использовать X, потому что это надёжнее", или "потому что есть такой паттерн и так правильно". А вот когда начинаешь спрашивать: "надёжнее в каком смысле?", "а какие минусы есть у паттерна и не сыграют ли они злую шутку в данном кейсе?", "что именно здесь может пойти не так?" и так далее, начинается самое интересное...

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

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

Посмотрим, что изменится после следующих недель 👀

Как бы вы спроектировали будильник для человека, который не слышит? ⏰

Такой вопрос реально встретился на собеседовании. Его принёс мне один из учеников))

Представьте: готовитесь к вопросам про REST, Kafka, базы данных и архитектуру. А на собеседовании вас просят спроектировать будильник 😊

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

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