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

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

«Какие изменения схемы обратно совместимы, а какие нет? Как организовать работу с новой версией схемы, если появились несовместимые изменения в Kafka?»

Как бы ответили вы? Пишите в комментариях

Ранее рассказывали, что купили у Дениса Бескова профессиональный чат аналитиков Одна из главных целей покупки — развивать в сообществе направление ИИ 🤖 😎 Мы хотим, чтобы аналитики не наблюдали за изменениями рынка в сторону ИИ, а разбирались в новых инструментах и учились применять их в работе. Потому что есть риск, что специалиста заменит не сам ИИ, а другой аналитик, который научился использовать его быстрее и эффективнее Но когда мы зашли внутрь сообщества и начали разбираться с его структурой, появилась другая проблема... 😊 Чат существует с 2016 года. За десять лет там накопились тысячи обсуждений и полезных сообщений, подборок! Можно было отправить старые чаты в архив и начать с чистого листа. Но участники рассказали, что периодически возвращаются к старым сообщениям и пытаются найти нужные разборы. Ключевое слово здесь — «пытаются» 😀 И тут две наши задачи сошлись в одну 😏 Мы решили с помощью ИИ разобрать архивы: найти темы, вопросы, решения и противоречия, сохранить ссылки на исходные сообщения и собрать всё в отдельную базу знаний на сайте с авторизацией. ❗️Так мы одновременно сохраним историю сообщества, сделаем её удобной для участников и покажем практическое применение ИИ на реальной задаче Именно этот проект станет основой воркшопа по вайбкодингу

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

➡️ Так что подробнее о воркшопе можете почитать тут. Но он точно стоит того, чтобы вы поучаствовали в нем!

«Системный аналитик не должен выбирать архитектуру»

Звучит вполне логично. Архитектор проектирует систему, аналитик собирает требования и описывает их. Но на практике (!) аналитик часто оказывается человеком, который лучше всех знает, что именно должна делать система Архитектор предлагает решение. А аналитик может спросить: - А что будет, если пользователь отправит запрос дважды? - Что произойдёт при недоступности внешнего сервиса? - Какие данные должны быть согласованы между системами? - Что изменится через полгода? Почти всегда ответы на эти вопросы напрямую влияют на архитектуру. Поэтому вопрос не только в том, должен ли системный аналитик «выбирать архитектуру». Вопрос в другом: Где заканчивается ответственность аналитика и начинается ответственность архитектора? 👀 Давайте в комментах похоливарим? У кого как на проектах? Считаете ли это правильным?

Самые частые ошибки в архитектурных решениях 🌚 Проверяем домашки учеников на курсе «Архитектура.База» и видим одни и те же паттерны. Кажется, что эти ошибки допускают все, кто начинает проектировать распределённые системы Делимся тремя горячими: 1️⃣ Дублирование кодов ответа в теле В ответе на запрос пишут ""code"": 200 и при этом в заголовках HTTP уже летит 200 OK. Зачем дублировать? Это лишний трафик, путаница, консистентность. Код ответа является метаданными, она живёт в заголовках HTTP. В теле достаточно возвращать только бизнес-данные и, если нужно, свой кастомный код для внутренней логики. А HTTP-статус уже говорит сам за себя. 2️⃣ Одна общая база данных на несколько сервисов !!! Технически это не запрещено. В реальных проектах такое встречается. Но как только два сервиса начинают писать в одну базу, ты теряешь независимость. Изменение схемы одной таблицы тянет изменения во всех сервисах-соседях. И ещё вопрос: кто отвечает за миграции? Кто гарантирует целостность, если один сервис упадёт посреди транзакции? Такое решение требует жёстких договорённостей и сильной дисциплины в команде. 3️⃣ Брокер вместо синхронного запроса Вместо того чтобы дёрнуть API и получить мгновенный ответ, ставят брокер сообщений. И получают усложнение инфраструктуры, задержки и головную боль с подтверждениями. Если тебе не нужна асинхронность, если клиент ждёт результат здесь и сейчас, брокер не нужен. Используйте синхронные вызовы там, где они уместны." ❗️Хочется отметить: само по себе решение редко бывает "плохим" или "хорошим". Вопрос в том, зачем вы его выбрали и какие последствия этого выбора понимаете. Именно это мы и разбираем на домашних работах!

Скинули много своих проектов, которые навайбкодили! А там правда есть на что посмотреть) На след неделе сделаем их подборочку, выберем интересные ✌️

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

