Как каждый год деградировать в навыках и опыте? 😬 Дорасти до топовой должности.

Перейти в режим "я уже всё знаю".
Годами сидеть в одной компании.
Получать стабильное повышение 5-10% в год.
И быть уверенным, что ты вау!


А потом, спустя 5+ лет, выйти на рынок, потому что стало скучно… и офигеть.

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

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


Как пример, по моим ощущениям, 5 лет назад REST API, Kafka и микросервисы были чем-то уникальным для СА 🙌

Это были бонусы, которые ценились на отдельных проектах, и делали умножение ЗП на лучший коэффициент при выходе в новую компанию.

Сегодня же про Kafka и микросервисы спрашивают на каждом третьем собеседовании. REST API — вообще must-have для Middle СА. И не выпендриться уже, что я такая вот уникальная 🙁


👉 Такой вот жестокий мир IT.
Сидеть на месте тут не очень получается.


Я вообще постоянно переживаю, что могу отстать и не узнать что-то важное. Это отлично мотивирует.

Сейчас будущее за нейросетями.

Поэтому, на страхе отстать от жизни, я:
+ Пишу прототипы приложений
+ Езжу на конференции по AI
+ Разбираюсь с инфраструктурой, безопасностью и архитектурными проблемами AI
+ Считаю токены и оптимизирую запросы

И при всём при этом...
Я сижу с "синдромом самозванца" 😁
Это обычное явление, если ты постоянно изучаешь что-то новое))

IT — это про вечное обучение.

Те, кто приходят в IT только ради денег, надолго здесь не задерживаются.

Мы постоянно учимся.
Много работаем.
Это сфера, где ты либо постоянно растёшь, либо быстро устареваешь.


Так что если вам кажется, что вы ничего не знаете — это нормально.

Это ощущение заставляет
шевелить извилинами 🧠,
постоянно расти,
и быть лучшими в нашей профессии))

📚 Системным аналитикам: полный набор материалов для подготовки к техническим собеседованиям 📚

В этой подборке вы найдёте теорию вместе с разборами реальных рабочих задач.

Каждый материал подкреплён примерами для лучшего восприятия информации 🙌


REST API
▫️ Проектирование REST API: спорные вопросы с проектов и собеседований
🔹 Вопросы и ответы по REST API: собеседование на системного аналитика
▫️ Книга по JSON в REST API
▫️ Headers
▫️ Виды авторизации в API
▫️ Протокол HTTP
🔺 Связь базы данных и дизайна REST API
🔺 Postman: навык тестирования REST API за вечер

Интеграции
▫️ Как аналитику работать с задачами на интеграции — пошаговая инструкция
▫️ Интеграции - что это и основные способы
▫️ Отличия между обычными и интеграционными Use Case
▫️ Пример интеграционного Use Case
▫️ Практическое руководство по Postman - тестирование API DaData (с нуля до результатов)
▫️ Полный шаблон постановки задачи на интеграционный REST API-метод
🔹 Проблемы в работе с задачами на интеграции
▫️ UML-диаграмма: разбор задачи и инструменты

БД и SQL
🔹 Связь "многие-ко-многим": разбор задачи с собеседования
🔺 Проектирование БД: логический уровень
🔹 Нормальные формы БД
▫️ ER-диаграмма БД через код

Архитектура
▫️ 7 шаблонов проектирования архитектуры, которые важно понимать СА
▫️ Монолит, Сервисная и Микросервисная архитектура - сравнение
▫️ Как показать схему архитектуры: примеры решений
▫️ Нотация C4 для моделирования архитектуры
🔹 gRPС vs REST - что выбрать для проекта
🔹 Нефункциональные требования
▫️ GraphQL — знакомство на практике через Postman [пошаговая инструкция]
▫️ Очередь сообщений VS Брокер - вопросы с подвохами
▫️ Kafka


▫️ - статьи и книги
🔹 - подкасты
🔺 - видео YouTube

Сохраняйте, чтобы не потерять 👌

🔥 3 реальных задачи, которые решают брокеры 🔥

Брокеры сообщений — это не просто очереди для передачи данных. Это ТОП-инструмент для построения асинхронных, отказоустойчивых и масштабируемых систем.

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


Разберем три основных кейса, когда без брокеров не обойтись:

📌 1. Централизованная отправка уведомлений

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

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

👍 Почему так лучше?

+ Уменьшается связанность между сервисами
Если сервис уведомлений перегружен и не может принять сообщение сразу, оно сохранится в брокере.
Отправивший задачу на уведомление сервис не зависает в ожидании ответа, а продолжает работу.

