🛠️ Подрядчик передал документацию, но при инциденте команда всё равно звонит ему

Формально handover завершён:

— wiki есть;
— схемы есть;
— runbook есть;
— демонстрации проведены.

Но первый нестандартный сбой снова требует внешнего эксперта.

Частая причина: передали знания о системе, но не проверили способность самостоятельно её эксплуатировать.

Handover лучше строить вокруг рабочих сценариев:

операция
→ рабочий артефакт
→ типовой сбой
→ действия команды
→ граница эскалации

Например: диагностика деградации сервиса.

Команда должна уметь:

— подтвердить симптом;
— построить временную линию;
— определить затронутый компонент;
— собрать логи, метрики и change history;
— выполнить согласованные диагностические шаги;
— понять, когда нужна эскалация.

Демонстрации недостаточно.

Пока подрядчик показывает решение, он использует свой контекст: знает, какой лог открыть, какую ошибку игнорировать, где runbook устарел и когда нельзя продолжать.

Проверка начинается, когда тот же сценарий выполняет внутренняя команда без пошаговых подсказок.

Практика не обязана идти в production. Можно использовать тестовый стенд, модельный инцидент, обезличенные артефакты или controlled lab.

Оценивайте не только финальный ответ:

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

Runbook тоже нужно тестировать. После практики он должен становиться точнее: ссылки, доступы, критерии остановки и границы ответственности проверяются действием.

Вывод: передача эксплуатации — это переход способности действовать, а не только переход документов.

В УЦ ФОРС, мы поможем собрать программу обучения вокруг задач, которые команда должна принять в собственную эксплуатацию.

🔹🔹🔹🔹