Начните с результата, который нельзя надолго потерять
Перечень всего имущества проекта обычно слишком широк. Сначала определите обязательный результат: принять обращение, выполнить заказ или восстановить доступ к рабочим данным. Затем назовите процесс, который его обеспечивает, и оцените последствия остановки во времени. Час перерыва и неделя перерыва могут создавать совершенно разные проблемы. Приоритет не обязательно совпадает с заметностью функции. Красивый публичный сайт может временно уступать по важности доступу к списку текущих обязательств. Полезно отделить критический минимум от привычного полного режима работы. Так план становится реалистичнее: при сбое команда пытается восстановить необходимую функцию, а не одновременно вернуть абсолютно всё.
Найдите зависимости и назначьте ответственных
Для каждого важного процесса перечислите людей, данные, оборудование, внешние сервисы и поставщиков. Отдельно отметьте единственную точку отказа: ресурс, без которого нет работающего обходного пути. Например, инструкция может существовать, но находиться только в недоступном аккаунте того же сервиса, на случай отказа которого её написали. У каждого действия должен быть владелец и резервный исполнитель. Указывайте роль и способ связи, а не только имя человека. Решение использовать резервную копию требует заранее проверенного восстановления; факт наличия файла не доказывает его пригодность. Сведения для аварийной работы должны храниться доступно уполномоченным участникам, но без раскрытия паролей и лишних персональных данных.
Привяжите действия к наблюдаемым условиям
Фраза при серьёзной проблеме связаться с командой оставляет слишком много неопределённости. Лучше заранее определить сигнал: основной канал не работает установленное время, ответственный подтвердил сбой или пропущена контрольная точка поставки. После этого запускается конкретная последовательность действий и назначается время следующей оценки. План должен включать не только переход в резервный режим, но и возврат. Кто подтверждает исправность? Какие записи нужно перенести из временного журнала? Как избежать двойного выполнения заказа? После небольшого учебного разбора обновляйте инструкции по найденным пробелам. Проверка не обязана затрагивать реальных клиентов: настольный сценарий на вымышленных данных уже обнаруживает множество неясных мест.
Попробуйте на практике
Проведите бумажную репетицию сбоя одного сервиса в вымышленном небольшом проекте. Никакие действующие системы отключать не нужно.
- Выберите критический результат и укажите, сколько времени проект условно способен обходиться без него. Объясните последствия превышения этого срока.
- Запишите пять зависимостей процесса и выделите одну, для которой нет резервного варианта.
- Опишите сигнал начала резервного режима, ответственного, три первых действия и момент следующей проверки состояния.
- Смоделируйте восстановление. Перечислите данные, которые нужно сверить, и условие безопасного возвращения к обычной работе.
Как проверить результат. План содержит измеримый сигнал, конкретного владельца действий и порядок возврата. Каждое предположение о резервном ресурсе помечено как проверенное либо требующее отдельного испытания.
Частые вопросы
Нужно ли предусматривать все возможные кризисы?
Нет. Начните с нескольких сбоев, которые могут существенно нарушить обязательства. Универсальные зависимости и способы связи затем помогут адаптировать план к другим ситуациям.
Чем такой план отличается от списка рисков?
Список рисков описывает возможные проблемы. План дополнительно задаёт порядок действий, ответственных, необходимые ресурсы и критерий восстановления работоспособности.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.