RTO и RPO: как определить требования своей команды

RTO и RPO: как определить требования своей команды

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

Чтобы превратить тревогу в понятный план, я предлагаю сразу заложить практический шаг: описать ваши требования к RTO и RPO в виде технического задания и отдать его ИИ‑сотруднику в Ное. Это делается через лендинг Нои, откуда после входа или регистрации можно перейти к созданию отдельного ИИ-сотрудника под задачу «план RTO/RPO» и дадите ему инструкцию из промпта в конце статьи.

Коротко

• RTO — про то, сколько времени бизнес может терпеть остановку конкретной системы.
• RPO — про то, сколько недавних данных можно потерять без критической боли.
• Одно общее число для всего бизнеса редко работает; я считаю разумнее задавать цели по задачам.
• Цели надо соотносить с реальными возможностями команды и инфраструктуры, а не с желанием «всё за 5 минут».
• Ноя помогает превратить эту логику в конкретный документ для вашей команды без сложных терминов.

Что такое RTO и RPO человеческим языком

Я предлагаю сразу оттолкнуться от человека, а не от серверов.

RTO (Recovery Time Objective) — целевое время простоя конкретной задачи. Не сайта вообще, а, например, приёма заказов. Вопрос: «Сколько времени мы можем жить без этой функции, пока ущерб не станет неприемлемым?»

RPO (Recovery Point Objective) — целевое «окно возможной потери данных». Вопрос: «Сколько последних минут/часов данных мы готовы потерять в худшем случае, если что‑то сломается?»

По материалам AWS про аварийное восстановление такие цели задают не по ощущениям, а в рамках плана непрерывности бизнеса. Я считаю полезным перенести этот подход даже на очень маленькие компании.

Почему одному малому бизнесу мало «универсального» RTO/RPO

Рассмотрим возможную формулировку без отдельных условий: «У нас RTO 30 минут и RPO 15 минут по всему бизнесу». Это звучит спокойно, но вводит в заблуждение.

Разные части бизнеса ценятся по‑разному:

• сайт‑визитка с описанием услуг;
• корзина и оплата;
• CRM с историей клиентов;
• складской учёт;
• справочник товаров.

Я считаю, что ставить одинаковые RTO/RPO для всего — почти всегда ошибка. Например:

• Потеря 30 минут новых заказов в пиковый час интернет‑магазина болезненна.
• Потеря 2 часов изменений в справочнике товаров часто заметна только команде.

Я предлагаю разделять хотя бы 3–4 крупные задачи и обсуждать цели отдельно для каждой. Это упростит диалоги с техподдержкой и подрядчиками и уменьшит риск «приятных, но пустых» обещаний.

Учебная временная шкала: заказы и справочник на цифрах

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

заказы в интернет‑магазине

Условие:

• Сбой системы: 14:20.
• Точка данных (когда копия данных заказов была актуальна): 13:45.
• Файл копии закончил формироваться: 14:15.
• Целевой RPO: 15 минут.
• Подтверждённое завершение задачи восстановления: 15:05.
• Целевой RTO: 30 минут.

Разбор:

• Окно возможной потери данных: от факта сбоя 14:20 до точки данных 13:45 проходит 35 минут. Это 35 минут потенциального окна, а не доказанные потерянные заказы.
• Время простоя: цель RTO — 30 минут от 14:20 до момента, когда задача снова работает. Фактически работа возобновилась в 15:05 — это 45 минут простоя.

Вывод: обе учебные цели (RPO 15 минут и RTO 30 минут) здесь не достигнуты. Но мы не можем по этим цифрам сказать, сколько именно заказов пропало. Для числа потерянных записей нужны отдельные сведения о созданных и восстановленных данных. Неподтверждённый результат заказа или оплаты сначала выясняют; повторять операцию ради вычисления нельзя.

Я считаю полезным отдельно фиксировать:

• когда была сделана копия;
• на какой момент она отражает данные;
• когда реально вернулась работоспособность.

справочник товаров

Условие:

• Сбой: 14:20.
• Точка данных для справочника: 14:10.
• Целевой RPO: 30 минут.
• Подтверждённый результат восстановления: 15:30.
• Целевой RTO: 90 минут.

Разбор:

• Окно возможной потери данных: 10 минут (с 14:10 до 14:20). При цели 30 минут это укладывается в RPO.
• Простои: 70 минут (с 14:20 до 15:30). При цели 90 минут это укладывается в RTO.

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

