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

Стоимость простоя PostgreSQL — это не абстрактная метрика, а прямая проекция бизнес-модели на доступность базы данных. Большинство современных сервисов: e-commerce, fintech, SaaS, биллинг, заказы — критически зависят от БД. Если приложение работает, но PostgreSQL недоступна, пользователи не могут оформить заказ, провести платеж, посмотреть баланс, авторизоваться. Поэтому ключевая переменная — процент выручки, зависящий от БД. Для pure-online бизнеса это 95–100%, для гибридного — 40–70%, для внутренних систем — 10–30%. Эта оценка субъективна, и её правильнее делать на основе журнала транзакций или оценки критичности микросервисов.

SLA availability показывает долю времени, в течение которого сервис должен быть доступен. Перевод процентов в минуты неочевиден: 99% — это 432 минуты простоя в месяц, 99.9% — 43.2 минуты, 99.95% — 21.6 минуты, 99.99% — 4.32 минуты. Каждая «девятка» уменьшает допустимый простой в 10 раз и обходится экспоненциально дороже. Поэтому важно понимать, какой SLA вы реально обещаете клиентам и насколько ваша инфраструктура ему соответствует. Часто контракт содержит 99.9%, а фактическая архитектура на один инцидент в квартал уже превышает бюджет.

Время восстановления (MTTR, Mean Time To Recovery) — это окно от отказа до полного возврата в строй. Оно включает обнаружение, диагностику, восстановление из бэкапа, replay WAL, проверку целостности. У хорошо подготовленной команды MTTR — 5–15 минут (автоматический failover), у неподготовленной — 30–180 минут и больше. Если БД на 200 GB без реплики и без протестированного restore-скрипта, MTTR легко уходит за час. Поэтому «стоимость инцидента» — это не теоретическая цифра, а прямая функция вашей операционной зрелости. Уменьшение MTTR на 10 минут в день при стоимости часа 50 000 ₽ экономит 8 333 ₽ на каждом инциденте.

«Худший случай» — 24 часа простоя — моделирует катастрофу: потеря основного дата-центра, corruption без свежего бэкапа, длительный restore из холодного архива. Это верхняя граница потерь, которая помогает обосновать инвестиции в HA-конфигурацию (реплики, patroni, pitr, multi-AZ). Сравните эту цифру со стоимостью перехода на HA — часто HA-инфраструктура окупается уже на одном предотвращённом инциденте в год.