Русский
Русский
English
Статистика
Реклама

Зонтичный мониторинг

Доступность ИТ-сервисов как ключевой бизнес показатель, и причем тут арбуз

28.04.2021 02:24:00 | Автор: admin

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

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

Идеальная метрика

Впервые я с этим столкнулся в самом начале своей карьеры. Тогда я работал сетевым инженером в региональном операторе связи, и в мои обязанности входила обработка метрик из системы мониторинга для подготовки KPI-отчета по техническому блоку. За основу брались данные о том, пингуется или нет узел связи (без привязки количества абонентов, которые от него зависят). Но в жизни качество предоставляемых провайдером услуг измеряется далеко не прохождением ICMP-пакетов от сервера мониторинга до коммутатора в подъезде, тем более, когда эти коммутаторы находятся в своем стерильном VLAN-е. Этого, наверное, не знали, но смогли прочувствовать на себе абоненты, особенно, нового в то время сервиса: IPTV через multicast. Зависающие картинки на телевизорах абонентов никак не коррелировали с прекрасной зеленой картинкой, подаваемой на стол руководства, и премиальным фондом. Результатом стала проваленная маркетинговая кампания по продвижению IPTV и немного пошатнувшаяся репутация. А дальше по цепочке: пересмотр KPI для инженеров с включением в него кучи новых метрик (в том числе и с бизнес уклоном), весовых коэффициентов, которые было просто невозможно рассчитать, и на которые было сложно повлиять. И вишенка на торте: восприятие сотрудниками KPI в качестве репрессивного инструмента сокращения зарплаты, и полная неэффективность его регуляторной функции. Я думаю, что у вас будет много подобных примеров из практики, особенно если коснуться такой острой темы как KPI и SLA. Вообще тема KPI, особенно в IT, заслуживает отдельного остросюжетного романа.

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

Памятуя о своем неудачном опыте на первом месте работы, я не очень хотел ввязываться в KPI и SLA. Вначале я предложил решить эту проблему через настройку соответствующих Service Desk, тем более так рекомендует нам ITSM (Service Desk - единая точка входа и агрегации всей информации об услугах), а мой продукт будет лишь продолжать регистрировать инциденты и помогать с их дедупликацией за счет определения массовых сбоев и понимания: относится ли новый алерт к проблеме, находящейся на контроле у инженеров, или нет. Но коллегам хотелось не отчетности и репрессивного контроля, как я изначально ошибочно предположил, - им хотелось инструмента управления, который бы помогал и бизнесу, и инженерам находить некий общий язык и добавлял бы прозрачности в их отношения.

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

  1. Бизнес-ориентация. Метрика должна отражать работу нашего ИТ-окружения не с позиции работоспособности какого-либо сервера, а с позиции того, насколько это важно нашим клиентам;

  2. Понятность. Метрику можно однозначно интерпретировать как техническим специалистам, так и бизнесу.

  3. Декомпозируемость. По результатам можно провести анализ, разложить нашу единую синтетическую метрику на компоненты/факторы и выделить наиболее критический. В идеальном случае на выходе получить root cause анализ.

В итоге было предложено два варианта реализации: 1) метрика доступности сервиса/объекта (Service Availability); 2) карта здоровья (Health Map). Карта здоровья в итоге оказалась более сложной как в реализации, так и в аналитическом сопровождении, и была определена как перспективная целевая схема, и на время ее доработки был выбран более простой и привычный подход с оценкой доступности сервиса, о котором и пойдет дальше речь.

Доступность сервиса - это про бизнес, но и про ИТ

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

