Аптайм 99,9%: сколько это минут и какой нужен интервал проверки

«Аптайм 99,9%» пишут в договорах хостинга, на статус-страницах и в отчётах мониторинга. Цифра одна, а считают её по-разному. Ниже — сколько минут стоит за каждой девяткой, как доступность определяют в книгах Google по SRE и какой интервал проверки нужен, чтобы процент в отчёте хоть что-то значил.

TL;DR

1. 99,9% — это 43 минуты простоя за 30 дней или 8 часов 46 минут за год. 99,99% — 4 минуты 19 секунд за 30 дней.
2. Внешняя проверка измеряет доступность по времени: сколько проб прошло, сколько нет. Точность такого замера не лучше одного интервала проверки.
3. Сбой короче интервала проверка ловит только с вероятностью «длина сбоя, делённая на интервал». Двухминутное падение при проверке раз в 5 минут попадёт в отчёт примерно в 40% случаев.
4. Интервал подбирают под цель. Для 99,9% в год хватает проверки раз в несколько минут. Для 99,99% в месяц нужен шаг в десятки секунд. 99,999% в месяц внешней проверкой честно не измерить.

Сколько минут в девятках

Для своего процента и периода быстрее посчитать в калькуляторе SLA. Дальше важнее не сами минуты, а период: одна и та же цифра за месяц и за год — разные обязательства. 99,9% за год разрешает один восьмичасовой простой. 99,9% за месяц — нет.

Два способа считать доступность

В книге Site Reliability Engineering, глава «Приручаем риски», есть обе формулы.

Первая — по времени: время безотказной работы, делённое на сумму времени работы и времени отключений. По ней получаются минуты из таблицы выше. В книге пример: 99,99% за год — не больше 52,56 минуты простоя.

Вторая — по запросам: успешные запросы, делённые на все. Google пишет, что для них первая формула почти бесполезна: их сервисы почти никогда не лежат целиком, часть трафика обслуживается всегда. Поэтому они считают долю успешных запросов в скользящем окне. Пример оттуда же: 2,5 млн запросов в день при цели 99,99% — можно потерять до 250 запросов.

Внешний мониторинг вроде PingMap видит первый вариант. Он не знает, сколько у вас было запросов. Он раз в интервал сам отправляет запрос и записывает «ответил» или «не ответил». Это нормально: книга называет долю успешных запросов допустимым приближением к доступности по времени, и обратное для небольшого сайта тоже верно. Просто надо понимать, с какой точностью этот замер работает.

Что проверка видит, а что нет

В той же книге, в главе про мониторинг распределённых систем, это названо методом чёрного ящика: наблюдение за симптомами, которые видит пользователь. В разделе про Borgmon объяснено, зачем он нужен при наличии внутренних метрик: внутренний мониторинг видит только запросы, которые дошли до сервиса. Запросы, которые упали на DNS или не дошли из-за сбоя сервера, для него не существуют. Внешняя проба их видит.

В The Site Reliability Workbook, глава 2, те же варианты сравниваются для одного показателя. Лог веб-сервера пропустит запросы, которые не дошли до бэкенда. Проба снаружи поймает ошибку, когда до вашей сети вообще нельзя достучаться, но может пропустить проблему, которая задела только часть пользователей. Замер в браузере пользователя точнее всего, но его надо встраивать в код и где-то хранить.

У внешней проверки есть ещё одно слепое пятно, и оно считается арифметикой.

Интервал проверки и точность процента

Проверка раз в 5 минут — это 288 проб в сутки и 8640 за 30 дней. Между пробами мониторинг ничего не знает о сайте.

Отсюда два эффекта.

Сбой длиннее интервала попадёт в отчёт всегда. Хотя бы одна проба придётся на него. Длительность будет измерена с погрешностью до одного интервала: начало сбоя где-то между последней успешной и первой неудачной пробой.

Сбой короче интервала попадёт в отчёт случайно. Вероятность — длина сбоя, делённая на интервал. Двухминутный сбой при проверке раз в 5 минут будет замечен в 40% случаев, при проверке раз в минуту — всегда.

Теперь приложим погрешность в один интервал к бюджету. Сколько бюджета за 30 дней занимает один интервал:

Если один шаг проверки больше, чем весь бюджет периода, процент в отчёте описывает расписание проверок, а не сайт. 99,99% за месяц при пятиминутной проверке — как раз такой случай.

С годовой целью картина другая. 99,9% за год — это 525 минут, и пять минут на их фоне меньше процента. Тут я сначала ошибся: думал, что пять минут для трёх девяток мало. В русском издании SRE, в разделе про детализацию измерений, написано ровно обратное. Если сервису обещано не больше 9 часов простоя в год, слать 1–2 проверочных запроса в минуту ради кода 200, скорее всего, лишнее. Так что чаще — не значит лучше. Сначала цель, потом частота.

