Ошибки после релиза: как разбирать причины, а не искать виноватого

Утро после релиза часто начинается одинаково.

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

После релиза 1С не работает.

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

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

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

И вот здесь у команды есть развилка.

Можно пойти по плохому пути: искать виноватого. Это эмоционально понятно, особенно когда пользователи стоят над душой, руководитель спрашивает сроки, а бизнес-процесс уже встал.

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

 

 

Ошибка после релиза — это не только техническая проблема

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

Иногда так и бывает. Но чаще пострелизная ошибка показывает не только дефект в коде. Она показывает слабое место в процессе.

Например:

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

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

И это нормально. Пользователь не обязан разбираться в устройстве 1С. Команда разработки — обязана.

 

Почему в 1С пострелизные ошибки особенно чувствительны

В 1С редко бывает изолированная доработка, которая живет сама по себе и ни на что не влияет.

Документ связан с регистрами. Форма связана с командами, ролями и условным оформлением. Отчет связан с запросами, СКД, настройками пользователей и правами доступа. Обмен связан с регламентными заданиями, фоновыми заданиями, временными файлами, настройками подключения и данными, которые пришли из другой системы. Расширение может аккуратно добавить одну команду, а может неожиданно повлиять на типовую форму.

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

Вроде добавили строку в отчет. А у пользователя она не появилась. Начинаем смотреть — дело не в отчете. У пользователя нет права на один из регистров, из которого отчет добирает данные. Разработчик проверял под полными правами, аналитик смотрел демонстрационный пример, а реальная роль пользователя оказалась другой.

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

Вроде мелочь, но именно такие мелочи потом ломают релиз.

 

Плохой подход: искать виноватого

Самый бесполезный вопрос в первые минуты после ошибки:

Кто это сломал?

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

Но вопрос «кто виноват?» почти никогда не помогает быстро восстановить работу.

Он дает другой эффект:

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

В итоге команда тратит энергию не на разбор причины, а на объяснение, почему каждый лично не виноват.

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

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

 

 

Хороший подход: искать причину

Нормальный разбор начинается не с фамилии разработчика, а с факта:

• что именно не работает;
• у кого не работает;
• в какой базе;
• на каком объекте;
• после какого изменения;
• можно ли воспроизвести;
• есть ли быстрый обходной путь;
• нужен ли откат или можно исправить точечно.

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

Но даже в пожаре важно не потерять голову.

Плохой вариант: быстро поправили, выкатили, забыли.

Хороший вариант: быстро восстановили работу, а потом спокойно разобрали, почему ошибка прошла в релиз.

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

 

Как разбирать ошибку после релиза по шагам

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

Шаг 1. Зафиксировать симптом без интерпретаций

Пользователь пишет: «1С не работает». Это не симптом, а сигнал бедствия.

Нужно быстро превратить его в конкретику:

• какая база;
• какой пользователь;
• какой объект;
• какое действие выполнял;
• какое сообщение об ошибке;
• работало ли раньше;
• после какого релиза заметили;
• ошибка у одного пользователя или у всех.

Например, вместо «не работает запись документа» должно появиться: «у пользователя с ролью менеджера при записи документа появляется ошибка проверки заполнения нового реквизита, если документ создан на основании заказа».

Это уже можно разбирать.

Шаг 2. Воспроизвести ошибку

Пока ошибка не воспроизведена, команда часто спорит с воздухом.

Разработчик говорит: «У меня работает». Пользователь говорит: «У меня не работает». Тимлид смотрит на это и понимает, что где-то между ними живет реальная причина.

В 1С важно воспроизводить не просто действие, а весь контекст:

• тот же пользователь или роль;
• та же организация;
• тот же вид документа;
• тот же способ создания документа;
• та же форма;
• тот же режим запуска;
• тот же набор расширений;
• та же последовательность действий.

Документ, созданный вручную, и документ, созданный на основании, могут пройти разную ветку кода. Отчет с настройками по умолчанию и отчет с сохраненным пользовательским вариантом — это тоже не всегда одно и то же. Ручной запуск обработки и запуск из регламентного задания могут отличаться правами, контекстом и доступностью файлов.

