Запас прочности ИТ-инфраструктуры: как оценить, на сколько её хватит

Прогнозируя рост числа сотрудников ИТ-директор или системный администратор может задать вопрос: а выдержит ли вообще этот рост наша инфраструктура? Часто получается похожий ответ: сейчас процессоры загружены на 60 процентов, значит, запаса ещё прилично. Ответ звучит убедительно и при этом неверен. Нагрузка и время отклика связаны нелинейно: при утилизации 60% система уже работает в два с половиной раза медленнее своего теоретического предела, а при 90% — в десять раз. То есть, например, полтора раза роста от 60% дадут пользователям не «чуть медленнее», а примерно вчетверо худшее время ответа.

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

Почему «загрузка 60 процентов» — не ответ

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

Реальные системы сложнее одной очереди, и точные множители у вас будут другими. Важна форма кривой: до 50–60% рост утилизации почти не чувствуется, после 80% каждый процент стоит дорого, после 90% система переходит в режим, где небольшой всплеск нагрузки выглядит как авария.

Отсюда же следует практический вывод про рост в полтора раза. Если ресурс загружен на 40%, после роста он выйдет на 60%, и время отклика ухудшится примерно в полтора раза — терпимо. Если он загружен на 60%, после роста будет 90%, и это уже учетверение времени отклика. Разница между «загружено на 40» и «загружено на 60» в спокойном состоянии незаметна, а под ростом она определяет всё.

Вендоры это знают и закладывают в свои рекомендации. Microsoft в руководстве по планированию ёмкости контроллеров домена прямо называет целевую загрузку процессора 40% в рабочие часы при схеме с резервным узлом и 60% при работе без резерва, а 80% допускает только вне рабочих часов. Там же оговорка, которая подтверждает логику: некоторые среды живут и на 80–90% процессора, если время ожидания в очереди при этом заметно не растёт.

Из чего складывается запас прочности

Запас прочности — не одно число, а три разные величины, и путать их дорого.

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

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

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

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

Что мерить и какие пороги брать

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

Как снимать замер

До разговора о порогах нужно договориться о способе измерения, иначе спор пойдёт о цифрах, а не о выводах.

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

Берётся 95-й процентиль за рабочие часы, а не среднее за сутки. Среднее по месяцу размазывает пик по ночам и выходным и систематически показывает запас, которого нет.

Каждый замер проверяется в сценарии отказа. Если из двух узлов кластера останется один, его утилизация не просто удвоится: он уйдёт в ту часть кривой, где время отклика растёт в разы. Поэтому пороги задаются от режима N+1, а не от нормального режима.

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

Процессор

Смотреть нужно не среднюю загрузку, а загрузку в часы пик и время ожидания задачи в очереди к процессору. В виртуальной среде показательнее всего CPU Ready Time: он показывает, сколько времени виртуальная машина готова считать, но не получает такта. Заметная величина этого показателя означает, что хост перепродан, даже если суммарная загрузка выглядит умеренной.

Целевой ориентир для сред, где важно время отклика: 40–60% в пике при наличии резервного узла. При работе без резерва порог выше, но тогда отказ любого узла автоматически выводит систему за предел.

Память

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

Отдельно проверяется перепродажа памяти на гипервизоре. Для баз данных и систем с собственным кэшем перепродажа памяти недопустима: Microsoft в том же руководстве требует избегать overcommit на хосте.

Дисковая подсистема

Главная метрика здесь не IOPS, а задержка. IOPS показывает, сколько операций система делает, а задержка — сколько ждёт каждая из них, и именно её чувствует пользователь. Microsoft приводит целевое значение средней задержки чтения 10 мс и тревожное 15 мс, а в качестве ориентиров по носителям: SSD 1–3 мс, диски 15 000 об/мин 4–6 мс, 10 000 об/мин 6–10 мс, 7 200 об/мин 9–12,5 мс.

Если на массиве из SSD вы видите задержки в десятки миллисекунд, проблема не в дисках, а в контроллерах, кэше или в том, что массив перегружен.

