Денис Яковенко, AppDynamics: «Компаниям нужны не просто инструменты ИТ-мониторинга, а комплексное решение бизнес-проблем»

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

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

Согласно отчету «The App Attention Index 2019», 74% пользователей ожидают намного большего, чем всего лишь два года назад. Больше половины удаляют приложение, как только оно начинает работать некорректно. Это наглядно показывает, насколько требовательными стали клиенты. Поэтому сегодня становится критически важным то, как компания взаимодействует со своими клиентами в цифровом пространстве.Елена Истомина, Directum: Как no-code меняет стоимость проекта 5.7 т

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

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

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

Денис Яковенко: На примере нашей собственной клиентской базы мы увидели беспрецедентный приток клиентов в интернет-каналы. Например, в одной из страховых компаний, которая раньше обрабатывала порядка 12 тыс. заявок в неделю, за апрель-май количество заявок выросло в 25 (!) раз, до 300 тыс. заявок в неделю. А пиковое значение, возможно, связанное с маркетинговой акцией по привлечению дополнительных пользователей на сайт, составило 100 тыс. заявок за день. Это огромные цифры.

Влияние пандемии на клиентский опыт мы исследовали очень масштабно на глобальном уровне. Наша компания провела большое исследование «Отчет об агентах трансформации» («The Agents of Transformation Report»), которое проходило с апреля по май в 10 странах мира, включая Россию. Мы опрашивали ИТ-специалистов, чтобы выяснить, как влияют пандемия и удаленка одновременно с цифровизацией на клиентский опыт. Исследование выявило, что среди основных проблем, препятствующих обеспечению работы цифровых сервисов во время пандемии, есть три главных.

Первое – неконтролируемые пиковые всплески трафика. Об этом говорят 72% специалистов, которые были опрошены в России, и 81% – в мире.

Второе – отсутствие единой картины и вообще точного понимания процессов и взаимосвязей того, что происходит внутри приложения. Как, например, front-приложение работает с back-end системой, и каким образом это влияет на качество обслуживания. На это указало в мире 80% опрошенных специалистов, в России - 70%.

И третья большая проблема – это то, что в связи со всем вышеперечисленным происходит увеличение среднего времени на восстановление сервисов (mean time to resolution, MTTR). Почему? Потому что ИТ-специалисты работают во многом тоже удаленно, доступ в Data-центры, особенно, во время пандемии, получить достаточно сложно. Но возникающие проблемы надо было решать. Надо было по-прежнему собирать команды вместе, чтобы найти корневую причину проблемы, и это занимало гораздо больше времени, чем раньше. Об этом говорили 76% респондентов в России и, кстати, меньшее количество специалистов в мире – 70%. Наверное, наши ИТ-отделы к такому развитию событий были менее готовы.

Денис Яковенко: Необходимо максимально защитить свои бизнес-критичные приложения. Защитить – это значит иметь видимость (обозримость) того, что там происходит, и быстро реагировать на возникающие проблемы. И второе – использовать как можно шире предиктивные аналитические инструменты, которые позволяют с помощью машинного обучения гораздо более точно выявлять паттерны, различные тренды, например, увеличение количества медленных транзакций и приложений или количества ошибок. Тем самым появляется возможность снизить погрешности в определении проблем – уменьшить количество так называемых, alert-штормов, то есть штормов предупреждений, к которым у ИТ-специалистов уже развивается толерантность, они просто привыкают и перестают обращать на них внимание. Из-за этого в конечном итоге страдает конечный пользователь.

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

Денис Яковенко: Вы очень правильно подметили проблематику, с которой сталкиваются все: за многие годы функционирования ИТ-департаментов они накопили большое количество различных инструментов мониторинга. В 2015 году был выпущен отчет, в котором изучался этот вопрос. Оказалось, что около 65% заказчиков используют более 10 инструментов для мониторинга приложений. Представляете? Более десятка! И это было еще пять лет назад.

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

Факт наличия множества разнородных систем не позволяет соединить вместе три вещи: функционирование ИТ, опыт клиента и то, как происходящее с приложениями в данный момент влияет на наш бизнес. Для устаревшего подхода это три несовместимые вещи. И AppDynamics фактически борется именно с этой проблемой.

Денис Яковенко: Мы изначально ориентировали свое решение на то, чтобы одна система соединяла воедино эти три области: клиентский опыт, функционирование ИТ и здоровье бизнеса в цифровых каналах. Ключевая идея – покрыть единой платформой мониторинга и сеть, и базы данных, и среду приложений, и еще получить доступ на уровень кода, а также соединить все эти системы в единую цепочку так, чтобы видеть сквозные бизнес-транзакции, которые начинаются с кликом пользователя и заканчиваются, например, вызовом определенных back-end-систем или сервисов третьих сторон.

