Знание впечатлений конечных пользователей от работы с сайтом и быстрый анализ скрытых причин возникающих проблем необходимы для поддержания надлежащего функционирования приложений Web.

«Лучше выглядеть хорошо, чем хорошо себя чувствовать», — говорил Фернандо, персонаж Билли Кристала. Однако администраторы инфраструктур электронного бизнеса знают, что и внешний вид, и «общее здоровье» приложений Web одинаково важны. Поэтому они разрабатывают все более сложные стратегии управления производительностью с опорой как на внешние, так и на внутренние механизмы мониторинга.

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

КОПАЯ ВГЛУБЬ

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

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

К сожалению, этот уровень зависит от целого ряда взаимосвязанных факторов. В настоящее время нормальная работа типичного приложения Web определяется состоянием множества элементов. Среди них — внутренние базы данных, работающие на оборудовании старшего класса; программное обеспечение промежуточных серверов приложений, возможно, представляющих собой сложный комплекс компонентов Java; ряд серверов внешнего интерфейса вкупе с их операционными системами. Другие факторы, влияющие на производительность, включают различные аппаратные средства, такие, как распределители нагрузки, ускорители протокола защищенных сокетов (SSL) и сетевые устройства для связи и обеспечения доступа в Internet.

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

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

Приведенные факторы невозможно связать с единичными компонентами базовой инфраструктуры. Напротив, они отражают взаимодействие всех частей головоломки: базы данных, различных компонентов сервера приложений и серверов Web. Естественно, она представляет довольно сложную задачу для тех, кто поддерживает работу даже простого приложения Web. Эта сложность привела к тому, что успешное управление функционированием стало превращаться в сложную, многогранную дисциплину.

ВЗГЛЯД СНАРУЖИ

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

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

Кроме того, вы можете воспользоваться внешней статистикой наблюдений для анализа тенденций работы приложений в ретроспективе. Они важны для определения влияния изменений — таких как появление новых возможностей или увеличение трафика на уровень услуг сайта.

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

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

Теперь, когда вы узнали о том, что компании могут ожидать от систем мониторинга приложений, пришла пора взглянуть на разницу в предоставлении подобных услуг внешними поставщиками. Архитектуры современных служб мониторинга имеют заметные различия. Наиболее популярная среди них — система Keynote Systems, обслуживающая корпоративных клиентов и публикующая данные о функционировании сайтов с 1997 г. Keynote поддерживает около 1400 компьютеров для наблюдения за работой сайтов в 140 городах по всему миру. Компания предоставляет как предупреждающие отчеты, так и отчеты с анализом тенденций; клиенты могут получить их из любого места через защищенное соединение браузера.

Потенциальный недостаток подхода Keynote состоит в том, что наблюдение за сайтами ведется только через высокоскоростные соединения с поставщиками услуг Internet первого уровня. С одной стороны — это позволяет исключить влияние переменных на временную и сравнительную статистику, но с другой — ограничивается полезность службы в качестве меры восприятия сайта конечными пользователями, особенно если это индивидуальные потребители или небольшие компании без высокоскоростного доступа в Internet.

Чтобы данные о функционировании более точно отражали работу сайта, они должны быть получены на основании опыта именно таких пользователей, поэтому вам придется устанавливать точки наблюдения для целого среза типичных соединений, включая коммутируемые и широкополосные подключения к местным или региональным поставщикам услуг Internet. Именно этим занимается недавно созданная компания Porivo Technologies.

Вместо специализированных станций наблюдения, расположенных на магистралях поставщиков услуг Internet первого уровня, служба PeerReview этой компании использует существующие ПК пользователей Internet. Она привлекает участников для сбора статистики («партнеров Porivo») и получения репрезентативной выборки, поэтому ее база данных отражает реальное состояние опрашиваемых сайтов. Фактически Porivo может настраивать базу выборки для любого требуемого теста в соответствии с запросами отдельного клиента. Если вас интересуют только те посетители сайта, кто пользуется коммутируемыми соединениями и подключается через поставщиков услуг Internet второго уровня на Восточном побережье, вы сможете получать именно эти сведения.

