Системный анализ на максималках

Что спрашивают на собесах в 2025? + Практические кейсы 💡

Недавно я искал работу. Один из мифов, который удалось развеять для себя - то, что собесы стали очень сложными. Это не так (по крайней мере для грейда middle-senior)

Рассказываю об особенностях, которые отметил для себя

Теория 😴

В целом теоретические вопросы остались такими же - про требования, про различия БД, про интеграции, архитектуру. Все это вы уже наверняка читали и не раз. Из интересного немного:

🤍На каждом собесе спрашивали про кэширование, но не явно, а на примере кейса "Как оптимизировать/ускорить запрос от фронта к бэку".
🤍Глубже спрашивают про паттерны микросервисной архитектуры: BFF, API GateWay, Circuit Breaker, Saga, паттерны декомпозиции микросервисов. Советую изучить их, там нет ничего сверхъестественного

Практика 🤔

Куда интереснее - практика. Она тоже не стала сложнее, но решил поделиться кейсами, чтобы вы могли проверить себя:

🤍Спроектировать REST API для определенного кейса
Классика - система заказов еды, любимая всеми онлайн-библиотека, что-то еще. Требуют спроектировать REST API запросы: метод, endpoint, какие-нибудь особенности (пагинация, фильтрация)

Например: GET /books?author="Достоевский"&page=1&limit=5 - получение книг Достоевского с учетом пагинации

🤍SQL-запросы
Стали чаще спрашивать. Теорию могут спросить на скрининге (в чем отличия WHERE и HAVING?), на собесе почти гарантированно будет задача. Как правило решение будет содержать JOIN: либо INNER JOIN, либо LEFT JOIN, и агрегатные функции. Все мои задачи решались через джоины

Пример задачи: определить, какое количество каждого товара было куплено в 2025 году. Тут понадобится LEFT JOIN, так как некоторые товары могли не купить

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

🤍Спроектировать взаимодействие по процессу
А это было что-то новое. Собеседующий а-ля заказчик описывает процесс, а ты должен визуализировать его как угодно и предложить решение. Я выбрал UML Sequence и рисовал через PlantUML. А по другому и не знаю, как

🤍Найти ошибки в REST API
Тоже такой задачи не встречал, но она не стала сюрпризом

Приводят метод, заголовки и JSON с ошибками, надо их найти. Тут достаточно знать базу (отличия методов), основные заголовки (authorization, content-type) и синтаксис JSON

Например, "HEAD order?id=456 - частичное обновление данных"

—————

🚨

Еще несколько задачек в комментах

—————

В общем, собеседования особо не изменились - я ожидал везде гачимучи с System Design 🥵, а в итоге получал обычные собесы, где-то легче, где-то сложнее

⬇️ Пишите о самых запоминающихся практических задачках с собесов - возможно, они кому-то пригодятся при подготовке

Реально ли найти работу в 2025? Мой опыт

Отовсюду трубят, что рынок сильно изменился и устроиться на работу невозможно. Чтож, это вызов 🫡 - рассказываю, как недавно искал новую работу

Вводные 📌

Итак, обо мне:
🤍Техническая вышка
🤍3.5 лет в СА в аутсорс/аутстафф
🤍Опыт менторства
🤍Различные курсы, книги за плечами
🤍Нет опыта в биг техах/крупных компаниях (за исключением аутстафф)

Резюме разместил на трех площадках:
🤍HH
🤍GetMatch
🤍Habr

Начало поиска 🌚

15 сентября начал поиск, и неделю никто не писал - хотя два года назад, когда открыл едва мидловое резюме, в первую неделю было 5 собесов 🫥

Откликался сам, писал компаниям, знакомым - все безрезультатно. Беспощадные боты на HH отклоняют все отклики, другие игнорят, а другим компаниям, что звали работать, я уже не нужен (привет, Т-Банк)

Со второй недели HR начали писать сами. За все время поиска были следующие предложения:
🤍Аутстафф - 4
🤍Аутсор - 2
🤍Продукт (устройство в штат) - 4

Почти все писали с HH, лишь два рекрутера с Habr и... никто с GetMatch
Большая часть компаний - малоизвестные. Из крупняков только Альфа-Банк, WildBerries, Магнит Tech

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

Собесы 😁

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

Собесы были... как обычные собесы - чуть повысилась сложность, но в целом ничего фантастичного и нового 🌾

О том, какие были практические задания и как их решал - в следующем посте

Единственное, что заметил - появились вопросы "на волчонка" 😏. Например, если у вас указана какая-то компания, могут спросить, что она делает и где расположена

О волчонках мне есть, что сказать - но эта тема достойна еще одного поста

Итог 😎

В итоге 12 октября получил оффер куда хотел: поиск работы суммарно занял месяц. И вот какие выводы на основе моего опыта:

🤍Работу найти можно, но теперь это занимает больше времени (иногда - значительно)
🤍HH так и остается основной платформой
🤍На одну вакансию - от 200 до 500 (а то и больше) откликов
🤍По ощущениям осенью найм активизировался
🤍Боты на HH и волчата - основные препятствия при поиске, специалисты с ненакрученным опытом теряются на фоне
🤍Бездумно откликаться самостоятельно бессмысленно - лучше писать сопроводительное письмо, или вовсе забить и ждать HR
🤍Собеседования по структуре особо не изменились - правда, некоторые вопросы стали сложнее и глубже

