Отзыв на воркшопы System Education🧑‍🎓

Как-то довелось мне посетить два воркшопа от System Education – один на тему «Брокеры сообщений RabbitMQ и Apache Kafka», второй о «SQL. От проектирования до эксплуатации». Рассказываю свои впечатления

P.s. не реклама. Я действительно прошел воркшопы (сертификаты в комментах) и просто пишу свое мнение

1⃣ Проектирование Apache Kafka и RabbitMQ

• Дата: сентябрь 2023
• Длительность: 4 занятия по 4 часа
• Стоимость: ~20000 руб (для компаний), для физлиц было дешевле, но точную сумму не вспомню
• Страница воркшопа

Тогда мои знания про Kafka и RabbitMQ были очень плачевны🚨, поэтому надеялся на воркшопе как минимум разобраться в принципах работы. Моя цель была не просто выполнена, а перевыполнена

Начну с плюсов:

➕ Глубокая и действительно интересная практика. Теория была, но практика заняла бОльшую часть воркшопа. На первых двух занятиях мы запустили сервисы на Python, подняли инстанс Kafka и отработали два сценария – спаминг сообщений в Телеграм и наполнение таблицы в Google (т.е. были еще и интеграции, вау). На следующих двух занятиях проделали то же самое для RabbitMQ. И все это с нуля!
➕ Множество заготовленных материалов. Помимо статей перед стартом организаторы подготовили код сервисов на Python. Код мог запустить каждый ученик онлайн без настройки окружения и прочих мучений. А еще ведущие помогали, если код не работал по каким-то причинам
➕ Профессиональные ведущие. Мне запомнилась Анна Вичугова – она отвечала на все вопросы, помогала как могла и была вовлечена в процесс

Но есть и минус:
❌ Командная работа. Во время занятий мы делились на команды и переходили в комнаты для групповой работы. То ли мне так везет, но всегда в моей команде были очень неактивные люди, которые все время молчали. Приходилось брать лидерство, но было чувство, что я болтаю сам с собой

✔ Эти занятия меня очень впечатлили – я не ожидал, что будет настолько интересная практика. Сказать, что я стал гораздо лучше разбираться в Kafka и RabbitMQ, это ничего не сказать

Но следующий воркшоп меня впечатлил не так сильно

2⃣ SQL. От проектирования до эксплуатации

• Дата: январь 2024
• Длительность: 2 занятия по 4 часа
• Стоимость: на тот момент ~5000 руб (физлиц), ~10000 руб (для компаний)
• Страница воркшопа

С этим воркшопом я планировал закрыть пробел по проектированию реляционных БД. Правда, там было не только проектирование, но еще и SQL-запросы, которые меня интересовали меньше. К сожалению, воркшоп не оправдал мои ожидания

Плюсы:
➕ Заготовленные материалы. Была и теория, и практические задания, и домашку, и мои любимые «командные» кейсы. Тут не придраться
➕ Формат обучения. За один уикенд можно изучить и проектирование, и базовый SQL

Минусы:
❌ Самого проектирования было сильно мало. Две трети воркшопа мы занимались SQL-запросами, а про проектирование БД я ничего нового не узнал
❌ Чувствовалась спешка со стороны ведущего. Из-за частых вопросов от аудитории мы сильно выбились из графика. В итоге сложные JOIN пробежали буквально за пару минут. Возможно, блок с вопросами стоило вынести в конец

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

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

➡ Итог

Если говорить о воркшопах, то формат от System Education мне понравился – можно быстро закрыть какую-то проблемную для себя тему. Но нужно точно понимать, что именно ты хочешь, и внимательно изучить программу - возможно, уже и так все знаешь. А еще может встать вопрос цены - она довольно кусачая

P.s. Еще в этой школе есть «буткемпы» для БА и СА (интенсивная программа обучения). Слышал, что это имба, могут прокачать с нуля до middle, но сам не проходил, да и ценник ну слишком высокий (сейчас от 164 000 руб до 205 000 руб. за 3 месяца). За «буткемпы» ничего сказать не могу

————

⬇ А вы проходили воркшопы от System Education? Какие у вас впечатления? Пишите в комментах

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

Просто о партиционировании

Продолжаю цикл небольших материалов про сложные термины на темы БД: на этот раз разберемся с партиционированием

📌 Определение

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

Но что такое большая таблица? В этом контексте это миллиарды строк😰. Представьте стог сена, где спрятана игла. Чтобы найти ее, нужно немало времени. Также и в системах: очевидно, с таким объемом данных она будет медленнее работать

💡 Виды партиционирования

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

➡️ Горизонтальное партиционирование

Представьте, что мы разрезаем таблицу горизонтально. Сделать это можно так:

