Применение 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. FlashJava графический интерфейс «зонтика»!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

Автор: i_shutov

Источник