Системный суетолог

👋Всем привет! 24-25 августа пройдет Weekend offer к нам в бизнес линию. Хорошая возможность попробовать, как минимум попробовать свои силы. Как максимум, получить оффер за выходные. 👇 Записываться тут: https://www.tbank.ru/career/fast-offers/nfs/

Проходить собеседования — это навык. Если в 2024-м вы хотите — меньше волноваться на собесах, — эффективнее отвечать на вопросы и грамотно задавать их, рекомендую канал моего хорошего знакомого про собеседования в IT, где собран опыт и кандидата, и работодателя. —————— 🔹Булат ходит на собесы из азарта и интереса и пишет, что да как: какие были этапы, какие задавали вопросы. Лонгрид раз — про интервью к поставщику и разработчику технологий для бирж Два — про интервью в финтех Три — в Medtech 🔹Булат сам нанимает сотрудников и рассказывает, почему кандидату отказали. Лонгрид раз — про закрытые ответы Два — про улыбку и болтовню Три — про кандидата, который спорил ————— ✅Подписывайтесь, чтобы быть готовыми к собеседованию, а в случае отказа — сохранять здравую самооценку. https://t.me/tryoutonadancefloor 👆

Как системному аналитику стать мидлом в бигтехе? 👨‍💻 Приходи на интенсив для системных аналитиков в Открытые школы Т1! 🎓 Открытые школы Т1 — это бесплатная карьерная программа для IТ-специалистов с опытом от года, объединяющая обучение без отрыва от работы и offer weeks. За полгода существования проекта мы выпустили 450+ специалистов, лучшие из которых получили оффер в команду Т1 — крупнейшую ИТ-компанию России по версии RAEX 2023. Участники Открытых школ Т1 присоединились к командам финтех-разработки, разработки ИТ-продуктов, облачных сервисов, развития ИИ-решений, интеграции и консалтинга. Что в программе интенсива? — Курс по работе с требованиями. — Проектирование REST API. — Понимание банковской специфики. ⌛️ Длительность: 1 месяц. 💻 Формат: онлайн по вечерам (от 8 часов в неделю на вебинары и практику). Используй уникальный шанс для быстрого роста в ИТ — подай заявку до 21 июня! Реклама. Информация о рекламодателе

👋 Давно обещала обратную связь по курсу «Проектирование архитектуры и интеграций (API/брокеры) сервисов», который я покупала еще в ноябре, но в итоге прошла только в марте. 🍀  Что мне понравилось: 1. Качественная структурированная теория. Особо хочу выделить:  ➖ прям хорошо раскрыта тема с REST API: рассказали даже про безопасность, управление кешем, бачами и чанками, ретраями итп.  ➖ тема gRPC, graphQL, SOAP, JSON-RPC, вебсокетов и вебхуков расскрыта не так глубоко, как REST, но для общего понимания 🔥   ➖  очень подробно описана концепция брокеров сообщений + много про Кафку  ➖огромный блок с базой по архитектуре для понимания основных паттернов проектирования (даже про фича-тоглы упоминается) ➖ разбор оптимизации запросов в реляционной БД + много инфы про MongoDB и Redis. 2. Очень много тестов с самопроверкой 3. Достаточно интересных задачек на проектирование. Задачки не сильно сложные, но помогают закрепить материал в голове. 4. Понравились практические задания, где нужно понастраивать ручками (нр, работа с Кафкой через Atom KTool, задания в Chrome Dev Tools,  Postman ...) 5. Темы можно проходить независимо друг от друга. 🍀  Что не очень понравилось, но в целом окей: ➖ немного смущает, что часть тем в формате видео, часть - в виде текстовых статей. Хочется единого стиля.   ➖ некоторые картинки можно было бы сделать и покачественнее / посимпатичнее. Но это я придираюсь уже, как визуал. ➖ довольно верхнеуровнево затрагивается plantUML для сиквенсов, нотация C4. Итого: Курс хороший за свою стоимость. Подойдет для того, чтобы:        ➖ подготовиться к собеседованиям (+ есть файлик с частыми вопросами на собеседованиях про API) ➖структурировать имеющиеся знания   ➖научится разбираться в интеграциях + проектировать API (в первую очередь REST) ➖научиться проектировать БД   ➖получить базовое понимание проектирования архитектуры Новичкам скорее всего будет сложновато самостоятельно проходить курс. Я бы рекомендовала брать тариф с поддержкой. 💰 Я покупала курс за 12к (без обратной связи), сейчас он стоит не сильно дороже - 14к. За такие деньги, имхо, это находка. Особенно с учетом того, что материалы доступны бессрочно. А ещё через бота курса можно получить бесплатные открытые уроки по архитектуре и интеграциям. Польза 👇 https://t.me/studyit_help_bot?start=tolog Моя скидка на курс от канала — 1 000₽ на Stepik по промокоду TOLOG до 30 апреля.

