Управление инцидентами

Зачем эта практика

ИнцидентИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентамивесь глоссарий → — это незапланированное прерывание услуги или снижение её качества 1. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4весь глоссарий → управления инцидентами существует ради одного: сократить время, в течение которого услуга работает не так, как договорились. Не найти виноватого, не разобраться в причинах — на это есть PRBУправление проблемами, — а вернуть работу.

Из этой узкой цели следует всё остальное устройство практики. Восстановить работу можно обходным путёмОбходное решениеСпособ снизить или устранить последствия инцидента, когда полного решения ещё нет.ITIL 4, практическое руководство по управлению инцидентамивесь глоссарий →, не понимая причины, и это будет правильно. Отсюда же берётся главный конфликт, в который упирается каждая вторая служба поддержки: быстро восстановить и разобраться в причине — разные задачи, и смешивать их в одном процессе вредно.

Два фактора решают почти всё: насколько рано сбой обнаружен и насколько быстро восстановлена работа 1. Причём первый недооценивают: сбой, найденный мониторингом до того, как о нём сообщил пользователь, обходится дешевле того же сбоя, обнаруженного звонком в службу поддержки. Каждая минута простоя услуги стоит бизнесу денег, и считать эту стоимость надо до того, как процесс проектируется, а не после.

Методология ITIL описывает управление инцидентами как один из базовых элементов управления ИТ-услугами: без него остальные практики не на что опереть — данных о том, что и как часто ломается, просто не будет.

Скорость восстановления — это не про инструмент. Это про то, назначен ли владелец инцидента в каждый момент времени.

Как это работает

Обнаружение на схеме показано не шагом, а стартовым событиемСобытиеИзменение состояния, замеченное мониторингом.ITIL 4весь глоссарий →: сигнал может прийти и от мониторинга, и от пользователя, и от инженера, но дальше поток один. Нумерация шагов в таблице совпадает с номерами на схеме.

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

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

Модели инцидентов

Часть инцидентов повторяется. Для них заводят модель инцидентаМодель инцидентаЗаранее описанный повторяемый порядок обработки инцидентов одного типа.ITIL 4, практическое руководство по управлению инцидентамивесь глоссарий → — заранее описанный порядок обработки конкретного типа 1. Модель ускоряет решение и делает его предсказуемым: применяется проверенный способ, а не изобретённый заново в три часа ночи.

Критичный инцидент — отдельный случай. Это инцидент со значительным влиянием на бизнес, требующий немедленной скоординированной реакции 1. Значительное влияние не единственный признак: критичный инцидент обычно ещё и сложный — например, когда несколько мелких отказов совпали и усилили друг друга. Для него в модели описывают критерий отличия от катастрофы, назначенного координатора, выделенную команду и бюджет, порядок коммуникации с пользователями и регуляторами и обязательный разбор после.

Жизненный цикл инцидента: состояния и переходы

Схема выше показывает работу — кто что делает и в каком порядке. Здесь показано другое: в каких состояниях бывает сама запись и что переводит её из одного в другое. Это разные вопросы, поэтому и рисуются они по-разному.

Состояние	Кто переводит	Что должно быть верно	Куда уходит дальше
Зарегистрирован	Специалист поддержки	Заведена запись: что не работает, у кого, с какого момента	1-я линия, Отменён
В работе · 1-я линия	Специалист первой линии	Назначен исполнитель, проверено, нет ли готового решения в базе знаний	Решён, 2-я линия
В работе · 2-я линия	Инженер ответственной команды	Названа причина эскалацииЭскалацияПередача инцидента тем, у кого больше компетенции, либо уведомление руководителя об угрозе срока.разбор практикивесь глоссарий →, ход диагностики пишется по мере работы	Ожидание, Решён
Ожидание	Инженер	Названа причина ожидания и от кого ждём. Идёт срок или останавливается — решается моделью, а не каждый раз заново	2-я линия
Решён	Тот, кто восстановил	Работа восстановлена, способ решения записан	Закрыт, 2-я линия
Закрыт	Специалист поддержки	Пользователь подтвердил восстановление	—
Отменён	Специалист поддержки	Указано, чем оказалось обращение: запросом, плановой работой или ошибкой регистрации	—