Приведу пример: потенциальный клиент хочет подать онлайн-заявку на оформление кредита в банке, но система работает со сбоями. Из-за высокого времени ожидания ответа сервера форма постоянно сбрасывается или на ней возникают ошибки, но минут за 30 заявку можно подать. Это приводит к тому, что конверсия в воронке продаж резко падает. С позиции классического инженерного мониторинга это серьезная деградация, но услуга доступна, а вот с позиции бизнеса это неприемлемое состояние системы, когда он теряет потенциальных клиентов. В данном примере доступность сервиса должна считаться равной 0. Приведу обратный пример: у вас, в силу каких-то непредвиденных обстоятельств, полностью выключается целый ЦОД и ваши системы переходят на резервный, при этом клиенты в штатном режиме, правда, чуть дольше, чем обычно, но регистрируют заявки на кредит, и конверсия не падает. А тут мы говорим, что сервис доступен полностью и мы, как инженеры, молодцы - обеспечили горячее резервирование. Хотя при этом половина наших серверов и каналов связи находятся в коме и не доступны. Таким образом, определение доступности сервиса целиком находится на стороне бизнеса, а мы должны лишь зафиксировать в каком соответствующем состоянии должно находится наше ИТ-окружение. Можно поддаться искушению сделать все просто и повесить, например, метрику конверсии как KPI для ИТ-департамента, забывая при этом, что ИТ не про конверсию, его нормальная работа - необходимое, но недостаточное условие для продвижения клиентов по воронке продаж. Поэтому использование бизнес-метрики в лоб приведет к непониманию и отторжению инженерного состава. К сожалению, этому искушению простоты очень часто поддаются руководители и в результате получают прямо противоположный эффект.

Особенности реализации

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

В нашей системе мы позволяем рассчитывать доступность, как отдельной КЕ, так и совокупную доступность группы КЕ. Метрика доступности для группы КЕ - это и есть искомая верхнеуровневая метрика доступности конечного сервиса, потому что сервис зачастую оказывается целым комплексом информационных систем и, в целом, представляет цепочку более мелких сервисов (ЦОД отвечает за сервис предоставления виртуальных машин, Облако за сервис системных компонентов, Информационная систем за прикладные сервисы и так далее). А доступность отдельной КЕ - это оценка работоспособности того или иного объекта с позиции оказания конечного сервиса. Взаимоувязка позволяет в дальнейшем проводить факторный анализ и определять вклад каждого объекта в общий результат, таким образом, находить узкое горлышко.

При построении отчета необходимо прежде всего определить список аварийных ситуаций или их совокупности, которые свидетельствуют о нарушении работы сервиса. Определить также такие дополнительные параметры (при необходимости), как:

  • Время работы сервиса. Например, нам важно, чтобы услуга была доступна только в дневные часы и только по праздникам;

  • Есть ли у нас RTO (recovery time objective) - максимально допустимое время, в течение которого наш объект может находиться в аварийном состоянии;

  • Учитываем или нет согласованные сервисные окна.

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

Собственно методика

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

Для расчета доступности за период SA (Service Availability) необходимо построить функцию проблемного состояния КЕ от времени fProblem(t), которая в каждый момент времени принимает одно из четырех значений:

  • Значение (0) говорит о том, что в конкретный момент времени на КЕ не зафиксированы проблемы, отвечающие фильтру;

  • Значение (1) - в конкретный момент времени на КЕ зафиксирована проблема (-ы), подпадающая под условия;

  • Значение (N), что КЕ находится в необслуживаемом состоянии;

  • Значение (S), что КЕ находится в согласованном сервисном режиме.

В результате мы получим следующие показатели:

  • timeNonWorking - нерабочее время КЕ на исследуемом периоде. Значение функции равно "N";

  • timeWorkingProblem - время нахождения КЕ в не удовлетворяющим SLA состоянии на исследуемом промежутке времени. Значение функции равно "1";

  • timeWorkingService - время согласованного простоя, когда, в рабочее время, КЕ находилась в сервисном режиме. Значение функции равно "S";

  • timeWorkingOK - время, в которое наша КЕ удовлетворяла SLA. Функция fProblem(t) находилась в состоянии "0".

Расчет доступности за период для одиночной КЕ SA (Service Availability) осуществляется по формуле:

SA =timeWorkingOK / (timeWorkingOK+timeWorkingProblem) * 100%

Рис.1 Пример возможного распределения интервалов времени при расчете SA (Service Availability) для одной КЕРис.1 Пример возможного распределения интервалов времени при расчете SA (Service Availability) для одной КЕРис. 2 Пример влияния RTO на расчет функции fProblem(t)Рис. 2 Пример влияния RTO на расчет функции fProblem(t)

