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

Навайбкодили базу знаний для аналитиков 😏 Виктор Шариков, который ведёт наш чат по искусственному интеллекту, несколько месяцев собирал полезные материалы из Telegram-каналов в Obsidian А потом превратил всё это в полноценный сайт: www.basahub.ru Завтра выложим видео, в котором Виктор покажет BasaHub изнутри и расскажет, как всё работает! А 5 и 12 сентября на воркшопе Виктор будет учить делать также, начиная от сбора данных до вайбкодинга сайта с авторизацией 👉 https://systemanalyst.life/vibe Выгодная стоимость только до завтра (включительно)

"Вайбкодинг - это для разработчиков, мне это не нужно" 😏😏😏 Что аналитик может сделать с помощью вайбкодинга? 1️⃣ Собрать прототип до постановки задачи разработчикам Не просто нарисовать несколько экранов в Figma, а показать работающий сценарий: кнопки нажимаются, данные сохраняются, пользователь проходит весь путь. Так гораздо проще обсуждать требования и находить ошибки до начала разработки 2️⃣Автоматизировать свою рутину Например, сделать инструмент для проверки требований, обработки файлов, подготовки документации, сравнения версий или формирования отчётов 3️⃣Превратить проектные материалы в базу знаний Собрать в одном месте чаты, документы, решения и договорённости, добавить поиск и ссылки на источники. Особенно полезно при онбординге новых сотрудников и передаче проекта 4️⃣ Проверить собственную продуктовую гипотезу Не искать команду разработки для идеи, которая ещё может никому не понадобиться, а сначала собрать MVP и дать его реальным пользователям. Именно так появились проекты подписчиков, которые мы недавно показывали в канале 5️⃣ Получить дополнительный источник дохода Небольшие внутренние сервисы, базы знаний, личные кабинеты и сайты с авторизацией нужны экспертам и небольшим командам. Аналитик уже умеет выяснять требования, раскладывать задачу и проверять логику. Остаётся научиться доводить это до работающего результата 🙂 Именно этому посвящён наш воркшоп: созданию реального продукта с помощью ИИ За два занятия мы пройдём путь от исходных данных и требований до базы знаний и работающего сайта ➡️ Подробности и программа: https://systemanalyst.life/vibe

Из-за меня упал прод! Эта мысль тревожила меня после очередного релиза моих задач. Вроде всё обсудили, требования согласовали, вопросы закрыли, а потом я иду и думаю: А вдруг я не учла что-то важное? Именно этого я боялась больше всего в начале работы аналитиком. А на выходных был выезд на конную базу с другими аналитиками, обсуждали страхи и услышала много историй: как легла система после нагрузки, которую не учли, как из-за одной глупой синхронной связи лег весь интернет-магазин Так что, решила написать этот пост как напоминание, что наша работа не только записать то, что рассказал заказчик. Наша работа — догадаться, о чём ещё нужно спросить. И, кажется, именно поэтому страх "я что-то упустил" никуда не исчезает даже с опытом А у вас как? Или есть другие страхи?

Можно. И часть работы он действительно сделает: прочитает файл, найдёт несколько тем и подготовит краткое содержание Тогда зачем этому посвящать два занятия по пять часов? 😊 Потому что один красивый ответ ChatGPT — ещё не база знаний 👇 Возьмём обычный проектный чат В 2020 году один участник предложил решение. Через несколько сообщений его раскритиковали. В в другой раз вернулись и выбрали другой вариант. А через n времени выяснилось, что реализация вообще работает иначе Если просто попросить нейросеть «выделить главное», она может собрать все эти сообщения в одно убедительное резюме. Только какое из решений в нём окажется финальным? И это лишь одна проблема. Внутри архива есть ответы на сообщения, пересланные публикации, системные события, файлы, ссылки, сообщения без контекста и разные обсуждения одной темы, разбросанные по годам Результат ещё нужно: — очистить от лишнего; — правильно разбить на связанные фрагменты; — сохранить даты, авторов и связи между сообщениями; — отделить вопросы от предположений и принятых решений; — найти противоречия; — дать возможность проверить вывод по первоисточнику; — организовать нормальный поиск; — превратить всё это в продукт, которым смогут пользоваться другие люди. Поэтому на воркшопе мы не будем искать один «секретный промпт». Мы соберём целый процесс: Telegram-архив → подготовленные данные → темы и решения → поиск по базе → сайт с авторизацией ➡️ Пройдя этот путь один раз, вы сможете повторять его с проектными чатами, документацией, профессиональными каналами, материалами для собеседований и другими источниками (все секретики расскажем на воркшопе) 😏 То есть результатом будет не просто страница, которую однажды сгенерировал ChatGPT, а понятная и воспроизводимая механика создания подобных продуктов Программа воркшопа и примеры применения: https://systemanalyst.life/vibe До 31 августа участие доступно по ранней стоимости. С 1 сентября цена изменится

Этот ответ помог получить нашему эксперту оффер! Несколько хороших ответов вчера было, но я хочу поделиться полным ответом, который дал эксперт на собеседовании: 1️⃣ Что такое обратная совместимость? Изменения делятся на: Минорные — добавили поле с default или сделали его optional. Старые консьюмеры просто игнорируют новое поле. Всё работает. Мажорные — удалили поле, изменили тип или сделали обязательным то, что было опциональным. Консьюмеры падают. Это ломающее изменение 2️⃣ Что такое Schema Registry и как он помогает В Kafka схема это часть контракта. Вместо того чтобы хранить схему в каждом сервисе, используют Schema Registry. Это отдельный сервис, который: - хранит все версии схем; - проверяет совместимость новых версий со старыми; - не даёт зарегистрировать схему, если она нарушает выбранную стратегию 3️⃣Стратегии совместимости (Backward / Forward / Full) Настройка уровня топика определяет, что можно менять: Backward — новая схема читает старые данные. Продюсер может обновиться первым, консьюмер — позже Forward — старая схема читает новые данные. Консьюмер может обновиться первым Full — и то и другое, но требования строже None — можно ломать всё что угодно (но на практике так никто не делает) Если вы пытаетесь зарегистрировать несовместимую схему — Schema Registry вернёт ошибку Если возникли сомнения и проблемы при ответе на вопрос, то на курсе «Архитектура. База» мы работает с kafka и проектируем интеграционные взаимодействия с этим компонентом. Старт уже 7 сентября!

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

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

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

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

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