• По диапазону значений (Range Based). Например, по ID или дате – в одной партиции храним записи с ID от 0 до 500 000, в другой от 500 000 до 1 000 000
• По спискам (List Based). Например, по странам или категориям – в одной партиции храним данные по России, в другой по Вьетнаму
• По хэшу ключа (Hash Based). Тут посложнее: берем хэш-функцию, в качестве значений – один из столбцов (например, user_id). Результат делится на N, где N – количество партиций. Остаток от деления определяет номер партиции, куда мы запишем данные. Плюс такого способа: равномерное распределение
• По ключу (Key Based). Как Hash Based, но используется само значение ключа

Где что подойдет:
• Range – для логов и исторических данных
• List – для географически распределенных систем
• Hash/Key – для равномерного распределения данных

➡️ Вертикальное партиционирование

А теперь таблицу делим вертикально, по колонкам

Предположим, у нас таблица с тремя атрибутами: ID, name, email. Вжух – и теперь у нас две таблиц:, в первой id и name, во второй id и email

На практике этот способ деления встречается редко

⚠️ Партиционирование – не панацея

Партиционирование не подойдет, если:

❌ Маленькие таблицы (до 1 млрд строк) – расходы ресурсов будут неоптимальными
❌ Если запросы затрагивают все партиции – скорость выполнения не снизится, а может даже и увеличится

И подойдет, если:
✅ У нас огромная таблица – свыше 1 млрд записей
✅ Мы столкнулись с техническими ограничениями сервера – физически нет места
✅ Нужно удалить/архивировать данные – например, логи
✅ Нужно распределить нагрузку из-за частых запросов по одному критерию (например, по дате)

🆚 Индексы vs партиционирование

Казалось бы, зачем пилить таблицу, если есть индексы? Да, они тоже ускоряют работу с данными, но они не подойдут для огромных таблиц, т.к. тоже занимают место на диске. И индексы используются для «точечных» поисковых запросов, а не для выборки групп данных. В общем, разные задачи

Однако оба метода можно комбинировать – разбить большую таблицу на партиции, а внутри сделать индексы

—————

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

А вы сталкивались с партиционированием на проекте? Пишите, если был опыт

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

Просто о шардировании

Шардирование – слово, которое боятся произносить, как имя Волан-Де-Морта

📌 Определение

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

Принцип шардирования – разделение данных и хранение их на разных серверах. Части целого называют шардами

– Не путаем с репликацией. Тогда бы у всех книг было бы по 3 копии, и по 1200 книг мы бы хранили в разных местах. А если купили новую – пришлось бы делать копии

– Не путаем с партиционированием. Тогда бы все книги лежали дома (т.е. на одном сервере), но в разных углах

➡ Когда используют шардирование?

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

➡ Головная боль шардирования

Как распределить книги?

Тут как с партиционированием – по диапазону, по ключу. Например, книги можно шардировать по фамилиям авторов – в один шард от А до Ж, во второй от З до М и так далее

Когда я куплю новую книгу, то отвезу ее в определенное место согласно своим же правилам

Как понять, куда везти новую книгу?

Есть несколько методов маршрутизации:
– На стороне клиента. Мы знаем, в какие шарды что записано. Появляется логика на клиенте
– На стороне сервера. Кто-то другой за нас держит эту инфу, а мы просто передаем ему книгу. Дополнительная логика на сервере
– Маршрутизация встроена в БД. Все происходит автоматически, но такая функция встречается редко

Что делать, если нужно перераспределить книги?

Мы не задумывались о порядке, поэтому книжка Вигерса лежит между «Война и мир» и «Кулинарные рецепты Гордона Рамзи» 😁

Нужна перебалансировка (Rebalancing) – процесс перераспределения данных между существующими шардами

Сложности в самом процессе: допустим, это займет пару часов, но в этот период могут поступать новые данные

Способы решения:
1️⃣ На время допустить только чтение (проще всего)
2️⃣ Читать из старого шарда, а записывать в новый
3️⃣ Логическая репликация – делаем между старым и новым шардами логическую репликацию и переключаемся на новый

Что делать, если нужно добавить новое место хранения для книг?

Мы литературный гений, поэтому прочитали еще 300 книг. Осознали, что нужно еще одно место для хранения. Арендуем склад (это будет наш пятый шард) и думаем, как перераспределить нашу кипу

По научному это Решардинг (Resharding) – процесс изменения схемы шардирования (добавление/удаление шардов)

Тут на помощь придет такой метод, как Consistent Hashing – когда книги распределяются так, чтобы при добавлении нового места не пришлось перекладывать все заново

➡️ Примеры использования шардирования

1. Социальная сеть. Миллиарды лайков, постов, комментов. Шардируем по user_id и храним данные и действия пользователей в рамках одного шарда
2. Мессенджеры. Миллиарды сообщений. Шардируем по chat_id, храним их на разных шарах
3. Маркетплейсы. Тонны товаров и заказов. Товары можно шардировать по product_id, а заказы по user_id

—————

⬇️ Доводилось ли вам работать с системами, где использовалось шардирование? Пишите в комментах

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

