Системный анализ на максималках
394 subscribers
37 photos
23 links
Senior System Analyst в UmbrellaIT

Делюсь опытом и стремлюсь достичь позиции Solution Architect.

Рассказываю о прочитанных книгах, пройденных курсах, о собеседованиях и о разных темах СА.

Для связи @bening_cloth
加入频道
This media is not supported in your browser
VIEW IN TELEGRAM
Привет, рад видеть на моем канале!🖖

Кто я?

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

Зачем создал канал?

Моя цель – погрязнуть в технологиях и вырасти до Solution Architect👨‍🚀.

И че тут будет?

На канале рассказываю о своем непростом, но дико увлекательном пути к этой цели:
➡️ Делюсь мнением о пройденных курсах – и нет, не Skillbox
➡️ Рассказываю о прочитанных книжках – да, умею читать
➡️ Рассуждаю на разные темы системного анализа – без банальности
➡️ Делюсь чем-то новым для себя – например, накануне этого поста столкнулся с кэшированием, и оно победило
➡️ Отзываюсь о собесах в различные компании

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

Если ты СА с опытом и планируешь развиваться дальше, начинающий СА или хочешь попасть в IT – Welcome!
9🙈1
📖 System Design: как выжить на собеседовании? Обзор книги Алекса Сюя

О чем книга?

Аналитик при подготовке к грейду Senior наверняка столкнется с System Design на собесе. Это стрессовое проектирование какой-либо системы прямо на интервью онлайн без регистрации и смс🔞. Однако задание многое говорит о кандидате, его hard и soft skills, а также умении принимать решения.

Автор разбирает по косточкам Google, YouTube, WhatsApp – и дает пошаговый метод проектирования подобных систем на собесе.

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

Просто и коротко. 300 страниц с картинками можно осилить за 2-3 вечера.
Фокус на архитектуру. Учимся думать не только про функции, но и про прозводительность, масштабируемость (что, если пользователей станет 1 млн?)
Проектирование популярных систем. YouTube пока спроектировать не готов, но понимаю, что под капотом

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

Не все системы удастся понять. Я работал с мессенджерами и системой уведомлений, поэтому книга дополнила мои знания. А вот хранилище типа «ключ-значение» и согласованное хэширование остались темным лесом🤷‍♂️
Местами не хватает деталей и цифр. Хотелось бы больше конкретики

Кому бы порекомендовал?

Системным аналитикам (да и не только) уровня middle и middle+, у которых за плечами хотя бы несколько проектов. Для расширения кругозора или, внезапно, для подготовки к интервью по System Design.

Общее впечатление

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

А вы проходили интервью по System Design? Оставляйте комментарии о своем опыте, а я в будущих постах я расскажу о своем

#книги_системный_анализ
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥72👍21
This media is not supported in your browser
VIEW IN TELEGRAM
🟡 Цвет настроения желтый: как я проходил собеседование в Т-Банк

Эйчары Т-Банка писали мне чаще, чем отец – даже с закрытым резюме🗽. Решил залететь на Weekend Offer: все этапы за один день -> в итоге оффер или отказ

📌 Мой бэкграунд на тот момент:
– Middle SA с 2 годами опыта
– Знания далеко не блестящие – не знал про архитектуру, паттерны проектирования, GraphQL, и прочие фетиши СА

😑Подготовка к собесу

Ее не было, но у них крутой лендинг по подготовке: есть не только банальные советы по-типу наденьте рубашку перед созвоном, но и список литературы и статей, а также подробности по каждой секции. Это реально круто

🤸Что было на собесе

Тут аж три этапа: общение с HR, теория и практика

Для кого-то это круги ада, но по мне классическая модель, в которой нет ничего отталкивающего


1⃣ Звонок с HR обычный – знакомство, технический скрининг. HR довольно вежливая, тактичная, взаимодействие понравилось

2⃣ Второй этап проходил один на один с техническим специалистом, который довольно плотно спрашивает по теории с щепоткой практики. Блоки классические – Требования, Интеграции, Базы данных, Архитектура

Сквозного примера не было, а весь этап был похож на экзамен – вероятно из-за специфики мероприятия и загрузки ребят. На Weekend Offer ты как на слепом дейтинге: собеседующий словно переходит от одного стола к другому😁

Единственное, на чем я запнулся – это практика по SQL-запросам🔥. Спрашивают везде, а по факту ни на одной работе я не писал даже банального SELECT *


3⃣На третий этап пропустят, если прошел второй, а фидбек я получил уже спустя 15 минут. Вероятно, собеседующими я был оценен как Senior, поэтому на третьем этапе меня ждал босс в виде System Design🤯 с уже другим специалистом

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

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

На этом Weekend Offer был закончен

4⃣ Итог

Я был уверен, что завалил второй этап, но HR вернулась с положительным фидбеком


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

Несмотря на это, я отклонил оффер, так как не планировал уходить со своей компании. Однако собес в Т-Банк мне понравился

🛑 Но это еще не все...

Интересно, что спустя время моя супруга проходила собес туда же, но уже не в рамках Weekend Offer. И ее опыт был полной противоположностью моему: HR взаимодействовал довольно вяло, на самом собесе половина вопросов с системного анализа (а она тестировщица), а с обратной связью так и не пришли, прикрывшись «мы еще ищем тебе проект»

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

📌 Выводы и советы
✔️ Weekend Offer – эффективно, но хаотично.
✔️ Готовьте SQL и System Design – спрашивают даже у Middle.
✔️ Не повезет с HR и собеседующим – будет испорчен весь опыт.

——————

А есть ли у вас опыт прохождения собесов в Т-Банк? Делитесь им в комментариях, будет интересно почитать

#собеседования_системный_анализ
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍61👀1
Просто о кэшировании 🔥

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

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

🏠 Представьте кладовку в доме, где мы храним часто используемые вещи. Мы не везем их в гараж за тридевять земель, потому что эти вещи должны быть под рукой. В 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, а кэшируются только редко изменяемые данные.

——————

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

#полезное_системный_анализ
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥133💯1