Для группового расчета доступности за период SAG (Service Availability Group) необходимо построить функцию проблемного состояния КЕ от времени fProblem(t) для каждой КЕ, входящей в группу. Далее наложить получившиеся функции fProblem(t) по каждой КЕ друг на друга, исходя из определенных правил (см. Табл. 1)

ТАБЛИЦА 1.

f1

f2

fResult

f1

f2

fResult

f1

f2

fResult

0

0

0

1

1

1

N

N

N

0

1

1

1

S

1

N

S

S

0

N

0

1

N

1

S

S

S

0

S

0

В результате получаем функцию fGroupProblem(t). Суммируем длительность участков данной функции следующим образом:

  • timeGroupService - время, когда fGroupProblem(t)= S;

  • timeGroupOK - время, когда fGroupProblem(t) = 0;

  • timeGroupProblem - время, когда fGroupProblem(t) = 1;

Таким образом, искомая метрика:

SAG = timeGroupOK / (timeGroupOK+timeGroupProblem) * 100%

 Пример возможного распределения интервалов времени при расчете доступности для группы КЕ Пример возможного распределения интервалов времени при расчете доступности для группы КЕ

Факторный анализ

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

Факторный анализ позволяет определить: какой фактор-проблема повлиял за отчетный период на расчет доступности и сравнить степень такого влияния с остальным факторами-проблемами.

Предположения методики:

  • В методике определения доступности невозможно определить вес той или иной проблемы, если они произошли одновременно. Таким образом, единственным параметром будет длительность проблемы.

  • В случае, если одновременно произошли две и более проблемы, то на такой период будем считать длительность каждой с коэффициентом 1/N, где N - количество одновременно произошедших проблем.

Методика расчета:

  1. Необходимо взять функцию fProblem(t), построенную при расчете SA.

  2. Для каждого участка, где итоговая функция fProblem(t) = 1, составить список проблем данной КЕ, на основании которых данному участку было присвоено значение. При составлении списка необходимо учитывать и проблемы, которые начинались или заканчивались за пределами участка функции.

  3. Проставить проблеме метрику влияния. Она равняется длительности проблемы на участке умноженную на вес. В случае, если на участке в области свой длительности проблема была единственная, то ей устанавливается вес, равный 1, в случае множественных проблем вес равен 1/N, где N - количество одновременно произошедших проблем.

  4. При расчете следует учесть следующие моменты:

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

    2. Одна и та же проблема может присутствовать на разных участках fProblem(t) = 1. Например, проблема началась в пятницу, закончилась во вторник, а в выходные КЕ не обслуживается согласно SLA.

  5. В итоге должен быть сформирован список проблем, которые участвовали в расчете функции fProblem(t). При этом у каждой проблемы должна быть посчитана метрика влияния на SA.

  6. Необходимо обязательно верифицировать расчет. Сумма метрик влияния всех проблем должна равняться timeWorkingProblem.

  7. Пользователю необходимо выводить относительное значение влияния в %. Для этого метрику влияния необходимо разделить на timeWorkingProblem и умножить на 100%.

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

В результате получаем вот такую картину (см. рис 4.)

Рис. 4 Анализ и оценка проблем в расчете доступностиРис. 4 Анализ и оценка проблем в расчете доступности

Промежуточные итоги

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

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

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

В заключение несколько скриншотов расчета доступности в продукте MONQ.
Подробнее..

Application performance management (APM) от Broadcom для мониторинга производительности приложений (включая мобильные)

24.02.2021 08:04:01 | Автор: admin
Всем привет! В этой статье расскажем о возможностях мониторинга производительности приложений одного из лидеров квадранта Gartner c APM-решениями Broadcom.

image

Appdynamics, Dynatrace и New Relic достаточно известны на российском рынке. Broadcom чуть менее знаком, этакая серая лошадка, однако, имеет не уступающий всем троим функционал мониторинга приложений. А использование APM-решения от Broadcom в комплексе с другим их продуктом, зонтичной AIOps-системой DX Operations Intelligence, позволит создать единое окно мониторинга для разнокалиберного ПО и инфраструктуры. Под катом текст и скриншоты.

