системы интеллектуального мониторинга что это
Системы интеллектуального мониторинга что это
Информационный мониторинг входит в топ-10 технологий, которые являются определяющими для современного рынках IT. Как можно стать специалистом в данной области и какие карьерные перспективы она открывает?
Самый яркий пример использования этой технологии — внедрение в медицинских учреждениях по всему миру системы IBM Watson, которая позволила создать «умные больницы», где большую часть работы по постановке диагноза осуществляет компьютер. Такая потребность связана с тем, что даже в XXI веке от врачебных ошибок в только в США ежегодно погибает от 200 до 400 тысяч человек. Опытный онколог ошибается в 40 % случаев. При определении сердечных заболеваний кардиологи ошибаются в 30 % случаев. И не потому, что врачи имеют низкую квалификацию. Просто объём оцениваемых данных, анализов, размытых симптомов, лекарств и так далее превышает способности мозга к анализу, по некоторым данным, в 200 раз. Информационный мониторинг же допускает ошибку лишь в трёх процентах диагнозов. И всё благодаря тому, что система комплексно анализирует медицинские карты, исследования, компьютерные диаграммы, рентгеновские снимки и на основании огромного количества параметров ставит точный диагноз.
Интеллектуальный мониторинг на производстве
Также особенно высока потребность в интеллектуальном мониторинге у крупных промышленных предприятий и сложных производств. Ведь в этом случае речь идёт о безопасности людей и защите окружающей среды. Данные со множества датчиков на разных объектах и стадиях производственного процесса фиксируют параметры, которые формируются в огромный поток информации — Big Data, который необходимо обработать так, чтобы использовать для защиты инфраструктурных систем. Именно этой теме и будет посвящена новая магистерская программа «Интеллектуальный мониторинг инфраструктурных систем», которую IT-центр Московского авиационного института запускает уже в этом году.
Руководитель новой магистерской программы Сергей Нагибин, д. т. н., профессор заведующий кафедрой № 319 МАИ, генеральный директор ООО «РКСС — Программные системы»:
Интеллектуальный мониторинг — это прогнозная аналитика. Можно предсказать, когда случится авария на данном предприятии. Мы, например, уже два раза предсказали возможность наступления аварии на одном из предприятий, где установлена система интеллектуального мониторинга. А аварии могут приводить к гибели людей, экологическим катастрофам. Сейчас идёт внедрение системы интеллектуального мониторинга на предприятия топливно-энергетического комплекса в рамках системы дистанционного контроля промышленной безопасности.
Данные, которые поступают в систему мониторинга, различаются по качеству. Часть из них относится к процессу, в связи с которым они получены, но часть — к сбою аппаратуры, недостаточной точности измерений или качеству передачи информации. Для начала эти данные необходимо очистить, чтобы они соответствовали тому процессу, который описывают.
Вторая часть задачи — эффективно использовать полученные данные. Причём не просто контролировать происходящее и вовремя принимать правильные решения, но и прогнозировать развитие ситуации и заранее предсказывать, когда может наступить сбой. С помощью мониторинга можно оценивать, что происходит, определять внештатные ситуации и быстро с ними справляться. Это и есть рискоориентированный подход.
В современном мире 50 % знаний в области IT устаревают за пять лет. Это значит, что через пять лет вы просто не будете понимать, что происходит, если не будете постоянно учиться. Кроме того, каждые два года объём информации, который циркулирует вообще в мире, увеличивается в два раза. Не случайно Ginny Rannety (CEO IBM), заявила, что в течение ближайших пяти лет все компании на рынке разделятся на победителей и побеждённых — в зависимости от качества аналитики.
Уже сейчас есть уверенность, что такая специальность будет высоко востребована на рынке труда в ближайшие годы. Причём как в промышленности, так и в медицине, банковском секторе, ЖКХ и многих других отраслях
Партнёр программы «Интеллектуальный мониторинг инфраструктурных систем» Валерий Владимирович Шилов, к. т. н., профессор факультета компьютерных наук Высшей школы экономики:
Мониторинговых систем много, но здесь добавляется слово «интеллектуальный», потому что есть слой интеллектуального анализа данных и информации. Дальше мы можем добавить слово «особо опасных» или «особо важных» объектов. Это могут быть промышленные объекты или другие объекты хозяйствования.
Таких предприятий свыше 1000 по стране, и это только особо опасные производства. Заинтересованы в интеллектуальном мониторинге и банки. Одно дело — регулярно ездить с ревизиями, и совсем другое — осуществлять мониторинг их в реальном времени. Мы хотим внедрить новацию, которая востребована на рынке, но никто пока не готовит для нее специалистов. Поэтому выпускники такой магистратуры, безусловно, тоже будут востребованы.
Мы поставили на кафедру макет нашей системы «Зодиак», на котором студентов уже начинают обучать. Она является зонтичной системой, у которой нет аналогов. Такая система охватывает не только информационную составляющую, но и финансовую, системы электронного документооборота, бухгалтерию, промышленное производство и т. д.
Самое важное при обучении — уже существующие программные комплексы, которые работают с реально существующими предприятиями и решают не теоретические, а реальные практические задачи.
Эта система уникальна, и она планируется к установке на всех особо опасных предприятиях России. И если раньше хозяева предприятий часто экономили на безопасности, сейчас уже разработана концепция проекта федерального закона «О промышленной безопасности». А значит, совсем скоро потребуется огромное количество специалистов в этой области. Поэтому данная магистерская программа вполне актуальна и очень интересна.
Но даже если по окончанию магистратуры выпускник не захочет или не сможет работать на подобных предприятиях, знания, которые студенты получат в процессе обучения, могут быть применены в самых разных областях. Сильный математик, сильный программист, человек, который может общаться с нейронными сетями, найдёт себе десятки, а то и сотни применений. И конечно, не приходится сомневаться, что подобная работа уже сейчас предполагает достойную оплату.
Люди, которые у нас работают и которые уже являются специалистами, получают от 180 000 и более рублей. Молодые специалисты начинают зарабатывать от 80 000 рублей, а дальше, если проявляют себя в течение года, ставка повышается.
Учёба в новой магистратуре: к чему готовиться?
Выпускники бакалавриата часто не знают математику потому, что не применяют её на практике. Мы надеемся, что те знания из дополнительных разделов математики, которые им будут даны, тут же смогут быть использованы в профессиональной части, связанной с машинным обучением и с нейросетями. Как раз здесь они должны выполнять достаточно большой объём таких практических заданий. Есть задача, есть данные, нужно с этими данными поработать, их очистить, создать большое количество наборов данных, на этих данных построить нейросеть, спроектировать её, обосновать, какой тип должен быть у нейросети, обучить её, добиться того, чтобы она с хорошими показателями решала те или иные задачи.
Вести обучение по новой программе будут высококвалифицированные преподаватели-практики, которые не только теоретически владеют темой, но и сами имеют релевантный опыт работы в данной сфере.
Во время обучения мы будем привлекать студентов к практической работе в нашей компании, где они будут проходить стажировку. Будем давать лабораторные задания и курсовые, которые связаны с построением нейронных сетей. Ну а если они станут показывать хорошие результаты — приглашать их на работу. Поступить в магистратуру можно уже этим летом. Правда, придётся пройти вступительные испытания. Бюджетных мест в магистратуре немного. Возможен серьёзный конкурс. Но бояться не стоит. Интерес к проблеме желание учиться и работать — это самое главное.
Единая система мониторинга и оповещений BI: правда или вымысел?
Привет, Хабр! Мы, Юлия Лузганова HiJulia и Наталия Прудникова balzaant, аналитики в команде Business Intelligence Delivery Club. Наш департамент аналитики стремительно вырос за последние полтора года, сейчас в нем 50 человек и десятки различных проектов. Мы в группе BI-аналитики помогаем пользователям получать чистые и актуальные данные. Например, количество заказов, работающие рестораны и время доставки заказов — одни из главных сущностей. Наша основная задача — своевременная и бесперебойная поставка данных в аналитическое хранилище и их подготовка к дальнейшему использованию. Для этого нам необходимо оперативно выявлять проблемы с загрузкой и обработкой информации.
В этой статье мы хотели бы рассказать о создании мониторинга и системы “near real-time” оповещений. С технической точки зрения реализация простая, а вот нервных клеток разработчиков DWH, BI и пользователей после внедрения сохранено бесконечно много.
Почему мы вообще потратили время на создание системы оповещений для команды аналитики? Все просто: нам хотелось меньше заниматься поддержкой, а точнее, мы стремились минимизировать ручной мониторинг загрузки данных, состояния базы и отправки отчетов, чтобы автоматически оповещать пользователей базы данных об изменениях, неоптимальных запросах или активно растущих в объемах таблицах.
В статье вы найдете заметки, которые помогут вам реализовать подобную систему, а также идеи для автоматических оповещений. Также расскажем, как используя логи задач и немного статистики, мы выявляем аномалии в работе процессов.
Сразу к делу, или Как все устроено
Описанную систему оповещений можно переложить практически на любую инфраструктуру. Что касается стека проекта, то на момент написания статьи это база данных PostgreSQL, ClickHouse, Jenkins в качестве планировщика и Tableau как BI-инструмент. Сейчас мы переезжаем на новую инфраструктуру, в основе которой лежит Hadoop, и система оповещений будет развернута там с некоторыми изменениями. Мы обязательно расскажем об этом в блоге Delivery Club, поэтому подписывайтесь.
В качестве канала связи для оповещений мы выбрали Telegram, так как практика показала, что оперативнее всего команды реагируют именно там. Но также мы запускали оповещения в Slack, по почте, исследовали возможность реализации в корпоративном мессенджере Myteam — везде можно было внедрить это решение.
Схема реализации представлена на рисунке: приложение состоит из агентов, собирающих оповещения и сохраняющих их в управляющую таблицу DWH, и собственного Telegram-бота, отправляющего оповещения в чаты Telegram. Для более гибких настроек используется конфигурационный файл.
Агенты — это отдельные скрипты, которые собирают логи для отправки оповещений. Агенты написаны на SQL и Python. Результатом их работы являются записи оповещений в управляющей таблице в DWH. В строке, которую передает агент, есть все необходимое для отправки: сообщение, каналы, для которых оно предназначено, ключ сообщения (при его наличии, чтобы избежать повтора оповещения), флаг решения проблемы.
Управляющая таблица DWH — это место хранения логов для отправки, которые пишут агенты. Разработчик всегда может обратиться к этой таблице, чтобы понять природу оповещения: что за агент записал оповещение, какое пороговое значение превышено, кому предназначалось оповещение и во сколько оно было отправлено.
где chat_id — это номер чата из пункта 3, а message — тело сообщения.
Как правило, единый чат для оповещений на 100+ человек — это нерабочий вариант с точки зрения потребителей этих оповещений. В какой-то момент сообщений становится слишком много, пользователи не читают канал или вообще архивируют его. Поэтому мы сделали сегментированные каналы для различных групп пользователей: разработчиков, аналитиков, продуктовой команды.
При реализации мы поняли, что нам нужен более гибкий инструмент конфигурации. Например, чтобы отключать оповещения для конкретной задачи или вручную изменить владельца объекта для агента. В качестве быстрого решения могут быть предложены Google-таблицы. Использовать их необязательно и при необходимости можно заменить на любой пользовательский интерфейс, интегрированный с хранилищем данных.
Типы оповещений от агентов
Пользовательские процессы в базе данных
Оповещение о недоступности данных к ожидаемому времени. Мы ушли от ручного оповещения. Если к определенному с бизнесом времени данные загружены не полностью или есть ошибки в расчетах, то агент автоматически передаст сообщение для канала аналитики. После загрузки всех данных агент также проинформирует об этом.
Оповещение о росте размера таблиц в DWH. Структура команд подразумевает наличие доступа в DWH у всех членов команды аналитики. Есть отдельная схема-песочница, где каждый может создавать любые сущности и производить вычисления. Мы создали агента, который следит за размерами таблиц на SSD и оповещает владельцев слишком больших таблиц. В этом случае пороговые значения установлены по своему усмотрению.
Оповещение о блокирующих процессах DWH. Опытным путем мы обнаружили, что нередко пользователи могут заблокировать своим запросом другие процессы. В некоторых случаях это критично, так как влияет на обновление данных. Агент отслеживает блокировки длительнее 30 минут и информирует об этом пользователей.
Оповещения о долгих пользовательских запросах в DWH. Мы установили такие пороговые значения: в дневное время пользовательский SQL-запрос не должен превышать 2 часа, а в ночное время — 30 минут. Если запрос длится дольше, то агент его принудительно остановит и оповестит владельца запроса.
Информационный блок
Оповещения об изменениях в DWH. Агент записывает в хранилище информацию обо всех изменениях: интегрировании новых источников данных, удалении или добавлении таблиц и колонок.
Продуктовый блок
Оповещения об аномалиях в продукте. Агент отлавливает аномалии в приложении под iOS и Android в реальном времени с помощью составных KPI. Примеры KPI: доля пользователей, обратившихся в поддержку после создания заказа за последний час, или доля пустых выдач поиска за последний час. Эти оповещения помогают команде в кратчайшие сроки реагировать на потенциальные неполадки.
Эксплуатация и мониторинг
Оповещения о неуспешном завершении задач. Если процесс завершился со статусом “failure” или “aborted”, то соответствующая запись будет передана в управляющую таблицу для последующей отправки оповещения. Агент собирает логи задач через API Jenkins.
Оповещения о неполноте данных. Агент отвечает за проверку полноты ключевых данных в хранилище. Заранее определяются KPI для каждой области, и если они не соответствуют пороговым значениям, то сообщение будет передано в канал BI. В первую очередь, это сигнал, что данные загружены не в полном объеме или имеются логические ошибки в расчетах.
Оповещение о свободном месте в DWH. Так как бизнес Delivery Club быстро растет и расширяется, объем данных значительно увеличивается ежедневно. На текущий момент мы в процессе переезда на новую инфраструктуру, но пока требуется мониторинг свободного места. Оповещение предусмотрены, если на HDD или SSD значительно сократилось место и требуется вовлечение команды BI.
Оповещения об аномальном времени выполнения задач. Если задача работает дольше обычного, то отправляется сообщение на команду BI. Агент обращается к API Jenkins, чтобы получить текущие состояния работающих процессов, затем разработанная модель обрабатывает полученные данные на предмет аномалий.
Модель по выявлению аномалий в работе процессов — это нетривиальная задача, ведь продолжительность работы каждой задачи зависит от множества факторов и может варьироваться ежедневно. Далее расскажем, как мы реализовали подобную модель, динамически рассчитывая допустимый интервал для каждого процесса.
Ловим аномалии на лету
Ежедневно наш планировщик Jenkins запускает около 700 различных задач. За сутки выполняется более 10 тысяч сборок (“сборкой” в контексте статьи мы называем каждый отдельный запуск задачи планировщиком). Конечно, в его интерфейсе есть инструменты, позволяющие мониторить процесс сборки задач без доработок, но для этого нужно посадить отдельного оператора Jenkins (и не одного, ведь мониторинг нам нужен круглосуточно).
Мы хотели получить инструмент, позволяющий автоматически отслеживать все сбои и аномалии в наших процессах с минимальным участием человека. На рынке есть готовые решения для мониторинга процессов Jenkins (например, Datadog plugin), но они в основном являются платными и не покрывают всех необходимых для нас задач, в том числе по настройке оповещений. Кроме того, у нас уже были наработки по получению данных из Jenkins. Поэтому решили создать собственный мониторинг на стороне аналитического DWH.
С чего все началось
Ранее мы разработали процесс регулярной загрузки через Python API Jenkins в DWH следующих данных:
Выше описано, как мы наладили мониторинг результатов сборок и стали узнавать о падениях в реальном времени с помощью системы оповещений в нашем Telegram-канале. Это сильно ускорило реагирование на проблемы, но подходит только для завершившихся сборок. А ведь часто возникают ситуации, когда нам нужно узнавать о возникших проблемах еще до того, как задача упадет:
В итоге мы пришли к динамическому расчету допустимой длительности выполнения каждой задачи. Мы регулярно в реальном времени отслеживаем время работы запущенных сборок и оповещаем в случае превышения верхней границы. Как мы это реализовали и о какие подводные камни споткнулись, читайте дальше.
Подход к решению
Мы определились, что модуль мониторинга продолжительности сборок должен быть прост в создании и поддержке. С учетом текущего стека и экспертизы решили разрабатывать на Python + PostgreSQL. Для выявления аномалий в длительности задач использовали медианное абсолютное отклонение (MAD). Этот подход аналогичен методу трех сигм, но последний предполагает нормальное распределение данных, и в результате нам пришлось от него отказаться. Кроме того, нам требовалась устойчивость к выбросам, поэтому остановились на использовании медианы. Такой подход к выявлению аномалий подробно описан в статье Leys, C., et al., Detecting outliers: Do not use standard deviation around the mean, use absolute deviation around the median.
Медианное абсолютное отклонение — это устойчивая мера рассеяния данных. Получить ее значение можно рассчитав медиану выборки и вычислив расхождения между каждым значением и медианой. MAD является медианой полученных расхождений:
MAD похоже на стандартное отклонение, но поскольку медиана меньше зависит от крайних значений, MAD более устойчиво к выбросам.
Как работает модуль
1. Расчет интервала
Для начала мы включили все критически важные процессы загрузки данных, без которых встанет работа отдела, и исключили технические задачи, которые не влияют на остальные процессы. А остальные отфильтровали по параметрам:
В нашей системе параметры job_quantity и outlier_mult управляются через конфиг с учетом специфики задачи, времени работы и частоты запусков. Пример расчета верхней границы допустимого интервала для одной задачи на основе тридцати сборок показан ниже.
Рассчитанные пороговые значения записываются в DWH для дальнейших проверок работающих сборок. Границы интервалов регулярно актуализируются в зависимости от частоты запуска. Например, для задач, которые собираются один-два раза в сутки, пересчет границ происходит каждый день, а для задач, собирающихся раз в час и чаще, пересчет выполняется каждый час.
2. Анализ запущенных задач
К уже имеющимся данным из Jenkins мы добавили определение запущенных сборок в данный момент. Каждые 5 минут при помощи методов get_running_builds и get_build_info из питоновской библиотеки python-jenkins мы получаем информацию о запущенных на данный момент сборках и их длительности, сравнивая его с допустимыми интервалами. Если текущая продолжительность сборки превышает верхнюю границу, то записываем информацию в DWH и исключаем сборку из дальнейших проверок. То есть по каждому инциденту в DWH сохраняем только одну запись, чтобы не дублировать оповещения для мониторинга.
3. Оповещение о проблемах
После выявления аномально долгих сборок необходимо оповестить команду о наличии проблемы. Следом за мониторингом запускается процесс, который проверяет наличие новых записей об аномальных сборках в DWH и отправляет в Telegram-канал уведомление с названием задачи и ссылкой на сборку в Jenkins для проверки.
Изначально мы понимали, что на первых порах нам все равно потребуется ручная проверка каждого случая оповещений. Тем не менее запуск модуля существенно ускорил реагирование на проблемы и позволил выявить несколько проблем в начальной стадии: мы смогли отловить и блокировки процессов, и зависания источников данных.
Какие возникают проблемы
Помимо этого для некоторых задач со временем возникают особенности распределения продолжительности сборок: тенденция к росту с увеличением количества обрабатываемых данных или сезонность. Под сезонностью мы понимаем зависимость времени работы сборки, например, от дня недели, поскольку в выходные требуется обработать значительно больше записей, чем в будни. В таких ситуациях использование метода MAD будет не очень удачным и требуются дополнительные меры для корректной оценки выбросов. Для сезонных задач имеет смысл рассчитывать интервалы за соответствующие периоды (например, оценивать сборки отдельно за понедельник, вторник и т.д.). Минус такого подхода в том, что он предполагает достаточно большую историю наблюдений. Для применения MAD к задачам с тенденцией роста или уменьшения продолжительности времени сборок можно использовать один из методов сглаживания (например, скользящее среднее или метод Хольта).
Немного о наших планах
Запуск модулей помог нам ускорить получение данных в хранилище и сократить количество инцидентов с блокировками и зависшими процессами. Нам пока не удалось до конца устранить ложные оповещения об аномально долгом времени работы. В дальнейшем мы планируем развивать подход к выявлению аномалий в ситуациях сезонности или тенденции роста продолжительности работы, а также для слишком чувствительных задач. В том числе мы будем тестировать другие модели выявления аномалий в подобных задачах. Задача определения тренда также важна, так как позволит автоматически выявлять случаи, требующие оптимизации.
После усовершенствования подхода к распознаванию аномалий и устранения ложных оповещений мы планируем доработать модуль для автоматической остановки аномально долгих сборок через API Jenkins. Это поможет нам еще больше ускорить загрузку данных в хранилище.
Также мы планируем доработать мониторинг для распознавания сборок, которые завершаются раньше нижней границы допустимого интервала. Слишком низкая продолжительность может быть сигналом, что не все данные были доступны на момент запуска сборки или не отработали некоторые шаги в задаче.
В качестве идеи для последующего развития системы оповещений можно рассмотреть оповещения, связанные с BI-системой. А именно, управление лицензиями, появление новых дашбордов и источников данных.
Учитывая, что наш отдел сейчас активно переезжает на новую инфраструктуру, в основе которой будет Hadoop, Vertica и Airflow, в ней тоже потребуется прорабатывать системы мониторинга и оповещений и адаптировать имеющиеся подходы под новый стек.
Зачем нужен комплексный мониторинг ИТ и бизнесу и КАК его внедрять?
На «Хабре» есть статьи о том, как внедрять мониторинг. В них описано, как надо и не надо организовывать систему мониторинга. Все эти статьи мы прочитали и поняли, что чего-то не хватает. Здесь не будет информации о важности разработки ресурсно-сервисной модели и о том, как уменьшить число ложно-позитивных сообщений о проблеме. Мы поделимся лайфхаками в работе команды, которые помогают реализовывать подобные проекты. Дальше будут такие рекомендации, которых в других статьях нет. Советы собраны на основе нашего опыта.
Комплексный мониторинг позволяет компаниям понять, где они теряют деньги
В компаниях всегда есть бизнес-подразделения. Они смотрят, где компания может больше зарабатывать и меньше тратить. Часто они обращают внимание на внутренние ИТ-системы. Если в ИТ-системах возникают инциденты, компания будет терять деньги. Например, рухнула платёжная система. Или регистрация стала сложнее, потому что её модифицировали. Или процесс оплаты неудобен для пользователей – в нем 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 Анастасия Астафьева