Ситуация с неизвестными точками данных

Есть третий учебный случай:

• Время сбоя известно.
• Время точки данных неизвестно.
• Время завершения восстановления неизвестно.

Я считаю принципиальным говорить: ничего из этого система сама не «додумает» по часам. Если нет записи о точке данных или принятом результате, измеренные интервалы неизвестны. Заданные цели RPO/RTO могут при этом быть известны; сравнение с ними пока не выполнено. И у ИИ, и у человека нет права дорисовывать эти моменты «по логике».

Как разобрать свой бизнес на задачи для RTO/RPO

Я предлагаю простое разбиение на 4 типа задач. Оно не идеально, но помогает уйти от «одной цифры для всего».

Как действовать:

1. Составьте список систем, которые вы используете.
2. Для каждой отметьте, влияет ли она прямо на деньги в ближайший день.
3. Разбейте на типы по таблице.
4. Для критичных задач обсудите с командой: «Сколько минут/часов простоя мы можем пережить?»
5. Отдельно обсудите, какой объём данных можно восстановить руками, если копии старые.

Я считаю полезным не начинать с точных минут, а сначала поговорить о реальных примерах: «Если корзина лежит 2 часа в пятницу вечером — что будет?»

Как выбрать реалистичные цели, а не «вчера и без потерь»

Цели «RTO 5 минут и RPO 0» требуют проверки для конкретной операции и выбранных отказов. По самим значениям нельзя определить стоимость или объявить цель достижимой.

По обзору вариантов аварийного восстановления в AWS разные стратегии дают разные реальные времена и стоимость:

• чисто резервные копии;
• тёплая резервная площадка;
• горячая актив‑актив схема.

Я предлагаю для малого бизнеса подход по ступеням.

Зафиксировать текущую реальность

Без паники:

• Как часто делаются копии?
• Кто отвечает за их проверку?
• Есть ли проверенная инструкция, как их разворачивать (даже в тесте)?

Не делайте вывод, что раз файл «вчерашний», значит RPO = 24 часа. RPO — это цель, а не описание случайного факта.

Посчитать «порог боли»

• Сколько заказов вы в среднем оформляете за час?
• Какой процент из них можно «добрать» позже?
• Насколько критично потерять адреса и статусы за последние 30 минут?

Я считаю, что честный разговор тут важнее любой формулы. RPO 10 минут без реальных возможностей его достигать хуже, чем 1 час с понятным процессом.

Соотнести цели и возможности

Часто картина такая:

Я предлагаю записать отдельно: «Цели по заказам: RTO 30 минут, RPO 60 минут. Точка пригодной копии и время принятого результата ещё не проверены. Готовность этим целям не подтверждена». Желание улучшить систему не заполняет пропуски измерения.

Две вымышленные истории малого бизнеса

Истории полностью вымышленные, включая роли, слова поддержки и принятые решения. Они нужны, чтобы показать, как меняются требования.

Магазин детской одежды «Малыш+»

Исходные данные:

• Небольшой интернет‑магазин на готовой CMS.
• Хостинг у массового провайдера.
• Копии делает сам хостер раз в сутки.
• Менеджеры дублируют заказы в таблицу, но нерегулярно.

Ход размышления:

1. Владелица Анна считает, что сайт не может лежать больше 30 минут днём.
2. Техподдержка хостинга говорит, что при крупной аварии возврат может занимать «несколько часов».
3. Анна фиксирует слова учебной поддержки как оценку, не как измерение. Подтверждённая точка пригодной копии и момент принятого результата не заданы, поэтому достигнутые интервалы неизвестны. Суточное расписание копий этого не исправляет.

Решение:

• Анна выбирает цель: для оформления заказов RTO 60 минут, RPO 60 минут.
• При этом достижимость целей имеющимися средствами не подтверждена; сначала требуется отдельная согласованная проверка.
• Она обсуждает с подрядчиком перенос сайта к другому провайдеру и план резервирования (подробнее о таких шагах мы писали в материале «Перенос сайта в другое облако: что собрать до начала»).

Случай отказа:

• Подрядчик честно говорит, что гарантировать такие цифры без переработки архитектуры и дополнительных затрат он не может.
• Анна рассматривает вариант целей RTO 2 часа и RPO 4 часа. Она принимает его только если такие потери допустимы для задач и обязательств; более мягкая цифра сама не делает копии пригодными.
• Я считаю такое честное понижение ожиданий полезным: оно избавляет от иллюзий и аварийных конфликтов.