Шаг 3. Понять, что изменилось в релизе

После воспроизведения нужно ответить на скучный, но главный вопрос: что именно поменялось?

Не «в релиз вошло много задач», а конкретно:

• какие объекты метаданных изменялись;
• какие формы затронуты;
• какие модули менялись;
• какие запросы переписывались;
• какие роли обновлялись;
• какие расширения подключались или менялись;
• какие регламентные задания добавлялись;
• какие обработки участвовали в сценарии.

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

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

Пользователь видит, что в отчете нет строки. А причина может быть в отборе по организации, праве на чтение регистра, измененном запросе, варианте отчета или непроведенном регламентном задании, которое должно было подготовить данные.

Шаг 4. Проверить зависимости от других доработок

Одна из частых причин пострелизных ошибок — новая доработка тестировалась сама по себе. А в рабочей базе она встретилась с другими доработками.

На тесте проверили новый реквизит. Но не проверили старую обработку, которая записывает документ программно.

Проверили новый отчет. Но не проверили, что часть пользователей видит данные через ограниченные роли.

Проверили новую форму. Но не учли расширение, которое меняет команды этой формы.

Проверили ручной сценарий. Но не проверили регламентное задание, которое запускает тот же код ночью.

Это не всегда «косяк разработчика». Часто это следствие того, что у команды нет карты зависимостей и нормального чек-листа релиза.

Шаг 5. Быстро выбрать: исправление, обходной путь или откат

После локализации причины нужно принять практическое решение.

Вариантов обычно три:

• точечное исправление — если причина понятна, исправление маленькое, риск повторного релиза низкий;
• обходной путь — если можно временно продолжить работу без остановки процесса;
• откат — если ошибка критичная, затрагивает много пользователей или быстрое исправление может сломать еще больше.

Откат — это не поражение. Иногда это нормальное управленческое решение. Хуже, когда команда из гордости пытается чинить продуктив «на горячую» и добавляет второй инцидент поверх первого.

Шаг 6. После тушения пожара разобрать причину процесса

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

Нужно ответить не только на вопрос «какая строка кода упала», но и на вопрос «почему эта ошибка дошла до продуктивной базы».

Возможные ответы:

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

Вот это уже нормальный разбор. Без крика, без охоты на виноватых, но с выводами.

 

 

Таблица: что видит пользователь и что стоит проверить в 1С

 

Симптом со стороны пользователя	Возможная причина в 1С	Что проверить
Документ не записывается после релиза	Новая проверка в модуле объекта, незаполненный реквизит, ошибка в подписке на событие, изменение заполнения	Модуль объекта, обработчики ПередЗаписью и ПриЗаписи, способ создания документа, заполнение реквизитов, старые документы
Документ не проводится	Ошибка в движениях, измененный запрос, неучтенный вид операции, проблема с регистрами	Проведение по разным видам операций, движения по регистрам, данные для запроса, старые и новые документы
В отчете нет нужной строки	Права на данные, отбор в запросе, настройки СКД, пользовательский вариант отчета	Запрос, СКД, роли пользователя, варианты отчета, доступность регистров и справочников
Кнопка пропала с формы	Команда скрыта по условию, нет права, изменилась форма, влияет расширение	Состав команд формы, роли, функциональные опции, условное оформление, расширения
У одного пользователя ошибка есть, у другого нет	Разные роли, настройки, подразделение, организация, права доступа, RLS	Профиль пользователя, роли, ограничения доступа, параметры сеанса, настройки пользователя
Обработка работает вручную, но падает по расписанию	Другой контекст выполнения, права фонового задания, недоступный файл или каталог, параметры запуска	Регламентное задание, фоновое задание, пользователь запуска, доступ к файлам, журнал регистрации
После релиза обмен перестал загружать данные	Изменился формат данных, реквизит стал обязательным, не обработали пустое значение, ошибка сопоставления	Логи обмена, входящие данные, обязательные реквизиты, обработку исключений, тестовые пакеты данных
Форма открывается с ошибкой	Ошибка в ПриСозданииНаСервере, неверный тип реквизита, отсутствие данных, конфликт расширения	Код формы, серверные обработчики, реквизиты формы, параметры открытия, расширения
У пользователей появились ошибки доступа	Не обновили роль, новый объект не включен в профиль, отчет обращается к недоступному регистру	Роли, профили групп доступа, права на новые объекты, запросы отчетов и обработок
После релиза старая доработка перестала работать	Новая доработка изменила общий объект, реквизит, процедуру, запрос или поведение формы	Связанные объекты, общие модули, места программной записи, расширения, старые обработки

 

