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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🔹🔹🔹🔹