ТЗ на инфраструктуру: три уровня надёжности

Три варианта: стоимость, восстановление и сохранность

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

Варианты описывают этапы резервирования модульного монолита. Переход требует проверить общие файлы, фоновые задачи, подключение к БД и переключение. Исходный анализ предлагал старт со второго варианта; текущий выбор для проверки продукта — MTN по базовой схеме. Это не отменяет приёмку требования сохранности данных.

Состав по вариантам (прод + staging)

Общие требования для всех вариантов

• Регион — Африка; все копии данных (БД, реплики, бэкапы, фото, логи) — в Африке.
• Диски — SSD; для БД ≥ 3 000 IOPS (вариант 1) и ≥ 6 000 IOPS, ≥ 200 МБ/с (варианты 2–3).
• Исходящий доступ к Paystack, провайдеру карт и AirLabs; входящие вебхуки Paystack по HTTPS.
• S3-совместимое объектное хранилище с версионированием и запретом удаления (Object Lock).
• ОС Ubuntu 24.04 LTS; прод не делит серверы и БД с другими проектами.

Расчёт нагрузки

Для расчётного сценария принимаем ≈ 160 одновременных поездок. Загрузка 80% по часам сама по себе не определяет пик. Синтетический демо-месяц дал ориентир 3,7 заказа на машину в сутки при 66% загрузки; пересчёт до ≈ 4,5 при 80% и ≈ 900 заказов в сутки — предположение модели. Пиковый час ≈ 100 заказов (среднее × 2,5) нужно подтвердить профилем пилота и испытанием.

Плановая модель: ≈ 70 записей и ≈ 800 простых чтений БД в секунду, WAL ≈ 0,5 МБ/с. Цель нагрузочного испытания с запасом ×3: 750 RPS, 1 000 WebSocket, 2 400 чтений/с. Способность 4 vCPU выдержать этот профиль и предел масштабирования по числу машин ещё не измерены.

Один заказ на бэкенде

Исходная оценка базовой поездки: около 10 событий, 50–70 строк доставки уведомлений, 4–6 переводов в учёте (≈ 20 строк), ≈ 60 HTTP-запросов. Продления, сообщения, координаты, повторы и сбои добавляют операции; подписка и чаевые имеют отдельные циклы. Эти числа не заменяют трассировку текущей ревизии и замер нагрузки.

Доработки кода, обязательные для всех вариантов

1. Исключить телеметрию из журнала заказа — иначе ≈ 1,4 млн неудаляемых строк в сутки (≈ 250 ГБ в год).
2. Хранение уведомлений 30 дней и потолок повторов — сейчас notify.* растёт бесконечно.
3. Пул соединений к БД 25–30 вместо 10.
4. Свой OSRM и платный провайдер тайлов: в проде нет маршрутизации, а публичные тайлы OSM запрещены правилами.
5. Проверить на принимаемой ревизии защиту повторов создания заказа и платежей. Она уже реализована локально; настоящий Paystack sandbox ещё не подтверждён.

Что добавляется для вариантов 2 и 3 — в их вкладках.

Прототип: всё на одном сервере

Исходная схема для проверки продукта: приложение, база и маршруты на одной VM, копии — вне неё. Цель восстановления — 2–4 часа; объём возможной потери зависит от реально доставленных копий WAL и проверяется учениями. Сверка Paystack помогает найти внешнюю оплату, но не восстанавливает содержание потерянного заказа. Пока приёмка не пройдена, схема не подтверждает выполнение требования нулевой потери заказов и оплат.

Подходит: пилот с одним-двумя парками, первые недели. Не подходит: договоры с отелями и агентствами с гарантиями доступности.

Схема

