Управление рисками проекта¶

Оглавление¶

Исходные условия (фактическая база)
Модель рисков по этапам продукта
Реестр рисков (фактические сценарии)
Механизмы реагирования на инциденты
Связь рисков с этапами MVP → версия
Вывод

1. Исходные условия (фактическая база)¶

Управление рисками формируется на основе текущей архитектуры и эксплуатационного состояния системы.

Проект реализован как микросервисная платформа, включающая сервисы auth, user, product, order, review, admin, chat, а также frontend-приложение и Telegram-бот. Серверная часть построена на Django/DRF, взаимодействие осуществляется через REST API.

Развёртывание выполняется с использованием Docker Compose (основной контур — docker-compose.services.yml), при этом для production-окружения подготовлен отдельный конфигурационный файл и runbook.

Ключевые инфраструктурные особенности:

используется один экземпляр PostgreSQL (без репликации);
используется один Redis (broker для Celery);
асинхронная обработка реализована через Celery (order_celery);
CI включает smoke-тесты API и frontend;
присутствуют runbook: деплой, проверка состояния, backup/restore;
отсутствует единый OpenAPI-контракт;
отсутствует полноценный observability-стек (метрики, алерты, SLO).

Таким образом, система имеет базовый уровень инженерной зрелости, но сохраняет критические архитектурные и операционные риски, характерные для стадии MVP.

2. Модель рисков по этапам продукта¶

Риски анализируются с учётом стадии развития продукта:

Прототип — допускаются ошибки и ручные операции, основная цель — проверка идеи;
MVP — критично обеспечить работоспособность базового пользовательского сценария;
Версия — требуется стабильность, управляемость и предсказуемость поведения системы.

Ключевой пользовательский сценарий проекта:

регистрация → авторизация → каталог → карточка → корзина → оформление заказа

Нарушение данного сценария рассматривается как критический риск независимо от этапа.

3. Реестр рисков (фактические сценарии)¶

В рамках текущей архитектуры выделены следующие основные риски.

3.1 R1 — Падение PostgreSQL (критический SPOF)¶

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

Вероятность оценивается как высокая, поскольку риск обусловлен самой архитектурой (single instance). Влияние — максимальное: полный отказ системы.

Метрики риска:

доступность БД (uptime);
количество HTTP 5xx;
длительность простоя.

Управление риском реализуется через:

снижение: регулярные резервные копии (pg_dump), проверка восстановления;
контроль: health-check и pre-release проверки.

Время реакции:

обнаружение — 5–15 минут;
восстановление — 30–120 минут.

3.2 R2 — Падение Redis и деградация асинхронной обработки¶

Redis используется как broker Celery, обеспечивая выполнение фоновых задач, связанных с заказами. При его отказе нарушается обработка очередей, увеличивается время выполнения операций, часть сценариев переходит в fallback.

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

Метрики:

длина очереди;
время обработки заказа;
доля fallback-сценариев.

Стратегия — снижение:

использование синхронного fallback;
контроль состояния очередей;
перезапуск воркеров.

Время восстановления — 10–30 минут.

3.3 R3 — Рассинхронизация API-контрактов (frontend ↔ backend)¶

Отсутствие единого machine-readable контракта (OpenAPI) приводит к расхождению между frontend и backend. Это выражается в ошибках интерфейса, некорректной работе форм и нарушении пользовательских сценариев.

Вероятность — средняя (активное развитие системы). Влияние — частичное или полное нарушение функциональности UI.

Метрики:

количество 4xx ошибок после релиза;
число интеграционных инцидентов;
количество hotfix.

Стратегия:

избегание: дисциплина документирования API;
контроль: CI smoke-тесты и code review.

Время реакции:

обнаружение — 5–30 минут;
исправление — 1–4 часа.

3.4 R4 — Каскадные регрессии из-за связности сервисов¶

Использование общей базы данных и межсервисных зависимостей увеличивает вероятность каскадных ошибок. Изменение одной модели или endpoint может затронуть несколько сервисов.

