Короткий ответ: не начинайте передачу со смены всех паролей и потока срочных заявок. Сначала зафиксируйте состав инфраструктуры, критичные сервисы, владельцев доступов, состояние резервных копий и канал обращений. Затем передавайте ответственность по этапам: инвентаризация, безопасный доступ, стабилизация и регулярная эксплуатация.
Что должно быть известно до первого дня
Полной документации обычно нет. Для старта достаточно минимального набора, который позволяет работать без догадок и не потерять контроль.
| Блок | Минимум для передачи | Что проверить |
|---|---|---|
| Пользователи и офисы | Сотрудники, рабочие места, филиалы, удаленные сотрудники | Кто согласует доступы и приоритеты |
| Серверы и сервисы | AD, файловые ресурсы, 1С, почта, VPN, облачные системы | Что критично для работы и от чего зависит |
| Сеть | Маршрутизаторы, провайдеры, Wi-Fi, VLAN, внешние адреса | Где находятся конфигурации и резервные каналы |
| Доступы | Администраторские учетные записи, панели, домены, лицензии | Компания владеет учетными записями и может отозвать доступ |
| Резервные копии | Что копируется, куда, как часто и кто получает ошибки | Есть успешный тест восстановления, а не только зеленый статус задания |
| Поддержка | Канал заявок, приоритеты, ответственные, окно обслуживания | Пользователи понимают, куда обращаться и когда ждать ответ |
1. Назначьте владельца передачи со стороны компании
Подрядчик не должен самостоятельно угадывать, кто может согласовать доступ к бухгалтерии, остановку сервера или закупку оборудования. Нужен один координатор и резервный контакт. Они подтверждают приоритеты, владельцев бизнес-сервисов и допустимые окна работ.
2. Проведите инвентаризацию без остановки работы
Сначала фиксируется фактическое состояние: устройства, серверы, сеть, учетные записи, лицензии, домены, сертификаты, backup и внешние подрядчики. Необязательно ждать идеального паспорта инфраструктуры. Важно разделить данные на три группы:
- подтверждено — проверено доступом, конфигурацией или ответственным сотрудником;
- требует проверки — информация есть, но ее актуальность не подтверждена;
- неизвестно — владелец, пароль, схема или назначение пока не установлены.
Такой список полезнее красивой схемы, в которой старые серверы и неработающие резервные копии отмечены как действующие.
3. Передавайте доступы через контролируемый контур
Административные доступы должны принадлежать компании, а подрядчик получает отдельные учетные записи. Общие логины без истории действий лучше постепенно заменить персональными. Пароли меняют после проверки зависимостей: старый пароль может использоваться службой, заданием backup, VPN или интеграцией.
Минимальные правила:
- отдельная учетная запись для каждого администратора;
- MFA там, где сервис ее поддерживает;
- фиксация владельца учетной записи и способа аварийного доступа;
- отзыв старых доступов только после подтверждения, что новый контур работает.
4. До изменений проверьте backup и возможность восстановления
Передача инфраструктуры часто совпадает с накопившимися проблемами, поэтому первые изменения особенно рискованны. До обновлений, миграций и массовой смены настроек нужно понять, какие данные критичны, где находятся копии и как выполняется восстановление.
Зеленый статус задания не доказывает, что данные можно вернуть. Нужен хотя бы выборочный тест: открыть восстановленный файл, поднять копию базы в изолированной среде или проверить процедуру восстановления конфигурации сетевого устройства.
5. Отделите приемку от модернизации
В первые дни подрядчик неизбежно найдет устаревшие системы, открытые доступы и технический долг. Не стоит исправлять все одновременно. Сначала закрываются критичные риски и восстанавливается управляемость, затем формируется отдельный план модернизации с приоритетом, стоимостью, влиянием и способом отката.
- Критично: риск простоя, потери данных или неконтролируемого внешнего доступа.
- Важно: повторяющиеся сбои, отсутствие мониторинга, документации или резервирования.
- Планово: обновление оборудования, лицензий и архитектуры без немедленного риска.
6. Зафиксируйте заявки, SLA и границы ответственности
До начала регулярной поддержки нужно определить канал обращений, уровни приоритета, сроки реакции, порядок эскалации и перечень проектных работ. Срочность определяется влиянием на бизнес: остановка 1С для всей компании важнее настройки подписи одному пользователю, даже если второе обращение отправлено раньше.
Отдельно фиксируется, кто отвечает за провайдера, телефонию, 1С, облачные лицензии, видеонаблюдение и оборудование на гарантии. Подрядчик может координировать смежных исполнителей, но зона ответственности должна быть видна заранее.
Когда передачу можно считать завершенной
- есть актуальный список систем, устройств и ответственных;
- проверены административные доступы и аварийный способ входа;
- критичные сервисы включены в мониторинг;
- резервные копии проверены восстановлением;
- пользователи знают единый канал обращений;
- согласованы приоритеты, эскалация и окна работ;
- риски разделены на критичные, важные и плановые;
- руководитель получил короткий отчет о текущем состоянии и ближайших действиях.
Типовые ошибки
- Менять все пароли в первый день. Это может остановить службы и интеграции, о которых еще никто не знает.
- Принимать документацию без проверки. Старые схемы и списки доступов нужно подтверждать фактическим состоянием.
- Сразу начинать модернизацию. Сначала нужен управляемый исходный контур и возможность отката.
- Оставлять заявки в мессенджерах и личных чатах. Без единого канала теряются история, приоритет и ответственность.
- Считать backup исправным без восстановления. Проверяется результат, а не факт запуска задания.
Итог: безопасная передача — это не разовая передача паролей. Это короткий управляемый проект, после которого известны состав инфраструктуры, владельцы, риски, порядок обращений и следующие технические действия.