Итоги года 🎄

Ребята, привет!

В последний рабочий день подводим итоги года. Я никогда не планировал, но в ретроспективе всегда видится, что время потрачено не зря. Большое спасибо всем, кто был рядом и помогал.

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

В феврале начался ремонт. Ремонт…. Сложная штука, приходилось постоянно менеджерить. Крайне нервно, но результат стоил того. Отдельное спасибо родителям за постоянную помощь, без них бы ничего не вышло.

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

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

В июле повысил зп на текущем месте работы через контроффер. Поступил некрасиво, думал, что 100к на ровном месте не накинут. А оказалось, наоборот. Но, задачи на проекте интереснее не стали.

В августе запустил канал, где вы сейчас находитесь. Огромное спасибо всем, кто подписался и читает. Спасибо за реакции и комментарии, спасибо, что участвуете в дискуссиях. Канал и медийка в целом приносят большое удовольствие (и немножко денег), буду продолжать этим заниматься. А еще в августе мы переехали в свою квартиру, там был стол, кровать и ванная. Без мебели и кухни. Сейчас вспоминаем с улыбкой, но тогда было невесело.

В сентябре закончили ремонт. 80% изначального дизайна было реализовано. Остались мелкие доделки, но в целом картина полная. Также в первый раз за пару лет выбрались отдохнуть, я вообще впервые был в Египте, до этого только «наш юг». Шарм с трудом переживает кризисы и выглядит уставшим, но море, солнце, все дела – решает.

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

Как-то так. Сейчас ухожу на зимние каникулы, вернусь уже в январе. Меня можно найти в коммьюнити. Еще раз спасибо всем, кто подписан, вы даете топливо для дальнейшего движения. Пусть в новом году у вас сбудется все, что пожелаете. Добивайтесь карьерных успехов, но не забывайте отдыхать и беречь голову.

Всех обнял,
Андрей

З.Ы. (сейчас олды пустят слезу) Когда-то давно вел канал с рецензиями о кино. Если вдруг соскучитесь, здесь очень много материала, несвязанного с ИТ. Кто знает, может вернусь)

Как состояние позле праздничков? Готовы побеждать? (я еще нет)

@notsystemanalysis

6 архитектурных паттернов, которые ты должен знать

Event-Driven Architecture:
EDA фокусируется на производстве, обнаружении, потреблении и реакции на события. Компоненты в этой архитектуре взаимодействуют асинхронно через события. Когда происходит событие, оно запускает действия или уведомления по всей системе. Этот паттерн повышает масштабируемость, разделяет компоненты и позволяет реагировать на события в режиме реального времени.
Применение: Идеально подходит для систем, в которых события вызывают действия, способствуя масштабируемости и быстроте реакции.

Layered Architecture:
Многослойная архитектура организует систему на логические уровни, каждый из которых отвечает за определенную функциональность. Как правило, эти слои включают в себя представление, логику приложения, бизнес-правила и доступ к данным. Такое разделение обеспечивает модульность, способствует удобству обслуживания и упрощает обновление или изменение отдельных слоев, не затрагивая другие.
Применение: Распространена в корпоративных приложениях, повышает отказоустойчивость за счет разделения и модульной разработки.

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

Microservices Architecture:
Микросервисы разбивают приложение на более мелкие, независимые сервисы, каждый из которых отвечает за определенные функции. Эти сервисы взаимодействуют через API и могут разрабатываться, развертываться и масштабироваться независимо друг от друга. Микросервисы способствуют гибкости, масштабируемости и позволяют командам одновременно работать над разными сервисами.
Применение: Идеально подходит для больших и сложных систем, улучшая масштабируемость, изоляцию от сбоев и позволяя разрабатывать независимые сервисы.

Model-View-Controller (MVC):
MVC разделяет приложение на три взаимосвязанных компонента: Модель (представление данных), Вид (пользовательский интерфейс) и Контроллер (бизнес-логика). Этот паттерн повышает удобство сопровождения, позволяет вести параллельную разработку и способствует четкому разделению задач.
Приложение: Распространена в веб-приложениях, улучшает организацию и сопровождение кода за счет разделения сложной логики пользовательского интерфейса.

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

