ЧТО ДОЛЖЕН ЗНАТЬ АНАЛИТИК ПО SYSTEM DESIGN. АРХИТЕКТУРА ДЛЯ АНАЛИТИКА
🔖Архитектура для аналитика: https://systemanalyst.life/architectu...
📢 Telegram-канал для системных аналитиков — https://t.me/+R3LmOt7qEXYyYzIy
На вебинаре мы разобрали ключевые этапы проектирования системной архитектуры, которые необходимы системному аналитику на практике и при прохождении собеседований Таймкоды: 00:00 - Введение в тему вебинара 05:00 - Определение дизайна 06:16 - Этапы дизайна • Сбор требований: функциональные и нефункциональные. • Расчёт нагрузки и отказоустойчивости. • Разработка высокоуровневой и детальной архитектуры. • Мониторинг и безопасность. 08:14 - Сбор требований • Вопросы для сбора требований: пользователи, сценарии использования, количество пользователей, ожидаемое наращивание мощностей, требования к скорости и отказоустойчивости, ограничения. • Примеры вопросов для собеседований: проектирование приложений Netflix, Booking, Telegram, Яндекс.Доставка. 10:07 - Пример вопросов на собеседовании 11:41 - Функциональные и нефункциональные требования • Функциональные требования ФТ: что должна делать система. • Нефункциональные требования НФТ: как должна вести себя система. 13:06 - Примеры функциональных требований • Для клиента: просмотр каталога товаров, поиск товара, добавление в корзину, оплата, оформление доставки. • Для курьера: начало и завершение смены, приём заказа, отслеживание доставки. 16:05 - Нефункциональные требования • Производительность: скорость и объём обработки данных. • Масштабируемость: способность системы справляться с большой нагрузкой. • Доступность: возможность доступа к системе 24/7. • Устойчивость: реакция системы на сбои. • Надёжность: сохранение данных при сбоях. • Безопасность: защита данных пользователей. • Отзывчивость: обновление данных в реальном времени. • Консистентность: одинаковые данные на разных устройствах. 22:48 - Расчёт нагрузки и устойчивости • Расчёт нагрузки: количество пользователей, пиковые нагрузки, рост пользователей. • Расчёт устойчивости: время восстановления после сбоев. • Расчёт хранения данных: объём данных, необходимых для хранения. 23:46 - Расчёт запросов в секунду • Оценка количества запросов в секунду. • Расчёт объёма данных для хранения запросов. 24:46 - Расчёт DAU и RPC • DAU — это количество пользователей, которые заходят на сайт ежедневно. • RPC — это количество запросов в секунду. • Формула для расчёта RPC: DAU × среднее количество запросов от одного пользователя в день / 86400. 28:50 - Разработка высокоуровневой архитектуры • Хай-левел дизайн — это этап проектирования программного обеспечения после определения требований. • На этом этапе проектируются основные компоненты системы и взаимодействие между ними. • Пример для интернет-магазина: сервисы карточек товаров, профиля, корзины, заказов, внешние сервисы платёжные системы, доставка. 31:20 - Различие между сервисом и микросервисом • Сервис имеет больше логики и может быть более крупным. • Микросервис — это независимая единица с собственной базой данных и принципами эволюционного дизайна. • Деление на микросервисы может быть по бизнес-возможностям или доменам. 34:59 - Разработка детального дизайна компонентов • Включает фронты, базы данных, балансировщики, API Gateway, S3, очереди и кэш. • Фронты представляют пользователей, базы данных — данные, балансировщики — распределение нагрузки, API Gateway — единую точку входа для клиента. • S3 используется для хранения файлов, очереди — для асинхронных связей и обработки пиковых нагрузок. 37:49 - Примеры дизайна • Примеры дизайна можно найти, введя название системы в поисковике. • Архитектура может быть представлена по-разному, но основные элементы всегда присутствуют: фронты, базы данных, балансировщики, API Gateway, S3, очереди. 40:03 - Ошибки в архитектуре • Недописанные нефункциональные требования, например, «система должна быть консистентной» без уточнения, какие данные и с чем должны быть консистентными. • Несоответствие между требованиями и архитектурой, например, добавление сервиса стриминга фильмов без упоминания в требованиях. • Некорректные соединения между сервисами, например, последовательное выполнение действий «товар — корзина — заказы — доставка — оплата». • Повисшие сервисы, которые не связаны с пользователями, например, админ-сервис новостей. 43:10 - Роль аналитика и архитектора • Аналитик собирает требования и пишет TNT, архитектор отвечает за архитектуру, микросервисы и их соединение. • Архитектор имеет окончательное слово в выборе архитектуры и интеграции. 48:25 - Собеседования и задачи на работе • Собеседования помогают получить обратную связь и улучшить навыки. • Задачи на работе, такие как рисование архитектуры, способствуют профессиональному росту. • Важно получать поддержку от руководства для выполнения задач. 01:04:54 - Вопросы и ответы • Для прохождения курса не обязательно знать веб-сокеты, но полезно уметь проектировать REST API. • Обучение начинается с понедельника, воркшопы записываются.