Вероятность — высокая. Влияние — нарушение комплексных сценариев (например, product → order → review).

Метрики:

количество межсервисных дефектов;
частота rollback.

Стратегия — снижение:

контрактные проверки;
фиксация архитектурных решений (ADR);
контроль изменений.

Время устранения:

локализация — 1–2 часа;
полный фикс — до 24 часов.

3.5 R5 — Ошибки деплоя (ручной процесс)¶

Деплой осуществляется через runbook и Docker Compose, без полного CI/CD. Это создаёт риск ошибок конфигурации, пропуска миграций и частичных обновлений.

Вероятность — средняя. Влияние — нестабильность после релиза.

Метрики:

количество неуспешных релизов;
частота rollback;
post-release инциденты.

Стратегия — снижение и контроль:

preflight-проверки;
чек-листы;
обязательный smoke после релиза.

Время стабилизации — 15–60 минут.

3.6 R7 — Сбой критического пользовательского сценария¶

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

Вероятность — средняя. Влияние — критическое (потеря конверсии, невозможность завершения заказа).

Метрики:

success rate сценария;
процент успешных checkout;
ошибки на этапах.

Стратегия:

контроль: post-release проверки;
снижение: приоритетный hotfix.

Время реакции:

обнаружение — 5–30 минут;
исправление — 1–3 часа.

3.7 R8 — Недостаточная наблюдаемость системы¶

Отсутствие полноценного мониторинга и алертинга приводит к позднему обнаружению инцидентов.

Вероятность — средняя. Влияние — увеличение времени реакции (MTTR).

Метрики:

MTTD (время обнаружения);
MTTR (время восстановления);
доля инцидентов, выявленных пользователями.

Стратегия — снижение:

внедрение метрик;
централизованный дашборд;
алерты.

3.8 R9 — Потеря данных между backup-окнами¶

Несмотря на наличие резервного копирования, не зафиксированы точные значения RPO/RTO.

Вероятность — средняя. Влияние — потеря пользовательских данных и заказов.

Метрики:

фактический RPO;
успешность восстановления.

Стратегия:

контроль: регулярные backup + тест restore;
принятие: допустимая потеря данных фиксируется.

Время восстановления — 30–180 минут.

3.9 R10 — Риски использования ИИ в разработке¶

Использование ИИ без строгого контроля может приводить к логическим ошибкам и нестабильности системы.

Вероятность — средняя. Влияние — рост дефектов и снижение качества кода.

Метрики:

количество дефектов после merge;
доля AI-изменений без замечаний.

Стратегия:

избегание: запрет auto-merge;
контроль: обязательный code review.

4. Механизмы реагирования на инциденты¶

Система предполагает заранее определённые сценарии восстановления.

При полном отказе сервера выполняется диагностика состояния контейнеров и перезапуск Docker-окружения. Обнаружение инцидента происходит в течение 5–15 минут, восстановление — до 1 часа.

При отказе базы данных используется восстановление из резервной копии. Потери данных ограничиваются интервалом backup (RPO), а время восстановления (RTO) составляет до 180 минут.

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

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

5. Связь рисков с этапами MVP → версия¶

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

Переход к версии продукта возможен при достижении следующих показателей:

успешность пользовательского сценария >= 90%;
уровень ошибок <= 5%;
наличие завершённых пользовательских действий (заказы, регистрации);
стабильное время обработки операций.

Таким образом, риски становятся инструментом оценки готовности продукта, а не только источником угроз.

6. Вывод¶

Анализ показал, что ключевые риски проекта связаны с архитектурными ограничениями (SPOF), межсервисной связностью и операционными процессами.

При этом наличие runbook, CI-проверок и базового контроля позволяет не только фиксировать риски, но и управлять ими. Основными направлениями развития являются устранение точек отказа, внедрение мониторинга и стандартизация API-контрактов.

Реализация этих мер позволит перевести систему из состояния MVP в стабильную эксплуатационную версию с контролируемым уровнем риска.