Инструмент для DevOps и IT-менеджеров

Калькулятор SLA и стоимости простоя

Рассчитайте допустимый простой по уровню SLA, узнайте стоимость каждой минуты даунтайма и определите фактический SLA по реальному времени недоступности сервиса.

99.9%
Стандарт индустрии
Базовый SLA для облачных сервисов
8.76 ч
Простой при 99.9%
Допустимый даунтайм в год
5.26 мин
Простой при 99.999%
Пять девяток — золотой стандарт
24/7
Мониторинг
Непрерывный контроль доступности

Что такое SLA и Uptime

SLA (Service Level Agreement) — это соглашение об уровне обслуживания между провайдером услуги и клиентом. Одним из ключевых параметров SLA является Uptime — гарантированный процент времени, в течение которого сервис будет доступен. Чем больше «девяток» в показателе SLA, тем меньше допустимого времени простоя и тем выше требования к инфраструктуре.

📋

Uptime (время работы)

Uptime — это процент времени, когда система доступна и работает штатно. Например, SLA 99.9% означает, что сервис может быть недоступен не более 8 часов 45 минут в год. Этот показатель измеряется внешними системами мониторинга, которые регулярно проверяют доступность сервиса.

🔴

Downtime (простой)

Downtime — это период, когда сервис недоступен пользователям. Включает плановые работы (обновления, миграции) и внеплановые инциденты (сбои оборудования, DDoS-атаки, ошибки конфигурации). В SLA обычно учитывается только внеплановый простой, плановые работы выносятся в отдельное окно обслуживания.

🎯

«Девятки» (Nines)

В индустрии уровни SLA принято считать в «девятках»: 99% — две девятки, 99.9% — три, 99.99% — четыре, 99.999% — пять. Каждая дополнительная девятка уменьшает допустимый простой в 10 раз, но экспоненциально увеличивает стоимость инфраструктуры и сложность поддержки.

Где применяется SLA

Соглашения об уровне обслуживания являются стандартом для любого IT-сервиса, от хостинга до облачных платформ.

🌐

Хостинг и дата-центры

Провайдеры веб-хостинга и колокации гарантируют доступность серверов на уровне 99.9-99.99%. Нарушение SLA влечёт компенсацию в виде кредитов на обслуживание. При выборе хостинга SLA — один из ключевых параметров.

☁️

Облачные платформы (Cloud)

AWS, Google Cloud, Yandex Cloud, Selectel — все крупные облачные провайдеры публикуют SLA для каждого сервиса. Виртуальные машины обычно имеют SLA 99.95%, управляемые базы данных — 99.99%, а CDN — 99.999%.

💻

SaaS-сервисы

Программы как услуга (CRM, ERP, мессенджеры) указывают SLA в договорах с корпоративными клиентами. Для бизнес-критичных систем (платёжные шлюзы, медицинские системы) стандартом является SLA 99.99% и выше.

⚙️

DevOps и SRE

Команды Site Reliability Engineering используют SLA для определения Error Budget — бюджета ошибок. Если простой за месяц укладывается в бюджет, команда может выпускать новые фичи. Если бюджет исчерпан — фокус переключается на надёжность.

📈

Бизнес-планирование

Финансовые аналитики используют калькулятор SLA для оценки потенциальных потерь от простоя. Это помогает обосновать инвестиции в резервирование, мониторинг и disaster recovery перед руководством.

🚨

Управление инцидентами

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

Справочная таблица SLA/ стандартные уровни

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

SLA %ДевяткиПростой / годПростой / месяцПростой / неделяПрименение
99%23 дня 15 ч7 ч 12 мин1 ч 41 минНекритичные сервисы
99.5%2.51 день 19 ч3 ч 36 мин50 минВнутренние системы
99.9%38 ч 46 мин43 мин10 минСтандартный SLA
99.95%3.54 ч 23 мин21 мин5 минОблачные сервисы
99.99%452 мин4 мин 19 сек1 минФинансовые системы
99.999%55 мин 15 сек26 сек6 секТелеком, медицина

Заметка: каждая дополнительная «девятка» в SLA стоит примерно в 10 раз дороже предыдущей из-за необходимости дополнительного резервирования, автоматизации и инженерных ресурсов.

Совет: не стремитесь к 99.999% для всех сервисов. Определите критичность каждого компонента и выставите SLA, соответствующий бизнес-требованиям. Избыточная надёжность — это переплата.

Как повысить Uptime

Для достижения высокого уровня доступности необходимо системно работать над каждым звеном инфраструктуры. Ниже — ключевые стратегии повышения uptime.

🔁

Резервирование (Redundancy)

