Сообщить об ошибкеКороткий ответ
Hot-резерв — это заранее запущенная и постоянно синхронизированная копия системы, готовая принять трафик почти немедленно; cold-резерв — это инфраструктура или данные, которые нужно развернуть/восстановить при наступлении сбоя, что занимает заметно больше времени.
Как это работает подробнее
hot-резерв (например, реплика БД в другом регионе с непрерывной репликацией и балансировщиком, готовым переключить трафик) обеспечивает низкое RTO, но стоит дороже, так как ресурсы простаивают в ожидании. Cold-резерв (например, образ инфраструктуры и бэкапы данных, которые разворачиваются по требованию) дешевле, но RTO измеряется часами, а не минутами.
Пример / кейс
Платёжный сервис использует hot-резерв (реплика БД + активный standby-инстанс в другом регионе), а внутренний аналитический дашборд — cold-резерв (ежедневный бэкап, разворачивается вручную за несколько часов при необходимости).
Ожидаемое поведение: при отказе основного региона платёжный сервис переключается на standby за секунды/минуты, тогда как восстановление дашборда может занять часы — и это осознанный компромисс по стоимости для некритичного сервиса.
Что использовать на практике
- Практический подход. Выбор зависит от требуемого RTO и бюджета — критичные сервисы с жёстким RTO обычно используют hot или warm (промежуточный вариант, частично запущенный) резерв, а менее критичные системы могут обойтись cold-резервом с документированным runbook восстановления.
Подводные камни
- Частые ошибки. Выбирать cold-резерв для системы с жёстким RTO без расчёта реального времени восстановления; считать hot-резерв "бесплатной страховкой", не учитывая его постоянную стоимость; не тестировать переключение (failover) на hot-резерв регулярно, из-за чего механизм переключения оказывается нерабочим именно в момент инцидента.