Аудит производительности 1С-систем: на что обращаем внимание

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

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

Зачем нужен аудит производительности ИТ-системы

Почему компания решает привлечь стороннего подрядчика для анализа? И все же анализа чего? Что хочет заказчик получить на выходе и что реально может получить?

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

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

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

Таким образом, основной целью проведения независимого аудита производительности становится примерно такая формулировка «Хотим разобраться в причинах просадки производительности системы 1С, нестабильности ее работы. Получить практические рекомендации».

В нашей практике встречалась еще одна цель, более редкая, но она есть. Заказчик заказывает услугу аудита производительности ИТ-системы, когда хочет понять ее готовность к масштабированию – открытию новых филиалов, точек продаж и т.п. Готова ли система к росту нагрузки по оборудованию, отказоустойчивости, скорости работы?

Что такое аудит производительности?

Чтобы заказать услугу надо понимать кто и что вкладывает в понятие «аудит производительности». Понятие очень ёмкое. По сути, происходит расследование причин замедлений работы ИТ-системы. А вот полнота и многогранность исследования у всех разная.

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

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

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

1. Сбор данных о проблемах в системе от первоисточника.Этот этап позволяет точно собрать данные по проблемам от ключевых пользователей и службы поддержки (1C, сисадминов и т.д.) для понимания основных болей в системе.
2. Анализ аппаратных и программных ресурсов каждого компонента информационной системы 1С: серверов БД, серверов приложений, серверов терминалов, веб-серверов.Любой из перечисленных компонентов может являться бутылочным горлышком как перманентным, так и только при возникновении каких-то событий. По аппаратной составляющей обязательно должна быть оценка по нагрузке на CPU, памяти, дисковой подсистеме, сети. По программной составляющей нужно оценить версии всех продуктов их возможные ограничения, в том числе лицензионного характера.Поэтому оценка сбалансированности использования оборудования и ПО очень важна.
3. Настройки серверов СУБД и 1СЗдесь довольно большое поле для исследования и рекомендаций. Неправильные настройки могут быть сами по себе, могут исторически тянуться в следствие использования каких-то аппаратных ресурсов. Соответственно, важно проанализировать эти причинно-следственные связи.
4. Обслуживание, резервирование и отказоустойчивостьЭто тот пласт исследований, которые многие упускают из виду. А зря.Так, регулярное обслуживание индексов и статистик – это необходимое условие правильного и стабильного функционирования БД. Правильно ли настроен регламент? Успевает ли он отработать в технологическое окно? А если вообще технологические окна для полноценного обслуживания?Анализ резервирования позволяет оценить существующий тип резервного копирования и модель восстановления базы данных. Именно с правильными настройками резервирования в случае аварийной ситуации можно восстановить данные до последней сформированной копии с минимальными потерями данных, которые будут исчисляться не часами, а несколькими последними минутами работы пользователей.Анализ отказоустойчивости нацелен уже не на то, как и как быстро восстановить систему в случае сбоев, а на High Availability – высокую доступность. Здесь идет речь обычно о MS Windows Failover Cluster и AlwaysOn, позволяющих создать отказоустойчивый кластер СУБД. Но для PostgreSQL также есть свои механизмы кластеризации, причём их гораздо больше, чем под Windows.
5. Поведение системы на серверах СУБД и 1СЭто один из самых важных разделов аудита и включает в себя исследование тяжелых запросов, выполняющихся на сервере СУБД, блокировочную картину на сервере СУБД (табличные, страничные, ключевые блокировки, взаимоблокировки), управляемые блокировки на сервере 1С, моделирование тяжелых операций, анализ кода 1С, анализ журналов ТЖ и ЖР.
6. Выводы и прикладные рекомендацииПо каждому этапу аудита должны быть обоснованные выводы, подтвержденные замерами, статистикой, т.е. иметь доказательную базу. По каждой обнаруженной проблеме должны быть предложены рекомендации – либо оперативные (настройки, скрипты), либо стратегические (изменить, архитектуру, аппаратные ресурсы, программные ресурсы, переписать код, внедрить дополнительные решения).
7. Стратегия развития системы на ближайшие годы.Поскольку ИТ-система предприятия – это своего рода сердце бизнеса, то от качества ее работы зависит здоровье всей компании. Мало решить локальную проблему тормозов какого-то функционала. Нужно понимать концептуальную готовность системы к качественной и стабильной работе как в краткосрочной, так и в среднесрочной перспективе. Опять же, оставляем за рамками функциональность и автоматизацию бизнес-процессов – это совершенно другая задача и она не должна смешиваться с производительностью.