📖 Прочитал книгу «Микросервисы. Паттерны разработки и рефакторинга» и делюсь мнением

• Автор: Крис Ричардсон
• Объем: 544 с.

💡 О чем книга?

По шагам о микросервисной архитектуре: автор начинает с описания монолитного ада 😈, затем приступает к проектированию микросервисов с нуля по этапам, от сбора требований до развертывания. Для наглядности используется один сквозной пример – приложение по доставке еды FTGO а-ля Яндекс.Еда 🍟

В основном книга о всевозможных паттернах микросервисной архитектуры: о их плюсах и минусах, принципах работы, о том, когда что выбрать. Описаны шаблоны, о которых я уже слышал («База данных на сервис», «API Gateway»), так и специфичные для разработки типа «Предохранитель», «CQRS» и другие

Бонусом в конце каждой главы приведен код на Java с подробным разбором – в теории можно самому все спроектировать 👨‍💻

А теперь о том, что понравилось, а что нет глазами СА

⭐️ Что понравилось

➕ Структура повествования и сквозной пример. Постепенно вместе с автором опускаешься в глубины микросервисов и по кирпичикам выстраиваешь одну систему
➕ Много схем и изображений. Визуально все воспринимается намного проще
➕ Подробно разжеваны технические моменты. Удалось понять CQRS, узнал про тестирование, лучше стал понимать межсервисное взаимодействие

🤔 Что не понравилось

⚠ Четверть книги – разбор кода. Это не минус, просто эти куски текста тяжело понимаются даже при условии, что умеешь читать код. Для полного понимания потребуется спроектировать несколько своих сервисов
⚠ Некоторые главы так и остались темным лесом, а именно Глава 6 «Разработка бизнес-логики с порождением событий» и Глава 12 «Развертывание микросервисов». Этот материал отправил меня в нокаут на пару дней

➡ Кому подойдет?

Для СА уровня от middle, которые желают разобраться с микросервисной архитектурой. Еще будет очень полезна разработчикам, которые на практике работают с микросервисами

⬇ Итог
Отличная книга, в которой собрана, на мой взгляд, вся нужная информация про микросервисы

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

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

—————

Читали ли эту книгу? Если да, то как вам?

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

🏆 Решил поучаствовать в конкурсе телеграм-каналов

Моему каналу чуть больше месяца, и я неимоверно рад, что решился завести его🥳. Мне приятно делиться своими находками и опытом, рассказывать о своем пути СА и объяснять сложные термины простыми словами. Большое вам спасибо за реакции, комменты – очень ценю 🫡

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

А пока что хочу рассказать, что решил принять участие в конкурсе телеграм-каналов. Надежд не питаю, так как канал совсем молодой, но заявку уже одобрили 🔥 – посмотрим, как пойдет

– Ссылка на лендинг конкурса: https://tg-contest.tilda.ws
– Группа канала конкурса: @tg_contest_main

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

—————

⬇ Какой пост на канале запомнился вам больше всего?

🔥 Поработал на двух работах в IT и сгорел

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

💡 Есть «темка»

В IT есть такая «темка» – брать в работу несколько проектов помимо основной работы, оформляя их по самозанятости или ИП

Случайно мне выпал шанс поработать так – я увольнялся и переходил на новое место, но первый работодатель не хотел меня отпускать и предложил перейти на договор ГПХ 💡

«Хмм, дополнительный заработок, круто» – подумал наивный я 🤑. Тогда у меня был небольшой опыт в системном анализе (всего год), но я не сомневался, что потяну – буду вставать пораньше, а после основной работы переключаться на вторую и заканчивать попозже

Как же я ошибался...

👨‍💻 Разорваться и выжить

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

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

В итоге обе работы смешались в какого-то монстра, приходилось еще дорабатывать до глубокой ночи. А еще врал и тут, и там: основной работодатель не знал о моей «шабашке»

Само собой это повлияло на менталку и здоровье в целом. Я стал более раздражительным, сон был ужасным, забил на близких и друзей, забыл про прогулки и наслаждение жизнью 👨‍💻

Апогеем стали внезапные нервные срывы без причины. Это случилось со мной впервые. Я понял, что это серьезный звонок 🛑, и принял решение окончательно расстаться с первым работодателем

В итоге в таком режиме я продержался всего полтора месяца

🤯 Последствия

В тот период жизни мое ментальное состояние было не очень - частая смена работы, относительно недавний вход в IT, частые переезды и первые серьезные отношения

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

➡ Какие уроки вынес?

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

Я не был готов к такому опыту из-за:
– Малого опыта в профессии
– Отсутствия подходящей рабочей обстановки
– Недоговоренностей с работодателем
– Непростого периода в жизни
– Отсутствия явной цели

Главное из этого опыта – понял, что нельзя изнурять себя. Думал, что выдержу многое, но ошибся. Это привело к последствиям для здоровья, о которых я даже и представить не мог ранее. Поэтому я начал ценить отдых, вернулся к хобби, проработал work-life balance – и больше не проверяю себя на прочность 🏝

