Splunk: деликатный инструмент для развития бизнеса

Логотип компании
Splunk: деликатный инструмент для развития бизнеса
Вопрос подготовки данных, чтобы результат был максимально эффективным, — отдельная задача, предусматривающая анализ данных еще до загрузки в систему

В нынешних условиях искусство управления данными приобретает если не сакральный смысл, то, вне всяких сомнений, высочайший приоритет. Однако размеры данных и риски, связанные с ними, предполагают применение самых современных и эффективных инструментов управления. О том, как эта задача решается в компании «Мегафон», рассказывает Дмитрий Никитенко, руководитель по системам анализа и обработки данных.

Дмитрий, какие задачи, стоящие перед компанией, мотивировали вас на поиск и выбор инструмента управления данными?

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

В компании «МегаФон» генерируются огромные потоки данных – множество ИТ-систем в реальном времени формируют массивы разнообразных сведений. К примеру, содержат информацию об успешности и качестве предоставления услуги на конкретном участке обработки клиентского запроса, фиксируя возможные ошибки по каждому действию клиента. Эта информация раньше использовалась в основном ИТ-специалистами, например, для устранения технических проблем, но при этом бизнесу интересно знать, сколько клиентов не смогло подключить услугу из-за невыполненного условия заложенного в услугу, на каком шаге часть клиентов прекратила процесс подключения и узнать это нужно еще до того, как будут подведены финансовые итоги по этой услуге.

Поэтому в 2014 году, были запущены пилотные проекты мониторинга клиентских услуг и качества в сегментах обслуживания, контактного центра и инфраструктуры.

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

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

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

Не могли бы вы пояснить это на примере?

Когда в 2015 году мы запустили проект, то увидели, что по услуге «Обещанный платеж» процент отказов в подключении колеблется на уровне 50–60%. Это очень много. Однако технических отказов в этих процентах, когда действительно не работали какие-то узлы или соединения, было не более 1%. В общем-то, этим можно и пренебречь. Но все остальное относилось к логическим ограничениям. В результате получалось, что бизнес-логика услуги настроена так, что клиенты хотели, но не могли ее воспользоваться, из-за условий использования. Начали разбираться. Выяснилось, что примерно две трети из указанных 50–60% относятся к случаям, когда клиенты желают взять услугу повторно, но условиями акции это запрещено. После внесения изменений было позволено брать услугу повторно, что увеличило показатели по выручке.

Но Splunk это очень тонкий и деликатный инструмент, с которым нужно уметь обращаться, чтобы не допустить неприятных сюрпризов. Как вы оцениваете эту проблему?

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

Разумеется, мы понимаем, что в «МегаФоне» очень много услуг и данных, и вопреки нашим желаниям, чтобы охватить вниманием весь круг задач, нам, как говорится, не всегда хватает рук. Поэтому в нашу стратегию заложена возможность вовлекать в сотрудничество узких специалистов, компетентных в своих областях, которым мы предоставляем платформу для работы с данными, помогаем на старте и со временем они начинают работать самостоятельно. Например, такие направления как качество роуминга, системы самообслуживания, качество сервисов инфраструктуры и другие уже работают и контролируется через Splunk самостоятельно применяя свои алгоритмы.

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

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

Как выглядят ожидания от взаимодействия с функционалом Splunk именно вашего подразделения?

Я уже говорил, что мы стараемся понимать и контролировать все, что происходит на каждом этапе взаимодействия клиента с предлагаемыми сервисами. Понимать именно здесь и сейчас. Безусловно, мы можем потом посмотреть эту информацию в финансовых отчетах, увидеть какие-то тренды. Однако это будет «посмертный» анализ, когда мы уже никак не сможем повлиять на ситуацию. Что с того, что мы увидели потерю Х млн рублей? Мы не хотим этих убытков, а потому наши ожидания связаны с Splunk именно как с инструментом, который позволит нам именно здесь и сейчас видеть возможности для повышения уровня доступности и прозрачности услуг.

С этой точки зрения пример роуминга очень понятен. А какие услуги вы собираетесь мониторить в ближайшее время?

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

Как выглядит ваше взаимодействие со службой ИБ в вопросах управления данными?

Это очень важный вопрос. С ИБ мы договаривались заранее и играем по прозрачным правилам. Я бы назвал это нормальным операционным взаимодействием. Мы знаем, какие данные мы можем загружать в Splunk, а какие нет. Иначе есть вариант попасть под действия регуляторов. И этим обстоятельством никак нельзя пренебрегать. Соответственно, мы информируем ИБ о том, какие данные в Splunk хранятся и обрабатываются, кто должен иметь к ним доступ. На этой основе мы согласовываем с коллегами из ИБ ролевую модель доступа.

Можно рассказать, каким образом Splunk позволяет бороться с таким явлением, как fraud?

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

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

Данные и их объемы растут как грибы. Как можно координировать процесс, чтобы можно было управлять временем хранения и доступностью тех или иных данных?

Для этого на этапе запуска необходимо выработать внутреннюю политику хранения данных. Технически все делается просто, если удается выстроить и согласовать политики работы с данными. Гораздо важнее понять, к чему может привести пренебрежение подобной задачей управления хранением данных. Прежде всего, это вызовет дисбаланс, когда станет очень много замусоренных, неструктурированных данных, которые приходится хранить долго, а доля размеченных данных станет меньше. В итоге качество данных влияет не только на результаты работы системы, но и на деньги компании. Это продолжение темы подготовки данных для работы в Splunk.

Какие-то еще существуют правила работы с данными, о которых стоит напомнить?

Да, конечно.  В частности, с данными нужно работать регулярно. Это означает, что мы постоянно изучаем и подключаем новые источники поступления информации. Проводим их глубокий анализ при необходимости отметая ненужное. Мы создали базу знаний, которая поддерживается в актуальном состоянии, накапливаем размеченные данные на основе существующих моделей - это требует привлечения в команду Data Scientists компетенций в виде специалиста, который занимается изучением данных и сохранением их в базе. Такая функция появилась у нас вместе с Splunk.

Это дорого?

Да. Поэтому лучше воспитывать и растить своих.

Есть еще одна проблема. Как удается отслеживать актуальность источников данных? Я имею в виду те, что потеряли свою актуальность, но продолжают генерировать данные. Или наоборот, данные перестают поступать из источника. Кто отвечает за эти источники данных?

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

 

Опубликовано 04.12.2018

Похожие статьи