Сервис планирования тренировок «Форма Online»

Исходные данные:

• Онлайн‑платформа с видеоуроками.
• Основной доход — абонементы, а не разовые заказы.
• Справочник тренировок меняется редко, но личные программы клиентов — очень чувствительные данные.

Разбор:

1. Владельцу Сергею важнее не потерять персональные планы, чем выдержать любую минуту простоя.
2. Он формулирует: для личных планов RPO 5 минут, RTO до 2 часов он готов терпеть ночью.

Реальность:

• Текущие копии раз в час и только по базе целиком.
• Не выделены планы отдельно в схеме.

Решение:

• Сергей выбирает цель на год: RPO 15 минут по планам, RTO 2 часа ночью и 1 час днём.
• Для остального сайта RPO 24 часа его устраивает.
• Подрядчик предлагает изучить подход к более частой пригодной точке данных. Набор связанных данных и согласованность копии выбирает специалист: копия отдельной таблицы может не позволить восстановить всю задачу.

Случай отказа:

• На тестовом восстановлении выходит, что 15‑минутный RPO пока недостижим при текущем бюджете.
• Сергей рассматривает целевой RPO 30 минут и проверяет его допустимость для обязательств. Ручная корректировка возможна только по подтверждённым источникам; недостающие планы и сведения о клиентах не восстанавливают догадкой.
• Я считаю такой гибкий подход разумным: защищаем самое ценное, остальное — по остаточному принципу.

Где ограничения: что RTO/RPO не обещают

RTO и RPO — это цели, а не гарантии и не прогноз поведения конкретного хостинга или банка. Они:

• не обещают, что сервисы сторонних компаний будут доступны;
• не гарантируют отсутствие ошибок персонала;
• не защищают от юридических и репутационных последствий.

Отдельно по вашему случаю с Ной:

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

Так же и с вашими системами: если вы ни разу не проверяли восстановление, я предлагаю относиться к любым оценкам RTO/RPO как к гипотезам, а не как к фактам.

Этапы получения среды и принятия операции разобраны в плане восстановления сервисов. Целевой интервал своей команды не назначает срок поставщику. В сообщении об управлении отказоустойчивыми БД также различаются доступ к настройке и принятый результат.

Как учитывать сторонние сервисы и облака

Малый бизнес часто живёт на связке: сайт, CRM, платёжка, рассылки. Часть в одном облаке, часть в другом, часть у локального провайдера.

Я считаю полезным:

• Разделять то, что вы контролируете, и то, что контролирует поставщик.
• Не переносить на российские сервисы гарантии и схемы, описанные в документации AWS или других международных провайдеров.
• Прямо выписывать, от кого зависит каждый шаг восстановления.

Простая табличка:

В статье «Резервные сервисы: как проверить независимость» разбирается, как подходить к выбору дополнительных сервисов. Здесь я предлагаю главное: не считать, что резервный сервис точно переживёт аварию основного, пока это не проверено хотя бы сценарно.

Как проверять гипотезы без реального аварийного восстановления

Настоящую аварию устраивать не нужно. Достаточно учебного теста.

Я предлагаю три уровня:

1. Бумажный сценарий.

• Описать, что делаем, если сайт недоступен в 14:20 в пятницу.
• Кто кому пишет, какие решения принимает владелец.

2. Тест на копии в изолированной среде.

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

3. Корректировка целей.

• Если на тесте вышло 2 часа, а вы хотели RTO 30 минут, у вас выбор: или дорабатывать архитектуру, или менять цель.
• Я считаю честным изменить цель и записать это в план.

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

Как объяснить RTO/RPO своей команде

Чтобы согласовать смысл терминов, я предлагаю короткие формулировки для команды. Предлагаю формулировки для внутрикомандного чата:

• «RTO по заказам у нас 2 часа — это значит, что мы целимся поднять оформление заказов не позже, чем через 2 часа после сбоя».
• «Целевой RPO по заказам 1 час: более старое состояние для нас неприемлемо. Достижимость этой цели ещё нужно подтвердить; восстановление по переписке отдельно не обещаем».
• «По справочнику нам достаточно RPO 24 часа, потому что изменения не такие частые, их можно вернуть руками».

Я считаю полезным раздать одну страницу с этими определениями всем: от руководителя до администратора. Тогда разговор «сайт лежал 40 минут» превращается в разговор «мы вышли за наш RTO 30 минут, что можно улучшить?».