—————

⬇ А вы пробовали совмещать проекты? Как справлялись? Пишите в комментах

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

🏖️ Почему я впервые отдохнул только в 26 лет

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

🙄 Поиск себя

Получив магистра по робототехнике, в 23 года я вернулся в родной город в заснеженной Якутии 🥶. Там из роботов - максимум микроволновка

Но работать надо было, поэтому устроился инженером по связи в Мегафон. Я не шарил за связь, но у меня был напарник, благодаря которому я продержался полгода 😏. Поняв, что это не мое, уволился - хотя через полгода я уже мог получить отпуск в 1 месяц

Дальше был сумбур – поработал в родном городе 2 недели в другом месте, понял, что нужно ехать в Москву. После переезда удалось найти работу инженером-программистом. Но предприятие оказалось в антураже СССР с тестировщиками, которым уже за 70. Чувствовал себя некомфортно, поэтому снова уволился через 2 недели 😧

В итоге прыгал между работами и нифига не отдыхал

👨‍💻 Поиск себя… в IT

Однако в Москве довольно быстро получилось войти в IT. Причем не абы где, а в Москва-Сити 💎. Правда, формат был очным, поэтому приходилось 5 дней в неделю кататься туда-сюда и тратить по 3 часа на дорогу. Однако новая сфера и молодой коллектив перекрывали эти минусы

И вот через полгода я ждал, что наконец-то наступит мой первый заслуженный отпуск, но и тут не повезло – на работе перестали платить зарплату, и я уволился 🤯

Отдыхать не стал, устроился в другое место. Но это оказался аутстафф, тогда мне, новичку в сфере, этот формат не пришелся по вкусу, и я уволился через 2 месяца 🥴. И тут же устроился на место, где работаю сейчас

🌴 Первый отпуск

И только тут случился мой долгожданный отпуск длиной в 1 неделю. Мы с женой отправились на Красную Поляну – замечательное место, чтобы отдохнуть от всего 🏔

Однако мой мозг отличника переживал за работу и проекты – поэтому я заходил в рабочие чаты, отвечал на сообщение и в целом был включен в работу. Классическая ошибка: в итоге в отпуске не скажу, что отдыхал 😫

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

📌 Какие уроки вынес

Что я понял из своего опыта:

➡️ Херня случается. Если вынуждены уволиться и есть подушка безопасности – лучше взять перерыв в одну-две недели и постараться отдохнуть
➡️ В отпуске забываем про чаты и работу. Поверьте, и без вас справятся
➡️ Если есть возможность – делать отпуск насыщенным. Посетить другую страну, начать что-то новое, съездить на природу
➡️ Не работать без отпусков. Выгорание гарантировано – см. предыдущий пост

—————

⬇ А как вы отдыхаете от работы и проводите отпуск? Пишите в комментариях

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

Помните, я вписался в конкурс тг-каналов?

Я выбрал трек «Карьера», и меня добавили в уютный чатик. Там я увидел других интересных авторов, которые тоже пишут про свой карьерный путь

Кто-то только начинает его и рассказывает о первых достижениях, а кто-то уже занимает (или занимал) руководящую должность и делится неочевидным опытом управленца. HR-менеджеры, Data-аналитики, Карьерные коучи, Продакты, Маркетологи – пишут специалисты из разных предметных областей, но в основном IT

💡 Мы объединили наши каналы в папку, чтобы не потеряться. Делюсь этой находкой с вами - возможно, тоже найдете для себя интересных авторов

💎 Папка карьерных каналов

Как понять, что сбор требований завершен? Чек-лист для СА

Все зависит от методологии

➡ Сбор требований в Agile

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

✅ Не можете придумать новые use case или user story для этой фичи
✅ На встречах обсуждается одно и то же
✅ Заказчик уже говорит о фичах на будущее, а не о текущей
✅ Новые требования выходят за рамки фичи
✅ Новые требования имеют низкий приоритет
✅ У разработки после груминга нет или крайне мало вопросов

Если выполнены все эти пункты, можно говорить, что требования собраны 🎉

Требования могут измениться уже на этапе аналитики/разработки, но это тема для отдельной дискуссии. Могу рассказать о своем опыте - ставь 👍, если интересно

➡ Сбор требований в Waterfall

В Waterfall, в отличие от Agile, сбор требований покрывает весь продукт

Критерии завершенности сбора такие же, но нужно декомпозировать ТЗ на отдельные фичи

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

➡ Можно ли собрать все-все требования?

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

Все требования собрать невозможно (особенно в Agile) – заказчику что-то приснилось, или прочитал новости о какой-то трендовой фиче. Или во время разговора с коллегой родились новые идеи. Даже если все-все требования собраны, высок риск, что уже завтра они поменяются

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

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

⬇ Итог

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

—————

