System Analysis Pro: От требований до System Design

Работа с требованиями, стейкхолдерами и моделирование процессов с использованием PlantUML

Добро пожаловать в первую статью курса System Analysis Pro. Мы начинаем с фундамента. Любая архитектура, любой код и любая интеграция бессмысленны, если они решают не ту проблему, которая есть у бизнеса.

Системный аналитик (SA) — это мост между хаосом человеческих желаний и строгой логикой машинного кода. Ваша задача — не просто «записать, что сказал заказчик», а перевести бизнес-потребность в техническое решение.

В этом модуле мы разберем, как выявлять требования, управлять ожиданиями стейкхолдеров и превращать слова в строгие диаграммы с помощью подхода Docs-as-Code и инструмента PlantUML.

1. Стейкхолдеры: Кто все эти люди?

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

Классификация стейкхолдеров

На реальных проектах вы столкнетесь с разными типами участников:

Бизнес-заказчик (Sponsor): Тот, кто платит деньги. Ему важны сроки и ROI (Return on Investment).

Предметные эксперты (SME — Subject Matter Experts): Люди, которые знают, как процесс работает сейчас (бухгалтеры, логисты, менеджеры).

Конечные пользователи: Те, кто будет нажимать кнопки.

Техническая команда: Разработчики, QA, DevOps, архитекторы. Они — тоже ваши стейкхолдеры, так как потребляют ваши требования.

Регуляторы: Юристы, служба безопасности (InfoSec).

!Визуализация уровней влияния стейкхолдеров на проект от центра к периферии.

Матрица RACI

Чтобы не запутаться, кто за что отвечает, используйте матрицу RACI. Это обязательный инструмент для SA на старте проекта.

* R (Responsible): Исполнитель. Тот, кто делает работу (например, разработчик пишет код, аналитик пишет ТЗ). * A (Accountable): Ответственный. Тот, кто принимает работу и несет ответственность за результат (обычно один человек, например, Product Owner). * C (Consulted): Консультант. Тот, у кого спрашивают совета (SME, архитектор). * I (Informed): Информируемый. Тот, кого ставят в известность о результатах (например, техподдержка).

> Совет с собеседования: Если вас спросят, как вы работаете с противоречивыми требованиями от разных стейкхолдеров, правильный ответ: «Я собираю их вместе, подсвечиваю конфликт и влияние на бизнес-цели, и прошу ЛПР (Лицо, Принимающее Решения — Accountable) выбрать приоритетный вариант».

2. Пирамида требований

Требование — это условие, которому должна соответствовать система. Но требования бывают разного уровня детализации.

Уровни требований

Бизнес-требования (Business Requirements): Отвечают на вопрос «Зачем?». Описывают цели бизнеса.

Пример:* «Увеличить конверсию продаж на 15% за счет внедрения онлайн-оплаты».

Пользовательские требования (User Requirements): Отвечают на вопрос «Что делает пользователь?». Часто оформляются в виде User Stories или Use Cases.

Пример:* «Как покупатель, я хочу оплатить заказ картой, чтобы не искать наличные».

Функциональные требования (Functional Requirements): Отвечают на вопрос «Что делает система?». Это инструкции для разработчика.

Пример:* «Система должна отправить запрос в платежный шлюз с суммой заказа и токеном карты».

Нефункциональные требования (Non-Functional Requirements / NFR): Отвечают на вопрос «Как система это делает?». Это ограничения и качественные характеристики.

Пример:* «Время ответа платежного шлюза не должно превышать 2 секунды».

Атрибуты качества требований

Хорошее требование должно быть понятным и проверяемым. Используйте критерии INVEST для User Stories и SMART для целей, но для системного анализа критичны следующие свойства:

* Атомарность: Одно требование — одна мысль. * Недвусмысленность: Нельзя трактовать двояко. * Тестируемость: QA должен понимать, как написать тест-кейс. * Трассируемость: Понятно, откуда требование пришло (от какой бизнес-цели).

3. Моделирование процессов: Визуализация логики

Текст — плохой способ передачи сложной логики. Разработчики не читают «простыни» текста. Они смотрят диаграммы. Мы будем использовать UML (Unified Modeling Language), так как это стандарт индустрии.

Основные диаграммы для SA

Use Case Diagram: Кто и что делает в системе (верхнеуровневый обзор).

Activity Diagram: Алгоритм действий, блок-схема с условиями и ветвлениями.

Sequence Diagram (Диаграмма последовательности): Самая важная диаграмма для проектирования интеграций. Показывает обмен сообщениями между системами во времени.

State Machine Diagram: Жизненный цикл объекта (например, статусы заказа: Создан -> Оплачен -> Доставлен).

4. PlantUML: Практика Docs-as-Code

В современном мире мы отходим от рисования в Visio или draw.io в пользу PlantUML или Mermaid. Почему?

