Посада: Станіслав Андрєєв, операційний директор SharksCode: Як ефективно управляти ризиками зовнішніх сервісів у B2B-рішеннях.

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

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

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

Чужий збій перетворюється на проблеми з продуктом.

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

Масштаб ризику показує Uptime Institute Annual Outage Analysis 2026. Протягом дев'яти років дослідження приблизно дві третини публічно зафіксованих збоїв ІТ-сервісів та датацентрів припадали на сторонніх постачальників інфраструктури, зокрема хмарні, телекомунікаційні та датацентрові компанії. Ця статистика стосується задокументованих інцидентів, але добре показує, наскільки важливими стали зовнішні залежності.

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

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

Найгірший момент для з'ясування таких залежностей -- коли сервіс уже недоступний.

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

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

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

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

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

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

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

Як налаштувати продукт на випадок збоїв

Після проведення аналізу залежностей команда здатна виявити області, де необхідно здійснити додатковий технічний захист.

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

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

Наприклад, якщо тимчасово недоступний аналітичний сервіс, частину подій можна зберегти й передати після відновлення зв'язку. Користувач продовжить працювати з основними функціями продукту.

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

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

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

У вирішальний момент команді необхідно мати чіткий алгоритм дій. Хто здійснює оцінку наслідків інциденту? Хто відповідає за прийняття рішень щодо резервного плану? Хто інформує клієнтів і supervises процес відновлення?

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

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

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