Расскажем вам реальный кейс, с которым работает один из экспертов нашей школы Есть система1, которая для своей внутренней логики нуждается в данных из системы2. Немного НФТ: - объём данных -- 100 ГБ - 30 млн записей, в каждой по 30 полей - все данные лежат в одной таблице Вопрос: как организовать передачу? Какие варианты видите? Что предложите? p.s. REST вообще не вариант. Если отправишь запрос с телом в 100 ГБ, твой REST API умрет мучительной смертью на первом же сетевом устройстве. Серверы не читают файлы "на лету" частями. Большинство REST-фреймворков пытаются загрузить весь payload в оперативную память (RAM), чтобы распарсить его в объект. 100 ГБ в RAM это фантастика. У тебя просто нет столько памяти. Сервер упадет с ошибкой Out Of Memory (OOM) раньше, чем ты получишь первый байт данных в контроллере

Самые частые ошибки в архитектурных решениях Проверяем домашки учеников на курсе «Архитектура.База» и видим одни и те же паттерны. Кажется, что эти ошибки допускают все, кто начинает проектировать распределённые системы. Делимся тремя горячими: 1. Дублирование кодов ответа в теле В ответе на запрос пишут ""code"": 200 и при этом в заголовках HTTP уже летит 200 OK. Зачем дублировать? Это лишний трафик, путаница, консистентность. Код ответа является метаданными, она живёт в заголовках HTTP. В теле достаточно возвращать только бизнес-данные и, если нужно, свой кастомный код для внутренней логики. А HTTP-статус уже говорит сам за себя. 2. Одна общая база данных на несколько сервисов !!! Технически это не запрещено. В реальных проектах такое встречается. Но как только два сервиса начинают писать в одну базу, ты теряешь независимость. Изменение схемы одной таблицы тянет изменения во всех сервисах-соседях. И ещё вопрос: кто отвечает за миграции? Кто гарантирует целостность, если один сервис упадёт посреди транзакции? Такое решение требует жёстких договорённостей и сильной дисциплины в команде. 3. Брокер вместо синхронного запроса Вместо того чтобы дёрнуть API и получить мгновенный ответ, ставят брокер сообщений. И получают усложнение инфраструктуры, задержки и головную боль с подтверждениями. Если тебе не нужна асинхронность, если клиент ждёт результат здесь и сейчас, брокер не нужен. Используйте синхронные вызовы там, где они уместны."

Где на вашем проекте хранится правда? 👀 Вчера мы рассказывали про разработчика, который может самостоятельно поменять структуру базы данных, контракт или внутреннюю логику метода. Аналитики узнают об этом уже постфактум и пытаются догнать реальность документацией Но даже если забыть про конкретного коллегу, ситуация довольно знакомая: — в задаче осталась первоначальная постановка; — в документации описан согласованный вариант; — в чате потом договорились всё поменять; — на дейлике разработчик предложил ещё одно решение; — а в коде в итоге реализовано что-то пятое. Проходит несколько месяцев, к проекту подключается новый человек и задаёт простой вопрос: «А как это всё-таки должно работать?» Тут начинается расследование: поиск по чатам, просмотр старых задач, вопросы разработчикам и попытка понять, какая из найденных версий была финальной. Кажется, проблема не только в сложных коллегах. Если принятые решения и причины их появления нормально не зафиксированы, проект постепенно начинает жить на устных преданиях 😀 А где на вашем проекте хранится финальная версия решения? Ниже сделаем опрос, но можете рассказывать в комментариях подробно, какой источник у вас считается главным, когда документация, задача и реальная реализация говорят разное 👇

Какой коллега — твой главный кошмар? Мы, аналитики, общаемся со всеми: заказчики, разработчики, архитекторы, тестировщики и все, кто только есть в команде. Но со всеми ли легко находить общий язык?)

В нашем чате экспертов недавно был крик души. У одного аналитика в проекте есть разработчик, настоящий гений. Реально крутой профессионал, технически сильный. Но таких токсичных надо еще поискать. Он постоянно меняет постановку задач по-своему: переписывает структуру базы данных, правит контракты, внутреннюю логику метода может сделать по-другому. Сначала аналитики пытались актуализировать документацию постфактум, но это оказалось слишком долго и сложно. Решили внедрить процесс техревью с его участием. Он приходил недовольный, но хотя бы присутствовал. А недавно его перестали видеть даже на техревью, услышать его можно только на дейликах. Как быть? Что делать? Для команды это пока загадка

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

Сейчас снова проблемы с топливом — и приложение «ГдеБЕНЗ» опять как нельзя кстати Помните его историю? Создатель придумал сервис в самолёте, а после приземления завайбкодил его с помощью ИИ. И никакой команды разработки И мы тут подумали…:

Наверняка среди вас тоже есть те, кто уже завайбкодил своё приложение, сайт или сервис, но ему не хватает пользователей и нормальной обратной связи

