Аудит инфраструктуры: риски и план действий

Что обследуем

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

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

Стоимость и границы

79 000 ₽ · разовый аудит

Пять рабочих дней после получения необходимых доступов и согласований. В результате — письменный отчёт и встреча с командой. Изменения production, обследование Kubernetes, пентест и нагрузочные испытания не входят в этот объём.

Если серверов или продуктов больше, сначала уточняем контур и согласуем смету. Исправление найденных проблем — отдельная работа, а не скрытое продолжение аудита.

Как проходит работа

1. Фиксируем контур. Перечень VM и окружений, критичные сценарии, известные проблемы и контакт ответственного.
2. Собираем свидетельства. Схемы, конфигурации, история релизов, настройки мониторинга и backup. Доступы — после согласования, с минимальными правами.
3. Разбираем риски. Что наблюдаем, чем это грозит продукту, насколько вывод подтверждён и какие действия нужны.
4. Передаём результат. Обсуждаем приоритеты и зависимости, чтобы команда могла оценить и принять задачи в работу.

Как выглядит запись в отчёте

Ниже пример структуры, а не кейс клиента или утверждение о вашей системе.

Наблюдение

В истории релизов нет зафиксированной версии для возврата.

Риск

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

Проверка

Сопоставить журнал выпуска, реестр образов и инструкцию отката; отдельно отметить недоступные источники.

Действие и приёмка

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

Приоритет

Определить вместе с владельцем продукта по влиянию и вероятности; назначить ответственного и срок.

Такой отчёт можно использовать как исходный backlog для сопровождения или отдельной настройки CI/CD.

Что подготовить к знакомству

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