Дублирование критических компонентов: серверов, сетевых каналов, баз данных, систем хранения. Используйте кластеризацию (Active-Active или Active-Passive), мультизональное развёртывание и балансировку нагрузки. Каждый единичный компонент (Single Point of Failure) должен быть устранён.

📡

Мониторинг и алертинг

Внедрите многоуровневый мониторинг: внешние проверки доступности (Uptime Robot, Pingdom), метрики приложения (Prometheus, Grafana), логирование (ELK Stack). Настройте эскалацию алертов: если инцидент не закрыт за 5 минут — уведомление уходит следующему уровню поддержки.

🗺️

Disaster Recovery план

Разработайте и регулярно тестируйте план восстановления после катастрофы. Определите RPO (допустимую потерю данных) и RTO (время восстановления). Автоматизируйте переключение на резервную площадку. Проводите учения (Game Day) минимум раз в квартал, имитируя отказ компонентов.

🚀

CI/CD и автоматизация

Автоматизируйте развёртывание через CI/CD-пайплайны с Blue-Green или Canary-деплоями. Используйте Infrastructure as Code (Terraform, Ansible) для воспроизводимости среды. Автоматические откаты при обнаружении ошибок после деплоя значительно сокращают время инцидентов.

Советы по работе с SLA

Практические рекомендации для IT-менеджеров, DevOps-инженеров и владельцев бизнеса при составлении и контроле SLA.

1Определите критичность сервисов

Не все сервисы требуют одинакового SLA. Платёжный шлюз может требовать 99.99%, а внутренний wiki — 99.5%. Составьте матрицу критичности: разделите сервисы на категории (Tier 1, Tier 2, Tier 3) и назначьте соответствующий SLA для каждого уровня.

2Считайте композитный SLA

Если сервис зависит от нескольких компонентов последовательно, общий SLA равен произведению SLA каждого. Например, приложение (99.99%) + база данных (99.99%) + сеть (99.99%) = 99.97%. Учитывайте это при проектировании архитектуры и не обещайте больше, чем может обеспечить самое слабое звено.

3Используйте Error Budget

Бюджет ошибок — это допустимое количество минут простоя за период. Например, при SLA 99.9% в месяц бюджет составляет 43 минуты. Пока бюджет не исчерпан, команда может выпускать обновления. Если бюджет заканчивается, все силы направляются на стабилизацию.

4Фиксируйте метод измерения

В SLA-контракте чётко опишите, как измеряется доступность: с каких точек, с какой частотой, что считается инцидентом. Без этого SLA превращается в формальность. Определите, включаются ли в расчёт плановые работы и частичная деградация сервиса.

Связанные понятия

SLA тесно связан с другими метриками надёжности и производительности сервисов.

SLO (Service Level Objective)

Внутренняя цель по качеству сервиса. SLO обычно строже, чем внешний SLA: если SLA = 99.9%, то SLO может быть 99.95%. Это даёт запас для выявления проблем до нарушения контракта.

SLI (Service Level Indicator)

Конкретная метрика, по которой измеряется качество: процент успешных запросов, задержка p99, доля ошибок. SLI — это данные, SLO — целевое значение, SLA — юридическое обязательство.

MTTR (Mean Time To Recovery)

Среднее время восстановления после сбоя. Чем ниже MTTR, тем выше фактический SLA. Сокращается через автоматизацию отката, подготовленные runbook-инструкции и обученных дежурных инженеров.

MTBF (Mean Time Between Failures)

Среднее время между отказами. Показывает надёжность системы. Увеличивается через резервирование, качественное тестирование, постепенный rollout обновлений и анализ постмортемов.

RPO (Recovery Point Objective)

Допустимая потеря данных при катастрофе, выраженная во времени. RPO = 1 час означает, что допустима потеря данных за последний час. Определяет частоту бэкапов и стратегию репликации.

RTO (Recovery Time Objective)

Целевое время восстановления после катастрофы. RTO = 15 минут означает, что сервис должен быть восстановлен за четверть часа. Влияет на выбор архитектуры DR: hot standby vs cold backup.

Как пользоваться калькулятором

Три режима работы для решения любых задач, связанных с SLA и доступностью сервисов.

1

SLA -> Простой

Выберите уровень SLA (99%, 99.9%, 99.99% и т.д.) или введите свой процент. Калькулятор рассчитает допустимое время простоя за год, месяц, неделю и день в часах, минутах и секундах.

2

Простой -> SLA

Введите фактический простой (часы и минуты) за выбранный период. Калькулятор определит, какому уровню SLA соответствует ваш реальный uptime и покажет количество «девяток».

3

Стоимость простоя

Укажите выручку компании в час. Калькулятор покажет стоимость каждой минуты простоя и сравнительную таблицу финансовых потерь для разных уровней SLA.