💬 А как у вас со сбором требований на проекте? Часто ли меняются? Пишите в комментариях

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

Как увидеть запросы в режиме онлайн? Используем Charles

Не знаете, как смотреть API-запросы в режиме реального времени? Держите классный инструмент - Charles

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

Charles – сниффер (sniffer – перехватчик) HTTP/HTTPS трафика. Работает как прокси-сервер: вклинивается в цепочку «Клиент - Сервер», перехватывает все запросы и отображает их в интерфейсе программы

Работает для веб и мобилки, но наиболее эффективно для мобильных приложений, т.к. для веб проще посмотреть запросы через WebTools. Однако для работы нужна будет дебаг-сборка приложения, а не прод – там запросы закрыты

Есть еще другие снифферы: Proxyman, Fiddler, Wireshark. Суть одна, отличаются интерфейсом, набором функций и платформами

➕ В Charles мне понравились следующие фишки:

• Можно увидеть порядок вызова запросов
• Отображается полная информация о запросе и ответе
• Можно подменить запрос и посмотреть, что будет

⚠ Однако есть и некоторые трудности
• Сложно настраивать. У меня Charles работает только на Android, на iOS трудности с сертификатами
• Громоздкий интерфейс – легко потеряться
• Бесплатная версия на 30 дней, а потом ограничение по времени работы

➡ Когда Charles пригодится СА
• При онбординге на проект
• При изучении задачи на доработку/улучшение фичи
• При выявлении багов и изучении проблемы

➡ Мой опыт
Использовал Charles на трех проектах, все мобильные приложения. На двух из них восстанавливал документацию, на третьем нужно было понимать, как дорабатывать существующую функциональность – что нужно изменить в запросе, в каком порядке вызывать новый

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

⬇ Итог
Если вы работаете с мобильным приложением, и вам непонятно, как оно работает с технической стороны – качайте дебаг-сборку и установите Charles или любой другой proxy

Также делюсь статьей с Хабра про установку на все платформы и обзор функциональности Charles

————

Как думаете, пригодится в работе?

👍 Да, нужно попробовать
🤷‍♂️ Нет, не потребуется

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

💡 Паттерны микросервисной архитектуры для СА

Сохраняйте список паттернов микросервисной архитектуры (МСА), который пригодится системному аналитику при:

– Распиле монолита на микросервисы
– Проектировании МСА
– Подготовке к собеседованию
– Изучении принципов МСА

Okay, let’s gooo

🔹 Паттерны проектирования

1. Разбиение по бизнес-возможностям – на каждую хотелку бизнеса по одному микросервису. Пример: сервис управления доставкой
2. Разбиение по поддоменам – отдельный микросервис для каждой сущности. Пример: сервис заказов (сущность заказ)

🔹 Паттерны декомпозиции

1. «Душитель» (Strangler) – постепенный переход с монолита на МСА, по завершении монолит отключается
2. «Слой антикоррупции» (Anti-Corruption Layer) – когда полностью отказаться от монолита невозможно. В этом случае добавляется сервис-прослойка для связи с новыми микросервисами

🔹 Паттерны коммуникации микросервисов

1. API-шлюз (API Gateway) – единая точка входа для клиентов. Для маршрутизации запросов и не только
2. Бэкенды для фронтендов (Backend for Frontends, BFF) – отдельные API-шлюзы под разные платформы (Web, Mobile, Desktop) или роли (Клиент, Ресторан, Курьер)

🔹 Паттерн управления данными

1. База данных на сервис – у каждого микросервиса своя БД
2. Сага (Saga) – про управления транзакциями в микросервисной архитектуре с откатом при ошибках
3. API-композиция – сервис для агрегации данных из нескольких источников

🔹 Паттерны мониторинга микросервисов

1. Проверка работоспособности (Health Check) – эндпоинт /health для проверки статуса сервиса
2. Трассировка запросов – каждому внешнему запросу назначается уникальный ид (traceId) для отслеживания в цепочке вызовов
3. Агрегация логов – централизованный сбор логов со всех сервисов

🔹 Паттерны построения UI

1. Сборка интерфейса на стороне клиента – фронт запрашивает данные и формирует интерфейс самостоятельно
2. Или на стороне сервера – сервак отдает готовые страницу, фронт просто отображает

—————

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

⬇ Хотите разбор некоторых паттернов?

🤩 Естественно
🗿 Нет, списка достаточно

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

Проект провалился, я виноват? 🌧

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

Первый фейл

Заказчик хотел автоматизировать работу своих менеджеров, чтобы у них все было в одном месте. Срок был сильно сжатый

Что пошло не так:
🔴 Заказчик накидывал свои хотелки как только мог, мы их не отбивали
🔴 В основе решения иностранный сервис, который в итоге ушел из РФ
🔴 Как СА я не поспевал за темпом разработки, поэтому ребята делали не так, как хотел заказчик
🔴 Тут случился мой конфликт с разрабом с последующим его увольнением. Это затормозило разработку важнейшей фичи

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

