Аптайм сервиса: формула расчета, примеры и онлайн-калькулятор

Аптайм (uptime) — доля времени, когда сервис доступен и отвечает на запросы. Измеряется в процентах за период (обычно месяц или год). Но главное — это не абстрактный показатель, а метрика, завязанная на SLA. Технически аптайм считают по формуле:

Где T_total — суммарное время за период (например, 30 дней = 720 часов = 43200 минут), T_down — суммарное время недоступности. Часто путают: 99% — это не "почти 100", а 3,65 дня простоя в год. Ниже таблица соответствия:

Как видите, каждый дополнительный "девять" радикально снижает допустимый простой.

На практике аптайм считают за фиксированный период. Вот пример на Python — функция принимает список инцидентов (дата начала, дата конца) и период:

from datetime import datetime, timedelta

def uptime(incidents, period_start, period_end):
    total_sec = (period_end - period_start).total_seconds()
    down_sec = 0
    for start, end in incidents:
        # обрезаем инциденты за пределами периода
        start = max(start, period_start)
        end = min(end, period_end)
        if start < end:
            down_sec += (end - start).total_seconds()
    up_sec = total_sec - down_sec
    return up_sec / total_sec * 100

# Пример: месяц март 2026
period_start = datetime(2026, 3, 1)
period_end = datetime(2026, 4, 1)
incidents = [
    (datetime(2026, 3, 5, 10, 0), datetime(2026, 3, 5, 10, 5)),  # 5 мин
    (datetime(2026, 3, 20, 14, 30), datetime(2026, 3, 20, 15, 30)),  # 60 мин
]
print(f"{uptime(incidents, period_start, period_end):.3f}%")  # 99.850%

Подводные камни: если инцидент затрагивает только часть пользователей (например, только одно зона доступности), формально аптайм может быть 100%, но опыт ухудшился. Поэтому в SLA часто вводят weighted аптайм (взвешенный по числу пользователей).

1. Определите период. Например, июль 2026: 31 день = 744 часа = 44640 минут.
2. Соберите все инциденты полной недоступности. Только когда сервис не отвечал. Плановые окна обычно исключают, если в SLA явно указано.
3. Просуммируйте длительность. Допустим, за месяц было два инцидента: 15 мин и 45 мин. Итого 60 мин = 1 час.
4. Подставьте в формулу: (744 - 1) / 744 × 100% = 99,8656%.

Кажется просто? Но есть нюансы: время реакции (пока инцидент зафиксирован) и время восстановления — считаются как простой. Если мониторинг проверяет раз в 5 минут, вы можете не заметить 4-минутный сбой — аптайм будет завышен.

Совет: используйте внешний мониторинг с частотой проверок ≤ 1 минута. Иначе вы считаете "видимый" аптайм, а не реальный.

Частичная недоступность. Если отказал один сервер из трёх, аптайм формально 100% (остальные работают). В SLA это часто трактуют как снижение производительности, а не простой. Некоторые контракты вводят эффективный аптайм — доля успешных запросов.

Медленные ответы. Если время отклика превышает SLA (например, >1 сек), это не простой, но может считаться деградацией. Отдельные метрики: latency, error rate.

Плановые окна. Обычно аптайм считается за вычетом согласованного времени обслуживания. Но если в контракте не указано — включаются. Всегда читайте мелкий шрифт.

Зоны доступности. В облачных провайдерах (AWS, Azure) аптайм считается отдельно для каждой зоны. Если приложение развёрнуто в одной зоне и она упала — это даунтайм. Если в трёх — нагрузка перераспределяется, простой может быть нулевым.

• Игнорирование частичных сбоев. Если недоступна только часть API, но пользователь не может получить данные — это простой с точки зрения бизнеса. Считайте его отдельно.
• Неправильный период. Путают календарный месяц и 30 дней. Если считать 28 февраля, то 99,9% — это ~40 минут, а не 43,8. Для SLA обычно берут календарный месяц.
• Не учитывают время обнаружения. Инцидент начался в 23:59, а мониторинг заметил в 00:05 — пять минут потерь не учтены.
• Округление. 99,95% красивее, чем 99,9456, но при сумме за год набегает разница. Округляйте до 2-3 знаков, но в расчёте используйте точные значения.

Чтобы избежать этих проблем, используйте автоматизированные средства мониторинга и Калькулятор аптайма сервиса, который учитывает все нюансы.

Ручной расчёт аптайма — зло: легко ошибиться, сложно вести историю. Лучше довериться готовым решениям. Например, Калькулятор аптайма сервиса позволяет ввести даты и время инцидентов, а он сам вычислит процент за любой период. Поддерживает ввод в часах и минутах, рассчитывает сразу несколько метрик.

Важно: онлайн-калькулятор — это лишь вершина. Для полноценного мониторинга используйте системы вроде Prometheus, Grafana, Uptime Kuma. Они собирают данные в реальном времени и строят дашборды. Но для быстрой проверки или выставления счёта по SLA — калькулятор идеален.

Пример: ввёл два инцидента по 10 минут в июне 2026 (30 дней) → получил 99,95%. Если бы считал вручную, потратил 5 минут и мог ошибиться. Инструмент делает это за секунду.

Аптайм 99,9% — это не повод успокаиваться. Для большинства B2C-сервисов пользователи ожидают 99,99% (52 минуты простоя в год). Для финансовых транзакций — 99,999% (5 минут). Если вы не дотягиваете, первое, что нужно сделать — улучшить архитектуру: добавить реплики, балансировку, автоматическое восстановление.

Также стоит различать измеренный аптайм (что показал мониторинг) и согласованный в SLA. Часто поставщик гарантирует 99,9%, а по факту даёт 99,95% — это хорошо, но юридически он выполнил обязательства. Клиент может требовать компенсацию только если простой превысил 0,1%.

Запомните: 99,9% — это нижняя граница. В 2026 году тренд на 99,99% для всех публичных сервисов. Не отставайте.

Аптайм — простая метрика, но с подводными камнями. Главное — единообразно считать и фиксировать все инциденты. Используйте автоматизацию, избегайте ручного подсчёта. Регулярно сверяйте показатели с SLA и требуйте компенсации при нарушениях. Для быстрых проверок держите под рукой Калькулятор аптайма сервиса.