+ Гибкое масштабирование
Когда 15 сервисов генерируют уведомления, для их обработки может понадобиться от 5 до 15 экземпляров сервиса уведомлений.
Без брокера система должна мгновенно реагировать на всплески нагрузки и увеличивать количество работающих копий сервиса уведомлений.
С брокером это не критично — сообщения просто ставятся в очередь и обрабатываются позже.

+ Можно легко добавлять новые каналы уведомлений (почта, пуши, SMS)
Например, в сервисе заказов сменился статус товара на "Доставлен".
Пользователь подписан на push, SMS и email-уведомления
Вместо того, чтобы сервису заказов делать три запроса или один долгий и ждать, пока каждое уведомление отправится, мы положим событие о смене статуса в брокер с пометкой о каналах доставки. А сервис уведомлений позже его обработает.
Таким образом, сервису заказов не придётся длительно ожидать ответ о доставке всех уведомлений.


📌 2. Централизованный сбор событий для мониторинга

Все сервисы отправляют в брокер данные о своих состояниях, ошибках, метриках. Из брокера эти события забирает система мониторинга, анализирует их и отправляет алерты DevOps-инженерам.

👍 Почему так лучше?

+ Все данные собираются в одном месте
Логи, ошибки, метрики и другие события поступают в брокер от всех сервисов, упрощая их обработку и анализ.

+ Гибкость и независимость от конкретной системы мониторинга
Можно легко подключать новые инструменты анализа и визуализации (Prometheus, ELK, Grafana и др.), не внося изменения в код сервисов, которые генерируют события.
Без брокера пришлось бы перенастраивать все сервисы на доставку в новый сервис мониторинга.

+ Гибкое масштабирование


📌 3. Реакция нескольких сервисов на одно событие

Один сервис отправляет событие в брокер, а сразу несколько других сервисов на него реагируют.

Пример:
При успешной оплате заказа в Интернет-Магазине сервис платежей отправляет событие "Оплата успешна" в брокер.

На это событие реагируют три сервиса:
▫️ Сервис заказов переводит статус заказа в "Оплачен"
▫️ Сервис склада списывает товары и создает задачу на сборку
▫️ Сервис уведомлений отправляет клиенту подтверждение об оплате

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

Сервис склада упал?
➖ Прервали процесс обработки события оплаты, потому что не получилось достучаться до склада
➖ Или потеряли уведомление о платеже и оно не дошло на склад

Брокер позволяет сделать процесс асинхронным и надежным.

👍 Почему так лучше?

+ Уменьшается связанность между сервисами
За счет асинхронного обмена и отвязки от режима реального времени, когда все должны работать и быть доступны.

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

+ Лучше отказоустойчивость
Нет риска, что событие не обработается в каком-либо сервисе - брокер даёт гарантию доставки.

+ Гибкое масштабирование


Итого:
Брокеры — залог гибкой, масштабируемой и отказоустойчивой архитектуры 👍

#АрхитектураGA

💫 Kafka - что надо знать для работы Системному аналитику 💫

Apache Kafka — это распределённая платформа потоковой обработки данных.

Предназначена для публикации, хранения и обработки событий/сообщений в реальном времени.


Основные компоненты:

✔️ Продюсеры (Producers)

1) Генерируют сообщения/события к обработке и отправляют в топики (темы).

2) Определяют, в какую партицию топика записывать данные: автоматически или по заданным правилам.

3) Могут быть чем угодно: микросервисы, устройства IoT и другие приложения.

4) Поддерживают режимы отправки:
+ Синхронный — ждёт подтверждения от Kafka перед отправкой следующего сообщения.
+ Асинхронный — отправляет сообщения без ожидания ответа.

5) Могут гарантировать доставку с разными уровнями подтверждения (acks):
+ acks=0 — без ожидания подтверждения (возможна потеря данных, высокая скорость).
+ acks=1 — подтверждение только от лидера партиции (среднее).
+ acks=all — подтверждение от всех реплик (максимальная надёжность).


✔️ Потребители (Consumers)

1) Подписываются на один или несколько топиков и получают сообщения/события.

2) Могут работать как отдельные клиенты или объединяться в группы (Consumer Groups) для параллельной обработки сообщений.

3) В группе консьюмеров каждый участник обрабатывает свою часть партиций.

4) Kafka гарантирует, что каждое сообщение будет обработано хотя бы одним потребителем в группе.

5) Модели доставки сообщений:
+ at-least-once — как минимум 1 раз, возможны дубликаты.
+ exactly-once — ровно один раз.


✔️ Топики (Topics) — логическая тема, куда продюсеры отправляют сообщения, а потребители их читают


