Коротка відповідь
Аварійний план — це не про технології, а про послідовність дій і контакти, зібрані в одному місці заздалегідь: хто має доступ до панелі хостингу, де лежать останні бекапи, кому писати в підтримку, і що робити в перші 15 хвилин після того, як помітили проблему.
Сценарій 1: сайт зламали
Ознаки: дивний контент на сторінках, попередження браузера чи Google Safe Browsing, скарги клієнтів, підозрілі листи з вашого домену в спамі отримувачів. Детальний покроковий розбір — у статті сайт зламали: порядок дій, поки не пізно. Коротко: зняти копію поточного стану до чистки (для розслідування), закрити скомпрометовані доступи, відновити з чистого бекапа, змінити всі паролі.
Сценарій 2: людська помилка (видалили не те, зламали оновленням)
Найчастіший і найменш драматичний випадок. Оновили плагін — сайт видає білий екран; випадково видалили директорію через файловий менеджер. Дії: не панікувати і нічого більше не видаляти, звернутися в підтримку з описом що саме й коли робили, попросити відновити конкретний компонент (файли чи базу) з останнього робочого бекапа. Механіка бекапів і що саме можна відновити — в статті як улаштовані щоденні бекапи поза сервером.
Сценарій 3: перевищено ліміт ресурсів
Сайт видає помилку 500 чи «Internal Server Error», хоча ніхто нічого не змінював — швидше за все, вичерпано ліміт CPU, пам'яті чи кількості процесів на тарифі. Це не аварія в класичному сенсі, а сигнал, що тариф замалий для поточного навантаження. Детальний розбір, як знайти причину в DirectAdmin і підняти сайт за 15 хвилин, — у статті «перевищено ліміт ресурсів»: що це означає і що робити.
Сценарій 4: DDoS-атака чи аномальний сплеск трафіку
Сайт відповідає повільно або не відповідає взагалі, при цьому в панелі видно різкий стрибок кількості запитів. Це може бути і DDoS-атака, і органічний сплеск (вірусний пост, велика розсилка). Як відрізнити одне від іншого і що робить Cloudflare, — в статті DDoS-атака на сайт: як розпізнати і що дає Cloudflare.
Сценарій 5: збій дата-центру чи блокаут поза вашим контролем
Найрідший, але й найважчий для власника сценарій — коли причина взагалі не на боці сайту, а в інфраструктурі: аварія в дата-центрі, масове відключення електроенергії в регіоні провайдера. Тут єдине, що реально допомагає, — розташування сервера поза зоною найбільшого ризику й моніторинг, який повідомляє про проблему першим. Детальніше — у статті безпека сайтів українського бізнесу під час війни.
Що зібрати в документ «на випадок аварії» вже сьогодні
- Логін і доступ до панелі DirectAdmin (і хто саме з команди ним володіє).
- Контакт підтримки хостингу — Telegram, пошта, номер тікет-системи.
- Доступи до реєстратора домену (окремо від хостингу — це часто інша компанія).
- Хто в команді ухвалює рішення «відкочуємось на бекап» без узгоджень по колу.
- Контакт розробника чи агентства, яке підтримує сайт, якщо це не ви самі.
Практика: половина «аварій», які виглядають страшно о другій ночі, — це перевищений ліміт ресурсів чи забутий пароль. Але коли документ із доступами лежить в одному місці, паніка минає за хвилину, а не за годину пошуків.
Різниця між "аварією" і "інцидентом": чому варто розділяти
Не кожна проблема на сайті — це аварія, що вимагає повного плану дій. Корисно подумки розділяти "інциденти" (тимчасова незручність, яку можна виправити в робочому порядку — наприклад, застаріла картинка на сторінці) і власне "аварії" (сайт недоступний, замовлення губляться, дані під загрозою). Це розділення допомагає командам не панікувати передчасно через дрібниці й водночас не гаяти час на "може, саме пройде" у ситуаціях, які вимагають негайної дії за планом.
Хто в компанії має знати про існування плану
План аварійного відновлення марний, якщо про нього знає тільки одна людина, яка може бути недоступна саме в момент кризи — у відпустці, поза зв'язком, чи (як показує практика воєнного часу) без електрики й інтернету водночас. Мінімум двоє людей у команді повинні знати, де лежить документ із планом, і мати доступ до нього незалежно один від одного. Це не питання довіри, а питання елементарної відмовостійкості самого процесу прийняття рішень.
Практика "холодного" тестування плану
Найкращий спосіб перевірити, чи справді план працює, — раз на кілька місяців влаштувати собі коротку вправу: уявити, що сайт щойно ліг через один із п'яти сценаріїв вище, і буквально пройти по документу, перевіряючи, чи всі контакти актуальні, чи паролі не змінилися без оновлення запису, чи людина, вказана відповідальною, досі працює в компанії. Двадцять хвилин раз на квартал коштують значно дешевше, ніж година розгубленості в реальний момент аварії.
Роль зовнішнього розробника чи агентства в плані
Якщо сайт підтримує зовнішній підрядник, а не власна команда, план аварійного відновлення обов'язково повинен включати контакт цього підрядника й чітку домовленість про час реакції — не абстрактне "по можливості", а конкретна узгоджена рамка (наприклад, "відповідь протягом 2 годин у робочий час"). Без такої домовленості власник бізнесу в момент аварії опиняється в ситуації, коли технічне рішення проблеми залежить від людини, з якою немає навіть базових очікувань щодо швидкості реакції.
Наскільки швидко реально відновлюють сайт на Meridaro
Чесно: не миттєво. Відновлення з бекапа — це ручна процедура адміністратора з перевіркою цілісності даних, яка займає в межах кількох годин. Автоматичного миттєвого перемикання на резервний сервер (failover) у поточній інфраструктурі немає. Це реалістичне число, а не маркетингове обіцяння — і саме тому важливо мати план і контакти зібраними заздалегідь, щоб не втрачати час на етапі «зрозуміти, що взагалі сталося».
Хто ухвалює рішення "відновлюємось із бекапа"
Важливий, але часто пропущений момент: відновлення з бекапа означає втрату всіх змін, зроблених між моментом останньої копії і моментом проблеми. Для сайту-візитки це майже не має значення. Для інтернет-магазину це може означати втрату кількох годин свіжих замовлень, якщо відкотити базу даних повністю. Тому рішення "відновлюємось" — це не суто технічне питання, а й бізнес-рішення: іноді краще відновити тільки файли (де стався злам), залишивши базу даних поточною, ніж втратити свіжі замовлення заради ідеально чистого стану файлів. Саме тому в команді має бути людина, яка розуміє бізнес-контекст і може прийняти це рішення швидко, а не тільки технічний виконавець.
План на одну сторінку: приклад структури
| Пункт | Що записати |
|---|---|
| Доступ до хостингу | Логін DirectAdmin + хто з команди володіє |
| Підтримка хостингу | Telegram/пошта Meridaro, номер тікета останньої взаємодії |
| Домен | Реєстратор, логін, дата закінчення реєстрації |
| Відповідальний за рішення | Ім'я і резервний контакт, якщо перший недоступний |
| Розробник/агентство | Контакт, доступ до репозиторію коду, якщо є |
Цю таблицю можна буквально скопіювати в текстовий документ, заповнити своїми даними й тримати в доступному, але захищеному місці — не в загальному чаті, а, наприклад, у менеджері паролів команди.