Для мониторинга производительности приложений Broadcom поставляет два решения: DX APM и DX AXA. Первое работает с бэкэндом, второе с фронтэндом и мобильными приложениями.

DX APM


Архитектура DX APM


DX Applications Performance Management (APM) предназначен для мониторинга производительности приложений, написанных на Java, .NET, C++, PHP, Node.js, Python, Go и использующих другие технологии. Полный список поддерживаемых технологий можно посмотреть в Compatibility Guide. На ниже приведена область задач мониторинга, которые закрывает DX APM.



Основные особенности DX APM:

  • Распределенная (микросервисная) архитектура решения;
  • Простота в установке, использовании и обновлении;
  • Простота развертывания агентов, в том числе для микросервисных приложений, развернутых в кластере Kubernetes или Openshift;
  • Способность преждевременно выявлять нештатные ситуации до того, как это отразится на опыте конечных пользователей;
  • Автоматический поиск первопричины отказа или возникновения нештатных ситуаций как на программном так и на инфраструктурном уровнях;
  • Является поставщиком необходимой и достаточной информации для разработчиков, операционных подразделений заказчика и бизнес-ориентированных групп.

В спектр задач, решаемых DX APM входят:

  • Мониторинг производительности приложений;
  • Мониторинг опыта пользователей и бизнес-контекста;
  • Мониторинг отклика БД, инфраструктурных компонентов приложения и внешних сервисов;
  • Аналитика и root cause analysis.



DX APM предоставляет различные варианты для визуализации данных:

Experience View. Представление данных с точки зрения оценки опыта конечных пользователей. Данные представлены в виде Experience Cards. Experience card предоставляет верхнеуровневый обзор здоровья для транзакций. Транзакции объединены в Experience Card по заданным атрибутам.

Так выглядит набор Experience Cards:


А так отдельная Experience Card:


Map View транзакционная карта приложения. Слева направо отображает прохождение транзакций от конечного пользователя до сервера приложений, базы данных и т.д, в зависимости от архитектуры приложения. Карта строится автоматически после установки агентов на серверы приложений.



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



Если приложение микросервисное, DX APM распознает используемые технологии в рамках поддерживаемых и создаст соответствующую визуализацию.



Ещё одно важное преимущество решения от Broadcom наличие универсального агента Universal Monitoring Agent (UMA) для различных технологий. UMA устанавливается единожды на кластер, где развернуто микросервисное приложение, далее агент сам отслеживает динамические изменения и ведет мониторинг как инфраструктурных компонент кластера (nodes, pods, containers) так и осуществляет технологический мониторинг приложений в части исполнения кода. С точки зрения автоматизации мониторинга самое оно.



Расследование проблем DX APM


DX APM для ускорения поиска первопричины проблемы в снижении производительности использует в работе запатентованные технологии: Differential Analysis, Timeline View и Assisted Triage, Topology View/Layers. Во многих случаях упреждающие оповещения (на основе аномального поведения), генерируемые DX APM, позволяют избежать реальных проблем в будущем.

Assisted Triage сигнализирует о наличии проблем и аномалий в работе приложений и в автоматическом режиме предоставляет заключение о первоисточнике проблемы, тем самым обеспечивая root-cause analysis. Аномалии указывают на нестрандартное поведение в работе приложении, но при этом воздействия на опыт конечных пользователей еще нет. Так выглядит работа Assisted Triage



Для детального анализа оповещений, генерируемых Assistage Triage, и выявления проблемных компонентов в транзакционной цепочке по клику на оповещение можно перейти в центр расследований Analysis Notebook. Тут, на представлении в виде таймлайна можно увидеть процесс развития проблемы и возникновение параллельных событий.



Так выглядит сопоставление проблемных транзакций с компонентами приложения и инфраструктурой.



Функция Timeline позволяет быстро увидеть изменения в архитектуре приложения во времени в контексте проблем с производительностью, не покидая Map View. Особенно это эффективно при обновлении релиза приложения позволит увидеть все проблемы разом.