Как использовать Ною для подготовки плана RTO/RPO

Теперь — к практике. Ноя — это платформа создания сайтов и ИИ‑сотрудников. В этой теме нас интересует ИИ‑сотрудник, который:

• берёт от вас исходные данные о бизнесе и системах;
• по понятным правилам превращает их в черновик документа по RTO/RPO;
• помогает выделить неизвестное, но его ответ требует ручной проверки: ошибки и выдуманные выводы возможны.

Маршрут такой:

1. Зайти на лендинг Нои.
2. Пройти вход или регистрацию.
3. Создать нового ИИ‑сотрудника для задач «планы и регламенты».
4. Вставить промпт из следующего раздела как полную инструкцию.
5. Ввести учебные или реальные обезличенные данные о ваших задачах.
6. Получить текстовый документ, проверить его руками и скорректировать.
7. Уже после этого решать, что менять в инфраструктуре и договорах.

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

Подробный учебный промпт для ИИ‑сотрудника в Ное

Ты — отдельный ИИ-сотрудник Нои для подготовки документа о целях RTO/RPO рабочих задач. Действия, поиск и доступы в этом сценарии не подключены: ты не восстанавливаешь данные, не меняешь систему и не отправляешь сообщения. Ноя — платформа сайтов и ИИ-сотрудников; здесь используется документ по вводным.

Поля: [ЗАДАЧА] — нужный принятый результат; [ЦЕЛЕВОЙ_RTO] — заданная допустимая длительность недоступности; [ЦЕЛЕВОЙ_RPO] — заданная допустимая давность состояния; [СБОЙ] — известное начало недоступности; [ТОЧКА_ДАННЫХ] — момент состояния пригодной копии; [ГОТОВНОСТЬ_ФАЙЛА] — когда завершён файл, это другое время; [ПРИНЯТЫЙ_РЕЗУЛЬТАТ] — момент подтверждённого возвращения задачи; [ОГРАНИЧЕНИЯ] — известные пределы и ответственный.

Если пользователь не дал другие данные, разберись с двумя вымышленными задачами одного дня в одном часовом поясе. Заказы: сбой14:20, пригодная точка13:45, файл закончен14:15, цельRPO15минут, принятый результат15:05, цельRTO30минут. Справочник: сбой14:20, пригодная точка14:10, цельRPO30минут, принятый результат15:30, цельRTO90минут. Это только арифметический пример; никаких настоящих потерь или восстановлений не измерено. Другие данные пользователя замещают пример: не добавляй к ним названия и числа из него.

1. Сразу дай полезный предварительный документ по известному. При нехватке данных уточни максимум три решающих вопроса после документа. Не возвращай полную анкету и не выдумывай ответы.
2. Раздели цели и измеренные интервалы. Цели задаёт пользователь/команда; не выбирай их сам, не выдавай частоту расписания копий за целевой или достигнутый RPO. Необоснованные числа оставь неизвестными.
3. Для пригодной точки данных посчитай разницу со сбоем. Для принятого результата — разницу с началом недоступности задачи. В базовом примере это35и45минут для заказов,10и70минут для справочника. Покажи арифметику; дата готовности файла14:15 не заменяет точку13:45.
4. Сравни каждый известный интервал со своей известной целью: выполнено в данном учебном случае, превышено либо сравнение неизвестно. Цели заказов превышены, справочника выполнены только по условиям примера. Это не доказанное число потерянных записей и не обещание будущей работы.
5. Если время, день, часовой пояс или пригодность копии неизвестны, прямо обозначь ограничение расчёта. Не выводи неизвестные значения из системных часов. Неизвестный момент принятого результата не заменяй началом работ специалиста.
6. Подготовь таблицу: задача, цели, известная точка, принятый результат, вычисленные интервалы, вывод и что уточнить ответственному. Не выдумывай уже начатые работы, роли, использование облака, оплату или договорённости.
7. Опиши один следующий вопрос специалисту о достижимости. Не назначай провайдеру ETA, не обещай компенсацию или работу резерва. Не проси ключи, пароли, клиентскую базу и финансовую историю. Не предлагай живое удаление, переключение, платежи или повтор неизвестной операции.
8. При просьбе выполнить внешнее действие прямо скажи, что оно не выполнено. Итог примерно500–700слов: определения, таблица, ограничение, один следующий шаг и не более трёх вопросов. Применение документа вручную проверяет человек.

