Инциденты, проблемы и производительность

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

 

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Станислав

    Коллеги, поделитесь практиками, как организовать проактивный мониторинг времени отклика работы операций пользователя?

    Мы испольузем ручной способ — регулярный замер времени выполнения пользовательских операций по сценарию. 

     

    0
    0
    1. Евгений Шилов Автор

      Станислав, есть два пути, которыми можно идти:

      1. Использовать API приложения, если он есть.

      2. Имитировать работу пользователя специализированными средствами, которые имитируют нажатия кнопок и движения мышкой, умеют нализировать открытые окна и т.д. На практике встречался с решением подобных задач средствами AutoMate. Деталями, к сожалению, поделиться не смогу, т.к. в конфигурировании не участвовал.

      0
      0
    2. Ruslan Ziganshin

      Станислав, если есть возможность модифицировать приложение, можно обложить операции, отдельные процедуры/функции или их части кодом, который будет фиксировать время начала и окончания выполнения соответствующего блока. Можно, конечно, дополнительно добавить еще и ссылку/идентификатор на обрабатываемы объект, если это требуется.

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

      На полученные результаты можно навесить некий механизм (например тесты системы мониторинга), который будет анализировать измерения за некий промежуток времени и сравнивать их с допустимым и критеческим значением для наблюдаемого показателя, и если последний их достиг/превысил, уведомлять заинтересованных лиц.

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

      Кстати, ручной способ очень хорош при для предварительной оценки влияния на производительность подготавлиемых для применения на продуктиве изменений. И для автоматизации данной группы задач можно использовать, например, HP LoadRunner или (если приложение работает над RDBMS Oracle) Oracle RealApplication Testing, STS.

      0
      0

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ОКТ
26
Учебный курс:
Основы DevOps
ОКТ
30
Учебный курс:
Основы COBIT 5