Замеры APDEX против "ощущений" бухгалтеров

24.04.20

База данных - HighLoad оптимизация

Очень часто пользователи недовольны, как работает информационная система. Но даже когда ИТ-специалисты все полностью меняют, пользователи остаются недовольными. О том, как объективно оценить проведенные изменения, на конференции Infostart Event 2019 Inception рассказал руководитель ИТ-службы ИООО «Лукойл Белоруссия» Роман Жульпо.

Предисловие

 

Коротко расскажу, чем занимается наша компания. Это, в первую очередь, сеть автозаправочных станций – 83 АЗС, несколько нефтебаз, газовые комплексы и обеспечение переработки нефти на белорусских НПЗ.

Основная платформа автоматизации – 1С, основные учетные функции реализованы в конфигурации «Управление производственным предприятием». Но сразу сделаю поправку – сами заправки работают на автономных кассовых решениях, с 1С не связанных. Это для понимания, почему мы могли или не могли делать определенные вещи.

Мой доклад о том, как мы трансформировали нашу информационную систему из состояния «А» в состояние «Б». Я не так давно работаю в компании – с конца 2017 года, и вместе со мной обновилась ИТ-команда. Поэтому на многие вопросы, например, почему информационная система находилась в состоянии «А», я не смогу ответить. Мы даже для себя выработали шутливый паттерн «исторически так сложилось». Я думаю, многие бывают в такой ситуации, когда у вас «исторически так сложилось»: что-то построено и работает не так, как вам хотелось бы, или это не удовлетворяет бизнес сегодня.

На предприятии работает 1 300 человек, из них около 350 – активные пользователи информационной системы, в частности системы УПП. И прямо в воздухе витала общая неудовлетворенность работой системы – УПП работала медленно и не очень стабильно. И хотя все это знали, почему-то очень длительный период ничего по этому поводу не предпринималось.

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

 

О системе

 

 

Я как математик по образованию люблю формализовать задачи, формулировать требования и то, что у нас есть. Поэтому первое, что мы сделали, – записали «Дано на август 2018 года»:

  • сильно кастомизированная УПП на платформе 8.1;
  • база данных в MS SQL 2008 размером 1.2 ТВ с ошибками логической целостности (CHECKDB не проходит);
  • сервер 1С и SQL на разных виртуальных машинах в кластере VmWare;
  • около 300 активных пользователей, которые постоянно работают в базе в режиме 12х7. Тут стоит оговориться, режим многих распределенных объектов 24х7, но мы договорились, что бизнес-критичное время – это 12 часов, с 7 утра до 7 вечера. В это время база должна работать стабильно, и мы не можем вмешиваться в работоспособность, если только не появились какие-то критические вещи;
  • 2 специалиста 1С – сильный разработчик и сильный аналитик-консультант. Эти ребята пришли в компанию вместе со мной, мы с ними работаем давно, поэтому в их компетентности я не сомневался и делал на них очень большую ставку.

Проблематика – все работает медленно и периодически падает. Это классическая проблема.

Одна из моих миссий, как ИТ-руководителя на предприятии, – это переводить бизнесу, из-за чего возникают трудности в ИТ и объяснять своим коллегам, что хочет бизнес, почему его не устраивают те или иные вещи.

Но иногда руководителям трудно объяснить, что происходит в ИТ, поэтому приходится импровизировать, придумывать какие-то аналогии. Мне в этом часто помогает визуализация.

 

 

Вот реальная картинка общего состояния нашей информационной системы в состоянии «А».

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

С этого и начинали.

 

 

Отдельно стоит отметить, что мы сначала построили, а потом уже сделали этот доклад. Поэтому какие-то вещи вносились уже постфактум.

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

Я могу предположить, что первые два пункта этого списка появились после работы с франчайзи или с внутренними ИТ-специалистами.

  • Первое, на что ссылались, – слишком большая база, поэтому все тормозит.
  • Второе – классический тезис – старые медленные сервера, их надо менять, поэтому все тормозит.
  • Особо негативно настроенные пользователи, люди, у которых сложился негативный опыт, говорили, что 1С не может работать быстро, нужно внедрять SAP. Сами понимаете, Лукойл – компания достаточно большая, и ресурсы позволяют. Поэтому было движение, подталкивающее к внедрению другой системы.

 

 

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

  • На первом этапе мы решали проблему железа и инфраструктуры;
  • На втором этапе разбирались с платформой;
  • На третьем – улучшали код;
  • И на четвертом этапе – меняли процессы.

 