flowchart LR
  U([Клиенты, водители, парки]) -->|HTTPS, WebSocket| P
  PS([Paystack]) -->|вебхуки| P
  subgraph R1[Регион 1, Африка]
    P[prod-1
nginx · parkmanager
PostgreSQL · OSRM]
    S[staging-1
тестовая копия]
  end
  subgraph R2[Регион 2, Африка]
    B[(S3: WAL каждые 60 с
ночной бэкап · Object Lock)]
  end
  P -->|архив WAL, бэкап| B
  M([Внешний мониторинг]) -.->|/healthz раз в минуту| P
      

Спецификация

Что нужно от площадки

• VM с гарантированными ядрами (не burstable) и SSD с заявленными IOPS.
• Ежедневные снапшоты диска prod-1 (если доступны), хранение 7 дней.
• S3-совместимое хранилище во втором регионе или ДЦ в Африке.
• Исходящий доступ к Paystack, AirLabs, провайдеру карт; входящий HTTPS для вебхуков Paystack.
• Ubuntu 24.04 LTS; DNS-записи для поддоменов order. driver. fleet. partner. admin. auth.

Минимально допустимо держать staging на prod-1 — отдельной БД и отдельным сервисом с лимитами памяти, процессора и диска. Без лимитов тест может положить прод: так уже было на текущем сервере.

Что проверить по нагрузке

≈ 250 RPS — расчётный профиль, не измеренная загрузка CPU. План распределения 16 ГБ: shared_buffers 4 ГБ, OSRM 4–6 ГБ, приложение ≈ 1 ГБ, остаток — кэш ОС. Реальный размер карты Нигерии, рабочий набор БД и запас памяти нужно измерить. Оценка диска: ≈ 65 ГБ данных к концу года плюс WAL, индексы и запас ×2; её проверяют по скорости роста данных.

Цели и механизмы приёмки

Ручные процедуры

Алерты

Сервер недоступен · диск > 75% · не прошёл архив WAL или ночной бэкап. В Telegram.

Настройки

nginx: Upgrade/Connection для WebSocket, proxy_read_timeout 120s, тело до 10 МБ. Пул приложения 25–30. Обязательные доработки кода — во вкладке «Сравнение», блок 3.

Умеренная надёжность: реплика базы и ручной разбор платежей

База размещается на двух серверах в разных зонах с переключением при отказе. Асинхронная репликация допускает потерю последних записей; такая схема не выполняет безусловное требование нулевой потери заказов. Приложение остаётся одним узлом. Срок восстановления и частота ручного разбора платежей подтверждаются испытаниями и эксплуатацией, а не этой оценкой.

Подходит: коммерческий запуск и первые месяцы роста.

Схема

flowchart TB
  U([Пользователи и вебхуки Paystack]) -->|HTTPS · WebSocket| LB[L7-балансировщик · managed · TLS]
  LB --> APP
  subgraph ZA[Зона A · регион 1]
    APP[app-1
parkmanager · OSRM]
    PG1[(PostgreSQL мастер)]
  end
  subgraph ZB[Зона B · регион 1]
    PG2[(PostgreSQL реплика)]
    OPS[ops-1 · мониторинг · бэкапы · сверки]
  end
  APP --> PG1
  PG1 ==>|репликация · автопереключение| PG2
  APP --> MEDIA[(S3: фото)]
  APP --> NAT[NAT-шлюз · статический IP]
  NAT --> EXT([Paystack · карты · AirLabs])
  OPS --> BK[(Регион 2 · S3 бэкапы · Object Lock)]

Спецификация

Сеть

• Балансировщик → app-1: TCP 8300. app-1 → PostgreSQL: 6432 (TLS). ops-1 → app-1: метрики.
• Исходящий трафик app-1 — только через NAT-шлюз.
• Прод и staging — разные сети без связности.

Почему так

• Управляемая БД на 2 хостах защищает от части отказов; асинхронная реплика может потерять последние записи. Цели переключения ≤ 5 мин и PITR 14 дней нужно подтвердить поставщиком и испытаниями.
• Асинхронная реплика может отставать. Сверка с Paystack помогает найти внешний платёж, но не восстанавливает потерянные параметры заказа. При синхронной схеме запись может остановиться без реплики; выбор доступности и сохранности требует явного решения. Поведение конкретного управляемого сервиса нужно подтвердить.
• Один сервер приложения: целевой срок пересоздания из образа ≤ 30 мин проверяется учениями. Балансировщик позволяет заменить backend без смены DNS.
• Фото в S3 — обязательно: локальный диск app-1 пропадёт вместе с ним.

