Збій зовнішнього сервісу може зупинити B2B-платформу: Станіслав Андрєєв COO SharksCode пояснив, як знизити ризики

Зовнішній сервіс може бути недоступним лише кілька хвилин, але для клієнтів B2B-платформи це може означати збій важливої функції, затримку операції або проблеми із синхронізацією даних. COO SharksCode Станіслав Андрєєв пояснив, як компаніям виявляти небезпечні залежності від постачальників і заздалегідь готуватися до їхніх збоїв.

SharksCode – українська технологічна компанія, що спеціалізується на розробці масштабованих програмних рішень у сфері iGaming, B2B-платформ та мобільних клієнтських застосунків із підтримкою платіжних та інших сервісів.

Чому проблема партнера стає проблемою платформи

Коли команда підключає готовий зовнішній сервіс, вона економить час розробки. Згодом до першої інтеграції додаються нові функції. За кілька років через одного постачальника може проходити значна частина роботи продукту, хоча спочатку його обирали для другорядної задачі.

Для клієнта всі складові платформи працюють під одним брендом. Якщо через збій стає недоступною важлива функція, замовник звернеться до компанії, у якої придбав продукт. Йому важливі швидкість відновлення та зрозуміле пояснення ситуації. Те, що збій почався в іншій компанії, відповідальності перед клієнтом не знімає.

Згідно зі звітом Uptime Institute Annual Outage Analysis 2026, приблизно дві третини публічно зафіксованих за дев’ять років збоїв IT-сервісів і датацентрів припадали на сторонніх постачальників – зокрема хмарні, телекомунікаційні та інфраструктурні компанії. Це статистика відкрито задокументованих інцидентів, а не всіх технічних несправностей у світі.

Станіслав Андрєєв пропонує оцінювати залежність за двома запитаннями: що перестане працювати для клієнта, якщо постачальник стане недоступним, і скільки часу знадобиться на його заміну. Якщо вимкнення інтеграції зупиняє основний сценарій або змушує перебудовувати ядро продукту, такий сервіс потребує особливої уваги.

Що перевірити до підписання договору

Почати варто з реєстру підключених сервісів. Для кожного записують відповідального, пов’язані з ним функції, перелік даних, які він отримує, і можливу альтернативу. Важливо включити навіть старі тестові інтеграції: вони можуть залишатися активними після завершення експерименту.

Після інвентаризації залежності розподіляють за наслідками збою. Деякі сервіси забезпечують критичні операції, інші впливають лише на додаткові функції. Це допомагає зрозуміти, де варто інвестувати в резервування, а де достатньо моніторингу та зрозумілого плану відновлення.

Під час вибору нового постачальника важливо читати умови SLA, порядок повідомлення про зміни в API та правила експорту даних. Для оцінки безпеки можуть бути корисними звіт SOC 2 або сертифікат ISO 27001. Жоден із цих документів не гарантує відсутності збоїв, тому окремо слід оцінювати можливість виходу з договору та вартість перенесення інтеграції.

Операційний ризик має й фінансовий вимір: дешевша ліцензія іноді потребує дорожчої міграції. Якщо перехід забере місяці роботи розробників, це важливий аргумент ще на етапі закупівлі сервісу. Саме тому до вибору критичних підрядників доцільно залучати фінансистів і юристів.

Як діяти під час збою

Технічній команді варто відокремлювати роботу із зовнішніми сервісами від основної логіки продукту. Проміжний шар у коді може полегшити заміну провайдера, але сам не забезпечить відмовостійкості. Для цього потрібні додаткові сценарії: контроль помилок, безпечні повторні запити, черги відкладених операцій та, коли це виправдано, резервні підключення.

Наприклад, передачу подій до аналітики іноді можна відкласти до відновлення зв’язку. Платіжні операції вимагають іншого підходу: резервного провайдера варто використовувати лише за умови налаштованої інтеграції та захисту від дублювання транзакцій.

Для операцій, результат яких має бути зафіксований точно й однозначно, потрібен інший підхід: перш ніж повторювати запит, необхідно перевірити стан операції на платформі, щоб уникнути дублювання або розбіжностей у даних.

Власний моніторинг інтеграцій дає змогу швидше побачити проблему, ніж очікування повідомлення на сторінці статусу постачальника. Команда має заздалегідь знати, хто оцінює наслідки інциденту, запускає резервний сценарій і повідомляє клієнтів про строки відновлення.

За словами COO SharksCode Станіслава Андрєєва, керівництву варто оцінювати зовнішній сервіс і за витратами на підключення, і за можливими збитками під час простою. Коли ці цифри та відповідальні визначені до інциденту, реагувати значно простіше.