Свята закінчилися, а значить настав час корисних інсайтів про те, як витримати останній квартал кожного року й вийти з нього в плюсі. Так, це не тільки час, коли ви плануєте бюджети, бігаєте на корпоративи та в грудні кажете «ну давайте вже після свят». Четвертий квартал — це час, коли треба конкретно попрацювати, адже такої концентрації свят і розпродажів немає за весь рік. Свята та сейли = більші продажі, а більше продажі = прибуток. Наче звучить круто, правда? Але за плюсики у звітності треба заплатити стрес-тестом для всіх бізнес-процесів — у тому числі флоу платежів.
Мене звуть Влад Чухрай, я Project Manager у фінтех-компанії bill_line, і щороку я бачу, як прості помилки в конфігурації та недостатній план навантаження перетворюють «золотий» сезон на нічний кошмар для деяких мерчантів. Сьогодні поговоримо про конкретні технічні кроки, які фінтех має виконати щонайменше за місяць до піка й підтримувати під час нього. Тепер у вас є багато часу, аби точно встигнути зробити все, про що ви прочитаєте тут.
Одразу окреслю два моменти. Перший — у цій колонці багато технічної інфи, яку може не розуміти власник бізнесу, однак вся ця підготовча робота є справою як платіжного партнера, так і мерчанта. Постійна продуктивна взаємодія та компетентність — те, з чого починається святковий сезон без фейлів. Другий — багато що стосується в першу чергу середніх та великих бізнесів. Але це не значить що з проблемами перевантаження не може стикнутися маленький бізнес. Скоріше навпаки, це трапляється частіше, особливо коли невеликий бізнес може дати кращу ціну на популярний товар.
Починаємо з тестування. Навантажувальні тести це маст хев, бо вони виявляють болючі місця: connection pool у базі даних, вузькі місця в чергах повідомлень, непотрібні блокування в серіалізації транзакцій і т. д. План тестування має відтворювати не лише показник TPS (кількість транзакцій за секунду), але й реальні шаблони:
- сплески auth-запитів;
- одночасні refund/void;
- масові webhook-івенти.
Робіть тестування за кілька ітерацій з поступовим збільшенням навантаження — це дозволяє коригувати автоскейлінг та пуллінг без ризику «перепалити» прод.
Архітектура має бути готова до деградації: розподіляйте відповідальність, ізолюйте критичні шляхи платежів від неключових сервісів. Про що я? В першу чергу — що чекаут-флоу й авторизація карток мають працювати навіть якщо бэк-офісні сервіси (аналітика, email-розсилка) відчувають затримки. Використовуйте черги для буферизації (message queues), з ретельно налаштованими consumer-pool та idempotency токенами, щоб повторні спроби не створювали дублікати платежів.
Автоскейлінг — обов’язкова штука, але не як єдина захисна лінія. Налаштуйте прозорий горизонтальне масштабування інфраструктури та перевірте холодний старт нових інстансів. Часто проблема не в тому, що можна підняти нові ноди, а в тому, що під час старту вони не встигають прогріти кеші або приєднатись до кластерів баз даних і тому фактично недоступні в перші хвилини. Для критичних компонентів краще мати заздалегідь «гарячі» резерви. Ті, хто покладається лише на реактивний автоскейл, ризикують побачити лаги саме в пікові хвилини.
Платежі — це мережеві операції з багатьма змінними. Тут допомагає система платіжного оркестрування, яка містить смарт роутінг по провайдерам, про який я писав у вересні, каскадний фейловер і тюнінг параметрів retry/timeout (більше про smart retry читайте тут). Задачка у тому, аби налаштувати логіку так, щоб швидкі фейли переводили платіж на альтернативний провайдер без зайвих повторів, і при цьому зберігалися правила idempotency та відповідність PCI/регуляторним вимогам. Ось чому важливо мати досвідченого платіжного партнера, який вміє в оркестрування: він має давати метрики по latencies і success rates для кожного каналу в реальному часі — це дозволяє міняти пріоритизацію на льоту. Не хочу хизуватися, але ми у bill_line це вміємо. Окей, насправді хочу, тому це й написав 😉
Далі — моніторинг. Він має бути «живим» і з розумними сигналами. Не вистачає простого логіну в тому ж Grafana. Потрібні SLO/SLA-орієнтовані алерти, які мають включати:
- загальний час авторизації;
- відсоток помилок 5xx на шлюзі;
- середній час відповіді провайдера;
- черги в брокерах повідомлень.
Налаштуйте синтетичний моніторинг на чекаут флоу з реальними картками (sandbox + production synthetic) і сповіщенням не тільки в месенджер, з яким ви працюєте (знаю, що часто це Slack, але не наш випадок), а й через escalation-chain. Також бажано мати окремі дашборди для мерчантської підтримки: мінімізуйте «шум» і дайте їм зрозуміти, коли проблема з боку провайдера, а коли локальна.
Ну і куди ж без технічної безпеки та фрод-контролю під час піків? Антифрод досить часто блокує «легітимні» платежі під час сплесків. Причин для цього море, треба писати окремий текст, якщо узагальнити — активні покупки всякого коли люди відкладають покупки на останній момент виглядає для антифроду як вкрадена картка. Під час свят зробіть тимчасові адаптації правил: послабте занадто жорсткі threshold’и, але компенсуйте це більш інтенсивною перевіркою на бекенді та ручною модерацією для сумнівних випадків. Важливо зберегти баланс між ризиком і доходом. Під час свят іноді вигідніше прийняти більше транзакцій і відловлювати шахрайство після авторизації, ніж втрачати продажі через перебільшені блокування. Але все це треба робити тільки разом з відповідальними за безпеку колегами, а не, тому що я так написав: кожен пул клієнтів унікальний і зі своїми нюансами.
Не ігноруйте логістику операційної команди: план з резервних провайдерів, SLA-угоди, готові змінні конфігурації маршрутизації. Підготуйте playbook на випадок масових відмов: короткі чеклисти для інженерів і для людей техпідтримки. Розігруйте цей playbook під час чергового навантажувального тесту. Такі «репетиції» значно скорочують час розв’язання інциденту в реальному житті.
І останнє: якщо у вас планується великий апдейт прямо перед святами — не треба так. Хоча, звісно, різдвяно-новорічний сезон — це час чудес, але краще зустріти його з родиною, а не за гарячковим вирішенням проблем. Я вам бажаю лише першого цими святами 😉