Что добавить в чек-лист перед релизом 1С-доработки

Чек-лист не должен быть огромным документом, который никто не открывает. Тогда он быстро превращается в ритуал: галочки поставили, качество не изменилось.

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

1. Проверка пользовательского сценария

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

2. Проверка прав и ролей

• Доработка проверена не только под полными правами.
• Проверен реальный профиль пользователя.
• Новые объекты добавлены в нужные роли.
• Отчеты и формы не обращаются к данным, на которые у пользователя нет прав.
• Проверены ограничения доступа, если они используются.

3. Проверка форм

• Форма открывается у нужных пользователей.
• Команды отображаются в нужных условиях.
• Новые реквизиты заполнены и корректно сохраняются.
• Условное оформление не скрывает важные элементы.
• Клиентский и серверный код формы отрабатывает без ошибок.

4. Проверка документов

• Документ записывается.
• Документ проводится.
• Документ перепроводится.
• Старые документы открываются и записываются без неожиданных ошибок.
• Проверены разные виды операций и статусы.
• Проверены движения по регистрам.

5. Проверка отчетов

• Отчет формируется под обычным пользователем.
• Проверены основные варианты настроек.
• Проверены отборы, группировки и периоды.
• Результат сравнен с ожидаемыми данными.
• Проверено, что права пользователя не ломают результат.

6. Проверка обработок

• Обработка запускается на тестовой базе.
• Проверены пустые данные и некорректные данные.
• Есть понятное сообщение об ошибке.
• Нет записи лишних данных, если обработка должна быть диагностической.
• Проверено повторное выполнение обработки.

7. Проверка обменов и регламентных заданий

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

8. Проверка зависимостей

• Понятно, какие объекты метаданных затронуты.
• Проверены связанные доработки.
• Проверено влияние расширений.
• Проверены общие модули и подписки на события.
• Проверено, нет ли пересечения с задачами из того же релиза.

 

 

Роль постановки, критериев приемки и тестовой базы

Многие пострелизные ошибки рождаются не в момент написания кода. Они рождаются раньше — в задаче.

Например, в постановке написано: «Добавить проверку при записи документа». Разработчик добавил проверку. На тесте создали новый документ, записали, все хорошо. После релиза пользователь открывает старый документ, пытается записать, получает ошибку. Потому что для старых документов новый реквизит не заполнен.

Кто виноват?

Формально можно спорить долго. Аналитик не описал старые документы. Разработчик не подумал. Тестировщик не проверил. Пользователь работает не по «идеальному» сценарию.

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

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

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

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

Тестовая база не обязана быть идеальной копией продуктива. Но она должна позволять проверить реальные сценарии, а не только красивый демонстрационный путь.

 

Типовые ошибки команды при разборе инцидентов

Ошибка 1. Исправить и забыть

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

Почему? Потому что исправили код, но не исправили процесс.

Ошибка 2. Проверять только счастливый путь

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

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

Ошибка 3. Не проверять права

Права в 1С — отдельный источник сюрпризов.

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

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

Ошибка 4. Не учитывать старые доработки

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

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

Ошибка 5. Разбирать инцидент только технически

Технический разбор отвечает на вопрос: где была ошибка.

Процессный разбор отвечает на вопрос: почему она дошла до релиза.

Для тимлида второй вопрос важнее. Иначе команда будет героически тушить пожары, но не будет уменьшать их количество.

 

Что фиксировать после найденной ошибки

После инцидента стоит фиксировать не роман на десять страниц, а короткие практические выводы.

Например:

• какой был симптом;
• какая была реальная причина;
• какой объект 1С оказался затронут;
• почему ошибка не была поймана до релиза;
• что добавили в чек-лист;
• какой сценарий нужно проверять в похожих задачах;
• нужен ли автотест или достаточно ручной проверки;
• нужно ли обновить шаблон постановки или критерии приемки.

Если ошибка была в правах — добавить пункт проверки ролей.

Если ошибка была в старых документах — добавить проверку старых данных.

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

Если ошибка была в отчете — добавить проверку под рабочей ролью и с пользовательскими вариантами.

Если ошибка была из-за неучтенной доработки — добавить проверку связанных объектов.

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

 

 

Небольшой шаблон разбора пострелизной ошибки

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

 

Блок	Что фиксируем
Симптом	Что увидел пользователь: ошибка записи, нет строки в отчете, пропала кнопка, упал обмен
Контекст	Пользователь, роль, база, объект, сценарий, дата релиза
Воспроизведение	Какими шагами ошибка повторяется
Причина в 1С	Форма, модуль, запрос, роль, регистр, обмен, регламентное задание, расширение
Решение	Исправление, обходной путь или откат
Почему не поймали раньше	Не было сценария, не проверили права, тестовая база не содержала данных, спешили
Профилактика	Что добавить в чек-лист, автотест, шаблон задачи или критерии приемки

 

Где здесь место автотестам

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

Не нужно пытаться покрыть автотестами все подряд, особенно если команда только начинает выстраивать процесс. Но для повторяющихся критичных сценариев автотесты могут сильно помочь.

Например:

• запись и проведение ключевых документов;
• проверка заполнения обязательных реквизитов;
• формирование важных отчетов;
• проверка базовых прав доступа;
• обработка типовых входящих данных в обмене;
• запуск критичных обработок на тестовом наборе данных.

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

Главное — не превращать разговор об автотестах в красивую декларацию. Лучше один реально работающий тест на критичный документ, чем большой документ «когда-нибудь надо покрыть автотестами всю конфигурацию».

 

Что важно именно для тимлида и руководителя

Разработчик часто смотрит на ошибку через код. Это нормально. Ему нужно найти место, где падает, и исправить.

Тимлид и руководитель должны смотреть шире.

Их задача — не просто спросить «когда починишь?», а организовать нормальный разбор:

• быстро понять критичность;
• убрать лишнюю суету;
• помочь команде сфокусироваться на причине;
• принять решение по исправлению или откату;
• не дать разбору превратиться в поиск виноватого;
• зафиксировать выводы после восстановления работы;
• обновить процесс проверки.

Если руководитель сам начинает с вопроса «кто сломал?», команда считывает сигнал. Дальше люди будут не разбирать проблему, а защищаться.

Если руководитель начинает с вопроса «что именно произошло и как воспроизвести?», тон разговора становится другим. Более взрослым.

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

 

Мини-чек-лист для разбора ошибки после релиза

1. Зафиксировать точный симптом, а не общую фразу «1С не работает».
2. Понять, у кого ошибка: один пользователь, роль, подразделение, все пользователи.
3. Воспроизвести ошибку в том же сценарии.
4. Сравнить с тем, что изменилось в релизе.
5. Проверить формы, модули, запросы, роли, регистры, расширения и фоновые задания, если они связаны со сценарием.
6. Оценить критичность: можно работать дальше, нужен обходной путь, исправление или откат.
7. После восстановления работы разобрать, почему ошибка прошла проверку.
8. Добавить конкретный пункт в чек-лист релиза.
9. При необходимости добавить автотест или обязательную ручную проверку.
10. Зафиксировать вывод в задаче или базе знаний.

 

 

Вывод

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

Вопрос в другом: что команда делает после ошибки.

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

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

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

Но ошибка — это не только проблема. Это еще и диагностический сигнал.

Она показывает, где процесс дал слабину: в постановке, критериях приемки, тестовой базе, проверке прав, контроле зависимостей, регламенте релиза или коммуникации внутри команды.

И если этот сигнал правильно разобрать, следующий релиз станет немного спокойнее.

А для 1С-команды это уже хороший результат.