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

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

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

Наш чек-лист разделен на две части:

1. Опрос по продуктиву.

2. Проверки на тесте.

Чек-лист расследования проблем быстродействия и стабильности работы системы.

Опрос по продуктиву.

Необходимо максимально собрать ответы на вопросы, приведенные ниже. И важно помнить — пользователи могут лгать, при это не обязательно нарочно. Если есть возможность — проверяем сами.

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

Уточнить только ли 1С является источником жалоб пользователя.

Понять, действительно ли «тормозит все» или что-то конкретное.

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

Узнаем, если проблема без воздействия на систему других пользователей.

И одно из самых важных. Известна ли нам конкретная последовательность действий, которая приводит к данной проблеме. Или же такая последовательность неизвестна и ошибка является «плавающей».

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

Проверки на тесте

Выполнение проверок на тесте может также помочь в сужении области поиска причины.

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

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

И вот уж точно, отключить работу кластера СУБД на продуктиве вам вряд ли кто позволит. А вот на тестовом контуре можно отключить баллансировщик кластера СУБД, чтобы исключить его из цепочки подозреваемых.