В большинстве компаний слово «инцидент» означает любую возникшую проблему. Не работает принтер, перегрелся сервер, пропала связь с филиалом, пользователь не может войти в систему — все это попадает в одну очередь заявок и одинаково называется инцидентами.
На первых этапах развития службы поддержки такой подход кажется вполне рабочим. Пока заявок немного, разбираться в деталях действительно нет особого смысла. Но по мере роста компании выясняется, что одни задачи требуют немедленной реакции из-за обязательств перед заказчиком, другие — вообще не должны были стать инцидентами, а третьи являются лишь симптомами одной более глубокой проблемы. Именно в этот момент становится важным различать не только сами инциденты, но и понимать, что именно произошло: событие, инцидент или проблема.
Начнем с терминологии
В ITSM существует несколько близких понятий, которые часто смешивают.
Событие (Event) — любое изменение состояния, значимое для управления услугой или конфигурационной единицей.
Большинство событий вообще не требуют вмешательства человека. Некоторые носят информационный характер, другие предупреждают о возможной проблеме.
Например:
- загрузка процессора сервера достигла 80%;
- свободное место на диске уменьшилось до 15%;
- датчик температуры сообщил о перегреве оборудования.
Само по себе событие еще не означает, что пользователи столкнулись с нарушением работы услуги.
Если система мониторинга обнаружила повышенную температуру сервера, но инженеры успели заменить неисправный вентилятор до отключения оборудования, то никакого инцидента для пользователей вообще не произошло. Хороший мониторинг как раз и нужен для того, чтобы подобных инцидентов не возникало.
Инцидент появляется тогда, когда качество услуги уже нарушено или произошло незапланированное прерывание услуги.
Другими словами, инцидент всегда рассматривается относительно услуги, а не оборудования.
Если пользователи не могут войти в корпоративную почту — это инцидент.
Или если перестала работать система контроля доступа — это тоже инцидент.
Остановилась ERP-система — опять инцидент.
Во всех этих случаях пользователя мало интересует, какой именно сервер вышел из строя или какой коммутатор отказал. Для него недоступна услуга.
Отдельно существует понятие Проблема.
Проблема — причина или потенциальная причина инцидента или инцидентов (произошедших, текущих или будущих).
Например, несколько раз за месяц пользователи жалуются на недоступность CRM. Каждый такой случай — отдельный инцидент. Но после анализа выясняется, что все они вызваны дефектом сетевого оборудования. Вот этот дефект и становится предметом процесса Управления проблемами.
Почему появляются «инфраструктурные инциденты»
Во многих организациях используют термин «инфраструктурный инцидент». Он удобен в разговорной речи, хотя в классическом ITIL такого термина нет.
Обычно под ним понимают ситуацию, когда проблема обнаружена не пользователем, а внутренними средствами эксплуатации:
- системой мониторинга;
- инженером при обходе;
- дежурным администратором;
- автоматической диагностикой оборудования.
С практической точки зрения такое разделение действительно удобно.
Например, система мониторинга обнаружила деградацию RAID-массива. Пользователи пока ничего не заметили. Эксплуатационная команда заводит внутреннюю заявку, меняет диск, восстанавливает массив и предотвращает отказ услуги.
С точки зрения процессов это работа по управлению событиями с последующим внутренним инцидентом или запросом на обслуживание. С точки зрения ежедневной эксплуатации инженеры вполне могут называть такую ситуацию «инфраструктурным инцидентом». Главное — понимать, что речь идет скорее о внутренней классификации работ, чем об отдельном процессе ITSM.
Один технический сбой может породить десятки пользовательских инцидентов
Это одна из самых распространенных ошибок при анализе статистики.
Представим, что отказал центральный коммутатор. Через несколько минут Сервис-деск получает:
- пользователи не могут войти в CRM;
- не работают IP-телефоны;
- недоступна система видеонаблюдения;
- перестали открываться двери через СКУД;
- кассы потеряли связь с центральной базой.
Если рассматривать каждое обращение отдельно, складывается впечатление, что произошло пять независимых инцидентов. На самом деле пользовательских инцидентов действительно пять, но техническая причина у них одна. Именно поэтому зрелые ITSM-платформы позволяют связывать множество инцидентов с одной корневой причиной или одной конфигурационной единицей (КЕ). Без такой связи мы начинаем бороться с последствиями вместо устранения причины.
Где здесь место CMDB
Как только организация начинает управлять не отдельными устройствами, а услугами, появляется необходимость понимать зависимости между ними.
Например:
Если выходит из строя один компонент инфраструктуры, то система может сразу определить, какие услуги находятся под угрозой. Это позволяет еще до появления массовых обращений предупредить Сервис-деск и бизнес-подразделения о возможном влиянии. Поэтому современный ITSM практически невозможно представить без CMDB или хотя бы карты зависимостей услуг и сервисных компонентов.
Почему нельзя складывать все заявки в одну очередь
На практике компании часто совершают одну и ту же ошибку. В одной очереди оказываются:
- обращения пользователей;
- предупреждения системы мониторинга;
- результаты плановых проверок;
- внутренние задачи администраторов;
- аварийные работы;
- запросы на изменение конфигурации.
Через некоторое время становится невозможно ответить даже на простые вопросы:
- сколько пользовательских инцидентов произошло за месяц;
- сколько проблем удалось предотвратить благодаря мониторингу;
- какие услуги наиболее нестабильны;
- какое оборудование чаще всего становится причиной отказов.
В результате аналитика превращается в набор красивых, но бесполезных цифр.
Как организовать работу
Достаточно придерживаться нескольких принципов.
Во-первых, разделить источники поступления информации. Пользовательские обращения должны регистрироваться отдельно от событий мониторинга.
Во-вторых, не считать каждое событие инцидентом. Многие предупреждения должны устраняться до того, как пользователь вообще заметит проблему.
В-третьих, связывать пользовательские инциденты с технической причиной. Это позволяет видеть реальную картину и не создавать десятки одинаковых расследований.
И наконец, анализировать не только количество закрытых заявок, но и причины их возникновения. Именно здесь начинается управление качеством сервиса, а не просто обработка обращений.
Что получает бизнес
Когда процессы построены таким образом, то меняется не только работа Сервис-деска. Менеджер начинает видеть, какие услуги действительно нестабильны. Инженеры перестают бороться с одинаковыми симптомами. Пользователи реже сталкиваются с отказами, потому что многие проблемы устраняются еще на этапе событий мониторинга. А статистика перестает быть формальной отчетностью и становится инструментом принятия решений: где модернизировать инфраструктуру, во что инвестировать и какие услуги требуют особого внимания.
Зрелость ITSM определяется не количеством зарегистрированных инцидентов, а тем, сколько потенциальных инцидентов компания смогла предотвратить до того, как их заметили пользователи.
Вместо заключения
Во многих организациях спор о том, что считать инцидентом, а что нет, продолжается годами. На практике это не самый важный вопрос. Гораздо важнее понимать, какое влияние оказывает техническое событие на предоставляемые услуги и каким процессом оно должно управляться.
Если пользователь не заметил отказ благодаря своевременной реакции системы мониторинга и инженеров, значит процессы сработали именно так, как и должны работать. Если же один сбой в инфраструктуре превращается в десятки несвязанных пользовательских обращений, проблема уже не в оборудовании, а в зрелости управления услугами.
По мере развития сервисной организации акцент смещается от обработки отдельных заявок к управлению услугами и их зависимостями. Именно поэтому в современных ITSM-практиках основное внимание уделяется не количеству закрытых инцидентов, а способности предотвращать их появление, своевременно выявлять корневые причины и понимать влияние каждого компонента инфраструктуры на бизнес-услуги.
ITSM заключается не в том, чтобы быстрее закрывать заявки. Его задача — обеспечить устойчивость услуг, предсказуемость их работы и минимальное влияние технических сбоев на бизнес. Когда организация начинает смотреть на события, инциденты, проблемы и изменения как на взаимосвязанные элементы единой системы управления, то постепенно исчезает хаос, а решения становятся основанными не на интуиции, а на данных.
