Бережливый ITSM

Бережливый ITSM – это комплекс мер и технических решений, предназначенных для повышения эффективности ITSM за счет сокращения трудозатрат персонала Service Desk. Бережливый ITSM – это практическая реализация методологии Бережливого Производства (Lean Production) применительно к управлению ИТ-Услугами. Напомню, что Бережливое Производство – это концепция менеджмента, основанная на неуклонном стремлении к устранению всех видов потерь. В соответствии с концепцией Бережливого Производства, всё, что потребляет ресурсы, но не создает (не добавляет) ценности для потребителя, является потерями и должно быть устранено. Ценность для потребителя — способность товара или услуги удовлетворять ожиданиям потребителя. Внедрение Бережливого ITSM позволяет сократить потребление наиболее дорогостоящего ресурса - времени. Предлагаемая методика включает в себя:

1. Автоматическое создание Снимка Инцидента (Красная Кнопка). Решение предназначено для сокращения трудозатрат, связанных с квалификацией инцидентов.
2. Объединение информации об инцидентах, с информацией о здоровье ИТ-Инфраструктуры и производительности бизнес-приложений. Решение предназначено для сокращения трудозатрат, связанных с диагностикой инцидентов.
3. Мониторинг качества работы приложений «глазами пользователей» (Пятый Уровень). Решение предназначено для сокращения числа инцидентов и повышения качества ИТ-Услуг.

Автоматическое создание Снимка Инцидента (Красная Кнопка)

Автоматическое создание Снимка Инцидента позволяет службе Service Desk автоматически получать информацию, достаточную для быстрой квалификации инцидентов.

Обычно, чтобы сообщить службе Service Desk об инциденте, пользователю нужно позвонить по телефону, написать электронное письмо или заполнить web-форму. В каждом из этих случаев для квалификации инцидента полученной информации, как правило, бывает недостаточно. Поэтому оператор первой линии поддержки, получив сообщение об инциденте, обычно должен задать пользователю ряд уточняющих вопросов. Время, затрачиваемое на получение адекватных ответов, зависит от множества факторов, в частности, от коммуникативных навыков пользователя.Рынок аутсорсинга информационной безопасности в России: особенности развития и перспективы. Обзор TAdviser 6.2 т

Трудозатраты первой линии поддержки могут быть существенно сокращены, если первая линия поддержки будет получать информацию, достаточную для квалификации инцидента, сразу, без необходимости задавать дополнительные вопросы. Примером такой информацией является Снимок Инцидента, автоматически создаваемый с помощью решения Красная Кнопка (см. Рисунок 1).

Рисунок 1. Автоматическая передача Снимка Инцидента с использованием решения Красная Кнопка

На компьютерах пользователей устанавливается специальное ПО, позволяющее простым нажатием комбинации клавиш (нажатием Красной Кнопки) сообщать ИТ-Службе о сбоях в работе бизнес-приложений (ошибки, медленная работа и т.п.). При нажатии Красной Кнопки в службу Service Desk автоматически передается следующая информация:

1. Инцидент, как его «видит» пользователь:

• Скриншот компьютера пользователя в момент нажатия Красной Кнопки.
• Категория инцидента (определяется комбинацией нажимаемых клавиш) и, опционально, его описание. Пользователь может добавить краткое описание инцидента перед нажатием Красной Кнопки.

2. Информация о пользователе и его окружении:

• Имя компьютера и аккаунт пользователя (включая домен).
• Название подразделения, где работает пользователь (импортируется из Active Directory).
• Переменные среды (environment string), которые могут описывать, например, географическое местоположение пользователя, категорию персонала, к которой он относится и т.п.

3. Информация об активности пользователя:

• Наименование бизнес-приложения, с которым работал пользователь в момент нажатия Красной Кнопки.
• Наименование бизнес-операции, которую пользователь выполнял в момент нажатия Красной Кнопки. Для Windows-приложений бизнес-операция определяется по тексту в заголовке активного окна. Для Web-приложений – по URL. Для консольных приложений – по тексту на экране. Для идентификации бизнес-операции на компьютере пользователя должен быть предварительно установлен соответствующий каталог бизнес-операций.

4. История действий пользователя за 15 минут до нажатия Красной Кнопки, включающая информацию об используемых приложениях и выполняемых бизнес-операциях.

Снимок Инцидента автоматически принимается Зондом, автоматически записывается в Консолидированную базу данных и автоматически отображается на Инженерной консоли. Зонд, Консолидированная база данных и Инженерная консоль являются компонентами Агрегатора Информации (подробнее ниже), входящего в состав продуктов семейства ProLAN SLA-ON.

На компьютере Агрегатора Информации также устанавливается Коннектор к Service Desk (Windows-сервис). Коннектор непрерывно сканирует Консолидированную базу данных на появление информации о новых инцидентах. Когда такая информация появляется, Коннектор выполняет следующее:

• Определяет адресата информации об инциденте (соответствующую группу поддержки). Адресат определяется на основе информации о бизнес-приложении и (или) бизнес-операции, которую в момент нажатия Красной Кнопки выполнял пользователь. Напомню, что эта информация содержится в Снимке Инцидента. Разным бизнес-приложениям, а иногда и разным бизнес-операциям «внутри» одного приложения, могут соответствовать разные группы поддержки.
• Формирует Снимок Инцидента в формате соответствующего Service Desk и автоматически направляет его нужному адресату. В настоящее время поддерживаются HP Service Manager и BMC Remedy.

Автоматическое создание Снимка Инцидента позволяет существенно сократить трудозатраты на квалификацию и маршрутизацию инцидентов, а также снизить вероятность их ошибочной квалификации и маршрутизации. Это повышает эффективность ITSM. Подробнее см. Красная Кнопка.

Объединение информации об инцидентах, с информацией о здоровье ИТ-Инфраструктуры и производительности бизнес-приложений.

Объединение информации об инцидентах, с информацией о здоровье ИТ-Инфраструктуры и производительности бизнес-приложений позволяет службе Service Desk быстро определять корневые причины сбоев в работе ИТ-Инфраструктуры и бизнес-приложений.

Очевидно, что эффективность ITSM в значительной степени зависит от скорости, с которой ИТ-Служба диагностирует инциденты. Традиционная схема организации ITSM (см. Рис. 2), не способствует быстрой диагностике инцидентов.

Рисунок 2. Традиционная схема организации ITSM

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

Сначала нужно определить время, когда произошел сбой (инцидент). Затем, зная время, проанализировать метрик здоровья ИТ-Инфраструктуры и производительности приложений в этот момент времени. Поскольку инциденты регистрируются, как правило, по телефону, установить точное время бывает сложно, поэтому нужно анализировать метрики на большом временном интервале. Поскольку данных много, «увидеть» таким способом корневую причину удается не всегда. В таком случае единственным выходом является попытаться воспроизвести сбой. Как правило, это очень трудоемкая задача. Пo информации компании Network Instruments, 59% из 592 опрошенных этой компанией сетевых профессионалов, на воспроизведение сбоев тратят не менее 25 дней в год, а 71% опрошенных тратят 25 и более дней в год еще и на определение причин сбоев, которые они воспроизвели, подробнее ...

Рисунок 3. Схема Бережливого ITSM

Время диагностики инцидентов можно существенно сократить, если придерживаться следующих правил:

1. Регистрировать инциденты с помощью Красной Кнопки.
2. Сохранять информацию об инцидентах, здоровье ИТ-Инфраструктуры и производительности приложений в единой (консолидированной) базе данных.
3. Анализировать инциденты, метрики здоровье ИТ-Инфраструктуры и метрики производительности приложений с «привязкой» к единой временной шкале (видеть значения метрик в момент нажатия Красной Кнопки).

Схема организации ITSM, обеспечивающая поддержку приведенных выше правил, показана на Рисунке 3. Ключевой элемент предлагаемой схемы - Агрегатор Информации. Агрегатор включает в себя: Зонд, Консолидированную базу данных, Искусственный Интеллект, Инженерную консоль. Зонда принимает Снимки Инцидентов, собирает информацию о здоровье ИТ-Инфраструктуры и производительности бизнес-приложений, и всю полученную информацию записывает в Консолидированную базу данных. Искусственный Интеллект обрабатывает консолидированную информацию по заданным правилам, и после обработки передает в Service Desk.

По сравнению с традиционной схемой организации ITSM, предлагаемая схема имеет два важных преимущества. Во-первых, Service Desk получает не «сырую», а обработанную информацию, позволяющую быстро «ставить диагноз» инцидентам. Например, сразу виден масштаб бедствия (единичный пользователь, группа пользователей определенного региона, группа пользователей определенного бизнес-приложения и т.п.), сразу видно, что могло привести к возникновению инцидента (какие действия пользователя предшествовали инциденту) и многое другое. Второе преимущество, - возможность быстро определять причинно-следственные связи между инцидентами, с одной стороны, и здоровьем ИТ-Инфраструктуры и производительностью бизнес-приложений, с другой стороны. Для решения этой задачи используется Инженерная консоль, позволяющая отображать всю получаемую информацию с «привязкой» к единой временной шкале. Это очень действенный метод определения корневых причин инцидентов (root cause analysis). Подробнее читайте в статье: «Красная Кнопка – диагностика инцидентов по-новому».

Мониторинг качества работы приложений «глазами пользователей»

Мониторинг качества работы приложений «глазами пользователей» позволяет обнаруживать сбои в работе приложений до обращения пользователей в Service Desk и, таким образом, существенно сократить число инцидентов и повысить качество ИТ-Услуг.

Мониторинг качества работы приложений «глазами пользователей» (далее - Мониторинг Quality of Experience, QoE) – это получение в режиме реального времени информации о качестве работы реальных бизнес-приложений у реальных пользователей. Основной целью такого мониторинга является обнаружение сбоев в работе ИТ-Инфраструктуры и бизнес-приложений до обращения пользователей в Service Desk. Другими словами, чтобы узнавать о качестве работы ИТ-Сервисов не по числу обращений в Service Desk, а независимо от этого. Мониторинг QoE позволяет снизить число обращений в Service Desk (читай - трудозатраты персонала ИТ-Службы), и повысить лояльность пользователей ИТ-Сервисов.