⬇️ А вы искали работу недавно или может быть ищете? С каким трудностями столкнулись? Какие изменения на рынке труда заметили? Делитесь, интересно почитать

🤍🤍🤍🤍🤍🤍

Ухожу в отпуск 🌴, хочу также отдохнуть от постов – поэтому ничего не заготовил. Но, как выйду, расскажу, как искал работу в текущих непростых реалиях (спойлер – успешно нашел), и поделюсь инсайтами с собесов и в целом новостями по карьере – много интересного

А пока что – небольшие размышления на тему путешествий ✈️

До недавнего времени о них даже не думал – даже когда жил во Владивостоке, не сгонял ни в Китай, ни в Японию, ни в Корею (а тогда билеты в одну сторону стоили 7500 😭, а до Китая доезжают на автобусе)

Но в 2024 решил осуществить мечту супруги и мы поехали во Вьетнам, на целый месяц 🇻🇳. И это было одно из лучших решений в жизни – я быстро расслабился, забыл о бытовых и прочих проблемах дома, пропитался культурой... Благодаря смене обстановки поймал нехилый такой вайб

С тех пор выбираемся в другие страны, не так часто, как хотелось бы – были в Армении 🇦🇲, а сейчас решили вспомнить Турцию 🇹🇷. Хотелось бы путешествовать и в другие страны – но, к сожалению, сейчас это менее доступно

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

⬇ А вы путешествуете? Делитесь в комментах

Просто о Circuit Breaker 📌

Есть ли у вас друг, который вечно занят и редко соглашается на встречу? Сначала вы активно зовете его на кружку пива, а после нескольких неудачных попыток бросаете это гиблое дело 👀

Но спустя месяц кидаете мем в TG, слово за слово - и вот вы уже сидите в кафе и обмениваетесь новостями 🌾

На примере этой жизненной ситуации можно объяснить Circuit Breaker - паттерн МСА, который частенько стали спрашивать на собесе

🤍 Что такое Circuit Breaker
Circuit Breaker - это предохранитель, который реализуется на клиентской (вызывающей) стороне (на микросервисе или API Gateway)

🤍 Для чего нужен
Временно прерывать поступающие запросы в случае, если невозможно достучаться до другого микросервиса.

Circuit Breaker понимает, что вызываемый сервис лежит, и прерывает последующие запросы, давая возможность восстановиться после нокаута 🤡. Через время делает тестовый вызов - если сервис поднялся, то общение возобновляется

🤍 Принцип работы
🤍Если все в порядке и вызываемый сервис отвечает, то Circuit Breaker находится в состоянии Closed и спокойно пропускает запросы
🤍Если сбои участились, Circuit Breaker переходит в состояние Open и блокирует вызовы
🤍Через время Circuit Breaker переключается на состояние Half Open и делает тестовые запросы, чтобы проверить, исправлен ли сбой

А как Circuit Breaker понимает, что сервис лежит? Все просто - задается некоторый порог сбоев. Если количество неудачных запросов в состоянии Closed превышает порог, на ринг выходит Circuit Breaker. Порог устанавливается в % - например, 50% неудачных запросов из последних 20 запросов

Время ожидания (timeout) в состоянии Open - тоже настраиваемая метрика. Например, 30-60 секунд

—————
В итоге Circuit Breaker - это как предохранитель в электрощитке, временно предотвращающий вызовы к проблемному сервису. Благодаря ему повышается отказоустойчивость, и пользователю не придется ждать 10-20 секунд, чтобы словить ошибку

➡️ Забирайте себе и уверенно отвечайте на собесе

#полезное_системный_анализ

5 признаков, что компания – скам и вам пора бежать 🗑

Рассказываю реальную историю об одной из своих работ – какие тревожные звоночки были, и какие выводы из этого сделал

🤍 Локация – не гарантия

Та работа была в шикарном офисе в престижном бизнес-центре Москвы. Поначалу я был в восторге и офигевал от своей крутости

Но все это оказалось фальшивкой – по-моему мошенников и однодневок там столько же, сколько и везде. Просто у них больше денег на аренду 😁

Вывод: не верьте в красивую обертку – кинуть могут везде

🤍 Сомнительный проект

Бывало ли, что вы работаете над проектом, но не понимаете, откуда деньги и в чем прикол? Чувство, что продукт не решает реальные проблемы пользователей ❓

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

Вывод:

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

🤍 Миловидно-токсичное отношение

Руководство на публике – пушистые зайки, а при личной беседе – тираны и абьюзеры? Давление, манипуляции, навязывание своего мнения по личным вопросам – было немало неприятных историй. И часто они становились поводом для увольнений 🤬

Вывод:

если замечаете такое в коллективе – не думайте, что это вас не коснется

🤍 Внезапная текучка

За несколько месяцев до события Х мы заметили странное – коллеги из смежных отделов начали массово покидать компанию без видимых причин. Люди буквально испарялись 🤡

Вывод:

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

🤍 Задержки ЗП

Ну и вишенка на торте. Если это случается – сразу бегите. Теперь я не прощу задержки ЗП даже на один день

Было так – в день ЗП самой ЗП не произошло, потом каждодневные обещания выплаты. Задержки приобрели системный характер: обещания, частичные выплаты и снова задержки 😱