Этап первый – железо

 

 

Поскольку свою карьеру в ИТ я начинал как системный администратор, мне на первом этапе было понятно, что архитектурная конфигурация работы 1С и SQL-сервера у нас была неправильной – начиная от виртуализации и заканчивая разнесением на разные машины.

Поэтому мы разобрали виртуальный кластер, выделили из него достаточно мощный физический сервер, на нем установили операционную систему, сервер 1С и SQL. Сделали все настройки по Best Practices – Shared Memory, разнесли лог и файлы базы данных по разным дискам, и т.п. Все, что можно было выжать из этого железа, сделали. И в принципе, больших просадок по производительности в мониторе ресурсов не было. Но отдельно скажу, что железо было старое, 2011 года, и SSD там не было. Поэтому в пике по очереди к дискам могли быть большие задержки.

Вторая проблема – это большая база данных и не очень хорошее ее состояние. Тут стоит отметить, что большая база данных при не очень хорошем железе и не очень современной инфраструктуре – это проблема не столько скорости, сколько неэффективности проведения с ней регламентных операций по времени. Сами представьте, бэкап базы в 1.2 ТВ занимает много времени, на не очень быстрых дисках еще больше времени, а если вам нужно что-то оперативно развернуть из бэкапа, это сразу потребует несколько часов. Плюс 1С-ники не любят работать с конфигурациями без данных, поэтому несколько тестовых баз в пару терабайтов – это тоже большая проблема. Не говоря уже про постоянное обновление этих баз.

Как мы это решили? Я прекрасно понимал, что самостоятельно с этой задачей мы не справимся, поэтому нужно искать специалистов. У меня были хорошие контакты с ребятами из команды gilev.ru – в 2015 году я у них учился на курсе по оптимизации производительности. Мы с ними пообщались, и они сказали, что возьмутся за решение нашей проблемы. Основной фактор, по которому мы выбрали именно этих ребят, – это фиксированная стоимость услуг и понимание уровня компетенций специалистов. У них на сайте есть прайс, где можно увидеть, сколько реально стоит та или иная операция. Когда мы пробовали обращаться или консультироваться с фирмами-франчайзи у нас на локальном рынке, нам сначала предлагали провести аудит за много денег и никто не мог назвать сразу ни конкретные сроки, ни сумму, ни то, что получится в результате. А Дмитрий Юхтимовский из команды gilev.ru достаточно быстро нам определил стоимость для ожидаемого результата.

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

Все прошло штатно. Но надо обметить, что обрезка базы почти никак не повлияла на производительность и скорость работы. Никак. Как оно работало, так и работало. Поэтому если у кого-то есть предположение, что ваша база работает медленно именно из-за большого объема, скорее всего, это не так. Скорее всего, проблема где-то в другом месте, надо искать узкие места.

Но были и два позитивных результата:

  • Первый – для меня было очень хорошо то, что база после обрезки начала проходить check database. То есть проблема была именно в тех данных, которые мы в конечном итоге отрезали, и головная боль, как вылечить базу, пропала.
  • Во-вторых, объем базы сократился примерно до 400 гигабайт. Это сильно упростило развертывание тестовых баз, сильно сократило время на регламенты и высвободило необходимые ресурсы.

Чтобы полностью завершить первый этап и развеять мифы о том, что все работает плохо из-за старых серверов 2011 года, мы в январе 2019 купили новые сервера. Там все сделали по рекомендациям ИТС или gilev.ru – SSD-диски, разделенные mdf- и lgf-файлы, много оперативной памяти и т.д.

 

 

Подытожу первый этап:

  • После того, как мы переехали на новый сервер и свернули базу, мои коллеги (администраторы, разработчики 1С) заметили, что база стала работать чуть стабильнее, стали быстрее выполняться какие-то регламентные операции.
  • Но как вы думаете, что сказали пользователи? Они сказали, что стало хуже и мы вообще зря на все это время тратили вместо того, чтобы сделать еще один отчет. Чтобы объяснить им, что произошло, мне опять пришла на помощь визуализация, я показал им такую картинку – автобус остался примерно тот же, но из него убрали лишнюю гармошку, покрасили, поставили новый двигатель. Но это остался тот же автобус, на той же платформе, на том же шасси. Стало комфортнее, но это не то, к чему мы стремились, и не то, ради чего все затевалась.

Если подводить итог, то первый этап был необходимым условием, но недостаточным.

 