Как это делали в Evernote

Самый полезный кусок Workbook для этой темы — третья глава, история Evernote после переезда в Google Cloud. Они обещали 99,95% за календарный месяц. Это примерно 22 минуты.

Проверка у них ходила на служебную страницу статуса. Страница дёргает почти весь стек и отвечает 200, если всё живо. Проверяли раз в минуту, со сторонних проб в Северной Америке и Европе — снаружи своей сети, чтобы ловить и падения балансировщиков. Интересно, как они определили «лежит». Одна неудачная проверка ставит узлу статус Unconfirmed Down, и тогда его проверяет вторая точка из другого региона. Только если и она не достучалась, минуты идут в простой.

Ещё одна деталь, которую легко пропустить: плановые работы они тоже считали простоем. Сотни миллионов пользователей объявлений не читают, для них сайт просто не открылся.

Минута против 22 минут бюджета — 4,6% на шаг, запас нормальный. А перепроверка вторым регионом спасает бюджет от сбоев сети у одной точки. У нас в PingMap логика та же: сбой засчитывается после перепроверки с других точек.

Маленький сайт и редкий трафик

В пятой главе Workbook есть пример, который хорошо ложится на небольшие сайты. Сервис получает 10 запросов в час и держит 99,9% за 30 дней. Одна неудачная попытка — сразу 13,9% месячного бюджета. На месяц таких ошибок всего семь. По реальным запросам доступность тут почти не посчитать: один случайный сбой выглядит как авария.

Что советует книга? Первым делом — нагнать искусственный трафик, чтобы появился сигнал. По сути это и есть внешняя проверка по расписанию: запросы идут ровно, есть посетители или нет.

Там же таблица про скорость сжигания бюджета. При 99,9% за 30 дней полный отказ съедает весь месяц за 43 минуты. Прикиньте свою схему уведомлений. Если алерт приходит после трёх неудач подряд с шагом 5 минут, вы узнаёте о падении минут через 15. Это уже треть месячного бюджета.

Как выбрать интервал

Я бы шёл так. Сначала решить, какой процент обещаете и за какой период, и перевести его в минуты. Потом взять интервал, который в разы меньше этих минут, чтобы одна проба не съедала заметный кусок месяца. Потом умножить число неудач до алерта на интервал и сравнить с тем же бюджетом.

И не обещать того, что не можете измерить. 99,999% за месяц — это 26 секунд. Такой бюджет меньше самого частого интервала внешней проверки.

По тарифам PingMap получается примерно так. На Free проверка раз в 5 минут, этого хватает для 99–99,5% и для 99,9% за год. На Solo от минуты — уже можно держать 99,9% и 99,95% за месяц. На Team от 30 секунд. Это та граница, с которой 99,99% за месяц хоть как-то видно.

Под конец — мысль из первой главы SRE, которая хорошо остужает. Между сервисом и пользователем стоят его ноутбук, домашний Wi-Fi, провайдер, электричество. Всё это вместе работает хуже, чем 99,999%. Разницу между пятью девятками и сотней пользователь не заметит. Лишняя девятка стоит денег, а видна она только в отчёте.

FAQ

Сколько минут простоя допускает 99,9%?

43 минуты 12 секунд за 30 дней, 8 часов 45 минут за год. Для 99,99% — 4 минуты 19 секунд за 30 дней и 52,56 минуты за год.

Почему мониторинг показывает 100%, если сайт падал?

Скорее всего, сбой был короче интервала и попал между проверками. При проверке раз в 5 минут двухминутный сбой замечается примерно в 40% случаев. Уменьшите интервал или добавьте внутренние метрики.

Какой интервал проверки выбрать для 99,9%?

Для 99,9% за год хватает проверки раз в 5 минут: шаг меньше процента годового бюджета. Для 99,9% за месяц лучше раз в минуту: пять минут — это 11,6% месячного бюджета на одну пробу.

Можно ли доказать клиенту 99,99% внешним мониторингом?

За месяц — только с шагом в десятки секунд и подтверждением из нескольких регионов. С проверкой раз в 5 минут — нет: один шаг длиннее всего месячного бюджета.

Чем доступность по запросам отличается от доступности по времени?

По времени считают, сколько сервис лежал. По запросам — какая доля запросов завершилась успешно. Google в книге SRE использует второй вариант, потому что их сервисы почти никогда не лежат целиком. Внешняя проверка измеряет первый вариант.

В сухом остатке

Процент аптайма ничего не стоит без периода и интервала проверки. Сначала посчитайте бюджет в минутах, потом подберите шаг, который в разы меньше бюджета, и только потом пишите цифру в договор.

Минуты из процента — в калькуляторе SLA. Проверки с перепроверкой из нескольких городов и нужным интервалом — в мониторинге сайта.