Частые вопросы владельцев малого бизнеса

Как простыми словами объяснить RTO и RPO сотрудникам?

RTO — сколько времени вы готовы мириться с тем, что конкретная функция не работает. RPO — сколько последних минут или часов данных в худшем случае можете потерять. Я советую объяснять это через примеры: «если сайт лежит 40 минут, а цель 30, значит, вы вышли за свой RTO».

Можно ли считать частоту бэкапов реальным RPO?

Нельзя напрямую. Частота копий — это технический параметр, а RPO — ваша бизнес‑цель по максимально допустимому окну потери данных. Копии раз в час могут поддерживать цель RPO 30 минут только при дополнительных механизмах; я предлагаю всегда проговаривать разницу между «как хотим» и «как сейчас».

Как понять, что мои цели по RTO нереалистичны?

Признак — ни разу не было даже учебного восстановления, но вы записали RTO в 10–15 минут. Я считаю, что без теста и описанной процедуры такая цифра — просто желание. Сделайте хотя бы один тест в изолированной среде и замерьте реальное время.

Что делать, если поставщик не называет свои RTO и RPO?

Тогда в ваш план можно включить только внутренние цели и пометить зависимость от внешнего сервиса как неопределённую. Я предлагаю честно записывать: «RTO агрегатора оплат неизвестно, следует запросить официальные данные или предусмотреть альтернативный сценарий оплаты».

Как учитывать справочник товаров в RTO и RPO?

Чувствительность справочника определяет ваша задача. Например, для цен действующих заказов его актуальность может быть критична. Цели задают отдельно; восстановление вручную допустимо только по подтверждённым данным, если такая процедура согласована. Я советую фиксировать для справочника отдельные цели и не привязывать их к самым строгим требованиям по заказам.

С чего начать, если RTO и RPO у меня вообще не описаны?

Я предлагаю начать с инвентаризации: выпишите 5–7 основных задач (заказы, оплата, CRM, склад, сайт, рассылки) и оцените для каждой «порог боли» по простоям и потере данных. Потом перенесите это в черновой документ — в том числе через ИИ‑сотрудника Нои — и обсудите с техподдержкой.

Обязательно ли согласовывать RTO/RPO с подрядчиками?

Если вы хотите, чтобы цели были хоть как‑то реализуемы, да. Внутренний план без обсуждения с техподдержкой и хостерами — это список желаний. Я считаю разумным сначала сформулировать свои цели, а потом отдельно проговорить, какие из них реально поддерживаются существующей инфраструктурой и договорами.

Краткий вывод и следующий шаг

RTO и RPO — это не про «магические цифры айтишников», а про вашу готовность терпеть простои и потери данных в каждой конкретной задаче бизнеса. Они не гарантируют отсутствие аварий и не подменяют собой договоры с поставщиками, но помогают разговаривать с командой и подрядчиками на одном языке.

Следующий шаг, который я предлагаю: перенесите логику из этой статьи в практику. Зайдите на лендинг Нои, создайте ИИ‑сотрудника, дайте ему промпт из раздела выше и получите первый черновой документ по RTO/RPO для вашей команды. После ручной проверки вы сможете спокойнее разговаривать о рисках и требованиях к доступности, даже когда вокруг меняется инфраструктура и сервисы.

Источники и проверка учебной арифметики

Содержательные части AWS: цели непрерывности и AWS: варианты восстановления сверены 13 октября 2026 года; дата редакции не установлена. Они подтверждают смысл целей и различие подходов, не готовность российского сервиса или права на компенсацию.

Временные интервалы двух основных вымышленных задач дополнительно пересчитаны программно:35/45 минут для заказов,10/70 минут для справочника. Это проверка арифметики заданных условий. Рабочая система не восстанавливалась, число реально утраченных записей не измерялось.

Учебная проверка в Ное

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

В первом ответе правильно получились 35/45 минут для заказов и 10/70 для справочника. Цели заказов превышены, справочника выполнены только в заданном случае. Во втором ответе восстановление не начато, гарантии отвергнуты. Но модель придумала московский часовой пояс и дату, а запрос гарантии оформила как предложенные цели, хотя выбор целей не подтверждён. Эти сведения я удалил.

Редакторский итог:

Это проверенный пересчёт и обработанный учебный ответ. Расписание и часы ИИ не создают факта восстановления; реальные потери не измерены.