* Версионирование: Диаграмма — это код. Ее можно положить в Git. * Скорость: Правка текста быстрее, чем перетаскивание квадратиков мышкой. * Единообразие: Стиль отрисовки автоматический.

Основы синтаксиса Sequence Diagram в PlantUML

Давайте разберем реальный кейс: Авторизация пользователя.

Синтаксис предельно прост: * Participant -> Participant : Сообщение — синхронный вызов. * Participant --> Participant : Ответ — пунктирная стрелка возврата. * alt / else — блок условий (if/else).

Вот как выглядит код диаграммы для входа в систему:

!Диаграмма последовательности процесса авторизации, показывающая взаимодействие между пользователем, фронтендом, сервисом авторизации и базой данных.

Разбор элементов диаграммы

Участники (Participants): Мы явно задали их через participant и database. Использование as позволяет давать короткие алиасы (например, DB).

Активация (Activate/Deactivate): Прямоугольники на линиях жизни показывают, когда компонент «думает» или выполняет работу.

Альтернативы (Alt): Критически важно показывать не только «Happy Path» (успешный сценарий), но и обработку ошибок.

5. Документирование требований (SRS)

Результатом вашей работы является SRS (Software Requirements Specification). В современных компаниях это чаще всего страница в Confluence или файл Markdown в репозитории.

Типовая структура описания фичи:

Цель: Зачем делаем?

User Story: Кто, что и зачем хочет.

Диаграмма процесса (Sequence/Activity): Визуализация.

Описание API контрактов: Ссылка на Swagger или описание JSON (об этом в следующем уроке).

Критерии приемки (Acceptance Criteria): Список проверок для QA.

6. Подготовка к интервью (System Design Section)

На собеседованиях часто просят: «Нарисуйте, как происходит покупка товара».

Ваш алгоритм действий:

Уточните требования: «Какой масштаб?», «Нужна ли оплата сразу?», «Учитываем ли склад?».

Выделите акторов: Покупатель, Система, Склад, Платежная система.

Начните с Happy Path: Нарисуйте (или опишите) основной успешный сценарий.

Добавьте Edge Cases: «А что, если товара нет на складе?», «А что, если оплата не прошла?».

Использование PlantUML (или псевдокода диаграмм) на собеседовании показывает вашу техническую грамотность и умение структурировать мысли.

Заключение

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

В следующем модуле мы перейдем к техническому «мясу»: Синхронные интеграции, REST API и проектирование контрактов.

Проектирование баз данных: SQL, NoSQL, оптимизация и моделирование данных

В предыдущих модулях мы научились собирать требования и проектировать API. Но данные, которые передаются через API, должны где-то храниться. Для системного аналитика база данных (БД) — это не «черный ящик», а структурированное хранилище, логику которого проектируете именно вы.

На собеседованиях уровня Middle+ и Senior вопросы по базам данных занимают до 30% времени секции System Design. Вас не попросят написать сложный JOIN по памяти, но спросят, почему вы выбрали MongoDB вместо PostgreSQL для финансового сервиса (и если вы выбрали MongoDB, то, скорее всего, провалили интервью).

В этой статье мы разберем уровни моделирования, разницу между SQL и NoSQL, принципы ACID и основы оптимизации.

1. Уровни моделирования данных

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

Концептуальная модель (Conceptual Data Model)

Это взгляд бизнеса. Мы определяем сущности (Entities) и связи (Relationships) между ними, не вдаваясь в атрибуты. Пример:* «Клиент» делает «Заказ», в «Заказе» есть «Товары».

Логическая модель (Logical Data Model)

Это взгляд архитектора/аналитика. Здесь появляются: * Все атрибуты (поля) сущностей. * Типы данных (строка, число, дата), но без привязки к конкретной СУБД. * Первичные (PK) и внешние (FK) ключи. * Нормализация.

Физическая модель (Physical Data Model)

Это взгляд DBA (Database Administrator) и разработчика. Специфична для конкретной СУБД (PostgreSQL, Oracle, MySQL). * Точные типы данных (VARCHAR(255), BIGINT). * Индексы, партицирование, триггеры.

!Три уровня абстракции при проектировании баз данных.

2. ER-диаграммы и связи

Для визуализации логической модели используется ERD (Entity-Relationship Diagram). Основной стандарт нотации — Crow’s Foot («Воронья лапка»).

Типы связей

Один к одному (1:1): Одна запись в таблице A соответствует одной записи в таблице B.

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

Один ко многим (1:N): Одна запись в A связана со множеством записей в B.

Пример:* Один Клиент — много Заказов. Это самый частый тип связи. Реализуется добавлением Client_ID в таблицу Заказов.

Многие ко многим (M:N): Множество записей в A связано со множеством записей в B.

Пример:* Студенты и Курсы. Один студент ходит на много курсов, на одном курсе много студентов. Реализация:* В реляционных БД такая связь всегда раскрывается через третью (связующую) таблицу.

PlantUML для ERD

Как аналитики, работающие в парадигме Doc-as-Code, мы описываем структуру кодом:

3. Реляционные базы данных (SQL)

Реляционные СУБД (RDBMS) хранят данные в таблицах со строгой схемой. Самый популярный представитель сейчас — PostgreSQL.

Язык SQL

SQL (Structured Query Language) делится на 4 подмножества, которые вы должны различать:

DDL (Data Definition Language): Определение структуры (CREATE, ALTER, DROP).

DML (Data Manipulation Language): Работа с данными (SELECT, INSERT, UPDATE, DELETE).

DCL (Data Control Language): Права доступа (GRANT, REVOKE).

TCL (Transaction Control Language): Управление транзакциями (COMMIT, ROLLBACK).

ACID: Священный грааль надежности

Почему банки используют SQL? Из-за гарантий ACID. Это ключевой термин для собеседования.

A — Atomicity (Атомарность): Транзакция выполняется целиком или не выполняется вовсе. Если в процессе перевода денег отключилось электричество, деньги не спишутся со счета отправителя, если не зачислились получателю.

C — Consistency (Согласованность): Транзакция переводит базу из одного корректного состояния в другое. Нарушить ограничения (constraints) нельзя.

I — Isolation (Изолированность): Параллельные транзакции не мешают друг другу (уровень изоляции настраивается).

D — Durability (Долговечность): Если система сказала «ОК» (Commit), данные сохранены на диске, даже если сервер сгорит через секунду.

Нормализация

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

* 1NF: В каждой ячейке атомарное значение (не храним массив телефонов в одной строке). * 2NF: Все атрибуты зависят от всего первичного ключа. * 3NF: Нет транзитивных зависимостей (атрибуты зависят только от ключа, а не от других атрибутов).

> Совет: На практике часто используют денормализацию (осознанное дублирование данных) для ускорения чтения, но начинать проектирование всегда нужно с 3NF.

4. NoSQL: Гибкость и масштабируемость

NoSQL (Not Only SQL) — это семейство БД, которые отказываются от некоторых свойств реляционных баз (чаще всего от жесткой схемы и строгих JOIN-ов) ради скорости или масштабируемости.

Основные типы NoSQL

| Тип | Представители | Для чего использовать | Пример | | :--- | :--- | :--- | :--- | | Document | MongoDB, CouchDB | Хранение сложных иерархических структур (JSON), каталоги товаров с разными атрибутами. | Профиль пользователя, карточка товара | | Key-Value | Redis, Memcached | Кэширование, сессии, счетчики. Сверхбыстрый доступ по ключу. | Токен сессии, корзина покупок | | Column-family | Cassandra, HBase | Запись огромных потоков данных (Big Data), аналитика, логи. | История сенсоров IoT, логи событий | | Graph | Neo4j | Социальные связи, рекомендательные системы, поиск маршрутов. | «Друзья друзей», антифрод-системы |

CAP-теорема

В распределенных системах невозможно одновременно гарантировать все три свойства:

C (Consistency): Согласованность (все узлы видят одни и те же данные одновременно).

A (Availability): Доступность (каждый запрос получает ответ, успешный или нет).

P (Partition Tolerance): Устойчивость к разделению (система работает, даже если связь между серверами пропала).

SQL базы обычно выбирают CA (но плохо масштабируются). NoSQL выбирают AP (доступность важнее, данные могут быть временно несогласованны — Eventual Consistency) или CP.

5. Оптимизация производительности

Аналитик должен понимать, почему запрос работает медленно.

Индексы

Индекс — это структура данных (обычно B-Tree), которая ускоряет поиск, но замедляет вставку (так как индекс нужно перестраивать).

Представьте библиотеку. Чтобы найти книгу по названию, вы идете в картотеку (индекс). Это быстро. Сложность поиска в сбалансированном дереве описывается формулой:

где — «О большое» (оценка сложности алгоритма), — логарифм, а — количество записей в таблице. Без индекса сложность была бы (полный перебор всех книг).

Правило: Индексы нужны на полях, по которым часто идет поиск (WHERE), сортировка (ORDER BY) или соединение (JOIN).

Репликация и Шардирование

Когда данных становится слишком много:

Репликация (Master-Slave): Данные дублируются на несколько серверов. Пишем в Master, читаем со Slaves. Повышает надежность и скорость чтения.

Шардирование (Sharding): Горизонтальное разделение. Таблица разрезается на части: пользователи с ID 1-1000 на сервере А, 1001-2000 на сервере Б. Сложно в реализации, но позволяет масштабироваться бесконечно.

!Принцип горизонтального шардирования данных.

6. Практика System Design: SQL или NoSQL?

На интервью вам дадут задачу: «Спроектируйте Instagram». Какой выбор сделать?

Выбирайте SQL (PostgreSQL/MySQL), если: * Нужны финансовые транзакции (ACID). * Структура данных стабильна и предсказуема. * Важна целостность связей.

Выбирайте NoSQL, если: * Данные неструктурированы (разные поля у разных документов). * Нужна экстремальная скорость записи (IoT, логи). * Данных так много, что одна машина не справляется (Petabytes). * Нужна гибкость схемы на старте стартапа (MongoDB).

Гибридный подход (наиболее частый): * Пользователи и платежи — в PostgreSQL. * Лента постов и лайки — в Cassandra или MongoDB. * Кэш сессий и счетчики просмотров — в Redis.

Заключение

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

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

Архитектура интеграций: синхронные API (REST, gRPC) и асинхронное взаимодействие (Kafka, RabbitMQ)

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

Интеграция — это кровеносная система любой современной архитектуры. На собеседованиях по System Design вопрос «Как сервисы будут обмениваться данными?» является ключевым. Ошибка здесь может привести к тому, что падение одного некритичного сервиса (например, отправки уведомлений) «положит» всю систему оформления заказов.

В этой статье мы разберем два фундаментальных подхода: синхронный и асинхронный, а также ключевые технологии: REST, gRPC, RabbitMQ и Kafka.

1. Синхронное vs Асинхронное взаимодействие

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

Синхронное взаимодействие (Request-Response)

Клиент отправляет запрос и ждет ответа. Процесс на стороне клиента блокируется (или ожидает callback), пока сервер не вернет данные или ошибку.

* Аналогия: Телефонный звонок. Вы говорите, собеседник слушает и отвечает сразу. Если собеседник не берет трубку, разговор не состоится. * Плюсы: Простота, предсказуемость, получение результата «здесь и сейчас». * Минусы: Сильная связность (Coupling). Если сервер упал, клиент получает ошибку. Если сервер работает медленно, клиент тоже тормозит.

Асинхронное взаимодействие (Fire-and-Forget)

Клиент отправляет сообщение и не ждет мгновенной обработки. Он продолжает свою работу. Сервер (или несколько серверов) прочитает сообщение, когда сможет.

* Аналогия: Электронная почта или мессенджер. Вы отправили сообщение и пошли заниматься делами. Адресат прочитает его через минуту или через час. * Плюсы: Слабая связность, сглаживание пиковых нагрузок, отказоустойчивость. * Минусы: Сложность отладки, возможная задержка обработки (Eventual Consistency).

!Визуальное сравнение блокирующего синхронного вызова и неблокирующего асинхронного через очередь.

2. Синхронные интеграции: REST и gRPC

Когда нам нужно получить данные немедленно (например, отобразить профиль пользователя в мобильном приложении), мы используем синхронные протоколы.

REST (Representational State Transfer)

Это не протокол, а архитектурный стиль, работающий поверх HTTP. Это стандарт де-факто для публичных API и взаимодействия фронтенда с бэкендом.

Ключевые принципы для аналитика:

Ресурсо-ориентированность: Мы оперируем существительными (User, Order, Product).

HTTP глаголы:

* GET — получить данные (идемпотентный, безопасный). * POST — создать новый ресурс (не идемпотентный). * PUT — обновить ресурс целиком (идемпотентный). * PATCH — обновить ресурс частично. * DELETE — удалить ресурс.

Stateless: Сервер не хранит состояние сессии между запросами. Вся информация (токены) передается в каждом запросе.

Документирование: Для описания REST API используется спецификация OpenAPI (Swagger). Как аналитик, вы будете писать или генерировать YAML/JSON файлы, описывающие пути, типы данных и коды ответов.

gRPC (Google Remote Procedure Call)

Если REST — это «текстовая переписка», то gRPC — это «сжатый бинарный канал». Это фреймворк, разработанный Google для высокопроизводительного общения между микросервисами (Server-to-Server).

Особенности:

* Protocol Buffers (Protobuf): Данные сериализуются в бинарный формат, а не в текстовый JSON. Это делает сообщения намного легче и быстрее для парсинга. * HTTP/2: Использует возможности HTTP/2 (мультиплексирование, стриминг). * Строгая типизация: Контракт описывается в .proto файлах. Вы не можете случайно передать строку вместо числа, код просто не скомпилируется.

Когда выбирать gRPC? * Внутреннее общение между микросервисами (высокая скорость). * Стриминг данных (например, передача голоса или видео). * IoT устройства (экономия трафика).

Сравнение объемов данных (условно): Предположим, мы передаем объект пользователя. * JSON: {"id": 123, "name": "Alice", "active": true} — занимает около 45 байт + заголовки HTTP/1.1. * Protobuf: Тот же объект может занимать 10-15 байт благодаря бинарной упаковке и отсутствию ключей (имен полей) в передаваемых данных (передаются только значения по индексам).

3. Асинхронные интеграции: Брокеры сообщений

Для асинхронного общения используется промежуточное звено — Message Broker. Это «почтовое отделение», которое принимает сообщения от отправителей (Producers) и раздает их получателям (Consumers).

