IT ManagerИТ в бизнесеУправление

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

Олег Седов | 04.12.2018

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 на предмет того, что данные перестали поступать.

 

Цифровизация, телекоммуникации

Горячие темы: Бизнес в цифре

Журнал: Журнал IT-Manager [№ 11/2018], Подписка на журналы

MegaFon | МегаФон


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Другие материалы рубрики

Мысли вслух

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

Компании сообщают

Мероприятия

15.07.2020
Создание и вывод на рынок hardware-продукта

Санкт-Петербург, онлайн-трансляция

17.07.2020 — 18.07.2020
Лаборатория: бизнес как система.

онлайн, 10.40 -18.00 (мск)

23.09.2020 — 24.09.2020
Форум Индустриальной Роботизации

Санкт-Петербург, Чернорецкий пер. 4-6