Что такое прикладной мониторинг
Принципы мониторинга бизнес-приложений
Приветствую всех читателей! Сегодня хотелось бы поговорить об основных принципах мониторинга бизнес-приложений, которые ежедневно используют многие компании по всему миру. Само понятие «бизнес-приложение» следует понимать как программный комплекс, который обеспечивает поддержку определенного бизнес-процесса компании.
Самый типичный пример архитектуры современного приложения — т.н. «трёхзвенка», т.е. веб-сервер, сервер приложений и сервер БД, следовательно, каждый из этих компонентов будет чуть менее чем полностью оказывает влияние на работу всего приложения. Если рассматривать именно такую конфигурацию, то со своего опыта могу сказать, что чаще всего возникает ситуация, которая в утрированном виде выглядит так:
Периоды недоступности или низкой производительности компонента проецируются на общую доступность приложения, которую ощущает на себе пользователь: т.е. даже при том, что нынешние прикладные системы могут обеспечивать свою доступность сильно за 90%, общая производительность всего бизнес-приложения может не дотягивать и до 90%. В реальном мире картинка выше может выглядеть как-то по-другому, но суть всегда одна — это непредсказуемость характера влияния мельчайших проблем с компонентами приложения на весь программный комплекс в целом. Ниже разбор что, как и почему, прошу под кат.
Сценарий, приближенный к реальному
В любой компании возникают ситуации, когда определенные периоды недоступности одного из звеньев приложения в итоге выливаются в периоды низкой производительности либо полной недоступности пользовательского веб-интерфейса (читай, основного функционала приложения). Если ИТ-ландшафт компании сложный, то бывает весьма затруднительно разобраться, какой именно слой является источником проблемы и к кому обращаться за ее решением. Если вернуться к визуализации такой штуки, то это все можно изобразить следующим образом:
Получается ситуация lose-lose, т.е. проигрывают все. Пользователи чувствуют, что ИТ их не понимает, линейный руководитель для решения конкретной ситуации задействует ИТ и самого главного босса, который посылает лучи негодования ИТ-менеджеру. ИТ-менеджер в смешанных чувствах идет к своим администраторам, которые пытаются валить друг на друга, предоставляя результаты своих систем мониторинга (или работы самописных скриптов) и далее, далее, далее. В общем-то такая ситуация может длиться довольно долго, до тех пор пока проблема в лучшем случае самоустранится, либо все ИТ-администраторы придут к соглашению проводить диагностику каждый в своей системе и наконец найти корневую причину. По опыту коммуникаций с заказчиком могу сказать, что бывает еще такой сценарий, когда своими силами сделать ничего не удалось (в силу недостаточной экспертизы или других объективных причин), и заводится кейс у вендора соответствующего софта, что может растянуться уж совсем на неопределенный срок.
Есть еще момент, на котором остановлюсь подробнее. Любая прикладная система требует мониторинга, и не всегда в компании есть для этого нечто промышленное. В такой ситуации администратора в большинстве случаев выручит встроенный механизм мониторинга приклада, а в случае его отсутствия это может быть некий хорошо зарекомендовавший себя скрипт, запускаемый на регулярной основе. Отлично, что администратор использует удобные и понятные для него инструменты, а теперь допустим, что возник ахтунг планетарного масштаба (радикальное снижение производительности приложения или его полная недоступность). При этом механизм запуска скрипта решил какое-то время не исполняться и спокойно покурить в сторонке. В итоге размахивать перед ИТ-директором скриншотами, подтверждающими, что мониторинг всё-таки был, но вот скрипт выдал exception и scheduler споткнулся, может быть не лучшей идеей. Встроенный мониторинг хорош тем, что учитывает особенности приложения, но опять-таки владельцу приложения может быть не очень удобно собирать разнородную информацию со всех администраторов и отчитываться перед руководством о непрерывности бизнес-процесса, который поддерживает приложение. По моему мнению, администраторы прикладных систем не должны тратить свое драгоценное время на поддержку системы мониторинга, им стоит переложить этот функционал на специально обученных сотрудников внутри компании либо на внешнего подрядчика.
Как научиться понимать приложение
Что же можно сделать для формирования ситуаций win-win? Чтобы у больших боссов не возникало дополнительных вопросов на тему «а что вы делаете, чтобы такого больше не повторилось», и вы, как человек от ИТ (или менеджер по доступности такого-то сервиса), лишний раз не беспокоились, следует иметь оперативную информацию о состоянии всех компонентов систем, участвующих в основном (и не очень) бизнесе компании. Желательно на большом LCD-телевизоре, желательно с большими понятными подписями, цветовой индикацией (а-ля красный-жёлтый-зелёный) и, где-то рядом, списком фамилий напротив названий сервисов. А еще было бы здорово кликнуть мышью по сервису (который окрасился, например, в красный) и узнать, на каком звене возникла проблема. Таким образом, мы пришли к идее единой (а она может быть и зонтичной) системы мониторинга, которая охватывает все части бизнес-приложения, используя стандартные модули мониторинга (конечно, всегда есть возможность наравне со стандартными средствами использовать кастомные скрипты, либо вообще другую оупенсорсную или промышленную систему мониторинга). Ниже пример так называемого heat map, т.е. карты сервисов:
Таким образом, у сотрудников ИТ-подразделения или менеджера бизнес-сервиса есть возможность буквально «держать руку на пульсе» и в любой момент времени иметь представление о том, где возникла проблема, и у кого можно узнать о сроках решения, чтобы отчитаться перед пользователями или руководством. Очень полезен такой мониторинг бывает, когда вы проводите регламентные работы на большом количестве приложений (или их компонент) и хотите убедиться, что всё успешно восстановилось после перезагрузки, ведь тратить остаток ночи (ну, ведь правда, такие работы чаще всего проводятся по ночам) на ручную проверку всего «зоопарка» было бы не совсем рационально.
Нынешний уровень промышленных систем мониторинга позволяет производить глубокий контроль и даже рассчитывать уровень доступности бизнес-приложения. Особенно важным это может быть, когда ИТ-департамент предоставляет бизнесу набор услуг (или сервисов), по которым заключено соглашение об уровне обслуживания (SLA). Система мониторинга позволит формировать отчеты с необходимой детализацией, позволит накапливать статистику и понимать, какие компоненты бизнес-приложения недостаточно производительны, и, в конце концов, позволит бизнесу хотя бы как-то понимать, насколько качественно предоставлен ИТ-сервис. Но наиболее полное представление о работе приложения вы будете иметь, если с определенной периодичностью на среднестатистической рабочей станции будете делать то, что делает пользователь. Об этом ниже.
Как научиться понимать пользователя
Наконец, переходим к вопросу мониторинга бизнес-приложения с точки зрения пользователя, без этого вообще нынче никуда. Понятное дело, что конечные пользователи наиболее чувствительны к снижению производительности или недоступности приложения, и «видеть» их глазами было бы наиболее предпочтительным вариантом. Нанимать людей, которые будут, допустим, оформлять банковские проводки и сидеть с секундомером, замеряя время отклика веб-интерфейса того же Siebel, не самое лучшее занятие. Наиболее оптимальным вариантом в таком случае будет написание специального алгоритма (синтетической транзакции), который будет запускать браузер, производить авторизацию в приложении и перекидывать условную сумму в 1 рубль с одного счета на другой. Специально для дорогих читателей я написал браузерную транзакцию (есть еще транзакции с тяжёлыми клиентами) на примере одного известного интернет-магазина. По ней измеряется затраченное время на каждый шаг — первоначальная загрузка страницы в браузер, время на авторизацию пользователя, время на поиск товара и межстраничные редиректы и переходы – плюс проверяется успешное выполнение каждого шага и транзакции в целом.
Система позволяет контролировать, что загрузились конкретные изображения, также есть возможность распознавать текст со страницы (OCR-метод), сравнивать его с чем-нибудь или просто записывать, например, в БД. Можно получить тайминг транзакции, т.е. на каждом шаге запускается таймер, который измеряет время его выполнения и проверяет на успешность, чтобы владелец приложения мог понять, на каком шаге произошел сбой.
Получается, что если условный пользователь вам заявляет, что в вашем приложении все тормозит и глючит, вы сможете предоставить результаты таких транзакций и объяснить, что его случай уникальный и происходит в совершенном отрыве от реальности:) Если серьезно, то предоставление подобных графиков производительности поможем вам избавиться от ненужных активностей по поиску надуманных пользователем проблем.
В сухом остатке мы имеем инструмент, который позволяет получать информацию о наличии проблемы на самой ранней стадии (даже до начала обращения пользователей в службу поддержки). Успешность/неуспешность выполнения транзакции (или ее доступность) система мониторинга может позволять привязывать к бизнес-сервису (если говорить о сервисно-ресурсной модели) и настраивать степень ее влияния на сервис в целом (т.н. вес связи). Ниже пример сервисно-ресурсной модели:
Для тех, кто хочет еще больше понимать своих пользователей, существуют системы мониторинга реальных транзакций. Еще более круто, еще более технологично. Выглядят такие системы следующим образом:
Т.е. весь HTTP/HTTPS трафик, который маршрутизирован на веб-сервер (ферму веб-серверов), зеркалируется на специальный коллектор (на схеме обозначен как Collector). Далее происходит его анализ и формирование заранее заданных представлений (иногда называются дашлетами от англ. dashlets). Такого рода мониторинг можно использовать, например, как механизм отладки веб-приложений для поиска низкопроизводительных компонент, либо определения алгоритмов перехода пользователя между страницами, определения географической локации пользователя, типа браузера и т.п. Ниже приведен пример дашборда анализатора сетевого трафика:
Обратите внимание на т.н. «стакан» в верхнем правом углу окна. Это заранее заданный алгоритм перехода пользователей между страницами, который подсчитывает, сколько пользователей переходят от одной страницы к другой именно в таком порядке, и сколько пользователей выходят из этой последовательности и на каком шаге. Строить графики и делать отчеты можно практически по любому параметру, который передается в HTTP заголовках (имя пользователя, его id и т.п.), т.е. система действительно гибкая и готова подстраиваться под потребности заказчика.
Для отладки и мониторинга самописных приложений просто must have.
А что же на выходе
На выходе мы можем иметь зонтичное решение, которое будет получать данные о работе приложения из всех описанных источников и, что самое главное, полную картину того, что происходит внутри приложения, и как это отражается на нашем (не побоюсь этого слова) любимом пользователе, ради которого всё и затевается. На рынке немало софтверных вендоров, которые имеют весь арсенал описанных решений, и выбрать для себя оптимальное решение, исходя из бюджета, потребностей, ожиданий и т.п., может быть не так уж и сложно. Б̀о́льшую часть оупенсорсных и промышленных решений можно собирать как пазл: т.е. если у вас уже есть сетевой или инфраструктурный мониторинг от одного вендора, вы с большой долей вероятности сможете дополнить его, например, синтетическим мониторингом от другого вендора.
На сегодняшний день ИТ стремится приблизиться к бизнесу настолько, насколько это возможно, и оказывать влияние на стратегию компании в целом, а инструменты, в которые может заглянуть руководитель ИТ (или выше) и понять, что деньги потрачены не зря, в целом очень востребованы рынком.
Я попытался дать поверхностное представление о различных методах мониторинга абстрактного бизнес-приложения, и если у вас возникли вопросы, то с радостью на них отвечу. Будет также интересно узнать, какими способами вы решаете задачи мониторинга, и с какими проблемами приходится сталкиваться, особенно с учетом влияния нынешних внешнеполитических факторов. Спасибо за внимание!
Что такое мониторинг и его уровни
Поговорим о том, какие уровни мониторинга бывают и что стоит измерять и анализировать в IT-проектах.
Зачем нужен мониторинг и что это такое
Случается, что серверы падают и программы ломаются. Это неизбежно. Случайный баг, скачок напряжения в сети, сбои в подаче электричества — всё это может вызывать поломки.
Кроме того, помимо очевидных проблем, могут быть и куда менее очевидные. Например, менеджеры по продукту приняли плохое решение, реализовали плохую фичу и из-за нового релиза упала выручка. Технически код хорошо работает, серверы в порядке — но бизнес несет убытки.
Начнем снизу: мониторинг оборудования
Что бы вы ни запускали — у вас всё равно будут серверы в дата-центре, а у них есть определенные параметры производительности. Эти показатели надо мониторить на каждом сервере, обслуживающем ваших клиентов:
Список параметров вполне очевиден. Мониторинг этих значений позволяет диагностировать большую пачку неприятных ситуаций, которые могут привести к полному или частичному коллапсу инфраструктуры.
Для анализа поведения серверов в самом простом виде можно использовать штатные средства контроля по типу htop. Более гибкое и масштабируемое решение — Zabbix — он уже умеет анализировать основные параметры целого кластера серверов и собирать их в одной панели. Такое решение требует настройки со стороны квалифицированного администратора.
Поднимаемся выше: мониторинг состояния приложений
Допустим, мониторинг серверов у нас есть и они выглядят адекватно. Памяти много, нагрузка на процессор — незначительная. Наверное, всё хорошо организовано, клиентов немного, всё работает как часы? Может быть. Или всё упало, программы не запущены, клиенты не могут попасть на сервер и выполнить запросы? Тоже может быть.
Какой из вариантов правильный — подскажут метрики приложений.
У любого приложения должны быть параметры, по которым разработчики и администраторы понимают, что программа работает и в ней что-то делается. У каждой программы эти параметры свои, но вот несколько примеров, которые позволят понять, какие метрики нужно придумать для приложения:
У вас в системе 100 активных пользователей, они генерируют 1 000 запросов в минуту и у них случается 1 ошибка в час? Допустим, что всё хорошо. У вас в системе 3 активных пользователя, они генерируют 10 000 запросов в минуту и ловят 5 000 ошибок? Наверное, стоит начать беспокоиться. Даже если метрики нагрузки на процессор и диски в порядке.
Для мониторинга на этом уровне подойдет специализированная СУБД — Prometheus, Graphite, InfluxDB. С установкой самой базы данных проблем не будет, а вот посчитать и пробросить нужные метрики в базу — для этого понадобятся усилия программистов.
Для удобства анализа ко всем этим базам лучше всего подключить Grafana — графический инструмент для отображения статистики и метрик.
Есть еще специфические системы отлова ошибок в коде — они могут вовремя оповестить программистов о сбойной ситуации. Иногда этого вполне достаточно для базовой диагностики проблем. Хороший пример такой системы — Sentry.
Третий уровень: мониторинг бизнес-метрик
Конечная цель любой программы — решать чьи-то проблемы и получать за это деньги. Это значит, что для управленцев нужны метрики, которые расскажут:
Список метрик, которые нужны бизнесу, велик и зависит от конкретного проекта и индустрии. Лучше всего вам помогут разобраться с правильными параметрами менеджеры продукта.
Минимально здесь можно обойтись Google Analytics — базовые конверсии и переходы можно смотреть в готовых системах анализа пользовательского поведения. Более глубокое понимание ситуации потребует четкой и слаженной работы администраторов, программистов и ребят из отдела аналитики — они смогут правильно реализовать и посчитать тонкие поведенческие аспекты. Например, зависимость выручки от A/B-тестов на бэкенде.
Зачем нужен комплексный мониторинг ИТ и бизнесу и КАК его внедрять?
На «Хабре» есть статьи о том, как внедрять мониторинг. В них описано, как надо и не надо организовывать систему мониторинга. Все эти статьи мы прочитали и поняли, что чего-то не хватает. Здесь не будет информации о важности разработки ресурсно-сервисной модели и о том, как уменьшить число ложно-позитивных сообщений о проблеме. Мы поделимся лайфхаками в работе команды, которые помогают реализовывать подобные проекты. Дальше будут такие рекомендации, которых в других статьях нет. Советы собраны на основе нашего опыта.
Комплексный мониторинг позволяет компаниям понять, где они теряют деньги
В компаниях всегда есть бизнес-подразделения. Они смотрят, где компания может больше зарабатывать и меньше тратить. Часто они обращают внимание на внутренние ИТ-системы. Если в ИТ-системах возникают инциденты, компания будет терять деньги. Например, рухнула платёжная система. Или регистрация стала сложнее, потому что её модифицировали. Или процесс оплаты неудобен для пользователей – в нем 10 кликов вместо 2.
Чем сложнее архитектура бизнес-приложения, тем больше людей необходимо для ее обслуживания: мониторить системы, анализировать и диагностировать инциденты, вникать, как эти инциденты влияют на клиентов. Итог – потрачены часы на выяснение причин сбоя, кто виноват и что делать. Пока это делается, клиенты страдают, деньги компании тратятся, а время устранения инцидентов растёт. Компании приходится смотреть на шлейф всех этих проблем, а не в светлое будущее. Дальше разберёмся, почему так происходит.
Есть кое-что, что мешает быстро обнаруживать источник проблем. Это разрозненность средств мониторинга. Все вместе они не дают единой картины для всех ИТ-компонентов, которые влияют на работу бизнес-приложения. Бывает так, что задачи похожи или даже одинаковые, но повторно их решают другие люди другими инструментами. Нередко приходится сверять друг с другом показатели одних и тех же метрик.
Что будет, если вот это все заставить работать вместе? О плюсах комплексного мониторинга – далее.
Преимущества комплексного мониторинга
Внедрение единого комплексного мониторинга для бизнес-процессов и ИТ-систем – логичное решение. Вот, что сможет делать компания, которая внедрила комплексный мониторинг:
Оперативно обнаруживать и решать проблемы в работе приложений до того, как они повлияют на пользователей;
Оценивать качество работы приложений на основе объективного мониторинга работы пользователей с приложением, а не обращаться в службу поддержки;
Анализировать клиентский опыт на протяжении всего процесса взаимодействия пользователя с системой;
Оценивать работу подрядчиков. Сравнивать их по количеству пользователей, которые выбирают данную платформу;
Получить единую точку доступа к общей картине состояния ИТ, возможность исследования «вглубь» – до сырых данных, а также анализировать корреляции.
Какие правила при внедрении комплексного мониторинга мы выработали
Совет №1: Выделите отдельную целостную команду разработки системы комплексного мониторинга.
Вот, кто должен быть в команде:
Специалист по Data Science
Бизнес- и системные аналитики должны быть вовлечены в проект на 100% и играть роль Product Owner’а. Они общаются с командой разработки основного продукта компании: от администраторов до руководителей. Бизнес- и системные аналитики пишут требования к системе мониторинга, планируют релизы и проводят UAT. Они обучают конечных пользователей системы мониторинга.
ИТ-роли в команде можно совмещать: разработчик системы мониторинга и инженер данных, администратор и DevOps инженер.
Совет №2: Заведите мониторинг препродуктивной среды. Потом синхронизируйте релизные циклы команды разработки основного продукта и команды разработки системы мониторинга
Бизнес ставит задачу разработчикам оптимизировать процесс взаимодействия пользователей с платформой. Например, процесс регистрации, оформления покупки, оплаты или возврата средств. Это влечет за собой изменение логов и логики построения KPI. Чтобы это сделать, нужно строить синхронные процессы изменения логики бизнес-процессов сайта и их KPI. Это важно, чтобы одним утром после релиза не обнаружить, что мониторинг не работает.
Совет №3: Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно
Мониторинг не универсален. Он много от чего зависит. Например, от архитектуры систем и взаимодействия между ними, от пользователей мониторинга и их видения.
В проектах разработки и внедрения системы комплексного мониторинга лучше использовать спринты и Agile-подход. Процесс разработки в нашей команде упрощенно выглядит так:
Определяем один показатель или один бизнес-процесс для мониторинга
Делаем небольшие выгрузки данных, достаточные для построения KPI. Чем больше выгрузок, тем лучше. Изучаем данные и определяем минимально достаточные источники для построения KPI.
Реализуем KPI на основе выгрузок и демонстрации пользователя мониторинга.
Дорабатываем источники данных и их подключения.
Разрабатываем KPI на основе живых данных.
Дальше релиз и получение обратной связи.
Потом планируем доработки на основе отзывов. Усложняем KPI путём подключения новых источников. Повторяем цикл.
Совет №4: Не планируйте ресурсные затраты на разработку мониторинга на основе объема систем, покрываемых мониторингом, или по количеству метрик и KPI, запланированных в разработку – вы все равно промахнетесь
Этот пункт вытекает из предыдущего. Наша команда начала разрабатывать мониторинг с зафиксированным объемом и количеством KPI. Сначала мы реализовали несколько дашбордов. Потом перешли на спринты и запланировали только набор бизнес процессов, которые будут мониториться. В результате (а может в процессе) перехода выработался процесс разработки KPI. Тот, что описан выше.
Совет №5: Дайте пользователям системы мониторинга больше свободы
Пускай у пользователей будет возможность исследовать данные, на основе которых вычисляется KPI. Ещё хорошо, если они смогут реализовывать простейшие вычисления и разрабатывать собственные метрики.
Продуктовая команда знает о своем продукте всё. При общении с системными аналитиками они могут упустить некоторые детали в работе или архитектуре систем. Если дать им доступ к изучению сырых данных, вы повышаете интерес конечных пользователей к мониторингу. Может так получиться, что продуктовая команда заметит отклонение показателей. Тогда она начнёт исследовать причины отклонений. Для этого команда сформирует новые метрики – так в будущем обнаруживать подобные проблемы будет проще. Команде мониторинга останется только формализовать метрику и запустить в работу.
Совет №6: Предусмотрите возможность отображения показателей на дашбордах в разрезе разных отрезков времени
Рассмотрим пример: мы разрабатываем бизнес KPI «Процент успешно завершенных регистраций пользователей на сайте». Для разработки KPI необходимо выбрать промежуток времени, в рамках которого мы будем наблюдать за показателем, а также на основе исторических данных определить уровни критичности. Уровень критичности, или важность проблем, определяет какой процент успешно завершенных регистраций считается обычным поведением (обычно обозначается зеленым цветом), или, когда процент успешно завершенных регистраций очень мал, сигнализирует о серьезных проблемах и обозначается красным цветом. В зависимости от промежутка времени, за который мы рассчитываем «Процент успешно завершенных регистраций», уровень критичности может быть разным. Процесс регистрации, как правило состоит из двух основных шагов: заполнение формы на сайте и подтверждение почты путем перехода по ссылке из письма. Некоторые пользователи выполняют регистрацию за пару минут, а другим – требуется вспомнить или восстановить забытый пароль от своей почты, что может занять более 5 минут. Если мы будем вычислять Процент успешных регистраций в рамках 5 минут, то мы «потеряем» пользователей, которые завершат регистрацию за 7-8 минут, что может значительно повлиять на Процент успешных регистраций, и система будет сигнализировать о проблеме.
Поэтому, разрабатывая KPI, мы ориентируемся и выбираем промежуток согласно оценке от бизнес аналитика, но обязательно добавляем другие промежутки времени в интерфейс, чтобы иметь возможность анализировать реальное поведение пользователей.
Совет №7: Настраивайте self-мониторинг, чтобы сохранить доверие к системе мониторинга
Совет №8: Используйте стандартный функционал продвинутой аналитики «из коробки». Например, «Автоматический ML»
Когда мы подключаем новый источник, мы уже знаем, какие поля и значения мы будем использовать. Ещё мы знаем, как будем строить KPI. По возможности, подгружаем в систему мониторинга исторические данные.
Однако, мы всегда прогоняем их через встроенные аналитические инструменты. Полученные показатели и графики оставляем «пожить» в течение какого-то времени и «пережить» инциденты. В половине случаев обнаруживаем новые зависимости от других показателей и интересные аномалии. На основе этого рождаются новые KPI.
Совет №9: Не спешите передавать дашборды и направлять оповещения группе поддержки второй и третьей линии
Есть показатели, разрабатываемые в рамках комплексного мониторинга, а есть – в рамках инфраструктурного. Они сильно различны по своей природе и имеют совершенно разные понятия «нормы» и отклонения от нее.
«Комплексные» KPI строятся на основе корреляции разнородных бизнес и ИТ-показателей. Как правило, этим показателям присваивают веса, которые определяют влияние на «комплексный» KPI. Поэтому сразу определить понятие «нормы» и построить грамотный алертинг бывает очень сложно.
Команда разработки мониторинга должна брать на себя роль поддержки на какое-то время при релизе каждого нового дашборда или KPI. Это позволит получать обратную связь без посредников и дорабатывать «на ходу». Оповещений не должно быть много.
Есть специалист поддержки, который отвечает за решение проблемы или поиск её причин. Действия этого специалиста должны быть максимально понятными и простыми. Написано множество статей про лечение событийной усталости и о том, как грамотно настраивать алертинг.
Совет №10: Ведите историю инцидентов
ИТОГ: Выгоды от внедрения системы мониторинга
Мы собрали их пять. Вот они:
Система комплексного мониторинга является зонтичным решением для существующих систем мониторинга. Она объединяет агрегированные данные из других узкоспециализированных систем.
Комплексное решение закрывает все «слепые зоны», не покрытые существующими в компании системами мониторингами – сбор сырых данных из систем источников в комплексный мониторинг.
Появляется единая точка для анализа данных и расследования причин инцидентов.
Бизнес-аналитики, маркетологи, администраторы и руководители подразделений смотрят на одни и те же данные.
Все события имеют корреляцию по времени.
Ещё раз все наши рекомендации кратко:
Комплексный мониторинг внедряет отдельная команда, а не участники продуктовой команды;
Не упускайте мониторинг препродуктивной среды;
Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно;
Для внедрения комплексного мониторинга больше подходит Agile методология и отсутствие жестко зафиксированного скоупа;
При планировании закладывайте ресурсы продуктовой команды на доработку и изменение источников данных;
Пользователи системы мониторинга должны иметь возможность «покрутить» данные и метрики;
Дашборды должны иметь фильтры для настройки отображения метрик в разрезе 5 минут и 1 часа;
Разрабатывайте мониторинг для системы мониторинга. Особое внимание стоит уделить точкам взаимодействия системы мониторинга с источниками данных;
Аналитический функционал системы мониторинга, поставляемый «из-коробки», может быть полезен;
Не спешите передавать дашборды и направлять оповещения группе поддержки второй и третьей линии. Пусть команда разработки мониторинга поживет с ними сама, чтобы понаблюдать за количеством оповещений и по возможности сократить их количество;
Ведите историю инцидентов.
Статью подготовил консультант компании Accenture Анастасия Астафьева