Графический материал прикрепил в комментариях.
Какие недостатки того или инного паттерна можете назвать?

Сравнение архитектурных паттернов

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

Давайте сравним описанные паттерны по нескольким критериям: Масштабируемость, Удобство обслуживания, Гибкость, Сложность.

Масштабируемость:
EDA: Высокая масштабируемость благодаря своей асинхронной природе. Может обрабатывать большое количество событий одновременно.
Layered Architecture: Масштабируемость может быть ограничена, так как масштабирование отдельных слоев может быть затруднено независимо друг от друга.
Monolithic Architecture: Масштабирование может быть сложным, так как необходимо реплицировать все приложение.
Microservices Architecture: Обеспечивает отличную масштабируемость за счет независимого масштабирования сервисов в зависимости от спроса.
Master-Slave Architecture: Масштабируемость зависит от распределения задач между ведомыми и возможностей ведущего узла.

Удобство обслуживания:
EDA: Разрозненные компоненты облегчают обслуживание и обновление конкретных функций.
Layered Architecture: Способствует удобству обслуживания за счет разделения проблем, но может создавать зависимости между слоями.
Monolithic Architecture: Может быть сложной в обслуживании, так как изменения могут повлиять на всю систему.
Microservices Architecture: Легче поддерживать благодаря независимым сервисам, но управление несколькими сервисами требует эффективной координации.
Master-Slave Architecture: Сопровождение проще, поскольку каждый ведомый может управляться независимо, но работоспособность всей системы зависит от ведущего.

Гибкость:
EDA: Очень гибкая благодаря своей слабосвязанной природе, позволяющей легко добавлять или изменять компоненты.
Layered Architecture: Обеспечивает умеренную гибкость, но для определенных модификаций может потребовать изменения нескольких слоев.
Monolithic Architecture: Менее гибкая, поскольку изменения могут повлиять на всю систему.
Microservices Architecture: Обеспечивает высокую гибкость, поскольку отдельные сервисы могут быть изменены, обновлены или заменены, не затрагивая другие.
Master-Slave Architecture: Гибкость ограничена структурой, в которой ведомые зависят от указаний ведущего.

Сложность:
EDA: Умеренно сложная из-за управления асинхронными событиями и обеспечения согласованности событий.
Layered Architecture: Умеренная сложность, но может стать сложной, если плохо управлять зависимостями между слоями.
Monolithic Architecture: Проще в разработке на начальном этапе, но может стать сложной в управлении и масштабировании по мере роста.
Microservices Architecture: Может быть сложной в настройке и управлении из-за распределенной природы и межсервисного взаимодействия.
Master-Slave Architecture: Умеренная сложность в управлении отношениями "ведущий-ведомый" и обеспечении синхронизации.

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

С добрым утром!

@notsystemanalysis

Как вы попали в професию

Ребята, салют!
Давайте немного пообщаемся. Очень интересно, чтобы вы рассказали:

1) Почему выбрали бизнес/системный анализ?
2) Какие плюсы/минусы видите?
3) Куда думаете развиваться дальше?

Начну с себя:

1) Обучался в ВУЗе, верхнеуровнево объяснили, чем занимаются аналитики - понравилось. Плюс спрашивал у знакомых, которые рассказывали, что тут много "творческой работы". В процесс доучился из бизнес аналитика в системного
2) Плюсы: платят, как разрабам; востребовано в РФ; в процессе качаешь скиллы архитектора; относительно низкий порог входа;
Минусы: много коммуникации с людьми (для кого-то может быть плюсом); не востребовано вне РФ; от компании к компании обязанности сильно разнятся
3) Для себя вижу путь архитектора. Хочется больше качаться в технических задачах, чем в бизнесовых.

Сравнение Kafka и RabbitMQ

RabbitMQ