Два гиганта в этой области: RabbitMQ и Apache Kafka. На собеседовании вас обязательно спросят, в чем разница.

RabbitMQ (Smart Broker, Dumb Consumer)

Классический брокер очередей. Реализует протокол AMQP.

Как это работает:

Продюсер отправляет сообщение в Exchange (Обменник).

Exchange по правилам маршрутизации (Routing Key) кладет сообщение в одну или несколько Queues (Очередей).

Консьюмер забирает сообщение из очереди.

Важно: После того как консьюмер подтвердил обработку (Ack), сообщение удаляется из очереди.

Сценарии использования: * Фоновые задачи (отправка email, генерация PDF). * Сложная маршрутизация (сообщения с ошибками — в одну очередь, логи — в другую). * Ситуации, где порядок не критичен или нагрузка не экстремальна.

!Поток данных в RabbitMQ: от продюсера через обменник в очереди и к потребителям.

Apache Kafka (Dumb Broker, Smart Consumer)

Это не просто очередь, это распределенный лог событий (Distributed Commit Log).

Как это работает:

Сообщения записываются в Topic (Топик) и хранятся на диске.

Топик делится на Partitions (Партиции) для масштабирования.

Сообщения не удаляются после прочтения. Они хранятся заданное время (Retention Policy, например, 7 дней).

Консьюмер сам помнит, на каком месте (Offset) он закончил чтение.

Сценарии использования: * Обработка потоков данных (Stream Processing, аналитика кликов, логи). * Event Sourcing (восстановление состояния системы по истории событий). * Огромные объемы данных (сотни тысяч сообщений в секунду).

Главное отличие для собеседования

> В RabbitMQ сообщение исчезает после обработки. В Kafka сообщение остается, и его могут прочитать другие сервисы или тот же сервис заново (Replayability).

4. Паттерны гарантии доставки

При проектировании интеграций аналитик должен определить требования к надежности. Существует три уровня гарантий:

At-most-once (Максимум один раз): Сообщение может потеряться, но никогда не продублируется. «Выстрелил и забыл». Подходит для логов или метрик.

At-least-once (Минимум один раз): Сообщение точно дойдет, но может прийти дважды. Это самый популярный стандарт.

Проблема:* Дубликаты. Решение:* Идемпотентность. Ваш сервис должен уметь обрабатывать одно и то же сообщение много раз без побочных эффектов (например, проверять ID транзакции перед начислением денег).

Exactly-once (Ровно один раз): Святой Грааль интеграций. Сообщение доставляется строго один раз. Очень дорого и сложно в реализации (Kafka Streams + транзакции), сильно снижает производительность.

5. Практика System Design: Что выбрать?

Представьте, что вы проектируете систему такси (Uber/Yandex Go).

Клиент заказывает такси:

Выбор:* REST/gRPC (Синхронно). Почему:* Пользователь ждет подтверждения «Поиск начат» прямо сейчас. Ему нужен ответ HTTP 200 OK.

Поиск водителя:

Выбор:* RabbitMQ/Kafka (Асинхронно). Почему:* Это долгий процесс. Сервис заказов кидает событие OrderCreated в брокер. Сервис матчинга вычитывает его и начинает искать водителя. Пользователь не держит соединение открытым.

Координаты водителя на карте:

Выбор:* gRPC (Bidirectional Streaming) или WebSocket (для клиента). Почему:* Поток координат идет постоянно (раз в секунду). REST создаст огромный оверхед на открытие соединений. gRPC идеален для передачи потока координат от водителя на сервер.

Сбор аналитики поездок:

Выбор:* Kafka. Почему:* Огромный поток данных, который нужно сохранить для Data Science. RabbitMQ может захлебнуться, а Kafka создана для этого.

Заключение

Умение комбинировать REST для пользовательских интерфейсов, gRPC для быстрых внутренних связей и Kafka/RabbitMQ для надежных фоновых процессов — это признак зрелого системного аналитика.

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

Проектирование архитектуры приложений, микросервисы и основы DevOps для аналитика

Мы прошли долгий путь: научились собирать требования, спроектировали базу данных и определили способы интеграции (REST, Kafka). Теперь перед нами стоит главная инженерная задача — собрать эти компоненты в единую работающую систему.

На собеседованиях секция System Design часто начинается с вопроса: «Как бы вы спроектировали архитектуру для аналога Uber?». Если вы сразу ответите «Микросервисы!», интервьюер, скорее всего, начнет вас «топить». Почему? Потому что архитектура — это искусство компромиссов (trade-offs).

В этой статье мы разберем, когда нужен монолит, а когда микросервисы, как документировать архитектуру по стандарту C4 и почему аналитик должен понимать основы DevOps.

1. Монолит vs Микросервисы: Вечная битва

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

Монолитная архитектура (Monolith)

