Появление новых паттернов работы 1С:Эксперта
Под искусственным интеллектом я в первую очередь буду понимать LLM-модели. Почему так – станет понятно по ходу статьи.
Примерно в середине или конце прошлого года стало понятно, что у нас появляются новые паттерны работы 1С:Эксперта, которые дешевле и эффективнее того, что было раньше.
Первый – прямое использование искусственного интеллекта как помощника эксперта. Второй – разработка инструментов, опять же с помощью LLM-моделей. Об этих двух больших группах инструментов я и расскажу: как они уже реально работают, с чем мы сталкиваемся, что работает, а что – нет.
Сразу уточню для тех, кто привык к базам объемом сто терабайт и к большим постоянным командам, которые эти базы поддерживают. Поскольку я работаю в консалтинге, специфика моей работы несколько другая. Возможно, задачи, о которых я буду говорить, будут не очень близки людям, работающим в инхаусе.
Жизнь в консалтинге выглядит так, как показано на рисунке: ты один на проекте, у тебя нет установленных инструментов и ничего нельзя быстро поставить. Конфигурация может оказаться какой-нибудь отраслевой, которую ты видишь впервые в жизни. Сегодня один проект, завтра другой.
Первый пункт с рисунка – то, что человек оказывается один на один с заказчиком – уже не всегда имеет место, предпринимаются усилия, чтобы это минимизировать. Все остальное – ноль установленных инструментов, невозможность быстро что-то поставить, незнакомые конфигурации, постоянная смена проектов – это реальная жизнь.
Почему так происходит? Есть два основных случая.
Первый: мы заходим на проект, где только начинается импортозамещение, а команда технической поддержки со стороны заказчика еще не выстроена. Она появится через девять месяцев, но сейчас ее нет.
Второй случай – есть заказчики, у которых на самом деле система работает в хайлоад-режиме, но нет времени и ресурсов ею с этой точки зрения заниматься.
И в том, и в другом случае возникает описанная ситуация. Поэтому мои инструменты и подходы рассчитаны на такую жизнь.
Прямое использование ИИ
Основные принципы:
-
доверяй, но проверяй,
-
используй LLM для проверки себя самого и других LLM.
Главный принцип, которым всегда можно и нужно руководствоваться: если сам не можешь проверить LLM-модель, попроси другую LLM-модель проверить результат. Потому что результаты бывают разные.
На курсах «Основы ремесла эксперта», которые я веду в учебном центре 1С, есть две большие группы слушателей. Первая группа приходит из администраторов, вторая – из 1С-разработчиков.
Группа из 1С-разработчиков обычно очень плохо знает Linux bash, практически не знает, и для нее теперь есть хорошая новость: все это тоже можно использовать, и не нужно долго искать в интернете и собирать скрипты по частям. Универсальные LLM-модели более-менее хорошо знают Linux bash. И прекрасно пишут простые короткие скрипты, примеры на рисунке.
С помощью таких простых запросов мы можем получать нужные результаты (то есть скрипты) и находить ошибки в имеющихся скриптах. Например, берем скрипт с ИТС, копируем, запускаем – он не работает. А, скажем, длинное тире при копировании – это отдельная боль.
В одном таком скрипте было намеренно внесено три ошибки. Спрашиваем LLМ: «Где здесь ошибка?». Проверка показала, что Gemini 3.0 нашла все три, а DeepSeek – только одну: неправильную кавычку. Gemini заметила даже то, что в регулярном выражении отсутствует точка.
Качество ответов очень разное. Понятно, что LLM-модели неустойчивы и в разных чатах результаты будут отличаться, но индикативно картина выглядит именно так. Поэтому все равно нужно перепроверять.
Далее на рисунке приведен пример алгоритма разбора графа взаимной блокировки с помощью LLM.
Публичные LLM имеют ограничения по размеру файлов, которые в них можно загрузить через веб-интерфейс их чата. Но раз теперь мы умеем работать с Linux bash, то мы можем подготовить файл, вырезав из него фрагмент нужного размера, чтобы LLM-модель смогла его обработать. Например, можно написать скрипт, который подготовит файл для расследования взаимной блокировки, а затем отдать его на анализ.
Поскольку генезис взаимных блокировок в 1С и в СУБД примерно одинаковый, если не говорить о пространстве блокировок, LLM-модель очень хорошо строит граф взаимной блокировки даже по небольшому файлу. Она определяет, кто виновник, кто жертва и почему возникла блокировка: ресурсы захватываются в разном порядке, повышается уровень изолированности ресурса или происходит что-то другое.
В ситуации, когда вы находитесь в командировке и нужно быстро ответить на вопрос: «Почему так произошло?», а под рукой вообще ничего нет, этот способ действительно разгружает вас.
Далее показан алгоритм разбора таймаута. Как сказано на рисунке, это сложнее.
Если сделать такую же вещь для разбора таймаута, окажется, что все немного хуже. Чтобы построить граф взаимной блокировки, не нужно лезть в код. А чтобы понять, почему возник таймаут, во-первых, уже нужно смотреть код, а во-вторых, далеко не все LLM-модели знают о пространстве блокировок 1С и о том, как блокируются незаданные измерения.
Например, в моем случае Gemini, DeepSeek и Qwen этого не знали, а Sonnet уже знал. Это тоже только индикативный результат: возможно, в другом чате они бы ответили правильно, но у меня получилось именно так.
На следующем рисунке – попытки анализа неоптимальных запросов.
Здесь нужна фильтрация по длительным запросам. Писать подробный промпт необязательно: любой непонятный фрагмент можно вырезать, вставить в LLM-модель и попросить объяснить, что он делает.
Можно взять плохой запрос, скопировать его и сразу вставить в DeepSeek. При этом обезличивать обычно ничего не требуется, потому что в самом тексте запроса нет чувствительных данных. По большому счету, такой подход позволяет проверить себя: не пропустил ли я что-то интересное? В моем случае одну вещь я действительно пропустил.
Но дальше выясняется, что в выводах, которые LLM-модель делает по тексту запроса, есть рациональное зерно, а есть много мусора.
Во-первых, она предлагает очень многое индексировать, и, как правило, эти рекомендации не работают. Если речь идет о совсем грубых ошибках, когда про индексы вообще забыли, тогда эти рекомендации могли бы помочь. Но обычно – нет.
Во-вторых, применимость рекомендации тоже остается под вопросом. Пока неизвестно, что это за запрос: платформенный, запрос из компоновки виртуальной таблицы или запрос, доступный в коде. А если он доступен в коде, поможет ли изменение, которое предлагает LLM-модель, – тоже вопрос.
Для этого нужно брать изолированный тестовый контур и все проверять. Только проверенный результат можно отдавать заказчику. Сырые данные от LLM-модели заказчику отдавать ни в коем случае нельзя. Но как инструмент самоконтроля и самопроверки – это хорошая вещь.
Где LLM-модель проявила себя действительно хорошо, так это в анализе неочевидных взаимосвязей, см. следующий рисунок.
Если нет ни Prometheus, ни Grafana, на Linux-площадках мы включаем atop и пользуемся им так, как описано, например, на сайте РЕД ОС. У atop есть встроенная утилита atopsar, которая позволяет получать текстовые логи в хорошо читаемом виде без дополнительного парсинга.
Можно просто выделить нужный фрагмент и отдать его LLM-модели. Такие неочевидные двухходовые случаи, как на рисунке – она видит. Человек может их проглядеть. Загрузка процессора находится в пределах нормы – маркер у человека не сработал. Загрузка памяти составляет 90%, но тоже остается в допустимом диапазоне – маркер снова не сработал. LLM-модель помогает такие вещи не пропускать.
То, чем LLM-модель может помочь в первую очередь как самостоятельный инструмент, – это проверять за вами и проверять саму себя. При этом за ней тоже нужно проверять.
Прирост скорости и экономия когнитивных ресурсов все равно есть. Но это не самый эффективный способ. Мы говорим о хайлоаде, и при таком подходе LLM-модель сама становится узким местом нашей организационной и технологической цепочки. Поэтому эффективнее использовать ее для создания новых инструментов.
Следующий раздел – LLM как изготовитель инструментов.
Скрипты для построения графиков по данным atopsar
Первая задача – включить в отчет по нагрузочному тестированию данные о загрузке оборудования по данным atop на неподготовленной площадке, где есть только голый Linux.
LLM-модель прекрасно с этим справляется. Как кто-то сказал: «Если она не может написать скрипт на Python, то она неисправна». По моим ощущениям, это действительно так: скрипты на Python модели пишут хорошо, причем на Python более-менее хорошо пишут и дешевые LLM-модели. Код на 1С хорошо пишут далеко не все. Я лично пользуюсь Gemini 3.0. Но сейчас речь не о 1С, а о Python.
Мы передаем модели файл atopsar, который получили. Естественно, перед этим обезличиваем его и удаляем информацию о серверах. Структуру файла модель понимает не сразу, поэтому ее приходится объяснять, а затем давать команду: «Построй график». В этом случае модель скорее всего напишет скрипт, даже если вы ее явно об этом не просили (а лучше бы сразу попросить явно). На рисунке показаны результаты работы написанного LLM кода.
Главное – не перегенерировать каждый скрипт с нуля. Иначе может оказаться, что разные изображения совсем не похожи друг на друга: модель просто возьмет другую библиотеку. В результате вставить в отчет изображения, сделанные по разным шаблонам, будет можно, но выглядеть это будет некрасиво.
У меня выработался подход, при котором скрипты используются как промты. Не нужно заниматься сложной промт-инженерией и объяснять, кто какую роль выполняет. Я беру готовый код и говорю: «Сделай то же самое по такому же шаблону». Тогда изображения получаются похожими друг на друга. Это сильно экономит ресурсы. Не нужно самому становиться новым узким местом процесса и превращаться в промт-инженера.
Дальше на эту же тему можно экспериментировать. Например, можно анализировать любимую в 1С ситуацию, когда из 36 ядер одно работает, а остальные стоят.
Красный график наверху на рисунке выше показывает загрузку одного ядра. Синий график чуть ниже – среднюю загрузку ядер. Она находится примерно на уровне 5–8%. Фиолетовый график показывает количество ядер с загрузкой более 20%: в основном одно, иногда два, совсем редко три или четыре.
Нижний график показывает номер ядра с загрузкой более 20%. На нем видно, что система может по 40 минут оставаться на одном и том же ядре. Затем она перепрыгивает с одного ядра на другое, но работа все равно ведется в основном в один поток.
Когда это полезно? Например, мы получили такую картину, затем поменяли настройку параллельности, допустим при закрытии месяца, и проверили, изменился ли нижний график.
Честно говоря, без LLM-модели я бы такую вещь не сделал. А с ней получился полезный инструмент.
Скрипты для поиска стеков плохих запросов и для их визуализации
Следующий инструмент, также написанный LLM-моделью на Python, – анализатор горячих строк. Алгоритм всего анализа показан на рисунке.
Прикладной смысл следующий. У нас есть плохой запрос, который выполняется тысячу раз. При этом 300 раз он вызывается из одного места, 200 раз – из другого. У него могут быть разные входные параметры и даже немного отличаться текст запроса.
Нужно понять, какие пути приводят к его плохой работе, а какие можно проигнорировать.
Здесь у меня был вариант пойти по пути создания MCP-сервера. Но я сделал иначе: выгрузил конфигурацию в файлы. Затем с помощью LLM-модели на Python был написан парсер, который прошелся по pff, проиндексировал строки, определил, где начинаются и заканчиваются процедуры, и выгрузил результат в JSON.
Как оказалось, JSON – наилучшая структура для работы с LLM-моделью. Все остальные форматы ей время от времени приходится дополнительно объяснять, а JSON они как-то сразу понимают.
Дальше мы разбили работу на несколько участков, а контрактом между ними объявили JSON-файл. В результате без использования MCP-сервера тоже получили работающую аналитическую модель.
В чем преимущество этой технологии перед MCP-сервером? Ее можно использовать на площадке, где MCP-сервер развернуть невозможно.
Я в самом начале говорил, что работаю в том числе в контурах, где вообще ничего нет. Согласование чего-либо занимает месяцы, а разбираться с проблемами нужно за несколько дней, максимум за неделю.
Как выглядит визуализация такого запроса с помощью библиотеки Graphviz, показано на следующем рисунке. Красным справа обозначен плохой запрос, а к нему ведут по-разному раскрашенные стеки.
Сразу видно, что одни пути начинаются с одного участка, а дальше разделяются. Где-то накопленное время составляет 0%, где-то – 6–7% по замеру в отладчике. Затем пути снова сходятся в одной общей точке.
После этого можно понять, какие пути нам интересны. Где накоплено 7%, вероятно, разбираться интереснее. Где 0% – скорее всего, совсем неинтересно.
«Неинвазивная» «консультант-френдли» оснастка
Все предыдущие инструменты были сделаны достаточно быстро. Следующий инструмент потребовал уже полноценной разработки.
Здесь важно объяснить, почему мы вообще сознательно переходим к скриптам, помимо решения самой LLM их создать, как было в случае с графиками. LLM-модели не умеют считать. Арифметика для LLM – это боль. Если попросить LLM-модель сложить сто чисел, она выдаст результат, похожий на правду, но почти никогда это не будет точно посчитанное число. В том числе поэтому приходится отказываться от прямого использования LLM-моделей. Есть еще и ограничения, связанные с логикой.
Идея использовать LLM как внешнего неинвазивного тестировщика в том числе на нагрузочных тестах родилась из следующего.
Станислав Косолапов писал в своей статье, что LLM-модель умеет нажимать кнопки в браузере. Я спросил его:
«Она умеет делать это в нескольких браузерах?»
Он ответил:
«Да».
Я попробовал – действительно умеет.
Тогда появилась идея объединить Vanessa Automation с «Тест-центром» в одну общую оснастку. Это давало бы ряд концептуальных преимуществ, см. рисунок.
С одной стороны, новая оснастка должна иметь возможность проводить нагрузочные тесты. Vanessa Automation тоже это умеет, но в очень ограниченном объеме и в этом плане остается достаточно хрупкой.
С другой стороны, по сравнению с «Тест-центром» новая оснастка должна быть неинвазивной.
Работе с «Тест-центром» можно научить даже начинающего разработчика, если правильно все объяснить и поставить задачу. Но там все равно требуется много встраиваний.
Если нам нужно не провести разовый нагрузочный тест, а оставить решение заказчику на поддержку, то каждое обновление и встраивание форм может ломать сценарии нагрузочного теста. Даже если все добавлено через расширение, где-то поменялась форма, где-то иначе заработала интеграция – и все ломается.
Это требует постоянного присутствия разработчика, которого мы только что обучили. Если приходит другой разработчик, его снова нужно учить. Теоретически новый подход позволял избавиться от этой проблемы.
Появились и дополнительные преимущества. Абстракция получилась проще, чем Gherkin. Можно передавать данные от одного пользователя другому. Кроме того, у Playwright есть headless-режим: браузеры могут полноценно работать, не отрисовываясь на экране. Таким образом мы экономим ресурсы оконного интерфейса при работе с веб-клиентом.
Фрагмент сценария может выглядеть как обычная табличная часть справочника 1С, как показано на рисунке ниже:
Фрагмент в данном случае включает в себя следующие действия: «Нажать “Выбрать к производству”, нажать “Организация”, выбрать производство, нажать Ctrl+Alt+F, перейти на следующую панель, нажать Ctrl+Enter, провести документ».
К слову, нажатие клавиш работает устойчивее, чем клик по ID. Кроме того, для клика по ID нужен тестировщик, который понимает, что такое ID и напишет себе сценарий исходя из этого понимания, но консультант, не занимающийся профессионально сценарными тестами, так делать не станет.
Идея заключалась еще и в том, чтобы сделать оснастку удобной для консультанта и исключить разработчика из задачи написания и поддержки сценариев – как для нагрузочного, так и для сценарного и регрессионного тестирования. Разработчика предполагалось оставить только на генерации данных.
Но с генерацией данных LLM-модель нам тоже может помочь. Это следующий шаг.
Гибридная система тестирования 1С
В результате получилась следующая схема процесса.
С помощью глоссария или Playwright Codegen мы готовим данные. Playwright Codegen нужен в основном тогда, когда вы еще совсем не ориентируетесь в ID. Затем примерно 97% этих «кубиков Lego» закрываются с помощью глоссария.
После этого настраиваем сценарий в 1С.
Кастомная конфигурация одновременно выступает командным центром и хранилищем скриптов. Она никак не встраивается в исследуемую базу – это отдельная база, которая может быть опубликована даже на другом веб-сервере.
Дальше сценарии выполняются через Playwright. Все они запускаются в асинхронном режиме. Доступны синхронизация и оркестрация очереди сообщений. Все это пришлось написать.
И, конечно, никуда без APDEX и анализа логов.
Еще одна боль тестировщика – модальные окна, которые появляются во время проведения тестов. В этом случае мы просто делаем снимок экрана и идем дальше. Playwright это позволяет.
Не нужно переключаться между RDP-сеансами и смотреть, где конфликт блокировок завис в модальном окне. Не нужно ломать конфигурацию, создавая заглушку на вызов этого модального окна.
Как выглядит работающий тест на экране его оператора, показано на рисунке.
В работе теста участвуют четыре части.
Черное окно – Python-агент. По своей сути он похож на агента «Тест-центра», только сделан на Python и немного иначе устроен.
Большая левая часть – управляющая база, оркестратор и хранилище скриптов. Она взаимодействует с Python-агентом по HTTP.
Python-агент через Playwright в асинхронном режиме управляет заданным количеством веб-клиентов 1С. Он выполняет один из множества ролевых сценариев, которые консультант завел как описание рабочих процессов.
Оснастку можно использовать для сценарного и нагрузочного тестирования.
LLM-модель не только помогла написать весь код на Python, но и написала часть кода на 1С. Выгрузка в JSON – задача достаточно скучная, и Gemini хорошо написала этот код. С загрузкой из JSON она тоже прекрасно справилась.
Кроме того, модель подсказала ряд архитектурных решений: использование headless-режима, полную неинвазивность и еще несколько вещей, которые легли в основу решения.
Сейчас решение протестировано на 128 пользователях. Больше мощностей у меня просто не было. Оно работает.
Антипаттерны
Теперь о ложках дегтя. Их много.
Самая опасная ситуация – краш проекта за одну секунду. LLM-модель может написать так:
«Сейчас я быстро перестрою структуру всего проекта».
И если каталог со скриптами не сохранен простым копированием в другое место и нет резервной копии, может сломаться все. Восстановить происходившее после этого довольно сложно.
Ограничения
Если мы используем LLM-модели в работе, нужно понимать, что модель ведет себя как начитанный, но ленивый и бестолковый стажер. Все человеческие недостатки, представленные и в литературе, и в кинематографе, здесь тоже присутствуют: лень, переобувание на лету и многое другое.
Еще один важный момент: прототип, который показывает LLM-модель, может совсем не совпадать с тем, как система будет вести себя в реальной жизни.
Да, LLM-модель умеет нажимать кнопки в браузере. Но если поручить ей делать это самостоятельно, не написав существенную специализированную оснастку, она будет работать крайне неэффективно.
Она будет тратить огромное количество токенов и выполнять каждую операцию так, словно делает ее впервые. Кроме того, далеко не у каждого заказчика такое решение получится развернуть.
Реальность и прототип сильно различаются. Это пришлось осознать на примере построения оснастки для нагрузочного тестирования. Это один из основных выводов.
Руководитель проекта или задачи должен довести работу до конца. Как тракторист должен довести свой трактор до цели, используя его как инструмент, так и 1С:Эксперт должен довести систему до работоспособного состояния, используя LLM-модели, людей и все что угодно.
Все равно отвечает он. Цель, видение, разум для достижения цели и воля к ее достижению есть только у него. Именно он ведет весь процесс.
Рост личной эффективности и пределы масштабирования
Остается вопрос, сколько времени все это сэкономило.
В моем случае LLM-модель заменила примерно полтора программиста: одного программиста на Python и половину программиста на 1С. То есть личная эффективность повысилась примерно в два с половиной раза.
Но эта система не масштабируется. Оставшиеся полпрограммиста никто не заменит, потому что в этой части я одновременно программист, технический архитектор и функциональный архитектор.
Сильнее система уже не масштабируется.
Менеджеру, который говорит: «Я заменю всех программистов LLM-моделями», нужно понимать, что половину своего рабочего дня ему придется тратить на то, чтобы разбирать результаты их работы.
Без инженерного мышления и инженерного подхода никуда. И человек, и LLM-модель становятся узкими местами этой системы. Но личная эффективность действительно повышается.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
Вступайте в нашу телеграмм-группу Инфостарт