Инструменты оптимизации

 

 

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

В качестве инструментов мы выбрали:

  • Корпоративную подписку на сервис gilev.ru – это не реклама, мы ими действительно пользуемся до сих пор. На конференции много рассказывали про ЦКК, другие сервисы 1С, но для нас оказалось удобнее и эффективнее использовать именно сервисы gilev.ru. Многие из них бесплатные, но некоторые, которые входят в корпоративную подписку, дополнительно еще настраиваются и поддерживаются со стороны команды gilev.ru. В подписку входят такие сервисы, как:
    • сервис производительности Apdex;
    • сервис анализа логов технологического журнала;
    • анализ долгих запросов;
    • анализ состояния SQL базы;
    • контроль загруженности оборудования;
    • контроль взаимоблокировок – все то, чем нам только предстояло заняться и с чем работать.
  • Отдельно рекомендую курс по оптимизации производительности Андрея Бурмистрова. Мне удалось лично побывать на многих курсах по оптимизации производительности, в том числе от 1С, но это были курсы именно администрирования. А для своих специалистов, на которых упала эта задача, мы приобрели удаленный курс Андрея Бурмистрова – очень подробный хороший курс, который описывает на уровне понимания, что нужно сделать. В частности, он является одним из этапов подготовки к сертификату 1С:Эксперт. Очень рекомендую.
  • И еще один административный инструмент – мы договорились с генеральным директором на полгода наложить запрет на доработки конфигурации информационной системы. И хотя стек доработок очень большой, очень много функциональности, мне удалось объяснить и доказать, что на непрочном фундаменте нельзя достраивать этажи, нельзя развивать конфигурацию, потому что в конечном итоге все точно упадет, и риск потерять данные будет слишком большой – в этом случае простои будут очень большие.

 

Замеры производительности

 

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

 

 

Представление APDEX мы выбрали именно в таком виде – это скриншот сервиса gilev.ru.

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

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

Видно, что общая оценка производительности системы плохая. Мы четко можем констатировать, что проблема есть, она реальная, вопрос «работает / не работает» не стоит, но чтобы исправить эту ситуацию, нужно, как сказал наш президент, «раздеваться и работать».

 

Второй этап – платформа

 

 

На следующем этапе нам нужно было перевести базу УПП на новую платформу 1С.

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

  • Мы  самостоятельно с помощью небольших манипуляций осуществили обновление платформы с 8.1 на 8.2. Сначала развернули тестовую базу и перевели для нее платформу. То, что вывалилось, сразу поправили самостоятельно. Потом сделали бета-тестирование: для этого разослали информационные письма и обзвонили ключевых руководителей с просьбой зайти в базу и совершить какие-нибудь свои классические операции (провести документ, сформировать отчеты), а если что-то не работает, прислать нам фидбэк, чтобы мы оперативно все исправили. Конечно же, в момент уже реального перехода появились новые ошибки, которые мешали работать, но они достаточно быстро были исправлены нашими программистами. Да, пришлось немного динамически обновить конфигурацию, но мы с этим справились.
  • Второй большой этап заключался в том, что мы перевели базу на управляемые блокировки. Сразу анонсирую, что эта вещь очень сильно влияет на производительность, имеет очень большой эффект и вклад в трансформацию состояния из неудовлетворительного в положительное. Речь про перевод старой конфигурации из режима неуправляемых (автоматических) блокировок, когда блокировками управляет SQL Server, в управляемый – когда вы управляете этим сами на уровне кода. Делали мы это не сами, потому что хорошего практического опыта у нас не было. Обратились к подрядчикам, к той же команде gilev.ru, они нам все достаточно быстро, в течение пары недель, реализовали. Это дало сразу большой скачок по APDEX.
  • На следующем этапе мы обновили платформу с 8.2 на 8.3.10, но без режима совместимости. Это тоже очень важно, потому что с 8.3.10 включается механизм версионирования на уровне SQL, что тоже сильно влияет на производительность, особенно на многопоточную обработку информации от различных пользователей.

 

 

Традиционная картинка. После каждого этапа, который занимал достаточно длительный промежуток времени, мы делали точечные доклады для бизнеса, чтобы показать, что платформа стала новее (автобус – симпатичнее).

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

А мы помним, что у нас есть APDEX, который дает объективную оценку нашей работе.

 