При возникновения проблем в работе приложения, разработчикам будет интересно и полезно проанализировать транзакционные трейсы. DX APM предусматривает как функционал автоматической записи трейсов Smart Instrumentation, так и возможности запуска ручной трассировки. DX APM автоматически записывает трассировки транзакций при возникновении следующих событий:

  • В случае ошибок;
  • В случае нестабильного поведения в работе приложения (на основе изменяющегося времени отклика между компонентами приложения или так называемого Differential Analysis).



Использование коммерческими решения открытых решений заметный тренд последнего времени. DX APM поддерживает технологию OpenTracing. При этом решение получает данные о показателях и трассировках транзакций из приложений, оснащенных трассировщиками, совместимыми с OpenTracing. Как результат, можно видеть в UI DX APM целостную транзакционную цепочку (MAP) и сквозной транзакционный трейс. Это особенно актуально для распределённых микросервисных приложений.



Ещё одной важной функцией при расследовании проблем снижения производительности в работе приложения является анализ SQL-запросов к базам данных и мониторинг производительности баз данных. DX APM предоставляет такие возможности для наиболее популярных баз данных, таких как Oracle, MS SQL и некоторых других.



Business Payload Analyzer


Business Payload Analyzer (BPA) это запатентованная функция сбора и анализа данных (Payload транзакций), которая помогает использовать бизнес-контекст для именования транзакций. На рисунке 23 представлено позиционирования BPA по отношению к AXA и APM. По сути, как и AXA (через Browser agent и мобильный SDK) BPA является поставщиком метаданных для APM и помогает в определении бизнес-транзакций.



Физически, BPA является плагином, который устанавливается на web-сервер приложения. Плагин собирает сырые http-данные (после дешифрования серверов https-трафика) каждого запроса и ответа и заливает их в DX APM для дальнейшей обработки и формирования бизнес-транзакций. В текущей версии DX APM 20.2 плагин BPA доступен для:

  • Apache Web Server Plugin for Linux and Windows;
  • IIS Plugin;
  • Nginx Web Server Plugin.

DX AXA


DX AXA (Application Experience Analytics) ориентирован на мониторинг взаимодействия пользователeй с фронтэндом через браузер или мобильное приложение на своём гаджете. Данные, собираемые AXA, могут быть использованы как разработчиками для оптимизации работы приложений, так и бизнес-аналитиками для формирования отчетности о доступности сервисов и планирования бизнес-KPI. Фокус AXA в задаче мониторинга опыта конечных пользователей представлен на рисунке ниже.



DX AXA получает данные по транзакциям пользователей мобильных приложений с помощью интеграции SDK в приложение. В список поддерживаемых платформ включены: Android, iOS, WatchOS. Стоит отметить, что процедура встраивания инструментария SDK в приложения Android очень проста, осуществляется в web-интерфейсе AXA в несколько кликов мыши и не требует привлечения разработчиков.

Также AXA покрывает мониторинг и web-транзакций пользователей с помощью Browser Agent. Browser agent это snippet (скрипт), который встраивается в домашнюю страницу приложения, и при взимодейсвии пользователя с приложением собирает и отправляет метрики взаимодействия на сервер AXA для анализа. Таким образом, это не требует установки агента на рабочих станциях конечных пользователей. Browser agent имеет широкий спектр возможностей по кастомизации и сбору данных. При этом поддерживаются web-транзакции во всех популярных браузерах.



Основной спектр задач, который решает AXA для команд эксплуатации являются:
  • Сегментация данных по версии приложения, провайдеру / wifi, местоположению, платформе, ОС;
  • Оповещения в режиме реального времени о снижении в производительности в работе приложений, пользовательскго опыта и нарушнении SLA, и потенциальных рисков для доходов компании;
  • Ускорение выявления первопричины проблемы.



В список функций, предназначенных для разработчиков приложений входят:

1. Просмотр скриншотов и видео взаимодействия пользователя с приложением,
оптимизация приложений на основе анализа наиболее популярных действий пользователя в приложении.



