99,9% доступности — это 43 минуты простоя за 30 дней

За 30 дней проходит 43 200 минут. Если доступность измеряют временем и задают цель 99,9%, на недоступность остаётся 0,1% периода: 43 минуты 12 секунд. Цифра выглядит небольшой, пока эти минуты не приходятся на начало распродажи.

Это арифметический пример, а не обещание конкретного провайдера и не прогноз будущего сбоя. Процент задаёт долю за выбранный период. Он не сообщает, случится одна длинная авария или много коротких, ночью или в час максимального спроса.

Формула для временной метрики проста: длительность периода умножают на долю недоступности. Для 30 дней цель 99,95% оставляет 21 минуту 36 секунд, а 99,99% — 4 минуты 19,2 секунды. Переход от 99,9% к 99,99% сокращает допустимое время в десять раз, хотя визуально к числу добавляется всего одна девятка.

Представим условный магазин с целью 99,9%. Одна учитываемая остановка на 30 минут уже израсходует примерно 69,4% его месячного бюджета недоступности. До границы останется 13 минут 12 секунд. При цели 99,99% эта же остановка превысит бюджет почти в семь раз. Никакие дополнительные часы успешной работы внутри того же тридцатидневного периода не превратят такой результат в соответствие более строгой цели.

У месяца из 31 дня знаменатель другой: 44 640 минут. Для 99,9% получится 44 минуты 38,4 секунды. Поэтому в отчёте нельзя брать процент из календарного SLA, а минуты — из условного месяца, не пояснив различие. Скользящие 30 дней, календарный месяц и рабочие часы дают разные расчёты.

В SLA закреплены условия обслуживания поставщика. Внутренняя цель команды — SLO — может описывать другой объект и быть строже. Например, соглашение относится к виртуальной машине, а магазин интересует возможность оформить заказ. Нельзя автоматически переносить процент одной услуги на весь путь покупателя.

На практике полезно выписать четыре вещи: объект измерения, критерий отказа, период и исключения. Это могут быть минуты недоступности ресурса или доля успешных запросов. Плановые работы, минимальная длительность инцидента и требования к архитектуре учитываются так, как определено в конкретном соглашении. Единого набора исключений для всех хостингов нет.

Yandex Cloud, например, публикует общие условия SLA и отдельные уровни обслуживания сервисов. Сам факт такого разделения — повод читать условия выбранного продукта, а не переносить цифру из соседней услуги. Указанный в рекламе процент без области применения ещё не даёт сопоставимого критерия выбора.

Если метрика считается по запросам, переводить её прямо в минуты нельзя. При 100 000 учитываемых запросов цель 99,9% оставляет 100 неуспешных запросов. Когда они произошли и сколько длилось ухудшение, из одной этой суммы неизвестно. Ночная минута с десятью обращениями и дневная минута с тысячей обращений имеют одинаковый вес во временной метрике и разный — в метрике запросов.

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

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

При этом не каждому небольшому магазину экономически оправданна одинаковая архитектура. Можно отдельно задать цель для просмотра каталога и для оформления заказа, определить критические часы и приоритеты восстановления. Это не разрешение скрывать неудобные сбои из отчёта: правила измерения фиксируют заранее и применяют последовательно.

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

In 30 days, there are 43,200 minutes. If availability is measured by time and the target is set at 99.9%, the remaining 0.1% of the period equals 43 minutes and 12 seconds of downtime. This figure may seem small until those minutes coincide with the start of a sale.

This is an arithmetic example, not a promise from a specific provider or a forecast of a future outage. A percentage defines the proportion of downtime within a chosen period. It does not indicate whether the downtime will be one long outage or many short ones, or whether it will occur at night or during peak demand.

The formula for the time-based metric is simple: multiply the period duration by the proportion of unavailability. For 30 days, a target of 99.95% leaves 21 minutes and 36 seconds, while 99.99% leaves 4 minutes and 19.2 seconds. Moving from 99.9% to 99.99% reduces the allowable downtime by a factor of ten, even though visually only one additional nine is added to the number.

Imagine a hypothetical store with a target of 99.9%. A single stoppage lasting 30 minutes would already consume approximately 69.4% of its monthly downtime budget. Only 13 minutes and 12 seconds would remain before reaching the limit. At a target of 99.99%, that same stoppage would exceed the budget by nearly seven times. No additional hours of successful operation within the same thirty-day period can turn such a result into compliance with a stricter target.

A 31-day month has a different denominator: 44,640 minutes. For 99.9%, that equals 44 minutes and 38.4 seconds. Therefore, a report must not take a percentage from a calendar SLA and minutes from a hypothetical month without explaining the difference. Rolling 30-day periods, calendar months, and working hours yield different calculations.

An SLA defines the service provider's obligations. An internal team goal, an SLO, may describe a different object and be stricter. For example, the agreement might cover a virtual machine, while the store is concerned with the ability to complete a checkout. You cannot automatically apply the availability percentage of one service to the entire customer journey.

In practice, it is useful to list four items: the measurement object, the failure criterion, the period, and exceptions. These may be minutes of resource unavailability or the share of successful requests. Scheduled maintenance, minimum incident duration, and architecture requirements are handled as defined in the specific agreement. There is no single set of exceptions applicable to all hosting providers.

Yandex Cloud, for example, publishes general SLA terms and separate service levels for services. The very fact of such a division is a reason to read the terms of the selected product rather than transferring a figure from a neighboring service. A percentage indicated in advertising without a defined scope does not provide a comparable selection criterion.

If a metric is calculated per request, it cannot be directly converted into minutes. With 100,000 considered requests, a 99.9% target leaves 100 failed requests. It is unknown when they occurred or how long the degradation lasted based solely on this sum. A night minute with ten requests and a day minute with a thousand requests have the same weight in a time-based metric but different weights in a request-based metric.

A stricter goal requires changing recovery methods, not just the tariff. If failure detection takes five minutes, then a person spends ten minutes searching for access and another twenty restoring the system, the monthly budget for 99.99% availability can be exhausted before repairs even begin. Here, it is useful first to reduce specific delays, and only then discuss redundancy.

A second server helps only with a clear failover and available data. Two applications depending on the same database retain a single point of failure. A backup solves the data recovery problem, but the time required to deploy it does not disappear. A strict goal must rely on a tested scenario, including failover errors and the return to normal mode.

At the same time, the same architecture is not economically justified for every small store. You can set separate goals for catalog browsing and checkout, define critical hours, and establish recovery priorities. This is not permission to hide inconvenient failures from reports: measurement rules must be defined in advance and applied consistently.

The practical outcome of the calculation is a concrete question for the team: what is the total allowable downtime for the selected operation, and can we meet this target during a typical incident? If the answer is not yet known, the next useful step is to measure detection and recovery on a safe training scenario. Purchasing an additional nine in the service description will not close this gap.