# Аудит инфраструктуры и планирование ёмкости

С этого обычно начинается работа. Аудит — законченная услуга сама по себе: отчётом можно пользоваться и без продолжения сотрудничества, в том числе чтобы поставить задачу другому подрядчику.

## Что смотрим

- **Опись.** Что вообще есть: серверы, виртуальные машины, кластеры, базы, службы, домены, сертификаты, доступы. На этом шаге обычно находятся системы, о которых все забыли.
- **Версии и поддержка.** Что снято с поддержки и больше не получает исправлений безопасности — ОС, Kubernetes, container runtime, СУБД.
- **Запас прочности.** Что произойдёт при отказе одного узла: переживёт ли нагрузка, переедут ли службы, есть ли куда.
- **Резервные копии.** Есть ли они, проверялись ли восстановлением, за какое время поднимется система.
- **Безопасность.** Где лежат пароли, кто имеет доступ, что открыто наружу, как выдаются и отзываются права.
- **Соответствие описанного реальному.** Совпадает ли то, что в репозиториях и схемах, с тем, что действительно развёрнуто.

## Планирование ёмкости

Отдельная часть, которая отвечает на вопрос «когда это упрётся»:

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

## Что на выходе

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

Дальше решение принимает бизнес — но уже зная, за что платит и чем рискует.

Как это выглядело на практике — в кейсах [«Что находится при приёме чужой инфраструктуры»](/cases/infrastructure-audit) и [«Кластер виртуализации упёрся в память»](/cases/capacity-planning).