Всем привет 👋 Недавно изучала тему брокеров сообщений в облаках. Одно из самых популярное решений на рынке (не РФ) - сервисы Amazon. 🔜AWS SNS и AWS SQS - веб-сервисы от Amazon для асинхронного обмена сообщениями в распределенных системах. Логика Работы: - SNS (Simple Notification Service): Работает по модели pub / sub (сообщения публикуются в топик и доставляются всем подписчикам этого топика). Push-модель (брокер оповещает получаетелей). Имеет высокую пропускную способность. Не гарантирует последовательность доставки и отсутствие дублей. - SQS (Simple Queue Service): Работает по модели point-to-point (один отправитель - один получатель). Pull-модель (получатель опрашивает очередь). Поддерживает 2 типа очередей: -  Cтандартные: доставка хотя бы один раз, не гарантирует последовательность. Высокая пропускная способность - поддерживает практически неограниченное кол-во сообщений в сек (если верить документации). - FIFO: строго последовательная и однократная доставка. Пропускная способность - 300 сообщ / сек (можно увеличить до 3000, используя пакетную обработку). Использование: - SNS: Подходит для масштабных распределённых систем для отправки уведомлений, параллельной обработки данных, мониторинга событий итп. - SQS: Подходит для интеграции микросервисов, буферизации сообщений итп. SNS и SQS часто используют в связке. Из минусов: SQS и SNS доступны только на AWS. 🔜У Яндекса, кстати, есть собственное облачное решение, совместимое с AWS SQS: - Yandex Message Queue (Yandex.Cloud) -  сервис очередей сообщений, очень похож на AWS SQS. Но имеет ограничения в пропускной способности. Стандартная очередь ~1000 сообщ / сек. По FIFO  ~ 30 сообщ / сек. Мы даже как-то рассматривали YMQ себе на прошлый проект в качестве очереди. 🔜У Amazon также есть Amazon MQ — сервис для облегчения миграции приложений, использующих брокер ActiveMQ, в облако AWS. ➡️Подробно про брокер ActiveMQ написала Юля в своем канале Шерлок в IT. Также у Юли много постов на тему методов и инструментов в работе системного аналитика.

