Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

03.02.2025

Обробка відмови в умовах високої надійності

Давайте продовжу тему цього посту та розкажу про власний досвід виконання вимог високої надійності.

Питання там стоїть таке: що повинен робити сервіс, залежність якого (база, наприклад) недоступна: 1) валитися напрочуд, чи 2) відмовляти клієнтам та чекати відновлення бази? Я погоджуюся, що краще друге, але на те в мене є ще декілька причин.

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

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

Далі. Можна подумати, що якщо БД лежить, то все одно немає чого робити. Але на практиці найчастіше відмови БД трапляються в момент її оновлення чи іншого обслуговування. Тобто у цілком штатній ситуації. Навіть коли є резерв (а він завжди потрібний!), перемикання бодай одноразово, але викликає помилку.

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

До речі, щодо оточень, де помилки легко можуть вести до вивалювання сервісу — можу запропонувати Go - там паніка (тобто “виняток”, помилка без явної передачі) в будь-якому з потоків моментально кладе весь процес.