Применение R для работы с утверждением «Кто виноват? Конечно ИТ!»

    Продолжение предыдущих публикаций «Инструменты DataScience как альтернатива классической интеграции ИТ систем»,
    «Экосистема R как инструмент для автоматизации бизнес-задач» и Джентельменский набор пакетов R для автоматизации бизнес-задач. Настоящая публикация преследует 2 цели:


    1. Взглянуть на типичные задачи, которые встречаются в бизнесе, под немного другим углом.
    2. Попробовать их решить, частично или полностью, с использованием средств, предоставляемых R.

    Крайний кто?


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


    Поэтому ответ на вопрос «Кто виноват?» в целом всегда известен. Конечно же виновато ИТ! Но это тупиковый вариант, поскольку причина проблем при этом не выясняется и не устраняется, а значит, эти проблемы будут возникать снова и снова.
    Чтобы перевести этот вопрос в конструктивное русло, первым шагом трансформируем этот вопрос в «Какая ИТ система виновата?».


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


    Возможный вариант решения


    Можно ли с этим что-либо сделать? Если умерить амбиции, включить голову и засучить рукава, то можно, и даже очень неплохо. Логика шагов, которые позволяют выйти из патовой ситуации примерно следующие:


    1. Будем честными, у ИТ уже есть множество средств мониторинга (и бесплатных и вендорских), которые так или иначе собирают какие-то данные и сколько-то их хранят. Для начала на этом надо и остановиться. Раз больше ничего не покупали, то явных доказательств, что нужно гораздо больше пока не нашлось.


    2. Бизнес-пользователй совершенно не волнуют все ИТ потроха и не надо с ними на эту тему даже беседовать. Их волнуют две вещи: чтобы приложение(-я) с которым они работает было доступно и чтобы оно не тормозило. Точнее, даже не все приложение, а только ограниченный набор окошечек и кнопочек. Вот это малое количество KPI (по сути, бизнес KPI) и надо дополнительно контролировать и использовать для разговора с бизнесом.


    3. Идеи кросс-корреляции 100500 метрик и автоматического поиска зависимостей и поиска первопричины хороши для фантастических рассказов. В реальности это не работает. Во-первых, в сложной ИТ системе всегда найдется n+1 метрика, о которой забыли, но которая и оказалась причиной. Во-вторых, странно пытаться натягивать идею о линейной зависимости на сугубо нелинейную ИТ систему, структура которой зачастую известна только «в общем». В-третих, без дополнительных внешних знаний невозможно определить, что является причиной, а что следствием (см. Spurious correlations), т.е. алгоритм поиска зависимостей должен быть весьма сложным и содержать модель наблюдаемой системы. Это долго, дорого, с непонятным результатом.


    4. В любом случае, проблемы в ИТ системах делятся на 2 класса: а) известные, когда при возникновении симптомов надо подойти и «стукнуть рукой» в левом верхнем углу б) на неизвестные, с которыми надо вручную исследовать и разбираться.

    Таким образом, можно преобразовать идею о корреляции метрик следующим образом, имеющим практическую реализацию:


    1. Известные решения известных проблем автоматизируем и далее их не рассматриваем. Что делать, иногда пожизненно необходимо принимать лекарства.


    2. Начинаем собирать, желательно существующими средствами, значения бизнес-метрик, которые беспокоят бизнес-пользователей. Эти метрики (временные ряды) используются в качестве референсных показателей.


    3. Включаем голову и ограничиваем количество железных метрик только тем железом, на котором эти бизнес-приложения работают.


    4. Вместо разговорах о нейронных сетях для начала используем подход «визуальной корреляции». В этом случае на экран в удобном для сравнения виде выводятся временные ряды бизнес-метрики и технологических метрик, подозреваемых в качестве причины проблем. Даем ИТ специалисту удобный инструмент для изменения наборов метрик для анализа.


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


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

    Запад нас спасет?


    Для данного случая у западных вендоров есть концепция «зонтичных систем». Но применительно к нашей задаче она является избыточной и дорогой, поскольку никогда неизвестно что может случиться в ИТ и в бизнесе. Собирать все, что только можно, и загонять потом в одну систему — не вариант, очень дорого. «Женить» кучу разнородных систем в рамках модели мира производителя «зонтичной» системы тоже не получается. Слишком простые и не конгруэнтные другу и исходной задаче модели в этих зонтиках. Есть еще несколько «засад»:


    1. Flash\Java графический интерфейс «зонтика»!


    2. Полноценная поддержка русского языка отсутствует!


    3. Для глубокой настройки используется мышка + внутренние скриптовые языки, сакральные знания по которым стоят не один десяток килодолларов.


    4. Встроенная математика заканчивается на вычислении среднего. Сложные алгоритмы? Да вы что, это же professional services, готовьте чемодан денег!


    5. Сможете ли вы получить ответ что делать с отсутствующими данными? Данными, поступившими за прошлое время? Апериодическими временными рядами? Различающейся периодичностью временных рядов? Забудьте!

    А можно решить эту задачу?


    Практика показала, что в рамках экосистемы R эта задача вполне решаема. Что мы получаем на выходе:


    1. Аналитическая консоль+дашборд на базе Shiny (HTML + JS + CSS). Можем как показывать бизнесу светофоры, так заниматься интерактивным анализом метрик для поиска возможных причин без погружения в консоль R. Все на русском языке. В силу определенных причин пока не могу публиковать скриншот, поэтому для примера приведу ссылку на идеологически похожую иллюстрацию (на картинке R+Tableau, позаимствовано отсюда)

    Metric Correlation


    1. Любой степени сложности графический вывод статики ggplot (наложения данных, преобразования, сетки, шрифты, и пр.) + широкие возможности по динамике htmlwidgets.


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


    3. Поддержка работы с временными рядами на любой вкус и цвет.


    4. Удобная обработка данных (hadleyverse).


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


    6. Не менее простой экспорт.


    7. Возможность разработки процедур по автоматическому внесению изменений во внешних системах, оставаясь в рамках R.

    Заключение


    На возможный вопрос «Почему же R?» примерные ответы такие:


    1. По результатам практического применения считаю экосистему R хорошо применимой и к «бытовым» бизнес-задачам. Поэтому использовался R по постановке задачи.


    2. Математика + интегрированный веб-интерфейс без веб программирования + простые механизмы импорта\экспорта и интеграции + удобные способы и методы работы с данными.


    3. Скорость и простота получения конечного результата.


    4. Мне не довелось найти какого-либо приемлемого аналога экосистемы на других языках, в т.ч. в рамках python. Искал достаточно долго. Если я упустил и что-то есть аналогичное, напишите, пожалуйста, в комментариях.

    P.S. Будет крайне интересно, если коллеги, у которых есть задачи, которые потенциально могли бы быть решены с применением R, обрисовали обезличенно задачу в комментариях. Пример различных бизнес-задач, отличных от широко обсуждаемых рекомендательных систем на базе больших данных, и автоматизированных на экосистеме R, был уже приведен в постах. Тогда будет повод обсудить конкретные вопросы и подходы.


    Предыдущий пост: "Джентельменский набор пакетов R для автоматизации бизнес-задач"
    Следующий пост: "Вам не хватает скорости R? Ищем скрытые резервы"

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 7

      +1

      А можно ссылки на используемые алгоритмы?

        +3

        Про какие именно алгоритмы заданы вопросы? Работа с временными рядами? Подходы к решению задачи будут сильно зависеть от характера самих рядов, например, наличие периодических составляющих.
        Тут ничего нового нет, используем хорошо известное старое, но с адаптацией под особенности работы конкретных бизнес-процессов компании и информационных систем


        Линейная корреляция рядов практически бесполезна, поскольку различные метрики могут иметь совершенно разные временные ряды, как по абсолютным значениям, так и по "дребезгу". Но при этом поведение ("как бы", 1-ая производная) может совпадать в фазе или в противофазе, иногда с определенной временной задержкой. Что может быть полезно с точки зрения практических упражнений?
        Ссылки даю на англоязычные труды, поскольку они нашли реализацию в тех или иных пакетах R.


        1. Предварительное сглаживание и устранение мелкого дребезга.


        2. Прогнозирование. Можно ознакомиться с сайтом и трудами Rob J Hyndman, автором пакета forecast.
          Также можно прочитать его книгу "Forecasting: principles and practice"


        3. Построение поведенческих профилей метрик и переход от анализа абсолютных значений рядов к отклонениям от поведенческого профиля. То, что западные компании называют "deviation from baseline & behavior analysis". (см., например, Anomaly Detection Using Elasticsearch)


        4. Поиск нетипичных значений и выбросов. Например, можно начать читать с twitter GitHub


        5. Поиск точек смена поведения (change point analysis). Можно почитать статью


        6. Немного погружаемся в архитектуру ОС и железа. Очень интересные методики созданы Brendan Gregg, можно начать знакомиться с его сайта
      0
      очень интересно! если вас не затруднит, можно подробнее? (алгоритмы и реализацию)
        0
        Заинтересовал термин hadleyverse.
        Положу сюда две найденных хороших ссылки
        Packages of the Hadleyverse. Power for your R. Barry Rowlingson
        The Hitchhiker's Guide to the Hadleyverse BY ADOLFO ÁLVAREZ
          +1

          Очень "правдивая" статья. У нас этот "зонтичный" мониторинг был как заноза в мягком месте несколько лет, пока манагеры не успокоились. Абсолютно точно, что люди, которые не очень понимают, как "всё" работает хотят это "всё" собирать, хранить 5 лет и сурово анализировать. Без понимания целей и желаемых результатов, кроме "чтобы всё работало" и умные слова типа "калобарэйшн" и "он сайт", которые произносятся не к месту, но с умным видом. Причём обязательно сделать самим, без взаимодействия "вон с теми выскочками из соседнего управления", которые тоже пытаются что-то похожее внедрить.
          А потом, когда все успокоились, мы спокойно взяли приоритетные проекты, определили возможные источники информации в совокупности с нашими умениями, положили все данные в промежуточную базу (это не обязательно) и силами R вытянули и свели верхнеуровневую инфу в едином интерфейсе. Потом всё это по-тихому вывели на телевизор руководителям. В итоге, телевизор не выключается, руководители довольны, IT процессы, с их точки зрения, стали понятне, мы — молодцы. Хотя, по факту, ничего особенного сделано не было.

          Only users with full accounts can post comments. Log in, please.