В таком режиме я продержался полтора месяца, и в итоге уволился. Кстати, деньги так и не выплатили

Вывод:

задержка ЗП – краснейший редфлаг

🚩

—————

Как-то смотрел с женой сериал "Разделение" – и был удивлен, насколько точно и правдоподобно авторы показали токсичную работу офиса, которая была точь в точь как у меня. У нас даже был свой Мистер Милчек 😅

⬇ А у вас были подобные истории? Делитесь в комментах

#истории_системный_анализ

Решаем рабочую задачу: Управление пуш-уведомлениями в мобильном приложении

Пробую новую рубрику – разбор реальных рабочих задач. Если интересно и хотите видеть другие задачи, поддержите и поставьте 🔥

Разбираем задачу, которая часто встречается в мобильных приложениях (и я тоже ее делал)

Постановка задачи 💡

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

С чего начать? 💬

С чего начинается танец СА? Правильно – с вопросов:

🤍 Какие группы уведомлений будут? (новости, акции)
🤍 Какие уведомления входят в каждую группу?
🤍 Планируются ли добавлять новые группы и уведомления в будущем?
🤍 Как настройки заданы по умолчанию?
🤍 Синхронизировать настройки между устройствами?
🤍 Нужна ли кнопка «Включить/выключить ВСЕ»?
🤍 Где в приложении размещаем экран настроек?

В итоге получаем инфу для БД, API и дизайна

Прописываем сценарии ✍️

Дальше подумаем над возможными сценариями:

🤍 Система задает дефолтные настройки для нового пользователя
🤍 Пользователь получает свои настройки
🤍 Пользователь меняет одну настройку
🤍 Пользователь меняет все настройки разом

Получилось не так уж и много

Проектируем БД ✍️

Возьмем самый сложный вариант – групп много, добавляться в будущем будут, настройки должны синхронизироваться

🤍 notification_settings – основная таблица (user_id, notification_id, is_enabled)
🤍 notification_groups – справочник групп
🤍 notification_types – типы уведомлений и их привязка к группам

Так мы сможем легко добавлять новые уведомления и группы

Проектируем API-запросы ✍️

Прикинем, какие API-запросы между фронтом и бэком понадобятся

🤍 GET /setting/notifications – получить настройки
🤍 POST /setting/notification или PUT /setting/notification/{id} – изменить настройку
🤍 POST /setting/notification/all – включение/выключение всех настроек
🤍 POST /setting/notification/default – внутренний метод для установки настроек по умолчанию

А теперь – неочевидные моменты ⚠

🤍 Дефолтные настройки. Вместо синхронного API-запроса лучше использовать асинхронное сообщение в брокер (например, Kafka). Потому что API-запрос может не отработать, и нужно думать, что с этим делать – ибо пользователь словит ошибку из-за отсутствия данных

🤍 Реакция UI. Запрос может отрабатывать долго и не отработать в итоге, и что в это время происходит на экране? Пользователь блокируется лоадером? Это кажется избыточным для такого простого действия

Лучше сделать искусственное обновление (Optimistic Update), когда пользователь нажмет тогл, то фронт сразу обновит его состояние и фоном отправит запрос. Если ошибка, фронт вернет предыдущее состояние и отобразит ошибку, а если все окей – ничего не поменяется

—————

⬇ Сталкивались с такой задачей? Пишите в комментах, как решали 

#разбор_задач_системный_анализ

Ныряем с аквалангом: как быстро заонбордиться на проект 📌

Процесс онбординга может затянуться на долгие недели, если не знать, как к нему подступиться. Держите пару советов, как его ускорить💡

🤍Список вопросов, которые я задаю

🤍 Есть ли документация и где ведется?
🤍 Есть ли работающая версия продукта и где ее можно посмотреть?
🤍 Как можно получить доступ к тестовой среде? (в целом спросите про доступы, какие есть и куда нужны)
🤍 Кто есть в команде, к кому можно обратиться по фронту/бэку/дизайну?
🤍 Как ведется коммуникация с заказчиком, нужно ли принимать нам участие в ней?
🤍 Есть ли демо на проекте, как проводятся?
🤍 Что ожидаете от системного аналитика на проекте?
🤍 Какой флоу работы?
🤍 Какие командные активности предусмотрены (дейли, ретро…)?
🤍🤍 Есть ли доска задач и как она ведется, кто ставит задачи?

🤍 Как я онбордюсь

Если документации нет – то процесс в любом случае затянется, так как придется:

🤍 Вдумчиво тыкать тестовую версию
🤍 Донимать вопросами коллег
🤍 Если вы аналитик, соответствующий требованиям 2025, изучать кодовую базу

Если документация есть, то тут попроще:

🤍 Я начинаю с архитектуры – какие есть компоненты системы и как взаимодействуют
🤍 Затем иду в БД – смотрю на сущности и реальные данные
🤍 После изучаю API-документацию (Swagger, Postman) – углубляется понимание системы
🤍 Потом все остальное (сценарии, ограничения, дизайн)

И параллельно изучаю тестовую версию (если мобилка – с Charles, если веб – с вебтулзами)

ОДНАКО! ⚠