Второй фейл

Второй проект – из гос. сектора. Несложный, но дико непонятный из-за специфичной сферы деятельности компании

Что пошло не так:
🔴 Работали по дырявому ТЗ с противоречивыми требованиями, поэтому возник сильный разрыв ожиданий
🔴 Из-за сферы деятельности не понимали, правильно ли делали или нет
🔴 Выяснилось, что наш заказчик и не заказчик вовсе, а есть другой заказчик, но об этом узнали на финальном демо

Итог: успели в срок и сделали все по ТЗ, но из-за разрыва ожиданий и неопределенности со стороны заказчика дорабатывали систему за свой счет

✍️ Какие уроки извлек

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

Но спустя время понял, что моя вина минимальна. Вот почему не стоит винить себя в провале

🟢 Не все мы можем контролировать и предугадать. Бюджеты урезают, кто-то халтурит, у кого-то другой темп работы, санкции прилетают, что там в голове у заказчика - никто не знает
🟢 Виноват не конкретный человек, а вся команда. Если ты часто косячишь, тебя просто уволят. Если тебе тычут на ошибки, этот человек не умеет общаться. Если команда ищет виноватых вместо решения – стоит найти компанию получше. Во всей моей практике удар принимала вся команда, и мы вместе решали проблему
🟢 Иногда твоей квалификации просто не хватает. Это нормально что-то не знать. Одно дело, когда ты соврал на собеседовании, другое – когда от тебя хотят большего, чем ты можешь

Что можно сделать, чтобы минимизировать вероятность провала:

1 Делиться своими переживаниями с командой и руководителем
2. Защищать свои решения и конструктивно обсуждать их с командой
3. Принимать, что ошибки – часть работы
4. Учиться на ошибках, выписать их и провести саморефлексию
5. Делать свою работу честно и добросовестно, чтобы не винить себя
6. Если не справляешься, попросить помощи – коллеги, в чате аналитиков, у ментора, у ChatGPT

Провал проекта — это почти всегда системная проблема, а не вина одного человека. Если ты честно выполнил свою работу, но проект всё равно сорвался — значит, были другие факторы. Анализируй, учись и двигайся дальше

———————
⬇️ А у вас были неудачные проекты? Пишите, что чувствовали и какие уроки извлекли

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

Собес на 20 минут – red флаг при трудоустройстве? 🚩

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

🔹 Мой опыт

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

Второй собес поинтереснее. 30 минут, из них первые 15 минут про проект и поверхностные вопросы СА, остальные 15 нерелевантные должности вопросы (деплоил ли проект, мигрировал ли БД) и бесполезная болтовня про жизнь. Я понял, что что-то не так

Прилетел отрицательный фидбек – сказали, что очень слабый специалист ❓

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

🔹 Другой опыт

Иной опыт у моей супруги – при трудоустройстве в IT-компанию, где она сейчас работает, у нее был сухой и короткий технический собес, после которого она сильно расстроилась. Не было понятно ничего, она думала, что провалила

Но уже через час ей прилетел положительный фидбек и приглашение на следующий этап

🔹 Почему так получается

Такие собеседования сильно зависят от интервьюера:

1. Он – очень скиловый человек, с завязанными глазами определяет компетенции кандидата и найдет человека в багажнике на парковке
2. У него плохое настроение или «таких как вы у меня 10 человек в день»
3. Он оказался тут случайно, попросили подменить – приходится выкручиваться
4. У него не развиты софт-скиллы
5. Проводит собес и параллельно работает
6. Не умеет проводить собес, поэтому это сухой и быстрый опрос с вопросами из статьи с Хабра «Топ 100 вопросов системному аналитику на собесе»

Но в любом случае кандидат остается в смятении. Даже если придет положительный фидбек, осадок скорее всего останется. Исключение – если мастерски попал в ожидания

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

🔹 Что делать после отрицательного фидбека

Чтобы сухой отказ не расстраивал, поинтересуйтесь, что было не так:

1. Запросите подробный фидбек
2. Запросите критерии оценки
3. Проанализируйте свои ответы и сделайте выводы

Так можно понять, это вы где-то не так ответили, или интервьюер не успел раскрыть ваши навыки

——————

⚠️ Короткие собесы – не всегда red flag, но часто сигнализируют о слабом интервьюере или неорганизованности. Если после такого общения остается осадок – стоит насторожиться

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

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

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

Частые вопросы про паттерны МСА на собесе СА 📌

Тут рассказал про основные паттерны МСА, а сейчас – про вопросы по этой теме, которые мне задавали на собесе

Что такое BFF?

Тут важно понимать, что такое API Gateway и зачем он в системе. BFF – Backend for Frontend (Бэкенды для Фронтендов) – подход, при котором используется несколько API Gateway под разные платформы (мобильные девайсы, десктоп, веб) или роли (клиент, курьер, ресторан). BFF используется, например, в Uber.