Примером решения, предназначенного для Мониторинга QoE, является решение Пятый Уровень компании ProLAN. Внедрив данное решение, ИТ-Служба сможет автоматически получать следующую информацию:

1. Время реакции бизнес-приложений , измеряемое на стороне пользователя (E2E RT, End-to-End Response Time). Это время от момента, когда пользователь, работая в бизнес-приложении, запрашивает выполнение определенной функции до момента, когда эта функция выполнена (пример функции, - поиск товара в справочнике).
2. Количество выполненных пользователем транзакций с разделением на успешно выполненные транзакции, принудительно завершенные транзакции по какому-то событию (например, ошибке, тайм-ауту и т.п.), транзакции, завершенные успешно, но выполненные с нарушением стандартной последовательности действий.
3. Количество ошибок при выполнении транзакций с разделением на системные и пользовательские. Системные ошибки вызываются сбоями в работе ИТ-Инфраструктуры или ошибками в коде самих приложений. Пользовательские – результат неправильных действий пользователей.
4. Значения APDEX (Application Performance Index). APDEX – это результат статистической обработки измеренных значений E2E RT, характеризующий удовлетворенность пользователей производительностью бизнес-приложений.

Для измерения QoE используется метод Client Instrumentation и программа (Windows-сервис): «EPM-Агент». Программа устанавливается на компьютерах пользователей; если пользователи работают в терминальном режиме, то на терминальном сервере. Принцип работы EPM-Агент заключается в автоматическом отслеживании всех выполняемых на компьютере пользователя процессов и связанных с ними событий.

Пятый Уровень имеет ряд преимуществ по сравнению с аналогичными решениями западных компаний. Во-первых, - высокая экономичность. Стоимость Пятого Уровня как минимум на порядок ниже стоимости западных аналогов. Во-вторых, - поддержка бизнес-приложений российского производства. Западные продукты, как правило, «не понимают» российские бизнес-приложения. Третье преимущество - прозрачная интеграция с системами сетевого управления. Очень немногие западные продукты сегодня умеют это делать. Всё это, безусловно, очень важно, но есть еще два преимущества, о которых следует сказать особо. Это поддержка EPM-Агентом протокола SNMP и прозрачная интеграция Пятого Уровня с решением Красная Кнопка.

Поддержка EPM-Агентом протокола SNMP

Поддержка EPM-Агентом протокола SNMP – это возможность передачи EPM-Агентом всех измеряемых им метрик с использованием протокола SNMP, см. Рисунок 4.

Рисунок 4. Поддержка EPM-Агентом протокола SNMP

Поддержка EPM-Агентом протокола SNMP означает возможность использования в качестве Консоли управления QoE практически любой системы сетевого управления, т.к. практически любая система сетевого управления сегодня поддерживает SNMP.

Интеграция Пятого Уровня с Красной Кнопкой

Интеграция Пятого Уровня с Красной Кнопкой обеспечивает возможность автоматической передачи в Service Desk Снимков Инцидента по инициативе EPM-Агента. Другими словами, в этом случае Красную Кнопку «нажимает» не пользователь, а EPM-Агент, см. Рисунок 5.

Рисунок 5. Автоматическая передача Снимка Инцидента по инициативе EPM-Агента

Предположим, бизнес-приложение на компьютере пользователя выдало сообщение об ошибке. Установленный на компьютере пользователя EPM-Агент автоматически идентифицирует возникшую ошибку и автоматически информирует об этом событии Красную Кнопку (приложение HelpMe). При этом EPM-Агент передаст Красной Кнопке подробное описание данного события. Получив информацию о событии, Красная Кнопка сделает снимок экрана (если для данного события это разрешено), прочитает переменные среды, определит выполняемую бизнес-операцию и т.д., после чего передаст всю полученную информацию в Агрегатор Информации, откуда она будет автоматически передана в Service Desk.

Интеграция Пятого Уровня с Красной Кнопкой обеспечивает принципиально новый уровень Мониторинга QoE. Новизна заключается в следующем:

1. ИТ-Служба автоматически получает информацию о сбоях в работе бизнес-приложений, не привлекая для этого пользователей. Например, пользователь ИТ-Сервиса, получив информацию о критической ошибке, всегда будет уверен, что соответствующий инцидент уже зарегистрирован в Service Desk, и он может спокойно «идти пить чай». При этом сотрудникам Service Desk не нужно задавать пользователю никаких дополнительных вопросов, т.к. они видят абсолютно всё, что видит пользователь, и даже больше.
2. ИТ-Служба автоматически получает информацию не только о сбоя, но и дополнительную информацию, позволяющую этот сбой квалифицировать и автоматически обработать. Эта информация включает в себя, в частности, данные о том, что пользователь делал в момент сбоя, что он делал до возникновения сбоя, какое ПО установлено на его компьютере, кто этот пользователь и т.п. Это позволяет автоматизировать обработку инцидентов и создать экспертную систему, диагностирующую критически важные события автоматически.