Третий этап – код

 

 

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

  • Проводились спецоперации по корректировке регистров. Мы выявили, что еще с 10-12 регистрами было что-то не так, потому что когда регистр накопления копит-копит-копит, и по нему нет ни одной расходной операции, он не схлопывается в ноль, а там миллионы каких-то записей – явно что-то не так на уровне кода. Также нашли много регистров сведений, которые накопили в себе под миллиард записей, но при этом ни разу нигде не использовались. Наверное, это были ошибки где-то на уровне архитектуры, или когда фирмы франчайзи для нас что-то делали, а потом что-то пошло не так. Такая точечная корректировка регистров позволила сократить объем базы на 100 гигабайт – еще около 100 гигабайт ненужных данных было вычищено из базы.
  • Мы провели оптимизацию кода запросов – это топ-уровень хороших разработчиков, которые не просто пишут код, но и могут разобраться в чужом и сделать это наиболее оптимально. Вручную это делать достаточно сложно, поэтому опять же, помогают сервисы, которые автоматически анализируют топ самых неэффективных запросов или запросов, которые больше всего занимают времени по базе данных. При этом любой запрос к базе данных – это, скорее всего, блокировки – взаимоблокировки или ожидание на блокировках. Мы проанализировали вручную и исправили порядка 15-20 запросов. Из самых вопиющих: запрос реестр накладных выполнялся на одних и тех же данных 220 секунд, а после оптимизации – 2 секунды, обработка печать ценников выполнялась 40 секунд, после оптимизации – 1 секунду. Таких примеров очень много, это, к сожалению, примеры непрофессионализма разработки или недостаточности знаний о работе платформы.
  • Тут мы вспомнили про удаление помеченных объектов. Напомню, что когда регламентные операции не работали, это все копилось, и в результате в базе оказалось около 2-2,5 миллионов помеченных объектов, не удаляемых типовыми средствами. Поэтому длительное время мы в ночные регламентные окна все эти помеченные объекты вычищали.

Стало еще лучше, людям во многом стало комфортнее.

 

 

Помимо того, что с помощью этих точечных спецопераций мы решили проблемы архитектурно, мы еще и попросили своих коллег (пользователей, бухгалтеров) рассказать конкретные проблемы, которые их беспокоят. Например, долго открывается форма, долго проводится документ, еще что-то не устраивает.

По этим жалобам мы точечно отработали – было много моментов, связанных именно с неэффективностью написанного кода, где-то с лишними записями в регистр. Это дало очень хороший эффект.

 

 

На слайде показаны замеры APDEX на июль 2019 года. Здесь можно увидеть, что зеленого стало гораздо больше.

В самом низу видно, что в целом характеристика системы стала «хорошо» и «отлично». Но красные вкрапления остаются.

Если посмотреть по верхним пунктам, то самая важная для нас оптимизация – это документ «Реализация нефтепродуктов АЗС». Количество операций в неделю – 3503 операции, среднее время проведения – 2.9 секунды. До этого один документ проводился 15-20 секунд.

При этом видно, что плохим осталось перепроведение документов в рабочее время – кто-то запустил обработку по массовому перепроведению, и в итоге все повисло на блокировках.

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

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

 

Четвертый этап – процессы

 

 

Запустив этот маховик, мы уже не остановились и перешли к самим бизнес-процессам.

  • Мы выяснили, что бухгалтеры формируют у нас в базе около 100-150 ручных операций в месяц. Ручные операции – это когда у людей есть доступ в регистры, они туда напрямую приходят и правят там какие-то данные. Зачем и почему – с этим предстояло разобраться. Отмечу, что большинство этих ручных операций было вызвано объективными причинами, потому что не существовало инструмента, который позволил бы отредактировать данные. Но оставшиеся операции делались просто потому, что «исторически так сложилось», так было удобнее – не корректировку сделать, а просто в регистр зайти напрямую и поправить. Все это приводило к потерям производительности, но уже не системы, а людей. В основном ручными операциями пользовались бухгалтеры – они корректировали, например, только бухгалтерский регистр, при этом их абсолютно не волновало, что происходит в управленческом учете. В итоге данные в бухгалтерском регистре и регистрах управленческого учета начинали расходиться: финансисты формируют отчет, у них одни цифры, а у бухгалтеров – другие. Поскольку решают, что правильно у бухгалтеров, финансист и экономист выгружают бухгалтерские ведомости к себе в Excel, крутят данные, делают какие-то отчеты, и все это мучительно вручную сводится. Для предприятия это было колоссальной потерей производительности целых подразделений, которые вынуждены постоянно перепроверять данные, делать сверки друг с другом. Поэтому мы взяли себе на вооружение и точечно в течение месяца-двух отстреливали все ручные операции, постепенно закрывая к ним доступ. На сегодняшний день этого уже нет.
  • Из этой первой проблемы вытекала вторая – финансисты не могли доверять управленческим регистрам по взаиморасчетам. Изначально, в попытках закостылить решения, которые были связаны с расхождением по регистрам, переписывались отчеты, чтобы брались данные для финансистов из бухгалтерских, а не из управленческих регистров – это все приводило к вакханалии. Поэтому мы переписали блок взаиморасчетов.
  • Заодно мы переписали блок учета основных средств и материалов. Это тоже многое дало для производительности.

 

 

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

 