Собственно, таким образом мы и находим хороший общий язык с бизнес-руководителями, ведь им понятно, что компании нужны не просто инструменты ИТ-мониторинга, а комплексное решение бизнес-проблем. А основная бизнес-проблема в этом контексте – недостаточная связь ИТ и бизнеса. Если вот сейчас конверсия на сайте интернет-магазина падает, то какую роль в этом играет ИТ? А самое главное, где именно сейчас находится проблема, и как ее устранить?

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

Денис Яковенко: Вы задаете вопрос с позиций старого подхода. Он базируется на том, что владельцем мониторинговых инструментов является отдел ИТ, и в штате 5-10 человек, может быть, даже нескольких десятков человек в крупных компаниях, каждый из которых отвечает за свое направление мониторинга. И за пределами ИТ-отдела эти инструменты никогда не выходят.

Компания AppDynamics принесла на рынок новый подход. В числе владельцев системы мониторинга действительно будут ИТ-специалисты, но эту задачу, как правило, можно совместить с какой-либо другой функцией отдела. Возможен также вариант, когда владельцем будет один-два человека – некоторый мини-центр компетенции Application Performance Management. А пользователями AppDynamics при этом станут десятки, зачастую даже сотни человек вне ИТ или в разных функциональных группах ИТ. К числу типичных персон, которые пользуются системой AppDynamics, относятся: сам ИТ-отдел, служба эксплуатации, бизнес-пользователи (каждый видит свое, предназначенное конкретно для него представление данных), а также разработчики, которые могут использовать AppDynamics в средах разработки и тестирования, чтобы понимать, как их код влияет на работоспособность приложения еще до выхода нового релиза.

Выделю еще отдельную группу пользователей системы – высшие руководители, то есть CxO: CIO, CEO, CTO, руководитель product-офиса. Каждый из этих высокопоставленных руководителей имеет возможность получать нужную ему консолидированную информацию и аналитику.

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

Денис Яковенко: Абсолютно так. Действительно, в самом нашем продукте заложена ролевая мелкогранулярная модель ролевого доступа к системе. Это значит, что мы можем обеспечить очень специфичный доступ различных сотрудников к платформе. Тот, кто не должен видеть, например, уровень кода, тот его и не увидит. Поэтому бизнес-пользователи могут видеть определенные высокоуровневые представления информации, «светофоры», «воронки», наблюдать сразу все «здоровье ИТ» на одном и том же экране. И им не обязательно проходить вглубь для того, чтобы понять, в чем проблема.

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

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

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

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

Денис Яковенко: Да, есть инструменты, которые дают возможность увидеть, что проблема есть. Система AppDynamics не только скажет, что она существует, но и ответит на вопросы: где эта проблема? Почему она возникла? На каком уровне, и кто за это ответственный? Решение о том, кто должен отвечать за разрешение конкретной проблемы: ИТ-отдел, бизнес или разработчики? – принимается просто и зачастую автоматически.

Денис Яковенко: Конечно. В наш инструмент сразу встроены алгоритмы машинного обучения. Это позволяет уйти от необходимости задавать каждую политику к использованию некоторой предиктивной аналитики. Она подразумевает установку пороговых значений для алгоритмов, которые описывают механизм принятия решений с помощью самой системы. Одновременно с этим у человека остается возможность вмешаться в эти алгоритмы, настроить правила здоровья – так мы их называем. Настроить их нужно один раз. При покупке продукта в коробке поставляются определенные правила здоровья и алгоритмы принятия решений.

Денис Яковенко: Безусловно, своя специфика есть у каждой компании и у каждого приложения. Как правило, это большой ландшафт приложений, состоящий как из устаревших, так и более-менее современных приложений: здесь написано на С++, здесь Java, там Node.js, а здесь вендорский код, который вообще нельзя никак увидеть. На практике корпоративный ландшафт приложений – «зоопарк» различных систем.

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

У нас в системе есть разные агенты под разные языки программирования, мы поддерживаем все современные фреймворки, и постоянно выпускаем новые.

Кроме того, в системе AppDynamics есть возможность выстроить длинную цепочку сквозной транзакции: от клика пользователя до back-end-системы. Это важно. Например, нередко нужно понимать, что происходит, когда пользователь кликнул в мобильном приложении, и через ряд систем этот запрос доходит до SAP-приложения. А оно представляет собой некую back-end-систему, и надо именно там разобраться, где тормозится процесс.

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

Но на первом этапе это может не потребоваться. Фактически мы позволяем пользователям AppDynamics расти в органическом режиме, постепенно добавляя новые блоки, новые части приложения, а также новые возможности получения и представления информации.

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

