Сколько теряет бизнес на медленной админке

MAATRIX

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

Почему потери от админки не считают

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

Логика типичного решения о бюджете такая: «сайт видят клиенты — на него нужен нормальный сервер, а админкой пользуются свои же, потерпят». В результате видел не раз одну и ту же картину: у компании фронтенд крутится на выделенном сервере с NVMe и нормальным запасом CPU, а бэкофис на 1С-Битрикс, SuiteCRM или самописной панели живёт на самом дешёвом VPS с одним виртуальным ядром и HDD или медленным сетевым диском — потому что «это же не для клиентов». При этом именно в бэкофисе люди проводят по 8 часов в день, выполняя сотни однотипных операций.

Стоимость ожидания в этом случае никуда не девается — она просто перекладывается с графика конверсии на фонд оплаты труда, где её никто не выделяет отдельной строкой. Ниже — методика, которая переводит эту скрытую статью расходов в конкретное число.

Методика расчёта: сотрудники × операции × задержка

Базовая формула простая и годится для любой внутренней системы — CRM, ERP, панели поддержки, внутреннего портала:

Потерянное время в день =
  число сотрудников
  × число операций в день на сотрудника
  × дополнительная задержка на операцию (в секундах)

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

Дальше переводим секунды в рабочее время и деньги:

Часы в день = Потерянное время в день / 3600
Часы в месяц = Часы в день × число рабочих дней (обычно 20-22)
Стоимость в месяц = Часы в месяц × средняя стоимость часа сотрудника

Разберём на условном примере — не как измеренный факт, а как иллюстрацию методики с ориентировочными цифрами, у вас они точно будут другими:

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

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

Где на самом деле теряются секунды

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

• Диск. Медленный сетевой диск или перегруженный HDD — самая частая причина в дешёвых тарифах. Каждый SELECT с диском вместо кэша в памяти — это лишние миллисекунды, которые в сумме по сложному экрану CRM (десятки запросов на одну карточку) складываются в заметную задержку.
• Нехватка CPU и throttling на виртуальных ядрах. На переподписанных тарифах виртуальное ядро может простаивать в очереди к физическому — CRM с PHP-FPM или Node.js под нагрузкой от нескольких сотрудников одновременно упирается именно в это.
• Мало RAM для кэша и OPcache. Если PHP каждый раз перекомпилирует код, а MySQL не может удержать рабочий набор данных в buffer pool, каждый запрос идёт до диска.
• Сеть между приложением и базой. Если веб-сервер и СУБД разнесены по разным дата-центрам или регионам — а такое бывает при историческом «выросло само» устройстве инфраструктуры — каждый запрос к базе платит round-trip задержкой сети, а таких запросов на одну страницу CRM может быть 30-50.
• N+1 запросы и отсутствие индексов. Это не про сервер, а про код и схему данных — но апгрейд железа даже не всегда лечит это полностью, если карточка сделки дёргает базу полсотни раз вместо одного JOIN.
• Один процесс на всех. Дешёвые тарифы часто идут с ограничением по числу воркеров PHP-FPM или подключений к базе — при нескольких сотрудниках, работающих одновременно, запросы начинают вставать в очередь друг за другом.

Практический вывод: прежде чем менять тариф, стоит понять, какая из причин у вас — иногда узкое место лечится добавлением RAM и SELECT через EXPLAIN, а иногда действительно нужен более мощный CPU и NVMe. Статья о медленной админке WordPress разбирает похожий набор причин на конкретном примере — многое из неё применимо и к другим CMS/CRM на PHP.

Как измерить задержку в вашей админке

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

Замер времени ответа сервера без учёта браузера — самый честный способ понять чистую серверную составляющую:

curl -o /dev/null -s -w \
  "connect: %{time_connect}s  ttfb: %{time_starttransfer}s  total: %{time_total}s\n" \
  https://admin.example.com/orders/list

Если нужно посмотреть поведение под параллельной нагрузкой нескольких сотрудников одновременно — ab (Apache Bench) или wrk:

ab -n 200 -c 10 https://admin.example.com/orders/list

-c 10 здесь имитирует десять одновременных запросов — то есть примерно ситуацию, когда десять человек одновременно листают список заказов. Если время ответа резко растёт при увеличении -c, это почти наверняка означает нехватку воркеров или CPU, а не проблему в коде.

Для замера «как это ощущается пользователем» — вкладка Network в DevTools браузера: колонка Waiting (TTFB) отдельно от Content Download покажет, сколько времени уходит именно на сервер, а сколько — на передачу и рендер. Если Waiting стабильно выше секунды на простых операциях типа «открыть карточку» — это уже сигнал.

На стороне сервера полезно включить лог медленных запросов в MySQL/MariaDB:

# my.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5

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

Для оценки диска — iostat:

iostat -x 1 10

Колонка %util, стабильно близкая к 100%, и растущий await — признак того, что диск не успевает за нагрузкой и именно он держит задержку. Статья про диагностику медленного диска на VPS даёт более подробный разбор этой команды и других способов проверки.

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

Что экономят сильнее, чем стоило бы

Если сравнить, на чём именно бизнес обычно экономит для внутренних систем и что это фактически стоит, картина получается неровная.

Разница в цене между тарифом «на 1 vCPU / 2 ГБ RAM / HDD» и тарифом «на 4 vCPU / 8 ГБ RAM / NVMe» на VPS обычно исчисляется несколькими сотнями-тысячей рублей в месяц. В примере выше с 25 сотрудниками и 91 000 ₽/мес потерь даже консервативная оценка окупаемости апгрейда получается быстрой — счёт идёт на недели, а не на годы. Это не значит, что нужно сразу брать самый дорогой тариф — но экономия «на глазок» без расчёта по формуле выше почти всегда недооценивает реальную стоимость медленной админки для компании с достаточным числом сотрудников.

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

Как ускорить: практические шаги

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

1. Перенести базу данных на быстрый диск (NVMe) и дать ей отдельный запас RAM. Для MySQL/MariaDB это в первую очередь innodb_buffer_pool_size — размер, при котором рабочий набор данных помещается в память:

# my.cnf
innodb_buffer_pool_size = 4G
innodb_buffer_pool_instances = 4

1. Включить OPcache для PHP, если админка на PHP (1С-Битрикс, SuiteCRM и подобные):

; php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.validate_timestamps=0

validate_timestamps=0 даёт максимальную скорость, но требует сброса кэша при каждом деплое — это нормально для продакшена, если деплой это учитывает.

1. Увеличить число воркеров PHP-FPM под реальное число одновременно работающих сотрудников, а не под дефолт:

; pool.d/www.conf
pm = dynamic
pm.max_children = 40
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20

Значения зависят от объёма RAM и среднего потребления памяти на один PHP-процесс — прежде чем ставить наугад, посмотрите текущее потребление через ps aux | grep php-fpm.

1. Разнести приложение и базу данных на отдельные серверы (или хотя бы отдельные диски), если сейчас всё живёт на одном VPS и конкурирует за одни и те же ресурсы.
2. Добавить Redis или Memcached под сессии и часто повторяющиеся выборки — справочники, права доступа, настройки — чтобы не ходить в базу на каждый чих.
3. Проверить индексы по логу медленных запросов из предыдущего раздела — часто одна добавленная индексация ускоряет конкретный тяжёлый экран в разы без апгрейда железа вообще.
4. Убедиться, что сервер физически близко к офису и/или к серверу базы данных, если сотрудники подключаются напрямую, а не через централизованный API — лишний прыжок через полстраны или через другой континент добавляет фиксированные миллисекунды к каждому запросу.

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

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