2000 виртуальных серверов: как устроена эксплуатация без героизма

Две тысячи виртуальных серверов — это размер, при котором «настроим по месту» перестаёт работать. Любая неописанная деталь превращается в героическую историю ночного восстановления. Ниже — то, что должно быть в порядке, чтобы этого не происходило.

1. Инвентарь, которому верят

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

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

2. Стандартный образ вместо снежинок

Уникально настроенный сервер — «снежинка» — красив ровно до момента, когда его нужно пересобрать. Практический стандарт: базовый образ, автоматическая установка агентов мониторинга и резервного копирования, единая политика обновлений. Всё, что отличается от стандарта, должно быть описано в коде развёртывания, а не в голове инженера.

Правило простое: любой сервер должен переживать полное пересоздание с нуля без участия того, кто его когда-то настраивал.

3. Ёмкость, посчитанная заранее

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

4. Резервные копии, которые проверяются

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

5. Мониторинг, который показывает сервис

Алерт «загрузка процессора 90%» не значит ничего. Алерт «время ответа сервиса заявок выросло втрое» значит всё. Мониторинг строится от бизнес-сервиса вниз к железу, а не наоборот. Иначе дежурная смена тонет в шуме и через месяц перестаёт реагировать.

6. Дежурство и разбор инцидентов

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

Что даёт этот порядок

• Новая машина разворачивается за минуты и сразу под мониторингом и бэкапом.
• Отпуск ключевого инженера перестаёт быть риском для компании.
• Планирование бюджета опирается на цифры, а не на ощущения.
• Инциденты становятся управляемыми: понятно, кто, что и в каком порядке делает.