Инцидент в 1С: как передать контекст и не начинать диагностику заново

Сложный сбой в 1С редко начинается с чистого листа. Внутренняя команда уже проверила журналы, сравнила окружения и выдвинула несколько гипотез. Но при передаче задачи следующей линии поддержки часть контекста теряется, и диагностика фактически начинается заново.

Длина обращения сама по себе не помогает диагностике. Даже подробное письмо бесполезно без точного времени, масштаба, условий воспроизведения и перечня уже выполненных проверок. Ниже — структура, которая превращает сообщение «у нас тормозит 1С» в рабочее описание инцидента.

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

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

Сравните два обращения. Первое: «при проведении документов зависает 1С». Второе: «Начиная с 9:40 документ проводится по несколько минут, но только у тех, кто работает через терминальный сервер; при другом подключении все в порядке. За день до этого обновили платформу. Какие гипотезы проверили — ниже, журналы за этот интервал во вложении». Со вторым можно сразу начинать проверку.

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

Блок

Что указать

Зачем это нужно

Симптом

Операция, ожидаемый и фактический результат, полный текст ошибки

Не смешивать наблюдение с гипотезой

Где и когда

База, версии платформы и конфигурации, тип подключения, точное время

Найти соответствующий интервал в журналах и метриках

Масштаб

Число пользователей и затронутые процессы, наличие обходного пути

Оценить приоритет и влияние на бизнес

Воспроизведение

Последовательность действий, частота, обязательные условия

Проверить сбой в контролируемом сценарии

Последние изменения

Релизы, доработки, настройки, инфраструктура, нагрузка

Сузить область поиска

Что проверено

Гипотезы, действия, результаты и временные меры

Не повторять уже выполненную работу

Данные

Журналы, стеки, ошибки и метрики с привязкой ко времени

Связать симптом с техническими событиями

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

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

Включайте технологический журнал точечно. Если технологический журнал не был настроен заранее, его включают в файле logcfg.xml на сервере 1С. Для ошибок обычно собирают события EXCP, для проблем с блокировками — TLOCK, TTIMEOUT и TDEADLOCK, для медленных операций — CALL и события запросов к СУБД (DBMSSQL или DBPOSTGRS) с порогом длительности. Полный журнал на нагруженной базе быстро разрастается, поэтому ограничивайте состав событий и время сбора, а настройки приложите к обращению вместе с самим журналом.

Записывайте результат каждой проверки. Фраза «все стандартное проверили» не передает контекст. Перечислите проверенные гипотезы и рядом запишите результат. Например: проблема сохраняется после перезапуска сеанса; воспроизводится только в терминальном подключении; на копии базы не проявляется; отключение конкретного фонового задания не изменило поведение.

Такой журнал действий полезен даже тогда, когда гипотеза не подтвердилась. Отрицательный результат сужает поиск и показывает, какие ветви диагностики уже закрыты.

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

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

Перед передачей проверьте, нет ли в данных персональной информации, учетных данных или коммерчески чувствительных сведений. Состав диагностического пакета должен соответствовать правилам вашей организации и каналу передачи.

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

Следующая линия должна сразу увидеть исходную точку: что случилось, насколько это критично, какие компоненты затронуты и какие выводы уже сделаны.

Шаблон карточки инцидента. Его можно использовать как основу для обращения во внутреннюю или внешнюю поддержку.

Заголовок: [система] [операция] [симптом]

Влияние на работу:
— затронутые пользователи и процессы
— работа остановлена / есть обходной путь

Окружение:
— база и контур
— версия платформы и конфигурации
— тип подключения и инфраструктура

Временная шкала:
— когда началось
— точное время примера
— какие изменения предшествовали инциденту

Воспроизведение:
1. Действие пользователя
2. Ожидаемый результат
3. Фактический результат

Что уже проверено:
— гипотеза → действие → результат

Вложения:
— файл → временной интервал → что в нем искать

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

Разберем на вебинаре. Как искать первопричину сложного сбоя на реальных кейсах, покажем 19 ноября в 11:00 МСК на бесплатном вебинаре «Сложные сбои в 1С: как найти первопричину и избежать повторения».

Алена Котова, руководитель проекта развития 1С:РКЛ, и Александр Буганов, эксперт по 1С в Инфостарте, разберут ошибки и блокировки, поиск первоначального сбоя в транзакции, работу с журналами и отладчиком, а также подготовку обращения в поддержку. В конце спикеры ответят на вопросы участников.

Программа и регистрация

Источник: habr.com