IT-CG IT-CG

Практики

IT-аудит перед сменой подрядчика: что проверить, пока ещё не поздно

Материал подготовлен с участием ИИ, проверен редакцией.

Смена ИТ-подрядчика редко начинается с красивой презентации. Обычно начинается с усталости: «не дозваниваемся», «каждый раз новый человек», «счёт за то, что уже должно входить в абонентку», «пароли знает один специалист, и он в отпуске». Решение «давайте сменим» принимается быстро. А вот передача дел — медленно и нервно, если заранее не зафиксировать, что вообще передавать.

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

Ниже — практичный порядок, которым пользуемся, когда клиента зовут «на новое сопровождение», а старый контур ещё жив.

Зачем аудит именно до расторжения

Пока действует договор со старым подрядчиком, у вас обычно есть легитимный канал: заявки, удалённый доступ, человек, который знает «где кнопка». После расторжения канал может оборваться в один день — и вместе с ним пропадут VPN-профили, облачные кабинеты «на личной почте инженера» и понимание, почему сервер перезагружается по ночам.

Аудит до смены позволяет:

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

Если отношения уже испорчены и доступа почти нет — аудит всё равно возможен, но дороже и дольше: придётся восстанавливать картину по кускам.

Схема передачи ИТ-контура: инвентарь, доступы, бэкапы

Что смотреть в первую очередь (чеклист владельца)

Не нужно с первого дня разбирать каждую строку firewall. Нужно закрыть то, без чего бизнес встаёт.

1. Доступы и «кто хозяин»

Список критичных кабинетов: домен и DNS, хостинг сайта, почта, облако бэкапов, телефония, кабинет эквайринга/онлайн-кассы, учётная система, VPN и RDP. Для каждого — на чей логин заведено, есть ли второй администратор у вас, не висит ли всё на личной почте подрядчика.

Отдельно — локальные админские учётки на серверах и рабочих станциях бухгалтерии. Если единственный пароль «у того парня» — это уже риск смены, даже если «всё работает».

2. Серверы и учёт

Где крутится 1С или другая учётная система, где база, какие диски, какой запас места, когда последний раз обновляли ОС и СУБД. Не «красивый отчёт», а ответ на вопрос: если сервер умрёт в субботу, откуда и за сколько часов поднимаем.

Сюда же — резервное копирование: расписание, куда пишется, сколько копий, была ли хоть одна проверочная восстановка. «Бэкап настроен» без даты последней успешной копии — почти то же, что «бэкапа нет».

3. Сеть и контур объекта

Интернет-канал, маршрутизатор, Wi‑Fi (особенно гостевой), VPN для удалённой поддержки, камеры и СКУД, если они завязаны на ту же сеть. Для объектов с посетителями полезно свериться с логикой сегментации Wi‑Fi — даже если у вас не фитнес, принцип тот же: гости и касса не должны жить в одной «удобной» сети.

4. Документы и «серые» договорённости

Договор, приложения с составом работ, SLA по реакции, список разовых проектов «вне абонентки». Часто болит не техника, а ожидания: клиент думал, что мониторинг входит, подрядчик — что это отдельная услуга. Аудит фиксирует расхождение до того, как новый исполнитель получит те же претензии.

Как выглядит нормальная передача дел

Хороший сценарий занимает не «час созвона», а серию коротких сессий:

  1. Инвентаризация и доступы (вы + старый подрядчик + наблюдатель с вашей стороны).
  2. Экспорт паролей в ваш менеджер (или согласованный сейф), смена критичных паролей после передачи.
  3. Проверка бэкапа на тестовом восстановлении хотя бы одной ключевой системы.
  4. Короткий runbook: куда звонить при падении сайта, кассы, 1С, интернета.
  5. Параллельная работа старого и нового контура на переходный период (неделя–две), если объекты живые.

Новый подрядчик в этот момент не «перехватывает власть», а принимает понятный пакет. Вам проще сравнивать предложения: вы покупаете сопровождение известного контура, а не кот в мешке.

Чего не стоит ждать от аудита

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

Также не путайте аудит с «поиском виноватых». Цель — Continuity: чтобы в понедельник открылась смена, а не судебная переписка про логины.

Практичный следующий шаг

Если смена уже назрела, начните с простого списка: десять систем, без которых не работает день, и напротив каждой — логин, бэкап, ответственный. Этот список можно принести на консультацию: мы скажем, чего не хватает для безопасной передачи и нужен ли полноценный IT-аудит или достаточно помочь с онбордингом на сопровождение.

Смена подрядчика — нормальный этап. Хаос при передаче — нет. Разница обычно в том, сделали ли вы снимок контура пока двери ещё открыты.

Поделиться: VK Telegram WhatsApp