Налоговый период: почему бухгалтерский сервер умирает в апреле

MAATRIX

Весь год сервер с бухгалтерским софтом ведёт себя образцово: нагрузка ровная, отчёты по мониторингу зелёные, никто про него не вспоминает. А потом наступают последние дни сдачи декларации — и тот же сервер, без единого изменения в конфигурации, начинает виснуть, тормозить и обрывать сессии именно тогда, когда цена ошибки для клиентов выше всего. Это не поломка и не совпадение: десятки или сотни бухгалтеров одновременно формируют отчётность к одному и тому же календарному дедлайну, и вся эта нагрузка синхронизируется в окно в несколько часов. Хорошая новость в том, что дата этого пика известна заранее — с точностью до календаря ФНС, а не до случайного всплеска трафика, — и именно поэтому к нему можно подготовиться заранее, а не тушить пожар постфактум.

Почему нагрузка синхронизируется именно в апреле — и не только в нём

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

• декларация по налогу на прибыль и НДС — как правило, 25 число месяца, следующего за отчётным кварталом;
• расчёт по страховым взносам (РСВ) — та же логика, привязка к кварталу;
• годовая бухгалтерская отчётность — конец марта следующего года;
• 3-НДФЛ для физлиц и ИП — конец апреля, отсюда и заголовок этой статьи;
• авансовые платежи и региональные налоги — свои даты, но тоже фиксированные и одинаковые для всех плательщиков одного режима.

Разница между обычным сезонным пиком (распродажа, отопительный сезон) и налоговым в том, что здесь совпадает не только период, но и поведение внутри периода: почти никто не сдаёт отчётность в первый день из отведённых двадцати пяти. Первые дни срока тихие, а в последние два-три дня приходит основная масса — потому что данные для отчёта у бухгалтера окончательно готовы только к концу периода, а часть клиентов физически откладывает до последнего. В результате нагрузка не растягивается на месяц, а сжимается в несколько рабочих дней, а внутри них — в несколько часов ближе к вечеру, когда все стремятся успеть до закрытия операционного дня оператора ЭДО.

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

Что именно происходит с сервером в эти дни

Технически перегрузка складывается не из одного узкого места, а из нескольких, которые совпадают по времени и усиливают друг друга.

Формирование отчётов — тяжёлая операция сама по себе. Построение регламентированного отчёта в 1С или аналогичном учётном ПО — это чтение и агрегация больших объёмов проводок, часто с блокировками на уровне базы. Когда десять бухгалтеров одновременно формируют декларацию по НДС на одной базе, каждый такой запрос конкурирует за CPU и I/O с остальными, а не выполняется параллельно без потерь.

Терминальные сессии множатся синхронно. Если бухгалтеры работают через терминальный сервер (RDS на Windows или аналог на Linux), в обычный день активно, скажем, треть учётных записей, а в последний день срока — почти все сразу. Проверить текущее число активных сессий на Windows-терминале:

qwinsta /server:localhost

На Linux-терминале с XRDP или подобным решением — число активных X-сессий и загрузка по каждому пользователю:

who
ps aux --sort=-%cpu | head -20

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

Отправка отчётности — не только локальная нагрузка, но и внешняя зависимость. Финальный шаг — выгрузка и отправка через оператора ЭДО (СБИС, Такском, Контур.Экстерн) или напрямую в личный кабинет ФНС. В последние часы срока растёт очередь не только у вас, но и на стороне оператора и приёмного шлюза налоговой — оттуда приходят таймауты и отказы, которые пользователи интерпретируют как «сервер завис», хотя причина может быть снаружи. Отличить одно от другого стоит заранее:

# смотрим на исходящие соединения к оператору ЭДО в момент отправки
ss -tn | grep -E ':(443|8080)' 
# и на код ответа, если отправка идёт через известный HTTP-эндпоинт
curl -o /dev/null -s -w "%{http_code} %{time_total}\n" https://<эндпоинт-оператора>

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

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

Как посчитать свой пик заранее, а не гадать

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

1. Поднимите метрики за последний пиковый период. Если стоит мониторинг (Zabbix, Netdata, встроенные счётчики хостинг-панели) — сравните CPU, память, дисковый I/O и число активных сессий в обычный день и в последние два-три дня перед прошлым дедлайном сдачи. Если мониторинга не было, начните вести его сейчас: следующий квартальный пик наступит независимо от готовности сервера.

1. Смотрите не на средние, а на пиковые пятиминутки. Средняя загрузка за день в 40% ничего не говорит о том, что происходило с 16:00 до 19:00, когда сервер стоял на 100% CPU с очередью процессов. Инструмент для точечного анализа:

sar -u -f /var/log/sysstat/sa<DD> | awk '$1 ~ /1[6-9]:/'

Это покажет загрузку CPU по интервалам конкретного дня из истории sysstat, если он был включён заранее — ещё один довод настроить его до, а не после первого падения.

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

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

Технические меры: что усилить до начала пика

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

Временное увеличение ресурсов сервера. Если провайдер поддерживает вертикальное масштабирование VPS без полной переустановки, самый простой вариант — заранее, за несколько дней до пика, увеличить число vCPU и объём RAM, а после спада нагрузки вернуть обычную конфигурацию. Это дешевле, чем держать избыточную мощность все двенадцать месяцев ради нескольких пиковых дней в квартал. Ориентир по тому, сколько ресурсов реально нужно под конкретное число пользователей 1С, разобран в статье сколько ресурсов нужно VPS для 1С в облаке — там же методика прикидки под свою конфигурацию, а не готовая цифра на все случаи.

Настройка лимитов СУБД под возросшее число сессий. Если 1С работает в клиент-серверном режиме с PostgreSQL, проверьте, что max_connections рассчитан на пиковое, а не на среднее число одновременных подключений, и что для рабочих процессов rphost выделено достаточно памяти:

# postgresql.conf, ориентировочные параметры под пиковую нагрузку —
# точные значения зависят от объёма ОЗУ сервера и размера базы
max_connections = 200
shared_buffers = 25% от RAM сервера
work_mem = зависит от сложности отчётов, начните с консервативного значения и мониторьте

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

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

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

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

Организационные меры: пик решается не только на сервере

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

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

Держать мощность круглый год или усиливать сервер только на пик

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

Практический ориентир для выбора:

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

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