- Обзор: RabbitMQ, надежный и проверенный брокер сообщений, работает на основе протокола Advanced Message Queuing Protocol (AMQP). Уделяя особое внимание гибкости и простоте использования, RabbitMQ хорошо подходит для сценариев, требующих связи в реальном времени, распределения задач и архитектуры, ориентированной на события.

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

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

Kafka

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

- Сильные стороны: постоянное и отказоустойчивое хранение данных, эффективная обработка потоков.

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

Сравнение:

- Масштабируемость: Распределенная архитектура Kafka делает ее горизонтально масштабируемой, что позволяет легко справляться с растущими объемами данных. RabbitMQ, хотя и масштабируется, может потребовать дополнительных конфигураций для оптимального масштабирования.

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

- Шаблоны обмена сообщениями: RabbitMQ поддерживает различные схемы обмена сообщениями, включая pub-sub и request-reply. Kafka, ориентированная на потоковую передачу событий, лучше справляется со сценариями, по принципу pub-sub, а также логгированию.

Ну а что, ведь только понедельник...

@notsystemanalysis

4 года в ИТ, что я понял за это время

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

ИТ – наиболее простой путь к заработку и обретению финансовой независимости. Это правда, за пару лет можно кратно увеличить зп и позволять себе больше, чем ты мог даже подумать. За 4 года мой доход с работы вырос в 10 раз! Покажите мне еще сферу, где такое возможно.

Работники в ИТ подвержены «выгоранию». Это работа с высокой нагрузкой на психику. Ты постоянно думаешь головой, решаешь задачи, развиваешься и впихиваешь в себя новое. Диссонанс случается, когда оказывается, что в рабочих процессах нужно 10% от того, что ты знаешь. А ключ к повышению дохода – это не объем знаний, а умение грамотно себя продать. Из-за того, что первичные потребности закрыты, возникают вопросы: «А что делать дальше?» Когда ты всю жизнь видел, как старшие жили и постоянно копили: на ремонт, на новую квартиру, на отдых, а ты можешь закрыть эти потребности не напрягаясь. Круто? Безусловно. Но вот представь, ты сделал ремонт, купил себе новые девайсы, заказал доставку и клининг. А что дальше?

Системный анализ – одна из востребованных и оплачиваемых специальностей в РФ на данный момент. Аналитиков не хватает, компании постоянно пишут, а для новичков проводятся стажировки. Порог входа здесь не такой высокий, как в программировании, а уровень зп соразмерен. Работая аналитиком, ты не только углубляешься в ИТ, но и изучаешь бизнес. Плюс, получаешь компетенции архитектора, которые пригодятся в дальнейшем.

С другой стороны, обязанности аналитика могут сильно разниться от компании к компании. Где-то ты можешь только писать требования, а где-то подрабатывать РП на пол ставки. Плюсом, легко поймать «синдром фронтендера», когда кажется, что у других специальностей работа важнее. Ведь ты не пишешь код. Хватаешь немного от бизнеса, немного от разработчиков, пишешь спеку и не факт, что будет сделано так, как описал ты. А эти бесконечные звонки и встречи….

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

Но боевые задачи не всегда удовлетворяют желаниям. Круто, когда твоя работа приносит пользу бизнесу. Когда фичи доезжают в прод. Но часто бывает, что ты несколько месяцев работаешь: собираешь требования, пишешь документацию, а в итоге задача не доезжает в прод. Либо доезжает, но функционалом никто не пользуется. Просто так получилось, ты не виноват, поменялись приоритеты. Осознание работы в стол – удручает.

Что вы думаете по теме? Какие откровения открылись, спустя некоторое время?

Всем удаленщикам привет)

@notsystemanalysis

Притеснение в ИТ

Ребята, салют!
Предлагаю немного пообщаться.

На одной из консультаций меня спросили: «Встречается ли в ИТ эйджизм?»