Наличие документации не гарантирует упрощение онбординга. Был на проекте, где три итерации доки (одна с мезозойской эры, другая с викторианской эпохи, третья – новейшее время), но все три версии написаны с дырами, да и с мезозоя что-то было актуально, поэтому приходилось прыгать по доке

В итоге я так и не понял полностью систему, особенно бэк часть – работала и ладно, я все равно фронтом занимался

————————

⬇ А как вы онбордитесь на проекты? Какие вопросы задаете?

#полезное_системный_анализ
#чек_лист_системный_анализ

Собесы раньше vs Собесы теперь 🙈

Вопросы на собесе раньше:
1. Как вас зовут?
2. Сколько вам лет?
3. Из какого вы города?
4. Что такое ФТ и НФТ?
5. Что такое REST API?
6. Что такое брокер сообщений?

Результат: поздравляем, вы приняты

Вопросы на собесе теперь:
1. Что такое Cherry Pick в GIT?
2. Делали ли rebase в GIT?
3. Проводили ли вы ревью кода?
4. Разворачивали ли микросервисы самостоятельно?
5. Реализовали ли API запросы в коде?
6. Был ли опыт с WebView, какие параметры передавали?
7. Какие знаешь алгоритмы работы с данными?
8. Что такое Сircuit Breaker и для чего используется в системе?
9. Какие сериалы посоветуете посмотреть?
10. Что такое CQRS?

Результат (даже если на все ответил): извините, нам нужен кандидат посильнее

—————

Утрировано, но по ощущениям сейчас именно так. Вторая часть – реальные вопросы с недавних собесов

При этом на часть сложных вопросов реально ответить (Webview, Circuit Breaker, CQRS, сериалы), другие же вызвали у меня ступор, но не по причине незнания – реально ли у них СА всем этим занимается?

⬇ Если вы как СА черепикаете 5 раз в неделю, разворачиваете микросервисы и сами пишете АПИшку (а разрабы смотрят в сторонке) – отмечайтесь в комментах. А также пишите о своих вопросах, которые вызвали ахуй застали вас врасплох

#собеседования_системный_анализ

Версии HTTP – простой вопрос с собеседований 💡

Вопрос звучал так:

Какие есть версии HTTP и в чем их отличия?

Как СА я постоянно описываю интеграции, и не знал, что в первой версии HTTP был только метод GET, HTTP 1.1 используется более 15 лет, а HTTP 3 вышел недавно и активно внедряется 😱

Разберем версии HTTP на примере курьера

🤍 HTTP/0.9 (1991 г.)

Такого курьера вы бы не вызвали – он может привозить только одну вещь, и то без упаковки. После доставки сразу исчезает – и даже не предъявишь, если что-то пошло не так 😡

В базовой HTTP/0.9:
🤍Только метод GET
🤍Никаких заголовков, метаданных, кодов состояний
🤍По запросу приходил голый текст HTML
🤍Соединение сразу разрывалось

🤍 HTTP/1.0 (1996 г)

Этот курьер уже может передавать что-то другим лицам, а на посылках написано, от кого, кому, что внутри. Отправитель получит ответ, все ли ок, или что-то пошло не по плану

В HTTP/1.0:
🤍Появилась структура запросов и ответов
🤍Одиночество GET разбавили POST и HEAD
🤍Проблема – на один запрос одно соединение с клиентом, из-за чего сложные страницы грузятся долго

🤍 HTTP/1.1 (1997 г)

Уже через год наш курьер сильно подкачался 💪 – освоил новые методы работы, и не теряется после доставки товара, а остается на связи и может принести что-нибудь еще

В HTTP/1.1:
🤍Появились все известные нам методы (PUT, PATCH (2010), DELETE, OPTIONS, TRACE)
🤍Поддержка постоянного соединения

Эта основа веба используется по сей день

🤍 HTTP/2 (2015)

Гигачад-курьер отправляет разные заказы одному клиенту на грузовой машине по одной дороге. Улучшется эффективность, но если потеряем один товар, то вся доставка заблокируется, пока не найдем его

В HTTP/2:
🤍Синтаксис не изменился
🤍Появилось мультиплексирование – передача нескольких запросов и ответов в одном соединении TCP.

🤍HTTP/3 (2022)

Сын Яндекс.Доставки, курьер-супергерой, Сэм Бриджес. Вместо грузовой машины из прошлой версии этот гений использует мопеды, поэтому аварии ему не страшны 😼

В HTTP/3:
🤍Синтаксис не изменился
🤍Изменился транспорт: вместо традиционного TCP используется транспортный протокол QUIC поверх UDP, что улучшает производительность, делает потоки независимыми и ускоряет установку соединения

—————

Эта инфа поможет глубже понять REST, дать определение gRPC (который основан на HTTP 2), поразить собеседующего своими знаниями или просто станет интересным фактом

Забирай себе и ставь 🔥 , если узнал что-то новое

#полезное_системный_анализ
#собеседования_системный_анализ

Обзор малоизвестного инструмента Structurizr + промт для ИИ 🛠

У кого ни спрошу, никто не знает про инструмент Structurizr. Пора это исправить

🤍Принцип работы

Structurizr – бесплатный инструмент для визуалиазации и документирования архитектуры в нотации C4. Используется код для отрисовки документации, как в PlantUML

Пример работы на картинке

🤍Как в нем работать

