Проверка готовности
Провалённый тест не теряется: система сама заводит повтор и с пятой попытки поднимает вопрос выше
Четыре вида тестирования восстановления — офис или площадка, поставщик, аттестация поставщика, система или приложение. У каждого теста свой срок, ответственный, счётчик попыток и согласование. Отрицательный результат порождает дочернюю запись повтора автоматически, а не по чьей-то доброй памяти.
ОНиВД — обеспечение непрерывности и восстановления деятельности; англоязычное обозначение — Continuity of Бизнес-подразделение (CoB).
Четыре вида тестирования — одна дисциплина
Разные объекты проверки, но общая механика: срок, ответственный, результат, обязательное согласование, счётчик попыток и автоматический повтор при провале. Благодаря этому сводка по готовности собирается по одному правилу, а не склеивается из четырёх разных таблиц.
- Офис или площадка Проверка готовности подразделения работать с резервной площадки по выбранной резервной стратегии. Фиксируется состав участников и результат.
- Поставщик Проверка готовности внешнего поставщика услуги, от которой зависит критичный процесс. Ведётся дата предыдущего и следующего теста.
- Аттестация поставщика Отдельный вид записи со своей карточкой и своим согласованием. Именно её годовая аттестация подразделения берёт как подтверждение по поставщику.
- Система или приложение Тест переключения на резервную схему: отдельно фиксируются начало переключения, окончание и его результат.
Тест не двинется по маршруту, пока не введён результат
Кнопка отправки на согласование недоступна, пока в карточке пусто поле результата. Закрыть проверку формально — «провели, оформим потом» — нельзя: запись останется в работе и попадёт в ночную проверку сроков как незакрытая.
Тесты офисов и площадок: проверяется тройка «офис — площадка — резервная стратегия»
Одному подразделению может соответствовать несколько сочетаний площадки и резервной стратегии, и каждое проверяется своим тестом. Это важнее, чем кажется: годовая аттестация ищет подтверждение именно по такой тройке, поэтому «мы тестировали резервный офис» без указания стратегии в подтверждение не превращается.
| Поле карточки | Что оно решает |
|---|---|
| План непрерывности | Привязывает тест к плану критичного процесса — и к отчётности по этому плану. |
| Подразделение | Определяет, кто увидит запись в реестре: фильтр по оргструктуре работает и здесь. |
| Офис и площадка размещения | Та самая тройка, по которой аттестация ищет последний согласованный тест. |
| Резервная стратегия | Что именно проверяли: переезд, удалённая работа, перевод на другую площадку. |
| Участники | Кто был задействован — состав переносится в повтор, если тест провален. |
| Дата теста и дата следующего теста | Первая попадает в ночную проверку сроков, вторая задаёт горизонт планирования. |
| Результат и причина провала | Без результата тест не уйдёт на согласование; провал открывает поле причины. |
| Номер попытки | Счётчик цепочки: у первого теста единица, у каждого повтора — на единицу больше. |
| Кто и когда согласовал | Проставляется системой в момент перехода в состояние «Согласован». |
Поставщики: тест и аттестация — две разные записи, и это осознанно
Тест поставщика подтверждает, что услуга восстанавливается в заявленные сроки. Аттестация поставщика — самостоятельная запись со своей карточкой и своим согласованием, и именно она служит годовым подтверждением по контрагенту. Разделение снимает вечный спор «мы же тестировали в марте» — тест и годовое подтверждение больше не путаются.
Тест поставщика
Ведёт дату предыдущего теста, дату текущего и дату следующего, состав участников, результат и причину провала. К записи привязываются выявленные недостатки и планы корректирующих действий.
Аттестация поставщика
Отдельная карточка с собственным разделом и правом доступа. Годовая аттестация подразделения берёт по каждому поставщику последнюю аттестацию в состоянии «Согласован» — по дате, а не по тому, какую строку вспомнили.
Любой тест — офиса, поставщика, системы или кризисное учение — связывается с недостатками и планами корректирующих действий, которые ведутся в модуле управления недостатками той же платформы. Создание и снятие связи попадает в журнал изменений, поэтому «недостаток был закрыт задним числом» становится видимой операцией.
Системы и приложения: переключение фиксируется по времени, а не по факту «всё получилось»
В карточке теста системы отдельными полями хранятся начало переключения на резервную схему, окончание переключения и результат самого переключения — независимо от общего результата теста. Это даёт то, ради чего тесты и проводят: измеренное время перехода, которое можно сопоставить с заявленным RTO плана.
Таблица прокручивается вбок.
| Поле | Значение | Заполнение |
|---|---|---|
| Система или приложение | Расчётное приложение | из справочника ИТ-объектов |
| План непрерывности | П-41 · Расчёты по операциям с ценными бумагами | связь с планом |
| Дата теста | 07.09.2026 | участвует в ночной проверке сроков |
| Начало переключения | 07.09.2026 02:10 | отдельное поле |
| Окончание переключения | 07.09.2026 03:35 | отдельное поле |
| Результат переключения | Успешно | отдельно от общего результата теста |
| Офис и площадка | Резервный вычислительный центр | из справочника площадок |
| Результат теста | — | обязательно перед согласованием |
| Номер попытки | 1 | проставляется системой |
| Дата следующего теста | 07.03.2027 | горизонт планирования |
| Недостаток | связан с планом корректирующих действий | связь фиксируется в журнале |
| Статус | На согласовании | меняется переходом, а не правкой поля |
Кто и когда согласовал — проставляется системой в момент перехода, руками эти поля не редактируются.
Состав колонок, полей, этапов и статусов — как в продукте. Данные в строках — пример заполнения.
Повтор создаётся сам, попытки считаются, с пятой вопрос уходит выше
Это главный механизм страницы. Провалённый тест в большинстве организаций живёт ровно до тех пор, пока о нём помнит один человек. Здесь при согласовании теста с отрицательным результатом система создаёт дочернюю запись повтора: с тем же планом, тем же объектом, той же резервной стратегией и тем же составом участников, но с номером попытки на единицу больше и в состоянии «Создан».
Схема прокручивается вбок.
Состав этапов и правило эскалации — как в продукте: порог одинаков для всех четырёх видов тестирования, уведомление уходит по обоим каналам.
Что стоит за элементами схемы: номер попытки · корневой тест · порог эскалации · перенос связей
Что переносится в повтор
План, проверяемый объект, резервная стратегия, состав участников и ссылка на родительскую запись. Заводить повтор с нуля не нужно — и «забыть» перенести половину связей тоже.
Что остаётся пустым
Дата повтора. Её назначает ответственный. Пока дата не назначена, ночная проверка ежедневно напоминает об этом — повтор не «зависает» между попытками.
Что происходит на пятой попытке
Как только номер попытки превышает четыре, уведомление уходит не автору повтора, а ответственному по корневому тесту цепочки. Проблема перестаёт быть личной задачей исполнителя.
Копия теста не наследует чужое согласование
При копировании записи система обнуляет идентификатор, отметку о согласовании и согласовавшего сотрудника, ставит текущего пользователя ответственным, обновляет даты создания и изменения и переводит копию в состояние «Создан». Скопировать согласованный тест и выдать копию за пройденную проверку невозможно.
Семь состояний теста и то, что каждое означает для ответственного
Статусная модель теста устроена так же, как у плана: пользователь выполняет действие, а не выбирает статус. Возврат на доработку требует комментария, согласование закрыто для того, кто сам отправил запись на согласование.
| Состояние | Код | Что это означает для работы |
|---|---|---|
| Создан | created | Запись заведена, дата и результат ещё не проставлены. В этом состоянии рождается каждый автоматический повтор. |
| Ожидание | waiting | Тест запланирован и ждёт проведения. Ночная проверка следит за его датой. |
| На согласовании | onConfirmation | Результат введён, ответственность передана согласующему. Автор отправки согласовать не сможет. |
| На доработке | onRevision | Согласующий вернул запись с обязательным комментарием. Комментарий сохранён в журнале статусов. |
| Согласован | approved | Проверка принята. Проставлены дата согласования и согласовавший сотрудник. При отрицательном результате здесь же создаётся повтор. |
| Повторное тестирование | retesting | Отметка цепочки повторов: проверка идёт заново по тому же объекту. |
| В архиве | archived | Запись снята с оперативного контроля вместе со всей историей и связями. |
Права выдаются на каждое состояние отдельно, поэтому «согласовать» и «вернуть на доработку» — это два разных права, которые можно дать разным людям. Как это настраивается — в разделе «Права доступа и аудит».
Календарь показывает собственные тесты — чужие в нём не мешают
Календарь собирает тесты офисов, поставщиков, систем и кризисные учения, у которых текущий пользователь указан ответственным и назначена дата. Каждый вид отмечен своим цветом, запись открывается по клику в отдельной вкладке. Ответственный видит свою нагрузку, а не общий список организации.
Просрочен Срок сегодня Дата не назначена Запланирован
Три из четырёх состояний на этой шкале система выставляет сама, без участия человека: ночная проверка ежедневно отбирает просроченные тесты, тесты со сроком сегодня и повторы без назначенной даты. Как устроены сроки и рассылка — в разделе «Сроки и уведомления».
Что это даёт ИТ-директору
- 4типа записей тестирования проходят через одну статусную модель — один набор прав вместо четырёх
- 1фоновое задание отвечает за все сроки: одна точка настройки и одна точка контроля
- 2канала доставки уведомлений: внутри приложения и на внутреннюю почту сотрудника
- 0исходящих сетевых вызовов: тестирование не требует выпускать модуль наружу
Тесты систем и приложений опираются на справочник ИТ-объектов, который ведётся в модуле управления операционным риском той же платформы, — отдельная база активов под непрерывность не заводится. Разделы карточек тестов — самостоятельные объекты защиты: сотруднику подрядчика можно открыть только карточку теста поставщика, не открывая ни планов, ни систем.
Что входит и что настраивается под вашу организацию
Что входит
- Реестры и карточки четырёх видов тестирования восстановления
- Статусная модель из семи состояний с обязательным комментарием на возврате
- Запрет движения по маршруту без введённого результата
- Автоматическое создание повтора при отрицательном результате с переносом связей и составом участников
- Счётчик попыток и эскалация ответственному по корневому тесту цепочки с пятой попытки
- Простановка даты и автора согласования системой
- Связь тестов с недостатками и планами корректирующих действий
- Календарь собственных тестов с цветовой разметкой по видам
Что настраивается под вашу организацию
- Справочник резервных стратегий и справочник площадок
- Периодичность тестирования по видам объектов — через поле даты следующего теста
- Права на согласование и на возврат на доработку по каждому состоянию
- Состав участников теста и роли, из которых он набирается
- Классификация недостатков и планов корректирующих действий
- Соответствие ролей продукта вашим подразделениям
Кому подходит: организациям, где тестирование восстановления проводится регулярно и по нескольким контурам сразу — собственные офисы, внешние поставщики, ИТ-системы — и где нужно доказуемо показать, что провалённая проверка была доведена до положительного результата.
Провести ваш просроченный тест через повтор и эскалацию
Возьмите одну реальную проверку, которая была провалена и потом потерялась. На демонстрации заведём её, согласуем с отрицательным результатом и покажем, как появляется повтор и что происходит на пятой попытке.