Добрый день, меня зовут Даниил, и я уже более пяти лет работаю в службе глобальной технической поддержки IT инфраструктуры крупной международной компании. Идея выделить анализ производительности приложений в отдельную область возникла у меня примерно два года назад и сейчас я нахожусь в той стадии, когда уже можно подводить первые итоги работы. Основная причина, побуждающая меня написать эту статью – желание получить конструктивные отзывы извне (в том числе и от уважаемых посетителей данного ресурса), чтобы в дальнейшем использовать их для корректировки курса развития этой области.
Управление производительностью приложений
Тема управления производительностью приложений [1] (более общая относительно её анализа) довольно популярна в наше время. Многие крупные компании осознают или близки к осознанию важности развития этого направления. Однако вопрос практической реализации и оценки эффективности прилагаемых усилий далеко не прост. Даже сама по себе формулировка, что есть “оптимальная производительность” для каждого конкретного приложения или службы представляет собой непростую задачу с нечёткими условиями и выводом. Также, на сегодняшний день не существует ни одного сколь-нибудь достоверного способа измерить финансовую эффективность инвестиций в данную область. Единственное, на что можно полагаться при развитии данной области – это здравый смысл, применяемый в каждом конкретном случае. Все эти вопросы неплохо отражены в глобальном исследовании компании Enterprise Management Associates [2].
Разберём типичный пример. В организации есть некое важное приложение. Бизнес предъявляет жесткие требования к доступности этого приложения, поскольку каждый час простоя приводит к вполне ощутимым убыткам. Подписывается соответствующее соглашение SLA. Отдел IT устанавливает непрерывный автоматический мониторинг доступности, когда специальное устройство регулярно опрашивает его пользовательский интерфейс, посылая простой запрос и ожидая типовой ответ. При отсутствии ответа создаётся автоматический инцидент, который устраняется соответствующими командами поддержки. Можем ли мы сказать, что отдел IT выполняет свою работу и обеспечивает поддержку интересов бизнеса в полном объёме? Не уверен.
В один прекрасный день пользователи обнаруживают, что приложение запускается и довольно быстро, но его ключевые операции исполняются чрезвычайно медленно. Автоматический мониторинг «молчит» и нам очень повезёт, если найдётся хотя бы один из пользователей, кто поднимет трубку и позвонит в службу технической поддержки до того как эта проблема приведёт к существенным убыткам. Моя практика показывает, что, как правило, пользователи не сообщают о таких проблемах. Причин множество, от банального нежелания куда-то звонить и объяснять непростые и субъективные симптомы до недоверия к локальной службе поддержки. Бывает, что подобные проблемы длятся годами, нанося скрытый ущерб бизнесу, портя людям нервы и существенно подрывая репутацию подразделения IT. Иногда о проблеме всё-таки узнают, если убытки от низкой производительности системы становятся слишком очевидными и попадают в фокус руководства бизнеса. Дальше начинается довольно увлекательная история. Старшее руководство IT требует от своих подчинённых немедленно устранить проблему. Собирается круглый стол из представителей отдельных команд, каждый проверяет вверенную ему часть инфраструктуры и все приходят к замечательному выводу – «у нас всё нормально!». Сервера в порядке — ни CPU, ни память не перегружены. Сеть в порядке — потерь пакетов нет, линии связи не перегружены. Клиентская часть тоже должна быть в порядке — остальные-то приложения работают нормально. Беда в том, что когда это всё объединяется в одну систему – работает ужасно, но где искать корневую причину? Производитель программы тоже не очень помогает, ссылаясь на то, что остальные клиенты не жалуются, и указывает на «какие-то проблемы в инфраструктуре». Далее обычно происходит одно из трёх (иногда в комбинации):
- После долгого изучения о проблеме могут забыть (бизнес смирился с тем, что работает теперь так и быстрее не будет), правда в процессе мы потратили немалые деньги на хаотическое усовершенствование отдельных элементов инфраструктуры. Увы, не помогло, но мы же старались!
- Бизнес не может примириться с плохой производительностью данной системы и, видя безуспешность попыток IT отделов устранить проблему, нанимает внешнего консультанта. Тот за большие деньги находит корневую причину где-то на стыке отдельных инфраструктурных элементов и технологий, но репутация отдела IT основательно подорвана.
- Кто-то из внутренних специалистов догадывается о причине, но действует далеко за рамками области своей ответственности.
Подразделение IT может сохранить лицо только в последнем случае, но то, что получится именно так, увы, нет никаких гарантий. Кроме того, совершенно непонятно, как мотивировать людей работать за рамками их непосредственной ответственности и сохранять прозрачность и управляемость в отрасли.
Основные функции анализа производительности приложений
Руководство компании поддержало мою инициативу выделить анализ производительности приложений в отдельную область. Это дало мне возможность на официальной основе развивать её в соответствии с нуждами нашей организации и делать то, что у меня получается лучше всего – проводить кросс-технологический анализ различных систем, работающих на нашем предприятии. Теперь давайте разберёмся, что представляет собой данная область в нашем понимании.
За областью анализа производительности приложений (далее – APA или Application Performance Analysis) мы закрепили следующие функции (в соответствии с имеющимися инструментами и навыками):
- Первоначальный анализ производительности и архитектуры новых приложений
- Помощь командам операционной поддержки в выявлении причин инцидентов, связанных с низкой производительностью приложений
- Автоматический мониторинг производительности операций для ключевых приложений
Рисунок 1
Одним из основных инструментов APA является база знаний, где отражено функциональное предназначение, архитектура и связанные инциденты всех приложений, когда-либо попавших в фокус внимания APA. Она помогает не делать одну и ту же работу дважды (особенно если в команде трудятся несколько специалистов). Можно сказать, что эта база роднит область APA с более общей областью Enterprise Architecture [3], а именно, её технической веткой. Чтобы не создавать избыточных ожиданий, сразу определим чёткие границы зоны ответственности:
- APA помогает командам внедрения проводить первоначальный анализ производительности для новых приложений но не отвечает за всестороннюю оценку этого приложения. Такие вопросы как функционал, резервирование, отказоустойчивость, и многие другие остаются за рамками исследования APA.
- APA помогает командам поддержки идентифицировать проблемный элемент инфраструктуры или приложения но не отвечает за его исправление.
- Для нужд мониторинга производительности приложений APA предоставляет технические средства и их тонкую настройку в соответствии с нуждами заказчика, но не отвечает за успешность разрешения выявленных проблем.
Суть работы области APA отражена в её логотипе (см. рис. 2). Маяк только помогает определить верный курс, но выбор маршрута всегда остаётся на совести капитана.
Рисунок 2
Основную нишу APA среди других служб можно определить следующими формулировками:
- Анализ проблем и инцидентов, в которых остальные команды зашли в тупик
- Кросс-технологическая экспертиза
- Предотвращение инцидентов связанных с ухудшением производительности приложений
В терминах ITIL можно сказать, что мы выводим область Performance Management за рамки традиционных представлений об области Capacity Management, к которой та формально относится [4].
Из сказанного видно, что APA играет важную роль в процессе управления производительностью приложений, но не заменяет его полностью. Это своего рода централизация и унификация самых сложных его составляющих – мониторинга и анализа, однако вопросы непосредственного управления приложениями остаются за соответствующими командами. Здесь они более эффективны: им проще наладить индивидуальный контакт с производителем программного обеспечения, они наиболее заинтересованы в успехе своего сервиса или приложения. APA лишь инструмент, закрывающий наиболее сложную область, всё остальное решается стандартными процедурами.
Основные методы анализа производительности приложений
Специалист APA анализирует сетевой трафик для выявления причин проблем производительности. Сеть – это универсальная среда, объединяющая различные архитектурные компоненты приложений и в подавляющем большинстве случаев анализ сетевых транзакций предоставляет необходимую и достаточную информацию для нахождения сбойного элемента. Однако этот метод имеет свои ограничения. Например, мы можем видеть, что данный сервер вносит наибольшую задержку в исполнение операции пользователя, и даже можем выделить наиболее проблемный вызов, например, GET или POST запрос при загрузке web страницы и соответствующий ему долгий SQL запрос к базе данных. Но то, что происходит внутри сервера в это время остаётся за кадром. Более того, если по каким-либо причинам сервер баз данных объединили с сервером приложений в рамках одного хоста, то разделить их влияние на общее время исполнения операции данным методом практически невозможно. К счастью, в большинстве случаев применение этого метода приносит хорошие результаты. Из своей практики я могу сказать, что порядка 99% обращений ко мне разрешается успешно. При этом информация полученная службой APA является ключевой.
На сегодняшний день на рынке существует множество программных и аппаратных средств, помогающий управлять производительностью приложений. Мы используем два основных инструмента: один – для детального изучения предварительно записанных транзакций, другой – для непрерывного мониторинга производительности приложений путём декодирования и анализа их сетевого трафика.
Теперь давайте подробнее разберёмся с методами реализации отдельных направлений APA.
Методы операционной поддержки
Ключевым условием успеха в операционной поддержке производительности приложений является чёткая формализация каждого инцидента. Пользователь, как правило, описывает проблему субъективно и зачастую весьма эмоционально. На первом этапе очень важно отделить эмоциональную составляющую (слишком крепкий кофе, плохое настроение или неприязнь к какому-либо приложению) от непосредственного определения проблемы. Для этого я создал специальный перечень вопросов, на который пользователь должен ответить во время создания инцидента. Важно отметить, что APA не предполагает непосредственной работы с пользователями, все необходимые ответы получают универсальные специалисты первого и второго уровня поддержки. Иногда часть необходимой информации можно получить, используя средства автоматического мониторинга производительности приложения.
Далее, команда, отвечающая за данное приложение, предоставляет мне достаточно полное описание его архитектуры (какой хост за что отвечает, и какие сетевые транзакции между ними ожидаются во время исполнения проблемных операций). Иногда даётся неполная информация, что не является непреодолимым препятствием для расследования. Так же, я могу их попросить установить необходимые агенты на клиентской и серверной части приложения. Агенты служат для сбора статистической информации с сетевых интерфейсов. Они ставятся в строгом соответствии с инструкцией и в 99% случаев их установка не вызывает никаких сложностей.
Затем, мы согласуем процедуру непосредственного тестирования проблемных операций: я или воспроизвожу проблему сам по инструкции или прошу пользователя сделать это по моей команде. Одновременно с этим я активирую процесс записи на своих агентах. Полученный материал представляет собой набор trace файлов, одновременно записанных во время исполнения проблемной операции в нескольких точках наблюдения. Они содержат полную историю сетевых операций на выбранных хостах. Ключевым преимуществом инструмента, который я использую для анализа, является возможность объединения этих файлов в один, выровненный по времени (то есть, 0 секунд trace файла снятого с клиента абсолютно точно соответствуют 0 секунд на серверных trace файлах). Это даёт мне возможность проследить во времени весь ход операции – сколько времени клиентский запрос шёл по сети к серверу приложений, сколько он потратил на обработку, перед тем как послать необходимый запрос к базе данных, сколько времени база данных обрабатывала этот запрос, и так далее. Разберём конкретный пример.
Вот фрагмент архитектуры интересующего нас приложения (см. рис. 3).
Рисунок 3
После записи и обработки проблемная операция выглядит, как показано на рисунке 4:
Рисунок 4
Далее можно определить влияние каждого элемента на общее время исполнения операции (см. рис 5)
Рисунок 5
Видно, что проблема связана с сервером приложений и CUBE сервером, но можно разобраться чуть глубже. Например, выделить наиболее проблемные вызовы (см. рис. 6).
Рисунок 6
Есть тема для аргументированного разговора с производителем данного ПО.
Важно также отметить, что указанный метод не менее эффективен в расследовании функциональных проблем, не связанных с производительностью, в которых команды поддержки зашли в тупик.
Первоначальный анализ производительности и архитектуры новых приложений
Данный вид деятельности целиком базируется на методах, используемых в операционной поддержке. В дополнение к ним, мы также имеем возможность математически спрогнозировать, какой будет производительность пользовательского интерфейса в разных регионах для централизованных приложений.
Мониторинг производительности приложений
Как уже было сказано выше, бывает весьма сложно получить объективную оценку производительности приложения от пользователя. Просто в силу субъективности самого вопроса. С другой стороны, техническая поддержка в своей работе не может оперировать субъективными метриками. Это противоречие зачастую приводит к тому, что мы пытаемся починить несуществующие или несущественные поломки, тогда как по-настоящему важные проблемы остаются без внимания. Главный вывод состоит в том, что для эффективного управления производительностью приложений, установленных на предприятии, нужно иметь независимую систему автоматического мониторинга производительности. Полагаться на пользователей в этом вопросе – бессмысленно.
Для разрешения данного вопроса я использую средства непрерывного мониторинга производительности приложений путём декодирования и анализа их сетевого трафика. Здесь источником информации являются SPAN порты, настроенные на интересующих нас коммутаторах. То есть, мы практически никак не вмешиваемся в работу интересующих нас систем, никаких агентов на серверах не нужно. Полученная информация собирается и фильтруется на специальных probe серверах и передаётся на центральный сервер. Этот сервер отвечает за анализ и хранение полученных данных, предоставление интерфейса отчётов и автоматическое оповещение о проблемах производительности приложений.
Данное решение не только помогает оперативно узнавать об имеющихся проблемах, но и зачастую даёт подсказку, где искать корневую причину их возникновения. Не настолько детально и точно как это можно сделать средствами операционной поддержки, но всё же достаточно, чтобы существенно ускорить процесс расследования. Кроме того, мы можем видеть долгосрочные тренды изменения производительности приложений, а также оценивать эффект от производимых изменений в инфраструктуре.
Приведу парочку примеров отчётов, которые мы используем.
Общая оценка нагрузки и производительности пользовательского web интерфейса приложения за последние 8 часов (см. рис. 7)
Рисунок 7
Здесь: Operations (левая шкала) – общее количество операций за интервал измерения, делится на «slow operations» и «fast operations». Операция считается медленной, если время её исполнения превышает некое пороговое значение, определённое для данного интерфейса. Average operation time (правая шкала) – среднее время исполнения операций за каждый интервал измерения.
Производительность и нагрузка сервера баз данных того же приложения за тоже самое время показана на рисунке 8.
Рисунок 8
При желании можно определить, какие именно SQL запросы вызвали скачок “Average operation time” между 8 30 и 9 00, но нет особой необходимости, так как это никак не отразилось на пользовательском интерфейсе.
In-house или outsource
На рынке существуют компании предоставляющие анализ производительности приложений как услугу. Насколько я смог разобраться, делают это они примерно теми же методами, как и я, но возможны различные вариации и дополнения. Если перед Вами стоит задача развития данного направления на своём предприятии, первый вопрос, который предстоит решить воспользоваться внешними услугами или развивать сервис внутри компании. Когда я проходил эту стадию, то выделил несколько ключевых факторов, которые и помогли нам принять окончательное решение. Надеюсь, Вам они тоже будут интересны и полезны.
Одним из первых факторов, о которых стоит задуматься – это цена. В случае с внешним сервисом, первоначальная стоимость установки может быть значительно ниже того что потребует внутренняя установка. Более того, можно практически избежать увеличения основных средств (мы же покупаем услугу). Если устанавливать всё внутри то нужно быть готовым к некоторым затратам – сервера, лицензии, персонал с его наймом и обучением, maintenance ежегодный, ресурсы на то чтобы всё это установить и отладить. Да и время, необходимое для того чтобы прилагаемые усилия и затраты начали приносить пользу может быть существенно больше если делать всё самим. Эти аргументы весьма существенны, если рассматривать краткосрочную перспективу, но со временем баланс может измениться. Поставщик услуги – это, прежде всего коммерческая организация. Ему тоже нужно покрывать свои расходы на содержание специалистов и обслуживание продуктов и делать это с выгодой для себя. Вполне может так получиться, что в долгосрочной перспективе при более-менее плотной загрузке данный сервис потребует больших расходов, если пользоваться услугами сторонних компаний. Я провёл немало времени пытаясь сопоставить стоимость владения для каждого варианта. Пришлось делать некоторые предположения, основываясь на существующем опыте: сколько расследований в год нужно проводить, сколько времени это в среднем занимает, и сколько, в конце концов, это может стоить.
Не менее важным вопросом является то, что же мы получаем за эти деньги (качество, объём, а также быстрота расследования критичных инцидентов).
Важной особенностью outsource услуги является то, что поставщик всегда работает в рамках своего контракта. В отличие от внутренней службы он абсолютно не заинтересован в успехе нашего бизнеса. Отсюда следует негибкость поставщика в пограничных ситуациях. Всё что не прописано в контракте, как правило, или невозможно или очень дорого. Например, возник сложный критический инцидент, не связанный с производительностью. Очень часто в таких случаях выручают те же инструменты и методы, которые используются для анализа проблем производительности. Внутренняя APA команда определённо поможет, а вот что скажет сторонний поставщик – неизвестно. Формально для него это далеко за рамками контракта и привычной работы. И не факт что будет легко убедить менеджера с той стороны помочь, ведь он может и не разбираться в технологии и многие аргументы на него попросту не подействуют.
Результатом расследования APA может являться рекомендация существенным образом изменить существующую инфраструктуру. Делается это для того, чтобы не только разрешить текущий инцидент, но и не допустить подобную проблему в других приложениях. Внешнему поставщику совершенно не выгодно разрешать ещё не случившиеся проблемы. Это их доход. К тому же, уровень ответственности за предоставляемые рекомендации довольно высок, так как они часто влияют на общую стратегию развития информационных технологий на предприятии. Не всегда разумно оставлять эти вопросы на усмотрение внешней компании.
Не менее сложный вопрос с быстротой расследования критических инцидентов. Вообще, расследование проблем производительности – область сложная. Никогда нельзя заранее сказать, сколько потребуется времени на анализ – слишком много неизвестных факторов. В любом случае – это не то, что можно отразить в контракте. А как тогда быть, если нужно срочно разобраться? Внутреннее подразделение, так или иначе, зависит от успехов нашего бизнеса, а внешняя компания – нет.
Кроме того, работа с внешним поставщиком предполагает некую формализацию запросов и получаемых результатов. А теперь вопрос: все ли внутренние подразделения готовы чётко формулировать свои запросы и могут понять, что именно им ответили? Ко мне зачастую приходят люди и спрашивают совсем не о том, что им действительно нужно. Выходит, что внутри нам всё равно нужен кто-то, кто будет выступать в роли переводчика, знающего нужных людей внутри компании и понимающего как общаться с внешним поставщиком на его языке. При этом данная роль подразумевает наличие неплохой технической экспертизы, практически такой же которая нужна, чтобы самостоятельно проводить расследования.
Рассмотрение вышеперечисленных аргументов привело нас к решению оставить APA как внутренний сервис. Разумеется, в каждом конкретном случае оптимальное решение может отличаться. Любые аргументы априори являются спорными из-за самой природы вопроса. Я лишь делюсь своим опытом.
Заключение
Всё вышеизложенное – версия практической реализации процесса анализа и управления производительностью приложений на крупном предприятии. В нашем случае она даёт неплохой результат. За последний год подразделение APA было вовлечено в расследование множества критичных проблем и в подавляющем большинстве случаев сыграло ключевую роль в определении корневой причины. Более того, во многих случаях было сложно себе представить, как найденные ошибки могли бы быть идентифицированы без привлечения методов APA. Наша работа ценится руководством.
Ссылки
[1] en.wikipedia.org/wiki/Application_Performance_Management.
[2] “Retail IT Service Operation: Calculating the Impacts of Poor Application Performance Across a Business Ecosystem”. Enterprise Management Associates. 2011
[3] en.wikipedia.org/wiki/Enterprise_architecture_framework
[4] en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library.
Автор: DaniilKochetov