Планы на будущее

 

 

Немного про планы на будущее:

  • Однозначно есть понимание, что нужно разделить базы на оперативную и аналитическую. Аналитическая база будет работать в режиме read only, в ней будут формироваться все необходимые отчеты, в том числе на 1С. Ее необходимо выделить отдельно, чтобы снять нагрузку с основной базы и более внимательно и в спокойном режиме заниматься аналитикой.
  • К этой read only базе мы планируем прикрутить BI аналитику. Не секрет, что хорошая аналитика – это не сильная сторона 1С, его сильная сторона – это учет и простота его ведения. А для аналитики я бы рекомендовал другие системы: Power BI, Qlik и т.д.
  • Третья задача, которую мы планируем реализовать, – это плотная связка 1С:Документооборота и ЭЦП, потому что очень много запросов приходит именно на внедрение электронного документооборота в части подписания документов электронной цифровой подписью. Изначально было представление, что это надо впихнуть куда-то в УПП. Но в итоге решили, что УПП хранит данные, там формируются проводки документов, потом из УПП формируется печатная форма необходимого документа, отправляется в 1С:Документооборот. Там она подписывается, становится юридически значимым документом, хранится и достаточно просто обеспечивается и хранение, и проверка целостности, и легальности данной подписи.

Надеюсь, мы все реализуем. И наконец-то наши пользователи будут довольны.

 

