Что такое управление инцидентами и почему без него IT-отдел тушит пожары, а не предотвращает их

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

Представим ситуацию: в пятницу в 17:40 у отдела продаж перестаёт открываться CRM. Менеджер пишет «айтишникам» в личку — тот, кому обычно пишут, уже ушёл. Второй сотрудник звонит руководителю IT, руководитель звонит администратору. К 18:30 выясняется, что упал сервер базы данных. Администратор находит причину и чинит к 23:00 — в одиночку, по звонкам, без единой записи.

В понедельник на планёрке звучит вопрос: «Что это было?» Точного ответа нет: кто что делал — не записано, почему упало — не разобрано. Через месяц сбой повторяется, и всё начинается заново.

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

По данным исследования ITIC 2024 года (опрос более 1 000 компаний), час простоя обходится свыше 300 000 долларов для 90% средних и крупных предприятий, а 41% оценивают потери от 1 до 5 миллионов долларов за час. Это усреднённые оценки самих компаний — потерянные транзакции, простой сотрудников, ущерб данным. Но даже если ваши масштабы в сто раз скромнее, логика та же: каждый час сбоя стоит денег, и чем быстрее сервис возвращается в строй, тем дешевле обходится инцидент.

Скорость же его решения зависит не от таланта администратора, а от того, насколько команда договорилась заранее: кто обнаруживает инцидент, кто регистрирует, кто решает, кто подтверждает решение.

В методологии ITIL инцидент — это внезапное событие, которое снижает качество работы сервиса или системы: нет доступа к приложению, зависла корпоративная почта, сбой сети, критически медленный интернет. Ключевое слово — «внезапное». Инцидент нужно устранять быстро, возвращая сервис в норму.

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

1. Выявление. Инцидент находят пользователи — они сообщают в поддержку. Но чем раньше компания узнаёт сама, тем лучше: системы мониторинга отслеживают состояние сервисов, а SIEM-системы — события информационной безопасности. Сбой, замеченный мониторингом в 17:41, дешевле сбоя, о котором рассказал клиент в 19:00.

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

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

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

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

6. Эскалация. Если инцидент не решается на текущем уровне — он передаётся дальше по заранее известным правилам: функциональная эскалация (более квалифицированным специалистам) и иерархическая (руководству, когда нужны ресурсы или решение). Эскалация по правилам, а не по степени близости с коллегами, — признак зрелого процесса.

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

8. Закрытие. Сотрудник поддержки связывается с тем, кто сообщил об инциденте, и получает подтверждение, что всё работает. Только после этого заявка закрывается, а пользователь может оценить качество работы. Инцидент, закрытый «в тихую» без подтверждения, — источник повторных обращений.

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

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

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

Технически процесс держится на учёте обращений: заявки из всех каналов, категории, приоритеты, SLA и база знаний — это есть в любом нормальном сервис-деске, в том числе в нашем Админ24. Но инструмент не заменит трёх решений, которые принимаете вы: кто владелец каждого сервиса, что считается критичным инцидентом и по каким правилам происходит эскалация. Без них любая система — просто красивая доска.

А как у вас проходят первые 30 минут после сбоя: есть ли в команде человек, который сразу знает, что делать? И что вы делаете первым — чините сервис или решаете причину?