В монолите вся функциональность (авторизация, заказы, платежи, отчеты) упакована в одно приложение, разворачиваемое как единое целое. У него одна кодовая база и, чаще всего, одна база данных.

Плюсы: * Простота разработки: Легко запустить локально, легко отлаживать, IDE «видит» весь код. * Простота развертывания: Один артефакт (например, один .jar файл или Docker-контейнер). * Производительность: Вызовы внутри процесса происходят в памяти, что на порядки быстрее сетевых запросов. * ACID-транзакции: Легко обеспечить целостность данных в одной БД.

Минусы: * Сложность масштабирования: Если нагрузка идет только на модуль «Отчеты», приходится масштабировать (дублировать) весь огромный монолит. * Технологический тупик: Сложно переписать часть системы на новый язык. * Риск отказа: Ошибка в одном модуле (например, утечка памяти в генерации PDF) может «убить» весь сервис.

> Важно: Монолит — это не ругательство. Для стартапов и систем с умеренной нагрузкой Modular Monolith (модульный монолит) — лучшее решение.

Микросервисная архитектура (Microservices)

Система разбивается на набор небольших, независимых сервисов, каждый из которых запускается в своем процессе и общается с другими через легковесные механизмы (HTTP/gRPC/Kafka).

Ключевые принципы:

Single Responsibility: Один сервис делает одну вещь хорошо.

Database per Service: У каждого сервиса своя база данных. Никто не лезет в чужую БД напрямую, только через API.

Independent Deployment: Можно обновить сервис «Платежи», не останавливая сервис «Каталог».

!Сравнение монолитной архитектуры с единой базой данных и микросервисной архитектуры с изолированными базами.

Математика надежности

Микросервисы вводят риск снижения доступности. Если для выполнения операции (например, «Оформить заказ») нужно синхронное участие 5 сервисов, общая доступность системы падает.

Формула расчета доступности последовательной цепи:

где — итоговая доступность системы (вероятность безотказной работы), а — доступность каждого отдельного компонента (например, 0.99).

Если у вас 5 сервисов с SLA 99% (), то общая надежность:

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

2. Паттерны микросервисной архитектуры

Аналитик обязан знать эти паттерны, чтобы грамотно проектировать потоки данных.

API Gateway

Если у вас 50 микросервисов, фронтенд не должен знать адреса их всех. Он обращается к единой точке входа — API Gateway.

* Функции: Маршрутизация запросов, аутентификация, ограничение нагрузки (Rate Limiting), агрегация ответов. * BFF (Backend for Frontend): Разновидность паттерна, когда создается отдельный Gateway для Web, отдельный для Mobile.

Service Discovery

В облаке сервисы постоянно перезапускаются, их IP-адреса меняются. Service Discovery (например, Consul или Eureka) — это «телефонная книга», где сервисы регистрируют себя, чтобы другие могли их найти.

Circuit Breaker (Предохранитель)

Паттерн защиты от каскадных сбоев. Если сервис А видит, что сервис Б постоянно отдает ошибки или тайм-ауты, он «размыкает цепь» и перестает слать туда запросы на некоторое время, сразу отдавая заглушку или ошибку. Это дает сервису Б время на восстановление.

3. Документирование архитектуры: Модель C4

Забудьте про хаотичные квадратики в Draw.io. Индустриальный стандарт описания архитектуры — модель C4 (Context, Containers, Components, Code). Она работает по принципу «Google Maps»: от общего вида планеты к улицам.

Level 1: System Context (Контекст)

Самый верхний уровень. Показывает вашу систему в центре и всех внешних акторов (пользователей и внешние системы). Для кого:* Для бизнеса, менеджеров, новых сотрудников. Вопрос:* В каком окружении работает система?

Level 2: Container (Контейнеры)

«Контейнер» здесь — это не Docker, а отдельно запускаемая/развертываемая единица: SPA-приложение, мобильное приложение, API-бэкенд, База Данных. Для кого:* Для архитекторов, аналитиков, DevOps. Вопрос:* Из каких приложений состоит система и как они общаются (протоколы)?

Level 3: Component (Компоненты)

Детализация конкретного контейнера. Из каких логических блоков состоит бэкенд (Controller, Service, Repository). Для кого:* Для разработчиков.

Level 4: Code (Код)

UML диаграммы классов. Аналитики обычно сюда не спускаются.

> Совет: На System Design интервью и в документации (SRS) вы чаще всего будете рисовать Level 2 (Container Diagram).

!Диаграмма C4 уровня Container, показывающая основные развертываемые модули системы и связи между ними.

4. Основы DevOps для аналитика

Вам не нужно уметь писать скрипты на Bash, но вы должны понимать, как ваши требования превращаются в работающий продукт. Это называется CI/CD.

CI (Continuous Integration)

Непрерывная интеграция. Разработчик отправляет код в Git. Автоматически запускается сборка и тесты (Unit-тесты). Если тесты прошли, создается артефакт.