Вопросы

 

  • Очень интересно собирать статистику, смотреть, анализировать перформанс монитор – это вообще очень мощная штука. Я мало знаю людей, которые умеют этим заниматься.
  • Действительно, сервисы gilev.ru работают, технологический журнал анализируется, и это действительно круто. При этом мы практически на это не тратим время.
  • Роман, спасибо за доклад. Вы сказали, что пришли в 2017 году, когда еще были автоматические блокировки и так далее. А вы вообще УПП не обновляли никогда? Где регламентированная отчетность? Она в другой базе?
  • Белорусский рынок и белорусский 1С сильно отличается от российского. Надо понимать, что для Беларуси нет ни одной реально написанной конфигурации. Это все адаптация. Например, в России вышла УПП с российским учетом, в Беларуси какие-то компании ее адаптируют. Но представительства фирмы «1С» у нас нет, поэтому и регламентных типовых обновлений практически нет. Не говоря про то, что ИТС вообще не работает. ИТС нужен только для обновления платформы.
  • Понятно. Еще один маленький вопрос. У вас был road map – обновление платформы с 8.1 на 8.2, потом включили управляемые блокировки, потом перешли на 8.3. Это только обновили платформу или все-таки еще и режим совместимости конфигурации поменяли?
  • Я уже говорил, что делали обновление платформ со снятием режима совместимости. Мы его полностью выключали. Сейчас у нас конфигурация УПП работает на платформе 8.3.10 без режима совместимости в принципе.
  • Вопрос по теме доклада «Замеры APDEX против ощущений бухгалтеров» – как вы построили шкалу APDEX, если у вас, исходя из всего доклада, бухгалтера все равно были недовольны. Как вы выделили нижнюю и верхнюю границы?
  • При любых работах, связанных с оптимизацией производительности, какие-то метрики должны быть обязательно – APDEX либо любая другая. Потому что в процессе очень сложно отличить, изменилось вообще что-то, стало лучше что-то или нет. Да, бухгалтера были недовольны. Но как собирались метрики? Есть типовой набор, когда в метрики добавляются все документы и на них ставятся счетчики на проведение документа. Если я не ошибаюсь, эталон для проведения документа – 1-2 секунды в зависимости от нагруженности базы. Дополнительно мы провели опрос всех пользователей, бухгалтеров, что им еще не нравится. В опроснике мы спросили, за сколько времени определенный документ должен проводиться. По этим значениям мы настроили APDEX, выставили эталонное время и дальше по нему уже работали.
  • Получается, не было такого, что вам бухгалтера всегда говорили, что все плохо?!
  • Они всегда говорили, что все плохо, независимо от того, что показывает APDEX. Но нам важно было не бухгалтерам что-то доказать, нам важно было показать руководству состояние системы до и после изменений без субъективных оценок. Мы внедрили независимого свидетеля этой работы, и ни я не могу повлиять на эту методику, ни пользователи не могут на нее повлиять, ни даже наши разработчики этого не могут. Стоит добавить, что в процессе трансформации системы из состояния «А» в состояние «Б» были человеческие потери. У меня в ИТ-отделе были потери, с некоторыми людьми пришлось расставаться. С некоторыми бухгалтерами пришлось расстаться – особо критично настроенными. Это неизбежно. Но для компании это был положительный момент. Я ещё раз повторю – нашей задачей не было сделать всех бухгалтеров довольными, мы должны были сделать так, чтобы бизнес перестал терять время на медленной работе систем. Именно об этом мы договаривались с генеральным директором. Поэтому степень удовлетворенности пользователей – это важно, но все-таки более важно объективное состояние системы.
  • Но у вас тема доклада про APDEX, который касается удовлетворенности пользователей. А получается, что в данном случае это, скорее, удовлетворенность бизнеса.
  • APDEX показал отличную удовлетворенность. А то, что показывает APDEX, – это не то, что думает бухгалтер. Например, если бухгалтер согласился, что проведение документа за 5 секунд его устроит, сама операция занимает 2 секунды, но бухгалтер все равно недоволен, значит, он недоволен чем-то еще – стулом, компьютером, кабинетом. Но это уже не совсем про информационные системы.
  • Хочу уточнить такой момент: опрос пользователей, который вы делали на APDEX, проводился один раз, и потом вы по нему работали? Либо такие опросы проводились на постоянной основе?
  • Когда мы делали опрос, откликнулись, наверное, только 5% всех пользователей, большинство не дали конкретных ответов. Поэтому мы сознательно добавили в мониторинг APDEX по умолчанию все документы, которые есть в информационной системе. И еще добавили открытие форм, какие-то отчеты, на которые нам указали. У нас есть тикетная система, и если туда прилетает заявка о том, что у кого-то что-то медленно работает, мы этот объект добавляем в APDEX. Мониторинг работает постоянно – мы все его объекты для себя анализируем, а если еще и приходит запрос от пользователя, то мы точечно смотрим, что не так. Бывают моменты, когда выплывает что-то, что мешает нормальной работе системы.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2953    spyke    26    

42

Быстродействие типовой 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    5090    vasilev2015    19    

37

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7617    158    ZAOSTG    66    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5948    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8832    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

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

15.11.2023    5092    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

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

11.10.2023    16153    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. mpeg1989 130 24.04.20 17:06 Сейчас в теме
С такими вводными просто любо-дорого работать. Тут не просто потенциал, а потенциалище! Железо я бы стал обновлять в самую последнюю очередь при таком раскладе.

1. Управляемые блокировки и 8.3. Простой пример - есть проведение документа, которое выполняется 20 секунд, но блокирует больше, чем нужно и 10 пользователей выстраиваются в очередь. Получаем 200 секунд ожидания. А скорее вылет по таймауту, если его не увеличили до космических значений. Ускоряем обработку, станет выполнятся за 5 секунд. Ожидания - 50 секунд, что больше психологического барьера в 20 секунд. А если просто убрать ожидание, то получаем, что у 10 пользователей ожидание 20 секунд, одновременно. А если одновременно не 10 пользователей, а 100, то выхлоп еще больше, даже если некоторые будут пересекаться в данных и ожидания все-таки будут. И вот на этом этапе узким местом станет как раз железо и пункт 2.

2. MS SQL 2016. Конкретно в 2016 добавилось столько приколюх по умолчанию, которые раньше через флаги трассировки включались.

А виртуализацию бесполезно убрали. 3-10% ничтожно, по сравнению с возможным выигрышем в несколько раз. Скорее даже десятков раз. А в некоторых операциях даже сотен раз.
3. it-boy 21 24.04.20 18:03 Сейчас в теме
(1) Да, работы было много. К сожалению, очень часто приходится сталкиваться полным непрофессионализмом в части проектов 1С, даже на достаточно крупных внедрениях. Сначала одни не думают про архитектуру решения, потом другие не знают, что с этим делать.