Необходимые компетенции и инструментарий

Нужны ли компетенции по аудируемому отраслевому решению 1С? То есть, имеет ли значение конфигурация 1С и ее специфика – Бухгалтерия, Торговля, ERP, самописное что-то или сильно кастомизирванное и т.д.? По нашему опыту (почти 20 лет) можем смело утверждать, что практически нет. Не имеет. Потому что, платформа 1С единая для всех решений и ее поведение, механизмы построения запросов, блокировок, настроек практически идентично, не зависимо от конфигурации. Знания тонкостей функционала конкретной конфигурации нужны для автоматизаторов/разработчиков. А здесь про другое.

Еще раз возвращаюсь к целям аудита производительности – поиск узких мест, из-за которых система начинает вести себя нештатно: тормозит, ведет себя нестабильно. Приведу небольшой пример, абстрактный, но показывающий почему разработчик 1С не всегда может самостоятельно решить проблему просадки производительности вроде бы во вполне конкретном функциональном контуре. Допустим, пользователь жалуется на Отчет, который постоянно тормозит. Разработчик может сто раз его переписывать, оптимизировать запросы 1С, и у него на тестовом стенде отчет будет выполняться мгновенно. Но в продуктивной системе отчет начинает вести себя совсем не так. А потому что многопользовательская среда накладывает свой отпечаток на поведение каждого объекта системы, и оно может быть разным сегодня, вчера, час назад. И потребует расследования, выходящего за пределы анализа и оптимизации лишь кода 1С. Отчет может быть совсем не причём. Просто в этот момент другие пользователи/фоновые задания отняли большую часть ресурсов (например, память) и конкретно этому отчету их не хватило. SQL Server вынужден считывать данные для отчета с дисковой подсистемы, которая заведомо более медленная, чем оперативная память. И это важно увидеть и показать! Ибо точка приложения рекомендаций становится совсем другой. Оптимизация требуется для других запросов, которые выгрызают память и нужно показать их, подсветить для разработчиков и админов.

А как разработчик 1С это увидит? У него этой информации нет. Более того, среднестатистический разработчик даже не хочет ее иметь и максимально ограждает себя от нее: «Моя работа код писать, а база тормозит у админов, разбирайтесь с настройками, у меня все хорошо, на стенде отчет летает».

Теперь про инструменты

Их много и даже очень. Начиная от Zabbix/Grafana + Prometheus, парсеров журнала регистрации и технологического журнала, заканчивая 1С:ЦУП. Набор метрик может быть колоссальным и здесь основная задача инструментария и методики – правильно эти метрики связать, выстроить не менее правильную причинно-следственную связь (системный подход) и докопаться до истины, причем за разумное время, ибо дорога ложка к обеду.

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

Итак, для расследования причин просадки производительности как в целом всей системы, так и по отдельным инцидентам инструмент (не обязательно один) должен позволить решать следующие задачи:

