Как платформа Fondy обеспечивает и поддерживает высокий уровень сервиса

Разработка

В разработке мы придерживаемся практики непрерывной интеграции (Continuous Integration), что позволяет нам оперативно производить доработку узлов системы под нужды клиентов и поставлять на production-систему обновления ежедневно и нередко по несколько раз в день.

Свежие изменения, внесенные разработчиком на основании техзадания, проходят код ревью и процесс автоматического тестирования и сборки. Таким образом от момента завершения разработки до поставки изменений на production-систему могут пройти считанные минуты.

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

Несмотря на постоянные изменения кода, наши программные приложения очень устойчивые. Стабильность системы, подверженной частым обновлениям, при этом достигается посредством большого количества автоматических тестов, запускаемых перед каждой установкой обновлений. Ни одно обновление не поставляется на production систему, не имея «зеленых» тестов.

Сборка на этом скриншоте будет помечена как broken и не попадет на production-систему, так как имеет плохие тесты.

Любое обновление, установленное на production-систему мы сначала разворачиваем на одном из production-серверов, на который направляется небольшой трафик платежей, до 1% от общего объема. При этом отдел мониторинга и разработчики, ответственные за изменение, после установки активно мониторят наличие ошибок, которые приложение регистрирует в автоматизированной системе слежения за ошибками  –  Sentry. Если ошибки есть, обновление немедленно откатывается назад и отправляется на разбор причин и исправление.

Пример автоматического уведомления об ошибке в системе Sentry

Если причиной ошибки, попавшей на production-систему, является непокрытый тестами функционал –  в этом случае отдел QA разрабатывает новый автоматический тест.

Автоматические тесты

Автоматические тесты  –  это основной этап контроля работоспособности обновлений. Помимо юнит-тестов, важную роль играют интеграционные тесты, и в этом месте стоит остановиться на более подробном описании.

Интеграционное тестирование – это проверка корректности взаимодействия системы с другими внутренними и внешними системами и сервисами.

Наш QA-отдел разработал большое количество интеграционных тестовых сценариев, которые проверяются перед каждым обновление production-системы. Например, самая критичная часть системы – платежный шлюз – покрыт несколькими сотнями файлов тестов, которые содержат более 3 000 автотестов. Так, количество проверок в одном регрессионном тестировании достигает 80 000. Такая регрессия представляет собой проверку как внутренней работоспособности всего API-шлюза, так и интеграции с различными внешними системами, такими как:

• процессинговые центры
• банки-эквайеры
• международные и локальные платежные системы
• другие платежные сервисы

которых реализовано в системе более 50.

Для тестирования интеграции с внешними системами, если такая система не имеет стабильной тестовой среды, наши разработчики реализуют так называемые «заглушки» –  имитацию ответа внешней системы в позитивном и негативном сценарии.

Регрессия включает в себя проверку всего платежного функционала, такого как:

• покупки через браузер
• покупки через сервер-сервер запрос для PCI DSS-мерчантов
• кнопки и виджеты для приема обычных платежей и пожертвований
• регулярные платежи
• реверсы
• проверки статусов платежей
• отчеты
• p2p-переводы
• JavaScript API
• верификация (проверка) карты
• iOS, Android, PHP SDK
• предавторизация и завершение платежа
• колбеки
• прочий функционал, описанный в публичных спецификациях API

Например, тесты, предполагающие имитацию взаимодействия плательщика в браузере с нашей платежной страницей, воспроизводятся во всех наиболее популярных версиях браузеров. Для Internet Explorer это от IE8 до IE11 включительно.

Все более 80 000 тестов выполняются в течение примерно 5 минут на сервере с конфигурацией 32 GB ОЗУ и 8 ядер процессора. Такая скорость выполнения тестов на сервере с вполне средней конфигурацией достигается за счет разработки нашей команды, позволяющей запускать тесты параллельно на всех ядрах процессоров наиболее оптимально.

Если бы все тесты запускались последовательно в один поток, то только один запуск регрессионных тестов занимал бы более часа времени. Для реализации мультипоточных тестов и загрузки всех CPU мы используем robot framework , который поддерживает запуск тестов в несколько потоков.

Также для ускорения тестов мы одновременно тестируем несколько веток разработки в параллельном режиме, используя docker  – платформу для автоматической виртуализации приложений. При помощи docker мы разворачиваем сразу несколько образов  – копий платежного шлюза, разработку над которыми вели и завершили разные разработчики.

Результат каждого запуска тестов рассылается всем заинтересованных сотрудникам в Telegram, что позволяет оперативно исправлять «упавшие» тесты. Такое сообщение содержит подробную информацию о всех тестах, в том числе скриншот и лог ошибки с описанием причины для разработчиков.

Кстати, именно через Telegram у нас выполняется основная рассылка уведомлений о событиях и инцидентах системы, о которых пойдет рассказ в следующем параграфе.

Мониторинг

Для мониторинга работоспособности системы мы используем как популярные средства, такие как zabbix и Sentry, так и Business intelligence (сокращенно BI)  – систему собственной разработки. Наша BI-система позволяет операторам следить за производительностью платежного шлюза, а также в зависимости от типа инцидента уведомляет того сотрудника, которому необходимо знать об инциденте в соответствии с матрицей эскалации инцидентов.

Раздел «Мониторинг мерчантов» в BI-системе отображает количество отказов, успешных платежей, ошибок, скорость прохождения платежей, конверсию по наиболее крупным мерчантам и отсылает уведомление в случае отклонения от нормы.

Точно также у нас есть раздел «Мониторинг протоколов», в котором отслеживается работоспособность активных интеграций с внешними системами, и в случае сбоя одной из них оператор связывается с службой поддержки этой системы для уведомления о проблеме либо активирует функцию каскадного процессинга.

Каскадный процессинг

Одной из очень важных функциональных особенностей нашей системы мониторинга является каскадный процессинг. Каскадный процессинг  – это возможность мерчанту переключиться на протокол резервного банка-эквайера в случае сбоя основного. Переключение может происходить как автоматически, так и вручную ответственным сотрудником.