План восстановления, который не даёт забыть о собственной проверке
Один план на процесс, с RTO и RPO, обязательной ежегодной аттестацией и правилом «четырёх глаз» на согласовании — вместо файла на диске подразделения, про который вспоминают только на аудите.
Жизненный цикл плана
План живёт по точной статусной модели из семи статусов, а не по свободным пометкам «в работе» / «готово». Из «Черновика» план уходит на согласование и становится «Одобренным» только через явное действие согласующего — а дальше, при годовой аттестации, either подтверждается («Аттестация успешно завершена»), либо сразу помечается как непройденная, без промежуточных состояний, в которых легко потерять статус процесса из виду.
Новый план на тот же процесс не плодит дубли
Если у процесса уже есть действующий план, система прямо предупреждает об этом при создании нового: действующий план переносится в архив, а не остаётся висеть рядом со свежим как источник путаницы «какой из двух актуальный».
Из чего состоит план восстановления
Карточка плана — это не одно текстовое поле «опишите порядок действий», а семь отдельных разделов, каждый со своим правом на просмотр и правку: от описания процесса до истории изменений. Разделы «Поставщики» и «Системы и приложения» показываются только тогда, когда к процессу действительно привязаны поставщики или системы, — сотрудник не листает пустые вкладки.
- Процесскритический процесс и его код по Банку России
- Описание планаRTO, RPO, ущерб, порядок перевода и возврата, офисы и резервные площадки
- Поставщикипоказывается, только если к процессу привязаны поставщики
- Системы и приложенияпоказывается, только если к процессу привязаны системы
- Годовая аттестациявидна только после одобрения плана
- Комментарииобсуждение плана внутри карточки, с вложениями
- История измененийкто, когда и что менял в плане
| Поле описания плана | Что фиксирует |
|---|---|
| RTO* | Целевое время восстановления процесса, в часах |
| RPO* | Допустимый объём потери данных или операций, в часах |
| Порядок перевода / возврата | Порядок перевода процесса в режим работы при непредвиденных ситуациях и порядок возврата в обычный режим |
| Ущерб | Оценка ущерба, нематериальный ущерб и обоснование оценки — отдельными полями, а не одной строкой комментария |
| Критичные сотрудники | Список сотрудников, без которых восстановление процесса невозможно |
| Офисы и резервные площадки | Офис, стратегия восстановления, резервная площадка и её вместимость |
| Доп. ресурсы | Произвольный текст о дополнительных ресурсах, нужных для восстановления |
| Координатор восстановления | Сотрудник, ответственный за восстановление подразделения |
Связь плана с критическими процессами
План можно завести по одному процессу — или сразу по всему подразделению: тогда в него автоматически попадают критические процессы этого подразделения и всей его дочерней иерархии, а не только те, что лежат на верхнем уровне. Создать план для подразделения, у которого нет ни одного связанного критического процесса (с учётом дочерних), система не даст — потому что плану тогда нечего восстанавливать.
Что это даёт ИТ-директору. Связь «план ↔ процесс» — это отдельная сущность с датой создания и датой закрытия, а не свободный текст в описании: процесс можно исключить из плана или добавить в него, и об этом уходит уведомление ответственным, вместо тихой правки поля, которую никто не заметит.
Годовая аттестация плана
Годовая аттестация — отдельный раздел карточки, который появляется только у одобренного плана. Он не собирает результаты тестирования вручную: по каждому офису, поставщику и системе плана в раздел автоматически подтягивается последний согласованный тест — с результатом Pass/Fail и связанным недостатком (Issue ID), если тест его породил. Ответственному не нужно поднимать переписку и искать, когда в последний раз тестировали конкретного поставщика, — карточка уже собрала это за него.
Прежде чем завершить годовую аттестацию
Всего обязательных полей, осталось отметить .
Оба поля заполнены — аттестацию можно завершить.
Результат аттестации разводит план по двум путям без серой зоны: при положительном результате план переходит в статус «Ожидание завершения годовой аттестации», а всем СоВ-координаторам уходит уведомление, что нужно подтвердить завершение, — и только их подтверждение закрывает цикл. При отрицательном результате план сразу помечается как «Аттестация не пройдена», без промежуточного шага.
Правило «четырёх глаз» при согласовании
Отправил на согласование — не согласовываешь сам
Система проверяет последнюю запись в журнале статусов плана: если план на согласование отправил текущий пользователь, кнопка «Согласовать» ему недоступна. Это защита не от постороннего, а от собственного сотрудника, который в спешке отправляет план самому себе, чтобы не ждать коллегу.
То же правило действует и для тестирований офисов, поставщиков и систем — подробнее на странице «Права доступа». Каждая смена статуса — план это или тест — пишется в общий журнал (кто, когда, из какого статуса в какой), так что «кто согласовал» не превращается в вопрос без ответа.
Архив поставщиков и систем плана
В момент, когда план одобряется, система фиксирует моментальный снимок его поставщиков и систем — отдельно от рабочих связей, которые могут поменяться позже. Это не дублирование ради дублирования: если после одобрения плана состав поставщиков или систем процесса изменится, у плана останется собственная точная запись о том, что именно было проверено на момент одобрения, — вместо того чтобы историю переписывал текущий, уже другой, состав справочника.
Зачем это нужно на практике. При проверке годовой аттестации важно видеть не «какие поставщики привязаны к процессу сейчас», а «какие поставщики тестировались в рамках именно этого плана». Архивная копия отвечает на второй вопрос, даже когда первый уже изменился.
Показать карточку плана восстановления на вашем стенде
Статусную модель, годовую аттестацию и правило «четырёх глаз» — на процессах, приближенных к вашей оргструктуре.