Это снижает нагрузку, разграничивает API и позволяет отдать разные Gateway на поддержку разных команд. Но если в системе роли плюс-минус похожи, а функциональность платформ одинаковая, в шаблоне нет смысла

Задача – разделить монолит на микросервисы. Что будешь делать?

В ответе говорим про два шаблона из группы «Паттерны декомпозиции» – Strangler или Anti-Corruption Layer. Аналитику сначала нужно изучить функциональность, а затем спроектировать будущие сервисы на основе этих паттернов

О чем паттерн CQRS?

О нем я не писал, но на собеседовании меня однажды спросили. CQRS (Command Query Responsibility Segregation) – паттерн, разделяющий операции чтения (запросы, queries) и записи (commands). При этом под чтение и запись создаются разные модели данных.

Шаблон применяется, когда в системе есть дисбаланс по операциям (например, чтение чаще чем запись), и он помогает масштабировать систему. Не стоит применять, если у вас простое CRUD-приложение или нет требований к масштабируемости

Как решается проблема согласованности данных в микросервисах?

Когда в одной операции задействовано несколько микросервисов, и один может не обновить/записать данные – возникает несогласованность

Тут на помощь придет паттерн Saga – бизнес-транзакция разбивается на цепочку локальных транзакций. Если хотя бы одна не выполнится – запускаются компенсирующие транзакции (откат). Подробнее разберем в следующем посте

Как определяются границы микросервисов? / С чего начать проектирование?

Обращаемся к группе «Паттерны проектирования». Каждый сервис должен отвечать за отдельную бизнес-область (домен, сущность): базу данных, бизнес-логику и API мы проектируем в пределах этой области.

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

Как организовать мониторинг и логирование микросервисов?

Тут поможет шаблон «Агрегация логов» – то есть централизованный сбор логов со всех сервисов для возможности мониторинга

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

Как повысить отказоустойчивость микросервиса?

Еще один неочевидный паттерн для СА – «Предохранитель» (Circuit Breaker). Шаблон основан на отслеживании количества неудачных запросов к сервису

Если мы отправили 50 запросов сервису, а он не ответил, то Circuit Breaker временно блокирует вызовы к нему, переключаясь на fallback-логику (например, кэш или заглушу). За это время сервис восстановится и продолжит свою работу

➡ Итог

Перед собеседованием на проект, где есть МСА, нужно повторить:

🔹 API Gateway vs BFF
🔹 Saga
🔹 Strangler vs Anti-Corruption Layer
🔹 Паттерны проектирования
🔹 (вряд ли попадется, но вдруг) Circuit Breaker, CQRS

—————

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

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

Нужно ли СА знать программирование? + Краткий анализ рынка

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

Давайте разбираться, нужно или нет

🔹 Что там на рынке?

Проанализировал вакансии на HH. Из 2685 вакансий в 74 встречаются ключевые слова «код» и «язык». Это всего 2.75%. Если пройтись по каждой, то можно убрать еще несколько вакансий, т.к. в выдаче попадаются «английский язык» и «дресс-код»

В 15% из отобранных вакансий это обязательное требование, в 45% это «желательно» или «будет плюсом», в 40% это «большой плюс»

😄 Самое интересное – вакансии, в которых это требование обязательное:

– Системный аналитик (middle) (еще ок)
– Младший системный аналитик/Технический писатель
– Младший системный аналитик

А для мидлов и сеньоров это опционально ❓

🔹 Зачем нужен этот навык?

Когда это действительно нужно:

1. Специфичный стек, или сам проект специфичен (блокчейн, анализаторы кода, информационная безопасность) – тогда придется разбираться в сложных процессах, завязанных на коде и железе
2. Активно анализируют логи, а в них встречаются фрагменты кода – навык поможет быстрее установить проблему и точнее поставить задачу
3. Нет документации, держатели знаний уволились – придется копаться в дебрях кода и восстанавливать доку
4. СА работает в паре с архитектором и в перспективе может вырасти до этой должности

Когда непонятно, зачем спрашивают:

1. Работодатель не понимает, кто такой СА
2. Собеседующий "просто" интересуется кругозором кандидата

🔹 На каком уровне нужно понимание?

На самом деле вы не должны быть убер-прогером. Достаточно знать:

1. Базовые механики (циклы, условия, алгоритмы)
2. Структуры данных (в идеале – как они хранятся на компьютере)
3. ООП (классы, методы)

Все это частично встречается в других артефактах СА – циклы и условия в UML Sequence, структуры данных в JSON и БД, а ООП можно увидеть в UML Class Diagram (агрегация, наследование)

🔹 А что на деле?

Я программировал в универе на Python и C++, знаю ООП – можно сказать, умею читать и писать код. И на удивление это пригодилось на моей первой работе, где не было документации, и ее пришлось восстанавливать по коду в Gitlab. Код был на Golang, но не составило труда прочитать его – если выучишь один язык, другие изучить проще 💡 В итоге я восстановил документацию по API, базе данных и архитектуре, что помогло быстро погрузиться в проект.