✔️ Партиции (Partitions) — подмножество данных внутри топика, которое позволяет распределять нагрузку и масштабировать обработку сообщений. Каждый топик состоит из одной или нескольких партиций


✔️ Брокер (Broker) — сервер Kafka, который отвечает за хранение, управление и передачу данных внутри кластера


✔️ Кластер — это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных


#АрхитектураGA

📚 Мини-книга по Интеграциям для Системных аналитиков: самое важное 📚

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


Например, нам в приложении для медитаций надо сделать возможность оплаты подписки 🧘‍♀️

Получается, надо делать сложный банковский процессинг для проверки карт кучи банков, списания с них денег, проверки CVV, отправки проверочных кодов, безопасность приема и обработки платежей...?
В общем эту всю кучу банковских задач мы делать не хотим. Мы же не банк! 🥲

Поэтому, для упрощения своей жизни, мы подключим готовое банковское решение "Интернет-эквайринг" - то есть сделаем интеграцию с банковской системой.
Обычно это интеграции по API.


Главная идея интеграций:

Если не хочешь "изобретать велосипед", просто подключи (интегрируй) уже готовое решение в свою систему.

👉 Виды интеграций:

1) по окружениям:
▫️ Внешние - когда мы хотим подключить к нашей системе чужую систему, от других разработчиков.
▫️ Внутренние
- у нас на проекте сервисная или микросервисная архитектура, и нам надо сделать так, чтобы сервисы обменивались данными друг с другом по API или через брокеры (очереди).
- мобильное приложение работает с данными благодаря интеграции с сервером по API.

2) по направлению:
▫️ Во внешние системы - когда мы используем API чужих систем.
▫️ К нашей системе - когда мы сами разрабатываем свой API, чтобы к нам подключались (например, по примеру выше, мы банк, и даем другим свой API для подключения)


👉 Способы обмена данными:
▫️ Синхронный - отправили данные и получили ответ сразу.
▫️ Асинхронный - отправили данные и продолжили работу без ожидания ответа. Обработка в фоне.


👉 Основные способы интеграции:
▫️ API
▫️ Библиотеки и SDK
▫️ Брокеры (очереди сообщений)
▫️ Файлы
▫️ Общая БД


📚 Подробнее о том, что такое интеграции и какие они бывают, рассказала в мини-книге с картинками и примерами.

Файл прикреплен к посту.

Загружаем, изучаем и запоминаем 👍

#ИнтеграцииGA

💫 ПРОБЛЕМЫ В РАБОТЕ С ЗАДАЧАМИ НА ИНТЕГРАЦИИ 💫

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

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

1:18 - Что такое интеграции?
4:25 - Роль системного аналитика в процессе работы с задачами на интеграции.
11:41 - Как изменилась работа с задачами на интеграции за последние годы?
16:49 - Написал требования в соответствии с API-документацией внешней системы, а потом оказалось, что работает не так.
19:40 - Интеграция работала в продакшн и всё было хорошо, а потом всё внезапно сломалось.
22:57 - Что делать если предстоит интегрироваться с системой у которой еще нет API, а сроки горят?
26:18 - Разработчик системы, с которой предстоит интегрироваться, не предоставляет API и доступы, а задачу нужно реализовать, потому что сроки (P.S. Влиять через заказчика на внешнюю команду при возможности).
28:07 - Что, если вы тот самый разработчик, у которого просят API, но вам пока не до этого?
29:21 - Платные подписки и использование внешних систем. Примеры: DaData.ru, сервисы SMS-рассылок с поштучной оплатой со счета заказчика и другие.
31:58 - Разные структуры данных в разных системах: как собрать всё в нашей системе воедино? Про агрегаторы.
36:07 - Высокие нагрузки и длительное ожидание ответов. Асинхронные запросы и вебхуки.
39:37 - Не работал с видом API, по которому предстоит интеграция (REST API, GraphQL, gRPC, SOAP API и WebSocket - основные, посмотрите на них).
42:02 - Заключение и рекомендации


Эпизод доступен в:

⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Apple Podcast
⏯ Castbox
⏯ Spotify
⏯ Amazon Music


Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!

🔷 User Stories: подход и применение в интеграциях 🔷

User Stories –

это формат описания требований с фокусом на конечного пользователя и его потребности.

Этот метод широко применяется в гибких методологиях разработки (Agile, Scrum) и помогает командам формулировать задачи так, чтобы они отражали реальную ценность для пользователей или стейкхолдеров.

Вместо детального технического описания требований, User Story фиксирует:

👉 цель,

