Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
21.10.2025
Fail Fast проти Hang In There
Є дві протилежні поведінки застосунку, коли виникають проблеми з його залежностями, або взагалі непередбачені ситуації. (Назви я тільки що вигадав.)
Fail Fast: якщо ми опинилися в ненормальному стані, то за майже визначенням програма не зможе з нього вибратись. Отже, краще, що можна зробити — це зупинити застосунок та дозволити супервайзеру запустити його наново. Переваги цього підходу: з чистого аркуша не виникне внутрішніх розбіжностей, бо ми точно знаємо, що кожна підсистема буде знову в передбаченому стані. Плюс, такий підхід робить застосунок простіше.
Hang In There: застосунок повинен триматися, хай би що трапилося. Кожну помилку пробувати наново. За браком залежності продовжувати без неї, в обмеженому режимі. Взагалі ніколи не зупиняти застосунок, поки не отримаємо на то сигнал. Переваги тут — що не буде перезапуску, власне.
Обидва підходи мають своє застосування. Колись я вважав, що в сучасній інфраструктурі з контейнерами Fail Fast - очевидний вибір. Але дедалі більше хочеться робити застосунки, які не будуть перезапускатися. Зокрема, перезапуск ризикує зробити із поганого гірше, як зі мною вже траплялось.
Вчорашній простій AWS us-east-1 це підкреслив, бо в нашому випадку найдовше не було можливості запускати нові задачі. Отже, те, що трималося — працювало, а те, що очікувало на перезапуск — просто впало до закінчення інциденту. (До речі, також не могли стартувати лямбди, а вони можуть бути тільки Fail Fast.)
Хоча здається, був і протилежний приклад: черги SQS не спричинили відмову споживачів, а просто припинили доставляти повідомлення до перезапуску клієнтів. Поки не зрозумів, чому так сталося.