Коли система падає – бізнес зупиняється. Кожна хвилина простою означає втрату грошей, клієнтів і довіри. Завдання інженера — забезпечити безперервну роботу 24/7.
Інженери Solidgate дбають про стабільність системи, яка щомісяця обробляє десятки мільйонів транзакцій. В її основі – платформа для оркестрації та процесингу платежів. Вона дає бізнесам можливість підключати різних платіжних провайдерів і керувати ними так, щоб платежі проходили без збоїв. Якщо один провайдер «падає» – система автоматично переключає на резервний.
Крім цього, Solidgate розвиває й інші сервіси: менеджмент підписок, банкінг для бізнесу, захист від шахрайства тощо.
Клієнти Solidgate — компанії, що створюють продукти, якими щодня користуються мільйони людей. Для таких бізнесів навіть хвилина даунтайму платіжної системи може коштувати десятки тисяч доларів. Якщо процесинг зупиняється, тисячі транзакцій не проходять: хтось не може викликати таксі, отримати посилку чи взяти в прокат фільм для вечора із сім’єю.
Саме тому в Solidgate аптайм — не формальність, а питання ціни помилки, і вимоги до нього визначають роботу всієї команди.
У цьому матеріалі ми разом із Solidgate розбираємося, що стоїть за стабільним аптаймом. А ще пропонуємо тобі спробувати себе в ролі фінтех-інженера.
В інтерактивному симуляторі ти маєш тримати систему на плаву якомога довше та швидко реагувати на інциденти. Шукай його внизу сторінки й перевір свої навички.
Fintech
x
solidgate
x
game
Як великі збої впливають на сервіси та користувачів
Збій Cloudflare
У січні 2023 року під час оновлення, яке мало додати поле «last seen» у метадані «service-tokens», сталася помилка: важливі дані токенів перезаписалися. Через це частина токенів стала недійсною, і збої торкнулися внутрішніх акаунтів та сервісів.
Близько двох годин (121 хвилину) окремі сервіси Cloudflare – зокрема Workers, Zero Trust і control plane CDN – працювали з перебоями або були недоступні. Це зачепило частину клієнтів компанії.
01
Google Cloud Platform – глобальний збій API-сервісів
У червні 2025 року стався масштабний збій у Google Cloud. Постраждали основні сервіси – API Gateway, Apigee, BigQuery, Cloud Run, Cloud DNS, Compute Engine та інші.
Інцидент тривав понад 7 годин і мав глобальний масштаб: сервіси були частково або повністю недоступні в усьому світі. Це спричинило помилки API, проблеми з деплоєм, запуском сервісів та логуванням.
Так одна платформа зачепила десятки сервісів одночасно.
02
Збій CrowdStrike – вплив на Delta Air Lines та інші сектори
У липні 2024 року оновлення Falcon Sensor від CrowdStrike спричинило збій більш як на 8 мільйонах Windows-пристроїв. Це викликало глобальний даунтайм і серйозно вдарило по авіакомпаніях, банках, медичних закладах та медіа.
Delta Air Lines, яка використовувала CrowdStrike, зазнала особливо великих втрат:
скасовано близько 7 000 рейсів;
постраждали 1,3 млн пасажирів;
збитки оцінили приблизно у $550 млн.
03
Як не допустити фейлів:
що таке SRE-практики
Щоб система працювала стабільно і користувачі не бачили «помилку 500», у Solidgate застосовують SRE-практики. Це підходи, які допомагають командам тримати аптайм під контролем.
SRE (Site Reliability Engineering) з’явився в Google ще у 2000-х. Тоді потрібно було зробити сервіси і масштабованими, і надійними, не сповільнюючи розвиток. Замість класичної моделі «адміни підтримують, розробники пишуть код», Google поєднали інженерію з операційними процесами та автоматизацією.
Суть проста: стабільність сервісу вимірюють метриками, а інциденти й релізи обробляють за чіткими правилами. Так народилась ціла культура, і з часом SRE став стандартом для гігантів на кшталт Meta, Netflix, Amazon чи Cloudflare.
Ми підготували короткий чекліст із практиками, який стане у пригоді тим, хто будує надійні сервіси. І для тих, хто хоче краще пройти гру.
Метрики та цілі
Щоб оцінити надійність системи, важливо визначити чіткі метрики та цілі.
Ми підготували короткий чекліст із практиками, який стане у пригоді тим, хто будує надійні сервіси. І для тих, хто хоче краще пройти гру.
SLI (Service Level Indicator) – те, як ми міряємо якість сервісу (наприклад, відсоток успішних запитів).
SLO (Service Level Objective) – яку ціль ставимо (наприклад, 99,99% аптайму).
SLA (Service Level Agreement) – що гарантуємо користувачеві.
Error Budget
Це «допустимий запас» на помилки. Якщо ціль – 99,99% аптайму, то 0,01% збоїв ще ок. Але якщо цей ліміт вичерпано – нові фічі ставимо на паузу і працюємо над стабільністю.
Моніторинг і алертинг
Щоб вчасно помітити проблеми, важливо відстежувати основні метрики:
latency – швидкість відповіді;
saturation – наскільки завантажені ресурси;
error rate – кількість помилок;
availability – доступність сервісу.
Алерти варто налаштовувати так, щоб вони спрацьовували лише в разі реальних проблем для користувачів, а не в разі незначних відхилень.
Інцидент-менеджмент
Коли щось ламається – потрібен заздалегідь узгоджений та чіткий процес: хто on-call, як швидко реагувати, як відновлювати сервіс і що комунікувати назовні. Це зменшує хаос і час простою.
Postmortems і навчання
Після інциденту варто робити його аналіз без пошуку винних. Головне завдання – знайти справжні причини його виникнення, зрозуміти, що можна зробити краще, та запобігти повторенню.
Автоматизація і
стрес-тести
Менше ручної роботи – менше помилок. Тож варто застосовувати self-healing механізми, автоматичні деплої та скейлінг.
Через chaos engineering і стрес-тести система перевіряється на міцність – це дає впевненість, що вона витримає реальні навантаження.
SRE – доволі нова дисципліна, і для глибшого розуміння варто звернутися до фундаментальних текстів інженерів Google та практиків індустрії.
Вони пояснюють усе по-кроково: від базових принципів аптайму до побудови зрілих процесів у великих командах.
Fintech
x
solidgate
x
game
Як вимоги по аптайму впливають на роботу інженерів Solidgate?
Владислав Павленко
Go Engineer
Оскільки моя команда займається розробкою найбільш наближених до кінцевих користувачів платіж...
Владислав Павленко
Go Engineer
Оскільки моя команда займається розробкою найбільш наближених до кінцевих користувачів платіжних інтерфейсів компанії, відчувається велика відповідальність у процесі деплою певних змін у логіці їхньої роботи.
Під час розробки ми дотримуємося принципу Trunk Based Development: великі зміни розбиваємо на менші атомарні частини, які простіше прорев’ювити й безпечніше виливати у прод поступово. Це допомагає, зокрема, якісніше підсвідомо декомпозувати завдання і глибше продумувати реалізацію. Під час деяких деплоїв я стежу за метриками та логами, щоб одразу реагувати у разі потреби.
Михайло Кратюк
Backend Engineer
Наші інженери думають не лише про те, як «пиляти фічі», а й про те, як робити це архітектурно. Я перевіряю к...
Михайло Кратюк
Backend Engineer
Наші інженери думають не лише про те, як «пиляти фічі», а й про те, як робити це архітектурно. Я перевіряю кожне своє рішення, і ось мої основні критерії: закон Мерфі, людський фактор та, звісно, down time.
1.
Якщо щось може піти не так – напиши fallback, який допоможе виграти час до розв’язання проблеми і навіть стати повноцінною заміною.
2.
Ніколи не сподівайся, що люди будуть дотримуватися правил – натомість створюй автоматизовані перевірки, які будуть форсити дотримування цих правил.
3.
Downtime виникає не лише через відмову компонентів системи. Навіть звичайний деплой, коли одночасно працюють дві версії сервісу, може стати причиною інциденту – наприклад, різниця в обробці повідомлень.
Тому щоразу задаюсь питанням, як зробити переключення ще більш безшовним.
Вимога високого аптайму постійно тримає у фокусі не лише якість коду, а й дизайн системи. За моїми рішеннями стоять не просто абстрактні графіки і цифри у статистиці, а реальний користувач, який намагається замовити таксі за 15 хвилин до комендантської години.
Артем Полубок
Senior Engineering Manager
Щоб досягти високого uptime, потрібно прагнути не системи, яка ніколи не падає, а системи, яка вміє падати...
Артем Полубок
Senior Engineering Manager
Щоб досягти високого uptime, потрібно прагнути не системи, яка ніколи не падає, а системи, яка вміє падати правильно.
«Падати правильно» – це реалізація підходів graceful degradation; наявність redundancy та failover; rate limiting та circuit breaker, які дають змогу ізолювати вплив проблем, пов'язаних із навантаженням;
це моніторинг, який покаже й повідомить про проблеми на ранніх етапах, та інструменти, завдяки яким можна ефективно відновити сервіс під час інциденту.Основні причини, які призводять до проблем, – це зміни системи та людський фактор. Тож ми будуємо системи, що максимально автоматизують зворотний зв'язок на всіх етапах розробки, щоб скоротити ймовірність помилок, які досягнуть користувача. «Падати правильно» – це реалізація підходів graceful degradation; наявність redundancy та failover; rate limiting та circuit breaker, які дають змогу ізолювати вплив проблем, пов'язаних із навантаженням;
Однак система все одно буде падати, і робитиме це новими неочікуваними способами, тому потрібно мати процес, який дасть змогу максимально ефективно її відновлювати, і процес, який допоможе робити висновки з минулих інцидентів та усувати системні недоліки, що були першопричиною.
Сергій Радиховський
Tech Lead
У своїй команді я налаштував duty-процес, під час якого відповідальний інженер реагує та опрацьов...
Сергій Радиховський
Tech Lead
У своїй команді я налаштував duty-процес, під час якого відповідальний інженер реагує та опрацьовує всі алерти, що виникають у наших сервісах. Жоден випадок не має залишатися без уваги: якщо було спрацювання, результатом обов'язково має бути або Merge Request із розв’язанням проблеми, або створене завдання. Ігнорування хронічних проблем породжує шум, який у майбутньому не дає змоги швидко зреагувати на справді критичну ситуацію.
За останній місяць нам вдалося скоротити кількість таких випадків удвічі. Для критичного функціоналу ми застосовуємо підхід Click it Through як фінальну перевірку, яку виконує інженер. Хоч у нас і налаштовано автоматичний ролбек деплою у разі аномалій (наприклад, велика кількість помилок у логах чи 5xx response code), важливі зміни все одно варто перевірити вручну. Зазвичай за логами, метриками та записами в базі зрозуміло, чи все працює належним чином, за винятком edge cases, які складно або неможливо змоделювати.
У шаблоні документів, що описують технічні рішення (Architecture Decision Record), було також додано окрему секцію Fault tolerance, яку необхідно враховувати та опрацьовувати для всіх нових змін. Отже, у новому функціоналі питанню uptime буде приділятися особлива увага, зокрема, мітигації наслідків відмови залежностей сервісу.
uptime
99.99%
Ти — інженер фінтех-компанії
Мета – утримати аптайм якомога довше, реагуючи на інфраструктурні інциденти. Після кожної відповіді з’являється новий інцидент. У тебе є до 12 секунд, щоб обрати одне з рішень. Якщо нічого не зробити – застосовується наслідок «за замовчуванням». Кожне рішення впливає на uptime %, який змінюється в реальному часі.
Uptime CTO
Система працює стабільно. Це зона високої надійності, де ви майже не втрачаєте контроль. Візуально – все спокійно, без тривожних сигналів.
01
Stripe заблокував платежі через підозру в фроді
time
00:06
Система працює стабільно. Це зона високої надійності, де ви майже не втрачаєте контроль. Візуально – все спокійно, без тривожних сигналів.
Вітаємо, майстре стабільності!
Ви тримали систему на плаву як справжній SRE-інженер Solidgate. Жоден провайдер не "впав" надовго, транзакції оброблялися безперервно, а клієнти навіть не помітили потенційних інцидентів.