Закрытие квартала: три дня, когда учётная система обязана выстоять

MAATRIX

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

Чем закрытие квартала отличается от обычного месяца

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

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

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

Что происходит с нагрузкой на систему в эти три дня

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

• Много одновременных сессий. Обычно в базе работает часть бухгалтерии, остальные заняты другими задачами. В дни закрытия подключаются все — включая тех, кто в обычный день в системе почти не появляется (руководители подразделений, которые визируют отчёты, внешние аудиторы, если они привлечены).
• Тяжёлые отчёты вместо лёгких операций. В обычный день типичная операция — провести документ, это быстро. На закрытии добавляются пересчёт итогов по всей базе, оборотно-сальдовые ведомости за квартал, консолидированные отчёты — операции, которые читают и агрегируют на порядок больше данных.
• Пиковая нагрузка на диск и СУБД. Массовое перепроведение документов и построение отчётов — это интенсивные операции чтения и записи. Если диск и так работает на пределе в обычные дни, на закрытии это становится узким местом первым.
• Параллельные фоновые задания. Регламентные задания 1С (обновление итогов, обмен данными, если есть интеграции с банком или CRM) продолжают выполняться на фоне ровно тогда, когда системе и так тяжело.

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

Подготовка инфраструктуры за одну-две недели до закрытия

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

Проверьте свободное место на диске. Массовое перепроведение документов и построение отчётов генерируют временные файлы и увеличивают объём логов транзакций СУБД. Правило простое: на закрытие квартала должно быть свободно заметно больше места, чем в обычный день — если у вас обычно есть 15–20% запаса, перед закрытием стоит убедиться, что этого хватит с учётом роста базы и временных файлов. Проверить занятость:

df -h
du -sh /var/lib/postgresql/*/main  # для PostgreSQL

Обновите статистику и переиндексируйте базу заранее, а не во время закрытия. Для PostgreSQL:

VACUUM ANALYZE;
REINDEX DATABASE your_1s_db;

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

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

Оцените реальный запас по ресурсам. Если сервер и в обычные дни работает с CPU под 70–80%, на закрытии он почти наверняка упрётся в потолок. Сравните текущую конфигурацию с тем, что реально нужно под число пользователей — ориентиры по CPU, памяти и дискам под 1С разбирали в статье про конфигурацию и цену выделенного сервера для 1С и учётных систем: для активной одновременной работы 20–30 пользователей в базе нужен запас, которого «сервер, который обычно справляется», часто не даёт именно в пиковые дни.

Почему в эти дни действует полный запрет на технические работы

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

• обновлений ОС и пакетов (кроме критичных патчей безопасности с публичным эксплойтом);
• обновления самой конфигурации 1С или платформы, если это не связано напрямую с корректировкой форм отчётности под закрытие;
• миграций, переносов баз, смены дисковой подсистемы;
• любых экспериментов «заодно сделаем то, что давно откладывали».

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

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

Бэкапы и план восстановления, если что-то пошло не так

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

Минимальный набор перед закрытием квартала:

• Отдельный контрольный бэкап прямо перед стартом закрытия. Не полагайтесь только на регулярное расписание — сделайте снимок базы вручную непосредственно перед тем, как бухгалтерия начнёт массово проводить документы. Это ваша точка отката, если в первый же час пойдёт не так.
• Тестовое восстановление на отдельном стенде. Разверните последний бэкап на тестовом сервере и убедитесь, что база поднимается и открывается в 1С без ошибок. Делать это стоит не только перед закрытием квартала, а регулярно — но перед квартальным пиком это особенно оправданно, потому что цена «бэкап оказался нерабочим» здесь максимальна.
• Более частые инкрементальные бэкапы на сами три дня закрытия. Если в обычные дни хватает бэкапа раз в сутки, на закрытии имеет смысл сократить интервал — например, до нескольких раз в день или включить непрерывный WAL-архив для PostgreSQL, чтобы при сбое откатиться не на вчера, а на последние минуты.

# Пример ручного бэкапа PostgreSQL перед стартом закрытия
pg_dump -Fc your_1s_db > /backup/pre-close-$(date +%Y%m%d-%H%M).dump

# Проверка, что дамп читается и не битый
pg_restore --list /backup/pre-close-20260828-0900.dump

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

Какая конфигурация сервера выдерживает квартальный пик

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

CPU. 1С плохо параллелится на уровне отдельной операции — важна частота ядра, а не их число. При этом на закрытии одновременно работает больше пользователей, чем обычно, поэтому нужен запас и по количеству ядер тоже: чтобы параллельные сессии не выстраивались в очередь за процессорным временем. Ориентиры по числу ядер и памяти под разное количество одновременных пользователей 1С разбирали в статье про лучший VPS для 1С в России — та же логика применима и к выбору конфигурации под пиковые дни, только с запасом на пиковое, а не среднее число сессий.

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

Диск. NVMe вместо SATA-SSD — не роскошь для учётной системы, а прямая защита от того, что при квартальном пике операции записи (а закрытие периода — это в первую очередь массовая запись, а не чтение) станут узким местом. RAID 1/10 обязателен: на закрытии, когда каждый час простоя стоит дорого, отказ единственного диска без резервирования — риск, который недопустим именно в эти дни.

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

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