CD (Continuous Delivery / Deployment)

Непрерывная доставка. Артефакт автоматически разворачивается на тестовом стенде (Stage), прогоняются автотесты, и затем (автоматически или по кнопке) код уходит в продакшн.

Контейнеризация (Docker)

Раньше была проблема: «У меня на машине работает, а на сервере нет». Docker решает её, упаковывая приложение со всеми библиотеками в изолированный контейнер.

Оркестрация (Kubernetes / K8s)

Когда контейнеров становится сотни, ими нужно управлять: перезапускать упавшие, масштабировать под нагрузкой. Этим занимается Kubernetes.

Что важно знать аналитику про K8s: * Pod (Под): Минимальная единица, один или несколько контейнеров. * ConfigMap/Secrets: Конфигурации и пароли хранятся отдельно от кода. Если вам нужно добавить новую настройку (например, таймаут), это требование к ConfigMap.

5. Observability: Логи, Метрики, Трейсинг

Как понять, что система работает плохо, если она распределенная?

Логи (Logs): Текстовая запись событий («Ошибка подключения к БД»). Инструменты: ELK Stack (Elasticsearch, Logstash, Kibana), Graylog.

Метрики (Metrics): Числовые показатели во времени (CPU, RAM, RPS — Requests Per Second). Инструменты: Prometheus, Grafana.

Трейсинг (Distributed Tracing): Самое важное для микросервисов. Позволяет увидеть путь одного запроса через 10 сервисов и понять, где именно возникла задержка. Каждому запросу присваивается Trace ID. Инструменты: Jaeger, Zipkin.

6. Практика System Design: Алгоритм выбора

На интервью вам зададут вопрос: «Монолит или микросервисы?». Ваш ответ должен звучать так:

«Я начну с монолитной архитектуры (или модульного монолита), чтобы ускорить Time-to-Market и упростить отладку, так как доменная область еще может меняться. Однако я буду проектировать модули слабосвязанными (Loose Coupling), чтобы в будущем, при росте нагрузки или команды, вынести нагруженные части (например, Поиск или Платежи) в отдельные микросервисы. Для связи буду использовать REST для синхронных вызовов и Kafka для асинхронных процессов».

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

Заключение

Архитектура — это скелет системы. Микросервисы дают гибкость, но требуют высокой культуры DevOps и сложной инфраструктуры. Монолит прост, но имеет предел роста. Ваша задача как аналитика — видеть картину целиком (C4 Context/Container) и понимать цену каждого архитектурного решения.

В следующем модуле мы поговорим о том, что происходит после релиза: Сопровождение сервиса, управление инцидентами и работа с техническим долгом.

Подход Doc-as-Code и подготовка к секции System Design интервью

Поздравляю! Вы прошли путь от сбора требований и рисования первых диаграмм до понимания микросервисной архитектуры и процессов CI/CD. Теперь у вас есть технический фундамент.

Однако в работе системного аналитика (особенно уровня Senior) есть два критически важных навыка, которые отличают профессионала от любителя:

Умение поддерживать документацию в актуальном состоянии, не тратя на это 100% времени.

Умение «продать» свои знания на техническом интервью, решая архитектурные задачи в реальном времени.

В этой финальной статье мы разберем методологию Doc-as-Code и подготовимся к самому сложному этапу собеседования — секции System Design.

1. Философия Doc-as-Code

Традиционный подход к документации (Word, PDF, разрозненные страницы в Confluence) имеет фатальный недостаток: документация отрывается от кода. Код ушел вперед, фича изменилась, а ТЗ осталось старым. Это называется «протухание документации».

Doc-as-Code (Документация как код) — это подход, при котором к написанию документации применяются те же инструменты и процессы, что и к разработке программного обеспечения.

Основные принципы

Единый источник правды: Документация хранится в системе контроля версий (Git) рядом с кодом сервиса или в специальном репозитории.

Текстовые форматы: Используются легкие языки разметки (Markdown, AsciiDoc, reStructuredText), а не бинарные файлы (.docx).

Диаграммы как код: PlantUML, Mermaid, Structurizr (мы изучали это в первом модуле).

Автоматизация: Сборка статического сайта с документацией происходит автоматически через CI/CD пайплайны.

Code Review: Изменения в документацию вносятся через Pull Request. Коллеги проверяют описание так же, как проверяют код.

!Визуализация жизненного цикла документации в подходе Doc-as-Code: от написания в Markdown до публикации через CI/CD.

Инструментарий аналитика

Чтобы внедрить этот подход, вам понадобится следующий стек:

* IDE: VS Code или IntelliJ IDEA (писать текст удобнее в редакторе кода с плагинами). * Git: Для версионирования (commit, push, merge). * Генераторы статических сайтов (SSG): * MkDocs: Самый популярный инструмент для Python-стека. Прост в настройке, использует Markdown. * Docusaurus: Мощный инструмент от Facebook на React. * Hugo: Очень быстрый генератор на Go.

