Моніторинг доступності сайту: як налаштувати uptime-контроль, сповіщення та SLA

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

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

Коротка відповідь

Для звичайного бізнес-сайту варто перевіряти головну сторінку та одну критичну сторінку щохвилини або кожні п’ять хвилин із кількох локацій. Успішною вважається не просто відповідь сервера, а правильний HTTP-код, прийнятний час відповіді, наявність контрольного тексту та коректний SSL-сертифікат.

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

Що таке uptime і чому 100% майже нічого не пояснює

Uptime — частка часу, протягом якого ресурс вважається доступним за заданими правилами. Формула проста:

uptime = успішний час / увесь вимірюваний час × 100%.

Ключове слово тут — «вважається». Якщо сервіс перевіряє лише наявність будь-якої HTTP-відповіді, сторінка з повідомленням «технічні роботи» та кодом 200 потрапить у зелену статистику. Якщо перевірка йде лише з однієї країни, вона не помітить регіональну проблему DNS або CDN. Якщо інтервал становить 30 хвилин, короткі, але регулярні збої можуть загубитися.

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

П’ять рівнів моніторингу

1. DNS і мережевий маршрут

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

Після будь-якої зміни корисно звірити DNS-записи A, AAAA, CNAME, MX і TXT та залишити моніторинг із кількох регіонів до завершення поширення змін.

2. HTTP-статус і час відповіді

Базова перевірка надсилає GET або HEAD на конкретний URL. Очікуваний результат для звичайної сторінки — код 200; для адреси зі штатним перенаправленням може бути 301 або 308. Коди 500, 502, 503 і 504 вказують на серверну проблему, але не всі поломки повертають 5xx.

Фіксуйте також затримку. Сайт може формально працювати, але відповідати 15 секунд, через що користувачі закривають сторінку, а рекламні переходи витрачаються. Для розбору затримок стане в пригоді окремий матеріал про TTFB, Core Web Vitals і перевірку швидкості сайту.

3. Контроль вмісту

Перевірка має шукати стабільний фрагмент сторінки: назву компанії, заголовок товару або технічний маркер, який присутній лише після успішного завантаження даних. Це знаходить «м’які» збої, коли сервер повертає 200, але шаблон порожній, база недоступна або замість сайту показано сторінку паркування домену.

Не обирайте текст, який маркетолог може змінити без попередження. Краще додати непомітний стабільний ідентифікатор у HTML або використовувати спеціальний health endpoint без секретних даних.

4. SSL і термін дії домену

Відстежуйте дні до завершення сертифіката, відповідність домену, повноту ланцюжка та підтримку потрібних імен. Автоподовження може зламатися через зміну DNS, прав доступу або конфігурації reverse proxy. Практичний порядок перевірки описано в матеріалі про SSL-сертифікат і виправлення HTTPS-помилок.

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

5. Синтетичні транзакції

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

Синтетичний тест не повинен створювати реальні замовлення, списувати кошти або забруднювати CRM. Використовуйте тестовий товар, окрему адресу, службову позначку та автоматичне очищення результатів.

Що саме моніторити

Не потрібно перевіряти кожну сторінку щохвилини. Виберіть кілька точок, що представляють реальний шлях клієнта, а повне сканування запускайте рідше.

Інтервал і кількість локацій

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

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

1. перша помилка запускає повторну перевірку;
2. інцидент підтверджується другою локацією;
3. повідомлення надсилається після двох-трьох невдач поспіль;
4. для критичного endpoint поріг зменшується;
5. після відновлення система також повідомляє про нормалізацію.

Так зменшується шум без небезпечної затримки.

Як уникнути хибних тривог

Найгірший моніторинг — той, повідомлення якого перестають читати. Хибні спрацювання виникають через короткі розриви мережі, блокування IP перевіряльника, надто суворий поріг часу, планові роботи або нестабільний тестовий сценарій.

Для кожної перевірки задайте:

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

Не додавайте IP моніторингу в безумовний білий список, якщо це дозволяє обійти реальний захист. Перевірка має проходити максимально близький до клієнтського маршрут, але тестові запити можна чітко позначити в User-Agent і логах.

Сповіщення та ескалація

