Ответ
RTO (Recovery Time Objective) — это целевое время восстановления, максимально допустимая продолжительность простоя системы или сервиса после инцидента. Это ключевой показатель в плане аварийного восстановления (DRP).
На практике это означает: если RTO для критичного платежного сервиса установлен в 1 час, то вся инфраструктура, процедуры и команда должны быть организованы так, чтобы уложиться в этот лимит.
Как это реализуется в DevOps:
- Инфраструктура как код (IaC): Использование Terraform или CloudFormation для быстрого развертывания всей среды с нуля.
- Контейнеризация и оркестрация: Приложения в Docker и Kubernetes легко перезапускаются на здоровых нодах или в другом кластере.
- Автоматизация восстановления: Написание скриптов (например, на Python или Bash) для автоматического переключения трафика, восстановления из бэкапа или запуска standby-окружения.
- Регулярные учения (Disaster Recovery Drills): Мы регулярно тестируем процедуры, чтобы убедиться, что укладываемся в RTO. Например, можем намеренно "уронить" стенд и замерить время полного восстановления из бэкапа.
RTO всегда рассматривается в паре с RPO (Recovery Point Objective), который определяет допустимый объем потери данных (например, восстановление до состояния на 15 минут назад).