Полный отказ 1С заметить легко: пользователи не могут войти в систему, операции останавливаются, обращения быстро доходят до ИТ, инцидент получает высокий приоритет. С деградацией производительности сложнее.
Система доступна. Пользователи открывают базы, проводят документы, формируют отчёты. Формально всё работает. Но привычная операция вместо нескольких секунд выполняется заметно дольше, отчёт периодически «задумывается», а в определённые часы сотрудники начинают ждать ответа системы.
Причём сегодня проблема может появиться, через час исчезнуть, а завтра повториться снова.
Именно поэтому постепенное или периодическое торможение 1С легко недооценить: аварии нет, но качество сервиса уже изменилось.
Важен не только вопрос «работает ли 1С», а способность команды объективно понять, где, когда и почему ухудшается работа системы — до того, как проблема превратится в поток пользовательских жалоб.
Система доступна, но качество работы уже изменилось
Доступность показывает, можно ли пользоваться системой в принципе. Производительность — можно ли выполнять нужные операции с приемлемой скоростью.
Если сотрудник может открыть 1С, но проведение документа, формирование отчёта или другая регулярно используемая операция занимает заметно больше времени, технически система остаётся доступной. С точки зрения рабочего процесса ситуация уже изменилась.
Отсутствие падений ещё не означает, что 1С работает нормально.
Рисунок 1 — Доступность системы не означает нормальную производительность пользовательских операций
Что стоит выяснить при первых жалобах
- какая конкретно операция стала медленной;
- когда проблема появилась и как долго продолжалась;
- затронут один пользователь, группа, подразделение, филиал или вся организация;
- проблема наблюдается в одной информационной базе или в нескольких;
- что в этот момент происходило с сервером 1С и СУБД;
- были ли незадолго до этого изменения конфигурации, инфраструктуры, интеграций или расписания фоновых задач;
- повторяется ли деградация в одинаковые периоды времени.
Уже эти ответы помогают отделить локальный симптом от более широкой деградации и выбрать первые направления проверки.
| Что наблюдаем | Что имеет смысл проверить в первую очередь |
|---|---|
| Одна операция медленная у большого числа пользователей | Прикладной сценарий, запросы, блокировки, СУБД |
| Одна база тормозит, остальные работают нормально | Контур этой базы, связанные операции, запросы, СУБД |
| Одновременно деградируют несколько баз | Общие компоненты: сервер 1С, СУБД, хранилище, виртуализация, сеть |
| Проблема только в одном филиале | Канал связи, терминальная инфраструктура, путь пользователя, локальные компоненты |
| Проблема только у части пользователей | Рабочая среда, терминальная сессия, роли и конкретные пользовательские сценарии |
| Проблема повторяется примерно в одно время | Фоновые задания, обмены, резервное копирование, обслуживание СУБД и другие ресурсоёмкие процессы |
| Медленная операция зависит от внешней системы | Интеграционный контур и время ответа зависимого компонента |
Это не таблица готовых диагнозов. Она только помогает определить, в каком направлении продолжать расследование.
Небольшая задержка становится проблемой, когда масштабируется
Один отчёт, который формируется дольше обычного, редко выглядит как серьёзный инцидент. Но корпоративная система состоит из повторяющихся операций.
Если одна и та же задержка возникает у большого числа пользователей или многократно повторяется в течение рабочего дня, влияние начинает накапливаться.
При этом переводить каждую дополнительную секунду напрямую в «потерянные человеко-часы» неправильно. Часть операций выполняется параллельно, сотрудники могут переключаться между задачами, а критичность процессов различается.
Глубина
Насколько изменилось время выполнения операции относительно нормального состояния.
Охват
Сколько пользователей, филиалов, баз или операций столкнулось с ухудшением.
Частота
Это единичный эпизод или ситуация возникает регулярно.
Если сотрудники заранее знают, что определённый отчёт после обеда лучше не запускать, медленная работа уже стала частью операционного процесса.
В медицинской организации влияние зависит от роли 1С
Набор процессов, реализованных в 1С, различается от организации к организации. Клинические процессы могут выполняться преимущественно в специализированной МИС, поэтому любое торможение 1С неправильно автоматически называть клиническим инцидентом.
Но 1С может участвовать в закупках, складском учёте, финансах, зарплате, договорах, учёте основных средств, работе подразделений и других процессах, обеспечивающих деятельность медицинской организации.
Техническая тяжесть проблемы и её бизнес-критичность не всегда совпадают.
Отчёт, который нужен завтра, и массовая операция, от которой прямо сейчас зависит работа нескольких подразделений, могут замедлиться одинаково. Приоритет расследования будет разным.
Поэтому ИТ важно понимать не только величину технического отклонения, но и контекст: какой процесс затронут, сколько пользователей от него зависит, как часто проблема повторяется, существует ли обходной сценарий и требуется ли немедленное восстановление скорости.
Опасный момент наступает, когда пользователи привыкают к медленной 1С
Полную недоступность системы пользователи почти всегда эскалируют. С периодическими торможениями всё иначе.
Если проблема существует долго, сотрудники начинают адаптироваться к поведению системы: тяжёлые операции переносят на менее загруженное время, после нажатия кнопки просто ждут дольше, внутри подразделений появляются собственные обходные сценарии.
Организация продолжает работать, но количество обращений в ИТ перестаёт отражать реальный масштаб деградации.
Возникает парадокс: проблема становится привычнее — и одновременно менее заметной для тех, кто отвечает за состояние ИТ.
Поэтому ориентироваться только на количество пользовательских заявок недостаточно.
Непредсказуемые торможения расследовать сложнее постоянных
Постоянно медленная система неудобна, но хотя бы предсказуема. Гораздо сложнее ситуация, когда утром операция работает нормально, после обеда становится медленной, через час восстанавливается, а спустя несколько дней ситуация повторяется.
Пользователь сообщает о проблеме. Специалист подключается. А проблема уже исчезла.
Если техническая история за этот период не сохранена, ИТ-команде остаётся ждать повторения или пытаться реконструировать произошедшее по нескольким источникам.
- как изменялась скорость пользовательской операции;
- что происходило с сервером 1С;
- как в тот же момент вела себя СУБД;
- какие длительные запросы выполнялись;
- возникали ли ошибки и блокировки;
- изменилась ли инфраструктурная нагрузка.
Если эти данные сохраняются, исчезновение пользовательского симптома уже не означает исчезновение инцидента для расследования.
Рисунок 2 — Сохранённая техническая история позволяет расследовать инцидент даже после исчезновения симптома
Почему реактивная диагностика становится дорогой
При реактивном подходе расследование начинается после жалобы. Пользователь сообщает: «1С сегодня тормозит». Системный администратор смотрит серверы, DBA проверяет СУБД, специалист 1С анализирует свою часть системы.
Если инфраструктура сложная, в расследовании могут участвовать несколько команд или подрядчиков. Каждый видит отдельную часть картины.
На сервере могла действительно вырасти нагрузка. В технологическом журнале мог появиться длительный запрос. В СУБД — ожидание. В 1С — блокировка.
Главный вопрос: являются ли эти события частями одной проблемы и совпадают ли они по времени с пользовательской деградацией?
Чем чаще такие инциденты повторяются, тем больше ресурсов уходит не на устранение причины, а на очередной сбор исходных данных.
Это уже вопрос не только быстродействия 1С, но и стоимости эксплуатации системы и способности команды быстро принимать обоснованные решения.
Почему одного инфраструктурного мониторинга может быть недостаточно
Во многих организациях инфраструктура уже контролируется через Zabbix, Grafana или другие системы мониторинга.
Это необходимые инструменты, но обычно они отвечают прежде всего на инфраструктурные вопросы: был ли доступен сервер, насколько загружен CPU, хватает ли памяти, что происходило с дисками и сетью.
Пользовательская жалоба находится уровнем выше.
Например: «Отчёт, который обычно формируется быстро, сегодня периодически выполняется значительно дольше». Для расследования такого случая недостаточно знать, что CPU в это время был загружен на 80%.
Нужно понять, какая операция деградировала, в какой базе и у каких пользователей; какие запросы выполнялись; были ли блокировки или ошибки; что происходило с СУБД; совпадает ли изменение инфраструктуры по времени именно с этой операцией.
Задача состоит уже не просто в мониторинге серверов. Нужна связь пользовательской производительности 1С с состоянием остальных технологических слоёв.
Типовая ситуация: проблема есть несколько месяцев, но поймать её не удаётся
Представим характерный для медицинской организации сценарий.
Пользователи несколько месяцев периодически жалуются на скорость работы 1С. Особенно заметны просадки при формировании отчётов. Инфраструктура давно существенно не менялась.
Когда пользователи сообщают о проблеме, ИТ пытается проверить текущее состояние через инфраструктурный мониторинг и стандартные инструменты 1С.
Явного отклонения обнаружить не удаётся. Через некоторое время система снова работает нормально.
Главная проблема такой ситуации даже не в том, что причина пока неизвестна. Проблема в отсутствии непрерывной доказательной картины.
Без неё одинаково правдоподобными остаются десятки гипотез: серверу не хватает ресурсов, изменилась работа СУБД, появился тяжёлый запрос, возникли ожидания или блокировки, в определённое время выполняется фоновая нагрузка или изменилась сама прикладная операция.
Начинать с модернизации оборудования только потому, что оно старое, рискованно. Так же рискованно сразу оптимизировать код или СУБД.
Сначала нужны факты. А для периодической проблемы факты должны собираться до того, как началось расследование, а не после обращения пользователя.
Как должен выглядеть диагностический контур производительности 1С
Полезный мониторинг начинается не с количества графиков. Он начинается с вопросов, на которые ИТ-команда должна уметь ответить.
Конкретная ключевая операция или группа операций 1С.
Нужен точный временной период, к которому можно вернуться после завершения проблемы.
Пользователей, информационную базу, подразделение или несколько контуров.
На сервере 1С, в СУБД, инфраструктуре и технологическом журнале.
Совпадение событий ещё не является доказанной первопричиной, но позволяет значительно сузить область поиска.
Показатели до и после изменения должны быть сопоставимы.
Нормальный эксплуатационный цикл: обнаружить ухудшение → локализовать проблемный слой → собрать фактуру → выполнить изменение → проверить результат.
Рисунок 3 — Диагностический цикл: обнаружение, локализация, факты, изменение и проверка результата
Когда диагностический контур должен оставаться внутри инфраструктуры
Для части медицинских организаций важен не только состав мониторинга, но и место хранения диагностических данных.
Ограничения могут задаваться внутренней политикой информационной безопасности, архитектурными требованиями или правилами эксплуатации корпоративных систем.
В такой ситуации серверные метрики, технологический журнал 1С, данные СУБД и история производительности должны оставаться внутри инфраструктуры самой организации.
Это не отменяет задачу полноценной диагностики — меняется модель размещения.
Поэтому при выборе системы мониторинга имеет смысл заранее проверять, может ли она работать в On-prem-контуре, какие данные остаются внутри организации, как организованы хранение истории, обновления и доступ специалистов к диагностической информации.
Это уже не только технический вопрос. Это критерий архитектуры решения и управляемости эксплуатации.
Пять вопросов к текущей системе мониторинга
Понять, существует ли проблема наблюдаемости, можно без внедрения новых инструментов. Достаточно проверить текущий процесс эксплуатации 1С.
- восстановить состояние системы за вчерашний проблемный период, если пользователь сообщает о торможении только сегодня;
- видеть скорость конкретных значимых операций 1С, а не только состояние серверов;
- в одном временном контексте сопоставить пользовательскую деградацию с сервером 1С, СУБД, запросами, ошибками и блокировками;
- обнаружить постепенное ухудшение раньше, чем первым индикатором станет обращение пользователя;
- после исправления объективно показать по данным, что производительность вернулась к нормальному уровню.
Если на несколько вопросов ответ отрицательный, проблема может находиться не только в конкретном медленном отчёте или сервере. Есть слепая зона в самом процессе контроля производительности.
С чего начать
Не обязательно сразу менять существующие системы мониторинга или увеличивать ресурсы серверов.
Сначала полезно взять один реальный повторяющийся сценарий — например, «пользователи периодически жалуются, что конкретная операция 1С тормозит» — и проверить, можно ли сегодня пройти весь путь расследования.
- зафиксировать момент и масштаб деградации;
- вернуться к нужному временному интервалу;
- увидеть состояние сервера 1С, СУБД и инфраструктуры;
- проверить запросы, ошибки и блокировки;
- сформировать проверяемую гипотезу;
- после исправления сравнить показатели до и после.
Если на каком-то этапе данных не хватает, становится понятно, какую именно слепую зону нужно закрывать.
Сначала сформулируйте требования к диагностике
Периодическая деградация 1С опасна тем, что система продолжает работать и проблема долго может оставаться незаметной на уровне стандартного контроля доступности.
Задача ИТ — видеть не только состояние серверов, но и скорость значимых пользовательских операций, сохранять историю проблемных интервалов и сопоставлять события разных технологических слоёв.
Такой подход позволяет сначала понять, какие данные действительно нужны для расследования, и только затем выбирать инструмент — вместо того чтобы покупать ещё один набор графиков и надеяться, что он сам ответит на вопрос «почему тормозит 1С».