Также знания пригодились при обучении СА, было проще освоить БД и UML-диаграммы

Однако после этого я работаю три года СА на разных проектах, от ноунейм-компаний до крупных игроков, и нигде повторно этот навык пока не пригодился

🔹 Так нужно или не нужно знать?

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

—————

⬇ А что вы думаете на эту тему? Если умеете читать код, пригодилось ли в работе СА? Пишите в комментах

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

🟧🟧🟧🟧🟧🟧🟧🟧🟧

Для удобства подготовил навигацию по постам, разбил по темам. Всем вновь прибывшим – добро пожаловать!

🔹 О личном
– Кто я и зачем пишу
– Лучшее лекарство от стресса – спорт

🔹 Мысли и про бытовуху на работе:
– Я поругался с разработчиком и его уволили
– 2 навыка, которые помогли мне стать middl SA за 9 месяцев
– Проект провалился, я виноват?
– Нужно ли СА знать программирование? + Краткий анализ рынка
– Так ли плох аутстафф?
– Поработал на двух работах в IT и сгорел
– Почему я впервые отдохнул только в 26 лет
– Фронт раньше бэка – это вообще законно?
– Шаблоны документации – пустая трата времени или действительно полезно?

🔹 Просто о сложном:
– Просто о кэшировании
– Реплицирование vs Партиционирование vs Шардирование
– Просто о репликации
– Просто о партиционировании
– Просто о шардировании
– Паттерны микросервисной архитектуры для СА
– Как понять, что сбор требований завершен? Чек-лист для СА
– Самый важный паттерн МСА на примере неудавшегося отпуска
– Что такое Polling и причем тут Шрек

🔹 Про собеседования:
– Цвет настроения желтый: как я проходил собеседование в Т-Банк
– Как я сходил на собес в Магнит Tech
– Собес на 20 минут – red флаг при трудоустройстве?

🔹 Обзоры книг:
– System Design: как выжить на собеседовании? Обзор книги Алекса Сюя
– Прочитал книгу «Микросервисы. Паттерны разработки и рефакторинга» и делюсь мнением
– Польза и вред той самой книги Вигерса

🔹 Обзоры курсов:
– Отзыв на воркшопы System Education

🔹 Инструменты для работы:
– Как увидеть запросы в режиме онлайн? Используем Charles

Самый важный паттерн МСА на примере неудавшегося отпуска

Представь, ты собрался в отпуск – забронировал авиабилеты, отель и даже экскурсию. Ты молодец - все спланировал заранее и теперь не нужно париться🌴

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

Шаблон «Saga» (или «Повествование») – шаблон, обеспечивающий согласованность данных в микросервисной архитектуре в конечном счете. То есть, если бизнес-процесс затрагивает три сервиса, то после его выполнения данные должны быть актуальными и правильными

🔹 Локальные транзакции

В примере оформление отпуска, авиабилеты, отель и экскурсии – это локальные транзакции. Каждая завершенная локальная транзакция инициирует запуск следующей. Их последовательность образует бизнес-процесс, т.е. весь отпуск

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

Например, в Uber 🚕 нужно создать заказ, назначить водителя, запустить поездку и обработать оплату

🔹 Компенсирующие транзакции

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

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

Например, в Uber Saga координирует цепочку: принятие заказа → назначение водителя → поездка → оплата. Если водитель отменит заказ, система компенсирует изменения (вернет заказ в очередь)

🔹 Поворотные транзакции

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

В системах подобные транзакции называются поворотными. После поворотной транзакции полная компенсация невозможна (только частичная)

В примере с Uber поворотная транзакции – начало поездки. До этого момента заказ можно отменить без штрафа, после компенсация будет частичная (например, пассажир получит штраф 🤑)

🔹 Координация транзакций

Два способа координации транзакциями в системах:

1. Хореография
2. Оркестровка

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

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

📌 Кратко о важном

– Saga – шаблон для обеспечения согласованности в рамках одного бизнес-процесса
– Локальная транзакция – действия в рамках одного сервиса
– Компенсирующая транзакция – операция для отката изменений
– Поворотная транзакция – операция, после которой полный откат невозможен (только частичный)
– Два способа координации транзакция: хореография и оркестровка

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

————

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

👍 Да, гораздо
🤔 Нужно разобраться

P.S. Пока писал пост, увидел новый конкурс авторских ТГ-каналов. На этот раз от ребят из System Education, куда мой канал вписывается куда лучше, чем в предыдущем конкурсе

В этом конкурсе несколько номинаций. Думаю, этот пост отлично вписывается в «Ясное объяснение». Оставлю пометку, что участвую в конкурсе от @systems_education.

#полезное_системный_анализ
#продолжи_мысль_SE