Я замешкался, ведь лично не встречался ни с какими притеснениями. Ко мне всегда относились с уважением, как и я к другим. С одной стороны, в ИТ высокая корпоративная культура, все понимают серьезность и ответственность профессии. Но с другой, если бы все складывалось гладко, то историй, вроде этой или этой не было бы.

А как у вас? Приходилось ли сталкиваться с любыми видами ущемлений (сексизм, эйджизм, расизм и т.д.)? Как боролись с этим? Какие выводы сделали для себя?

Как работает Single Sign-On (SSO)?

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

Как работает SSO
1. Аутентификация: Пользователи входят в систему один раз, используя свои учетные данные.
2. Выдача токена: После успешной аутентификации генерируется токен.
3. Проверка токена: Токен проверяется участвующими приложениями для последующего доступа.

Плюсы SSO
1. Удобство: Пользователи получают доступ к нескольким приложениям с помощью одного логина, что избавляет их от необходимости запоминать несколько паролей.
2. Безопасность: Централизованная аутентификация улучшает контроль, видимость и соблюдение политик безопасности.
3. Производительность: Упорядоченный доступ повышает эффективность и сокращает время, затрачиваемое на процессы аутентификации.

Типы SSO
Корпоративный SSO (ESSO): Доступ к приложениям в корпоративной сети.
Web SSO: доступ к веб-приложениям с использованием единого логина.

SSO протоколы
1. SAML (Security Assertion Markup Language): Стандарт на основе XML для обмена данными аутентификации и авторизации.
2. OAuth (Open Authorization): Протокол для безопасного, делегированного доступа к ресурсам.
3. OpenID Connect: Уровень идентификации поверх OAuth 2.0, облегчающий аутентификацию пользователей.

Примеры SSO
1) Google Sign-In
2) Apple SSO
3) VK SSO

Подробнее

Документация как код

На прошлой работе внедрили офигенную практику – вести документацию как код (docs as a code). Перед нами стояла задача перетащить всю доку из Confluence в Git, сделав удобно всем. Спойлер, получилось не совсем гладко, но давайте по порядку.

Я работал в команде интеграций на бэке. Мы пилили интеграционные адаптеры с различными банками и МФО. Процесс выглядел так: адаптер слушает определенную очередь, получает сообщение, преобразовывает его и отправляет вовне. В рамках адаптера содержится несколько методов, от одного до нескольких десятков. Это чисто техническая история, мы не взаимодействовали с фронтом и не описывали его.

Ситуация “As-Is”. Под каждый адаптер есть статья в Confluence, где пошагово расписан процесс: какую очередь слушаем, куда отправляем результат, в какую очередь складываем ответ, пример/описание входящего/исходящего сообщения, и другая техническая информация. Если методов было много, то прикладывали ссылку на draw.io с Sequence Diagram.

Что же получилось? Для текстового описания выбрали AsciiDoc. У него понятный синтаксис, а главное, он корректно отображается в Confluence. Для того, чтобы не делать двойную работу, вся документация велась в Git, а в Confluence указывались ссылки на репозитории.

Помимо AsciiDoc стали использовать PlantUML. Он сильно ускорил процесс «отрисовки» диаграмм, ведь теперь аналитик работает с текстом, а графическое расположение формируется автоматически. Плюс, для каждого метода стали моделировать Class Diagram. В перспективе из них разработчики могли бы генерировать классы.

Наконец, шлифанули это все OpenAPI. Ранее аналитик прописывал параметры и ограничения запроса, а разработчик дублировал эту работу в коде. OpenAPI позволял делать это один раз – аналитик формирует спеку, а разработчик из нее генерирует код. Искренне не понимаю, почему всю доку API не делают именно в формате OpenAPI, ведь это наглядный и понятный стандарт.

В идеальной картине мы видели следующие плюсы:

- Всегда актуальная документация. Ведь она изменяется только вместе с кодом.
- Ускоренная разработка. Ведь часть работы уже выполнил аналитик.
- Прокаченные аналитики. Ведь им нужно освоить несколько новых инструментов.