2. Сегментация сбоев по платформе, устройству. Индикация и детальные данные по App Crashes, HTTP и JavaScript Errors.



3. Просмотр параметров производительности для каждой сессии пользователя.



4. Функция Resource Waterfall обеспечивает более глубокое понимание производительности веб-приложений, отображая подробную информацию о времени загрузки всех компонентов веб-сайта.



Фунционал по разработке отчетности и визуализации данных способен удовлетворить требования бизнеса по планированию доходов и оценке затрат на модернизацию приложений:

  • Приоритезация проблем путем оценки влияния на доходы компании;
  • Возможность задания KPI для оценки ROI;
  • Дополнительные данные для формирования OPEX и CAPEX.





DX AXA имеет глубокую интеграцию с продуктом DX Application Performance Management (APM) для расследования проблем, не связанных с фунционированием фронтэнда. DX AXA при этом является дополнительным поставщиком данных для DX APM по транзакциям, совершаемым пользователями с помощью мобильных приложений.



Интеграция DX APM и DX AXA с DX Operational Intelligence


DX Operations Intelligence это зонтичная система мониторинга, в которой реализованы функции Machine Learning и Artificial Intelligence (ML и AI) над поступающими в платформу данными. Одними из поставщиков таких данных (наравне с Zabbix, Prometheus и прочими) являются DX APM и DX AXA.

DX AXA и DX APM работают в составе платформы DX. Платформа DX устанавливается и работает под управлением кластеров Kubernetes или OpenShift. Установщик платформы DX это консольное приложение, которое запускается пв докер-контейнере и поэтому имеет минимальные зависимости от операционной системы. Программа установки взаимодействует с кластером и выполняет все необходимые действия для создания готового к использованию экземпляра платформы DX. Установщик платформы DX также поддерживает развертывание с хоста, который не является частью кластера.
Используя установщик платформы DX, вы можете установить следующие компоненты:

  • Мониторинг производительности приложений DX APM
  • Мониторинг мобильных приложений DX AXA
  • Зонтичное решение DX OI



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

  • Создание и управление тенантами;
  • Мониторинг и управление ресурсами кластера и сервисами;
  • Создание учетных записей администраторов и пользователей и управление ими;
  • Управление учетными записями пользователей на основе LDAP;
  • Создание и управление учетными записями пользователей, не использующих LDAP;
  • Настройка параметров почтового сервера.





Broadcom безвозмездно предоставит в пользование продукт DX Operational Intelligence Foundation (DX OI) при приобретении лицензий DX APM. DX OI Foundation позволит реализовать фукнции Machine Learning над поступающими в платформу данными (логи, метрики, аварийные сообщения, топология) и оценить/спрогнозировать доступность сервисов на базе анализа поступающих данных. Кроме того, DX OI Foundation может стать единой точкой концентрации аварийных сообщений и интеграции с системой Service Desk.

К сведению: по сравнению с полной версией DX OI, версия Foundation имеет ограничения по времени хранения данных, также есть ограничения по функциям Predictive Insights, Capacity Analytics и интеграции со сторонними системами через Open RESTful APIs. Для снятия этих ограничений необходимо отдельно приобрести лицензии на решение DX OI.

Ну, и напоследок, важное замечание: все перечисленные в этой статье решения Broadcom можно использовать как on-premise так и в SaaS-формате.

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

В ближайшее время мы проведём вебинар по DX APM и DX AXA. Если вы хотели бы узнать подробнее об этих решениях, оставьте заявку и вам вышлем приглашение как только анонсируем вебинар.

А ещё у нас есть:

Запись нашего вебинара по DX OI

Статья на Хабре о зонтичной AIOps-системе мониторинга DX OI

Группа в Facebook

Канал в Youtube
Подробнее..

Мониторинг производительности приложений в Broadcom DX APM анонс вебинара

02.03.2021 10:09:04 | Автор: admin
image

Единый агент для всех популярных технологий, динамическое отслеживание изменений инфраструктуры, низкий оверхед, искусственный интеллект, оценка эффективности релизов, контекстный мониторинг, мониторинг реальных транзакций обо всём этом и многом другом вы узнаете на вебинаре, посвящённому инструменту для мониторинга производительности приложений и инфраструктуры под ними Broadcom DX APM. Вебинар состоится 5 марта в 11 часов утра по московскому времени.