Привет 👋 🧑‍💻 Всем легкого рабочего дня сегодня. Хотя мне еще отдыхать 2 дня, пора потихоньку возвращаться в рабочий режим. ➡Прослушала подкаст про Observability: что это, для чего нужно и какие есть инструменты. ▶ Observability (наблюдаемость) - отслеживание и анализ поведения системы в режиме реального времени. Включает в себя логирование, сбор метрик и трассировку. ▶ Логирование - запись событий и действий в системе. 🛠Инструменты: - Grafana-стек: Promtail (сбор) + Loki (хранение) + Grafana (визуализация) - ELK- стек: Logstash (сбор) + ElasticSearch (хранение) + Kibana (визуализация) (ELK в последнее время используется реже из за ценовой политики и ресусроемкости ElasticSearch) ▶ Метрики - это числовые показатели, которые отражают состояние системы или процесса в момент времени. Нр: использование CPU и памяти, время отклика, пропускная способность… 🛠 Инструменты: - Grafana-стек: Prometheus (сбор метрик и временное хранение) + Grafana (визуализация) Для длительного хранения метрик можно использовать Grafana Mimir, Thanos - VictoriaMetrics - Zabbix ▶ Трассировка - отслеживание пути выполнения запросов в системе в разрезе разных слоев. Позволяет увидеть последовательность вызовов, время выполнения каждого запроса на каждом слое итп. 🛠 Инструменты: - Grafana-стек: Tempo (хранение) - Grafana (визуализация) - Elastic APM - Jaeger - Zipkin ▶ Для сбора трейсов обычно используют стандарт OpenTelemetry. OpenTelemetry (OTel)- это проект с открытым исходным кодом для стандартизации сбора метрик, логов и трейсов в распределенных системах. OTel представляет собой набор API и SDK для различных ЯП. Позволяет отправлять данные в различные системы мониторинга. Но с метриками, говорят, работает не очень. ▶ Существуют также APM (Application Performance Management) решения от разных вендоров для комплексного мониторинга и управления производительностью и доступностью сервисов. Нр: Dynatrace, AppDynamics, Datadog, Instana, Elastic APM, Signoz итп. Но не все они доступны в РФ. _________________________________________________ На моем прошлом проекте для решения задач Observability мы использовали: Для метрик: Prometheus + Grafana Для логов: Promtail + Loki + Grafana Дополнительно для логов и трейсов: Vector (для сбора) + OpenObserve (хранение, анализ и визуализация). 🔤А какие инструменты для Observability используются на ваших проектах?

⛄️Всем привет! Давно меня тут не было. Декабрь выдался непростым, к тому же умудрилась в последние недели заболеть. А вас тут уже 386 🔥Офигеть! Приятно. Спасибо, что читаете 😘 🥹 Сегодня был мой последний рабочий день в Магните. 🎇 Рада, что довелось поработать тут над нетипичным продуктом. Огромное спасибо моей уже ex-команде. Буду немножко скучать. 😘 Всех с наступающим Новым годом! 🎉🎆 Желаю круто отдохнуть на праздниках ⛄️⛸ Обещаю в следующем году писать побольше.

👋 Всем привет! Хочу поделиться хорошим докладом, как решать задачи по system design. Спикер очень круто на примере объясняет, что пошагово нужно делать, в какую сторону мыслить. ➡https://www.youtube.com/watch?v=Be7INI_U6GY&t=176s

👋 Всем привет! Обещала выложить свое решение по задачке, которая была на систем дизайн интервью. Если коротко, то схема получилась такая: 1⃣ Передача Геолокации курьеров Устройства курьеров отправляют геолокацию через HTTP-запросы в сервис Геолокации. Сервис геолокации записывает данные в Кафку. Из Кафки данные ассинхронно записываются в БД Геолокации и БД Мониторинга. 2⃣Отслеживание курьеров проверяющим Проверяющий выбирает область для отслеживания на карте - отправляется HTTP-запрос с 2 координатами в сервис Мониторинга курьеров (для упрощения задачи предположили, что можно выделять только прямоугольную область) Открывается вебсокет соединение для передачи на клиент данных в реалтайме. Сервис мониторинга получает из БД Геолокации координаты, принадлежащие области, и курьеров. Далее передает данные на клиент. 3⃣Просмотр истории перемещений курьера за период Проверяющий в фильтре выбирает курьера и период - отправляется HTTP-запрос в сервис Истории. Сервис Истории читает данные из БД Геолокации. 4⃣Очистка истории перемещений за год Сервис очистки запускается раз в сутки и удаляет из БД Геолокации устаревшие данные. ➕Базы Данных БД Геолокации - хранит всю историю геолокаций по курьерам за 1 год. Это реляционная БД (Postgres), тк важна консистентность. БД Мониторинга - хранит последнюю геолокацию курьера. Кмк хорошо подойдет Redis, тк он производительный и быстрый. Ключ - ИД курьера. ➕ Масштабирование - Обязательно масштабируем сервис Геолокации с учетом 3300 RPS. На вход ставим балансировщик (условно ngnix, распределять можно раунд робином) - Шардируем БД Геолокации. Ключ шардирования - по timestamp, чтобы удобно было читать историю. Нагрузку на запись БД выдержать должна, тк пишем асинхронно из Кафки. - Каждый шард реплицируем. Из минусов, которые я сейчас вижу на этой схеме: 1. Не проработана история с сохранением настроек области проверяющего. 2. Не хватает API Gateway для распределения запросов между сервисом Мониторинга и Истории. ⚡А как бы вы решали задачу? Мб есть более оптимальные решения)