Целевой регламент ручного разбора оплат

Кнопки ниже — требование к будущему рабочему месту, не подтверждение реализованного экрана. Неизвестный исход оплаты не приравнивается к отказу или отмене.

Частота случаев и время ручного разбора пока не измерены; штат сопровождения и SLA нельзя рассчитывать как на подтверждённые «единицы случаев в месяц».

Алерты

/healthz · 5xx > 1% за 5 мин · переключение мастера · отставание реплики > 30 с · диск > 75% · не прошёл ночной бэкап · оплата pending > 30 мин · расхождение ежечасной сверки.

Доработки кода сверх общих

1. Админ-экран «проблемные оплаты и заказы» с кнопками из регламента.
2. Ежечасная сверка бухгалтерии (billing.Reconcile уже написан, не вызывается) и ежедневная сверка с выпиской Paystack.
3. Фото в объектное хранилище; подключение к БД по имени кластера с переподключением.
4. Образ и конфигурация app-1 кодом (Terraform или скрипт).

Энтерпрайз: ни одного потерянного заказа и платежа

Приложение и база дублируются по зонам. Цель — сохранить подтверждённый заказ и внутреннюю запись платежа при покрываемом отказе узла или зоны: нужны синхронная репликация и безопасное переключение лидера. Переключение базы может прервать приём запросов. Отказ всего региона, результат внешней оплаты и восстановление зависших операций проверяются отдельно; копии во втором регионе сами по себе не дают RPO=0.

Назначение: договоры с проверенным SLA. Сценарий роста до 1 000+ машин требует отдельного измерения и не является подтверждённым пределом этой конфигурации.

Схема

flowchart TB
  U([Пользователи и вебхуки Paystack]) -->|HTTPS · WebSocket| LB[L7-балансировщик · 3 зоны · TLS]
  LB --> A1
  LB --> A2
  subgraph ZA[Зона A · регион 1]
    A1[app-1
parkmanager · OSRM]
    P1[(pg-1 мастер)]
  end
  subgraph ZB[Зона B · регион 1]
    A2[app-2
parkmanager · OSRM]
    P2[(pg-2 реплика)]
  end
  subgraph ZC[Зона C · регион 1]
    P3[(pg-3 реплика)]
    OPS[ops-1 · мониторинг · бэкапы]
  end
  A1 --> P1
  A2 --> P1
  P1 ==>|синхронно| P2
  P1 ==>|синхронно| P3
  A1 --> NAT[NAT-шлюз · статический IP]
  A2 --> NAT
  NAT --> EXT([Paystack · карты · AirLabs])
  OPS --> BK[(Регион 2 · S3 бэкапы · WORM)]

Спецификация

Сеть и доступы

• Одна VPC на окружение, подсети в каждой зоне; прод и staging без связности.
• Правила: балансировщик → app 8300; app → pg 6432 (TLS); ops → app метрики; ops → реплика pg; bastion → всё 22; остальное запрещено.
• Публичные IP — только у балансировщика, NAT-шлюза и bastion.
• Секреты — в менеджере секретов облака; удаление кластера БД и бакета бэкапов — только с двумя подтверждениями.
• DNS у управляемого провайдера, TTL 60 с, CAA-запись.

SLO

Почему каждый узел

• 3 хоста БД позволяют спроектировать синхронную запись при недоступности одной реплики. Нужно подтвердить независимость зон, правила подтверждения записи, безопасного выбора лидера и защиты от двух лидеров; read-реплика сама по себе не доказывает эту схему.
• Каждый app-сервер должен выдерживать 100% профиля — проверить нагрузку оставшейся копии при отказе второго узла.
• Балансировщик managed — своя VM-балансировщик сама стала бы единой точкой отказа.
• Бэкапы в другом аккаунте с WORM — защита от ошибки человека и компрометации аккаунта, а не только от отказа железа.
• ops-1 отдельно — его отказ не влияет на приём заказов.

