Uptime 99.9% означает, что система может простаивать не более 0.1% времени за отчетный период. В пересчете на год это 8 часов 45 минут 36 секунд, или 525.6 минуты. Это допустимый предел простоя, а не гарантия того, что система обязательно будет недоступна именно столько.
Расчет строится на простой формуле: (1 - целевой_uptime) × период. Для 99.9% берем 0.001 × 365 дней × 24 часа × 60 минут = 525.6 минуты. Полученное значение становится отправной точкой для проектирования архитектуры, выбора оборудования и согласования SLA с подрядчиками.
Если вы проектируете систему, где простой обходится бизнесу в десятки тысяч рублей в час, разница между 99.9% и 99.99% становится критичной. Первый вариант допускает почти 9 часов простоя в год, второй - меньше часа. Дальше разберем методику расчета совокупной надежности, которая позволяет перевести целевой uptime в конкретные архитектурные решения.
Что означает uptime 99.9% в реальных цифрах
Uptime показывает долю времени, в течение которого система доступна для пользователей. Уровень 99.9% часто называют «тремя девятками». Это стандартный ориентир для большинства корпоративных сервисов: внутренних порталов, CRM, систем документооборота. Для сравнения, 99% допускает 3.65 дня простоя в год, а 99.999% - чуть больше 5 минут.
Пересчет процентов в конкретные единицы времени помогает принимать решения. Когда вы видите цифру 99.9%, полезно сразу понимать: это 10 минут простоя в неделю или 43.8 минуты в месяц. Такая конкретика отрезвляет при обсуждении бюджетов и SLA.
Таблица допустимого простоя для стандартных уровней SLA
Таблица ниже дает справочные значения для четырех стандартных уровней доступности. Используйте ее при первичной оценке требований к системе и при сравнении предложений облачных провайдеров.
| Уровень доступности | Простой в год | Простой в месяц (30 дней) | Простой в неделю |
|---|---|---|---|
| 99% | 3.65 дня (87.6 часа) | 7.2 часа | 1.68 часа |
| 99.9% | 8.76 часа | 43.8 минуты | 10.1 минуты |
| 99.99% | 52.56 минуты | 4.38 минуты | 1.01 минуты |
| 99.999% | 5.26 минуты | 25.9 секунды | 6.05 секунды |
Цифры для месяца и недели получены пропорциональным делением годового значения. На практике простой распределяется неравномерно: авария может занять все 8 часов разом, а не по 10 минут еженедельно. Планируйте запас по времени.
Методика расчета совокупной надежности системы
Целевой uptime всей системы складывается из надежности отдельных компонентов. Каждый сервер, сетевой коммутатор, балансировщик или база данных имеет собственную вероятность безотказной работы за заданный период. Эта вероятность называется надежностью и обозначается как R (reliability). Значение R = 0.99 означает, что компонент с вероятностью 99% проработает без отказа в течение года.
Совокупная надежность зависит от того, как компоненты соединены между собой. Есть два базовых типа соединения: последовательное и параллельное. В реальных системах они комбинируются, поэтому расчет разбивают на подсистемы.
Последовательное соединение: перемножение надежностей
При последовательном соединении отказ любого компонента приводит к отказу всей системы. Пример: приложение работает, только если доступны фронтенд-сервер, бэкенд и база данных. Если упал любой из трех, пользователи получают ошибку.
Формула для последовательного соединения:
R_total = R1 × R2 × ... × RnПример: два компонента с надежностью 0.99 каждый дают совокупную надежность 0.99 × 0.99 = 0.9801, то есть 98.01%. Это ниже надежности каждого отдельного компонента. Чем больше компонентов в последовательной цепочке, тем ниже общая надежность.
Практический вывод: сокращайте количество обязательных звеньев в цепочке. Каждый дополнительный последовательный компонент снижает итоговый uptime. Если система состоит из пяти компонентов с надежностью 0.99, итоговая надежность составит 0.99^5 ≈ 0.951, то есть 95.1%. Это уже уровень ниже 99%.
Параллельное соединение: резервирование и формула
При параллельном соединении система работает, если работает хотя бы один компонент. Это классическая схема резервирования: два сервера за балансировщиком, реплика базы данных, дублированный источник питания.
Формула для параллельного соединения:
R_total = 1 - (1 - R1) × (1 - R2) × ... × (1 - Rn)Пример: два компонента с надежностью 0.99, соединенные параллельно, дают совокупную надежность 1 - (1 - 0.99) × (1 - 0.99) = 1 - 0.01 × 0.01 = 0.9999, то есть 99.99%. Резервирование поднимает надежность на порядок.
Резервирование эффективно, но увеличивает стоимость. Два сервера вместо одного удваивают затраты на железо, лицензии и обслуживание. Поэтому резервируют только критические компоненты, отказ которых приводит к полной остановке сервиса. Подробнее о балансе между надежностью и бюджетом читайте в статье про архитектуру высоконагруженных систем.
Комбинированные схемы: расчет сложных архитектур
Реальная инфраструктура содержит и последовательные, и параллельные участки. Методика расчета: разбейте систему на подсистемы, рассчитайте надежность каждой подсистемы по соответствующей формуле, затем объедините результаты.
Пример: два сервера приложения работают параллельно (подсистема A), за ними последовательно включен сетевой коммутатор (подсистема B). Надежность каждого сервера - 0.99, коммутатора - 0.999.
Шаг 1. Рассчитываем подсистему A: R_A = 1 - (1 - 0.99) × (1 - 0.99) = 0.9999.
Шаг 2. Рассчитываем общую надежность: R_total = R_A × R_B = 0.9999 × 0.999 = 0.9989, то есть 99.89%.
Итоговое значение ниже, чем у каждой подсистемы по отдельности. Коммутатор с надежностью 0.999 становится узким местом. Если он выйдет из строя, оба сервера станут недоступны, несмотря на резервирование.
Практическое применение: от расчета к бюджету и SLA
Расчеты надежности нужны для принятия решений о закупках и договорах. Зная целевой uptime, вы определяете, какие компоненты резервировать, а какие оставить в единственном экземпляре. Затем переводите эти решения в бюджет и требования к поставщикам.
Обоснование бюджета на резервирование
Стоимость простоя часто превышает стоимость резервирования. Покажите это руководству на цифрах. Допустим, час простоя приложения обходится бизнесу в 100 000 рублей. При uptime 99.9% допустимый простой составляет 8.76 часа в год, то есть потенциальные потери - 876 000 рублей. Переход на 99.99% сокращает простой до 0.876 часа, потери - до 87 600 рублей. Разница в 788 400 рублей в год - это бюджет, который можно направить на резервирование критических компонентов.
Если дополнительный сервер или реплика базы данных стоит меньше этой суммы, инвестиция окупается. Такой расчет переводит абстрактный «uptime» в язык бизнеса: деньги и риски. Смежные вопросы стоимости инфраструктуры разобраны в статье про нагрузочное тестирование серверов.
Формулировка требований к подрядчикам и облачным провайдерам
В договоре с облачным провайдером или поставщиком оборудования указывайте не только процент uptime, но и допустимое время простоя, методику измерения и ответственность за превышение. Формулировка «доступность 99.9%» без расшифровки оставляет пространство для споров.
Требуйте от провайдера указать:
- период измерения (месяц, квартал, год);
- методику расчета (исключаются ли плановые работы);
- компенсации за превышение допустимого простоя;
- реальные показатели за предыдущие периоды, а не только заявленные в SLA.
Проверяйте фактические данные. Провайдер может заявлять 99.9%, но по факту давать 99.7%. Разница в 0.2% - это дополнительные 17.5 часов простоя в год. Для мониторинга реальных показателей используйте инструменты, описанные в статье про наблюдаемость высоконагруженных систем.
Ограничения методики и допущения
Формулы расчета совокупной надежности предполагают независимость отказов компонентов. На практике это не всегда выполняется. Общий источник питания, общая стойка в дата-центре или общий сетевой канал создают зависимость: отказ одного элемента тянет за собой другие. Два сервера, подключенные к одному коммутатору, не являются независимыми с точки зрения сети.
Uptime не учитывает плановые простои на обслуживание. Обновление операционной системы, миграция базы данных, замена оборудования - все это выводит систему из работы, но не считается аварией. Если плановое обслуживание занимает 4 часа в квартал, добавьте это время к допустимому простою.
Для критических систем, где ошибка в расчетах стоит дорого, используйте более сложные методы: анализ дерева отказов, моделирование отказов по распределению вероятностей, учет корреляции между сбоями. Упрощенные формулы подходят для первичной оценки и сравнения вариантов архитектуры, но не заменяют полноценный инженерный анализ.
Шпаргалка: быстрые формулы и таблицы
Сохраните этот раздел для быстрого доступа при проектировании и переговорах.
Перевод uptime в простой:
Простой = (1 - uptime) × периодДля года: (1 - 0.999) × 365 × 24 × 60 = 525.6 минуты = 8 часов 45 минут 36 секунд.
Последовательное соединение:
R_total = R1 × R2 × ... × RnПараллельное соединение:
R_total = 1 - (1 - R1) × (1 - R2) × ... × (1 - Rn)Типовые конфигурации:
- Один сервер с надежностью 0.99 - итоговый uptime 99%.
- Два сервера параллельно с надежностью 0.99 каждый - итоговый uptime 99.99%.
- Три сервера последовательно с надежностью 0.99 каждый - итоговый uptime 97.03%.
- Два сервера параллельно (0.99) + коммутатор последовательно (0.999) - итоговый uptime 99.89%.
Для проверки отказоустойчивости уже работающей системы используйте методики из статьи про тестирование отказоустойчивости. Если вы выбираете облачную инфраструктуру для размещения отказоустойчивой системы, обратите внимание на облачные серверы Timeweb Cloud с возможностью гибкого масштабирования ресурсов.