👋 Всем привет! На хабре вышла моя первая статья про то, как мы описываем требования к API для бэка. Моя задача была показать на конкретных примерах, как мы пошагово оформляем требования, на что обращаем внимание. Буду рада комментариям) ❤ Спасибо моей команде и деврелу за ревью и поддержку. https://habr.com/ru/companies/magnit/articles/779368/

🤯🤯🤯 Сегодня впервые в жизни проходила интервью по систем дизайну. Нужно было спроектировать верхнеуровневую архитектуру бэкенда для системы Мониторинга курьеров по ФТ и НФТ за час: ➖ Довыявить ФТ и НФТ ➖ Посчитать примерную нагрузку ➖ Отобразить компонеты системы и как они взаимодействуют межу собой ➖ Прикинуть API контракты (что на входе и выходе) и какие протоколы можем использовать ➖ Прикинуть тип БД и модель данных ➖ Подумать над масштабированием сервисов и БД В конце еще дали доп.задачку: добавить к итоговой схеме отслеживание курьера клиентом по заказу. 🔥Мне, в целом, такой формат интервью понравился) Прикольный опыт) ❓Как бы такую задачу решали вы? Если интересно, какое решение получилось у меня в ходе интервью, ставьте реакции - сделаю пост ☺

🎆 Ура! Наконец-то в открытый доступ вышло мок собеседование на канале Антона Назарова, где я была в роли интервьюируемого. Обсуждали вопросы по требованиям, моделированию, архитектуре, интеграциям и БД. К каждому вопросу в таймкодах добавлены материалы для изучения. Не все, конечно, идеально, но все равно это был крутой опыт 💪 🔥 Отдельное спасибо Андрею за интересные вопросы и возможность проверить себя. Очень рекомендую подписаться на его канал, если вы еще не подписаны. 👀 https://www.youtube.com/watch?v=Y_R3ZLhPQfQ

День 30 🔥 Ура! 30 день моего челленджа) Хотела сегодня выложить перевод статьи по System Design чата, но не успела подготовить👨‍💻 Поэтому делюсь видео МОК собеседования backend разработчика. В видео разбираются вопросы, которые задают и системным аналитикам на собеседованиях: оптимизация БД, индексы, масштабирование БД, монолитная и микросервисная архитектура, SAGA, Event Driven архитектура итп. 👍 Мне прямо зашло) В последнее время меня тянет в сторону тех части, бизнесовая как будто уже и не так интересна 🤷‍♂ ➡ https://www.youtube.com/watch?v=QgIWHeNy8fA&t=126s

День 29 🎧Послушала на выходных подкасты Podlodka про SQL (2023) и Базы данных (2019). Из нового для себя: ➖Про ACID. Есть разные уровни изоляции (serializable, repeatable read, read committed, read uncommitted). Причем в разных СУБД уровни изоляции могут быть реализованы по разному. ➖Транзакции не страхуют от конкурентных изменений (нр, когда запущены параллельные транзакции на изменение одной записи). При редактировании данных можно устанавливать блокировки (select for update). ➖Индексы не всегда быстрые и не всегда нужно их использовать. Они работают быстро, только если если запрос выбирает маленькое количество данных в % отношении к общему. ➖Не очень хорошая идея накручивать бизнес логику в БД, используя хранимые процедуры / триггеры, тк сложно будет потом все это отлаживать и масштабировать. В 2020 году был аж холивар на эту тему после статьи от Lingualeo. ➖Стандарт SQL ISO платный 🤯 ➡https://podlodka.io/321 https://music.yandex.ru/album/7570122/track/114019398 ➡https://podlodka.io/101 https://music.yandex.ru/album/7570122/track/53118588