Переход «решено на первой линииРешение с первого контактаДоля обращений, закрытых службой поддержки без обращения к другим уровням.ITIL Service Operation, раздел 4.2.8весь глоссарий →» важнее, чем кажется. Он идёт в обход второй линии, и доля таких закрытий — главная метрика первой линии. Если этого пути на схеме нет, первая линия превращается в передаточное звено: принимает и передаёт дальше, добавляя время на каждой передаче и теряя детали, потому что человек, который не решает, не понимает, какие детали важны.

Эскалация должна нести причину. Переход на вторую линию без указания, чего именно не хватило первой, — это способ избавиться от заявки, а не решить её. Записанная причина через месяц превращается в список того, чему первую линию стоит доучить.

Два состояния ломают статистику чаще прочих.

«Ожидание» — если оно останавливает срок и переводить в него может кто угодно без указания причины, метрика «закрыто в срок» перестаёт что-либо значить: любую просрочку можно спрятать, поставив паузу задним числом.

«Решён» — промежуточное состояние, а не конечное, и в этом его смысл. Между «работа восстановлена» и «пользователь подтвердил» лежит доля обращений, которые возвращаются. Если закрывать сразу, эта доля исчезает из виду вместе с проблемой, которая её порождает.

Инцидент, проблема, запрос и событие

Четыре понятия, которые в разговоре путают чаще всего, а в системе учёта смешивать нельзя: у них разные цели, разные сроки и разные метрики.

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

Как отделить запрос от инцидента на первой линии

Работающий признак — вопрос «работало ли это раньше так, как договорились».

Не работает то, что должно работать, — инцидент. Нужно то, чего раньше не было или что положено по каталогу, — запрос. Пользователь при этом почти всегда формулирует одинаково: «у меня не работает». Отделяет одно от другого именно специалист поддержки на этапе регистрации, и это единственный момент, когда это дёшево сделать.

Спорные случаи стоит закрепить решением заранее и записать в модель, а не решать заново каждый раз. Классические спорные: закончилось место на диске, истёк срок действия пароля, оборудование работает, но медленно.

Классификация и приоритет

Классификация отвечает на три вопроса: какая услуга затронута, кто отвечает за её восстановление и встречалось ли такое раньше. Последнее важнее всего: именно на этом шаге находится готовое решение, и инцидент закрывается без диагностики.

Приоритет — не то же самое, что оценка влияния. Оценка влияния и срочности — исходные данные. ПриоритизацияПриоритизацияВыбор задач, которыми займутся первыми, когда ресурсов не хватает на все.ITIL 4, практическое руководство по управлению инцидентамивесь глоссарий → нужна только там, где ресурсов на все задачи не хватает, и делается она в контексте всей очереди команды, куда попадает и плановая работа 1.

Почему матрица «влияние × срочность» ломается

Матрица даёт клетку, а клетка — не приоритет. Как только у команды окажутся два инцидента в одной клетке, решать всё равно придётся человеку, и решать он будет по тому, чего в матрице нет: по доступности нужного инженера, по времени, которое каждый случай съест, по тому, что один из них уже просрочен.

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

Второе, что ломает матрицу, — срочность, назначаемая пользователем. Если поле заполняет заявитель, через месяц все заявки станут срочными. Срочность оценивает тот, кто отвечает за услугу, а не тот, кто пострадал.

Линии поддержки

Классическая схема: первая линия принимает и решает типовое, вторая разбирается в конкретной системе, третья — это разработчики или вендор. Схема рабочая, но у неё есть два условия, без которых она даёт обратный эффект.