Архитектура Porivo не требует, чтобы участники опроса вручную набирали адреса тестируемых сайтов, а те, которые посещаются по личным делам, служба Porivo не учитывает. Кроме того, активный агент на базе Java, находящийся на ПК пользователя, проводит тестирование в фоновом режиме. Участники получают тестовые сценарии в соответствии с моделью опроса. Они периодически заходят на сервер Porivo, указывают тип подключения, ПК, браузера и т. д. и берут сценарии, необходимые для участия в тестировании.

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

Некоторые участники опроса Porivo располагаются в корпоративных сетях, но администраторы могут об этом и не знать. Генерируемый агентами Porivo трафик браузера похож на любое другое использование порта 80. Кроме того, участники получают команды во время шифруемых сеансов через порт 442, что, по сути, не отличимо от обычной транзакции SSL.

По заявлению Porivo, в распоряжении компании находятся около 15 тыс. тестовых машин. Из них 5000 могут одновременно участвовать в опросе в любой момент времени, предоставляя гораздо больше статистических данных, чем другие службы мониторинга. Учитывая размер выборки, серверы способны проводить до 500 млн измерений в день. Для достижения подобной масштабируемости Porivo использует свою собственную технологию серверов приложений на базе Java.

СИГНАЛ И ШУМ

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

«Вам необходимо различать мониторинг инфраструктуры Internet и мониторинг инфраструктуры приложений. Если первый дает множество информации о недостатках функционирования, на которые вы повлиять не в силах, то второй сообщает о проблемах, которые вы можете решить», — говорит Клэй Дэвис, вице-президент BMC Software по решениям для поставщиков услуг. Компания BMC работает на рынке мониторинга за пределами брандмауэров с мая 2000 г. после приобретения Evity и ее продукта SiteAngel. Служба SiteAngel позволяет выполнять мониторинг статического, динамического и персонифицированного контента с помощью сценариев и сообщать администраторам о возникающих проблемах.

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

Две точки наблюдения позволяют BMC применять простую процедуру защиты потребителей от ложных тревог. Если монитор обнаруживает проблему, к примеру, между третьим и четвертым шагами данной транзакции, то он не генерирует сигнал тревоги в тот же момент. Вместо этого другой монитор проводит ту же самую транзакцию, чтобы проверить реальность проблемы. При неподтверждении данного факта BMC хотя и сохраняет данные об инциденте, но считает, что они были вызваны мгновенным сбоем подключения к Internet. Дэвис утверждает, что службы мониторинга, использующие множество точек наблюдения, обычно не проводят подобную фильтрацию и генерируют большое количество ложных предупреждений о тривиальных событиях.

Некоторые администраторы, уже работающие с Patrol компании BMC — системой наблюдения за корпоративными приложениями для мониторинга внутренней сетевой инфраструктуры, — оценили и SiteAngel. По их мнению, SiteAngel облегчает интеграцию данных внешнего мониторинга в корпоративные консоли администрирования. Способность Patrol выполнять автоматизированные действия позволяет им настраивать SiteAngel на отслеживание специфических событий и выполнение действий по ликвидации проблемы, например остановки и перезапуска процессов на сервере приложений.

Дэвид Райхман, менеджер по продукции компании Mercury Interactive, полагает, что для подобной интеграции корпоративным клиентам не обязательно приобретать услуги внешнего мониторинга у поставщиков консолей корпоративного администрирования. «Если ваша служба внешнего мониторинга может передавать данные на языке XML, вы можете прибегнуть к прикладному программному интерфейсу любого поставщика решений корпоративного администрирования, чтобы перенести эти данные на консоль», — заявляет он. Службой внешнего мониторинга компании Mercury Interactive является ActiveWatch, располагающая почти 500 точками для запуска и наблюдения за искусственными транзакциями.

Но Mercury Interactive предлагает и другой подход к мониторингу функционирования приложений Web. Модуль Prism (часть пакета решений Topaz для мониторинга работы приложений) осуществляет пассивное наблюдение за реальными сеансами работы пользователей из зоны действия брандмауэра и позволяет взглянуть на систему, с точки зрения конечных пользователей, без установки дополнительных агентов на их компьютерах. Prism отслеживает взаимодействия пользовательских браузеров и сайта по протоколу TCP/IP и таким образом может оценить задержки для сквозных соединений Internet.