В части виртуалиазции - это было необходимо, так как и сама виртуализация была далеко не эталоном развертывания, но главное - это достаточно старая и медленная хранилка на медленных дисках и подключенная по 1 GB\s LAN. Поэтому гораздо эффективнее было разобрать такой кластер и приземлить все локально. Тем более объеденить сервер 1С и SQL для перехода на протокол Shared Memory.
4. 7o2uYXg 44 27.04.20 09:41 Сейчас в теме
(1) А можно ли пример операций или сценариев, где возможен выигрыш в несколько десятков, или даже сотен раз при использовании виртуализации?
9. mpeg1989 130 27.04.20 12:41 Сейчас в теме
(4) Видимо акценты не так расставил. Я имел ввиду, что выигрыш от ухода с виртуализации - 3-10%, выигрыш от разведения блокировок и оптимизации запросов - десятки и сотни раз. Поэтому единственное, для чего следует уходить с виртуализации - это доказать, что она не особо влияет либо криво настроена. Хотя в комментариях написали, что есть еще одна вполне себе адекватная причина перехода.
6. TerveRus 27.04.20 11:58 Сейчас в теме
(1)
Железо я бы стал обновлять в самую последнюю очередь при таком раскладе.

Железо в любом случае надо было обновлять, а такими вот установками, что железо хорошее, прошлая команда и отправилась ставить базы данных на HDD в бедные ларьки)
10. mpeg1989 130 27.04.20 12:44 Сейчас в теме
(6) Я же не написал, что железо огонь и менять его не надо. Сначала блокировки, разведение блокировок даст нагрузку на железо и вот тогда эффект будет уже ощутимым и не надо будет краснеть и что-то объяснять начальству и пользователям, которые не увидели эффекта.
2. пользователь 24.04.20 18:01
Сообщение было скрыто модератором.
...
5. adapter 417 27.04.20 11:54 Сейчас в теме
Интересная статья, редко встретишь реальный кейс на просторах.
Несколько замечаний. У вашего директора очень большое терпение. Видимо потому что команду ИТ сменили до вас, руководству уже некуда деваться, ребята взяли на себя удар )
Если бы прошлой команде дали большой бюджет и полгода на решение без доработок они бы и не уволились)

Самые большие этапы по затратам времени и денег так и не получилось толком обосновать руководству. Закупка серверов, свертка базы привлеченными специалистами, а APDEX ничего не показал. Бизнес вам время и деньги, а вы ему фотку автобуса.

