Источник

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

Многие организации привязывают доступность бизнес-системы к доступности бизнес-процесса. Если бы я считал SLA, получилось бы, что доступность ИТ-системы упала до нуля (в момент превышения порога по памяти на каком-то там сервере), а бизнес-процесс остановился. Но это же не так!? Внизу дерева может быть кластер или, вообще, забивание памяти под завязку — нормальный режим работы системы. Короче, задача звучит так: как правильно рассчитывать доступность бизнес-процесса и не оглядываться на некритичные события от компонентов бизнес-систем? Её и разберем.

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

Представьте оператора мобильной связи и платформу продажи контента. Пользователь — альфа-самец, наткнувшийся на СМС с балансом от оператора. В конце сообщения он увидел предложение воспользоваться услугой ”Знакомства” всего за 99,99 рублей в день. В мимолетном тестостероновом порыве набрал короткий номер — подключил услугу. Деньги со счета, разумеется, тут же списались. Проходит полчаса, час, а предложения познакомиться всё не идут. Порыв заканчивается, да и масштаб потерь не велик, и пользователь забивает на это. Теперь он понял, что пользование подобными услугами ведет к потере денег. Оператор теряет доход.

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

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

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

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

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

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

А теперь подскажу, что нужно в общем случае для реализации такого алгоритма:

? определиться с составом процессов компании (что именно хотим контролировать);
? определить влияние ключевых метрик ИТ на эти процессы (например, доступность какого-нибудь канала, без которого не работает 50% бизнеса и звонит директор розницы);
? разложить влияние на отдельные системы, а их — на инфраструктуру и прочее;
? реализовать указанную модель двух контуров — контроль бизнес-процесса и ключевые события по транзакциям плюс диагностическая информация от ИТ-систем и инфраструктуры.

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

Автор статьи: Антон КАСИМОВ, архитектор систем мониторинга компании «Техносерв».