Почему это выгодно аналитику?

История изменений: Вы всегда видите, кто, когда и почему* изменил требование (спасибо git blame). * Синхронизация: Если разработчик меняет API, он видит файл документации в том же репозитории и может (или обязан) обновить его в том же коммите. * Качество: Процесс Review позволяет отловить логические ошибки до того, как они уйдут в разработку.

2. Секция System Design: Ваш главный экзамен

System Design (SD) интервью — это стандарт проверки навыков для Middle+ и Senior специалистов. Вам дают абстрактную задачу (например, «Спроектируйте аналог Telegram») и 45–60 минут времени.

Ваша цель — не выдать единственно верное решение (его не существует), а показать структурное мышление.

Структура ответа (Framework)

Чтобы не запаниковать, используйте проверенный алгоритм. Я рекомендую подход RADIO или его вариации.

#### Шаг 1: Уточнение требований (Requirements Clarification) — 5-7 минут

Никогда не бросайтесь рисовать квадратики сразу. Задавайте вопросы.

* Функциональные требования: Что система должна делать? (Отправлять сообщения, создавать группы, звонить?) * Нефункциональные требования: Сколько пользователей? Какая задержка допустима? Нужна ли история переписки навсегда? * Ограничения: Бюджет, сроки, технологии.

#### Шаг 2: Оценка нагрузки (Capacity Planning) — 5 минут

Здесь нужна математика. Вам нужно прикинуть, сколько серверов и дисков понадобится. Не нужны точные числа, нужны порядки.

Допустим, мы проектируем мессенджер. * DAU (Daily Active Users): 10 миллионов. * Каждый пишет 10 сообщений в день. * Средний размер сообщения: 1 КБ.

Рассчитаем объем хранилища за год:

где — объем данных за год, — количество пользователей (10 млн), — сообщений на пользователя (10), — размер сообщения (1 КБ), — количество дней (365).

Вывод: 36.5 ТБ — это много для одной базы данных, нам точно понадобится шардирование или кластер NoSQL.

#### Шаг 3: Высокоуровневая архитектура (High-Level Design) — 10-15 минут

Нарисуйте основные компоненты (квадратики): * Клиент (Mobile/Web). * Load Balancer (Балансировщик). * API Gateway. * Сервисы (Auth Service, Chat Service, Notification Service). * Базы данных.

На этом этапе важно показать потоки данных стрелками.

!Пример высокоуровневой архитектуры мессенджера для этапа High-Level Design.

#### Шаг 4: Детальное проектирование (Deep Dive) — 10-15 минут

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

Здесь вы применяете знания из модуля про базы данных: * SQL или NoSQL? (Для чата лучше NoSQL типа Cassandra или HBase из-за скорости записи). * Схема данных (Partition Key = ChatID, Sort Key = Timestamp). * API контракты (REST или WebSocket?).

#### Шаг 5: Поиск узких мест (Bottlenecks & Scaling) — 5 минут

Посмотрите на свою схему критически. * Что будет, если упадет база данных? (Нужна репликация). * Что если Джастин Бибер создаст канал и напишет сообщение для 100 млн подписчиков? (Проблема Fan-out, нужно асинхронное решение через очереди).

3. Типовые ошибки на интервью

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

«Серебряная пуля». Не пытайтесь вставить Kafka и Kubernetes везде, где только можно. Если задача — сделать блог для 100 человек, монолит на PHP будет лучшим решением, чем микросервисы.

Игнорирование NFR. Если вы спроектировали систему, которая функционально работает, но падает под нагрузкой или отвечает 10 секунд — вы не прошли.

4. Как Doc-as-Code помогает на интервью?

Практика Doc-as-Code приучает вас к структурированности. Когда вы пишете документацию в Markdown и рисуете диаграммы в PlantUML, вы учитесь:

Декомпозировать сложные системы на простые блоки.

Четко формулировать контракты взаимодействия (Sequence Diagrams).

Видеть систему как набор компонентов, а не как черный ящик.

На интервью, когда вас попросят нарисовать схему на маркерной доске или в онлайн-редакторе (Excalidraw), навыки PlantUML помогут вам быстро структурировать визуализацию в голове.

Заключение курса

Мы прошли большой путь в рамках курса System Analysis Pro.

* Мы начали с того, как превращать хаос желаний заказчика в строгие требования. * Научились моделировать данные в SQL и NoSQL. * Разобрали, как связывать системы через REST, gRPC и Kafka. * Поняли, как строить микросервисную архитектуру. * И, наконец, узнали, как это все документировать и защищать на интервью.

Системный анализ — это не просто написание ТЗ. Это проектирование будущего цифрового мира. Теперь у вас есть все инструменты, чтобы делать это профессионально. Удачи на проектах и собеседованиях!