Аудит перед миграцией в облако: что проверить до переезда

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

Миграция без аудита — это переезд квартиры ночью без описи вещей. Что то обязательно потеряется по дороге, а найдут уже когда не откроется касса или отчётность.

Почему «просто перенести VM» не срабатывает

Первый провал: подняли копии машин в облаке, а приложению не хватает локальных путей, железных ключей защиты или «белого» IP, который был прописан у контрагентов. Технически ВМ живы, бизнесу — простой.

Второй: забыли про лицензии. СУБД, панели, отраслевое ПО, клиентские CAL. В старом ДЦ «как-то крутилось», в облаке всплывает несоответствие условиям вендора или внезапный счёт.

Третий: персональные данные и контуры. Переезд без карты потоков данных приводит к спору уже после переключения: где хранится ПДн, какие журналы куда пишутся, кто имеет доступ из админок облака. Исправлять это под давлением срока — самый дорогой вид аудита.

Что чаще всего пропускают

Скрытые зависимости: DNS внутри сети, файловые шары, очереди, «временные» скрипты на соседнем хосте, VPN-туннели контрагентов.

Реальные время восстановления и допустимая потеря данных. На слайде «час простоя», на практике бэкап восстанавливается сутки, а облачный снимок не покрывает прикладную согласованность.

Стоимость после переезда. Считают только CPU/RAM, забывают трафик, диски IOPS, NAT, резервные копии, простой простоя во время окна миграции.

Как выглядит полезный аудит

Цель аудита-—-не толстый том-«для галочки», а список решений: что переносить-as-is, что пересобирать, что выводить из эксплуатации, что пилотировать отдельно.

Сначала инвентаризация: серверы, роли, версии ОС и ПО, владельцы со стороны бизнеса, каналы доступа. Потом связи: кто с кем говорит по каким портам и протоколам, где хранятся секреты, куда уходят-бэкапы.

Отдельно-—-данные. Классификация: что можно в публичное облако, что только в закрытый контур, что вообще лучше не трогать до отдельного проекта. Для ПДн фиксируют правовые и организационные требования до выбора схемы сети, а не после.

Лицензии и интеграции сводят в одну таблицу с пометкой-«блокирует переезд-/-требует замены-/-ок». Это экономит недели сюрпризов на финише.

В конце аудита появляется-cutover-черновик: порядок переключения, критерии готовности, план-rollbackа, кто дежурит, как проверяют платежи, почту, обмен с-1С, сайт. Без этого-«день Х» превращается в импровизацию.

Пилот вместо большого взрыва

Даже хороший аудит не заменяет пилот. Берут один сервис с понятной ценностью и низким радиусом поражения-—-внутренний портал,-staging, некритичный сайт. На нём проверяют сеть, мониторинг,-бэкапы, доступы команды.

Опытный подход к-миграции и сопутствующим сервисам обычно строится так: сначала ясность, потом пилот, потом волнами остальное. Попытка утащить всё за один-weekend-почти всегда заканчивается-rollbackом или полуживым гибридом без документации.

Что должно лежать в отчёте аудита

Хороший аудит читается не только сисадмином. В нём есть блок для бизнеса: какие сервисы критичны, какой простой недопустим, какие данные чувствительны, какие лицензии блокируют переезд. И блок для инженеров: схема связей, список хостов, зависимости, черновик волн миграции.

Отдельно фиксируют «не переносим as-is»: старые ОС без поддержки, сервисы зомби, дублирующие системы. Миграция — удобный момент выключить хлам, а не аккуратно перевезти его в более дорогой контур.

По деньгам считают три слоя: инфраструктура после переезда, стоимость самого проекта миграции, стоимость риска (простой, откат, доработки интеграций). Если в презентации только «VM в облаке дешевле стойки», цифры почти наверняка неполные.

После аудита должен появиться go/no-go не к «облаку вообще», а к конкретной схеме: какие волны, какой пилот, какой критерий успеха пилота. Без этого аудит становится толстой справкой, которую положили на полку.

Итог

Страх миграции обычно рационален: внутри контура действительно много неизвестного. Аудит превращает неизвестное в список задач. Когда список есть, переезд можно планировать, бюджетировать и защищать перед собственником.

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

Зачем это бизнесу, а не только IT

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

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

На этапе аудита полезно отдельно пройтись по «тёмным» интеграциям: обмен с банками, ЭДО, телефония, партнёрские API с белыми списками IP. Именно они чаще всего всплывают в ночь переезда. Занесите их в волну миграции явно — с контактами второй стороны и сроком на смену ACL.

Ещё один артефакт — матрица ролей после переезда: кто создаёт ресурсы, кто видит биллинг, кто имеет право на break-glass доступ. Если это не проговорить, облако унаследует ту же модель «у всех админка», только в новой панели.

После аудита назначьте владельца каждой волны переезда со стороны бизнеса, не только IT. Иначе переключение снова превратится в ночной квест инженеров без права остановить продажи.

Проверьте отдельно каналы уведомлений клиентам и партнёрам на время окна: что писать, если сервис недоступен 30 минут. Коммуникация дешевле паники в мессенджерах.

И сохраните материалы аудита как живой документ: после пилота обновите риски и оценки. Аудит, который не пересматривают, быстро устаревает.