Наверняка вам встречалась ситуация, когда конечные пользователи недовольны производительностью приложения, а внутри ИТ происходит перекладывание ответственности за "тормоза". Ответственные за программное обеспечение обвиняют ответственных за оборудование и наоборот или говорят пользователю, что так и должно быть.
В чем сложность данной ситуации?
1. Понятие "тормозит" весьма субъективно, для одного пользователя приемлемо подождать 5 минут, для другого – 1 минута ожидания, уже вечность. Операции тоже могут быть разными.
Что делать:
Зафиксировать, что есть нормальная производительность, то есть, что значит "не тормозит". При этом измерение должно производиться в терминах максимально понятных конечным пользователям, желательно, чтобы пользователи могли самостоятельно повторить операцию и оценить скорость ее выполнения. Например, "время формирования отчета не должно превышать 5 минут".
2. Снижение производительности может наблюдаться на фоне изменения характера потребления. Например, значительное увеличение числа операций, совершаемых в ИТ-системе.
Что делать:
Зафиксировать при каких условиях потребления выполняются требования к производительности. Например, при 1000 операций в день отчет будет формироваться 5 минут, а при 10 000 уже не факт.
3. Самое сложное – понять, в чем причина снижения производительности. Зачастую медленное выполнение операций может быть вызвано неоптимальными алгоритмами работы в прикладном ПО и не связано с оборудованием. Для того чтобы понять в чем дело, необходимо проводить всесторонний анализ.
Что делать:
Необходимо иметь возможность оценить, что изменилось в текущей ситуации в сравнении с днями, когда все работало "как надо". Для этого необходимо периодически снимать, так называемые, "baseline" фиксирующие нагрузку на основные элементы оборудования (процессор, память, дисковая, сетевая подсистемы и т.п.) и основные характеристики потребления (количество пользователей, количество операций и т.п.) в момент выполнения операций с обычной рабочей нагрузкой и приемлемой производительностью.
Имея под рукой такой "эталон" в ходе диагностики, есть возможность выявить элементы, поведение которых изменилось. В идеале подобная работа должна проводиться группой лиц, включающих в себя представителей групп, отвечающих за прикладное ПО, СУБД, железо и т.д. Поэтому это как раз тот случай, когда можно сказать, что здесь может помочь процесс управления проблемами, в рамках которого как раз и могут создаваться такие смешанные группы.
Дополнительным подспорьем может стать наличие системы мониторинга с хранением исторических данных по ключевым параметрам. На основании подобной информации можно не только разбираться с единичными инцидентами, но и предотвращать их, оценивая тренды и своевременно реагируя на угрозы недостатка производительности. Кроме того, исторические данные позволяют проводить параллели между событиями в жизни организации (например, вывод на рынок нового продукта, предпраздничные дни и т.п.) и нагрузкой на основные элементы.
Коллеги, поделитесь практиками, как организовать проактивный мониторинг времени отклика работы операций пользователя?
Мы испольузем ручной способ – регулярный замер времени выполнения пользовательских операций по сценарию.