Главная СтатьиАудит ИТ-инфраструктуры

Аудит ИТ-инфраструктуры

Аудит ИТ-инфраструктуры: что проверить в серверах, облаке и отказоустойчивости

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

Обновлено 13 июня 2026 г.10 минут

Когда нужен аудит инфраструктуры

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

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

работа инфраструктуры зависит от одного инженера или устных договорённостей;

простои повторяются, но их причины не устраняются системно;

нет актуальной схемы сервисов, серверов, облачных ресурсов и зависимостей;

резервное копирование настроено, но восстановление давно не проверяли;

мониторинг есть, но команда всё равно узнаёт о проблемах от пользователей.

1. Серверная и облачная инфраструктура

Сначала собираем inventory: какие серверы, виртуальные машины, managed services, сети, DNS, storage и внешние зависимости участвуют в production. Без этого нельзя честно оценить отказоустойчивость и план восстановления.

В облаке отдельно смотрим IAM, service accounts, security groups, backup policies, labels, владельцев ресурсов и стоимость. В серверной инфраструктуре — роли узлов, обновления, capacity, диски, сеть и единые точки отказа.

актуальная карта серверов, облачных ресурсов, сервисов и владельцев;

single points of failure: DNS, ingress, БД, storage, очереди, NAT, один node или один канал;

capacity: CPU, RAM, disk, network, лимиты облака и запас под пики;

обновления ОС, runtime, managed services, Kubernetes/add-ons и критичных компонентов;

ownership ресурсов: кто отвечает, где документация, как проходит изменение.

2. Отказоустойчивость, резервное копирование и восстановление

Отказоустойчивость нельзя оценивать по наличию replica или backup job. Нужно проверить, что будет при отказе node, базы, storage, ingress, DNS или внешнего провайдера, и сколько времени займёт восстановление.

Резервная копия без проверенного восстановления — это надежда, а не план. В аудите фиксируем RPO/RTO, расписание, retention, место хранения, права доступа к копиям и дату последней успешной проверки восстановления.

какие сервисы критичны и какой допустимый downtime для каждого;

есть ли сценарии отказа для базы, storage, сети, Kubernetes nodes, DNS и внешних API;

проверялись ли backup/restore и сколько заняло восстановление;

не лежат ли backup в той же зоне риска, что и production;

есть ли runbook для восстановления и кто принимает решение о переключении.

3. Мониторинг, оповещения и разбор инцидентов

Мониторинг должен помогать команде понять причину деградации. Если Prometheus, Grafana, Zabbix или другой стек только показывает графики и не подсказывает первое действие, такой мониторинг плохо помогает production.

Проверяем покрытие критичных сервисов, качество алертов, маршруты Alertmanager или другой системы уведомлений, ответственных за сигналы, runbook и связь с postmortem.

покрыты ли метриками критичные сервисы, базы, очереди, ingress, storage, DNS и внешние зависимости;

разделены ли critical/warning/info, нет ли дублей и алертов без действия;

понятно ли, кто реагирует на каждый важный сигнал;

есть ли dashboards для инцидента, а не только красивые обзорные панели;

закрываются ли повторяющиеся причины или команда каждый раз разбирает одни и те же симптомы.

4. Доступы, ключи и безопасность изменений

Инфраструктурный аудит не заменяет полноценный security audit, но базовые риски доступов проверять нужно. Постоянные admin/root/cluster-admin права, старые service accounts и секреты в CI/CD часто создают проблемы, которые дорого исправлять после инцидента.

Смотрим, как выдаются и отзываются доступы, где лежат secrets, кто может менять production, как устроен offboarding и есть ли аудит действий в облаке, GitLab, Kubernetes и CI/CD.

кто имеет admin/root/cluster-admin и почему доступ постоянный;

как хранятся secrets, CI/CD variables, kubeconfig, cloud keys и registry credentials;

есть ли service accounts с лишними правами и без владельца;

как проходит offboarding сотрудников и подрядчиков;

можно ли понять, кто изменил production и по какому согласованию.

5. CI/CD, инфраструктура как код и ручные изменения

Релизы и инфраструктура связаны напрямую. Если deploy запускается вручную, Terraform не вызывает доверия, а часть ресурсов меняется через консоль, реальное состояние быстро расходится с документацией и репозиториями.

В аудите проверяем, где изменения проходят через review, что описано в Terraform/GitOps, где накопился drift, как устроен откат и какие операции всё ещё держатся на памяти одного инженера.

есть ли единый путь изменения от pull request до production;

что описано через Terraform/IaC/GitOps, а что меняется вручную без истории;

проверяется ли terraform plan, drift и blast radius изменений;

есть ли approvals, protected environments и post-release checks;

описан ли rollback для релиза и инфраструктурного изменения.

Что должно быть на выходе аудита

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

Удобный формат — P0/P1/P2. P0 закрывает риск простоя или потери данных, P1 снижает повторяемость инцидентов, P2 улучшает стоимость и порядок без срочного давления.

executive summary: что реально угрожает бизнесу и почему;

технический список работ по серверам, облаку, Kubernetes, резервному копированию, мониторингу, доступам и CI/CD;

быстрые исправления на 7–14 дней;

план 30/60/90 по отказоустойчивости, наблюдаемости и управляемости изменений;

список работ, которые требуют окна изменений или отдельного проекта.

FAQ

Чем аудит ИТ-инфраструктуры отличается от DevOps-аудита?

Аудит ИТ-инфраструктуры шире смотрит серверы, облако, сеть, резервное копирование, мониторинг, доступы и отказоустойчивость. DevOps-аудит глубже разбирает релизы, CI/CD, IaC, зоны ответственности и процесс изменений. На практике эти проверки часто пересекаются.

Можно ли провести аудит без доступа на изменение?

Да. Для первичной проверки достаточно read-only доступов, inventory, схем, выгрузок конфигураций, мониторинга и интервью с командой. Изменения в production идут отдельным этапом после согласования.

Что проверять в отказоустойчивости инфраструктуры?

Единые точки отказа, capacity, backup/restore, RPO/RTO, DNS, storage, базы, сеть, Kubernetes nodes, ingress, внешние зависимости и runbook восстановления. Важно не наличие резервирования само по себе, а проверенный сценарий восстановления.

Сколько времени занимает аудит инфраструктуры?

Для первичного production-аудита обычно 7–10 дней: сбор фактов, интервью, read-only анализ конфигураций, мониторинга, backup, CI/CD и подготовка карты рисков 30/60/90.