Сеть и каналы связи

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

Для внешних каналов Microsoft рекомендует целевую утилизацию 40% и предупредительную 60%, а при планировании закладывать не меньше 50% прироста трафика. Отдельно считается сценарий отказа: если в нормальном режиме два канала загружены по 45%, то при падении одного второй уйдёт в 90%.

Ёмкость хранения и окно резервного копирования

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

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

Что упирается раньше процессора

Самое неприятное в оценке запаса прочности то, что первым обычно заканчивается не вычислительная мощность, а что-то, чего нет на дашборде мониторинга. Типичные кандидаты:

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

Проверять их приходится вручную, потому что в системах мониторинга этих величин по умолчанию нет. Зато именно они чаще всего и определяют реальный ответ на вопрос «на сколько нас хватит».

«На аудитах мы почти всегда находим узкое место не там, где его ждал ИТ-отдел. Процессоры и диски видны в мониторинге, поэтому за ними следят. А выделенная на стойку мощность, свободные порты и условия лицензии на количество ядер нигде не нарисованы, и выясняется это в момент, когда оборудование уже куплено», — Станислав Гуляев, ведущий технический эксперт ОБИТ.

Как перевести рост компании в рост нагрузки

Ошибка, которую мы видим чаще всего: рост умножают на число сотрудников. Полтора раза по людям почти никогда не означает полтора раза по каждому ресурсу.

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

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

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

Из этого же соображения устроен и расчёт в руководстве Microsoft: при прогнозе роста спроса на 50% за три года расчётное количество процессоров умножается на полтора, но предварительно замеряется фактическая потребность, а не берётся из числа пользователей.

Сколько времени занимает расширение

Эту часть расчёта пропускают почти всегда, а она определяет, есть у вас запас или нет.

Поставка по российскому рынку сейчас не самое узкое место: по словам представителя ICL Техно в отраслевом обзоре IT Channel News за август 2026 года, сроки отгрузки типовых конфигураций стабилизировались на уровне 2–6 недель. Нетиповые конфигурации, сложные чипы и высокопроизводительные массивы идут дольше.

Зато ощутимо изменились цены. В том же обзоре представители Treolan и «Инферит Техники» говорят о дефиците DDR и NAND на мировом рынке из-за спроса на память для ИИ: оперативная память подорожала кратно, а full flash массивы, по оценке Treolan, почти на порядок. Это значит, что отложенное на полгода расширение может подорожать само по себе, и бюджет, посчитанный весной, к осени уже не сходится.

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

Отсюда рабочее правило: если по какому-то ресурсу время до упора меньше полугода, расширение нужно закладывать в бюджет текущего периода, а не следующего.

«Самый частый разговор звучит так: мы посчитали, что мощности хватит до середины года, значит, заложим в бюджет следующего. А дальше считаешь вместе с заказчиком срок согласования, поставки и миграции и получаешь, что заказывать надо было в прошлом квартале. Поэтому мы в отчёте всегда пишем не только месяц упора, но и крайнюю дату, когда ещё можно начинать», — Станислав Гуляев, ведущий технический эксперт ОБИТ.

Как проверить это у себя

Прямой ответ на вопрос о росте в полтора-два раза звучит так: выдержит, если по каждому ресурсу утилизация в пике сейчас не выше 40–50% с учётом отказа одного узла, если данные, логи и резервные копии имеют запас по месту на весь период роста, если окно резервного копирования остаётся в норме при увеличенном объёме и если по лицензиям, адресации, портам и электропитанию есть физическая возможность расширяться. Если хотя бы один из пунктов не выполняется, узкое место найдено, и дальше вопрос только в том, сколько месяцев до него осталось.

Начинать стоит с данных мониторинга за последние 6–12 месяцев: без истории тренд не построить, а без тренда любая оценка запаса превращается в мнение. Если мониторинг охватывает не всё или данных за прошлый год нет, первый шаг — не расчёт, а инвентаризация и настройка наблюдения.

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