🏦 Capital - архитектура продакшен-инфраструктуры

Версия 1.0 - 15.09.2026 - CTO-план Продукт: core-banking платформа Capital (bo. / app. / kyc. algorys.cc) Подготовлено: CTO (Claude) по итогам совета с внешними консультантами (Grok reasoning + GPT), референс - платформа Iorys.

1. 📌 Резюме для CEO

Продукт функционально готов (183 автотеста, AML/KYT, 4-eyes, 2FA, аудит), но инфраструктура - стартаперская: всё живёт на одном шаредном сервере вместе с Nextcloud, и у базы данных нет ни одного бэкапа. Любой отказ диска = полная потеря банка.

Целевое состояние достижимо за ~2-4 рабочих дня критики + месяц доводки, бюджет ~$60-80/мес (профи-вариант ~$130-150/мес). Ни один компонент не стоит «тысячи долларов».

Три главных решения: 1. 🖥 Capital переезжает на собственный выделенный сервер (team-nextcloud остаётся файловым сервером команды - его не трогаем). 2. 💾 Бэкапы прежде всего: pgBackRest + WAL-архивация в два независимых хранилища, шифрование age, автоматический еженедельный restore-тест. RPO ≤ 5 минут. 3. 📈 Мониторинг + staging + CI/CD-деплой - чтобы выглядеть и работать как банк, а не как pet-проект.

2. 🔍 Текущее состояние (as-is) и точки отказа