Сложность инструмента – в синтаксисе кода, который менее интуитивный, чем в PlantUML. Можете изучить его, или поступить проще и попросить ИИ сгенерировать код на промта (см. в комментах)

🤍 Переходим на сайт https://structurizr.com
🤍 Нажимаем на вкладку "Demo"
🤍 Генерируем код на основе промта в какой-нибудь ИИ
🤍 Вставляем код
🤍 Нажимаем кнопку "Render"
🤍 Вы великолепны!

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

🤍Особенности инструмента

🤍 Моделирование в нотации C4 – один из стандартов для архитектуры
🤍 Текстовая нотация – можно версионировать, легко менять, автоматизировать, поддерживать актуальность
🤍 Разные форматы экспорта – в PDF, PlantUML, Mermaid
🤍 Возможность совместной работы

⚠ Недостатки:
🤍 Сложный синтаксис
🤍 Зависимость от кода, что может отпугнуть
🤍 Ограниченная визуализация – нельзя править стрелки и прочие элементы
🤍 Некоторые функции (например, совместная работа) платные

🤍Когда и кому пригодится?

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

В своей работе использовал один раз на коммерческом проекте и один раз на обучении – однако благодаря инструменту это заняло меньше часа. Вручную C4, при этом, несложно рисовать, но если можно автоматизировать – почему нет?

————

➡ Если вы работает с архитектурой, или у вас задача отрисовать C4 – попробуйте Structurizr. Если не пригодится в работе – можно блеснуть знаниями на собеседовании. Уверен, оценят

Ставь 🔥, если было полезно и хочешь видеть обзоры других инструментов

#инструменты_системный_анализ
#промты_ИИ_системный_анализ

👨‍💻 Вопрос, который мучает меня всю карьеру Системного Аналитика

Практически на каждом собеседовании спрашивают про SQL – где-то попроще, где-то посложнее с практикой в режиме реального времени. И при этом ни на одном из этих проектов я не написал ни единого SQL-запроса: хватало подключения к DBeaver для просмотра данных

При этом знаю других СА, особенно из области DWH, для которых SQL-запросы стали вторым языком после русского.
У меня это происходит так: практикуюсь с SQL либо перед собеседованием, либо для себя раз в полгода-год. Однако это как езда на велосипеде – если не практиковаться, то быстро забываешь

Но недавно нашел еще один способ поддержания этого навыка – читаю посты Дмитрия с канала Дима SQL-ит (Аналитика данных)

Дима — работает аналитиком данных в Wildberries 🛒

Пишет интересные посты про SQL с примерами таблиц и запросов:

🤍 SQL Ловушка: почему оператор NOT IN ломается, а EXISTS работает
🤍 Казалось бы, агрегатные функции в SQL (SUM, AVG, COUNT) просто считают значения — что тут сложного? Но есть скрытая ловушка: как они ведут себя с NULL?
🤍 Как работают конструкции ANY и ALL в SQL — объяснение на простых примерах

Также Дима не обходит стороной ИИ и их использование в работе и жизни — нашел для себя интересные варианты использования:

🤍Как за 400 рублей в год получить доступ к Claude, ChatGPT, Gemini и Grok через Perplexity и без использования VPN
🤍 Вайбкодинг — бесплатный аналог Cursor AI от Alibaba (Qoder)
🤍 Бесплатные нейросети для аналитики и кода
🤍 Бесплатная нейросеть от Google для работы с любыми материалами — NotebookLM

Но помимо этого Дима пишет не менее интересные посты про личную эффективность, выдержки из книг и просто личные мысли:

🤍Как за год стать в 37 раз лучше: конспект «Атомных привычек» - Джеймса Клира. Часть 1 и Часть 2
🤍10 идей для повышения эффективности, которые я усвоил из книги Максима Дорофеева (Джедайские Техники)
🤍Здоровье в IT: как я борюсь с сидячим образом жизни. Часть 1
🤍Мое понимание мира - прими неопределённость или почему истины нет, а есть только вероятность

Рекомендую подписаться: тут есть, о чем почитать

⬇️ А вы используете на работе SQL? Или эта тема вас также обходит стороной, как и меня? Пишите в комментариях

API Gateway как бабка-вахтерша от мира IT 😼

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

Если не идентифицировали – то не пропускают. Если узнали – то подскажут, куда идти

🤍Что такое API Gateway

В мире IT подобный пост охраны называется API Gateway (шлюз) – единая точка входа, через которую клиенты (мобильное или веб-приложение) общаются с бэкендом

API Gateway это паттерн микросервисной архитектуры, поэтому этот компонент бэкенда вы увидите там

🤍 Основные функции

У API Gateway куда больше полезных функций, чем просто проверка и маршрутизция запроса:

🤍 Единая точка входа – клиенту не нужно знать адреса десятка серверов
🤍 Маршрутизация – шлюз сам решает, к какому сервису направить запрос
🤍 Аутентификация и авторизация – может выступать вместо или перенимать функции сервиса авторизации
🤍 Управление трафиком – можно поставить ограничение для одного клиента (например, не более 1000 в минуту)
🤍 Кэширование – может кэшировать ответ в своей памяти и отдавать данные, не обращаясь к сервису
🤍 Мониторинг и логирование – шлюз формирует журналы запросов, что поможет при отладке и анализе работы
🤍 Агрегация данных – шлюз собирает ответы из нескольких микросервисов

