Четыре показателя, которые путают
| Показатель | Вопрос, на который отвечает | Кто определяет | Пример |
|---|---|---|---|
| MTPD, допустимое время простоя | Сколько процесс может стоять, прежде чем ущерб станет неприемлемым | Владелец процесса по результатам BIA | Отгрузка: 24 часа |
| RTO, целевое время восстановления | За сколько процесс должен заработать хотя бы на минимальном уровне | Владелец процесса, ИТ подтверждает достижимость | 8 часов |
| RPO, целевая точка восстановления | Сколько данных допустимо потерять, в часах до инцидента | Владелец процесса, ИТ подтверждает периодичностью копий | 4 часа |
| MBCO, минимальный уровень | Какой объем и качество услуги достаточны в период восстановления | Владелец процесса | 50 процентов дневного объема по приоритетным клиентам |
Соотношение простое: RTO всегда меньше MTPD, иначе план гарантирует неприемлемый ущерб. RPO отдельно от RTO: можно восстановить систему за час и потерять данные за неделю.
Как определить RTO и RPO для процесса
Пять шагов, которые укладываются в одну встречу с владельцем процесса.
- Взять MTPD из BIA. Если BIA нет, оценить, на каком горизонте (4 часа, день, 3 дня, неделя, месяц) ущерб становится неприемлемым, по шкале из формы BIA.
- Назначить RTO как долю MTPD, обычно от трети до половины: запас нужен на обнаружение инцидента и принятие решения, которые в RTO обычно не считают.
- Определить RPO через вопрос «какой объем операций мы готовы восстановить вручную»: если за час в процессе проходит 50 заказов и их можно восстановить по почте, RPO час; если 5 000 платежей, RPO минуты.
- Сформулировать MBCO конкретно: процент объема, перечень клиентов, ручной режим.
- Спросить ИТ о факте: за сколько реально восстанавливали на последнем тесте и как часто делаются копии. Разница между целью и фактом и есть содержание матрицы.
Столбцы матрицы и зачем каждый
В шаблоне 14 столбцов. Первые восемь описывают цель: процесс, подразделение, владелец, MTPD, RTO, RPO, MBCO, ключевые системы. Следующие два описывают факт: время восстановления по последнему тесту и фактическая периодичность копий. Столбец «разрыв» заполняется словом «да», когда факт хуже цели. Последние три: стратегия закрытия разрыва, срок, дата пересмотра.
Матрица остается рабочей, пока в ней заполнен столбец факта. Матрица с одними целями превращается в декларацию, которую ИТ воспринимает как претензию, а бизнес как гарантию.
Скачать шаблон
Скачать шаблон. Лист «Матрица» с 14 столбцами и примером заполнения, лист «Справочник» с определениями и правилами. Формат xlsx.
Строки добавляются по числу критичных процессов; источник перечня процессов реестр критически важных процессов. Файл отдается без регистрации и форм. Если шаблон нужно адаптировать под вашу организацию или пройти с ним проверку, напишите: как мы это делаем и сколько занимает.
Разрывы и что с ними делать
Типичная картина после первого заполнения: у трети процессов RTO достижимо, у трети разрыв закрывается деньгами, у трети разрыв закрывается только изменением цели. Три варианта действий, и все три законны:
- Закрыть деньгами: вторая площадка, более частые копии, резервный канал. Матрица дает обоснование бюджета: цифра разрыва и ущерб из BIA.
- Закрыть процессом: ручной режим на время восстановления, например прием заказов по телефону. Тогда RTO системы может быть больше RTO процесса.
- Изменить цель: владелец процесса признает, что 8 часов это желание, а 24 часа реальность, и правление утверждает новый RTO. Это честнее, чем план с невыполнимой цифрой.
Какой вариант выбрать, подсказывает стоимость дня простоя: если час простоя стоит дороже резервного канала за год, выбор очевиден.
Частые вопросы
RTO это время, за которое процесс должен заработать после инцидента. RPO это допустимая потеря данных, выраженная во времени до инцидента: при RPO 4 часа копии делаются не реже чем раз в 4 часа. Показатели независимы: можно восстановиться быстро и потерять много данных.
Владелец процесса, потому что он знает ущерб от простоя. ИТ подтверждает, достижимы ли цифры, и называет стоимость их достижения. Утверждает правление в составе плана непрерывности.
MTPD это максимально допустимое время простоя, после которого ущерб неприемлем. RTO всегда меньше MTPD, обычно треть или половина, чтобы оставить запас на обнаружение инцидента и принятие решения.
Через объем операций, который готовы восстановить вручную: если за час проходит 50 заказов и их можно восстановить по переписке, RPO час; если тысячи платежей, RPO минуты. Затем сравнить с фактической периодичностью резервного копирования.
От реестра рисков к решениям руководства
Проверьте, доходят ли ваши риски до тех, кто принимает решения. Дашборд показывает состояние одним экраном, система под ключ доводит его до рабочего.