3. 🗺 Целевая топология (to-be)

                        Интернет
                           |
                 [Cloudflare: WAF/proxy/tunnel]
                    (2 connector'а cloudflared)
                           |
        +------------------+------------------+
        |                                     |
  🖥 capital-prod (Hetzner, NEW)        🖥 capital-ops (Hetzner, NEW)
  CCX23: 4 vCPU ded / 16GB / 160GB      CX22 + volume 100GB
  - backoffice / cabinet / kyc          - staging (тот же compose, throwaway-БД)
  - Postgres 16 (WAL-архивация)         - Uptime Kuma (внешний надзор за prod)
  - pgBackRest (клиент)                 - pgBackRest repo-зеркало + restore-тест
  - Netdata, node-alerts → Telegram     - Netdata
        |                                     |
        +----------- бэкапы (age) ------------+
                           |
        ☁️ Backblaze B2 (EU, Object Lock/WORM)   - копия №1 off-site
        ☁️ Hetzner Storage Box 1TB               - копия №2 off-site
                           |
        team-nextcloud - ОСТАЁТСЯ как файл-сервер команды.
        Capital с него уезжает целиком (переезд = первый DR-тест).

Принципы распределения рисков: - Prod и ops/staging - разные серверы в разных дата-центрах Hetzner (Nuremberg / Falkenstein). - Бэкапы - в двух независимых хранилищах у двух разных провайдеров (B2 + Storage Box), обе копии зашифрованы age, ключ расшифровки НЕ на prod-сервере. - Мониторинг prod живёт НЕ на prod (ops-сервер видит падение prod снаружи). - HA-кластер (Patroni и т.п.) сейчас НЕ нужен - на нашем масштабе правильнее быстрый DR (восстановление ≤ 2-4 ч), это в 10 раз дешевле и проще. - Managed Postgres не берём: дороже, меньше контроля для аудита; self-hosted + PITR на этом масштабе надёжнее по цене/качеству (консенсус обоих консультантов).

4. 🗄 Хранение данных

Postgres-настройки банковского уровня: wal_level=replica, archive_mode=on, wal_compression, archive_command → pgBackRest; контрольная запись LSN перед каждой миграцией.

5. 💾 Бэкапы и Disaster Recovery (правило 3-2-1)

Инструменты: pgBackRest (БД) + restic (конфиги/файлы), всё шифруется age.

Целевые показатели: RPO ≤ 5 минут (теряем максимум 5 минут данных), RTO ≤ 2-4 часа (полное восстановление банка на новом сервере).

Restore-тест - автоматический, еженедельный: ops-сервер разворачивает бэкап в изолированный контейнер, проверяет pg_isready + контрольные суммы ключевых таблиц, шлёт отчёт в Telegram. Бэкап, который не восстанавливали, - это не бэкап.

DR-ранбук (документируется в репо): заказ нового сервера → restore из B2 → deploy образов из GHCR → перевод Cloudflare tunnel → смоук-тест. Прогоняем учения раз в квартал.

Мониторинг бэкапов: каждая джоба пингует Healthchecks.io - если бэкап НЕ прошёл, алерт в Telegram (отсутствие сигнала = тревога, а не тишина).

6. 📈 Мониторинг и алертинг (всё бесплатное)

Все алерты - в Telegram, три канала: 🔴 critical (будим CEO), 🟠 warning, 🔵 backup/report. Внешняя status-page (BetterStack free / GitHub Pages) - вне Cloudflare, чтобы работала даже при падении CF.

7. 🔐 Безопасность (поверх уже сделанного)

1. Hardening-стандарт группы на оба новых сервера с первого часа: SSH только через Tailscale, ufw deny inbound, fail2ban, unattended-upgrades, Telegram-алерт на SSH-вход (с анти-спамом), порты приложений только на 127.0.0.1, Docker без privileged.
2. Секреты: sops + age (конфиги в git зашифрованы, расшифровка только на серверах); значения впрыскиваются оператором мимо чата - как заведено.
3. CI-сканеры (все бесплатные): gitleaks (секреты в коммитах), Trivy (уязвимости образов), Dependabot (зависимости), CodeQL.
4. Доступы: GitHub - protected main + обязательная 2FA; Tailscale ACL - prod видит только CEO и деплой-ключ; ревизия доступов раз в квартал.
5. Incident Response план (короткий документ): кто, что, в каком порядке при инциденте: изоляция → оценка → восстановление → пост-мортем → уведомления клиентам.
6. Внешний pentest - 1 раз в год (~$2-3.5k разово, закладываем в бюджет квартала, обязателен перед активными продажами и для партнёров/регуляторов).
7. Graceful degradation при отказе партнёров (частично уже в коде): rail недоступен → платёж в pending_partner, клиент видит «принят, в обработке», ledger не финализируется; SumSub упал → заявка сохраняется draft; Resend упал → email-очередь с ретраями. Клиент никогда не видит ошибку 500 вместо статуса.

8. 🚀 Деплой-пайплайн (уходим от rsync)

git push → GitHub Actions: тесты (183) + сканеры → сборка образов → GHCR
  → авто-деплой на staging (ops) → смоук-тест
  → ручное подтверждение → деплой на prod (docker compose pull && up -d)

• Rollback = откат на предыдущий образ (храним 5 последних в GHCR) - секунды.
• Миграции - строго expand/contract: сначала совместимая миграция, потом код, деструктивные изменения - отдельным релизом позже. Перед миграцией - автоматический чекпоинт бэкапа + запись LSN (можно PITR ровно к моменту «до»).
• Staging - обязателен (на ops-сервере, throwaway-БД): каждый релиз сначала живёт там. Стресс/security-тесты - только на staging (стандарт группы).
• Kоротое окно (5-15 сек) при рестарте compose на пилоте приемлемо; blue-green - в квартале 1.

9. 🧯 Матрица отказов

10. 🗓 Roadmap внедрения

Неделя 1 - «перестать жить без бэкапов» (2-4 рабочих дня)

1. Заказать capital-prod + capital-ops (Hetzner API), hardening с первого часа.
2. pgBackRest + WAL → B2 + Storage Box, age-шифрование, Healthchecks-пинги.
3. Переезд Capital на capital-prod (по сути - первый DR-тест: restore из бэкапа).
4. Uptime Kuma + Netdata + Telegram-алерты.
5. Первый ручной restore-тест - убедиться, что восстановление реально работает.

Месяц 1 - «профессиональная база» (1-2 недели работ)

6. GitHub Actions CI/CD + GHCR + staging на ops.
7. sops + age для секретов; сканеры gitleaks/Trivy/Dependabot в CI.
8. Sentry + автоматический еженедельный restore-тест.
9. Миграция документов из BLOB → B2; второй cloudflared connector.
10. DR-ранбук + первые учения; IR-план; hash-chain аудита + WORM-дайджесты.

Квартал 1 - «зрелость» (3-5 недель суммарно)

11. Blue-green деплой, status-page, второй email-провайдер (резерв).
12. Квартальные DR-учения + security tabletop.
13. Внешний pentest (перед активными продажами).
14. Формальный risk-register + политики (backup/retention/access/change) - партнёры и регуляторы такое спрашивают.

11. 💰 Бюджет

Базовый (рекомендую стартовать с него)

Профи-апгрейд (когда пойдут клиенты)

Разовые: внешний pentest ~$2-3.5k/год (квартал 1+).

12. 🤝 Что нужно от CEO

1. 🔑 Hetzner API token (проект для Capital) - закажу и настрою оба сервера сам, мимо UI.
2. 🔑 Backblaze B2 - аккаунт (или создаём новый), ключ сгенерирую на стороне сервера мимо чата.
3. ✅ Утвердить бюджет (~$52-55/мес база) и переезд prod на выделенный сервер.
4. 💳 (Отдельный трек) Оплата инвойсов Papaya и NS Cards - для флипа симуляторов на live.
5. 🔒 Age-ключ восстановления бэкапов - сгенерирую, приватная половина хранится у CEO (не на серверах): без него бэкапы не расшифровать, с ним банк восстанавливается даже при потере всего.

13. 📎 Приложение: сводка мнений консультантов

Оба консультанта независимо назвали одни и те же топ-риски: нет бэкапов → нет restore-тестов → прод смешан с Nextcloud → ручной деплой → нет мониторинга. Это и есть порядок работ.