Пошук уроків, статей та іншого контенту
Розберете, що таке High Availability, як вимірювати доступність і читати показники uptime та SLA.
High Availability (HA), або висока доступність, — це здатність системи залишатися доступною для користувачів протягом потрібного часу навіть у разі відмови окремих компонентів.
Доступність відповідає на запитання:
Яку частину часу користувачі можуть успішно користуватися сервісом?
Висока доступність не означає, що система ніколи не помиляється. Вона означає, що:
відмови трапляються рідше;
несправності виявляються швидше;
відновлення займає менше часу;
відмова одного компонента не обов’язково зупиняє весь сервіс.
Наприклад, інтернет-магазин може залишатися доступним, якщо один сервер вийшов з ладу, а запити автоматично обробляються іншими серверами.
Доступність зазвичай виражають у відсотках:
[ Availability = \frac{Час\ роботи}{Загальний\ час} \times 100% ]
Або через час недоступності:
[ Availability = \frac{Загальний\ час - Час\ недоступності}{Загальний\ час} \times 100% ]
Наприклад, якщо сервіс працював 30 днів, але був недоступний 30 хвилин:
загальний час: 43 200 хвилин;
час роботи: 43 170 хвилин;
доступність: приблизно 99,93%.
Навіть невеликий відсоток недоступності може означати значний час для великого періоду.
Uptime — це час, протягом якого система доступна та виконує свої функції.
Приклад:
Сервіс мав uptime 99,95% за місяць.
Це означає, що протягом відповідного періоду він був доступним приблизно 99,95% часу.
Downtime — це час, протягом якого сервіс був недоступним або не міг коректно виконувати основні операції.
До downtime можуть належати:
повна недоступність сервісу;
помилки під час більшості запитів;
неможливість увійти в систему;
недоступність критичної функції, наприклад оплати.
Важливо заздалегідь визначити, що саме вважається недоступністю. Якщо сторінка відкривається, але кожен запит до API завершується помилкою, формально сервер може бути «працюючим», але сервіс для користувача недоступний.
Показник доступності краще розуміти не лише у відсотках, а й у допустимому часі недоступності.
Орієнтовні значення:
99% — приблизно 7 годин 18 хвилин недоступності на місяць;
99,9% — приблизно 43 хвилини 12 секунд на місяць;
99,99% — приблизно 4 хвилини 19 секунд на місяць;
99,999% — приблизно 26 секунд на місяць.
Ці значення залежать від тривалості конкретного місяця та від того, як саме організація рахує період.
Різниця між 99% і 99,9% здається невеликою — лише 0,9 процентного пункту. Але дозволений downtime зменшується з кількох годин до десятків хвилин.
Якщо період триває 30 днів, то його тривалість:
[ 30 \times 24 \times 60 = 43200\ хвилин ]
Для доступності 99,9% допустимий downtime:
[ 43200 \times (1 - 0,999) = 43,2\ хвилини ]
Отже, за місяць із 30 днями сервіс із доступністю 99,9% може бути недоступним приблизно 43 хвилини.
Ось невелика програма на JavaScript, яка обчислює допустимий downtime:
function allowedDowntime(days, availabilityPercent) {
const totalMinutes = days * 24 * 60;
const availablePart = availabilityPercent / 100;
const downtimeMinutes = totalMinutes * (1 - availablePart);
return downtimeMinutes;
}
const targets = [99, 99.9, 99.99, 99.999];
for (const target of targets) {
const downtime = allowedDowntime(30, target);
console.log(
`${target}%: ${downtime.toFixed(2)} хвилини недоступності за 30 днів`
);
}Результат буде приблизно таким:
99%: 432 хвилини недоступності за 30 днів
99.9%: 43.20 хвилини недоступності за 30 днів
99.99%: 4.32 хвилини недоступності за 30 днів
99.999%: 0.43 хвилини недоступності за 30 днівЩоб виміряти доступність, потрібно визначити:
Що перевіряємо — сайт, API, авторизацію чи певну бізнес-операцію.
Коли перевіряємо — постійно, щохвилини або за кожним реальним запитом.
Що вважається успіхом — наприклад, HTTP-відповідь із кодом 200 і часом відповіді до певного порогу.
Який період аналізуємо — годину, день, місяць або рік.
Як враховуємо планові роботи — включаємо їх у downtime чи виключаємо за правилами угоди.
Проста перевірка HTTP-коду не завжди достатня. Сервер може повернути 200 OK, але:
віддати порожні або неправильні дані;
не виконати операцію;
працювати настільки повільно, що користувач не може ним скористатися.
Тому вимірювання має наближатися до реального досвіду користувача.
Пасивний моніторинг аналізує реальні запити користувачів:
кількість успішних запитів;
кількість помилок;
час відповіді;
частку невдалих операцій.
Активний моніторинг самостійно виконує контрольні запити через певні проміжки часу:
відкриває головну сторінку;
перевіряє API;
виконує тестову авторизацію;
перевіряє критичний сценарій.
Найкраще використовувати обидва підходи. Активна перевірка може виявити проблему ще до появи реальних користувачів, а пасивна показує фактичний вплив на аудиторію.
Ці три поняття описують різні рівні роботи з метриками доступності.
SLI (Service Level Indicator) — конкретний вимір якості сервісу.
Приклади:
частка успішних HTTP-запитів;
частка успішних операцій оплати;
середній або процентильний час відповіді;
кількість доступних хвилин.
Наприклад:
За останню добу 99,95% запитів до API завершилися успішно.
Це значення є SLI.
SLO (Service Level Objective) — внутрішня ціль для SLI.
Приклад:
Не менше 99,9% запитів до API мають завершуватися успішно протягом календарного місяця.
SLO допомагає команді зрозуміти, який рівень надійності вона повинна підтримувати.
SLO може бути встановлений для:
усього сервісу;
окремого API;
критичної бізнес-операції;
конкретної групи користувачів.
SLA (Service Level Agreement) — формальна угода між постачальником сервісу та клієнтом.
У SLA зазвичай визначають:
гарантований рівень доступності;
період вимірювання;
правила обчислення;
винятки;
наслідки порушення, наприклад сервісні кредити.
Наприклад:
Постачальник гарантує доступність API не нижче 99,9% за календарний місяць.
SLA є договірним зобов’язанням, SLO — ціллю команди, а SLI — фактичним вимірюванням.
Часто внутрішній SLO роблять трохи суворішим за зовнішній SLA. Наприклад, клієнтам гарантують 99,9%, а команда планує підтримувати 99,95%. Це залишає запас для помилок вимірювання та несподіваних інцидентів.
Error budget, або бюджет помилок, — це допустима частина часу чи запитів, які можуть бути невдалими без порушення SLO.
Якщо SLO дорівнює 99,9%, бюджет помилок становить:
[ 100% - 99,9% = 0,1% ]
За 30 днів це приблизно 43,2 хвилини недоступності.
Бюджет помилок допомагає знаходити баланс між стабільністю та змінами:
якщо бюджет майже не використаний, команда може безпечніше випускати нові зміни;
якщо бюджет вичерпано, варто зосередитися на надійності та виправленні причин інцидентів;
якщо команда регулярно перевищує бюджет, поточні процеси або архітектура не відповідають цілі.
Це не означає, що команда «має право» витратити весь бюджет. Це інструмент для прийняття рішень і керування ризиком.
Однакова доступність не потрібна для всіх систем.
Наприклад:
внутрішній інструмент, яким користуються лише в робочі години, може мати нижчу ціль;
сервіс онлайн-платежів потребує дуже високої доступності;
система моніторингу аварій може вимагати доступності протягом усього часу;
інформаційний сайт може тимчасово показувати кешовані дані під час проблем із основною системою.
Під час визначення цілі потрібно враховувати:
вплив недоступності на користувачів;
фінансові втрати;
вимоги бізнесу;
час, коли сервіс має бути доступним;
вартість забезпечення вищої доступності;
залежності від зовнішніх сервісів.
Вища доступність майже завжди потребує додаткових ресурсів: резервних компонентів, моніторингу, автоматичного перемикання та складніших процедур експлуатації.
Тому ціль 99,999% не є автоматично кращою за 99,9%. Вона має бути виправдана вимогами продукту.
Система часто складається з кількох компонентів. Якщо для виконання операції потрібні всі вони, доступність усієї операції може бути нижчою за доступність кожного компонента.
Наприклад, запит залежить від:
вебсервера;
бази даних;
сервісу авторизації.
Якщо будь-який компонент недоступний, операція може завершитися помилкою.
Для незалежних компонентів із послідовною залежністю приблизну доступність можна оцінити як добуток:
[ A_{system} = A_1 \times A_2 \times A_3 ]
Якщо кожен компонент має доступність 99,9%:
[ 0,999 \times 0,999 \times 0,999 \approx 99,7% ]
Це спрощена модель. У реальній системі результат залежить від резервування, кешування, повторних спроб і способу обробки відмов. Проте вона показує важливу ідею: багато обов’язкових залежностей можуть зменшувати загальну доступність.
MTTF (Mean Time To Failure) — середній час до відмови компонента або системи.
Що вищий MTTF, то рідше в середньому трапляються відмови.
MTTR (Mean Time To Recovery або Repair) — середній час від початку відмови до відновлення роботи.
Що нижчий MTTR, то швидше система повертається до нормальної роботи.
Доступність можна приблизно оцінити так:
[ Availability \approx \frac{MTTF}{MTTF + MTTR} ]
Наприклад, якщо відмова в середньому трапляється раз на 1000 годин, а відновлення займає 1 годину:
[ Availability \approx \frac{1000}{1000 + 1} \approx 99,9% ]
Ця формула спрощена, але вона демонструє два способи покращення доступності:
збільшити час між відмовами;
зменшити час відновлення.
На практиці скорочення MTTR часто є найшвидшим способом зменшити downtime.
На базовому рівні високу доступність забезпечують такими підходами:
резервування критичних компонентів;
запуск кількох екземплярів сервісу;
автоматичне перемикання на резервний компонент;
регулярні перевірки працездатності;
швидке сповіщення про проблеми;
автоматичне відновлення після типових відмов;
безпечне розгортання змін;
документовані процедури реагування на інциденти.
Проте сам факт наявності двох серверів не гарантує високу доступність. Якщо обидва залежать від одного несправного компонента або оновлюються одночасно, відмова цього спільного елемента все одно може зупинити систему.
Сервер може бути запущений, але основна функція може не працювати. Доступність потрібно вимірювати через результат, важливий для користувача.
99,9% дозволяє приблизно 43 хвилини недоступності за 30 днів. Для критичного сервісу цього може бути багато.
99,9% за годину, місяць і рік — це різні за змістом показники. У звіті завжди потрібно вказувати період.
Якщо сервіс доступний для 90% користувачів, але недоступний для решти, це не обов’язково можна описати як «сервіс працює». Метрика має враховувати масштаб впливу.
SLA — це угода з клієнтом. Внутрішні технічні цілі зазвичай називають SLO, а фактичні вимірювання — SLI.
Сам відсоток не пояснює причину проблеми. Для роботи з надійністю також важливо аналізувати кількість інцидентів, їхню тривалість і час відновлення.
High Availability — здатність сервісу залишатися доступним і відновлюватися після відмов.
Uptime — час роботи сервісу, а downtime — час його недоступності.
Доступність вимірюють як частку часу або успішних операцій у загальному обсязі.
Навіть невелике зменшення відсотка доступності може означати багато хвилин або годин downtime.
SLI — фактична метрика, SLO — внутрішня ціль, SLA — формальна угода з клієнтом.
Error budget показує допустимий рівень помилок до порушення SLO.
На доступність впливають частота відмов і швидкість відновлення: важливі MTTF та MTTR.
Ціль доступності потрібно вибирати відповідно до впливу сервісу на користувачів і бізнес, а не просто прагнути до найбільшого відсотка.