Доработки кода — без них железо не даёт RPO = 0

1. Статус, деньги и обязательное событие — в одной транзакции; этот механизм реализован в текущем рабочем дереве. При выпуске нужна проверка конкретной ревизии, а не повторное обещание будущей разработки.
2. Защита повторов создания заказа и пополнения реализована локально; проверить конкурентные запросы и настоящего провайдера на стенде приёмки.
3. Вебхук Paystack: записать → ответить 200 → обработать задачей River; сверка pending-платежей раз в несколько минут.
4. «Дворник»: completed без расчёта, удержание без назначения, резерв без заказа — доводятся автоматически; ежечасная сверка бухгалтерии и с Paystack.
5. Выбор лидера (advisory lock) для одиночных тиков: статусы водителей, аренда, симулятор.
6. Фото в S3; обратно совместимые миграции (expand → deploy → contract).
7. Тесты на сбои: падение процесса на каждом шаге и повтор запроса → ровно один заказ и одно списание.

Процессы

• Деплой: GitHub Actions → staging автоматически → smoke-тесты → ручное подтверждение → прод по одному серверу; откат ≤ 5 мин.
• Учения: восстановление бэкапа — раз в месяц автоматически; переключение мастера и выключение app-сервера — раз в квартал.
• Алерты 24/7: /healthz, 5xx > 1%, p95 выше SLO, отставание реплики > 10 с или потеря кворума, диск > 75%, не прошёл бэкап, расхождение сверки, pending > 15 мин, застрявшие заказы, неподтверждённые критичные уведомления.

Размещение данных: выбранный старт и подтверждения

Для старта выбран MTN в Нигерии. Географию основных данных, фотографий, журналов и всех резервных копий нужно подтвердить поставщиком и юристом. Azure в ЮАР ниже — историческая альтернатива из анализа 2 октября, не текущая рекомендация и не доказательство уже обеспеченного хранения.

Кандидаты

Историческая таблица из исходного анализа 2 октября. Число зон, свойства управляемых БД и задержки заново не проверены; для закупки она не заменяет подтверждение поставщика. Выбранный старт — MTN в Нигерии. Основной и резервный регионы и правила хранения данных согласуются отдельно.

Требования к площадке

• Все копии данных — в Африке: БД, реплики, бэкапы, фото, логи, снапшоты дисков.
• Исходящий доступ к Paystack и входящие вебхуки Paystack (с текущей российской площадки доступа нет — проверено).
• Для варианта 3 — три зоны доступности в регионе; для вариантов 2–3 — второй регион или ДЦ под бэкапы.
• Договор обработки данных (DPA) с провайдером.

Историческая альтернатива: Azure

• В исходном сравнении рассматривалось облако с несколькими африканскими регионами и зонами. Состав регионов и свойства конкретных сервисов перед заказом нужно проверить заново; это не актуальный каталог поставщиков.
• Прежняя оценка задержки ЮАР → Лагос 90–130 мс не является измерением p95 API. Проверять нужно полный путь с сетевой задержкой и обработкой запроса.
• Свойства синхронного standby, ограничения переключения и область RPO=0 требуют подтверждения выбранного сервиса. Для старта сейчас выбран MTN в Нигерии.

Если закон потребует хранить данные в Нигерии

Облака из ЮАР отпадают. Вариант 3 строится в двух ДЦ Лагоса и одном в Абудже: PostgreSQL на Patroni с синхронной репликацией (3 VM), свой балансировщик в паре (keepalived), S3-совместимое хранилище ДЦ или MinIO. Задержка лучше (5–20 мс), но эксплуатация заметно дороже и требует своего дежурства.