Денис Яковенко: Система AppDynamics никак не лимитирует наших заказчиков в отношении того, сколько метрик они могут использовать. Абсолютно все, что есть в коде приложения, мы можем достать, показать и использовать в принятии решений. Например, сигнализировать о том, что выручка в цифровом канале за последние 15 минут снизилась на 5%. Или система может сделать вывод о том, что за последние 30 минут 10% ключевых VIP-заказчиков не может осуществить трансферы из-за того, что эта бизнес-транзакция выполняется очень медленно, в среднем в течение 20 сек.

Вот такие «сложносочиненные» правила здоровья вполне можно использовать и построить их очень просто. Полагаю, что основной задачей владельца AppDynamics оказывается настройка бизнес-метрик и Data-коллекторов – сборщиков данных, и все это делается в интерфейсе AppDynamics. При этом не надо забираться в код приложения. Надо просто выбрать те или другие методы, классы. А для всех ИТ-метрик и метрик клиентского опыта можно настроить динамические уровни нормы, использующие алгоритмы машинного обучения.

Денис Яковенко: Начиная с 2014 г. с AppDynamics работает большинство западных банков. Иными словами, мы стали стандартом де-факто для индустрии и для APM-решений, особенно в тех сферах, где решения мониторинга нужны для бизнеса не в меньшей степени, чем для ИТ.

В числе наших клиентов – UBS (ЮБС, Юнайтед Бизнес Систем), BforBank, Groupe BPCE, The World Bank. Также систему AppDynamics использует один из крупнейших в мире операторов сотовой связи Vodafone, авиакомпания Alaska Airlines, глобальная туристическая компания Expedia Group. В России – «Ингосстрах», банк «Санкт-Петербург» и многие другие.

Например, банк «Санкт-Петербург» находится в фазе цифровой трансформации компании. В связи с пандемией банк стал активно наращивать количество онлайн-клиентов. И сотрудники столкнулись с тем, что в цифровых каналах очень сложно обеспечить требуемый уровень качества услуг. Банк поставил задачу резко повысить качество работы с онлайн-клиентами и добиться существенного увеличения прибыльности этих каналов. Для решения этой задачи был выбран путь получения полной видимости того, что происходит в банковских системах в сфере приложений. Весной мы начали сотрудничество с банком «Санкт-Петербург» в русле долгосрочной программы цифровой трансформации банковских продуктов. И уже сегодня, как говорят специалисты банка, они могут видеть бизнес-процессы полностью: от front-end до back-end, а также могут отслеживать транзакции до уровня кода. Прошло совсем немного времени, а они уже пользуются инструментами, которые позволяют им полностью контролировать процессы, критичные для бизнеса компании. Теперь банк «Санкт-Петербург» может точно определить строку кода, которая содержит причину аномалии. И, конечно, это значительно сокращает время, необходимое для решения возникающих проблем.

Фактически система AppDynamics для банка «Санкт-Петербург» стала общим языком для бизнеса и ИТ.

Денис Яковенко: В одной российской компании из страховой индустрии через полгода после внедрения решения AppDynamics мы провели, так называемый, процесс business value realization. Подразумевается оценка того, что изменилось в бизнесе за шесть месяцев работы продукта. Так вот, после внедрения AppDynamics у них на 75% сократилось время простоя по инцидентам, а время разрешения крупных инцидентов сократилось в 8 раз. И до 80% сократились потери при конверсии.

Напомню, что воронка конверсии – это фактически весь путь пользователя в приложении: от входа до подтверждения заказа, если это интернет-магазин. Причем, для разных пользователей эти пути могут отличаться. В результате внедрения нашего продукта потери конверсии, то есть количество ситуаций, когда посетитель по каким-то причинам не завершил свой маршрут в приложении подтверждением заказа, сократились на 80%! По-моему, это колоссальный результат, который компания получила, и к тому же всего за шесть месяцев.

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

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

Денис Яковенко: Скорее, система AppDynamics может дать бизнес-аналитику отличные инструменты для того, чтобы лучше понимать влияние ИТ на бизнес.

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

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

Денис Яковенко: После приобретения Cisco стартапа ThousandEyes в ближайшее время ожидается глубокая интеграция AppDynamics с этим продуктом, это открывает ещё большие возможности для нас и наших клиентов. Комплексное решение поможет бизнесу расширить возможности сетевого мониторинга с помощью ведущего в отрасли решения AIOps и аккумулировать все компоненты цифрового взаимодействия с клиентом на единой платформе. Наши возможности по анализу корреляций событий, которые происходят на уровне локальной и глобальной сети, интернет-провайдеров, облачных продуктов, кратно увеличатся.

Другое направление, которое сейчас активно развивается, – это видимость и управляемость производительностью приложений SAP. Мы совсем недавно выпустили обновление продукта SAP Peak, который позволяет глубоко мониторить SAP-приложения. В частности, мы собираем информацию о логах, мета-данных, фоновых заданиях и видим все это на уровне ABAP-кода. А значит, разработчики SAP могут точно понимать, в какой именно строчке кода сейчас есть проблема.

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