• Данные должны собираться непрерывно, а доступ к ним должен быть ретроспективный. Т.е. не нужен просто срез на сейчас, нужна динамика. По всем метрикам, счетчикам, запросам.
• Статистику должно быть удобно анализировать – нужные данные должны быть доступны, предрассчитаны и синхронизированы, чтобы можно было на единой линейке времени совместить друг с другом любые метрики. Т.е., например, если при увеличении нагрузки на CPU счетчик количества запросов в секунду уменьшился, то, вероятнее всего, снижение количества запросов явилось следствием нехватки ресурсов CPU на их обработку и необходимо искать причину этой нагрузки, которая может быть даже не связана с запросами от ИТ-системы.
• Понимание какой запрос (группа запросов) нагружала в тот или иной момент систему, желательно с планом запросов. Т.е. должны собираться трассы.
• Должна быть возможность связывать метрики от серверов 1С и SQL между собой, чтобы понимать вклад каждого в ту или иную операцию в программе, а также для более быстрого поиска проблемного участка кода 1С.
• Просмотр данных журнала регистрации и технологического журнала в привязке к метрикам производительности, блокировкам, тяжелым запросам, пользователям и их сессиям. В журналах содержится много полезной информации, но вытаскивать ее может быть накладно, если данные журнала не обработаны заранее (не предрассчитаны). Допустим вы знаете примерное время проблемы и пользователя. Из ЖР можно вытащить номер сессии 1С, дальше с этим номером пойти в ТЖ и вытащить из него данные по sql-запросам, контексту, управляемым блокировкам и т.д. При условии, что ТЖ настроен на сбор этих событий, т.к. он имеет свойство очень быстро отъедать все свободное место на диске. На поиск этой информации в ручном режиме надо потратить 15-20 мин. А если таких событий не один десяток, то задача становится очень тяжелой. Поэтому важно понимать, что в эти моменты (на единой оси времени) происходило в системе, чтобы увидеть тренды.

То есть, основное требование к инструменту – он должен позволить рассмотреть ИТ-систему с разных сторон.

Выбор подрядчика

Тут лучше рассмотреть не «как выбрать», а «как не надо выбирать».

Если подрядчик использует только штатные инструменты 1С + парсинг ТЖ и/или ЖР, то маловероятно, что на выходе вы получите качественный разбор. Будет разбор APDEX, будет игра в рыбалку путем анализа ТЖ и ЖР во время моделирования инцидентов. Будут рекомендации по установке тех или иных параметров серверов, основанные на каком-то предыдущем опыте. Возможно, найдете какие-то 1С-запросы, которые стоит оптимизировать путем рефакторинга кода, если анализ ЖР и ТЖ что-то покажет.

В целом, это будут заплатки к системе и не будет полной картины происходящего с ней, а также реальных прогнозов ее поведения в перспективе. И, скорее всего, локальный пожар будет даже потушен. Но вы, наверняка, ожидали от аудита чего-то более фундаментального. А потом через 3 месяца, когда система опять станет колом, бизнес спросит с поддержки. «Вы же проводили уже аудит. Был отчет. Деньги заплачены. Почему опять проблемы с производительностью?».

Не должно быть такой ситуации, когда подрядчик смотрит только 1С-ную часть или только настройки СУБД. Не должно быть ситуации, когда множество рекомендации представляют собой сферического коня в вакууме – типа лучшие практики из интернета. Все должно быть аргументировано. Пример одной из таких «рекомендаций из интернета» – это убрать параллелизм на сервере СУБД, выставить MAXDOP =1. Об этом я написал целую статью – нельзя подходить к этому вопросу вот так вот «в лоб». Кто не читал, обязательно ознакомьтесь.

Резюмирую.

Цель этой статьи была попытка сориентировать заказчиков в выборе услуги аудита производительности 1С-систем и помочь с предварительным анализом предложений на рынке. Естественно, на основе нашего практического опыта. Всё-таки 20 лет без малого!

Сами мы, конечно, предлагаем клиентам рассмотреть нашу услугу «Аудит производительности информационных систем 1С для MS SQL и PostgreSQL» и уверены, что не разочаруем вас в качестве наших работ.