ЧАСТЫЕ ВОПРОСЫ

Часто задаваемые вопросы

SLA 99.9% (три девятки) означает, что сервис может быть недоступен не более 8 часов 45 минут в год, или примерно 43 минуты в месяц. Это стандартный уровень для большинства облачных сервисов. На практике это значит, что за месяц допускается один инцидент длительностью до 43 минут или несколько коротких сбоев суммарно не превышающих это время.
SLA (Service Level Agreement) — это юридический контракт с клиентом, за нарушение которого предусмотрены штрафы или компенсации. SLO (Service Level Objective) — внутренняя цель команды, обычно строже SLA, чтобы иметь запас. SLI (Service Level Indicator) — конкретная метрика, которая измеряется (процент успешных запросов, задержка, доступность). SLI — это данные, SLO — цель, SLA — обязательство.
Если компоненты системы расположены последовательно (каждый обязателен для работы), общий SLA равен произведению SLA каждого компонента. Например: веб-сервер (99.99%) x база данных (99.99%) x сеть (99.9%) = 99.88%. Если компоненты параллельны (резервируют друг друга), формула: 1 - (1-SLA_1) * (1-SLA_2). Два сервера с SLA 99% дают композитный SLA = 99.99%.
Error Budget — это допустимое количество минут простоя за определённый период, рассчитанное из SLA. При SLA 99.9% месячный бюджет ошибок составляет 43 минуты. Пока бюджет не исчерпан, команда может выпускать новые функции и обновления. Когда бюджет заканчивается, все ресурсы перенаправляются на повышение надёжности. Этот подход был популяризирован Google в рамках методологии SRE.
Зависит от условий контракта. В большинстве SLA-соглашений плановое обслуживание (maintenance window) исключается из расчёта доступности, если провайдер уведомляет клиента заранее (обычно за 48-72 часа). Однако лучшие провайдеры проводят обновления без простоя (zero-downtime deployment), и плановое окно используется только для редких крупных миграций.
Для среднего интернет-магазина оптимален SLA 99.9% (три девятки). Это допускает примерно 43 минуты простоя в месяц. Для крупных e-commerce площадок с выручкой более 1 млн рублей в час рекомендуется SLA 99.95-99.99%. Важно помнить, что в пиковые периоды (распродажи, праздники) каждая минута простоя стоит в разы дороже, поэтому SLA можно дифференцировать по сезону.
Uptime измеряется системами внешнего мониторинга, которые с заданной периодичностью (обычно каждые 1-5 минут) отправляют запросы к сервису из разных географических точек. Если сервис не отвечает или отвечает с ошибкой в течение нескольких проверок подряд, фиксируется инцидент. Популярные инструменты: Uptime Robot, Pingdom, Better Stack, Datadog, а также российские — Мониторус, Host-tracker.
SLA 99.999% допускает только 5 минут 15 секунд простоя в год. Для достижения этого уровня необходимо: мультизональное или мультирегиональное развёртывание, автоматическое переключение при отказе за секунды, дублирование каждого компонента, круглосуточная дежурная смена SRE-инженеров. Стоимость инфраструктуры и команды может быть в 10-100 раз выше, чем для трёх девяток.
При нарушении SLA провайдер обычно предоставляет компенсацию в виде кредитов на обслуживание (SLA Credits). Типичная схема: при downtime 99.0-99.9% — кредит 10% месячной стоимости, при 95-99% — 25%, ниже 95% — 50%. Важно: компенсация редко покрывает реальные потери бизнеса от простоя, поэтому не стоит полагаться только на SLA провайдера — нужна собственная стратегия отказоустойчивости.
MTTR (Mean Time To Recovery) — среднее время восстановления после сбоя. Чем ниже MTTR, тем быстрее система возвращается в рабочее состояние и тем выше фактический SLA. Для SLA 99.99% (4 минуты 19 секунд в месяц) MTTR должен быть менее 5 минут. Снижение MTTR достигается через автоматизацию: auto-scaling, self-healing, automated rollback и подготовленные runbook-инструкции для дежурных инженеров.
Лиана Арифметова
АВТОРverifiedред. calcal.ru

Лиана Арифметова

Создатель и главный редактор

Миссия: демократизировать сложные расчёты. Превратить страх перед числами в ясность и контроль. Девиз: «Любая повторяющаяся задача заслуживает своего калькулятора».

Mathematical Engineering · МФТИ · редактирует каталог с 2012 года

Был ли этот калькулятор полезен?

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ

Инструмент справочный — не заменяет эксперта

Только для информационных целей. Все расчёты, результаты и данные, предоставляемые инструментом, носят исключительно ознакомительный и справочный характер. Они не являются профессиональной консультацией — медицинской, юридической, финансовой, инженерной или иной.