В итоге доработка кода дала самый ощутимый эффект
mpeg1989; TerveRus; +2 Ответить
13. it-boy 21 28.04.20 18:40 Сейчас в теме
(5) Спасибо за отзыв. Замечания принимаются ) На самом деле время доклада жестко ограниченно, поэтому подробно обо всем, что происходило фактически на протяжении года сложно вписать в 30 минут, да и я совсем не претендую на оригинальность или статуc "советчика". Вы правильно отметили, данная статья - это моя попытка рассказать реальный кейс о состоянии информационной системы и процессе оптимизации на достаточно крупном предприятии с определенными возможностями и бюджетом. Кейс из разряда "Богатые тоже тормозят" :-)
14. it-boy 21 28.04.20 18:52 Сейчас в теме
(5) Немного уточню:
команду уже менял я, к сожалению, предыдущие ребята не дотягивали по уровню задач, поддержку еще закрывать могли, но серьезные изменения с ними мы бы не вытянули.
Да и дело вроде как не в бюджете было, а бюджет на сторонние услуги был совсем скромным (в пределах 2-3 ЗП хорошего разработчика 1С). Мне кажется просто нужен был "свежий" взгляд и желание что-то изменить.
В конечном итоге, бизнес остался доволен, хотя, кроме картинок с автобусами, почти ничего не понял о проведенных изменениях. )))
Но, в общем положительный результат сложился из всех этапов, и было бы странно только оптимизировать код, но при этом оставить старое железо, платформу 8.1 и не закрыть ручные операции
user1279931; adapter; +2 Ответить
7. adapter 417 27.04.20 12:09 Сейчас в теме
по железу обсуждать не вижу смысла. Для этого должны быть замеры до\после - утилизация ресурсов, очереди дисков, страницы в процедурном кеше и многопоточное тестирование. Если есть ярко выраженное узкое место, то цена апгрейда. Просто так не глядя менять хорошее на новое можно если бюджет позволяет.
Я не конкретный кей
mpeg1989; +1 Ответить
15. it-boy 21 28.04.20 19:00 Сейчас в теме
(7) Основная причина замены железа - это срок эксплуатации серверов, на которых работает бизнес критичные сервисы, срок первышал номру в 5-7 лет. В 2018 году, базы 1С работали на серверах 2008-2011 года, и хотя после переконфигурации и тонкой настройки, действительно больших просадок по железу не было, мониторы ресурсов чистые и без больших задержек. Все-таки железо мы решили менять. Уже скорее по соображениям безопасности, чем производительности. И именно это я и объяснял генеральному, опять таки на примерах:
"Вот, вы свой мерседес 5-летний поменяли на новый, потому что если он сломается в дороге, будет дорого и неудобно. А если 7 летний сервер сломается, то будет еще дороже и еще неудобнее" ))
user1279931; +1 Ответить
8. adapter 417 27.04.20 12:13 Сейчас в теме
я не в конкретный кейс, а вообще скажу часто бывает так что это результат дуэли руководителей:
директор напал - "почему все не работает. Ты можешь что нибудь сделать" ?
айтишник отбился - железо старое, надо *млн
16. it-boy 21 28.04.20 19:02 Сейчас в теме
(8) У нас как раз обратная ситуация, деньги вроде были, но никак не могли "начать" и объяснить руководителю необходимости достаточно масштабных мероприятий на длительный период. Все хотели "волшебную" таблетку, сегодня деньги - завтра результат.
11. adapter 417 27.04.20 14:28 Сейчас в теме
apdex это интегральный показатель, как средняя температура по больнице. Провели документ в 10 строк - зеленый, в 10 000 - красный. Он конечно лучше чем ничего, но все на свете туда не запихнешь. Кто то отчет запустил самодельный без фильтров и повесил сервак - этого там не увидишь. Я например, писал еще один инструмент для замеров и мониторинга. Он тоже не полностью охватывает все кейсы, но как дополнение весьма хорош. Просто нельзя опираться только на apdex

Монитор кластеров серверов
https://infostart.ru/public/1197376/
17. it-boy 21 28.04.20 19:12 Сейчас в теме
(11) Полностью согласен с вами, на одном Apdex далеко не уедешь, это необходимый инструмент, но не достаточный. Мы пользовались целым набором серсов и анализом долгих запросов, и анализом Технологического журнала, и различными счетчиками производительности по разным выборкам, аудитом SQL сервера подробнее тут http://www.gilev.ru/korponline/

А вашу разработку обязательно посмотрим, как раз 10 стартмани завалялось )
12. SGordon1 27.04.20 20:17 Сейчас в теме
А точно эл документы можно через документооборот гонять? Важны же не только печатные, но и всякие цифровые формы , СФ, ЕГАИС, ИСМП..... Или у Вас нет таких букв?
18. it-boy 21 28.04.20 19:22 Сейчас в теме
(12) У нас действительно таких большинства таких букв нет ) Есть СФ (счета-фактуры если я правильно понял), и они как-раз летают через отдельный модуль-подсистему для УПП. В документооборот переносим сами формы документов в электронном виде, а данные остаются в УПП.
Например, отчет о реализации за смену на АЗС (отчет по кассе и магазину) - обязательный документ на 4-5 страниц, который раньше каждый день печатали на АЗС, подписывали и передавали в центральный офис.
Сейчас:
1.1. Передаются только данные из кассы в УПП
1.2. В УПП формируется необходимая печатная форма в электронном виде
1.3. Передается в документооборот
1.4. Менеджеру АЗС прилетает задача подписать документ
1.5. Менеджер локальной ЭЦП подписывает.
1.6. Электронный документ хранится в документооборот, данные в УПП.
user1279931; +1 Ответить
19. SGordon1 29.04.20 11:34 Сейчас в теме
(18) А товаром разве вместе с бензином не барыжите? У нас постоянно было лукойл то купит че то то вернет .....
Если готовые обмены подходят - то потом и какая нить обувь/ сигареты/ что там у вас заработает .....
20. it-boy 21 29.04.20 11:48 Сейчас в теме
(19) Конечно, на большинстве АЗС полноценный магазин с широким ассортиментом товаров. Но готовые обмены и типовые решения - это, к сожалению, не про Беларусь. В РБ с готовими и типовыми решениями в принципе, все плохо, а точнее их фактически нет.
Оставьте свое сообщение