Реальность оказалось суровее. После ухода тимлида (мощнейший эксперт, безумно рад, что нам удалось поработать вместе) инициативу стало почти невозможно толкать. В работе использовалось только Ascii описание, а Puml и Swagger никто не использовал. Соседние команды смотрели на нас как на сумасшедших – «ведь аналитикам придется делать столько дополнительной работы». А бизнес говнялся, ведь им было неудобно смотреть рендеринг репозиториев Git в Confluence.

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

А как обстоят дела с докой на работе у вас?

Начальники, не делайте так…

@notsystemanalysis

Документация как код. Инструменты

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

Давайте подробнее об инструментах, что нужно использовать, чтобы реализовать подход Docs as a Code.

0) У аналитиков должен быть доступ к коду. Очевидный и главный пункт. Если ИБ считает, что код вам видеть не положено, то дальнейший текст не имеет смысла.

1) IDE. Подойдет любая, но мы работали с продуктами JetBrains. Выбирайте ту, в которой пишут разрабы. Кстати, недавно зарелизилась IDE для документации – Writeside. На боевых проектах не пробовал, но выглядит интересно.

2) Описание. Дальнейшие шаги завязаны на расширениях для IDE, поскольку не все поддерживается из коробки. Мы использовали AsciiDoc для текстового описания. Конкретно этот плагин. Также прикладываю синтаксис. В качестве аналога можно использовать Markdown. Он работает без дополнительных расширений.

3) Диаграммы. Использовали PlantUML. Расширение доступно здесь. Синтаксис можно изучить тут. В качестве альтернативы рассмотрите возможность использования Mermaid.

4) API. Для описания апишек использовали формат OpenAPI. Он также поддерживается без дополнительных расширений. Но для удобства использовал плагин позволяющий быстро перемещаться по разделам. Уроков по использования Swagger очень много, вот один из них.

Как это работало? При написании документации аналитик создавал ветку, где добавлял папку “docs” в корень репозитория, в ней хранились необходимые файлы с расширениями .adoc, .puml и .yaml соответственно. Как только описание было завершено, разработчик начинал писать код в той же ветке. Наконец, дока и код одновременно сливались в мастер.

Стало ли понятнее? Остались ли вопросы? Пишите в комментариях.

Синдром хорошего парня или как избыток эмпатии может навредить

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

«Синдром хорошего парня» или желание понравиться всем сильно вредит в повседневной жизни и на работе. Нет ничего страшного в том, чтобы отказывать людям. Предлагают поработать дополнительно, без оплаты? Нет, спасибо. Выдвигают на новую должность с повышенной нагрузкой, ведь в перспективе можно будет вырасти в зп? Думаю, что откажусь. Никто не посмотрит косо, если вы хотите делать только то, на что договорились, а в свободное время отдыхать. Вы не обязаны подскакивать от каждого уведомления и судорожно бежать делать задачу. Вспомните коллег, которые отвечают вам в течение дня, а не в течение часа. Разве их кто-то упрекает в том, что они недоступны в режиме онлайн?

Плюс на работе всегда встречаются мудаки. Коллеги, которые могут и не хамить напрямую, но отвечать с высока и упрекать вас в некомпетентности. На первом месте был разработчик, который постоянно косячил и не хотел читать ТЗ. Он звонил и говорил: «Я тут ничего не понимаю, и делать ничего не буду». На другой, аналитик из соседней команды отвечал на мои вопросы: «Это же ваша задача, вот и делайте как знаете». Единственно верный выход из ситуации – эскалация. Но не в духе: «Он меня обидел», а с посылом: «Я пытался наладить коммуникацию, но коллега закрыт. Это мешает достижению результата». Крайний случай, не нужно доводить до такого, но подумайте, раз их никто не уволил, почему же вы должны всем нравиться? Плюс, вы ценный и крутой специалист, разве может рандомный человек, мнение которого вас не интересует, пошатнуть ваши компетенции?

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

Карта компетенций бизнес/системного аналитика

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

Это мастхэв и минимум, который ждут на собеседованиях.

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

@notsystemanalysis