которую хочет достичь пользователь,

👉 основные критерии приемки,

которые являются аналогом функциональных требований.

Это делает требования более понятными для всех участников проекта – от бизнеса до разработчиков.

Детализация требований может быть (и будет) сделана на следующих этапах аналитики и разработки.


👉 Пример User Story:
Как пользователь-арендатор платформы #BookingGA,
я хочу видеть отзывы по домам и квартирам, предлагаемым в ней,
чтобы принимать более взвешенное и уверенное решение перед началом аренды.

👉 Критерии приемки:
+ После окончания аренды пользователю предлагается оставить отзыв по бронированию:
++ при просмотре истории бронирований в приложении,
++ через email и push-уведомления.
+ При размещении отзыва пользователь может поставить количество звезд, написать текстовое сообщение и прикрепить фотографии.
+ …

🔷 Особенность User Stories в интеграционных проектах – это акцент не только на взаимодействии пользователей с системой, но и на том, как разные системы обмениваются данными.

При формулировке таких историй и их критериев приемки важно учитывать:
✅ 1. Событийный характер данных
✅ 2. Взаимодействие с API внешних систем
✅ 3. Авторизация систем и пользователей
✅ 4. Логирование и мониторинг
✅ 5. Требования к гарантии доставки
✅ 6. Обработка дубликатов данных
✅ 7. Обработка конфликтов данных
✅ 8. Ограничения и лимиты API внешних систем
✅ 9. Масштабируемость и обработка больших объемов данных


Подробности каждого пункта и примеры разобрала в мини-книге к посту 📚

#ИнтеграцииGA

🐺 Работа не волк, но может и загрызть 🐺

Еще год назад я думала, что главное — это успеть как можно больше.
Работала по 10-12 часов в день, почти без выходных.
Жила в режиме «ещё чуть-чуть, и можно выдохнуть».

Но потом в очередной раз поняла:

Если не заботиться о себе, никакие успехи не спасут от выгорания, а потом никакие деньги не вытащат из больниц.

Уже не первое озарение.
И каждый раз с новой стороны.

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

Делюсь самым сокровенным.


◻️ Физическое здоровье

1. Спорт — неотъемлемая часть моей жизни уже почти 10 лет.
Даже если день загружен под завязку, я нахожу время подвигаться. Бегаю, делаю силовые, хожу на длинные прогулки.
Это не про «надо» — это про «если не сделаю, почувствую себя хуже».

2. Добавила регулярные чекапы.
Раз в год сдаю анализы, проверяю, какие показатели улучшились, а где капец.
В прошлом году нашелся дефицит железа. А еще слишком высокий уровень стресса.
Весь год работала над исправлением.
+ Витаминки и правильные продукты - мои лучшие друзья
+ Увеличение сна до 8+ часов (хотя всё ещё периодически косячу)
+ Два выходных в неделю без компьютера
В конце марта снова пойду проверять показатели.
Надеюсь, что ситуацию поправила.


◻️ Питание
С едой у меня вечно какая-то история.
Считаю калории, экспериментирую с выбором продуктов.
В этом году — полный отказ от кофе и алкоголя.
Пока похоже на интересный опыт и улучшение самочувствия.

Но самое неожиданное: год назад убрала из рациона молочку.
И впервые с подросткового возраста у меня чистая кожа. Ни один косметолог не дал такого результата! 😱
Приготовила сырники один раз за всё время, думала жаренный творог норм. Ага 🤣 Моё лицо дало реакцию на следующий день. На чипсы по неосторожности такой реакции нет, как на молоко))
У кого проблемы с кожей - рекомендую попробовать.
Привыкаешь со временем, но иногда скучаю 😅


◻️ Уход за собой
Дисциплина — это не только про работу и спорт, но и про заботу о себе.
Через "галочки" в ежедневнике каждый день заставляла себя пользоваться кремами, маслами для волос, делать маски.
Уже почти сделала рутиной это всё))
Для девушек это точно важно!!!
Ведь красота — это не только про внешность, но и про ощущение себя, самочувствие и качество жизни.


◻️ Ментальное здоровье

Отдыхать — это не слабость, а необходимость.

Путешествовать, делать выходные, спрашивать себя: «Как я себя чувствую?».
А если внутри хаос — не бояться пойти к психологу или коучу. Это реально помогает.

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

Работа в IT — круто, но порой стрессово.
Мы постоянно думаем, решаем задачи, держим в голове десятки процессов.
👉 И если не следить за своим состоянием, можно загнать себя так, что никакие достижения не принесут радости.
Работа загрызёт 🐺


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


Берегите себя ❤️