День 28 🌎 Сохранила себе конференции и митапы, которые мне интересно было бы посмотреть/посетить. ➡23 ноября Analytics MeetUp (Контур и red_mad_robot) Онлайн / Оффлайн Иннополис Интересно послушать про артефакты аналитика на пресейлах, тк сама в этом варилась долгое время. ➡1-2 декабря ЮМоneyDay: большая конференция про IT Онлайн Будет 1 доклад по SA. Также хочу послушать доклады разработчиков про Здоровье сервисов, Обновление микросервисов во фронте, Внедрение SSO и Кодогенерацию из OpenAPI. ➡5-6 декабря YaTalks’23 Онлайн / Оффлайн Москва Есть интересные доклады по Архитектуре: Интеграция DeliveryClub и Яндекс Еды, Три архитектуры одной покупки на Маркете... ➡Naumen Analytics MeetUp Митап был на этой неделе. Еще не смотрела, но сохранила себе доклад про Управление стрессом.

День 27 🚀 Для работы с запросами на работе обычно используем Postman и Swagger. Но частенько приходится использовать curl для тестирования запросов к внешнему сервису, с которым интегрируемся (SOAP over HTTP). Тк запросы к нему почему-то в один прекрасный день перестали работать через Postman (мы так и не разобрались, почему). 🤷‍♂️ 📌cURL (Client URL) - кроссплатформенная утилита командной строки для передачи данных с сервера на сервер при помощи различных протоколов с синтаксисом URL. Поддерживает протоколы: HTTP,  HTTPS,  FTP,  FTPS,  TFTP,  SCP,  SFTP,  Telnet,  DICT, LDAP, POP3, IMAP, SMTP. С curl можно работать в Mac, Windows, Linux через командную строку или в IDE, Git Bash. Я обычно запускаю curl запросы на Mac в терминале. Сами запросы удобно формировать в Postman: ➖Создаем запрос с указанием метода, URL, заголовков и body при необходимости ➖Копируем curl запрос из вкладки <Code> ➖Отправляем запрос из терминала и получаем ответ ➡Инструкция, как работать с curl тут: https://starkovden.github.io/curl-intro-and-instalation.html

День 26 Хорошей пятницы 😂

День 25 🚀Наконец-то решилась приобрести первый в своей жизни платный курс на степике за 5 лет в it. Решалась долго, тк привыкла всегда собирать информацию и учиться самостоятельно. Моя цель сейчас - за максимально короткое время систематизировать свои знания по проектированию интеграций (особенно gRPC, graphQL и брокеров) и микросервисов. ☺ По итогу поделюсь своими впечатлениями тут.

День 24 🤓 Вдогонку к предыдущему посту собрала варианты реализации архивации данных в реляционной БД. Архивирование данных - это процесс перемещения старых или малоиспользуемых данных из активных таблиц в специальные хранилища (архивы) с целью оптимизации производительности системы. Это может быть полезным, когда база данных содержит большой объем данных, и многие из них уже неактуальны или редко используются. 🚩Логическое архивирование - помечаем записи, которые нужно архивировать, используя специальное доп поле. Сами данные остаются в той же таблице. Часто таким же способом реализуют логическое удаление. Простой вариант для небольшого объема данных. 🚩Партиционирование - архивные записи можно перемещать и хранить в отдельных партициях таблицы. Подходит для объемных таблиц и помогает повысить производительность. Есть нюансы по работе с партициями в разных СУБД. 🚩Архивная таблица - переносим и храним архивные записи в отдельной таблице. Тоже достаточно простой вариант. 🚩Архивная схема - переносим и храним архивные данные в отдельной исторической схеме. Самый трудоемкий способ. Может подойти, если требуются различные уровни доступа к данным. ❓А вы как работаете с архивными данными?