Главная проблема при расследовании производительности — не отсутствие графиков. Она возникает, когда жалоба уже есть, а техническая картина разбросана по разным системам, инцидент заканчивается раньше начала анализа, а любое вмешательство в продуктив может затронуть важные процессы.
В медицинской компании 1С редко работает изолированно. Рядом могут находиться МИС, ЛИС, RIS/PACS, интеграционные сервисы, терминальные серверы, СУБД, виртуальная инфраструктура и каналы связи между площадками.
Конкретная архитектура у каждой организации своя, но для пользователя результат выглядит одинаково: операция в 1С стала выполняться медленно.
Для ИТ-руководителя в этот момент начинается знакомая проблема. Системный администратор видит свои графики, DBA — показатели СУБД, специалист 1С — технологический журнал и прикладной контекст. Каждый слой может выглядеть подозрительно, но сам по себе редко отвечает на вопрос, почему пользователи почувствовали деградацию именно сейчас.
Если проблема уже закончилась, расследование становится сложнее. Текущие показатели снова нормальные, часть событий не сохранилась, а команде приходится ждать повторения инцидента.
Жалоба звучит просто: «1С тормозит». Но за ней может стоять сервер, СУБД, блокировка, конкретная операция, терминальная сессия, филиальная сеть или зависимая система. Пока эти слои не сопоставлены по времени, команда видит не причину, а набор совпадений.
Почему такие инциденты затягиваются
| Проблема | Как она выглядит на практике | К чему приводит |
|---|---|---|
| Проблема исчезает раньше расследования | К моменту подключения эксперта система снова работает нормально | Нужно ждать повторения или делать выводы по неполным данным |
| Данные разбросаны по разным инструментам | Инфраструктура, СУБД, 1С и журналы анализируются отдельно | Время уходит на сбор общей картины вместо проверки причины |
| Команды видят только свой слой | Администратор, DBA и 1С-специалист по очереди исключают свою зону | Возникает «пинг-понг» между командами и подрядчиками |
| Нет понятной нормы | Высокий CPU или длительный запрос воспринимаются как причина сами по себе | Возникают ложные гипотезы и ненужные изменения |
| Опасно экспериментировать на продуктиве | Рестарт, изменение настроек или подробный сбор могут повлиять на работу | Команда либо рискует, либо откладывает диагностику |
| После исправления эффект не доказан | Графики стали спокойнее, но исходная операция не проверена | Проблема может вернуться, а выводы остаются субъективными |
Поэтому надежное расследование начинается не с поиска самого «красного» графика. Сначала нужно определить масштаб и влияние проблемы, восстановить технический контекст в одном временном окне, сравнить его с нормальным состоянием и только после этого выбирать действие.
Сначала локализуйте симптом, а не компонент
Пользователь видит итог всей технологической цепочки. Операция может начинаться на рабочем месте в филиале, проходить через терминальный сервер, обращаться к серверу 1С и СУБД, а затем ждать ответа интеграционного сервиса.
Поэтому первые минуты инцидента лучше использовать для локализации симптома.
Какая конкретно операция стала медленной и когда это началось?
Проблема затронула одного пользователя, группу, филиал или всю организацию?
Одна информационная база работает медленно или несколько?
Повторяется ли проблема с другой площадки или у другого пользователя?
Нормально ли работают другие корпоративные системы на затронутой площадке?
Были ли перед инцидентом изменения в конфигурации, инфраструктуре, расписании заданий или интеграциях?
Как симптом помогает сократить область поиска
| Что наблюдаем | Что проверить в первую очередь |
|---|---|
| Одна операция медленная у многих пользователей | Прикладной сценарий, запросы, блокировки, СУБД |
| Одна база тормозит, остальные работают нормально | Контур этой базы, связанные операции, запросы, СУБД |
| Деградируют сразу несколько баз | Общий слой: сервер 1С, СУБД, хранилище, виртуализация, сеть |
| Проблема только в одном филиале | Путь пользователя, канал связи, терминальная инфраструктура |
| Проблема только у части пользователей | Сессия, рабочая среда, роль, конкретный сценарий |
| Проблема повторяется примерно в одно время | Фоновые задания, обмены, обслуживание СУБД, резервное копирование и другие ресурсоемкие процессы |
| Операция зависит от внешней системы | Интеграционный контур и время ответа зависимого компонента |
Таблица не заменяет диагностику. Ее задача — быстро сократить область поиска и не начинать расследование с предположения «раз тормозит в 1С, значит проблема внутри 1С».
Техническая тяжесть и бизнес-критичность — не одно и то же
В медицинской организации одно и то же техническое замедление может иметь разный приоритет.
В зависимости от архитектуры 1С может обслуживать финансы, закупки, складской учет, зарплату, договоры и другие процессы, а часть медицинских процессов выполняется в специализированных системах.
Поэтому приоритет лучше определять не только по значению метрики, а по тому, какой реальный процесс затронут, сколько пользователей от него зависит и существует ли приемлемый обходной сценарий.
Медленное формирование отчета, который понадобится завтра, и задержка массовой операции в рабочее время могут выглядеть одинаково на технических графиках, но требуют разных решений.
Если заранее не определены владелец расследования, человек, принимающий решение о вмешательстве, и критерий восстановления, несколько команд могут одновременно улучшать «свои» показатели, но не восстановить пользовательский процесс.
Без baseline высокий показатель легко принять за причину
Высокая загрузка процессора сама по себе еще ничего не объясняет. Если сервер работает примерно так каждый рабочий день, а жалобы начались сегодня после 14:20, важнее понять, что изменилось именно в этот период.
То же относится к памяти, дискам, соединениям, длительности запросов, количеству операций и блокировкам.
Нужен baseline — представление о нормальном поведении системы в сопоставимых условиях. Тогда команда ищет не просто высокий показатель, а отклонение от привычного состояния.
Для сопоставления источников критична и синхронизация времени. Если часы на сервере 1С, СУБД, терминальных серверах и других компонентах расходятся, реальная последовательность событий может выглядеть как набор несвязанных фактов.
Проверяйте все слои в одном временном окне
После локализации симптома задача команды — не по очереди «проверить все», а сопоставить изменения разных слоев в тот же момент, когда пользователь почувствовал проблему.
Рисунок 1 — Состояние разных компонентов сопоставляется по общей временной шкале
Пользовательский и филиальный контур
Если жалобы поступают только из одной клиники или филиала, сначала стоит проверить, воспроизводится ли та же операция с другой площадки и нормально ли работают другие приложения в проблемном филиале.
При терминальной модели полезно определить, связана ли деградация с конкретным RDP-сервером, группой сессий или частью пользователей.
Серверная инфраструктура
CPU, RAM, Disk и Network показывают состояние ресурсов, но не обязательно первопричину.
Рост нагрузки может быть как причиной, так и следствием тяжелой операции внутри 1С или СУБД. После обнаружения отклонения важно определить, какой процесс его создал и совпадает ли изменение со временем пользовательской проблемы.
Сервер 1С
Если медленной стала одна операция в одной базе, область поиска заметно уже, чем при общей деградации нескольких баз.
СУБД
Значительная часть времени операции может уходить на работу с базой данных, поэтому слой СУБД анализируется в том же временном окне.
Запросы, технологический журнал и блокировки
Самый длительный запрос не обязательно является главным источником проблемы. Более короткая, но часто или массово выполняемая операция способна давать больший суммарный эффект.
Интеграции и фоновые процессы
Пользователь может работать в интерфейсе 1С, но фактически ждать ответ другой системы. Поэтому интеграции нельзя исключать из расследования только потому, что жалоба пришла на 1С.
Кейс: сеть медицинских клиник — отчеты в 1С тормозят полгода, а Zabbix не показывает причину
| Исходная ситуация | Что известно |
|---|---|
| Ландшафт | Сеть клиник; конфигурация 1С «Медицина. Больница» |
| Проблема | Проблемы быстродействия наблюдаются около полугода |
| Основной симптом | Наиболее заметные просадки возникают при формировании отчетов |
| Явный триггер | С конкретным релизом или событием проблему не связывают |
| Инфраструктура | Оборудование давно не обновлялось; возраст инфраструктуры рассматривается как одна из гипотез |
| Текущий подход | В момент торможения команда смотрит Zabbix и консоль 1С, но устойчивую причину найти не удается |
Это типичная управленческая проблема: деградация превратилась из разового инцидента в хроническое состояние.
Как построить расследование
Выбрать 2–3 конкретных проблемных отчета. Зафиксировать, кто их запускает, в какой базе, в какое время и сколько обычно занимает формирование.
Найти нормальный период для сравнения. Сопоставить медленный и нормальный периоды по одинаковому набору данных.
Сравнить сервер, кластер 1С, СУБД, технологический журнал и фоновую активность.
Проверить гипотезу об инфраструктуре. Возраст оборудования сам по себе не доказывает, что именно оно ограничивает производительность.
После изменения повторно измерить тот же отчет. Эффект проверяется по схеме «до/после».
Рисунок 2 — Сравнение нормального периода и периода деградации помогает увидеть изменившийся слой
Как сопоставление данных меняет гипотезу
| Что видно при сопоставлении | Как это меняет гипотезу |
|---|---|
| CPU не достигает предельных значений, но отчет все равно замедляется | Причину нельзя сводить только к нехватке процессора |
| В тот же период растут задержки дисковых операций или ожидания СУБД | Проверяется инфраструктурный и DB-слой, а не только сервер 1С |
| Технологический журнал показывает рост длительности конкретной операции или тяжелых запросов | Появляется связь между жалобой пользователя и прикладной нагрузкой |
| Просадка совпадает с фоновыми заданиями или обменами | Проверяется конкуренция за ресурсы и расписание регламентных процессов |
| После изменения повторно измеряется тот же отчет | Можно доказать эффект по схеме «до/после» |
Например, средняя загрузка CPU может оставаться в привычном диапазоне, поэтому просмотр Zabbix не дает очевидного ответа.
Но если при сопоставлении видно, что во время формирования проблемных отчетов растут ожидания на стороне СУБД и дисковой подсистемы, а в технологическом журнале увеличивается длительность связанных запросов, направление расследования меняется.
Вместо гипотезы «1С старая и медленная» появляется конкретное направление: проверить профиль запросов отчета, работу СУБД и способность хранилища обслуживать такую нагрузку.
Почему «включим подробную диагностику, когда снова затормозит» — слабая стратегия
Технологический журнал и другие механизмы глубокой диагностики дают ценную фактуру, но увеличение детализации обычно увеличивает объем собираемых данных и может создавать дополнительную нагрузку.
Практичнее разделять постоянный и углубленный сбор: постоянно хранить минимально достаточный набор данных, а детальную диагностику включать контролируемо под конкретную гипотезу.
От мониторинга ресурсов к диагностическому контуру 1С
У многих компаний уже есть Zabbix, Grafana, мониторинг СУБД и журналы. Проблема часто не в отсутствии инструментов, а в том, что они отвечают на разные технические вопросы и не объединены вокруг одного сценария расследования.
Пользовательский симптом → временной диапазон → база и операция → инфраструктура → сервер 1С → СУБД → технологический журнал → гипотеза → проверка результата.
Рисунок 3 — Диагностический маршрут от пользовательского симптома до проверенного результата
Такой контур не обязан автоматически выдавать готовую первопричину. Его задача — заранее сохранить доказательную фактуру и сократить область поиска, чтобы эксперт тратил время на анализ, а не на сбор данных.
Что должно быть в диагностическом контуре
| Компонент | Какую проблему решает |
|---|---|
| История серверных метрик, состояния 1С и СУБД | Позволяет расследовать уже завершившийся инцидент |
| Данные технологического журнала в согласованном объеме | Дают прикладной контекст по операциям, запросам, ошибкам и блокировкам |
| Контроль скорости ключевых операций | Отделяет пользовательскую деградацию от абстрактной нагрузки |
| Единое временное окно | Позволяет сопоставлять события разных слоев |
| Детализация по базе, пользователю, операции и компоненту | Сокращает область поиска причины |
| Оповещения об отклонениях | Снижают зависимость от массовых жалоб |
| Сравнение «до/после» | Позволяет доказать эффект исправления |
Как понять, что существующего мониторинга уже недостаточно
- Можно ли восстановить картину проблемы, которая закончилась вчера?
- Можно ли в одном временном диапазоне сопоставить инфраструктуру, сервер 1С, СУБД и технологический журнал?
- Понятно ли, какие базы, пользователи и операции пострадали?
- Есть ли нормальный период для сравнения?
- Можно ли отделить подтвержденный факт от гипотезы?
- Можно ли после изменения проверить ту же операцию и доказать эффект?
- Не зависит ли расследование от того, успел ли конкретный эксперт подключиться?
Практический чек-лист на время инцидента
- Зафиксированы точное время начала и пример проблемной операции.
- Понятно, какие пользователи, базы, филиалы и бизнес-процессы затронуты.
- Проверено, воспроизводится ли проблема из другого пользовательского или филиального контура.
- Найден сопоставимый период нормальной работы.
- Инфраструктура, сервер 1С и СУБД проверяются в одном временном диапазоне.
- Проверены запросы, ошибки, блокировки и события технологического журнала.
- Проверена зависимость операции от интеграций и внешних систем.
- Проверены изменения конфигурации, фоновые задания и инфраструктурные работы.
- До включения дополнительной диагностики оценена возможная нагрузка на продуктив.
- После изменения проверена конкретная пользовательская операция, а не только технические показатели.
С чего начать без большой перестройки
Необязательно сразу перестраивать мониторинг всей медицинской инфраструктуры.
Практичнее выбрать одну информационную базу 1С и один действительно болезненный сценарий: периодическое торможение массовой операции, жалобы в определенные часы, блокировки или проблему, которую невозможно нормально разобрать после завершения.
Далее описывается путь операции от пользователя до сервера 1С, СУБД, интеграций и фоновых процессов. После этого определяется, какие данные уже собираются, каких срезов не хватает и какую историю необходимо хранить.
Главный результат
Ценность диагностического подхода не в обещании автоматически находить любую первопричину.
Она в сокращении пути от жалобы до проверяемой гипотезы, уменьшении числа экспериментов на продуктивной системе и снижении зависимости от того, какой специалист оказался рядом в момент инцидента.
Для этого данные нужно собирать заранее, сопоставлять в одном временном окне и строить расследование вокруг конкретной пользовательской операции.
