Почему в системном дизайне нецелесообразно стремиться к 100% надежности?

«Почему в системном дизайне нецелесообразно стремиться к 100% надежности?» — вопрос из категории Архитектура, который задают на 10% собеседований Java Разработчик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Достижение 100% надежности (нулевого времени простоя) требует экспоненциального роста затрат при мизерном практическом выигрыше. Закон убывающей отдачи делает это экономически неоправданным.

Почему 99,99% (или 99,999%) — это практический предел?

Уровень надежности Время простоя в год Что требуется для достижения
99,9% («три девятки») ~8.76 часов Стандартное резервирование, мониторинг.
99,99% («четыре девятки») ~52.6 минут Активно-активные дата-центры, автоматическое переключение.
99,999% («пять девяток») ~5.26 минут Географически распределённые системы, бесшовный failover.
100% 0 минут Теоретически недостижимо (сбой сети, питание, человеческий фактор).

Практический пример (компромисс):

public Response processRequest(Request req) {
    try {
        return primaryService.call(req); // 99.99% успеха
    } catch (ServiceUnavailableException e) {
        // Обработка редкого сценария (0.01%)
        log.warn("Primary failed, using fallback");
        return expensiveFallbackService.call(req); // Дорогой и медленный резерв
    }
}

Ключевые причины:

  1. Стоимость: Каждая дополнительная «девятка» удорожает систему в разы.
  2. Сложность: Резко возрастает сложность проектирования, тестирования и поддержки.
  3. Закон Мёрфи: Полностью исключить все риски (аппаратные сбои, ошибки ПО, человеческий фактор, стихийные бедствия) невозможно.

Вывод: Оптимальный уровень надежности определяется анализом стоимости простоя vs стоимости обеспечения надежности.