Как провести ИТ-аудит инфраструктуры компании перед модернизацией: оборудование, сети, ПО и информационные риски

08 Окт 2026 Опубликовано в Полезные советы | Просмотров: 1

(Еще нет голосов)

Загрузка...

Модернизация ИТ-инфраструктуры редко проваливается из-за неправильной модели сервера или недостаточной пропускной способности канала. Гораздо чаще компания начинает закупки, не понимая, что именно у неё уже есть, какие системы критичны для бизнеса и где скрываются зависимости. В результате появляются дублирующие сервисы, неиспользуемые лицензии, перегруженные коммутаторы и резервные копии, которые невозможно восстановить.

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

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

Для независимой технической оценки и подготовки плана модернизации полезно привлекать профильного подрядчика, например компанию https://iiii-tech.com, особенно если внутри компании нет специалиста, который одновременно понимает архитектуру, безопасность, лицензирование и экономику ИТ.

Как провести ИТ-аудит инфраструктуры компании перед модернизацией: оборудование, сети, ПО и информационные риски

С чего начинать: границы и цели аудита

До сбора технических данных необходимо определить объём обследования. В него могут входить офисы, дата-центр, облачные сервисы, удалённые рабочие места, телефония, системы видеонаблюдения, производственное оборудование и интеграции с внешними платформами. Если заранее не обозначить границы, аудит превратится в бесконечную инвентаризацию, а его результаты будет сложно связать с бизнес-задачами.

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

Критически важно: зафиксируйте критерии успеха до начала обследования. Например: восстановление ключевой системы не дольше четырёх часов, отсутствие единственной точки отказа на периметре, инвентаризация не менее 98% активов и подтверждённая актуальность резервных копий.

Инвентаризация оборудования: проверять нужно не только наличие

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

Одной инвентарной карточки недостаточно. Следует сопоставить оборудование с фактическими метриками: загрузкой процессора, потреблением оперативной памяти, заполнением дисков, IOPS, температурой, состоянием RAID, ошибками интерфейсов и временем работы без перезагрузки. Сервер с 25% средней загрузки CPU может быть узким местом из-за медленных дисков. А устройство хранения с большим свободным объёмом способно иметь критический износ SSD или деградировавший RAID.

Объект	Что проверять	Типичные признаки проблемы	Результат для проекта
Серверы и виртуальные хосты	CPU, RAM, диски, резервирование, прошивки	Нехватка ресурсов, устаревший гипервизор, единичный хост	Расширение кластера или замена платформы
Системы хранения	Ёмкость, IOPS, задержки, RAID, репликация	Рост latency, заполнение выше 80%, нет второго экземпляра данных	Модернизация СХД и резервного копирования
Сетевое оборудование	Порты, uplink, VLAN, PoE, версии ПО	Перегруженные uplink, неуправляемые коммутаторы, общий сегмент	Перестройка топологии и сегментация
ИБП и инженерные системы	Нагрузка, батареи, автономность, обслуживание	Снижение ёмкости АКБ, отсутствие тестов, один ввод питания	Обновление электропитания и регламентов

Аудит сети: схема должна подтверждаться измерениями

Сетевая документация нередко расходится с реальностью. На схеме может быть один VLAN для серверов, рабочих станций и телефонии, хотя фактически используются десятки исключений. Поэтому топологию нужно восстанавливать по данным коммутаторов, маршрутизаторов, DHCP, DNS, систем мониторинга и контроллеров Wi‑Fi.

Проверяются адресные планы, маршрутизация, правила межсетевого экрана, резервные каналы, точки выхода в интернет и удалённый доступ. Отдельное внимание стоит уделить широковещательным доменам, транкам между коммутаторами и пропускной способности uplink-портов. Если доступ к нескольким этажам проходит через один канал 1 Гбит/с, его загрузку нужно оценивать в часы пиковых операций, а не поздним вечером.

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

Программное обеспечение и зависимости

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

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

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

Информационные риски и отказоустойчивость

Риск оценивается не по количеству установленных антивирусов, а по возможному ущербу и вероятности события. В рамках аудита проверяются учётные записи, привилегии, многофакторная аутентификация, удалённый доступ, журналы событий, сегментация, защита резервных копий и процедура реагирования на инциденты.

Особое место занимает резервное копирование. Наличие задания в консоли не означает наличие резервной копии, пригодной для восстановления. Нужно выполнить тестовый restore хотя бы для нескольких критичных объектов: базы данных, файлового ресурса, виртуальной машины и конфигурации сетевого устройства. Для каждой системы фиксируются RPO — допустимая потеря данных, и RTO — допустимое время восстановления. Эти показатели задаются бизнесом, а не выбираются «по умолчанию» ИТ-отделом.

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

Практический порядок проведения аудита

Согласовать цели и границы. Определить площадки, системы, ответственных, сроки и формат итогового отчёта.
Собрать исходные документы. Запросить схемы, договоры, лицензии, регламенты, перечни оборудования и отчёты мониторинга.
Провести автоматизированный сбор данных. Использовать системы управления конфигурациями, SNMP, сканирование активов и средства анализа виртуальной среды с соблюдением правил безопасности.
Проверить инфраструктуру вручную. Осмотреть серверные, маркировку кабелей, стойки, электропитание, точки доступа и фактическое подключение оборудования.
Сопоставить данные. Найти расхождения между документами, настройками и фактической эксплуатацией.
Оценить риски и зависимости. Для каждого замечания определить вероятность, ущерб, владельца и срок устранения.
Сформировать целевую архитектуру и дорожную карту. Разделить работы на быстрые исправления, проекты средней сложности и долгосрочные изменения.

Каким должен быть итоговый отчёт

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

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

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

Памятка перед утверждением проекта

Перед запуском модернизации стоит убедиться, что для каждой критичной системы назначен владелец, описаны зависимости и определены RPO/RTO. В реестре не должно оставаться активов без статуса: «неизвестный» сервер или «временная» учётная запись имеют свойство оставаться в инфраструктуре годами. Все рекомендации необходимо проверить на совместимость с текущими лицензиями, кадровыми ресурсами и требованиями регуляторов.

Наконец, проект следует строить поэтапно. Сначала устраняются опасные единичные точки отказа, закрываются очевидные уязвимости и приводятся в порядок резервные копии. Затем выполняются изменения сети, серверной платформы и систем хранения. После каждого этапа нужны измерения: доступность, задержки, скорость восстановления и фактическое снижение рисков.

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

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