Годовой техосмотр инфраструктуры: ритуал, который режет счёт на следующий год

MAATRIX

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

Зачем это отдельный ритуал, а не текучка

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

Годовой техосмотр закрывает именно этот слепой участок. Смысл в регулярности и полноте: не «проверим, когда будет время», а фиксированная дата раз в год, когда вы проходите по всей инфраструктуре целиком, а не по кускам, которые вспомнились. Формат похож на подход из аудита сервера на выходные — там про безопасность одного сервера за два дня по плану, здесь — про экономику всей инфраструктуры компании, но принцип общий: без чек-листа половина пунктов забывается.

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

Инвентаризация: считаем всё, за что вы платите

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

Соберите инвентарь по категориям:

• Виртуальные и выделенные серверы — все аккаунты у всех провайдеров, включая тестовые окружения и серверы, оставшиеся от завершённых проектов.
• Диски и снапшоты — отдельно оплачиваемые тома, резервные копии, снапшоты, которые копятся и никогда не удаляются.
• Сетевые ресурсы — статические IP-адреса, балансировщики, VPN-шлюзы, зарезервированные, но не используемые.
• Managed-сервисы — базы данных, очереди, объектные хранилища в облаке, за которые платится отдельно от вычислительных мощностей.
• Подписки вокруг инфраструктуры — мониторинг, логирование, CDN, панели управления, сертификаты, лицензии на софт.

На хостах с гипервизором список получить быстро:

# Proxmox: все виртуалки и контейнеры на хосте
qm list
pct list

# libvirt/KVM
virsh list --all

# Docker: что реально запущено, а не просто существует
docker ps -a --format "table {{.Names}}\t{{.Status}}\t{{.CreatedAt}}"

Для облачных провайдеров то же самое делается через CLI — и тут находятся самые дорогие сюрпризы: неприкреплённые диски и «висящие» IP-адреса продолжают тарифицироваться, даже если к ним ничего не подключено.

# AWS: диски, которые не привязаны ни к одному инстансу
aws ec2 describe-volumes --filters Name=status,Values=available

# AWS: elastic IP, которые никуда не назначены
aws ec2 describe-addresses --query "Addresses[?AssociationId==null]"

# Hetzner Cloud
hcloud server list
hcloud volume list

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

ss -tn state established | wc -l
tail -n 100000 /var/log/nginx/access.log | awk '{print $1}' | sort -u | wc -l

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

Тарифные планы: сверяем с реальной нагрузкой

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

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

# Средняя и пиковая загрузка CPU
vmstat 1 10
sar -u 1 10

# Память: сколько реально используется, а не просто выделено
free -m

# Диск: заполненность и I/O-ожидание
df -h
iostat -x 1 5

Дальше — простое сопоставление: где ресурс годами используется на малую часть от лимита, а где, наоборот, система регулярно упирается в потолок и тормозит под пиковой нагрузкой.

Самое сложное здесь — не техническая часть, а решение о даунгрейде. Психологически проще оставить тариф с запасом «на всякий случай», чем один раз в год признать, что запас избыточен уже давно. Эта ловушка разобрана в статье про даунгрейд тарифа и то, почему на него не решаются — годовой техосмотр как раз тот момент, когда за год уже накопились данные и оправдания «а вдруг вырастет» больше нет.

Архитектура: что было правильным год назад — не факт что сейчас

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

Пройдитесь по крупным решениям и задайте по каждому один вопрос: если бы вы проектировали это сегодня, зная реальные цифры за год, приняли бы вы то же решение?

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

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

Консолидация и отключение: где реально экономятся деньги

Экономия от техосмотра складывается из нескольких разных механизмов, и стоит различать их, потому что у каждого свой эффект:

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

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

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

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

# Пример: найти снапшоты старше года без явного тега "keep"
aws ec2 describe-snapshots --owner-ids self \
  --query "Snapshots[?StartTime<='2025-08-01'].[SnapshotId,StartTime,Tags]"

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

План на следующий год: превращаем аудит в дорожную карту

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

Первый раздел — что сделано по итогам аудита: какие серверы отключены, какие тарифы изменены, какие архитектурные решения пересмотрены. Это не только отчёт, но и защита от повторных вопросов «а почему у нас нет того сервера» через полгода.

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

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

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

Частые вопросы