🤍Пример работы

Есть запрос:

GET https://api.my-shop.com/my/orders – получение списка заказов

где https://api.my-shop.com – адрес нашего API Gateway

Порядок работы:

1 – От клиента запрос поступает на шлюз
2 – Шлюз проверяет авторизацию (JWT-токен) на валидность и получает ID пользователя
3 – Шлюз видит URL /my/orders и понимает, что это для сервиса заказов
4 – Шлюз отправляет внутренний запрос в Сервис заказа (GET /internal/orders?user_id=12345)
5 – Шлюз получает ответ 
6 – Шлюз отправляет ответ клиенту

Если нужно агрегировать данные – то между 4 и 5 шагами будет отправка других запросов и агрегация данных

🤍Мой опыт

На проектах, где были микросервисы, всегда был API Gateway. Где-то был задействован полнее (с функциями авторизации и управления трафика), где-то это был просто маршрутизатор

И на этих проектах, как СА, я просто знал, что API Gateway есть и выполняет определенные функции. Максимум моей работы – отобразить компонент на схеме архитектуры и описать возможности 🐸

Знаю при этом, что в крупных проектах, где несколько API Gateway, над каждым работает целая команда – и там, я думаю, СА вовлечен более детально. Если у вас есть такой опыт, пишите в комментах

—————

В итоге API Gateway – важный компонент микросервисной архитектуры, который принимает все запросы, проверяет их и отправляет нужным сервисам, а результат возвращает клиенту. Он разгружает внутренние сервисы и клиента, делая их независимыми, но при этом является единой точкой отказа

➡ Забирай себе, пригодится в работе с микросервисами или на собесах

#полезное_системный_анализ

Собеседование в Samokat.tech (бывший) – или как вызвать аналитика на ковер 😱

Год назад думал о смене работы – и тут мне написала бывшая коллега из Samokat.tech с предложением. Решил попробовать, почему нет? И собес оказался запоминающимся – с негативной стороны

🤍Все начиналось хорошо

По структуре собеса все стандартно – первый этап с HR, второй с техническим специалистом, а третий с командой

Первые два этапа не вызвали сложности – классический скрининг, довольно интересная техничка на полтора часа. Мне нравится, когда технический специалист вовлечен в процесс и любит свое дело, для меня это положительный сигнал о компании 😍

И совсем не нравятся короткие технические собесы на 20 минут – писал о них ранее

🤍 Но настал этап общения с командой…

На встрече присутствовало несколько членов команды – системный аналитик, лидер команды, еще какие-то люди. Общение шло гладко, пока лидер команды не стал предупреждать о том, что СА у них раз в 1 или 2 недели вызывают на ковер 😏

Продукт связан с расчетом логистики, и за неточности расчетов и жалобы клиентов почему-то отвечает СА. Причем вызов на ковер звучал как обычное регулярное мероприятие, типа дейлика 🌾

Лидер команды то и дело ссылался на другого СА на звонке, но радости и эмоций на его лице я не увидел. Интересно, почему

Сразу представил картину – стоишь на экзамене или в военкомате перед длинным столом, за которым сидят суровые дядьки. Говорить можно только по разрешению, шаг влево, шаг вправо – расстрел🌾

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

С этого момента я начал сильно сомневаться, речь поутихла, в голове гуляла мысль: «А надо ли мне оно?» 😎. Идти на работу со страхом – ненужный стресс, которого и без того в жизни немало

Взаимного мэтча не произошло, мне пришел отказ – HR предлагала попробовать с другой командой, но желания не было. Еще смущал тот факт, что в тот момент Samokat.tech объединялся со Сбером, а подобные процессы для меня еще один ред флаг

———————

Через некоторое время узнал, что знакомая, которая рекомендовала это место, сама сменила работу 🤣. Я же рад отказу – наверняка в других командах другие процессы, но первое впечатление было испорчено

⬇ А как вы считаете, должен ли системный аналитик отчитываться за косяки продукта и нести полную ответственность? Пишите в комментариях

#собеседования_системный_анализ

Промт для генерации User Story и Use Case 🤖

Как-то на проекте я был одним аналитиком, и всю доку писал в гордом одиночестве – а ее было ну очень много. Самую нудную часть – User Story и Use Case – отдал ИИ на аутсорс 😼

Делюсь этими промтами с вами

🤍User Story

Тут все просто, нужно лишь скормить ИИ:
🤍Описание системы (наиболее полное) с разделами
🤍Шаблон стори
🤍Соответствие критериям INVEST
🤍Критерии приемки

Промт:

Работай как системный аналитик. Есть система – мобильное приложение по учету финансов со свободной регистрацией по логину и паролю, счетами, возможностью добавлять операции (доход/расход). Опиши User Story для каждого раздела по шаблону «Как <роль>, я хочу <функция>, чтобы <ценность>» одним предложением. User Story должны соответствовать INVEST. Также должны быть приведены критерии приемки 

Если не уточнять 2-4 пункты, то ИИ напишет в неудобном формате и уйдет в разнос. Результат и сравнение на первой картинке

🤍Use Case

Тут поинтереснее: для ИИ нужно указать структуру Use Case с примером

Предполагаю, что в первом примере получил список пронумерованных User Story и нахожусь в том же чате

Если нужна конкретная User Story, то так и вписываем: Опиши Use Case для User Story: [вставьте User Story]

