Меня зовут Андрей Хватов, я работаю тестировщиком в компании «Контур» и отвечаю за качество продукта под названием «Контур.Меркурий». Впервые с 1С я познакомился в 2007 году, когда на первом курсе университета устроился в компанию – франчайзи 1С. С тех пор прошло 17 лет, а я все еще здесь.
Чтобы определиться с идеей для этой статьи, я отправился на infostart.ru. Начал искать, какие темы сейчас в тренде, какие статьи собирают больше всего лайков, какие обработки – больше всего стартмани. И тут меня посетил вьетнамский флэшбэк 2007 года: оказывается, функция, реализующая паузу, до сих пор в трендах. О ней пишут, комментируют, ставят лайки.
Пауза в одну секунду
Я стал изучать примеры кода, чтобы понять, что внутри этих обработок. И заметил закономерность: во многих шаблонах пауза по умолчанию установлена ровно на одну секунду. Тут я задал себе вопрос: а почему именно одна секунда? Это вообще норма? Что вообще считается нормой в таких случаях? Я – тестировщик, поэтому не знаю. Пришлось обратиться к коллегам – специалистам по UX и UI-исследованиям. Пообщался с ними и выписал ключевые тезисы.
В целом, да – одна секунда считается нормой. Если система отвечает на действия пользователя дольше одной секунды, он начинает нервничать, топать ногами. А еще хуже – теряет контекст, забывает, зачем вообще нажимал на эту кнопку. Поэтому задержка свыше одной секунды – повод задуматься об оптимизации кода.
Особенности десктопного приложения 1С
Все это, безусловно, работает и для мобильных, и для веб-приложений. Но у нас с вами – 1С, десктопное приложение. И не у всех есть мощные серверы, кластеры или ноды. У кого-то база просто развернута в локальной сети. Соответственно, картина здесь может быть совсем другой. Поэтому важно отметить два важных «но».
Первое «но». Задержка системы на действия пользователя не обязательно должна укладываться ровно в одну секунду. Для разных операций норма ожидания может быть разной. Она может быть прописана в техническом задании, а может – не быть прописана вовсе. Иногда пользователь вполне спокойно ждет 3–5 секунд на выполнение тяжелой операции – и это нормально.
Второе «но». Если какая-то операция выполняется быстрее, чем за секунду – это вовсе не значит, что все в порядке. Давайте поиграем в игру. Перед вами два столбика. В левом – операции, которые длятся одну секунду (в рамках условной виртуальной организации). В правом столбике – операции, занимающие 20 секунд. Начнем с левого: все ли здесь в порядке, или есть операции, которые за одну секунду выполняться не должны? Например, закрытие месяца за секунду – это нормально?
Слишком быстрое выполнение – сигнал для проверки
Нет, закрытие месяца за одну секунду – это не норма. Напомню: я говорил про контекст и два «но». Когда операция выполняется слишком быстро – это тоже повод насторожиться. Например, у нас есть автотесты в Vanessa: я нажимаю кнопку и ожидаю открытия окна в течение 300 секунд. Если окно откроется через секунду – тест пройдет, будет зеленым. Но это не означает, что все отработало корректно. Автотест пропустит это, потому что окно открылось с нужным заголовком. А вот то, что оно открылось подозрительно быстро – тест не проверяет. Вручную тоже не факт, что тестировщик заметит такую аномалию. Теперь давайте посмотрим на правый столбик – операции по 20 секунд. Все ли здесь нормально, или что-то вызывает сомнения? Вы заметили, что отправка уведомления в ФНС есть и в первом, и во втором столбике? Все зависит от контекста.
Время выполнения зависит от внешних факторов
Когда мы отправляем уведомление об оплате или начислении НДФЛ для одного сотрудника за вторую половину месяца – нормально, если оно уйдет за одну секунду. И так же нормально, если оно уйдет за 20 секунд. Потому что здесь не все зависит от нас и от нашей 1С. Есть еще сервера ФНС, время отклика, сетевая задержка – все это влияет на скорость. Поэтому в этих двух случаях и то, и другое можно считать допустимым.
А что же тогда не норма? Открытие формы элемента справочника за 20 секунд. Такого быть не должно.
Важность контроля производительности кода
Что из этого следует? Если мы говорим о качестве кода и о том, что тестировщики должны следить за этим качеством, то помимо привычных и очевидных вещей – корректности, функциональности – важно еще и контролировать производительность. Причем не только следить, чтобы операции не выполнялись слишком медленно, но и обращать внимание, если они выполняются подозрительно быстро.
Производительность – это не просто «быстро или медленно». Это – в пределах ожидаемого.
Особенности производительности в 1С
В 1С это особенно важно, потому что одна и та же конфигурация – та же бухгалтерия – может работать по-разному: на сервере 1С:Предприятие или просто в локальной сети. И один и тот же код у разных клиентов будет выполняться с разной скоростью – в зависимости от железа, объема данных, настроек. Поэтому универсальных норм быть не может. Нужно учитывать контекст.
Конкурентные преимущества через производительность
В «Контуре» мы разрабатываем интеграционные решения для 1С. У нас есть конкуренты, у нас разные клиенты. Чтобы оставаться конкурентоспособными, нам важно не только делать удобные и функциональные интерфейсы, но и не забывать о производительности. Быстродействие – это тоже часть пользовательского опыта. И тоже наше преимущество.
Расскажу, как мы начали тестировать производительность в «Контур.Меркурий». Но сначала – пара слов о том, что это за продукт. Это интеграционное решение, которое работает с любой конфигурацией на «восьмерке»: это может быть «Бухгалтерия», «УНФ», «УТ», «УПП», «1С:Молокозавод» или любая самописная конфигурация.
Что делает «Контур.Меркурий»? Берет стандартные или нестандартные документы из 1С, и – немного магии – превращает их в ветеринарные сопроводительные документы. «Меркурий» – это федеральная система, которая обеспечивает прослеживаемость продукции животного происхождения.
Пример работы системы. Контроль и безопасность
Например, на свиноферме родилась свинка Пеппа. Через полгода свинка Пеппа стала котлетой и пельменями. Все этапы ее «жизненного пути» – взросление, перевозка с одной фермы на другую, разделка, переработка – по законодательству должны фиксироваться в системе «Меркурий» в виде ветеринарно-сопроводительных документов.
Зачем это нужно? Представьте: кто-то отравился пельменями. У Россельхознадзора должна быть возможность «размотать» цепочку в обратную сторону – от пельменей до самой свинки Пеппы – и приехать на ту ферму, где, возможно, что-то пошло не так.
Но при этом мы не хотим перекладывать всю эту нагрузку на пользователей. Это ведь лишняя работа. Да и не все ветврачи в 1С умеют работать с системой, как и не всем менеджерам хочется вручную отправлять кучу справок в Россельхознадзор.
Автоматизация процессов через фоновые задания
Поэтому у нас все сделано максимально автоматически. Если нет ошибок, если данные корректно конвертируются – система сама все отправит. Например, если нужно указать номер машины и прицепа при перевозке свиней, коров или пачек пельменей – и эта информация уже есть в 1С – наша интеграция возьмет ее и отправит документы в «Меркурий» без участия человека.
Если же что-то пошло не так – например, не хватает данных или возникла ошибка конвертации – система сохранит черновик. Оператор сможет вручную доработать документ и отправить его.
И это очень удобно. Более двух тысяч организаций используют наше решение. Среди них – крупные свинокомплексы, молочные заводы, торговые сети, дистрибьюторы, оптовики, мелкая розница и даже компании в сфере электронной коммерции. У всех разные конфигурации, разное «железо», разные объемы данных. Но при этом все используют один и тот же наш код. И когда что-то работает не так, как ожидалось, пользователи обращаются в техподдержку.
Статистика обращений по поводу производительности
Когда я готовил эту статью, я попросил коллег из техподдержки прислать статистику обращений, связанных с жалобами на медленную работу. Вспомнил свои времена – как в 2007-м ходил с дисками ИТС, обновлял бухгалтерию, а потом какая-нибудь бухгалтерша звонила и говорила: «После вашего мальчика у меня все стало медленно работать!»
Так что я попросил выгрузить именно такие обращения – и мне их прислали. Результат вы видите на рисунке.
Должен признать: для 2000 пользователей 20–30 обращений в месяц – это почти ничего. Но дело в том, что даже если сегодня все работает отлично – это не гарантия, что завтра, после нового релиза, все останется так же быстро и стабильно.
Необходимость постоянного улучшения продукта
Мы живем в конкурентной среде. Наш продукт нужно постоянно дорабатывать, чтобы он оставался удобным и востребованным. Плюс меняется нормативка, обновляется сама система «Меркурий». Разработчики каждый день что-то пишут, кодят, я это тестирую – и наша задача не просто следить, чтобы после обновления модуля у клиента ничего не сломалось, но и чтобы система не стала работать медленнее.
Автотесты не всегда видят падение производительности. На примере с закрытием месяца мы убедились: стандартные автотесты не фиксируют замедление. Они проверяют, что операция выполнилась, а не то, как быстро она выполнилась. Чаще всего они просто не замечают, что стало медленнее. А для нас это критично: мы не можем позволить себе проседания по производительности.
И второй важный момент – нам нужно адекватно оценивать работу разработчиков. Есть грейды, переоценки, инструменты оценки. Но бывает так: приходишь на пересмотр и говоришь: «Я переписал запрос из пяти экранов – теперь он занимает полэкрана. Значит, я – синьор!»
Однако не факт, что короткий код работает быстрее. Запрос в полэкрана может быть медленнее, чем тот, что растягивался на три. Поэтому нужно не просто смотреть на объем изменений – нужно измерять результат. И было бы здорово, если бы все это происходило «само».
Как измерить производительность
Я уже упоминал, что наше интеграционное решение может работать как в одной базе с «Бухгалтерией» или УПП, так и как отдельная база с одной конфигурацией. В наш CI мы добавили отдельную задачу (джобу), в которую поместили выделенную базу. Туда развернули актуальную версию нашего модуля и наполнили ее «тяжелыми» документами – по 500–1000 позиций номенклатуры в каждом.
Цель – сделать так, чтобы все работало очень и очень медленно. Именно в таких условиях проще всего оценить, улучшилась ли производительность после оптимизации.
Создание контролируемой среды. Мы добавили технические ограничения для контейнера: выделили ему минимальный объем оперативной памяти. Потому что на «тяжелой» системе, где все и так медленно работает, проще оценить, улучшилась ли производительность после оптимизации. Чем больше исходное время – тем заметнее снижение.
Мы наполнили базу документами, специально «нагрузили» ее – чтобы все работало медленно и предсказуемо.
Изоляция среды тестирования. Затем упаковали все в Docker-образ и «изолировали по полной»: никаких кэшей, никакой синхронизации с «Меркурием», с 1С, с интернетом – вообще ничего лишнего. Хотелось получить что-то вроде «сферического коня в вакууме» – чистую, контролируемую среду, где на результат влияет только наш код.
И в таком состоянии мы начали работать. Причем кодить пришлось совсем немного.
Минимальные изменения в коде. Даже тестировщик со средним опытом, который умеет не только писать в Vanessa, но и заглядывает в конфигуратор, справится с этим. Объем кода, который нужно было добавить, – минимальный.
Примерно столько, сколько вы видите на рисунке, но в два раза больше. Две ключевые функции: одна запускает замер времени, вторая – останавливает и отправляет метрику на сервер статистики.
Гибкая система замеров через расширение. Но возникла еще одна задача: система меняется, и нам нужно быть гибкими. Мы хотели сделать так, чтобы замеры можно было легко настраивать – не только для текущих критичных документов, но и для новых в будущем. И чтобы этим опытом можно было поделиться с другими командами в «Контуре» без лишних усилий.
Мы решили эту задачу с помощью расширения. Не стали править основную «коробку» – ту версию, которую получают клиенты. Вместо этого создали небольшое расширение: написали общий модуль, который отвечает за снятие замеров и отправку метрик.
В это расширение мы вставляем вызовы ровно в те места – документы, обработки, – которые считаем критичными по производительности. То есть в тех местах, где операции особенно тяжелые и где медленная работа может «подбешивать» клиента. И все, что нужно – буквально три строчки кода в расширении. Это минимальные трудозатраты.
И, конечно, как положено ленивому тестировщику, я написал автотест, который создает черновик документа оформления ВСД.
Процесс замера производительности. Как только тест нажимает кнопку «Создать», подключается наше расширение, которое вызывает общий модуль и запускает замер. Пока внутри происходит вся магия – конвертация, сопоставление данных, подбор номера машины, фамилии ветврача, нужной свинки или пачки пельменей – все это время фиксируется. Как только операция завершается, замер останавливается, и метрика отправляется на сервер статистики.
Тестирование тестирования производительности
Мы создали отдельную ветку и начали тестировать. Да, тестирование производительности тоже нужно было протестировать. Мы сосредоточились на трех самых тяжелых документах: отгрузка, производство – когда из свинки Пеппы через пять переделов получаются пельмени – и инвентаризация.
Это самые ресурсоемкие операции, потому что там активно идет подбор партий. А в «Меркурии» партии – это важно: каждая пачка пельменей принадлежит своей партии. Даже если одна пачка изготовлена сегодня, а другая – завтра, это уже разные партии.
Создание тяжелой тестовой ситуации. У нас огромное количество клиентов – и у всех все настроено по-разному. Поэтому мы специально создали максимально «тяжелую» с точки зрения производительности ситуацию.
В итоге документы у нас открывались в среднем по 80 секунд. А вот этот всплеск в начале графика – это я, как тестировщик, «протестировал тестирование».
Проверка стабильности измерений. Я специально добавил в образ еще пару сотен документов по паре сотен строк, чтобы проверить: действительно ли система корректно считает время? И действительно ли внешние факторы не влияют на замеры?
В течение месяца мы запускали одну и ту же ветку без изменений в коде с целью убедиться, что на результат не влияют посторонние факторы. У нас каждый раз разворачивается один и тот же Docker-образ, с одинаковым кодом, один и тот же автотест без кэшей нажимает одну и ту же кнопку «Создать документ».
И все сработало. На графике видно: отклонения от среднего значения в 80 секунд были, но в пределах 2–3%. Это просто статистическая погрешность. Значит, замеры стабильны и достоверны.
Оптимизация кода
Мы поняли: система работает. Теперь разработчики взялись за оптимизацию – тяжелых запросов, конвертаций, подбора данных. И мы пришли к вот такому результату.
Те же операции, те же документы, те же метаданные. Изменился только наш интеграционный код – и время выполнения сократилось в четыре раза.
Не у всех клиентов работа стала быстрее. Кто-то, возможно, вообще не заметил изменений. У кого-то разница была минимальной. Но я знаю одного клиента, у которого буквально миллион ветеринарных документов. Так вот, он явно почувствовал, что стало быстрее.
В итоге мы определили актуальное время выполнения этих операций – 23 секунды.
Автоматическая проверка границ производительности
Я добавил в автотест, который показывал ранее, проверку: если операция выполняется дольше 23 секунд или, наоборот, быстрее 20–21 секунды – тест падает и становится красным.
Если все в пределах нормы – тест проходит, остается зеленым. Это значит, что система работает стабильно: ни слишком медленно, ни подозрительно быстро.
А если вдруг стало быстрее – мы с разработчиком садимся вместе: «Ну-ка, расскажи, что ты там написал? Почему вдруг все ускорилось?» Такие аномалии тоже требуют внимания.
Все это можно оперативно отслеживать в Redash.
На этом скриншоте – день, когда я готовил статью. Внизу видны названия веток. Каждый коммит запускает автотесты, включая замер производительности. Видно, что когда разработчики не трогают критичные участки кода – а большинство, как вы можете заметить, их и не трогали – график остается ровным и не выходит за границы нашей нормы.
Если вдруг график резко скачет – падает автотест. И в отчетах Redash мы сразу видим: на какой ветке, каким коммитом была вызвана ситуация, когда производительность упала или, наоборот, резко взлетела. Это позволяет быстро реагировать, находить причину и, при необходимости, вносить корректировки.
Не забывайте тестировать производительность
Если вы работаете над бизнес-решениями, конкурентными продуктами или внутренними разработками – не забывайте тестировать производительность. Как вы убедились, начать это делать – очень просто. Даже минимальными усилиями можно внедрить систему, которая будет следить за тем, чтобы код не тормозил и не работал слишком быстро.
Для реализации такого решения не потребовалось ничего сверхъестественного. Нужны базовые знания языка 1С и минимальные навыки работы с Vanessa Automation – и все уже можно настроить.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт
