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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⬇ Итог

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

—————

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

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

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

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

🙄 Поиск себя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—————

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

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

😁😁😁

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—————

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

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

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

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

💡 О чем книга?

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

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

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

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

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

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

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

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

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

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

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

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

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

—————

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—————

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

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

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

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

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

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

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

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

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

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

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

• По диапазону значений (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 партиционирование

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

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

—————

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

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

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

Отзыв на воркшопы 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? Какие у вас впечатления? Пишите в комментах

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

Просто о репликации

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

➡ Хозяева и рабы

📌 Пару терминов перед началом:

• Master (хозяин) – основная БД
• Slave (раб) – «подчиненная» БД, т.е. реплика. Может быть несколько для одного Master

Машины тоже добиваются отмены рабства, поэтому сейчас также используются термины Primary-Replica или Leader-Follower. Но для простоты понимания остановимся на Master-Slave

Выделяют несколько видов репликации:

• Master-Slave. Основная БД для записи данных, а реплики – для чтения (и иногда для записи). Если Master падает, Slave поднимается по карьерной лестнице и становится Master без права возврата первого😼
• Master-Master. В распределенных системах у каждого сервака свой Master: они синхронизируют записи и могут распределять нагрузку, но есть риск конфликта 👊
• Каскадная. Один раб выступает хозяином для другого. Данные реплицируются по уровням Master -> Slave -> Slave. Надежно, но долго
• Равноправная (Peer-2-Peer). Оковы сняты – каждый узел самостоятелен и может писать, читать и отправлять изменения. Но опять высок риск конфликта🙈

Где что использовать:
• Master-Slave – для систем с нагрузкой на чтение (веб-приложения, аналитика)
• Master-Master – для систем с несколькими дата-центрам (например, в разных странах)
• Каскадная – для больших систем (Wikipedia, соцсети)
• Peer-2-Peer – для распределенных систем (блокчейн)

➡ Как происходит репликация

Есть два типа взаимодействия:
• Синхронная репликация – отправляем данные на реплику и ждем подтверждения о записи ✅
• Асинхронная репликация – отправляем данные на реплику и не ждем ответа, а лукавим и говорим клиенту, что все ОК 😏

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

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

➡ Кто рассылает изменения

И еще одна небольшая классификация касается инициатора изменений:
• Мастер сам отправляет изменения репликам – это push-модель
• Реплики самостоятельно стягивают данные у мастера – это pull-модель

Push-модель подойдет для систем с высокой скоростью обновлений (банки, финансовые транзакции), pull-модель – для систем, где не требуются минимальные задержки (например, аналитика)

—————

В следующем посте поговорим про партиционирование, а затем про босса этой мини-подборки – шардирование

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

2 навыка, которые помогли мне стать middle SA за 9 месяцев

Рассказываю, как мой неочевидный жизненный опыт помог быстро освоиться в профессии СА 📣

⌨️ Копирайтинг

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

Я перепробовал многие способы заработка – тыкал по рекламе, писал отзывы, комментарии. За месяц написания отзывов я получил всего 500 рублей. Звучит как пустая трата времени, но я понял, что в интернете можно зарабатывать🤑

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

👩‍💻 Базовые навыки программирования

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

Начиная с 3 курса нас преследовало программирование, причем каждые полгода почему-то менялся язык 👨‍💻. Мой максимум до этого этапа – это школьный курс по Паскалю и проект с черепашкой. Мне было тяжело, но накостылять говнокод все же смог. На магистратуре я уже целенаправленно выбрал C++, выпускной проект был полностью на этом языке

Может показаться, что я тру прогер, но нет – в C++ я дошел максимум до ООП включительно, а указатели и списки так и не понял. Код выпускного проекта тоже лучше никому не показывать😁. Зато в профессии СА мне пригодились знания базовых алгоритмов и структур данных: знал все эти ваши стринги и варчары, умею читать код

❓ Технарь или гуманитарий?

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

💡 Но как только я узнал, что СА это грань между технарем и гуманитарием, я понял, что это мое. И о своем прошлом опыте я не жалею: неотточенные навыки заиграли новыми красками на работе в IT. И благодаря им я довольно быстро стал middle

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

—————

⬇ А какие неочевидные навыки пригодились вам в IT? Пишите в комментариях

P.s. на фото я пытаюсь работать инженером-электроником, продержался две недели 😁

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

Реплицирование vs Партиционирование vs Шардирование

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

➡ Реплицирование

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

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

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

Цель: повышение отказоустойчивости и доступности. Если потеряем одну БД, то будем уверены, что где-то есть актуальная копия🎉

➡ Партиционирование

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

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

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

📌 Пример: у нас есть табличка Users, в которой 1 млн пользователей. Если использовать один из методов партиционирования, то таблица Users разделится на две, в одной будут юзеры с id от 1 до 500 тыс, во второй от 500 тыс до 1 млн

➡ Шардирование

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

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

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

➡ Когда что использовать?

– Реплицирование — если нужны отказоустойчивость и читаемая масштабируемость. Данные на разных серверах
– Партиционирование — если таблица очень большая, но сервер один. Данные хранятся на одном сервере, но в разных разделах/партициях
– Шардирование — если данных слишком много для одного сервера. Данные лежат на разных серверах

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

—————

Этот пост не раскрывает особенности каждого из методов: в следующих расскажу о каждом отдельно

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

Как я сходил на собес в Магнит Tech

Третьи майские в самом разгаре, и в перерыве между сном и шашлыками решил рассказать про собес в Магнит Tech 🧲, где было все не так гладко, как в Т-Банке

📌 Я на тот момент:
– Ранний middle с 1 годом опыта
– Оценивал свои знания как хорошие для текущего опыта

Согласно вакансии им требовался middle с классическими функциями, такими как интеграции, БД, UML, BPMN и так далее. Выглядело вкусно. Да и компания у всех на слуху, даже в нашем доме есть Магнит – почему бы и нет? Может, получу скидки на продукты. В общем, нацелился туда.

👨‍💻 Тестовое: день впустую

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

1. Есть некая компания, нужно описать процессы AS IS и TO BE, сформулировать проблемы
2. Нарисовать ER-диаграмму для банка
3. Определить связи между 4 таблицами и написать SQL-запросы

Итог: 8 страниц текста, куча схем, один день жизни. Тогда я не заметил подвоха, но сейчас по тестовому его вижу😏. Догадаетесь, какой? Спойлер: почти все задания по бизнес-анализу

⚡️ Собеседование

Этап всего один. Я ожидал, что это будет техническое интервью один на один, но буквально за 8 минут до начала HR предупредила, что там будут «еще ребята из команды» ❓. Этими ребятами оказались дяди и тети 40+: было ощущение, что я зашел не в ту дверь

Начался собес с вопросов по бизнес-анализу по типу «Как будете готовить доклад по своему решению», «Боитесь ли выступать на публику». Ладно, это начало, думал я. Но вопросы не заканчивались. Позже я понял, что попал в классическую ловушку Джокера из мира IT для СА – собес по бизнес-анализу

Я так и не дождался ни интересных мне вопросов, ни обсуждения тестового. Вместо этого – ненавистные логические задачки по типу «Человек спускается с 16 этажа, а поднимается только на 12. Почему?». Всегда теряюсь на таких, поэтому мой ответ: «Человек ходит в любовнице на 12 этаже»😁

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

✏️ Итог

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

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

Тогда я и начал судить компанию по собеседованию. Если собес - фигня и не соответствует вакансии, то это red flag 🚩

⬇️ А вы попадали на собес на бизнес-аналитика, хотя шли на системного? Уверен, это нередкий кейс. Пишите в комменты, если тоже было

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

Я поругался с разработчиком и его уволили 😲

Расскажу про свой первый (и пока что единственный) конфликт в IT: что случилось, какие последствия и какие уроки вынес

📌Предыстория

Осенью 2023 я работал в небольшой команде на проекте со сжатыми сроками в несколько месяцев. На счету был каждый день: я прорабатывал ТЗ для фронта и бэка, а разработчики буквально дышали в затылок 👨‍💻

Среди бэкенд-разрабов было два человека. Второй, назовем его N, подключился к проекту позже, так как функциональность у него была небольшая. N еще до ссоры вызывал вопросы: работал по 10 часов в день без результата, не спешил разобраться в контексте проекта и почему-то не мог неделю получить доступ к внутренней Confluence❓. Чем ты занимаешься тогда?

👊 Что случилось?

Однажды из-за спешки я неполностью описал контракты для бэка, поэтому оставшуюся часть расписал N в личке. Он согласовал без вопросов, но все равно сделал по своему, в итоге на фронт прилетел JSON с некорректными данными ❓

Это привело к горячей перепалке на дейли на повышенных тонах: разраб ссылался на неполную документацию, я же упоминал про переписку в личке. Дошло до перехода на личности. Благо, другие ребята на дейли вовремя нас «разняли»

Дальше было веселее: оказалось, что разработчик вопросы все же имел, но оставлял их не в личке, а в... тикетах на доске задач. Никак не уведомляя о них. Мини-чат в тикетах, как вам такое? Ожидаемо, что я даже не знал об этих комментариях🤨

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

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

Позже выяснилось, что для N это далеко не первый конфликт. В ходе разбора полетов в репозитории обнаружился говнокод, а доступ к Confluence был с самого начала. Он не просто работал 10 часов без результата, а мастерски имитировал бурную деятельность😱

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

👨‍🏫 Ошибки и уроки

1⃣ Дал волю эмоциям на публичном созвоне, дошло до перехода на личности. Это неконструктивное поведение: в любом конфликте важно сохранять трезвую голову и привлекать третью сторону – это и есть решение. Позже я изучил тему конструктивной конфронтации, где был описан не только этот кейс, но и множество других. Рекомендую тоже почитать об этом на досуге

Если бы я или N написали в общий чат "Эй, давай согласуем контракты", конфликта бы не было

2⃣ Спешка. Отдавать куски доки тоже было некорректно. Стал относиться к своим артефактам более ответственно

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

➡Итог

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

——————
⬇ А были ли у вас конфликты на работе? Как решали? Делитесь в комментах

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

Так ли плох аутстафф? 🤔

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

📌 Но для начала – что такое аутстафф?

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

Это как работать на дядю в квадрате – компания-аутстафф нанимает специалиста в свой штат, а другая фирма «арендует» его себе на время. Forbes говорит, что 70% компаний из РБК-500 используют аутстафф (в основном банки)

👿 6 причин моей ненависти

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

1️⃣ В компании не было корпоративной культуры, от слова совсем. Тогда я нуждался в сообществе, обмене опытом, сильном наставнике. Коммуникация была через сообщения в Telegram. Никаких созвонов, поддержки. Меня определили на проект, и связь на этом с аутстафф-компанией почти прервалась. Смысл тогда работать на посредника?

2️⃣ Отчетность на две стороны. Каждую неделю приходилось сводить отчеты для двух компаний – это выматывало

3️⃣ Чувствуешь себя чужим в команде. У них свои тусовки, посиделки на кухне, дни рождения, корпоративы. Тебе хочется быть с этими ребятами, но из-за опасения, что завтра проект будет другой, не получается

4️⃣ Отсутствие бенефитов. Твоя команда получит премию, а ты нет

5️⃣ Непрозрачная система развития. Ни грейдов, ни системы оценки, ни вилок по зарплате. Ни-че-го

6️⃣ Неудобная система выплат. Зарплата приходила раз в месяц, и это крайне неудобно, когда у тебя съемная квартира и семья. Но это скорее исключение из правил

Чувствуя, что компания мне не помогает, я уволился через несколько месяцев 💥

📈 Что изменилось во второй компании?

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

Опасения, что предыдущий опыт повторится, не оправдались, но некоторые минусы все же остались. Что изменилось?

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

➕ Понятная система развития – при приеме твой грейд оценивают, и далее ты повышаешь его после ежегодного пересмотра. Все прозрачно.

➕ Появилось чувство собственного достоинства. Тебя ценят как специалиста, ты получаешь волну мотивации для саморазвития. Тебе не страшно подсветить проблемы на проекте, обсудить все честно с руководителем.

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

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

Идти или не идти в аутстафф?

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

Еще аутстафф подойдет начинающим специалистам, так как можно поработать на 2-3 проектах за год и довольно быстро набрать опыт

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

Просто о кэшировании 🔥

Я боялся кэширования, думал, что это сложно😱. В действительности все не так трудно, но есть нюансы. Давайте разберемся.

➡️ Что такое кэширование?

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

➡️ Для чего?

Если вещи дома под рукой, не нужно будет ехать в тот же гараж и тратить время. 💡 Основная идея кэширования – ускорение работы системы, мы получаем нужные данные быстрее, чем если бы ходили в БД. Также снижается нагрузка, а в случае отказа компонента мы все равно получим данные.

➡️ Какие данные кэшируются?

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

➡️ Где хранится кэш?

Варианты:
– Клиентский кэш (браузер, мобильное приложение)
– Серверный кэш (in-memory cache, Redis)
– Распределенный кэш (CDN)

Если говорить про сервер, то различают внутреннее и внешнее кэширование:

➡Внутреннее (in memory) кэширование происходит внутри сервиса (внутри его оперативной памяти, хеш-таблице). ➕ Высокая скорость обращения за счет того, что не нужно выполнять запросы к чему-то извне, но ⚠ при горизонтальном масштабировании (создании копий сервиса) требуется синхронизация

➡Внешнее кэширование происходит на стороне (например, в Redis).⚠Работает медленнее внутреннего, зато можно хранить большие объемы данных, легче масштабировать➕

Чаще всего используют внешнее кэширование, если нет требования к скорости работы

❓ Что это за буквы?

– TTL (Time To Live)⏱ – время жизни кэша в секундах
– Cache miss – промах кэша, запрошенный ключ не был найден
– Cache hit – попадание в кэш, запрошенный ключ найден
– Hit ratio – процент попаданий запросов в кэш, характеризует эффективность кэширования
– Горячий ключ🔥 – ключ, на который приходится большая часть запросов
– Прогрев кэша – процесс наполнения кэша данными
– Инвалидация🗑 – удаление кэшированных данных

➡️ Как работает?

Смотрите картинки к посту

– Cache Aside (кэширование на стороне) – сервис координирует запросы в кэш и БД и сам решает, куда и в какой момент обращаться. Достоинство➕: простота, минимум рисков
– Cache Through (сквозное кэширование) – все запросы от приложения проходят через кэш. По сути сервис не знает о БД, вместо этого он обращается только в кэш. Достоинство➕: консистентность данных
– Cache Ahead (опережающее кэширование) – кэш сам периодически подгружает данные из БД через воркер. Если сервис не обнаруживает данные в кэше, он говорит, что их нет. Достоинство➕: нет Cache Miss

➡️ Вывод
Кэширование – мощный инструмент для ускорения работы сервера, но его реализация зависит от требований. Большинство систем обходятся внешним кэшированием с использованием Cache Aside, а кэшируются только редко изменяемые данные.

——————

⬇А у вас на проекте используется кэширование? Если да, то как реализовано? Делитесь своим опытом в комментариях

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