• У панелі все зелене, а сайт не працює
• Спочатку домовтеся, скільки часу й даних можна втратити
  • RTO: скільки часу сервіс може не працювати
  • RPO: скільки даних можна втратити
• Копія, яку ніхто не відновлював, ще не є страховкою
  • Копія повинна пережити втрату основного сервера
• Сервер справний, але запит до нього не доходить
• Коли одного сервера вже недостатньо
• Моніторинг має попереджати, а не створювати шум
  • Перевіряйте сервіс із зовнішньої точки
  • Сповіщення має підказувати наступну дію
• Найнебезпечніша зміна — та, для якої немає шляху назад
• Що робити, коли сервіс уже недоступний
• Чек-лист, який варто пройти до аварії
  • Інфраструктура
  • Резервні копії
  • Домен і TLS
  • Моніторинг і зміни
  • Відновлення

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

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

Матеріал підготовлено за участю технічної команди UkrLine, яка працює з хостинговою інфраструктурою українських проєктів.

У панелі все зелене, а сайт не працює

Доступний VPS ще не означає, що доступний бізнес-сервіс. Сервер може відповідати на ping, але вебсервер уже не приймає з’єднання, PHP-FPM завис, база даних відхиляє запити або API повертає помилку 500. Для клієнта технічна причина не має значення: сторінка не відкривається, замовлення не оформлюється або особистий кабінет не працює.

Тому моніторити лише IP-адресу недостатньо. Базова зовнішня перевірка має показувати щонайменше HTTP-код і час відповіді:

curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://domain.ua/

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

Спочатку домовтеся, скільки часу й даних можна втратити

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

RTO: скільки часу сервіс може не працювати

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

RPO: скільки даних можна втратити

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

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

Копія, яку ніхто не відновлював, ще не є страховкою

Надійною можна вважати лише ту резервну копію, яку можна прочитати, розпакувати й відновити на окремому середовищі. Повідомлення «Backup completed» саме по собі нічого не гарантує: архів може бути неповним, база — пошкодженою, а всі копії — зберігатися на тому самому диску, який щойно вийшов із ладу.

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

Копія повинна пережити втрату основного сервера

Копія на тому самому VPS допоможе після випадкового видалення файлу, але не врятує після втрати вузла, диска або доступу до облікового запису. Практичний мінімум — зберігати одну копію поза основним сервером. Для важливих даних корисний принцип 3-2-1: кілька копій, різні носії або сховища, принаймні одна копія окремо від робочої системи.

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

Сервер справний, але запит до нього не доходить

Якщо сервер справний, а користувачі все одно не можуть відкрити сайт, проблему потрібно окремо шукати в DNS, домені та TLS. Перезапуск вебсервера тут може нічого не змінити, оскільки запит іноді взагалі не доходить до основного вузла.

Перевірка dig domain.ua допоможе побачити A, AAAA та NS-записи й фактичну адресу, на яку спрямовано домен. Особливої уваги потребує IPv6: старий AAAA-запис інколи залишається непоміченим, через що частина користувачів потрапляє на неактуальний сервер.

TLS можна перевірити через curl -Iv https://domain.ua/ або openssl s_client. Окремо потрібно контролювати строк продовження домену, сертифіката й доступ до реєстратора. Втрата доменного імені або DNS-акаунта може бути критичнішою за збій одного VPS, тому що швидко розгорнути копію в такій ситуації недостатньо.

Коли одного сервера вже недостатньо

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

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

Моніторинг має попереджати, а не створювати шум

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

Для невеликого VPS достатньо контролювати HTTPS, час відповіді, помилки 5xx, CPU, оперативну пам’ять, swap, дисковий простір, inode, стан критичних служб і результат останнього резервного копіювання. Базову діагностику дають uptime, free -h, df -h, df -i та журнали системи.

Перевіряйте сервіс із зовнішньої точки

Моніторинг на тому самому VPS не побачить повну недоступність вузла або частину мережевих проблем. Тому HTTP- і TLS-перевірки мають надходити ззовні. Для простої інфраструктури підійде кілька точних перевірок; складний набір графіків не допоможе, якщо його ніхто не переглядає.

Сповіщення має підказувати наступну дію

Повідомлення «CPU high» без назви вузла, значення й тривалості швидко перетворюється на шум. Корисне сповіщення містить контекст: який сервіс постраждав, коли почалася проблема, яка метрика перевищила поріг і хто має реагувати. Після налаштування алерт потрібно один раз перевірити на тестовій службі, щоб переконатися, що він доходить до відповідальної людини.

Найнебезпечніша зміна — та, для якої немає шляху назад

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

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

Навіть для невеликого проєкту достатньо послідовності: зміна → тестування → розгортання → перевірка → відкат у разі проблеми. Складна система автоматизації не обов’язкова, але порядок змін потрібен навіть на одному сервері.

Що робити, коли сервіс уже недоступний

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

1. Перевірити проблему ззовні: HTTP-код, DNS, TLS і час відповіді.
2. Визначити масштаб: один URL, весь сайт, API, база даних або весь VPS.
3. З’ясувати, що змінювали безпосередньо перед збоєм.
4. Зафіксувати стан: час, навантаження, пам’ять, диск і помилки служб.
5. Зібрати актуальні журнали вебсервера, застосунку та бази даних.
6. Стабілізувати сервіс: виконати відкат, запустити службу, перейти на резервний вузол або відновитися з копії.
7. Після відновлення знайти першопричину й усунути умови повторення.

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

Чек-лист, який варто пройти до аварії

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

Інфраструктура

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

Резервні копії

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

Домен і TLS

• Контролюються строки продовження домену та сертифіката.
• Відомо, хто має доступ до реєстратора й DNS.
• Перевірені актуальні A, AAAA та NS-записи.

Моніторинг і зміни

• HTTPS перевіряється із зовнішньої точки.
• Контролюються 5xx, ресурси сервера та критичні служби.
• Перед ризикованим оновленням існує резервна копія або snapshot.
• Після розгортання перевіряються ключові бізнес-функції.

Відновлення

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

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

Резервні вузли, реплікацію та складніші схеми варто додавати тоді, коли цього вимагають RTO, RPO і реальна вартість простою. У такому разі інфраструктурні витрати перетворюються з абстрактної «страховки» на зрозумілий інструмент керування бізнес-ризиками.