Регистрация на вебинар

Под катом вы найдёте квадрант Gartner за 2020 год по APM-решениям и дополнительные материалы по DX APM и другим решениям Broadcom.


DX APM несколько лет подряд сохраняет лидерство. Решение регулярно обновляется, появляется новый функционал. Особенность продукта использование под капотом открытых технологий, например, OpenTelemetry. Этот тренд, кстати, распространяется и на некоторых других лидеров квадранта.

image

А ещё у нас есть:

Как устроен и работает DX APM

Запись нашего вебинара по зонтичной AIOps-системе мониторинг DX OI

Статья на Хабре о зонтичной AIOps-системе мониторинга DX OI

Группа в Facebook

Канал в Youtube
Подробнее..

Как команде технарей построить свой стартап или путь из функционального мониторинга к AIOps-платформе

17.06.2020 16:18:48 | Автор: admin

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


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


Как родилась идея


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


Этот интегратор занимался тогда в основном поддержкой высоконагруженных систем с огромным числом пользователей и большим числом процессорных ядер на каждую систему. Поддержка была в лучших традициях жанра 24/7. В одной смене могли работать по 20-30 человек. Кто-то смотрел в экраны инфраструктурного мониторинга, кто-то следил за обращениями пользователей, кто-то в непрерывном режиме тестировал руками функционал, кто-то поддерживал автотесты на селениуме и т.д.


Было две проблемы, за решение которых можно было взяться:


  1. Руками проверять функционирование систем очень тяжело и дорого, надо этот процесс автоматизировать;
  2. Летит безумное число оповещений из систем мониторинга, надо найти способ сократить число оповещений и выявить из них только важные.

На обе проблемы было дано решение.


Первая решилась развертыванием Jenkins, на нем запускались сборки тестов на Selenium, далее данные парсились и выводились в виде метрик в Zabbix, на которые были построены триггеры. По сработавшим триггерам приходили оповещения команде поддержки.


Вторая решилась написанием небольшого приложения, где в RabbitMQ падали все оповещения из систем мониторинга, далее они по жестко заданными правилам обрабатывались, результаты складывались в базу PostgreSQL, был построен небольшой дашборд на Bootstrap шаблоне, где были выведены эти события. Назвали его Сервис-монитор. После чего стоял тот же Zabbix, который следил за возникающими событиями и высылал уже команде предобработанные события в почту.


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


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


Потом руководитель заказчика увидел данный дашборд и попросил настроить на него оповещение, если критический сбой длится более 2 часов.


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


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


Урок 1: не упускайте возможностей

Если у вас есть технические наработки, которые помогают вам, покажите их своим клиентам, возможно им они даже нужнее.


Функциональный мониторинг


В 2015 году этот заказчик эксплуатировал более ста информационных систем, работал с двадцатью подрядчиками, а в эксплуатации были заняты более 50 инженеров внутри организации и 300 со стороны подрядчиков. Затраты на мониторинг были очень высокими, а эффективность низкая из-за понятных сложностей в координации всех разрозненных процессов, ну, и, конечно, человеческого фактора, который делал систему оценки качества непрозрачной. При этом мониторинг был зачастую в руках подрядчиков, которым было невыгодно регистрировать инциденты, чтобы не портить свои KPI занижением SLA.


У организации были две наиболее сильные боли, для которых она искала решение:


  1. Пользователи систем обнаруживали проблемы в работе ИТ сервисов раньше специалистов эксплуатации;
  2. Подрядчики иногда не регистрировали инциденты и завышали SLA.

Так как заказчику была известна система Сервис-монитор, он выбрал ее в качестве решения. За первые полгода к мониторингу были подключены 87 информационных систем (в среднем 3-7 тестов по 10 шагов на каждую систему), использовали более 7 000 метрик и более 2600 триггеров. Было написано более 50 разных правил эскалации. Все это позволило ответить на самый главный вопрос работают ли услуги у заказчика и кто из подрядчиков врёт. Оказалось, что некоторые инциденты не замечались не только ночью, но и днем, если пользователи не писали о проблемах.


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