Точность результатов. Калькулятор основан на общепринятых формулах и методиках, однако фактические результаты могут отличаться в зависимости от индивидуальных условий, исходных данных и применяемых стандартов. Мы не гарантируем полноту, точность или актуальность приведённых расчётов.

Профессиональные решения — медицинские, финансовые, инженерные — должны приниматься только после консультации с квалифицированным специалистом. Не используйте автоматический расчёт как единственное основание для важных решений.

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

СМЕЖНЫЕ ИНСТРУМЕНТЫ

Похожие калькуляторы

15

Генератор Cron-выражений

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

/generator-cron

Конвертер Unix Timestamp ↔ дата

Онлайн конвертер Unix Timestamp в дату и обратно. Текущий Unix-таймстемп, конвертация с учётом часовых поясов России, форматы ISO 8601 и RFC 2822.

/konverter-unix-timestamp

YAML валидатор и форматтер

Онлайн проверка и форматирование YAML-файлов. Валидация синтаксиса, конвертация YAML ↔ JSON, подсветка ошибок с номерами строк.

/yaml-validator

Калькулятор размера Docker-образа

Оценка размера Docker-образа по базовому образу и зависимостям. Сравнение base images, советы по оптимизации и multi-stage сборке.

/razmer-docker-obraza

Калькулятор контейнеров (Docker)

Расчёты контейнеров: ресурсы, образы, Docker Compose, реестр, оркестрация, стоимость

/container-calculator

Калькулятор подсетей CIDR/IP

Онлайн калькулятор подсетей IPv4. Расчёт маски подсети, диапазона IP-адресов, количества хостов по CIDR-нотации. Бесплатный инструмент для сетевых инженеров.

/kalkulyator-podsetej-cidr

Калькулятор контрастности (WCAG), шрифтов и сетки

Инструменты UI/UX дизайнера. Проверка контрастности цветов (WCAG AA/AAA), расчет модульной сетки и подбор типографической шкалы.

/contrast-grid

Калькулятор микросервисной архитектуры

Расчёты микросервисов: ресурсы, сеть, надёжность, API Gateway, очереди, стоимость

/microservices-calculator

Калькулятор балансировки нагрузки

Расчёты балансировки: пропускная способность, бэкенды, SSL/TLS, алгоритмы, HA, стоимость

/load-balancer-calculator

DevOps калькулятор: DORA-метрики, SLA, CI/CD пайплайн, мониторинг

Комплексный DevOps калькулятор. DORA-метрики (deployment frequency, lead time, MTTR, change failure rate), расчёт SLA и доступности (uptime 99.9–99.999%), размер инфраструктуры (CPU/RAM/диск), мониторинг и алертинг, оптимизация облачных затрат (Reserved vs Spot), анализ CI/CD пайплайна.

/devops-calculator

CI/CD калькулятор: пайплайн, кэш, тесты, раннеры, деплой

Комплексный CI/CD калькулятор: оптимизация пайплайна (критический путь, параллелизация), кэш сборки (hit ratio, ROI), анализ тестов (flaky, шардирование), артефакты (Docker, npm), раннеры (автоскейлинг) и стратегии деплоя (Blue-Green, Canary, Rolling).

/ci-cd-calculator

Калькулятор технического долга: объём, SQALE, рефакторинг

Комплексный калькулятор технического долга: оценка объёма в часах и рублях, расчёт процентной ставки (стоимость бездействия), матрица приоритизации (impact vs effort), метрики качества кода (цикломатическая сложность, дупликация, покрытие тестами), план рефакторинга по спринтам, SQALE рейтинг A-E.

/technical-debt-calculator

Генератор Cubic Bezier (CSS transition)

Интерактивный генератор кривых Безье для CSS анимаций. Визуальная настройка плавности переходов, пресеты (ease, linear) и копирование кода.

/cubic-bezier

Калькулятор код-ревью: время, размер PR, дефекты, нагрузка

Комплексный калькулятор код-ревью: оценка времени проверки кода, анализ размера PR (XS/S/M/L/XL), покрытие ревью и bus factor, плотность дефектов и escape rate, нагрузка команды ревьюеров, метрики качества (churn, rework, first-pass yield).

/code-review-calculator

Калькулятор теории цвета: гармония, конвертер, палитры, смешивание, дальтонизм

Комплексный инструмент для работы с цветом: цветовые гармонии (комплементарная, аналогичная, триадная, тетрадная), конвертер HEX/RGB/HSL/HSV/CMYK, генератор палитр (монохроматическая, shades, tints, tones), смешивание цветов (аддитивное/субтрактивное), симулятор дальтонизма и анализ цветовой температуры.

/color-theory-calculator