Отчётный период: как посчитать мощность на пять дней в году

MAATRIX

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

Шаг 1: замерить пиковую нагрузку прошлого периода

Расчёт «на глаз» почти всегда ошибается — либо в оптимистичную сторону (сервер не тянет), либо в пессимистичную (переплата за фантомный запас). Первый и обязательный шаг — посмотреть, что реально происходило на сервере в прошлый отчётный период, а не гадать заранее.

Что смотреть и как:

1. Метрики CPU и памяти за последний отчётный период. Если на сервере стоит мониторинг (Zabbix, Netdata, встроенные метрики хостера), поднимите график за 3-5 дней вокруг даты закрытия предыдущего месяца или квартала. Ищите не среднюю нагрузку, а пиковые пятиминутки — именно они определяют, тормозит ли 1С в момент, когда бухгалтер нажимает «Провести».
2. Дисковую нагрузку (IOPS и latency). 1С на файловой базе или на MS SQL/PostgreSQL особенно чувствительна к диску в моменты перерасчёта итогов. Если в мониторинге нет отдельного графика по дисковой очереди, посмотрите хотя бы iostat в моменты жалоб пользователей на подвисание.
3. Число одновременных сеансов 1С. В консоли кластера серверов 1С (или через ras cluster session list, если используется сервер 1С:Предприятие) можно посмотреть, сколько сеансов было активно в пиковые часы отчётного периода — это косвенно показывает, во сколько раз выросла параллельная нагрузка относительно обычного дня.
4. Субъективные жалобы с привязкой ко времени. Спросите бухгалтерию: во сколько конкретно тормозило, что именно делали в этот момент (закрытие месяца, групповое проведение, формирование отчёта). Это не строгая метрика, но она помогает интерпретировать графики — без неё легко перепутать причину и следствие.

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

# быстрый снимок нагрузки прямо во время пика, если готового мониторинга нет
top -b -n 1 | head -20
vmstat 1 10
iostat -xz 1 10

Шаг 2: посчитать коэффициент пика и заложить запас

Когда есть реальные цифры буднего дня и реальные цифры пикового дня, дальше — арифметика, а не гадание.

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

коэффициент_CPU  = пиковая_загрузка_CPU_% / средняя_загрузка_CPU_%
коэффициент_RAM  = пиковое_использование_RAM / среднее_использование_RAM
коэффициент_IO   = пиковый_IOPS / средний_IOPS

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

Практический ориентир по величине запаса — не точная цифра, а диапазон, в котором стоит держаться, если данных мало:

Важный нюанс: если коэффициент пика получается больше 3-4 раз для CPU, часто выгоднее не масштабировать вертикально «в лоб», а разобраться, что именно так проседает — иногда groupBy-проведение документов упирается не в CPU сервера, а в блокировки на уровне СУБД, и наращивание ядер даёт куда меньший эффект, чем ожидалось. Разовый замер до масштабирования экономит деньги на неэффективном апгрейде.

Шаг 3: временное масштабирование вместо постоянного апгрейда тарифа

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

Практические варианты, от простого к сложному:

• Ручное апгрейд/даунгрейд тарифа по календарю. Самый простой вариант для небольшой инфраструктуры: за день до закрытия периода поднимаете VPS на тариф с большим числом ядер и памяти, после закрытия — возвращаете обратно. У большинства провайдеров это делается без переустановки, через панель, изменение вступает в силу после перезагрузки. Минус — требует человека, который не забудет сделать оба действия вовремя.
• Заранее запланированное изменение ресурсов по расписанию. Если хостинг или собственная автоматизация это позволяет — задача в cron или планировщике, которая инициирует апгрейд за N часов до даты закрытия и даунгрейд через M часов после. Снимает человеческий фактор, но требует API у провайдера и тестирования сценария заранее — не в первый отчётный день.
• Отдельный временный сервер под пиковые дни. Вместо масштабирования основного сервера — поднять второй, более мощный, временно перевести на него терминальные сессии бухгалтерии на время закрытия, затем вернуть на основной. Подходит, когда сама архитектура (терминальный сервер, RDP) это позволяет без сложной миграции данных. Дороже в реализации, но не требует простоя основного сервера на переключение.
• Горизонтальное распределение нагрузки заранее, а не масштабирование в моменте. Если пик предсказуем по датам, часть операций можно сдвинуть по времени внутри допустимого окна — например, начинать групповое проведение документов не всем отделом одновременно в 9:00, а с разбивкой по 30-60 минут. Это не замена мощности, а способ снизить сам коэффициент пика, и часто дешевле любого масштабирования.

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

# пример: апгрейд и даунгрейд тарифа через API хостера по расписанию (псевдокод cron)
# за сутки до закрытия периода — апгрейд
0 9 25 * * curl -s -X POST https://api.hoster.example/v1/servers/12345/resize \
  -H "Authorization: Bearer $API_TOKEN" -d '{"plan":"cpu8-ram16"}'

# через двое суток — возврат на базовый тариф
0 9 28 * * curl -s -X POST https://api.hoster.example/v1/servers/12345/resize \
  -H "Authorization: Bearer $API_TOKEN" -d '{"plan":"cpu2-ram4"}'

Проверьте у своего хостера точное поведение при апгрейде: у части провайдеров изменение ресурсов на лету не требует перезагрузки, у части — требует, и тогда апгрейд нужно планировать не впритык к началу пика, а с запасом в 15-30 минут на перезагрузку и старт служб 1С.

Как посчитать даты: не только «пять дней»

«Пять дней» в заголовке — условность, реальный список дат под усиленную мощность зависит от учётной политики компании и типа отчётности:

• Ежемесячное закрытие — обычно 3-5 первых рабочих дней месяца, когда закрывается предыдущий и формируются первичные отчёты.
• Квартальное закрытие — накладывается на месячное, но добавляет регламентированную отчётность (декларации, расчёты по страховым взносам) — обычно на 2-3 дня дольше обычного месячного цикла.
• Годовое закрытие — самый долгий и тяжёлый пик, может растягиваться на 1-2 недели в январе с максимальной параллельной нагрузкой.
• Отраслевая специфика. У некоторых компаний есть дополнительные пики, не привязанные к стандартному учётному календарю — сдача статистической отчётности, отраслевые декларации с фиксированными датами.

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

Частные случаи: месячный и квартальный пик 1С

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

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

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

Частые ошибки при расчёте мощности на отчётный период

• Считать средний CPU за месяц вместо пиковых пятиминуток. Средняя загрузка за месяц может быть 15%, а в пиковые 10 минут закрытия — 95%. Именно эти 10 минут определяют, будет ли 1С тормозить, а не среднемесячная цифра.
• Забыть про диск, считая только CPU и RAM. На больших базах перерасчёт итогов и групповое проведение документов часто упираются в дисковую очередь раньше, чем в процессор — особенно на сетевых дисках без SSD.
• Не учитывать рост базы год к году. Коэффициент пика, посчитанный в прошлом году, устаревает по мере роста числа документов и пользователей — пересчитывайте его хотя бы раз в год, а не один раз на старте.
• Планировать апгрейд впритык к началу пика. Если у хостера смена тарифа требует перезагрузки сервера, а апгрейд запущен утром в день закрытия — сама перезагрузка может занять те самые 15-30 минут, которые бухгалтерия рассчитывала потратить на работу.
• Забывать про даунгрейд. Апгрейд без обратного понижения тарифа превращает временное масштабирование в постоянную переплату — задача на возврат тарифа должна быть настолько же надёжной, как задача на апгрейд, а лучше вообще автоматической.

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