Запас производительности сервера нельзя надежно планировать по одной цифре средней загрузки. Сервер может показывать 25 процентов CPU за сутки и при этом регулярно тормозить в конце месяца, во время резервного копирования или при массовой работе пользователей.
Годовое планирование емкости отвечает на простой управленческий вопрос: хватит ли текущей инфраструктуры на следующие 12 месяцев с учетом роста, пиков, обслуживания и допустимого риска. Ответ должен быть не "сервер нормальный", а "ресурс достаточен до такого-то условия, дальше нужен такой-то шаг".
Сначала нужна базовая линия
Базовая линия - это не разовый снимок диспетчера задач. Нужна история нагрузки за типичный период: рабочие дни, выходные, закрытие месяца, резервное копирование, обновления, массовые операции пользователей. Для небольших компаний обычно достаточно нескольких недель наблюдений, если в них попали регулярные пики.
Смотреть нужно не только CPU. Часто первым ограничением становится память, очередь диска, задержки на хранилище, сетевой интерфейс, размер базы, место под журналы или окно backup. Если измеряется только один ресурс, план емкости будет давать ложную уверенность.
| Ресурс | Что смотреть | Почему среднее значение опасно |
|---|---|---|
| CPU | пики, готовность виртуальных CPU, длительность высокой загрузки | короткие пики могут совпадать с ключевыми операциями |
| Память | рабочий набор, swapping, давление на кеш | средняя загрузка не показывает вытеснение данных |
| Диски | latency, очередь, IOPS, свободное место | диск может быть заполнен только на 60 процентов, но уже не выдерживать задержки |
| Сеть | утилизация, ошибки, пики backup и репликации | узкое место проявляется в определенные окна |
| Данные | рост баз, файлов, логов, архивов | свободное место заканчивается ступенчато после новых процессов |
Пики важнее средней загрузки
Для пользовательского сервиса важна не средняя температура за сутки, а периоды, когда бизнес ждет ответа системы. Если бухгалтерия закрывает месяц, склад делает выгрузку, а backup забирает дисковую производительность, среднее значение за день может выглядеть спокойно, но пользователи увидят задержки.
Пики нужно описывать словами: что происходит, кто затронут, сколько длится, можно ли перенести нагрузку, какие сервисы конкурируют за один ресурс. Иногда проблема решается расписанием задач, иногда разделением ролей, а иногда без дополнительного ресурса не обойтись.
Рост бывает разным
Рост пользователей не всегда главный фактор. Сервер может обслуживать то же количество людей, но нагрузка растет из-за увеличения базы, новых отчетов, сканов, вложений, журналирования, камер, интеграций или требований к хранению истории. Поэтому план на 12 месяцев должен учитывать не только штат, но и рост данных и процессов.
Практично разделять рост на три группы: предсказуемый, событийный и скрытый. Предсказуемый - новые сотрудники, филиалы, объем документов. Событийный - миграция, внедрение нового сервиса, сезонная нагрузка. Скрытый - накопление логов, временных файлов, старых архивов и данных, которые никто не удаляет.
Запас нужен не только для скорости
Часть ресурса нужна для обслуживания: обновлений, миграции, тестового восстановления, проверки backup, временного параллельного запуска старого и нового контура. Если сервер работает на пределе в обычный день, любые плановые работы становятся аварийным риском.
Отдельно считается запас на отказ. Если виртуализация или кластер должны пережить потерю одного узла, суммарная свободная емкость должна позволять поднять критичные машины на оставшихся ресурсах. Иначе отказоустойчивость существует только в схеме, но не в реальной емкости.
Как задавать пороги решений
План емкости полезен, когда заранее определяет действия. Например: при устойчивом росте дисковой задержки сначала переносим backup-окно, затем разделяем хранилище, а при достижении согласованного порога готовим закупку или миграцию. Без порогов обсуждение начинается только после жалоб пользователей.
Пороги не должны быть одинаковыми для всех серверов. Для файлового архива допустим один профиль, для базы с рабочими транзакциями - другой, для контроллера домена - третий. Важно связать техническую метрику с бизнес-последствием: кто пострадает, сколько времени можно терпеть, какой запас нужен для восстановления.
Что должно быть в годовом capacity-плане
Хороший план на 12 месяцев помещается в понятный документ. В нем есть текущая базовая линия, ожидаемый рост, известные пики, первое вероятное узкое место, варианты действий, бюджетный горизонт и дата пересмотра. Такой документ не заменяет мониторинг, но переводит графики в управленческие решения.
Для серверной поддержки это часть нормальной модели услуги: подрядчик или внутренняя IT-команда не просто тушит жалобы на тормоза, а ведет наблюдение, показывает тренды, предупреждает о порогах и предлагает варианты до аварии. При этом решение о бюджете и допустимом риске остается за владельцем бизнеса или сервиса.
Типичные ошибки
Первая ошибка - планировать запас только от текущей загрузки CPU. Вторая - забывать про диски и рост данных. Третья - не учитывать backup, антивирус, обновления и регламентные операции. Четвертая - считать виртуальную среду бесконечной, хотя все виртуальные машины конкурируют за одни физические ресурсы.
Пятая ошибка - откладывать решение до момента, когда уже начались жалобы. В этот момент вариантов меньше: приходится быстро покупать ресурс, переносить сервис в неудобное окно или принимать риск простоя. Годовой план нужен именно для того, чтобы выбирать заранее.