1С:Документооборот, системы контроля доступа, базы данных, резервное копирование. Ставим с нуля, разбираемся в чужом коде и лечим то, что «тормозит уже полгода».
Сервер, база данных, учётная система, права доступа, резервное копирование и мониторинг — собранные так, чтобы работали вместе, а не по отдельности. Отдаём с документацией и обучением сотрудников, а не с логином и паролем на бумажке.
Чаще всего система уже стоит, а человека, который её настраивал, давно нет. Мы читаем то, что есть: конфигурации, расширения, регламентные задания, планы обслуживания. Это отдельная работа — понять чужое решение, прежде чем в нём что-то менять.
«Работает медленно» почти никогда не означает «нужен сервер помощнее». Обычно это устаревшая статистика планировщика, отсутствующий индекс, полнотекстовый индекс на медленном диске или регламентное задание, которое молча падает уже год. Мы измеряем, а не гадаем: смотрим планы запросов, время выполнения и журнал регистрации — и правим то, что действительно тормозит.
Из практики. На сервере 1С:Документооборота у госучреждения задачи зависали на двух ответах. Причина оказалась не в нагрузке: доработка закрывала только одну задачу из выборки и молча глотала ошибку прав, поэтому зависание было невидимым. Помимо исправления мы добавили запись реальной ошибки в журнал регистрации — чтобы следующий такой случай было видно сразу. Заодно перенесли базу с зеркала HDD на SSD и вернули регулярное обслуживание PostgreSQL.
Мы не советуем «купить сервер помощнее», пока не измерили, во что упирается система. И не трогаем боевую базу без резервной копии и понимания, как откатиться: любое изменение на проде должно иметь обратный ход.
Полнотекстовый индекс съел системный диск. На сервере 1С каталог служебных данных занимал под сотню гигабайт и лежал на том же диске, что и операционная система. Перенесли служебные каталоги и базу на SSD, вернули регулярное обслуживание PostgreSQL — обновление статистики и переиндексацию, — после чего исчезли «тормоза», которые до этого списывали на нехватку памяти.
Ошибка, которую никто не видел. Доработка глотала исключение и писала в лог «не критичная ошибка». Из-за этого сбой прав доступа выглядел как зависание задачи и жил в системе неизвестно сколько. Помимо исправления мы завели запись реальной ошибки в журнал регистрации: следующий такой случай будет виден сразу.
Копия, из которой ни разу не восстанавливались, копией не считается. Мы настраиваем расписание, проверяем восстановление и добавляем оповещения о том, что копия не сделана. То же с мониторингом: уведомление должно приходить до того, как о проблеме сообщит пользователь.
Разберём процесс, покажем, где машина справится лучше, и назовём срок. Ответим в течение рабочего дня.
Прислать задачу