Цифровая трансформация бизнеса резко изменила условия конкуренции, она заставляет компании быть динамичнее, сокращать сроки вывода на рынок новых продуктов и услуг. Одним из эффективных инструментов, помогающих в гонке если не за лидерство, то за выживание, служат системы мониторинга производительности приложений (APM).
Восемь лет подряд компания AppDynamics входит в число лидеров в квадрантах Gartner в сегменте производителей решений для мониторинга производительности приложений. В
Руководитель сейлз-инженеров AppDynamics в России и СНГ Яков Керанчук рассказывает, как строится система APM, какие задачи могут решать с ее помощью заказчики, как оценить стоимость затрат на ее внедрение и сроки окупаемости, какие новые свойства эти системы приобретают уже сегодня и какими они станут завтра.
Что такое мониторинг производительности приложений? Какие задачи при этом решаются?
Платформа APM позволяет оценить работоспособность и производительность программных приложений, выявить корневые причины проблем, появившихся в их работе. Такие оценки критичных бизнес-приложений, позволяющих пользователям работать с тем или иным интеллектуальным корпоративным капиталом, важны заказчикам в первую очередь. Скажем, для банка это может быть его интернет-структура, через которую осуществляется доступ к счетам, переводам, прочей банковской информации.
Система APM оперирует большим количеством метрик, технических и бизнесовых. Решение AppDynamics позволяет не только собирать такие метрики, но и вычислять для них динамические пороговые значения, дающие администраторам системы представление о меняющемся во времени с позиции проведения бизнес-операций уровне нормы для них. Зная эти значения, администратор понимает, находится ли то или иное приложение в рамках нормального функционирования, нормального времени отклика на запросы или же работает медленнее ожидаемого, отрицательно сказываясь на пользовательских оценках работы систем.
Какова архитектура решения APM?
Концептуально APM-решение строится, как правило, как агентское, подразумевающее размещение на уровне серверов приложений программных модулей, которые выявляют пользовательские бизнес-транзакции, производят их диагностические снимки. Данные с агентов обрабатываются собственно серверами системы (физическими или виртуальными). Они могут размещаться внутри инфраструктуры заказчика или реализуются как услуга SaaS, когда серверный модуль APM размещается в облаке провайдера, а пользователи подключаются к нему через веб.
Кто разрабатывает показатели эффективности бизнес-приложений в рамках решения APM?
Показатели эффективности определяются до того, как заказчик начнет внедрять решение у себя. Как правило, перед каждым проектом мы погружаемся в анализ деталей задач, поставленных бизнесом заказчика. Исходя из результатов этого анализа, вместе с заказчиком формируем показатели эффективности. Сравнивая показатели в начале проекта и по его завершении, оцениваем эффективность внедрения APM.
Решение AppDynamics позволяет уже на этапе тестирования развернутой системы диагностировать возможные проблемы в коде приложений, в производительности и надежности функционирования. Если заказчик сам внедряет APM-решение, он, конечно же, должен располагать информацией о том, какие приложения оно будет охватывать, куда нужно установить агенты APM и каковы должны быть показатели нормы для приложений.
В случае, когда APM-решение развертывает и обслуживает внешний подрядчик, заказчику полезно получить помощь в его инвентаризации, чтобы понять, как система будет встроена в его инфраструктуру. Само решение поможет определить показатели нормы для приложений, продемонстрировать реальную картину их функционирования.
В целом полнота и оперативность получаемой от APM информации зависят от полноты покрытия объектов мониторинга необходимыми для этого процесса инструментами и их настройкой.
По умолчанию AppDynamics предоставляет заказчикам некоторый предопределенный набор метрик, таких как время отклика, количество допустимых ошибок, скорость выполнения транзакций... Поскольку платформа AppDynamics является расширяемой, она позволяет создавать новые метрики, как правило, ориентированные на бизнес, — например, для банка это количество выполненных денежных переводов, для оператора каршеринга — количество букированных автомобилей.
Предлагая свою платформу, мы ориентируемся на владельцев приложений (Product Owners), которые для системы являются источником метрик, имеют детальное представление о потребностях заказчиков и выступают связующим звеном между заказчиком и разработчиком APM.
Сказывается ли на производительности серверов приложений нагрузка от клиентов системы APM?
Технологии AppDynamics стали успешными именно потому, что в процессе мониторинга они практически не создают дополнительных нагрузок на информационные системы клиентов. Достигается это за счет разработанных нами интеллектуальных алгоритмов сбора данных, которые позволяют получать детальные метрики и диагностические данные только в том случае, когда в работе приложений есть отклонения от нормы, и при этом они в состоянии собирать огромное количество метрик, используемых для выявления этих самых отклонений. Наша APM-система работает подобно видеонаблюдению на дорогах, которое отслеживает весь поток транспорта, не нарушая его, но при этом выявляя нарушителей.
Какое значение для работы системы AppDynamics APM имеет мониторинг состояния сети?
Есть у нас и такой функционал. Кстати, недавно компания Cisco усилила это направление в своем продуктовом портфеле, приобретя решение ThousandEyes. Оно дополняет возможности, позволяющие выявлять, как состояние сети влияет на качество услуг, предоставляемых платформой AppDynamics APM. Однако сама по себе технология AppDynamics базируется на работе именно агентов и использует особенности платформ разработки, на которых написаны приложения (таких, как Java, .Net, HP и др.). Анализ кода выполняется агентами во время исполнения приложений. Сложности для APM вызывают приложения, написанные на компилируемых языках (например, С++), к кодам которых у заказчика нет доступа. В этом случае система может только косвенно получать данные и оценивать качество выполнения бизнес-операций.
Как выглядит «типовой портрет» пользователя APM-решения?
В фокусе системы APM находятся приложения, которые отвечают за решение бизнес-задач в компании заказчика. Вокруг приложений формируется несколько групп пользователей, ответственных за их разработку, внедрение, тестирование, эксплуатацию; они понимают, как ИТ-метрики работы приложений влияют на метрики бизнеса заказчика. Именно эти группы и выступают внутренними заказчиками и пользователями систем APM.
Что для APM является инцидентом?
Понятие инцидента может быть разным и зависит от характера бизнеса заказчика. В качестве общих типичных примеров инцидентов для APM можно назвать незапланированные простои в работе приложения, вызванные ошибками в его коде или отказом оборудования, от которого зависит его функционирование.
Какой вариант — SaaS или On-Premises — предпочитают заказчики сегодня?
Облачные решения дают заказчику преимущества в стоимости владения и гибкости при эксплуатации. Сформировавшиеся в мире благодаря этим преимуществам тренды на переход в облака сегодня дополнительно стимулируются пандемией COVID-19. Однако в России продолжают пользоваться популярностью решения On-Premises, поэтому здесь мы уделяем внимание обоим вариантам.
Сколько стоит решение APM и каковы сроки его окупаемости?
Стоимость зависит от множества факторов, прежде всего от сложности приложений.
AppDynamics для оценки стоимости решения использует агентский подход: нам важно знать, сколько компонентов используется в приложениях. Вместе с заказчиками мы прорабатываем аспекты экономической эффективности проектов. Внедрение APM всегда приносит пользу и окупается, как правило, за год.
С какими сложностями приходится сталкиваться в процессе развертывания APM?
В технических аспектах мы сложностей для внедрения не видим. Затруднения могут возникать только при решении организационных задач — при согласовании необходимых доступов в инфраструктуру заказчика. Когда же внедрению способствует руководство заказчика, которому понятны цели проекта, мы и здесь не испытываем сложностей и получаем нужное ускорение в ходе работ.
Каковы требования к квалификации специалистов, эксплуатирующих и поддерживающих APM?
Базовые требования такие же, как и для работы с любой другой корпоративной информационной системой, не выше. Для самостоятельного внедрения, настройки и администрирования системы мы рекомендуем пройти специализированный недельный курс. Чтобы получать от APM аналитические бизнес-данные, разумеется, заказчик должен понимать сам предмет бизнеса — как он работает, знать бизнес-показатели для корректного соотнесения их с данными, получаемыми от системы.
Какие изменения происходят в архитектуре решений APM сегодня? Чем они вызваны?
Одним из главных вызовов для нынешнего развития решений APM являются динамично растущие масштабы цифрового бизнеса. Решения APM должны гибко масштабироваться горизонтально, чтобы справляться с обработкой больших объемов данных; уметь работать с облачными технологиями, как иностранными, так и российскими; использовать актуальные технологические стандарты (например, открытый стандарт трассировки OpenTracing); работать с проприетарными технологиями (такими, как технологии компании SAP); гибко развертываться в различных средах — облачных и гибридных. Интеграция нашего решения с платформой Cisco Intersight превращает операции APM из реактивных в проактивные, позволяет не только вести мониторинг, но и по его результатам управлять работой приложений, скажем, автоматически перераспределять ресурсы между облачными и гибридными платформами, оптимизируя нагрузку на них.
