DDoS-атака на крупнейшие российские банки: как мы возвращали оборот екома и какие уроки вынесли
На прошлой неделе лидеры российской банковской индустрии пострадали от масштабной DDoS-атаки. Пока банки таймаутили, покупатели испытывали трудности с оплатой, а платежные шлюзы и еком теряли деньги (и плакали). Как платежный сервис Payture спасал выручку клиентов и свой оборот — в этом материале.
Что это было?
Вечером 2-го сентября началась крупная DDoS-атака на магистральных провайдеров российского сегмента интернета, среди которых Orange Business Services. Именно через него идет значительная часть трафика российских банков по картам. Атака случилась вскоре после новостей о крупнейшей за последние годы DDoS-атаке на сервисы 3D Secure, пик которой пришелся на 13-16 августа. Тогда, благодаря быстрой реакции и резервным каналам, банки работали в штатном режиме, поэтому для многих участников финансового рынка она осталась незамеченной.
Сентябрьский эпизод был более ощутимым: физлицам в течение определенного времени не были доступны банкоматы и сервисы банкинга. Юрлица столкнулись с невозможностью процессинга операции по банковским картам из-за полного отсутствия сервиса.
2-4 сентября мы фиксировали сбои в наших крупных банках-партнерах, среди которых ВТБ, Сбер, Открытие, Киви.
Как это отразилось на нашем процессинге?
Мы временно потеряли большую часть оборота. По некоторым клиентам мы наблюдали критическое снижение уровня конверсии. Самыми сложными были ситуации, когда и основной и резервные банки-эквайеры (куда платеж автоматически перенаправляется в случае недоступности основного) оказались накрыты атакой.
Полного даунтайма не случилось, так как стабильные банки все же остались, и некоторым клиентам удалось спасти свой трафик.
Что мы с этим делали?
Сначала было непонятно, что именно произошло и сколько это продлится, а на внутреннюю аналитику смотреть было все больнее.
Главное, что мы сделали — задействовали внутреннюю логику платежного шлюза и увеличили мощности на ряд эквайеров, которые были признаны стабильными в пик атаки. Первый удар пришелся на нашу техподдержку: необходимо было как можно быстрее провести анализ доступности сервисов банков-партнеров и перевести платежи с проблемных эквайеров.
Дальше включились другие команды Payture: разработке удалось быстро пересмотреть и улучшить retry-схему с банками, а команда администраторов с повышенной готовностью следила за сетевым трафиком, маневрируя его между датацентрами в поисках работающих маршрутов в банки-эквайеры.
Все это потребовало перестройки сложившейся схемы устройства онлайн-платежей у клиентов и заняло определенное время. Каждая минута простоя в таких случаях означает невозможность оплатить, а значит и своевременно получить нужный товар или услугу покупателем. Продавец при этом не просто упускает прибыль, но и сталкивается с волной негатива от пользователей из-за проблем с оплатой, что не лучшим образом сказывается на пользовательском опыте и лояльности клиентов.
Какие уроки мы вынесли?
- Если вы думаете, что продумали и предусмотрели самый негативный сценарий, подумайте еще раз. Большинство платежных сервисов принимают за такой негативный сценарий историю с 1-2 точками отказа. Но к ситуации, когда лежат сразу несколько крупнейших банков-эквайеров, оказываются не готовы. Сценарий, когда недоступен целый сегмент, должен стать одним из рабочих.
- Под самый негативный сценарий всегда должны быть готовы ресурсы. Здесь два рабочих варианта: либо эта структура должна быть подготовлена заблаговременно и сразу использоваться в критические моменты, либо нужно иметь готовую техкарту, по которой эта буферная структура может быть оперативно построена. Здесь мы использовали первый сценарий, и именно благодаря подготовленной инфраструктуре полной остановки процессинга не случилось: мы накинули мощностей на стабильные банки и увели трафик.
- Хорошая идея — выделить время и ресурсы на то, чтобы установить собственные каналы связи с банками-партнерами, а не обращаться к их сервисам через открытый интернет.
- Оператор техподдержки процессингового центра должен сразу действовать, а не думать, а потом действовать. В таких ситуациях скорость реакции прямо пропорциональна финансовым потерям сторон.
- И совет напоследок: заранее оценивайте сложность построенной бизнес-логики при приеме онлайн-платежей. Модель приема онлайн-платежей строится из потребностей клиента и постепенно подстраивается под конкретный проект. Службы мониторинга и техподдержки платежного сервиса всегда должны оценивать каждую модель на гибкость и возможность оперативного изменения. Это нужно, чтобы не столкнуться с ситуацией, когда кажется, что все стабильно, а потом случается обвал всего, и вы оказываетесь не готовы перестроить логику оплаты.
Интересный кейс
спасибо!
Это точно была DDOS атака, или РКН тестировал блокировку независимого интернета ко дню выборов, чтобы иностранные агенты не повлияли на российскую демократию?
Об источниках и причинах можно рассуждать долго. Нашей главной задачей было разобраться с последствиями с минимальным ущербом для всех сторон. Собственно, этот опыт и описали)
Спасибо, всегда интересно почитать про процессинг платежей в онлайне!
спасибо!