Сисадмин просит купить сервер помощнее: как проверить, что он прав

MAATRIX

Администратор написал: «сервер не тянет, нужно докупить ресурсы» — и назвал сумму. Вы не разбираетесь в CPU и RAM настолько, чтобы спорить по существу, но и просто кивнуть неприятно: а вдруг проще почистить логи или поправить один медленный запрос в коде. Хорошая новость: чтобы отличить обоснованный запрос от отговорки, не нужно самому читать графики нагрузки — нужно знать, какие вопросы задать и какие ответы должны насторожить. Дальше — конкретный порядок действий.

Почему сам факт запроса — ещё не аргумент ни за, ни против

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

Разница в том, что для администратора апгрейд — почти всегда самый дешёвый лично для него вариант действия. Нажать кнопку в панели управления и подождать перезагрузку — это пятнадцать минут работы. Найти медленный запрос без индекса, разобраться в утечке памяти или настроить кеширование — это часы, а иногда дни профилирования, тестирования и риска что-то сломать. Если администратор оценивается не по результату (стабильная и недорогая инфраструктура), а просто по факту «сервер работает», у него нет стимула выбирать сложный путь вместо простого — даже если сложный путь дешевле для бизнеса в целом.

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

Три метрики, которые стоит попросить показать: CPU, RAM, диск

Вам не нужно уметь администрировать Linux, чтобы понять эти три графика — достаточно знать, на что смотреть.

CPU (процессор). Просите не цифру «сейчас», а график загрузки за последние недели или месяцы. Разовый снимок через top или htop показывает состояние в момент, когда админ зашёл на сервер — это может быть случайный пик или, наоборот, спокойная минута, не отражающая типичный день. Полезный вопрос: «Покажите график средней загрузки CPU по дням за три месяца». Если такого графика нет вообще — это уже сигнал: значит, решение принимается не по данным, а по ощущению.

RAM (память). Здесь чаще всего путают — сама память устроена так, что Linux всегда старается занять свободную память под кеш файловой системы, потому что это ускоряет работу. Команда free -h в столбце used может показывать почти всю память занятой, но в столбце available — сколько реально доступно приложениям при необходимости. Если админ показывает вам только «used», а не «available», попросите объяснить разницу или прислать интерпретацию от мониторинга, а не сырую команду. Настоящая нехватка памяти проявляется не в проценте занятости, а в oom-killer (сообщения о том, что система принудительно завершала процессы из-за нехватки памяти) или в активном использовании swap — это можно спросить прямо: «Были ли за последние месяцы события oom-killer или рост использования swap?»

Диск. Здесь две разные вещи: место (сколько свободно в гигабайтах) и скорость (успевает ли диск обрабатывать операции чтения-записи). Команда df -h покажет первое, iostat -x 1 5 — второе, конкретно колонку %util (насколько диск занят операциями) и await (сколько миллисекунд ждёт операция). Заполненный на 95% диск — понятная и наглядная проблема, которую легко объяснить без цифр. Диск, который упирается в скорость при формально свободном месте, — менее очевидная ситуация, и здесь особенно важно, чтобы админ показал именно график %util, а не просто сказал «диск медленный».

Общее правило для всех трёх метрик: снимок момента — не доказательство, история за недели или месяцы — доказательство. Если в компании есть система мониторинга (Zabbix, Netdata, Grafana или встроенные графики в панели хостинга), у графиков за длительный период не должно быть проблем — их либо покажут за минуту, либо начнут объяснять, почему их нет, и вот это объяснение стоит выслушать внимательно.

История нагрузки важнее текущего числа

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

Практически это можно сделать без всякой технической подготовки — просто попросить у админа (или составить самому по данным из CRM/аналитики и биллинга хостинга) простую таблицу: дата апгрейда, что было и что стало по ресурсам, что в этот период происходило с ключевой бизнес-метрикой. Если апгрейды случаются часто — раз в два-три месяца — а бизнес-метрики не растут теми же темпами, подробный разбор именно этой ситуации и того, что за ней обычно скрывается, есть в статье «Апгрейд тарифа четвёртый раз за год: пора на выделенный или пора чинить код» — там же таблица-шаблон для сопоставления роста ресурсов с ростом бизнес-показателей.

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

Когда апгрейд — действительно правильный ответ

Апгрейд оправдан, когда совпадает несколько признаков одновременно, а не один из них:

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

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

Когда дело не в железе: код, конфигурация или независимое мнение

Обратная картина выглядит иначе, и вот её характерные признаки.

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

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

Один процесс съедает непропорционально много. Попросите показать вывод top или htop, отсортированный по потреблению CPU или памяти, и назвать, какой конкретно процесс лидирует. Если это, например, старый тестовый скрипт, забытый cron-задачей, или контейнер без ограничения ресурсов, который разросся без контроля, — проблема не в общей мощности сервера, а в конкретном процессе, который стоит остановить, ограничить или переписать.

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

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

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