Email доречний для звіту, але слабкий як єдиний канал критичної тривоги. Повідомлення про падіння checkout краще дублювати в месенджер, push або телефонний канал. Водночас не варто будити всю команду через один повільний запит.

Матриця може виглядати так:

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

SLI, SLO і SLA без плутанини

SLI — фактичний показник, наприклад частка успішних запитів або частка хвилин, коли checkout працював.
SLO — внутрішня ціль команди, наприклад 99,9% доступності за місяць.
SLA — домовленість із клієнтом або провайдером, яка описує рівень сервісу, спосіб вимірювання, винятки та наслідки порушення.

SLA не слід зводити до красивого відсотка. Документ має визначити об’єкт перевірки, часовий пояс, період розрахунку, планові роботи, залежності від сторонніх систем, момент початку інциденту, строк реакції та формат компенсації.

Скільки простою приховують «дев’ятки»

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

Що робити після сповіщення

Моніторинг без плану реакції лише швидше повідомляє про проблему. Підготуйте короткий runbook:

1. Підтвердити збій із незалежної мережі та кількох локацій.
2. Визначити рівень: DNS, CDN, SSL, сервер, CMS, база, стороннє API чи конкретна функція.
3. Перевірити останні розгортання, оновлення, імпорти та зміни конфігурації.
4. За можливості швидко відкотити останню зміну або переключити трафік.
5. Не очищати логи й не перезапускати все без фіксації симптомів.
6. Повідомити бізнесу про вплив і наступний контрольний час.
7. Після відновлення перевірити форми, оплату, пошту, CRM та аналітику.
8. Записати причину, тривалість, втрати та запобіжну дію.

Якщо проблема пов’язана зі зламом, дійте за окремим чеклістом перевірки сайту на віруси. Якщо потрібен відкат, використовуйте лише перевірену резервну копію сайту, а не перший знайдений архів.

Налаштування за один робочий день

Крок 1. Визначте критичні шляхи

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

Крок 2. Створіть базові перевірки

Додайте головну, одну комерційну сторінку та критичний endpoint. Перевіряйте код, контрольний текст, TLS і затримку. Увімкніть дві-три географічні локації.

Крок 3. Налаштуйте пороги

Для звичайної сторінки почніть з інтервалу 5 хвилин і трьох невдалих перевірок; для checkout — з 1 хвилини та двох невдач. Пороги швидкості задавайте за власною стабільною базовою лінією, а не випадковою «ідеальною» цифрою.

Крок 4. Побудуйте маршрути повідомлень

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

Крок 5. Проведіть навчальну аварію

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

Типові помилки

• контролюється лише головна сторінка;
• будь-який код відповіді вважається успіхом;
• не перевіряється вміст сторінки;
• усі запити йдуть з одного регіону;
• повідомлення надсилаються лише на email людини у відпустці;
• немає сповіщення про відновлення;
• планові роботи не позначаються;
• моніторинг працює з того самого сервера, який перевіряє;
• ніхто не тестує канали сповіщень;
• uptime рахують без опису методики;
• після інциденту не усувають системну причину.

Чекліст власника сайту

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

Висновок

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

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

Часті запитання

Як часто перевіряти доступність сайту?

Для звичайного бізнес-сайту достатньо інтервалу 1–5 хвилин. Для checkout, API або рекламної посадкової з великим бюджетом краще одна хвилина. Щоб не реагувати на випадковий мережевий збій, підтверджуйте проблему повторною перевіркою з іншої локації.

Чи достатньо перевіряти код 200?

Ні. Сервер може повернути 200 OK разом із порожнім шаблоном, повідомленням про помилку або сторінкою паркування. Перевіряйте також контрольний текст, час відповіді, SSL і, для критичних процесів, повний тестовий сценарій.

Який uptime потрібен бізнес-сайту?

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

Чому моніторинг показує збій, а сайт відкривається?

Причиною може бути короткий збій, проблема лише в одному регіоні, блокування IP перевіряльника, повільна відповідь або помилка конкретного URL. Звірте час, локації, код, логи CDN і сервера, а потім скоригуйте поріг лише після підтвердження причини.

Хто має реагувати на повідомлення про падіння сайту?

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