Промт:

Опиши Use Case для User Story из раздела 3 из списка выше по следующему примеру:

**Use Case Авторизация на портале через логин и пароль**
**Участники**: Пользователь
**Предварительные условия**:
1. У пользователя есть соединение с интернетом
2. Пользователь имеет аккаунт на портале
**Триггер**: Пользователь нажал кнопку «Войти» на главной странице
**Выходные условия**: Пользователь получил доступ к личному кабинету
**Основной сценарий**:
1. Пользователь нажал кнопку «Войти»
2. Система отображает форму для входа
3. Пользователь вводит логин и пароль
4. Пользователь нажимает кнопку «Войти»
5. Система проверяет логин и пароль
6. Система выдает токен авторизации
7. Система отображает личный кабинет
(необязательно) **Альтернативный сценарий**:
1. Пользователь нажимает кнопку «Войти через Google»
2. См. Сценарий «Авторизация на портале через Google»   
**Исключительные сценарии**:
5e: Логин и пароль неверные
1. Система отображает ошибку
2. Пользователь вводит верные логин и пароль

Сделай Use Case в виде таблицы. Для каждого Use Case должна быть своя таблица. Добавь еще User Story, которую описываешь

Обратите внимание на форматирование в виде таблицы – ее легко скопировать себе в доку

Также лучше явно указывать список сторей. Если попытаться указать "по всем User Story", то ИИ сгенерит только самые основные

Если дать свободу ИИ и не указывать шаблон, то в целом он тоже справился, но сделал по своему шаблону (неудобно копировать, не все поинты описаны) – результат и сравнение на второй картинке

—————

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

#промты_ИИ_системный_анализ

Путь до архитектора. Часть 3 🚀

Всех с пятницей и хороших выходных! 🌴

Это заключительная часть серии постов про архитектуру (часть 1, часть 2). Расскажу про виды архитекторов в IT, что я сделал по плану и что еще предстоит

Архитекторы в IT 📌

Рассмотрим, какие есть архитекторы в IT, на примере строительства города

🤍 Корпоративный архитектор (Enterprise Architect)

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

В IT такой человек занимается архитектурой всей компании/предприятия, которая состоит из множества решений. Вовлечен в бизнес-процессы и общается с топ-менеджерами, практически никогда не работает с кодом

🤍Архитектор решений (Solution Architect)

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

В IT архитектор решений занимается конкретным проектом (или проектами): собирает требования и подбирает технологии, платформы, сервисы для реализации. Редко вовлечен в код, больше работает с технологиями и проектированием

🤍Системный архитектор (Software Architect)

Отвечает за сложные системы внутри каждого дома: вентиляция, электроснабжение, лифты, отопление. Гарантирует, что все работает надежно и эффективно

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

Куда расти системному аналитику? 🤔

Узнавал информацию у компаний, которые обучают СА, у ментора, у ИИ, из других источников. И в итоге вижу два мнения:

🤍Solution Architect – наиболее частое мнение. Они тоже собирают требования, моделируют и проектируют, но более технически подкованы и смотрят на систему шире. Желательно, но не обязательно, уметь программировать
🤍Enterprise Architect – путь для «стратегов», кого интересует «большая картина». Такие архитекторы более погружены в бизнес-часть и понимают, как архитектурные решения влияют на всю экосистему компании

А Software Architect, на мой взгляд, наиболее подойдет для разработчика, а не СА

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

Мои мысли 💡

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

Недавно прошел тестовое интервью по System Design с ментором-архитектором. Ментор оценил мои знания как очень неплохие. По его оценке, уже через полгода могу претендовать на роли в архитектуре

Правда, я в этом сомневаюсь, у меня немного другой план:

🤍Поработать с высоконагруженным проектом с микросервисной архитектурой
🤍Брать сложные задачки с принятием решений
🤍Прочитать хотя бы 50% из списка книг из второй части
🤍Прокачать софт-скиллы
🤍Написать pet-проект а-ля Социальная сеть и пощупать разные технологии (особенно темный лес DevOps)

Без спешки и непредвиденных обстоятельств оцениваю переход в 1.5-2 года. Причем не могу сказать, каким хочу быть архитектором – пока у меня только самурайский путь без цели

——

Если посты на этой неделе были полезны, ставь 🔥

И как вы думаете, куда логичнее расти системному аналитику? Или may be свой вариант?

#полезное_системный_анализ

Путь до архитектора. Часть 2 🚀

Первая часть тут. Во второй – список годных книг по архитектуре в желаемом порядке чтения 📚

📌 Забирайте себе, чтобы не потерять

🤍Погружаемся в архитектуру

В целом о том, что такое архитектура и для чего нужна:

🤍«Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы»: Нил Форд, Марк Ричардс

🤍 Знакомимся с типами архитектуры и распределенными системами

Подробнее про типы архитектуры: монолит, микросервисы

🤍«Распределенные системы. Паттерны проектирования»: Брендан Бернс
🤍«От монолита к микросервисам»: Сэм Ньюмен
🤍«Создание микросервисов»: Сэм Ньюмен

🤍 Углубляемся в корпоративные приложения и интеграции

Некоторая информация в этих книгах устарела, но они такие же классические, как Вигерс:

🤍«Шаблоны корпоративных приложений»: Мартин Фаулер
🤍«Шаблоны интеграции корпоративных приложений»: Хоп, Вульф

🤍Думаем о будущем

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

🤍«Эволюционные архитектуры. Поддержка непрерывных изменений»: Нил Форд, Ребекка Парсонс, Патрик Куа

🤍Глубже изучаем модели данных

О том, почему проработка модели данных – это действительно важно:

🤍«Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем»: Эрик Эванс
🤍«Изучаем DDD предметно-ориентированное проектирование»: Влад Хоронов

🤍Собираем все в кучу

🤍«Высоконагруженные приложения. Программирование, масштабирование, поддержка»: Мартин Клеппман

🤍А как же поддержка?

Следующие книги – про релизный цикл, доставку обновлений, поддержку систем, CI/CD и все такое:

🤍«Site Reliability Engineering». Надежность и безотказность как в Google»: Байре, Джоунс, Петофф
🤍 «Release it!! Проектирование и дизайн ПО для тех, кому не все равно»: Майкл Т. Найгард

🤍Про масштабирование и нагрузку

🤍«Масштабирование приложений. Выращивание сложных систем»: Ли Атчисон
🤍«Паттерны Kubernetes: Шаблоны разработки собственных облачных приложений»: Билджин Ибрам, Роланд Хасс

🤍Облака

Сложная и специфичная тема с облачными решениями, особенно востребованная в международных проектах

🤍 «Шаблоны проектирование для облачной среды»: Корнелия Дэвис

––——–––

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

#книги_системный_анализ

Путь до архитектора. Часть 1 🚀

Как и обещал, рассказываю о своих планах по переходу в архитекторы

Разбил пост на три части – тут делюсь чек-листом по темам архитектуры ПО. Им со мной поделился мой ментор – опытный архитектор

Делюсь доской в Холст – там весь чек-лист можно рассмотреть подробнее. А еще оригинал картинки в комментариях

📌 Чек-лист по темам

🤍 Теория по проектированию систем (System Design)

Must have темы для изучения, развитие базы системного аналитика:

🤍Паттерны архитектуры: монолит, сервисная, микросервисная, Serverless, корпоративная
🤍Сеть: топология, DNS, OSI & TCP/IP, протоколы
🤍Интеграции: REST, SOAP, GraphQL, gRPC, WebSockets, Webhook, Kafka, ActiveMQ, RabbitMQ
🤍Прокси: балансировщики нагрузки, Reverse Proxy, API Gateway
🤍Процессные движки: BPM, Activiti, Camunda
🤍Базы данных: DML & DDL, транзакции, ACID, изоляция, нормализация, реляционные БД, нереляционные БД, in-memory БД, индексы, репликация, шардирование, профилирование, CAP-теорема
🤍Кэширование: CDN, клиентский кэш, серверный кэш
🤍BigData: Hadoop, S3, Spark
🤍Поисковые движки: Elasticsearch, Opensearch
🤍Безопасность: виды аутентификации, хэш-функции, SSL/TLS, HTTPS

🤍 Алгоритмы и структуры данных

Двигаемся далее и погружаемся в алгоритмы и структуры данных:
🤍Алгоритмы: понятие сложности алгоритмов, оценка сложности
🤍Структуры данных: массивы, списки, очереди, графы, деревья, хэш-таблицы

🤍Frontend & Backend

Наиболее сложная и объемная часть для тех, кто ранее не программировал. И пригодятся темы только архитекторам, работающим с кодом

🤍Frontend: базовое понимание устройства (протоколы, веб-сокеты, cookie). В идеале изучить какой-нибудь язык (например, JavaScript) и написать небольшой pet-проект
🤍Backend: общие принципы работы (ООП, SOLID, Паттерны проектирования), изучение языка (например, Java) и pet-проект

🤍DevOps & Тестирование:

Не обязательно углубляться, достаточно изучить общие концепции и инструменты:
🤍DevOps: как устроен CI/CD, Docker, Kubernetes
🤍Тестирование: теория, интеграционные тесты, unit-тесты, Postman, Swagger, Charles

🤍Методологии разработки & Soft Skills:

Все что связано с управлением проектом и взаимодействием с людьми:
🤍Методологии: Waterfall, Agile, Lean
🤍Soft Skills: все, что с ними связано

И как все это осилить? 🤯

Курсы, книги, менторство, pet-проект, сложный проект на работе:

🤍Курсы. Дорого и эффективно. О курсах, которые для меня покрыли бОльшую часть тем System Design, расскажу в будущих постах
🤍Книги. Углубляют знания, полученные на курсах. Мне помогли Крис Ричардсон «Паттерны микросервисной архитектуры» и Алекс Сюй «Прохождение сложного интервью по System Design», о которых я уже писал
🤍Менторство. Хороший способ выявить пробелы и восполнить знания – проверено
🤍Pet-проект. Лучший способ попробовать все технологии и инструменты. И благодаря ИИ это будет не так сложно
🤍Сложный проект на работе. Это как кидать ребенка в воду, чтобы тот научился плавать

—————

💡 Если тоже хотите начать изучать архитектуру – сохраняйте пост себе, чтобы не потерять

Это была первая часть. Во второй части – список рекомендуемых книг, в третьей – мои мысли по поводу перехода в архитекторы

#полезное_системный_анализ