Что делать, если бизнес-система тормозит только в конце месяца?

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

Почему сбой повторяется именно в конце месяца

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

Представьте единственный выезд со склада в последний час работы. Дорога есть, машины исправны, но в один момент к воротам подъезжают все. Добавить ещё один офис рядом со складом не поможет. Сначала нужно понять, кто и почему оказался в одной очереди.

Соберите факты, пока проблема происходит

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

Во время следующего замедления зафиксируйте простую картину:

• точное время начала и окончания;
• какие действия стали медленными, а какие остались нормальными;
• сколько пользователей работало в ключевых разделах;
• какие регламентные задания, обмены и отчёты шли в это время;
• есть ли одинаковая ошибка, ожидание или операция, которая не завершается.

Не надо превращать сотрудников в администраторов. Достаточно попросить их назвать действие и время: «в 16:20 не открывалась карточка заказа», «в 16:35 отчёт строился семь минут». Техническая команда потом сопоставит это с журналами и нагрузкой. Без времени даже хороший журнал похож на коробку чеков без дат.

Проверьте четыре обычные причины

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

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

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

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

Не лечите скорость отдельно от процесса

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

В такой ситуации полезно нарисовать маршрут одного документа от появления до закрытия. Где он задерживается? Кто ждёт чужого решения? Что можно проверить раньше? Иногда достаточно перенести один контроль на день раньше или разделить отчёт по подразделениям, чтобы нагрузка перестала приходить волной.

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

Когда нужно звать техническую команду

Срочно подключать специалистов стоит, если система останавливает операции с деньгами, теряет документы, не даёт восстановить нормальную работу или проблема усиливается от месяца к месяцу. Но и тогда полезно сформулировать запрос не как «всё тормозит», а как «с 16:10 до 18:00 при закрытии периода карточка заказа открывается пять минут; параллельно идёт обмен с учётной системой».

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

Короткий план на следующий месяц

1. Назначьте человека, который соберёт время и примеры медленных действий.
2. Составьте список задач, автоматически запускаемых в пиковый период.
3. Выберите один самый болезненный сценарий и повторите его на безопасной копии данных.
4. Исправьте узкое место или перенесите нагрузку, затем измерьте следующий месяц.
5. Добавьте ранний сигнал: длительность очереди, время отчёта или число необработанных обменов.

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

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

Связанные вопросы

• Почему отчёт работает быстро утром и медленно днём?
• Как понять, что проблема в интеграции, а не в базе данных?
• Можно ли переносить закрытие периода на ночь?
• Какие показатели системы нужно смотреть руководителю?

Чего не делать во время расследования

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

Не меняйте одновременно пять настроек. После такого «лечения» сложно понять, что помогло, а что создало новую проблему. Лучше выбрать одну гипотезу: тяжёлый отчёт, массовый обмен, блокировка или накопленная проверка. Сделать безопасное изменение, измерить следующий пик и только затем идти дальше.

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

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

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

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

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