Первая линия должна что-то решать. Если она только маршрутизирует, каждая передача добавляет время и теряет данные, а её показатель «доля решённых с первого раза» просто фиксирует, насколько бесполезно это звено.

Передача должна быть с владельцем, а не в пустоту. Инцидент, переданный на вторую линию, не перестаёт быть чьим-то: владелец либо переходит, либо остаётся у первой линии, которая продолжает отвечать перед пользователем 1.

Когда линий лучше не заводить

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

Схема со свормингаСвормингСовместный разбор сложного инцидента, где собирают не много людей, а нужных.ITIL 4, практическое руководство по управлению инцидентамивесь глоссарий → работает и здесь: вместо передачи по линиям — сбор нужных людей под конкретный случай 1. Кто нужен, определяет не структура, а характер сбоя.

Сроки и эскалация

Сроки на восстановление берутся из соглашения об уровне услугСоглашение об уровне услугДоговорённость с заказчиком о том, каким должно быть качество услуги и в какие сроки восстанавливается работа.ITILвесь глоссарий → — за них отвечает практика SLMУправление уровнем обслуживания, а внутренние — из технической спецификации услуги. Практика управления инцидентами при этом восстанавливает нормальную работу и тогда, когда отклонение вообще не видно потребителю: нормальное состояние определено в конфигурации, которую ведёт CFGУправление конфигурациями,, а не только в договоре 1.

Эскалация бывает двух видов, и путать их дорого. Техническая — привлечь тех, у кого больше компетенции. Управленческая — сообщить руководителю, что срок под угрозой. Первая ускоряет решение, вторая не ускоряет ничего, но позволяет вовремя предупредить бизнес. Регламент, где есть только вторая, превращает эскалацию в наказание, и инженеры перестают её запускать.

Кто участвует

Оператор первой линии принимает сигнал, регистрирует, классифицирует и закрывает. Его главная ответственность не «быстро принять звонок», а качество данных в записи: от него зависят и правильность решений, и скорость восстановления, и возможность потом найти причину 1.

Инженер ответственной команды диагностирует и восстанавливает. Работает не в одиночку: при сложных инцидентах применяется сворминг — совместный разбор, где собирают не много людей, а нужных 1. Физические встречи при этом не обязательны.

Координатор критичного инцидента появляется только на критичных. Он не чинит — он держит картину целиком, распределяет работу и разговаривает со стейкхолдерами, освобождая инженеров от объяснений.

Владелец услуги участвует в разборе после и решает, что менять в самой услуге.

Чем измерять

Метрики практики группируются вокруг трёх факторов успехаФактор успеха практикиТо, что должно быть верно, чтобы практика выполняла своё назначение.ITIL Service Operation, раздел 4.2.8весь глоссарий →: рано обнаруживать, быстро решать, постоянно улучшать подходы 1. Третья редакция раскладывала их подробнее — шесть факторов и полтора десятка показателей под ними 12, и предписывала разбивать каждый по влиянию, срочности, затронутой услуге и периоду, сравнивая с предыдущим 12.

Так набор выглядит на панели руководителя поддержки: не список показателей, а сравнение с прошлым периодом — само по себе число ничего не значит, значение имеет направление.

6Панель по инцидентам — целиком, с разборомШесть уровней руководства и объяснение, кому какие показатели нужны и почему. Плюс таблица: как считается каждый показатель и чем искажается.Открыть →

Ни одну из них нельзя делать целевой в одиночку. Требование «закрывать 95% в срок» получают не ускорением работы, а переклассификацией: инциденты начинают заводиться как запросы, срок по которым мягче. Формально метрика выполнена, реально стало хуже, и увидеть это можно только по соотношению нескольких показателей сразу.

Где ломается чаще всего

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

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

Данные записываются после, а не по ходу. «Перезагрузили кластер, через сорок пять минут заработало» — это не запись, это её отсутствие. За такой фразой прячется последовательность действий, которую потом не восстановить, и разбор причины становится невозможен 1.

