¶ Блок 1 "Техническая база в IT-проектах"
¶ Технологический стек: что это и зачем он нужен
Технологический стек — это набор инструментов, с помощью которых команда создаёт и поддерживает продукт.
В него входят:
-
языки программирования,
-
фреймворки и библиотеки,
-
базы данных,
-
инструменты сборки, тестирования и деплоя,
-
инфраструктурные решения.
Когда на собеседовании спрашивают:
«Какой стек был на проекте?»
от тебя ждут не списка слов, а понимания:
-
почему выбран именно этот стек,
-
какие задачи он решал,
-
с какими ограничениями и проблемами команда столкнулась.
¶ Примеры технологических стеков
¶ Пример стека для frontend
Типичный стек современного веб-фронтенда может выглядеть так:
-
Язык: TypeScript
-
Фреймворк: React / Next.js
-
Стили: CSS Modules / Tailwind / SCSS
-
Сборка: Vite / Webpack
-
Работа с API: REST / GraphQL
-
Тестирование: Jest, Playwright
Такой стек выбирают, когда:
-
нужен интерактивный интерфейс,
-
важна скорость разработки,
-
проект предполагает дальнейшее масштабирование.
¶ Пример стека для backend
Один из распространённых вариантов:
-
Язык: Python
-
Фреймворк: Django / FastAPI
-
База данных: PostgreSQL
-
Кэш: Redis
-
Очереди: RabbitMQ / Kafka
-
API: REST
-
Аутентификация: JWT / OAuth
Такой стек подходит, если:
-
важна надёжность,
-
много бизнес-логики,
-
есть интеграции с внешними сервисами.
¶ Как выбирают стек
Выбор стека — это компромисс, а не поиск «самой модной технологии». Обычно учитывают:
-
требования продукта,
-
опыт команды,
-
бюджет и сроки,
-
требования к масштабируемости,
-
ограничения заказчика или инфраструктуры.
¶ Базы данных и СУБД
¶ Зачем вообще нужны базы данных в проектах
Любой цифровой продукт работает с данными:
пользователи, заказы, платежи, настройки, логи, статусы, история действий.
База данных — это не просто «хранилище», а ключевая часть продукта, от которой зависят:
-
скорость работы системы,
-
стабильность под нагрузкой,
-
безопасность данных,
-
возможность масштабирования.
Ошибки на уровне работы с данными — одни из самых дорогих:
их сложно исправлять и они часто проявляются уже в продакшене.
¶ База данных и СУБД — в чём разница
Эти термины часто путают, но для понимания архитектуры проекта разница важна.
-
База данных (БД) — это сами данные: записи, таблицы, документы.
-
Система управления базами данных (СУБД) — это программное обеспечение, которое:
-
хранит данные,
-
позволяет их читать и изменять,
-
следит за целостностью,
-
управляет доступом и безопасностью.
-
Пример:
-
PostgreSQL — СУБД
-
Таблицы с пользователями и заказами внутри неё — база данных
Проще говоря:
данные — это БД, а «двигатель», который с ними работает — СУБД.
¶ Реляционные и нереляционные базы данных: в чём реальная разница
Если упростить до одной фразы:
Реляционные БД — про порядок и строгие правила.
Нереляционные БД — про гибкость и скорость.
¶ Реляционные базы данных (SQL)
Реляционная база данных — это структурированное хранилище, где данные заранее описаны и связаны между собой.
Представь Excel, но:
-
с тысячами таблиц,
-
строгими правилами,
-
защитой от ошибок,
-
одновременной работой тысяч людей.
¶ Структура данных
В реляционной БД:
-
данные хранятся в таблицах,
-
каждая таблица имеет строгую схему,
-
у каждого поля есть тип (строка, число, дата),
-
таблицы связаны между собой.
Пример:
-
таблица
users -
таблица
orders -
заказ всегда ссылается на конкретного пользователя
Это и есть реляция — связь.
¶ Что это даёт проекту
Плюсы:
-
невозможно сохранить «битые» данные,
-
высокая надёжность,
-
отличная работа с транзакциями,
-
идеально для сложной бизнес-логики.
Минусы:
-
сложнее менять структуру данных,
-
требуется продуманная схема,
-
масштабирование может быть сложнее.
¶ Где реляционные БД подходят лучше всего
-
финансы и платежи,
-
CRM и ERP,
-
учёт заказов,
-
системы с отчётностью,
-
всё, где важна точность данных.
¶ Нереляционные базы данных (NoSQL)
Нереляционная база данных — это хранилище, где данные не обязаны подчиняться жёсткой схеме.
Можно хранить разные объекты рядом, даже если они выглядят по-разному.
Представь папку с JSON-файлами:
-
у одного файла есть поле
email, -
у другого — нет,
-
и системе это ок.
¶ Какие задачи решает СУБД в реальном проекте
Современная СУБД отвечает сразу за несколько критически важных вещей:
-
Хранение данных — надёжное и долговременное
-
Параллельный доступ — когда с базой одновременно работают сотни и тысячи пользователей
-
Целостность — защита от «битых» и противоречивых данных
-
Производительность — быстрые запросы даже при больших объёмах
-
Безопасность — разграничение прав доступа
-
Резервное копирование и восстановление
Если СУБД выбрана или настроена неправильно, продукт начинает «тормозить», падать или терять данные.
¶ Почему в одном проекте может быть несколько баз данных
На практике почти всегда используется несколько хранилищ.
Типичный пример:
-
PostgreSQL — основная бизнес-логика,
-
Redis — кэш и сессии,
-
Elasticsearch — поиск,
-
ClickHouse — аналитика.
Это нормально и правильно.
Каждая база решает свою задачу, и попытка «запихнуть всё в одну» часто приводит к проблемам.
¶ Транзакции и целостность данных
Транзакция — это набор операций, которые либо выполняются полностью, либо не выполняются вовсе.
Классический пример:
-
списание денег со счёта,
-
создание заказа,
-
изменение статуса.
Если один шаг не удался — система должна вернуться в исходное состояние.
За это и отвечают транзакции.
Для менеджера важно понимать:
не все базы данных одинаково хорошо работают с транзакциями.
¶ Масштабирование и рост проекта
На старте проекта база данных обычно:
-
одна,
-
простая,
-
без сложных оптимизаций.
С ростом продукта появляются:
-
репликация,
-
шардинг,
-
отдельные базы под разные сервисы,
-
read/write-разделение.
Хорошо выбранная СУБД позволяет расти без полной переделки архитектуры
¶ Клиент-серверная архитектура
Клиент-серверная архитектура — это способ организации системы, при котором:
-
одна часть системы запрашивает данные или действия (клиент),
-
другая часть обрабатывает запросы и управляет данными (сервер).
Клиент и сервер могут находиться:
-
на разных устройствах,
-
в одной сети или в интернете,
-
и взаимодействовать через сеть по заранее определённым правилам (протоколам).
¶ Клиент
Клиент — это любая программа или устройство, которое инициирует запрос.
Примеры клиентов:
-
веб-браузер,
-
мобильное приложение,
-
desktop-программа,
-
другой сервер или сервис.
Клиент:
-
отправляет запрос,
-
получает ответ,
-
отображает данные пользователю или передаёт их дальше.
Клиент не хранит бизнес-логику и не управляет данными напрямую.
¶ Сервер
Сервер — это программа (или набор программ), которая:
-
принимает запросы от клиентов,
-
обрабатывает их,
-
обращается к базе данных или другим сервисам,
-
возвращает результат клиенту.
Сервер может выполнять разные роли:
-
веб-сервер,
-
сервер приложений,
-
сервер аутентификации,
-
сервер баз данных.
Часто все эти роли логически разделены, даже если физически работают на одном компьютере.
¶ Порты и сетевое взаимодействие
Для общения по сети используются порты.
Порт — это логический номер, который указывает, какой сервис должен принять запрос.
Примеры:
-
80 — HTTP,
-
443 — HTTPS,
-
5432 — PostgreSQL,
-
6379 — Redis.
Важно:
-
порт — это не физический разъём,
-
это способ маршрутизации сетевых запросов внутри системы.
¶ Как происходит взаимодействие
Типичный сценарий:
-
Клиент отправляет запрос на сервер.
-
Сервер принимает запрос на определённом порту.
-
Сервер обрабатывает запрос:
-
проверяет права доступа,
-
выполняет бизнес-логику,
-
обращается к базе данных.
-
Сервер возвращает ответ.
-
Клиент использует ответ (показывает пользователю или обрабатывает дальше).
¶ Зачем нужна клиент-серверная архитектура
Она позволяет:
-
централизованно управлять данными,
-
повышать безопасность,
-
масштабировать сервер независимо от клиентов,
-
поддерживать разные типы клиентов (веб, мобильные, API).
Почти все современные веб- и мобильные приложения используют клиент-серверную модель.
¶ API: что это и зачем оно нужно
API (Application Programming Interface) — это способ, с помощью которого программы общаются друг с другом.
Проще говоря, API — это договорённость о том:
-
какие запросы можно отправлять,
-
в каком формате,
-
и какой ответ на них придёт.
API — это интерфейс не для людей, а для кода.
¶ Где используется API
API есть практически в любом современном продукте:
-
фронтенд получает данные с бэкенда,
-
мобильное приложение обращается к серверу,
-
сервис отправляет платёж в платёжную систему,
-
система аналитики получает события,
-
один сервис запрашивает данные у другого.
Если системы взаимодействуют между собой — между ними почти всегда есть API.
¶ Как выглядит API на практике
Обычно API — это:
-
HTTP-запрос,
-
к конкретному адресу (endpoint),
-
с параметрами,
-
и структурированным ответом (чаще всего JSON).
Клиент не знает, как данные хранятся внутри сервера.
Он знает только, как их запросить.
¶ Зачем нужен API
API решает несколько важных задач:
-
Изоляция логики
Клиенту не нужно знать, как устроена серверная часть. -
Безопасность
Клиент получает доступ только к разрешённым данным и действиям. -
Масштабируемость
Один и тот же API могут использовать сайт, мобильное приложение и внешние сервисы. -
Параллельная разработка
Фронтенд и бэкенд могут работать независимо, опираясь на контракт API.
¶ Основные подходы к построению API
¶ REST
REST — это архитектурный стиль проектирования API.
Основные принципы:
-
система строится вокруг ресурсов (пользователи, заказы, товары),
-
используются стандартные HTTP-методы:
-
GET — получить данные,
-
POST — создать,
-
PUT / PATCH — изменить,
-
DELETE — удалить,
-
-
данные чаще всего передаются в формате JSON.
REST прост в использовании и подходит для большинства веб- и мобильных приложений.
¶ SOAP
SOAP — это строгий протокол обмена сообщениями.
Особенности:
-
используется формат XML,
-
жёсткие контракты между системами,
-
сложнее в реализации и поддержке.
Чаще всего применяется в корпоративных и банковских системах, где важны формальные требования и безопасность.
¶ REST и SOAP — в чём разница
-
SOAP — конкретный протокол со строгими правилами.
-
REST — набор принципов и рекомендаций по построению API.
Это инструменты для разных задач и контекстов.
¶ Тестирование API
API можно и нужно тестировать отдельно от пользовательского интерфейса.
Это позволяет:
-
проверять бизнес-логику без UI,
-
быстрее находить ошибки,
-
автоматизировать проверки.
Для этого используют:
-
Postman,
-
Swagger / OpenAPI,
-
автоматизированные API-тесты.
¶ Что важно понимать менеджеру
Менеджеру стоит знать:
-
какие клиенты используют API,
-
как изменения в API влияют на продукт,
-
есть ли документация и версии,
-
кто отвечает за поддержку API.
Любое изменение API — это риск, если не управлять контрактами и версиями.
¶ Главное
-
API — это способ общения между программами.
-
Он отделяет клиент от внутренней логики сервера.
-
REST — стандарт де-факто для большинства продуктов.
-
SOAP используется в системах с повышенными требованиями.
-
Хорошее API — стабильное, предсказуемое и документированное.
¶ Архитектура приложения: монолит и микросервисы
Архитектура приложения отвечает на вопрос:
как устроена внутренняя логика системы и как её части взаимодействуют между собой.
Рассмотрим два самых распространённых подхода.
¶ Монолитная архитектура
Монолит — это приложение, в котором:
-
вся бизнес-логика находится в одном проекте,
-
код собирается и разворачивается как единое целое,
-
все компоненты тесно связаны между собой.
Даже если внутри есть модули, они живут в одном приложении и разворачиваются вместе.
¶ Плюсы монолита
-
проще начать разработку,
-
проще отлаживать,
-
меньше инфраструктурной сложности,
-
легче контролировать целостность данных.
¶ Минусы монолита
-
сложно масштабировать отдельные части системы,
-
изменения в одном месте могут повлиять на всё приложение,
-
со временем код становится труднее поддерживать,
-
релизы требуют большей осторожности.
¶ Когда монолит — хороший выбор
-
небольшой или средний продукт,
-
стартап или MVP,
-
команда без сильной DevOps-экспертизы,
-
понятная и стабильная бизнес-логика.
¶ Микросервисная архитектура
Микросервисы — это подход, при котором:
-
система состоит из набора независимых сервисов,
-
каждый сервис отвечает за свою зону ответственности,
-
сервисы взаимодействуют между собой через API.
Каждый микросервис:
-
разрабатывается отдельно,
-
может иметь свою базу данных,
-
разворачивается независимо от других.
¶ Плюсы микросервисов
-
независимое масштабирование сервисов,
-
изоляция ошибок,
-
команды могут работать автономно,
-
проще внедрять изменения локально.
¶ Минусы микросервисов
-
высокая сложность инфраструктуры,
-
сложнее отладка и мониторинг,
-
больше сетевых взаимодействий,
-
выше требования к DevOps и тестированию.
¶ Когда микросервисы оправданы
-
большой продукт с ростом нагрузки,
-
несколько команд разработки,
-
сложная бизнес-доменная модель,
-
есть опыт и ресурсы для поддержки инфраструктуры.
¶ Монолит vs микросервисы — краткое сравнение
| Критерий | Монолит | Микросервисы |
|---|---|---|
| Старт разработки | Проще | Сложнее |
| Масштабирование | Ограниченное | Гибкое |
| Релизы | Общие | Независимые |
| Инфраструктура | Простая | Сложная |
| Поддержка | Проще в начале | Проще на больших масштабах |
¶ Частая ошибка
❌ Сразу начинать с микросервисов «на вырост».
На практике:
-
большинство продуктов успешнее стартуют как монолиты,
-
микросервисы — это эволюция, а не обязательный стартовый выбор.
¶ Что важно понимать менеджеру
Менеджеру стоит знать:
-
какой архитектурный подход используется,
-
почему он выбран,
-
какие риски и ограничения он несёт,
-
во что обойдётся переход на другую архитектуру.
Архитектура — это не про «модно», а про стоимость изменений и риски.
¶ Главное
-
Клиент-серверная архитектура — основа большинства продуктов.
-
Монолит — простой и надёжный старт.
-
Микросервисы дают гибкость, но увеличивают сложность.
-
Архитектура должна соответствовать масштабу и задачам продукта.
¶ Дополнительный блок
¶ Окружения: Dev / Stage / Prod
Окружение — это отдельная версия системы, в которой приложение запускается с разными
настройками, данными и уровнем доступа.
Разделение на окружения нужно для того, чтобы:
-
разрабатывать и тестировать продукт,
-
не ломать рабочую версию для пользователей,
-
безопасно выкатывать изменения.
Чаще всего используется три основных окружения: Dev, Stage и Prod.
¶ Dev (Development)
Dev — это окружение для разработки.
Здесь:
-
работают разработчики,
-
активно пишется и меняется код,
-
допускаются ошибки и нестабильность.
Особенности Dev-окружения:
-
частые деплои,
-
тестовые или упрощённые данные,
-
может не совпадать с боевой инфраструктурой,
-
низкие требования к стабильности.
Dev нужен для быстрого цикла: написал код → проверил → исправил.
¶ Stage (Staging / Pre-production)
Stage — это окружение, максимально приближенное к боевому.
Здесь:
-
проводится финальное тестирование,
-
проверяются сценарии, близкие к реальным,
-
тестируются релизы перед выкладкой.
Особенности Stage:
-
конфигурация похожа на Prod,
-
используются тестовые или обезличенные данные,
-
релизы выходят реже, чем на Dev,
-
именно здесь QA и менеджеры проверяют готовность продукта.
Stage — это «репетиция перед премьерой».
¶ Prod (Production)
Prod — это рабочее окружение для конечных пользователей.
Здесь:
-
продукт используется клиентами,
-
обрабатываются реальные данные,
-
любые ошибки имеют бизнес-последствия.
Особенности Prod:
-
строгий контроль изменений,
-
деплои по регламенту,
-
повышенные требования к стабильности и безопасности,
-
доступ ограничен.
Любое изменение в Prod должно быть осознанным и контролируемым.
¶ Зачем разделять окружения
Без разделения окружений:
-
ошибки разработчиков попадают к пользователям,
-
тестирование мешает реальной работе,
-
сложнее искать причины проблем.
Разделение позволяет:
-
безопасно экспериментировать,
-
ловить ошибки раньше,
-
снижать риски для бизнеса.
¶ Логи и мониторинг
Логи и мониторинг — это инструменты наблюдения за системой в работе.
Если упростить:
-
логи отвечают на вопрос «что произошло?»,
-
мониторинг отвечает на вопрос «всё ли работает нормально?».
Они нужны не только разработчикам, но и менеджерам.
¶ Логи
Логи — это записи о событиях, которые происходят в системе.
В логах фиксируется:
-
ошибки и исключения,
-
действия пользователей,
-
запросы к API,
-
внутренние события приложения.
Примеры логов:
-
ошибка при обработке запроса,
-
отказ подключения к базе данных,
-
успешное выполнение операции.
¶ Зачем нужны логи
Логи позволяют:
-
находить причины ошибок,
-
понимать поведение системы,
-
разбирать инциденты,
-
анализировать пользовательские сценарии.
Без логов ошибка превращается в «у кого-то что-то не работает».
¶ Уровни логирования
Обычно логи делятся по уровням:
-
DEBUG — технические детали, полезны при разработке,
-
INFO — важные события работы системы,
-
WARNING — подозрительные, но не критичные ситуации,
-
ERROR — ошибки, требующие внимания,
-
CRITICAL — сбои, влияющие на работу продукта.
На разных окружениях могут использоваться разные уровни логирования.
¶ Мониторинг
Мониторинг — это система автоматического наблюдения за состоянием продукта.
Он отслеживает:
-
доступность сервисов,
-
время отклика,
-
нагрузку,
-
ошибки,
-
использование ресурсов.
Мониторинг работает постоянно и автоматически.
¶ Что обычно мониторят
-
статус сервисов (работает / не работает),
-
количество ошибок,
-
время ответа API,
-
загрузку CPU и памяти,
-
заполненность дисков,
-
состояние очередей и баз данных.
¶ Алерты и уведомления
Мониторинг настраивается так, чтобы:
-
при отклонениях система присылала уведомления,
-
команда узнавала о проблеме сразу,
-
а не от пользователей.
Алерты могут приходить:
-
в мессенджеры,
-
на почту,
-
в системы инцидентов.
¶ Почему мониторинг важен для бизнеса
Мониторинг позволяет:
-
быстрее реагировать на сбои,
-
снижать простой продукта,
-
контролировать качество сервиса,
-
принимать решения на основе данных, а не ощущений.
Хороший мониторинг — это профилактика, а не пожаротушение.
¶ Что важно понимать менеджеру
Менеджеру стоит знать:
-
какие окружения существуют,
-
кто и как в них работает,
-
есть ли логи и мониторинг,
-
как команда узнаёт о проблемах.
Если нет логов и мониторинга — продукт «слепой».
¶ QA: качество продукта и как его обеспечивают
QA (Quality Assurance) — это не просто «поиск багов», а процесс обеспечения качества продукта на всех этапах разработки.
Задача QA — сделать так, чтобы продукт:
-
работал стабильно,
-
соответствовал требованиям,
-
был предсказуем для пользователя.
QA участвует в процессе с самого начала, а не только перед релизом.
¶ Роль QA в команде
QA-инженеры:
-
проверяют требования и макеты,
-
тестируют функциональность,
-
находят и описывают дефекты,
-
помогают команде понять риски изменений.
QA — это связующее звено между:
-
бизнесом,
-
разработкой,
-
пользователем.
¶ Уровни тестирования
Тестирование обычно организуют в виде пирамиды.
¶ Модульные тесты (Unit)
Проверяют отдельные функции или модули кода.
Особенности:
-
пишутся разработчиками,
-
быстрые и дешёвые,
-
позволяют находить ошибки на раннем этапе.
Чем больше unit-тестов — тем стабильнее кодовая база.
¶ Интеграционные тесты (Integration)
Проверяют взаимодействие компонентов между собой:
-
сервис ↔ база данных,
-
сервис ↔ внешний API,
-
несколько модулей вместе.
Позволяют выявить ошибки на стыках системы.
¶ Компонентные тесты
Проверяют отдельные функциональные блоки приложения в рамках более крупной системы.
Часто используются для тестирования сервисов или модулей в изоляции от остальной системы.
¶ End-to-End тесты (E2E)
Проверяют систему целиком с точки зрения пользователя.
Особенности:
-
самые дорогие и медленные,
-
но максимально приближены к реальным сценариям,
-
часто используются для проверки ключевых бизнес-процессов.
¶ Виды тестирования, с которыми сталкиваются чаще всего
¶ Функциональное тестирование
Проверяет, что продукт выполняет заявленные функции:
-
кнопки работают,
-
сценарии выполняются,
-
данные обрабатываются корректно.
¶ Регрессионное тестирование
Проводится после изменений в продукте.
Цель — убедиться, что:
-
старый функционал не сломался,
-
новые изменения не повлияли на существующую логику.
¶ Нагрузочное и производительное тестирование
Проверяет:
-
как система ведёт себя при высокой нагрузке,
-
сколько пользователей она может выдержать,
-
где находятся узкие места.
Важно для продуктов с ростом аудитории.
¶ Автоматизированное тестирование
Это способ выполнения тестов с помощью кода и инструментов.
Автоматизируют:
-
unit-тесты,
-
интеграционные тесты,
-
часть E2E-сценариев.
Автотесты ускоряют проверку и снижают количество ручной работы.
¶ Тест-кейсы и документация
Тест-кейс — это описание сценария проверки, которое может выполнить любой член команды.
Обычно включает:
-
шаги,
-
ожидаемый результат,
-
условия выполнения.
Хорошие тест-кейсы делают процесс тестирования прозрачным и воспроизводимым.
¶ Что важно понимать менеджеру про QA
Менеджеру стоит знать:
-
какие виды тестирования используются,
-
что покрыто автотестами,
-
где остаётся ручная проверка,
-
какие риски остаются перед релизом.
QA — это инвестиция в стабильность, а не тормоз разработки.
