# Целевые показатели времени восстановления, которые подходят вашей команде и бюджету

> Установите целевые показатели времени восстановления, соответствующие реальным сбоям, рабочему времени сотрудников и бюджетным ограничениям, чтобы план действий при катастрофах превратился в конкретные цели восстановления.

## Почему расплывчатые планы терпят неудачу при сбое

План, который говорит «восстановить быстро», — это не план. Это желание, и желания разваливаются, когда сервис падает в 2:13 ночи. Один человек читает эту фразу и думает «15 минут». Другой считает, что полдня — нормально. Оба уверены, пока не начался сбой.

Этот разрыв в ожиданиях быстро вызывает проблемы. Отдел продаж хочет в первую очередь вернуть клиентский портал. Финансы требуют биллинг. Инженеры могут сосредоточиться на базе данных, потому что всё остальное от неё зависит. Ни один из таких приоритетов не иррационален, но расплывчатые формулировки заставляют людей спорить, когда время уже идёт.

Короткий простой сбой может превратиться в путаный спор о том, что восстановить первым. Каждая минута, потраченная на принятие решения, — это всё ещё время простоя. Команды часто винят сам сбой, но путаница — обычно более серьёзная проблема. Чёткие целевые показатели времени восстановления снимают догадки до того, как кто‑то окажется под давлением.

Непроверенные планы скрывают медленные шаги, которые на бумаге кажутся безобидными. Резервная копия может существовать, но время восстановления зависит от деталей: у кого есть доступ к системе бэкапов, куда надо вернуть данные, сколько реально занимает импорт базы данных, кто может одобрить переключение на запасной ресурс или изменение DNS, и что всё ещё ломается после восстановления сервиса.

Эти детали редко появляются в аккуратном документе. Они всплывают, когда кто‑то не может открыть админку, старый скрипт падает или единственный человек, который знает процесс, спит или в отпуске.

Небольшие компании ощущают это острее, чем большие. Если у вас три инженера, вы не можете притворяться, что у вас есть круглосуточная команда восстановления. План должен соответствовать людям, которые у вас есть, инструментам, которые они знают, и ежемесячной сумме, которую вы готовы платить.

Представьте себе небольшую SaaS‑компанию, которая обещает клиентам, что может восстановиться «быстро». Во время сбоя сервер приложения вернулся первым, но входы всё ещё не работали, потому что сессии и почтовый сервис не вошли в первый этап восстановления. Команда действительно быстро что‑то восстановила. Просто они восстановили не то.

Вот почему расплывчатое планирование аварийного восстановления разваливается. Оно оставляет время, порядок и ответственность открытыми для интерпретаций — а за это сбои наказывают.

## Выберите, что должно вернуться в первую очередь

Большинство планов по восстановлению терпят неудачу по простой причине: они считают все системы одинаково важными. Это не так. Если команда небольшая, нужен короткий порядок восстановления, который защищает денежные потоки, поддержку клиентов и выплату зарплат.

Начните с перечисления систем, которые останавливают бизнес при падении. Для большинства компаний это всё, что связано с продажами, поддержкой или выплатой зарплат. Витрина, платёжный поток, CRM, общий почтовый ящик, телефонная система, трекинг времени и приложение для зарплаты часто важнее внутренних дополнений, которые могут подождать день.

Простая сортировка обычно работает:

- Сейчас: системы, которые должны восстановиться в первую очередь, чтобы бизнес мог принимать заказы, отвечать клиентам или не пропустить выплату зарплат
- В тот же день: системы, которые приносят неудобства, но не останавливают компанию в первый час
- Позже: инструменты, без которых люди могут обойтись день‑два

Держите группы маленькими. Если всё попадает в «сейчас», список бесполезен.

Назначьте для каждой системы одного владельца. Не команду, не отдел, а одного человека. Этот человек не обязан выполнять все шаги восстановления в одиночку, но он должен знать, где хранится резервная копия, как войти и кто может одобрить доступ. Если владельцев трое, то фактически никто не владеет.

Запишите затем, что каждой системе нужно, прежде чем начинать восстановление. Это ловит скрытые проблемы заранее. Ваше приложение биллинга может зависеть от базы данных, записей DNS, облачного хранилища, API‑ключей и почтового сервиса. Почтовый ящик поддержки может требовать сначала работу единого входа. Зарплата может зависеть от доступа по VPN и аккаунта финанса, к которому имеет доступ только один человек.

Небольшой пример иллюстрирует мысль. Допустим, онлайн‑бизнес имеет три ключевые системы: оформление заказа, почта поддержки и расчёт зарплаты. Оформление заказа должно быть в «сейчас», но оно всё равно не запустится, пока не вернут базу данных и платёжные креденшиалы. Почта поддержки — тоже «сейчас», если клиенты ждут быстрых ответов. Зарплата может быть в «тот же день», если сегодня не выплата.

Вот тогда целевые показатели времени восстановления начинают что‑то означать. Вы не выбираете числа в вакууме. Вы задаёте цели восстановления для реальных систем, в реальном порядке, с реальными людьми и зависимостями.