Поэтому присылайте свои проекты нам в тг @care_sa ➡️ Самые интересные бесплатно покажем в нашем канале на 30 000+ человек — дадим аудитории потестировать, оставить фидбэк и, возможно, немного бустануть ваш проект 🚀 Что прислать: пару слов о проекте + ссылку/скрины Почему нам это интересно? Мы сейчас активно развиваем тему вайбкодинга и хотим чаще показывать не теорию, а реальные проекты и людей, которые их делают. Поэтому вам — аудитория и обратная связь, нам — классные реальные кейсы для канала 💛

Мы внимательно читаем обратную связь после каждого обучения После прошлой версии курса по архитектуре мы получили замечания, что он оказался слишком лёгким. Собственно, поэтому мы его и переделали: разделили программу на Базу и Хард, усилили наполнение и практику А в этот поток решили провести эксперимент — пригласили на обновлённые курсы тех, кто оставил самую развёрнутую и критичную ОС о прошлой версии На первом скрине — отзыв одного из таких учеников. Кажется, эксперимент удался 🥹 А второй скрин — небольшое предупреждение для тех, кто сейчас проходит Хард 😎 Хард на то и Хард! После прошлой версии вы просили нас усложнить курс — мы усложнили. Поэтому домашки теперь действительно непростые и иногда могут занять не один вечер Но зато представьте, с каким уровнем знаний и практики вы выйдете после курса 🤌

Кого бы вы наняли? Кандидат А: отлично знает UML, BPMN и DDD, но принципиально не использует ИИ Кандидат Б: знает теорию чуть хуже, но активно использует ИИ и умеет быстро проверять его результаты Битва началась. Кого ты возьмешь в команду и почему?

Vibe coding — программирование по атмосфере или настроению А вы уже пытались "вайбкодить"? Какие результаты?

Даже немного грустно, что все закончилось 🌚 Подвели итоги последнего розыгрыша, в котором выбрали всех, кто участвовал на протяжении 10 дней и выбрали трех счастливчиков! Ими стали: @lunacherry13 @Alesya_Demyanchuk @person_dii Спасибо всем, кто принимал участие! 💛

У человека паука сейчас две проблемы: 1. Колобок 2. Он не успеет купить наши курсы до конца дня Но вы не человек-паук, еще успеваете 😂 Через 2 часа уже всё, до НГ распродажи не планируем, лучше брать сейчас

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

Если вы только начинаете путь в системном анализе: — программа «Свой темп» поможет получить необходимые знания и практику для старта в профессии; — «Базы данных. Основы» и SQL помогут разобраться в работе с данными; — курсы по API, Postman и Swagger — понять интеграции и научиться работать с основными инструментами аналитика Если вы уже работаете системным аналитиком: — «Архитектура. База» поможет систематизировать знания и увереннее участвовать в проектировании систем; — «Архитектура. Хард» — углубиться в сложные архитектурные решения; — программы по брокерам сообщений, UX и базам данных — закрыть отдельные пробелы в знаниях; — курсы по ИИ — научиться быстрее работать с требованиями, документацией и другими повседневными задачами аналитика.

Можно выбрать одну программу или собрать сразу несколько. Чем выше общая стоимость, тем больше скидка В распродаже участвуют тарифы с обратной связью: с проверкой заданий, поддержкой и возможностью задавать вопросы экспертам. Доступ к материалам останется на год. Также можно оформить рассрочку на 3, 5, 6, 9 или 12 месяцев 👉 ВЫБРАТЬ ПРОГРАММУ

День 10. Финал марафона 💛 Вот и подошли к концу наши десять дней вместе Мы угадывали факты, искали ошибки, решали задачи, разбирались, где используется ИИ, и делились историями, которые связывают вас с нашей школой Спасибо каждому, кто участвовал — даже если вы присоединились только к одному из дней А теперь — финальный розыгрыш 🎁 Мы соберём комментарии под заданиями всех прошедших дней марафона и с помощью рандомайзера выберем трёх победителей. Каждый победитель сможет получить на выбор: — футболку школы; — настольную игру; — сборник ответов или задач для подготовки к собеседованиям. Ничего дополнительно делать не нужно. Если вы оставляли комментарий хотя бы под одним заданием марафона — вы уже участвуете. Результаты объявим 13 августа 💛 И напоминаем: сегодня заканчивается не только марафон, но и распродажа. До 23:59 обучение можно приобрести со скидкой до 50%. После полуночи цены вернутся к обычным 💯 - если понравилось и проводить такое еще раз ❤️ - если хочется что-то другое (напишите в комментах что улучшить!) 👌 - если не понравилось и такое делать не нужно