Инструкция по поддержке и жизненному циклу платформы FT-Pay (ФТ-Пэй)

ЧАСТЬ 1. ЭКСПЛУАТАЦИОННЫЕ ХАРАКТЕРИСТИКИ СИСТЕМЫ

1.1. Назначение Системы

Программное обеспечение «Платформа интернет-эквайринга FT-Pay (ФТ-Пэй)» (далее — Система) предназначено для автоматизации процессов приема платежей, проведения массовых выплат, каскадирования и маршрутизации транзакций, финансового учета (биллинга) мерчантов, а также обеспечения безопасности платежного трафика с использованием встроенных инструментов антифрод-мониторинга.

1.2. Требования к программно-аппаратной среде

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

1.2.1. Минимальные системные требования к серверному оборудованию (на одну ноду):

  • Процессор (CPU): Архитектура x86-64, не менее 4 ядер с базовой частотой от 2.4 ГГц.
  • Оперативная память (RAM): Не менее 16 ГБ.
  • Дисковая подсистема (ROM): Не менее 100 ГБ доступного дискового пространства на быстрых накопителях (SSD или NVMe) с поддержкой конфигурации RAID-массивов для избыточности данных.
  • Сетевой интерфейс: Выделенный адаптер со скоростью передачи данных не менее 1 Гбит/с.

ЧАСТЬ 2. ПОРЯДОК ПОДДЕРЖАНИЯ ЖИЗНЕННОГО ЦИКЛА ПО

2. ПОРЯДОК ОКАЗАНИЯ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ

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

  • Электронная почта: support@fintech-service.ru
  • Телефон горячей линии: +7 (495) 000-00-00 (укажите ваш телефон)
  • Портал технической поддержки (Service Desk): Ссылка на вашу тикет-систему

2.1. Уровни критичности инцидентов и время реагирования

Все поступающие заявки регистрируются в тикет-системе и классифицируются по трем уровням приоритета:

Критический (Блокирующий)

Полная недоступность платежного API или Панели управления.
Реакция: до 15 минут.

Высокий (Частичный сбой)

Проблемы с отдельным провайдером/банком, личные кабинеты работают.
Реакция: до 1 часа.

Низкий (Консультация)

Вопросы по интеграции API, настройке тарифов, генерации отчетов.
Реакция: до 4 часов.

3. РЕГЛАМЕНТ ДЕЙСТВИЙ В АВАРИЙНЫХ СИТУАЦИЯХ

3.1. Сбой внешнего платежного шлюза (банка-эквайера)

Признак инцидента: Резкое увеличение числа ошибок 504 Gateway Timeout или массовые отказы в проведении авторизаций со стороны конкретного эквайера.

Реакция Системы: Встроенный модуль автоматического каскадирования самостоятельно и бесшовно переключает платежный трафик мерчантов на резервные банки-эквайеры.

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

3.2. Превышение лимитов трафика (DDoS-атака или всплеск активности)

Признак инцидента: Рост утилизации мощностей CPU процессора до 100%, замедление времени отклика API-методов платформы.

Реакция Системы: Модуль контроля интенсивности трафика (Rate Limiting) автоматически включает защиту и начинает отдавать код ошибки 429 Too Many Requests для запросов, превышающих установленные лимиты, защищая ядро Системы от отказа.

Действия администратора: Произвести горизонтальное масштабирование (подключение дополнительных нод приложения) или заблокировать IP-источники вредоносного трафика на уровне веб-сервера Nginx / аппаратного файрвола.

3.3. Сбой сервера базы данных (Нарушение целостности данных)

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

Порядок аварийного восстановления БД администратором:
  1. Незамедлительно перевести и остановить связанные сервисы веб-приложения.
  2. Проверить физическое состояние дисковых накопителей сервера БД.
  3. При невозможности штатного восстановления службы — развернуть базу данных из последнего актуального ежедневного дампа резервной копии и применить инкрементальные WAL-логи.

4. ВЫПУСК ОБНОВЛЕНИЙ И ПЕРСОНАЛ

4.1. Обновления и версионирование

Система регулярно обновляется для повышения стабильности, оптимизации скорости процессинга и добавления новых платежных методов. Все обновления предварительно тестируются в изолированной тестовой среде (Staging/Test environment) и не переносятся на продуктовые сервера без успешного выполнения автоматических smoke-тестов.

Плановые релизы обновлений Системы производятся в часы минимального трафика транзакций (с 02:00 до 05:00 по московскому времени) с обязательным заблаговременным уведомлением контрагентов. При изменении версий Системы эксплуатирующая организация обеспечивает параллельное обновление сопутствующей технической документации.

4.2. Персонал, обеспечивающий поддержку жизненного цикла ПО

Для поддержания работоспособности, развития и администрирования Системы привлекается штатный персонал (граждане РФ) со следующими ключевыми компетенциями:

  • Инженеры технической поддержки (1-я и 2-я линии): Прием обращений, консультирование пользователей, первичная маршрутизация инцидентов.
  • Системные администраторы / DevOps-инженеры: Мониторинг доступности серверов, контроль СУБД PostgreSQL, балансировщика Nginx и Docker-контейнеров.
  • Разработчики ПО (Backend / Frontend): Исправление ошибок в программном коде, интеграция новых API банков, оптимизация логики биллинга.
  • QA-инженеры (Тестировщики): Контроль качества и проведение регрессионного тестирования перед выпуском обновлений.