ВАЖНЫЕ ВПЕЧАТЛЕНИЯ

Развивая эту концепцию дальше, Mercury Interactive предлагает приложение TwinLook для визуализации впечатлений от работы пользователя с сайтом на основе собранных Prism данных. Администраторам электронного бизнеса и сетей Prism будет полезен для оценки впечатлений конкретных конечных пользователей от посещений сайта. Данная информация пригодится при получении жалобы от какого-либо клиента или делового партнера.

Prism и TwinLook — компоненты пассивного мониторинга пакета Topaz. Он также включает средства всесторонней диагностики серверов. С их помощью технические специалисты электронного бизнеса могут выявлять первопричины проблем, обнаруженных пассивными мониторами. Компания Mercury Interactive представила новое дополнение к пакету Topaz под названием AutoRCA, базу знаний и подсистему правил для анализа и автоматического решения проблем приложений Web.

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

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

Имея собственные подключения к поставщику услуг Internet, такие системы требуют защиты от вирусов и брандмауэры.

В случае потоковых данных необходим другой подход по причине отсутствия «шагов» HTTP, которые можно было бы отслеживать. Для этого службы, подобные Keynote, обычно имеют специализированные программы. Если компания занимается мониторингом сама, то его типичная архитектура включает установку нескольких точек наблюдения (см. предшествующий параграф) и второго соединения через корпоративную сеть для потоковых источников. Подобный подход позволяет в реальном времени сравнить данные, которые «видит» ПК, с теми, что передает сервер, и таким образом обнаружить чрезмерные задержки или сбои в системе.

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

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

Другие системы идут еще дальше, отслеживая типовые маршруты перемещения по сайту, незавершенные покупки и даже то, куда направляется пользователь, покинув сайт. Эти службы не ограничиваются рамками контроля производительности и целостности данных и предоставляют отчеты о реальной эффективности сайта в целом как маркетингового, торгового средства или инструмента для обслуживания клиентов. Примеры таких служб — Web-Hancer и Gomez.

У СЕМИ НЯНЕК...

Как бы ни были ценны решения для оценки пользовательских впечатлений, они не заменят эффективный мониторинг инфраструктуры. Упомянутые решения могут предупреждать администраторов о проблемах и даже помочь с анализом первопричин, но у них нет диагностических возможностей более удобных специализированных средств. Сложные средства мониторинга баз данных особенно важны для обеспечения работы современных многофункциональных приложений Web. Наиболее эффективные мониторы предоставляют подробную информацию о всех запросах к системе, включая время ожидания, объем поиска, эффективность использования кэша и продолжительность соединений с базой данных. Не менее критичны ретроспективные «снимки» активности базы данных: например, узнать в 11.00 утра во вторник о проблеме, возникшей в 16.30 в прошлую пятницу и более не существующей, не так уж необычно.

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

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

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

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

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

Ленни Либман — консультант и независимый автор, специализирующийся по вопросам использования сетевых технологий в бизнесе. С ним можно связаться по адресу: LL@exit109.com.

Ресурсы Internet

Интересное глубокое исследование оценки работы приложения интерактивного обучения компанией British Telecom вы можете найти по адресу: http://www.bt.com/bttj/vol18no2/ shaw/shaw.pdf.

Неплохой список параметров для оценки работы приложений Web находится по адресу: http://www.bangalorelabs.com/resource_center/ whitepapers/Web_perf_measure.pdf.

Документ Meta Group о стратегиях мониторинга работы приложений Web можно бесплатно загрузить с сайта компании Mercury Interactive: http://a1772.g.akamai.net/7/1772/248/faacca08256e45/ www-svca.mercuryinteractive.com/ pdf/products/new_frontiers.pdf.

Документ Консорциума W3C о влиянии на функционирование сети HTTP и других сетевых протоколов расположен по адресу: http://www.w3.org/Protocols/HTTP/ Performance/Pipeline.html.

Технический анализ взаимосвязи протокола HTTP и функционирования TCP находится по адресу: http://www.isi.edu/lsam/publications/http-perf/index.html.