Приоритет путают с оценкой влияния. Оценка влияния и срочности — не приоритизация. Приоритизация нужна только тогда, когда ресурсов на все задачи не хватает, и делается она в контексте всей очереди команды, а не одного инцидента 1. Матрица «влияние × срочность», выданная как окончательный приоритет, ломается в первый же день, когда у команды одновременно окажутся два инцидента с одинаковой клеткой матрицы.

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

Этап устранения путают с этапом закрытия. Работа восстановлена — это ещё не закрытая заявка. Пока пользователь не подтвердил, что услуга работает, инцидент закрывать рано: значительная часть повторных обращений приходит именно из-за преждевременного закрытия, когда сбой устранили частично.

Как менялось от редакции к редакции

В третьей редакции ITIL управление инцидентами было процессом с предписанным порядком шагов — учебные материалы того времени так его и разбирают, шаг за шагом 7. В четвёртой это практика — набор ресурсов, который в разных потоках создания ценности собирается по-разному 1. Практическая разница не косметическая: раньше от организации ждали, что она внедрит процесс как описано, теперь — что соберёт под свою ситуацию из описанных элементов.

Второе изменение — приоритизация переехала в контекст команды. Раньше приоритет считался по матрице влияния и срочности и был свойством инцидента. Теперь это инструмент распределения людей по задачам внутри общей очереди, куда попадает и плановая работа 1.

Третье — упор сместился на раннее автоматическое обнаружение. Регистрация со слов пользователя описана как всё ещё распространённая, но уже не как хорошая практика 1.

Где описано

Свод Microsoft описывает ту же работу под другим именем и с другой разбивкой: у него управление инцидентами не отдельная практика, а часть функции обслуживания заказчиков, живущей на этапе эксплуатации 23. Разница не косметическая — MOF сильнее связывает поддержку пользователей с эксплуатацией инфраструктуры, тогда как ITIL разводит их по разным практикам. Оба документа выложены у нас: лицензия Microsoft это разрешает.

42Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и MOF, что из этого обязательно, а что на выбор, и где брать первоисточник. По 49 практикам из 60 проставлено соответствие COBIT.Открыть →

Проекты внедрения

Три проекта разного масштаба. Общее в них не инструмент, а порядок: сначала описывают процесс и назначают ответственных, потом автоматизируют. Там, где делают наоборот, система становится ещё одним местом, куда никто не заносит заявки.

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

Материалы по теме

Примеры

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

Критичный инцидент. Недоступен сервис приёма платежей. Классификация показывает влияние на выручку — назначается координатор, собирается команда из инженеров базы данных и сети, открывается канал оповещения. Инженеры ведут диагностику, координатор каждые пятнадцать минут пишет статус. После восстановления обязателен разбор — не для поиска виноватых, а чтобы понять, почему обнаружили не мониторингом.

Где практика не применяется. Запланированные работы инцидентами не являются. Заявка на новый доступ — тоже: это запрос на обслуживание, и держать его в одном потоке с инцидентами значит испортить обе метрики. Сервисные работы по расписанию, миграции и плановые остановки идут своими процессами, даже если внешне выглядят как простой услуги.

Что почитать дальше

Начинать стоит с официального практического руководства ITIL 4 1: оно короткое, тридцать пять страниц, и написано как рабочий документ, а не как учебник.

Вторым — процессное руководство Стейнберга 6. Оно старше и относится к третьей редакции, но там подробно расписано то, чего в новом руководстве нет: конкретные процедуры, формы записей, правила эскалации.

Если нужен пример настоящего внедрённого регламента, а не образца, — описание процесса Fermilab 8: реальный документ реальной организации со всеми компромиссами.

По-русски систематическое изложение есть у Елхимова 9.

А для раздела «где ломается» полезнее всего не итсм-литература, а книги про эксплуатацию: «Философия DevOps» 10 и «Хаос-инжиниринг» 11 — обе про то, как системы отказывают на самом деле, а не как это описано в регламенте.