Компания Fondy, многофункциональный сервис интернет-эквайринга, на собственном примере рассказывает и показывает, как все устроено.
Что такое Fondy и о чем эта статья
Сервис Fondy является облачным провайдером платежных технологий и предоставляет услуги процессирования платежей по картам Visa и MasterCard, а также white label решения в Украине, России, Европе. Если объяснить немного более простыми словами, то:
- облачный — значит вам не обязательно иметь собственные сервера, чтобы принимать платежи по картам на сайте, – мы разместим все программное обеспечение в своих датацентрах;
- провайдер платежных технологий — это как классический интернет-эквайринг через банк, так и более сложные финансовые и технологические решения, например: функции расчетного центра, электронных кошельков, p2p переводов, оплаты услуг;
- white label — это такое особое решение для клиентов, которые хотят предоставлять весь тот же спектр услуг, что и Fondy, но под своим брендом и под своим доменным именем.
Дело в том, что наша принципиальная позиция заключается в желании быть честными и открытыми с нашими клиентами и информировать не только о преимуществах, но и о рисках нашего сервиса как инструмента развития собственного бизнеса. Поэтому мы хотим рассказать, как устроены наши внутренние бизнес-процессы, обеспечивающие доступность, стабильность и качество сервиса.
В нашем публичном соглашении об уровне обслуживания (Service Level Agreement, SLA) мы декларирует своим клиентам доступность (uptime) платежного шлюза на уровне 99,95%, а это значит, что:
1. Суммарный простой (запланированный и не запланированный) не должен быть более, чем:
- день: 43,2 с
- неделя: 5 мин. 2,4 с
- месяц: 21 мин. 54,9 с
- год: 4 ч 22 мин. 58,5 с
2. Количество платежей, отклоненных по причине технического сбоя, не должно быть более 5 на каждые 10 000 платежей.
Для 99% платежей дополнительные задержки, накладываемые нашей системой во время передачи платежа от клиента к обслуживающему процессинговому центру или банку-эквайеру, не превысят 0,5 секунды и для 99,95% не превысят 3 секунды.
Стоит сразу отметить, что эти требования распространяются только на ту часть инфраструктуры, доступность которой мы в состоянии обеспечить, и не распространяется на работоспособность платежных шлюзов банков, платежных систем, каналы связи за пределами нашего дата-центра и прочие сервисы и объекты, на которые мы не влияем напрямую.
Чтобы достичь и регулярно поддерживать такой высокий уровень доступности сервиса, мы проделали большую работу по улучшению процессов разработки, тестирования, установки изменений и мониторинга работоспособности. В этой статье мы расскажем, как это у нас реализовано и какими средствами достигается.
Разработка
В разработке мы придерживаемся практики непрерывной интеграции (Continuous Integration), что позволяет нам оперативно производить доработку узлов системы под нужды клиентов и поставлять на production-систему обновления ежедневно и не редко по несколько раз в день. Свежие изменения, внесенные разработчиком на основании техзадания, проходят код-ревью и процесс автоматического тестирования и сборки. Таким образом, от момента завершения разработки до поставки изменений на production-систему могут пройти считанные минуты
Такие эффективные процессы в разработке позволяют нам идти навстречу любым инновациям и экспериментам, и это очень важно для наших клиентов, поскольку многие из них — динамично развивающиеся бизнесы, которым требуются как финансовая, так и технологическая гибкость, дающие очевидное преимущество на высококонкурентном рынке.
Несмотря на постоянные изменения кода, наши программные приложения очень устойчивые. Стабильность системы, подверженной частым обновлениям, при этом достигается посредством большого количества автоматических тестов, запускаемых перед каждой установкой обновлений. Ни одно обновление не поставляется на production-систему, не имея “зеленых” тестов.
Сборка на этом скриншоте будет помечена как broken и не попадет на production-систему, так как имеет “плохие” тесты.
Любое обновление, установленное на production-систему, мы сначала разворачиваем на одном из production-серверов, на который направляется небольшой трафик платежей, до 1% от общего объема. При этом, отдел мониторинга и разработчики, ответственные за изменение, после установки активно мониторят наличие ошибок, которые приложение регистрирует в автоматизированной системе слежения за ошибками — Sentry. Если ошибки есть, обновление немедленно откатывается назад и отправляется на разбор причин и исправление.
Пример автоматического уведомления об ошибке в системе Sentry
Если причиной ошибки, попавшей на production-систему, является не покрытая тестами функциональность — в этом случае отдел QA разрабатывает новый автоматический тест.
Автоматические тесты
Автоматические тесты — это основной этап контроля работоспособности обновлений. Помимо юнит-тестов, важную роль играют интеграционные тесты, и в этом месте стоит остановиться на более подробном описании.
Интеграционное тестирование —это проверка корректности взаимодействия системы с другими внутренними и внешними системами и сервисами.
Наш QA-отдел разработал большое количество интеграционных тестовых сценариев, которые проверяются перед каждым обновление production-системы. Например, самая критичная часть системы – платежный шлюз – покрыт несколькими сотнями файлов тестов, которые содержат более 3000 автотестов. Так, количество проверок в одном регрессионном тестировании достигает 80 тыс. Такая регрессия представляет собой проверку как внутренней работоспособности всего API-шлюза, так и интеграции с различными внешними системами, такими как:
- процессинговые центры;
- банки-эквайеры;
- международные и локальные платежные системы;
- другие платежные сервисы, которых реализовано в системе более 50.
Для тестирования интеграции с внешними системами, если такая система не имеет стабильной тестовой среды, наши разработчики реализуют так называемые “заглушки” — имитацию ответа внешней системы в позитивном и негативном сценарии.
Регрессия включает в себя проверку всей платежной функциональности, такой как:
- покупки через браузер;
- покупки через сервер-сервер запрос для PCI DSS-мерчантов;
- кнопки и виджеты для приема обычных платежей и пожертвований;
- регулярные платежи;
- реверсы;
- проверки статусов платежей;
- отчеты;
- p2p-переводы;
- JavaScript API;
- верификация (проверка) карты;
- iOS, Android, PHP SDK;
- предавторизация и завершение платежа;
- колбеки;
- прочая функциональность, описанная в публичных спецификациях API.
Например, тесты, предполагающие имитацию взаимодействия плательщика в браузере с нашей платежной страницей, воспроизводятся во всех наиболее популярных версиях браузеров. Для Internet Explorer это от IE8 до IE11 включительно. Все более 80 тыс. тестов выполняются в течение примерно 5 минут на сервере с конфигурацией 32 GB ОЗУ и 8 ядер процессора.
Такая скорость выполнения тестов на сервере с вполне средней конфигурацией достигается за счет разработки нашей команды, позволяющей запускать тесты параллельно на всех ядрах процессоров наиболее оптимально. Если бы все тесты запускались последовательно в один поток, то только один запуск регрессионных тестов занимал бы более часа времени. Для реализации мультипоточных тестов и загрузки всех CPU мы используем robot framework, который поддерживает запуск тестов в несколько потоков.
Также для ускорения тестов мы одновременно тестируем несколько веток разработки в параллельном режиме, используя docker — платформу для автоматической виртуализации приложений. При помощи docker мы разворачиваем сразу несколько образов — копий платежного шлюза, разработку над которыми вели и завершили разные разработчики.
Результат каждого запуска тестов рассылается всем заинтересованных сотрудникам в Telegram, что позволяет оперативно исправлять “упавшие” тесты. Такое сообщение содержит подробную информацию о всех тестах, в том числе скриншот и лог ошибки с описанием причины для разработчиков.
Кстати, именно через Telegram у нас выполняется основная рассылка уведомлений о событиях и инцидентах системы, о которых пойдет рассказ в следующем параграфе.
Мониторинг
Для мониторинга работоспособности системы мы используем как популярные средства, такие как zabbix и Sentry, так и Business Intelligence (сокращенно BI) систему собственной разработки. Наша BI-система позволяет операторам следить за производительностью платежного шлюза, а также уведомляет в зависимости от типа инцидента сотрудника, которому необходимо знать об инциденте в соответствии с матрицей эскалации инцидентов
Раздел мониторинга в BI -системе Fondy
Раздел “Мониторинг мерчантов” в BI-системе отображает количество отказов, успешных платежей, ошибок, скорость прохождения платежей, конверсию по наиболее крупным мерчантам и отсылает уведомление в случае отклонения от нормы.
Также у нас есть раздел “Мониторинг протоколов”, в котором отслеживается работоспособность активных интеграций с внешними системами, и в случае сбоя одной из них оператор связывается с службой поддержки этой системы для уведомления о проблеме либо активирует функцию каскадного процессинга.
Каскадный процессинг
Одной из очень важных функций нашей системы мониторинга является каскадный процессинг. Каскадный процессинг — это возможность мерчанту переключиться на протокол резервного банка-эквайера в случае сбоя основного. Переключение может происходить как автоматически, так и вручную ответственным сотрудником.
Резюме
Надеемся, эта статья была вам полезна и дала некоторое представление о Fondy как открытой, высокотехнологичной компании, которая заботится о качестве своего сервиса и выполнения обязательств перед своими клиентами.
