Представим обновление небольшого сервиса. Установка занимает около десяти минут, рабочая проверка — ещё пятнадцать. Возврат предыдущего пакета и повторная проверка требуют получаса. К сумме добавим пятнадцать минут запаса: минимальное окно получилось длиной 70 минут.

Если ответственный заканчивает работу в 19:00, последний разумный старт — 17:50. Запуск в 18:30 оставляет время только на удачный сценарий.

Карточка перед запуском

Изменение: обновить пакет web до 4.8.2
Исходное состояние: web 4.8.1, health OK
Старт: 17:50
Точка остановки: 18:15
Проверка: вход, загрузка файла, свежие ошибки
Откат: вернуть 4.8.1 и перезапустить web
Завершить наблюдение: 19:00

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

Что меняет расчёт

Миграция данных может сделать возврат приложения недостаточным. Тогда в карточке отдельно указывают совместимость старой версии с новой схемой и время восстановления данных. Резервная копия полезна только после проверенного восстановления; сам факт её наличия длительность отката не сокращает.

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

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