Изначально система анализа машинных данных компании Splunk позиционировалась как средство обеспечения ИТ-безопасности. По мере расширения ее возможностей она стала использоваться и в других областях, например, для предсказания и обнаружения проблем с ИТ-инфраструктурой и приложениями. Одним из пионеров в этом направлении стало российское подразделение компании Mars. Накануне практической конференции «Технологии управления данными 2018», которую издательство «Открытые системы» проведет 29 ноября, Ольга Налгранян, специалист отдела автоматизации и анализа данных Mars, рассказала Computerworld Россия об опыте применения системы анализа машинных данных в новых сферах и о том, что можно было бы сделать по-другому.
- Почему вы решили использовать Splunk в новой роли?
Это обусловлено возможностями решения. Оно позволяет анализировать любые машинные данные в их исходном виде, создавать на их основе дашборды, отслеживать и анализировать происходящее в ИТ-системе компании. У него также гибкая система разделения прав на доступ к данным: какими-то могут оперировать все, другими — скажем, персональными данными — только уполномоченные на это люди. Еще одна особенность продукта — он дает возможность анализировать данные в реальном времени. Кроме того, система обладает большой библиотекой средств машинного обучения, благодаря которым можно создавать новые модели и обучать средства анализа данных.
- В Mars уже был опыт работы со этим ПО?
Да, облачная версия, которая используется глобальным отделом безопасности с 2014 года. Но мы в IT Operations, отделе управления инфраструктурой, видели ее огромные возможности и для себя, и для бизнеса. И в 2016 году по согласованию с «безопасниками» подключились в Splunk и стали его использовать.
Они от этого тоже выиграли: у Splunk стало больше источников данных, а значит, появилось больше разнообразной информации для анализа.
Мы же получили возможность мониторить все происходящее в ИТ-системе на уровне инфраструктуры и приложений и выводить результаты анализа на дашборды, настраиваемые информационные панели.
- Насколько гладко происходил перенос функциональности на новые сферы?
Конечно, были проблемы, связанные и с особенностями продукта, и с особенностями нашего бизнеса.
Основная сложность заключалась в том, чтобы «научить» работать с системой анализа машинных данных приложения, которые не поддерживаются ее стандартными средствами.
У любой большой компании с длинной историей есть свои системы сбора и анализа, какие-то самописные, какие-то просто уже не поддерживаются их разработчиками, но отказаться от них нельзя. Пережиток прошлого века, можно сказать. Мы в этом отношении не уникальны. И данные из «систем XX века» сделать полностью пригодными для систем XXI века оказалось нелегко.
Также пришлось поработать над разграничением доступа к данным. С одной стороны, Splunk дает много информации, опираясь на которую уже второй уровень поддержки способен понимать, что случилось с тем или иным элементом инфраструктуры или приложением, и решать проблемы до того, как придется задействовать экспертные центры. С другой — к «чувствительным» данным, например к персональным, доступ надо давать не всем. Splunk позволяет настроить гибкую систему ролей, однако, для того чтобы ею воспользоваться, надо провести тщательный анализ, создать «матрицу данных», определить, какие из них можно предоставлять всем, какие — нет.
Это особенно важно компаниям, которые растут быстро и стихийно, например стартапам. В них часто попросту нет «главного по данным», который может определить, кому что должно быть доступно.
Еще одна проблема в том, что если все начинают писать запросы к аналитической системе, то какое бы мощное облако у вас ни было, какой бы широкий канал ни соединял с ним, система начнет подтормаживать. И тут необходимо решить, что важнее — мониторинг или анализ.
Мы решили, что для нас важнее мониторинг, а ресурсы для анализа предоставляются во вторую очередь.
При этом не все пользователи достаточно хорошо знают внутренний язык системы, и поэтому их разработки могут создавать проблемы с производительностью Splunk. Для решения этой проблемы в начале прошлого года мы начали процесс создания экспертного центра, подключили партнера. Его сотрудники помогают нам отслеживать плохо написанные дашборды и улучшать их. Таким образом, мы оставляем за бизнес-пользователями право создавать себе средства аналитики, ведь кто как не они эксперты в своей функциональной области, а технические специалисты поддерживают эффективность работы системы в целом.
- К каким улучшениям привел проект?
Главное то, что мы смогли сократить время реакции на инциденты до нескольких минут и снизить количество критических инцидентов, которые возникают с этими системами.
Если раньше сотрудники, отвечающие за работу инфраструктуры и приложений, замечали, что что-то случилось, то, чтобы разобраться в происходящем, им приходилось обращаться в разные экспертные центры, потому что у них не было необходимого уровня доступа к этим приложениям.
Сейчас они видят все, что происходит в приложении, и сразу понимают, в чем проблема и чем она вызвана.
Мы отслеживаем аномальное поведение приложений и инфраструктуры и теперь можем не просто анализировать сбои постфактум, а также использовать собранные данные для того, чтобы учить системы предугадывать сбои. Это позволяет нам реагировать проактивно, до того, как что-то действительно произошло в системе. При этом более эффективные средства мониторинга позволили сократить количество людей, занятых на данной операции, и использовать освободившихся сотрудников для решения других задач.
Еще одно достоинство продукта — наличие средств выявления неавторизованных изменений. В больших распределенных корпорациях нередко несколько отделов работают одновременно над одними и теми же приложениями. Бывает, что не все изменения своевременно отслеживаются, и порой это приводит к большим проблемам. Splunk позволяет создать дашборды, с помощью которых можно видеть все отклонения в поведении систем.
Это, наверное, самое важное, что мы получили от внедрения. Но если бы я делала все сначала, я какие-то вещи сделала бы по-другому.
- Например?
В первую очередь мы бы сразу обратились к партнерам и возложили на них текущую поддержку системы, а сами бы работали над стратегией и внедрением новых возможностей.
Кроме того, при наличии ресурсов, я создала бы команду, которая сфокусировалась бы на изучении и внедрении лучших практик в конкретной области. И привлекла бы специалистов по машинному обучению.
Мы могли бы более разумно распределить нагрузку по этапам. Мы же делали все сразу — и подключали новые источники данных, и новых пользователей, и создавали новые дашборды. При том, что нас было всего трое.
Сейчас мы все делали бы с большим пониманием того, для чего добавляются новые источники данных и новые дашборды, что мы получим от каждого такого действия. И, конечно, надо было сразу документировать все наши шаги.
Но тогда мы были очень увлечены процессом создания. Ведь мы были пионерами, даже в мировом масштабе, попробовали применить Splunk за пределами сферы безопасности, мы не могли опираться на чей-либо опыт, набили все возможные шишки в этом процессе.
Например, сначала мы интегрировали ITSM-решение ServiceNow с помощью стандартных возможностей Splunk. Но, когда систему начали использовать для работы с ИТ-инфраструктурой, стало понятно, что ее недостаточно. И мы создали свою собственную. Если бы сразу пошли по этому пути, сэкономили бы время и силы.
- Традиционный вопрос — о чем вы хотите рассказать на конференции?
В первую очередь о том, что какой бы у вас ни был великолепный инструмент, его возможности не раскроются, если вы не готовы в него инвестировать, причем речь не только о деньгах. О том, что внедрение покажет вам достоинства и недостатки ваших методов работы с данными, вашей организационной структуры, ваших подходов к бизнесу. Выбирая систему и внедряя ее, вы получите важные уроки. И только работа над этими уроками позволит вам действительно получить выгоду от внедрения.
- А о чем вы сами хотите услышать на ней?
Мне интересно узнать о работе других компаний, с другими системами. Я хочу посмотреть, как другие корпорации получают выгоду от внедрения различных средств, сравнить время и силы, которые они тратят на это внедрение, с тем, какую пользу они получают на выходе.
