SLA и поддержка: время реакции, каналы связи, инциденты
Надёжная обработка платежей — это фундамент онлайн‑бизнеса. Страница описывает, как устроен наш SLA платежи: целевые показатели доступности сервиса, время реакции саппорта, каналы связи 24/7, а также порядок работы с инцидентами и эскалацией. Здесь же вы найдёте регламент работ, подходы к обслуживанию событий и рекомендации для мерчантов.
Что входит в SLA платежей
SLA платежи распространяется на ключевые компоненты платформы API Платежи:
Зона нашей ответственности — доступность сервисов платформы и контролируемых интеграций. На внешние провайдеры (банки, платёжные системы) мы воздействуем через дежурную эскалацию и маршрутизацию трафика; такие события также отражаются в статусе сервиса.
Для Enterprise‑клиентов доступна расширенная поддержка api платежей, включая индивидуальные окна обслуживания, выделенную линию и повышенные SLO.
Доступность сервиса и целевые метрики
Мы стремимся к высокой доступности сервиса в продакшн‑среде и прозрачному измерению качества.
Целевые показатели (типовые значения):
- Доступность платёжного API: 99.95% в месяц.
- Медианная задержка авторизации: ≤ 300 мс на стороне шлюза (без времени внешних провайдеров).
- Доставка вебхуков: ≥ 99.9% в течение TTL (с ретраями).
- Время публикации инцидента на статус‑странице: ≤ 15 минут с момента подтверждения.
Измерение доступности ведётся по фактическому успешному завершению критических операций и доле ошибок 5xx в контролируемой зоне. Методика доступна в Документации API.
Каналы связи 24/7 и время реакции саппорта
Поддержка доступна по нескольким каналам. Для критических обращений действует онколл‑режим 24/7.
| Канал |
Доступность |
Для каких случаев |
Примечание |
| Тикет в кабинете мерчанта |
24/7 |
Все запросы, инциденты, изменения |
SLA по времени реакции считается от момента создания |
| Чат поддержки |
24/7 для P1–P2, 10×5 для остальных |
Оперативные вопросы интеграции и статуса |
Эскалация по ключевому слову «P1/P2» |
| Email/интеграция с системой тикетов |
24/7 |
Баг‑репорты, вопросы интеграции |
Авто‑назначение приоритета по шаблону |
| Экстренная эскалация (онколл) |
24/7 |
Только P1 |
Поднимается из тикета «P1» автоматом |
Конкретные целевые метрики времени реакции саппорта зависят от приоритета и описаны ниже.
Классификация инцидентов и эскалация
Чёткая классификация помогает быстро стабилизировать работу и вернуть продажи.
| Уровень |
Описание |
Примеры |
Первичная реакция |
Обход/стабилизация |
Полное решение |
| P1 — критический |
Сбой, влияющий на большую долю транзакций в продакшне |
Недоступен платёжный API, всплеск 5xx, массовые отклонения у провайдера |
≤ 15 мин |
≤ 2 ч |
≤ 4 ч |
| P2 — высокий |
Частичная деградация, есть обходные пути |
Проблемы с одним из методов оплат, задержки вебхуков |
≤ 30 мин |
≤ 4 ч |
≤ 8 ч |
| P3 — средний |
Функциональные дефекты без существенного влияния на оборот |
Ошибка в интерфейсе дашборда, незначительные несоответствия API |
≤ 4 ч |
≤ 2 р. дн. |
≤ 5 р. дн. |
| P4 — низкий |
Вопросы, консультации, улучшения |
Запросы по интеграции, UX‑предложения |
≤ 1 р. дн. |
По плану |
По плану |
Эскалация инцидентов:
- Регистрация тикета с правильным приоритетом → 2) Триаж и назначение IC (Incident Commander) → 3) Коммуникации в статус‑канале → 4) Техническая стабилизация и обход → 5) Полное исправление → 6) Пост‑мортем и профилактика.
![Диаграмма жизненного цикла инцидента]
Обслуживание событий и вебхуки
Событийная модель позволяет надёжно синхронизировать статусы платежей и сервисных операций между нашими системами и вашим бэкендом.
- Доставка: каждый вебхук подписывается и отправляется с несколькими ретраями с экспоненциальной паузой.
- TTL доставки: до 72 часов с постепенным бэкоффом; затем событие попадает в DLQ для безопасного дозапуска.
- Идемпотентность: используйте ключи идемпотентности и сохраняйте идентификатор события для защиты от дублей — см. Вебхуки и события.
- Порядок: гарантируется хотя бы один раз; при необходимости строгой упорядоченности применяйте локальные очереди потребителя.
В рамках SLA мы отслеживаем скорость обработки очередей, время подтверждения от мерчанта и долю успешной доставки. Это и есть «обслуживание событий», критичное для жизненного цикла платежа.
Регламент работ и плановое обслуживание
Для непрерывного улучшения мы проводим плановые работы в предсказуемые окна, максимально снижая влияние на бизнес.
- Типовое окно обслуживания: 02:00–06:00 MSK (минимальный трафик).
- Уведомления: не менее чем за 7 дней для плановых изменений и за 24 часа для срочных профилактик.
- Заморозка изменений: в пиковые продажи и крупные маркетинговые события вводится change freeze.
- Миграции API: все breaking‑изменения анонсируются и поддерживаются через версионирование — см. Документация API и Быстрый старт интеграции.
![Схема плановых окон и уведомлений]
Мониторинг, алерты и status page
У нас многослойный мониторинг: технические метрики инфраструктуры, синтетические проверки API из нескольких регионов, бизнес‑метрики (конверсия, одобрение, возвраты).
- Алерты: многоканальные, с автоматической агрегацией инцидентов и антидребезгом.
- status page: прозрачное отражение состояния компонентов (API, вебхуки, дашборд, интеграции с провайдерами), журнал событий и подписка на обновления.
- Отражение прогресса: на статус‑странице публикуются этапы «Идентифицировано → Стабилизировано → Решено», ETA и обходные рекомендации.
Это помогает вам быстро оценить доступность сервиса и принимать верные решения в моменте.
Ответственность клиента и лучшие практики
Надёжность — совместная работа. Рекомендуем:
- Следовать гайдам из Документации API и пройти Быстрый старт интеграции в тестовой среде — см. Песочница и тестирование.
- Использовать идемпотентность, логировать X‑Request‑Id и payment_id, измерять стороной клиента время ответа и коды ошибок.
- Настроить алерты на падение конверсии и рост отказов; включить автоповторы на стороне вашего бэкенда.
- Подписывать и проверять подписи вебхуков; изолировать секреты и регулярно ротировать ключи — см. Безопасность и PCI DSS.
- Включить правила антифрода и мониторить риск‑метрики — см. Antifraud и риск.
Так вы минимизируете влияние внешних факторов и ускорите разбор любых инцидентов.
Отчёты, пост‑мортемы и коммуникации
По критическим инцидентам (P1) предоставляется полный пост‑мортем с корневой причиной и мерами профилактики в течение 5 рабочих дней; по P2 — в течение 10 рабочих дней. Ежемесячно мы формируем сводку SLA с основными метриками доступности и производительности.
Оперативные данные о платежах, возвратах и комиссиях доступны в кабинете и через API — см. Отчёты и выгрузки и Тарифы и комиссии.
Как обратиться в поддержку: чек‑лист
Чтобы ускорить разбор, приложите максимум контекста:
- Идентификаторы: merchant_id, payment_id, X‑Request‑Id, номер заказа.
- Среда: прод/тест; релиз/версия SDK — см. Mobile SDK.
- Таймстемпы и часовой пояс, затронутые регионы и методы — см. Методы оплат.
- Запрос/ответ API (без чувствительных данных), шаги воспроизведения, скриншоты/логи.
- Оценка масштаба (сколько транзакций/пользователей) и влияние на бизнес.
Создавайте тикет через кабинет; для критики пометьте приоритет P1/P2. По интеграционным вопросам полезны ссылки на используемые эндпоинты из Приёма платежей API.
Связанные сценарии: возвраты, рекуррентные, выплаты, фискализация
Некоторые запросы касаются конкретных бизнес‑процессов:
Эти разделы содержат особенности SLA и операционных регламентов для соответствующих сценариев.
Итог: мы обеспечиваем высокую доступность сервиса, предсказуемое время реакции саппорта и прозрачные процессы работы с инцидентами и эскалацией. Следуйте рекомендациям, используйте наши инструменты мониторинга и документацию — так вы получите максимум надёжности и конверсии.
Готовы обсудить расширенный SLA или задать вопрос? Создайте тикет в кабинете и укажите тему «SLA и поддержка», либо начните с Быстрого старта интеграции.
