# Аудит ИТ-инфраструктуры: что должен получить руководитель
Редакция SGI24. Материал основан на обследовании рабочих систем, резервного копирования и технических зависимостей бизнеса. [О бюро](/company).
Аудит ИТ-инфраструктуры часто заканчивается длинной таблицей серверов и версий программ. Техническому специалисту она полезна. Руководителю всё ещё непонятно, где бизнес может остановиться и что исправлять первым.
Нормальный результат переводит технику на язык процессов. Какая система принимает заявки? Где хранятся документы? Что произойдёт, если узел станет недоступен? Кто узнает об ошибке и сколько займёт восстановление?
Получить карту рисков инфраструктуры
Сначала определите критичные процессы
Инфраструктуру нельзя оценивать в отрыве от работы организации. Один сервер может быть старым, но не влиять на срочные операции. Другой выглядит исправным, однако на нём держатся запись клиентов, платежи и документы.
Мы начинаем с процессов и допустимого простоя. Руководитель отмечает, что должно работать постоянно, что можно восстановить к следующему дню и что допускает ручной режим.
После этого техника получает приоритет. Проверка становится короче и полезнее: внимание направлено на узлы, от которых зависят деньги, обязательства и данные.
Инвентаризация без самообмана
Нужно увидеть не только серверы. В контур входят облачные сервисы, домены, почта, CRM, 1С, медицинские и образовательные программы, телефония, рабочие компьютеры, сетевое оборудование и резервные хранилища.
Отдельно фиксируются владельцы учётных записей и договоров. Бывает, что критичный домен оформлен на бывшего подрядчика, а доступ к облаку есть у одного сотрудника. Это организационный риск, хотя оборудование работает без ошибок.
Инвентаризация отвечает на вопросы: что используется, кем управляется, где находится и от чего зависит.
Карта зависимостей
Сбой редко остаётся внутри одного сервиса. Если недоступна база, сайт продолжает принимать форму и обещает успех. Если остановилась интеграция, заявки копятся в промежуточной очереди. Если истёк сертификат, сотрудники считают, что «сломался интернет».
Поэтому строится цепочка от пользовательского действия до хранения и следующего рабочего шага. Для каждого перехода отмечается, как система узнаёт об ошибке и что делает дальше.
Такая карта обнаруживает единичные точки отказа: один канал, одна учётная запись, один сервер или один человек без замены.
Доступы и ответственность
Кроме наличия паролей проверяют административные права, закрытие доступа после увольнения, хранение второго фактора и порядок восстановления учётной записи.
Общий логин удобен до первого инцидента. Потом невозможно понять, кто изменил настройку или выгрузил данные.
Результатом становится понятная модель ролей и список критичных доступов. Не обязательно перестраивать всё сразу. Сначала закрываются учётные записи и права, которые создают наибольший риск.
Резервная копия проверяется восстановлением
Зелёная отметка задания ещё не означает, что данные можно вернуть. Копия может быть неполной, зашифрованной вместе с основной системой или зависеть от пароля, которого никто не знает.
Аудит проверяет состав копий, частоту, место хранения, защиту от изменения и историю тестового восстановления. Для каждой критичной системы задаются допустимая потеря данных и время возврата в работу.
Как устроить резервное копирование для бизнеса
Производительность и пропускная способность
Медленная система не всегда требует новый сервер. Причиной может быть запрос к базе, очередь интеграции, сетевой канал или ручной процесс, который запускается одновременно у всей команды.
Сначала измеряется, где возникает задержка. Затем сравниваются варианты: настройка, изменение архитектуры, перенос отдельной операции или расширение ресурса.
Покупать оборудование до измерения — дорогой способ оставить причину на месте.
Мониторинг должен вести к действию
Графики нагрузки полезны специалисту. Руководителю нужен ответ: что остановилось, какой процесс затронут, кто уже получил задачу и когда будет следующая информация.
Для критичных событий задаются пороги и маршрут уведомления. Сигнал не должен уходить только человеку, который может быть недоступен.
Отдельно проверяется «тихий сбой»: система формально работает, но перестала передавать документы или обновлять данные. Обычный контроль доступности такой случай не увидит.
Что входит в итог аудита
Руководитель получает не каталог замечаний, а четыре связанных результата:
- схему систем и зависимостей;
- риски с влиянием на бизнес;
- быстрые исправления и проекты следующего уровня;
- план проверки результата.
Для каждого пункта указано, почему он важен, кто отвечает и как понять, что проблема закрыта. Технические детали остаются приложением, а не главным документом.
Что делать с картой после аудита
Он не обязывает покупать модернизацию у SGI24. Карта и план остаются у заказчика. Исправления можно выполнить своей командой, текущим подрядчиком или заказать отдельными блоками.
Если требуется только резервное копирование, мониторинг или разбор производительности, границы фиксируются отдельно. Полный комплекс нужен, когда риски связаны между собой.
Чего аудит не обещает
Одно обследование не гарантирует отсутствие сбоев и атак. Оно показывает подтверждённое состояние на момент проверки, критичные зависимости и порядок снижения риска.
Проверка на соответствие отраслевым требованиям, тест на проникновение и юридическая экспертиза могут потребовать отдельных специалистов. Мы не прячем их внутри общего слова «аудит».
Как расставляются приоритеты
Не каждое замечание нужно исправлять немедленно. Мы оцениваем влияние на критичный процесс, вероятность события, сложность обнаружения и возможность восстановления. Один и тот же технический дефект получает разный приоритет в архивном сервисе и в системе, которая принимает оплату или медицинскую запись.
План делится на быстрые меры, обязательные проекты и улучшения. Быстрые меры закрывают очевидные доступы, уведомления и копии. Проекты требуют согласованного изменения архитектуры. Улучшения полезны, но не должны вытеснять критичные работы.
Для руководителя у каждого пункта есть решение: принять риск, снизить его, передать или временно остановить зависимый процесс. Технический термин без такого решения в управленческий отчёт не попадает.
Проверка после исправления
Закрыть строку в плане недостаточно. Если настроена копия, проводится восстановление. Если добавлен мониторинг, создаётся безопасное контрольное событие и проверяется маршрут сигнала. Если изменена производительность, сравнивается тот же сценарий под сопоставимой нагрузкой.
Эту проверку можно включить в отдельный этап или поручить своей команде. Критерий заранее записан в плане, поэтому заказчик не зависит от устного заверения исполнителя.
Какие материалы нужны на старте
Достаточно перечня ключевых процессов, контактов ответственных и доступов к согласованным системам в режиме, необходимом для обследования. Полная передача паролей не является нормой: применяются временные учётные записи и минимальные права.
Если документация устарела, это фиксируется как исходное состояние. Аудит как раз должен восстановить проверяемую карту, а не требовать идеального порядка до начала работы.
Получить карту рисков инфраструктуры