Там, где речь идет о финансовом и зарплатном учете, робот может просматривать данные, но никаких изменений вносить было нельзя. Представьте заработную плату сотруднику изменить, или уволить сотрудника. А размер заработной платы вообще вещь очень чувствительная. К таким данным надо относиться со всей заботой и безопасностью. Пришлось рядом с каждым подразделением, на той же инфраструктуре модернизировать препрод, сделать зеркало системы с похожими, но трансформированными данными. Уже сюда можно было вносить изменения и смотреть, как поведет себя система, и, если все работало (входные данные же практически неотличимы) мы знали, что и на проде всё тоже будет работать. Собственно, кейс подтверждался на 100%: сбои и на дублере, и на боевой системе происходили одновременно.


А как же мониторинг логов и мониторинг реальных транзакций?

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


Вот так, например, выглядит отчет о выполненных проверках:




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

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


Когда у тебя 10 инженеров и 200 оповещений в день внутри нескольких проектов интегратора, это не одно и тоже, когда у тебя 100 систем, 350 инженеров и 10 тысяч оповещений от систем мониторинга в день у крупной организации, где миллионы клиентов и десятки тысяч сотрудников.


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


Урок 2: цените критику

Самые ценные советы по развитию продукта дают те, кто от него отказывается.


В интеграторе было принято решение, что продукт надо развивать быстрее и было выделено дополнительное финансирование на расширение команды R&D. Были взяты на карандаш все требования ситуационного центра. А они были примерно такие:


  1. Ролевая модель доступа к разным объектам инфраструктуры;
  2. Написание правил эскалации из интерфейса, желательно в визуальном конструкторе;
  3. Шаблоны оповещений для разных групп пользователей;
  4. Возможность подключать разные системы мониторинга, такие как Zabbix или SCOM;
  5. Автоматическая регистрация инцидентов в системе Сервис-деск не через почтовый канал;
  6. Просмотр информации по инциденту (протокол) из интерфейса системы.

Заказчик в 2016 году архитектуру своего мониторинга видел так:



Требования были разумные и полезные для развития продукта.


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


Урок 3: не теряйте коммуникацию и будьте упорными

Нам очень повезло, что заказчик не выбрал другой более зрелый продукт известного западного вендора. Если бы мы не напоминали о себе, скорее всего так бы и произошло.


Так, например, в итоге стали выглядеть правила в конструкторе правил и действий:



Зонтичный мониторинг


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


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


Приходилось обмениваться скринами из своих мониторингов, показывать, доказывать, а время шло, инцидент висел в работе, клиенты оставались без сервиса. И так было несколько лет и воспринималось нормой.


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


На эту тему у меня есть картинка, которая говорит, что прогресс, если он нужен людям, победит.




Человек на картинке с красным флагом (или лампой) предупреждает людей о приближении автомобиля. Это требование Locomotive Act 1865. Его отменили в 1896 году, 31 год спустя запуска на дорогу первого автомобиля. Представьте, через какой протест прошли первые автостроители.

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


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


Урок 4: не бойтесь тяжелой работы

Трудности обязательно будут. Преодолеть их поможет только трудолюбие и стремление к результату.


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




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




А вот такой экран здоровья систем появился не так давно:


Развитие продукта


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


Продукт развивался вместе с развитием требований заказчика. В 2019 году появилась автоматизация, был сделан большой рефакторинг бэкэнда и фронтенда, в 2020 году появился анализ логов, аналитические модели с использованием ML. Сейчас мы понимаем, кто наши конкуренты и что мы делаем, какое у нас позиционирование, что мы AIOps-платформа. Мы в 2019 году также изменили название, стали называться платформой MONQ, вывели продукт в отдельный спин-офф, получили статус резидента Сколково. В 2020 году стали наконец-таки операционно прибыльными, победили на Startrup Village, но это все уже другая история, которая относится к другой стадии стартапа.


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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru