Основные принципы мониторинга бизнес процессов

Рассмотрим основные принципы мониторинга бизнес процессов, а именно бизнес-приложений, которые ежедневно используются во всем мире. Бизнес-приложение – это программный комплекс, который обеспечивает поддержку определенного бизнес-процесса какой-либо компании.
Самый наглядный пример, это архитектура современного приложения-«трехзвенка» или веб-страница, также сервер приложений. Данные компоненты полностью влияют на работу приложения. Если использовать данную конфигурацию, то она будет выглядеть как на рис.1.
Периоды недоступности или низкой производительности компонента проецируются на общую доступность приложения, которую ощущает на себе пользователь, то есть, даже при том, что нынешние прикладные системы могут обеспечивать свою доступность сильно за 90%, общая производительность всего бизнес-приложения может не дотягивать и до 90%. В реальном мире картинка выше может выглядеть как-то по-другому, но суть всегда одна -это непредсказуемость характера влияния мельчайших проблем с компонентами приложения на весь программный комплекс в целом.
В компании могут возникнуть ситуации, когда определенные периоды недоступности одного из звеньев приложения в итоге выливаются в периоды низкой производительности либо полной недоступности пользовательского веб-интерфейса. Если ИТ-ландшафт компании сложный, то бывает весьма затруднительно разобраться, какой именно слой является источником проблемы и к кому обращаться за ее решением. Данную ситуацию можно рассмотреть на рис.2.
В данной ситуации проигрывают все. Пользователи могут почувствовать, что ИТ их не понимает, руководитель будет задействовать ИТ для решения конкретной ситуации и также самого главного босса, который в свою очередь задействует ИТ-менеджеров. Далее ИТ-менеджер уже задействует администраторов, а администраторы в свою очередь предоставляют результаты своих систем мониторинга. Данная ситуация может длиться очень долго, до тех пор пока проблема самоустраниться, либо ИТ-администраторы будут проводить диагностику и следовательно найдут причину. Бывает такое, что проблему решить самостоятельно нельзя, тогда заводиться кейс у вендора соответствующего софта и данная процедура может затянуться на очень долгий срок.
Любая прикладная система требует мониторинга, и не всегда в компании есть для этого нечто промышленное. В данной ситуации администраторов выручает встроенный механизм мониторинга приклада, а если его нет, то может быть некий хорошо зарекомендовавший себя скрипт, который запускается на регулярной основе. Администратор использует удобные и понятные для себя инструменты.
Например, возникло радикальное снижение производительности приложения или его полная недоступность. Механизм запуска скрипта не используется и не лучшая идея доказывать ИТ-директору, что мониторинг все-таки был, но скрип выдает exception. Встроенный мониторинг хорош тем, что учитывает особенности приложения, но опять-таки владельцу приложения может быть не очень удобно собирать разнородную информацию со всех администраторов и отчитываться перед руководством о непрерывности бизнес-процесса, который поддерживает приложение. Администраторы прикладных систем не должны тратить время на поддержку системы мониторинга, данную работу лучше переложить на специально обученных сотрудников, которые будут находиться внутри компании или внешних подрядчиков.
Можно рассмотреть, что можно сделать для формирования беспроигрышной ситуации. Чтобы начальство не задавало дополнительных вопросов, менеджер по доступности такого сервера имеет оперативную информацию о состоянии всех компонентов систем, участвующих в основном (и не очень) бизнесе компании. Таким образом система мониторинга, которая охватывает все части бизнес-приложения, используя стандартные модули мониторинга (конечно, всегда есть возможность наравне со стандартными средствами использовать скрипты, либо вообще промышленную систему мониторинга). Данную ситуацию, так называемую heat map, т.е. карты сервисов можно рассмотреть на рис.3.
Таким образом, у сотрудников ИТ-подразделения или менеджера бизнес-сервиса есть возможность буквально «держать руку на пульсе» и в любой момент времени иметь представление о том, где возникла проблема, и у кого можно узнать о сроках решения, чтобы отчитаться перед пользователями или руководством

.
Данный уровень промышленных систем мониторинга позволяет производить глубокий контроль и рассчитывать уровень доступности бизнес-приложения. Важным это может быть, когда ИТ-департамент представит бизнесу набор услуг или серверов, по которому заключено соглашено об уровне обслуживания. Система мониторинга позволяет формировать отсчеты с необходимой детализацией, также позволяет накапливать статистику и понимать какие компоненты бизнес-приложения недостаточно производительны, а также позволит бизнесу понять, как качественно представлен ИТ-сервис.
Также понять мониторинг бизнес-приложения помогает пользователь, так как пользователи наиболее чувствительны к снижению производительности или недоступности приложения. Для этого пишется специальный алгоритм, который будет запускать браузер, также производить авторизацию в приложении.
На примере, интернет-магазина можно рассмотреть браузерную транзакцию. Измеряется затраченное время на каждый шаг – первое загрузка страницы в браузер, время на авторизацию пользователя, время на поиск товара, и межстраничные переходы, далее проверяется успешное выполнение каждого шага и транзакции в целом.
Система позволяет контролировать, загрузились ли конкретные изображения, также есть возможность распознавать текст со страницы (OCR-метод) и сравнивать его с чем-нибудь или просто записывать. Можно получить тайминг транзакции, т.е. на каждом шаге запускается таймер, который измеряет время его выполнения и проверяет на успешность, чтобы владелец приложения мог понять, на каком шаге произошел сбой.
Условный пользователь может сообщить, что в приложении произошел сбой, то можно предоставить результаты транзикций и объяснений, также помогут избавиться от ненужных активностей по поиску надуманных пользователем проблем.
Инструмент, который позволяет получать информацию о наличии проблемы на самой ранней стадии (даже до начала обращения пользователей в службу поддержки). Успешность/неуспешность выполнения транзакции (или ее доступность) система мониторинга может позволять привязывать к бизнес-сервису (если говорить о сервисно-ресурсной модели) и настраивать степень ее влияния на сервис в целом (т.н. вес связи). Пример, сервисно-ресурсной модели, можно рассмотреть на рис.4.
Для бизнес-приложений, которые хотят сотрудничать со своими пользователями, существуют системы мониторинга реальных транзакций, которые более технологичны. Такие системы выглядят, следующим образом, их можно увидеть на рис.5.
То есть весь HTTP/HTTPS трафик, который маршрутизирован на веб-сервер или ферму веб-серверов, зеркалируется на специальный коллектор (на схеме обозначен как Collector). Далее происходит его анализ и формирование заранее заданных представлений (иногда называются дашлетами от англ. dashlets). Такого рода мониторинг можно используют, например, как механизм отладки веб-приложений для поиска низкопроизводительных компонент, либо определения алгоритмов перехода пользователя между страницами, определения географической локации пользователя, типа браузера. Можно также рассмотреть пример дашборда анализатора сетевого трафика, представленного на рис.6.
Рассмотрим «стакан» в правом в верхнем углу. Это заранее заданный алгоритм перехода пользователей между страницами, который подсчитывает, сколько пользователей переходят от одной страницы к другой именно в таком порядке, и сколько пользователей выходят из этой последовательности и на каком шаге. Строить графики и делать отчеты можно практически по любому параметру, который передается в HTTP заголовках (имя пользователя, его id и т.п.), т.е. система действительно гибкая и готова подстраиваться под потребности заказчика.
Можно рассмотреть и глубокую диагностику бизнес-приложения (особенно актуально для заказных разработок). Такого рода анализ могут делать системы типа Application Diagnostics, диагностику можно производить как для JAVA, так и для .NET приложений