Управление инцидентами: как восстановить ИТ-сервис и не потерять контроль над процессом
Блог Kaiten ·
Все о работе с инцидентами: как расставлять приоритеты и координировать работу команду при сбоях
ИТ-сервисы ежедневно сталкиваются с разными угрозами: техническими сбоями, ошибками при обновлении, кибератаками, проблемами на стороне внешних провайдеров. Как итог, сотрудники теряют доступ к нужным инструментам, клиенты не могут воспользоваться сервисом, а бизнес несет убытки.
Полностью исключить подобные ситуации невозможно. Но можно снизить их последствия — если заранее продумать, как на них реагировать. Именно для этого существует управление инцидентами (Incident Management). В статье разберем, как выстроить этот процесс, чтобы быстрее возвращать сервисы к нормальной работе.
Представьте: кассир не может пробить чек, потому что касса зависла, или клиент банка не видит баланс в приложении. Для бизнеса это инцидент — сбой, который мешает людям делать свою работу или пользоваться услугой. Причем сервис не обязательно должен полностью «упасть»: задержка в доставке уведомлений или ошибка при оплате — тоже инцидент, даже если платформа в целом работает.
Управление инцидентами — ИТ-процесс, который описывает, как быстро вернуть сервис в рабочее состояние, кто за это отвечает и как оценить результат. Это часть ITSM (IT Service Management) — подхода к организации ИТ-работы, который охватывает не только разбор инцидентов, но и обработку запросов пользователей, а также улучшение качества услуг.
Без выстроенного процесса инцидент может затянуться на часы вместо минут: инженеры ищут причину сбоя вслепую, бизнес теряет продажи или клиентов, а пользователи не понимают, когда все заработает снова. Это особенно критично для компаний, где простой напрямую влияет на выручку или доверие клиентов — оплата, логистика, банковские приложения, SaaS-платформы с SLA.
Если сервер перестал отвечать, первая задача инженера — вернуть пользователям доступ: кассирам — проводить продажи, менеджерам — обрабатывать заказы, клиентам — оплачивать покупки.
Пока специалисты ищут решение, пользователям и бизнесу важно получать понятную информацию: какие сервисы затронуты, кто отвечает за восстановление и что уже сделано. Это тоже часть практики Incident Management. А завершается инцидент, как правило, проверкой результата — важно убедиться, что сервис снова выполняет все необходимые функции.
Как это работает на практике — показывают кейсы клиентов Kaiten, которые выстроили у себя процесс работы с обращениями и инцидентами:
В поддержку могут прийти 3 похожих обращения: «Перестали приходить уведомления», «Уведомления пропадают после каждого обновления» и «Подключите мне уведомления». Все они касаются одной функции, но за каждым стоит разная задача — и разная логика работы:
От типа обращения зависит, как с ним работать и что считать результатом. Если смешивать инциденты, проблемы и сервисные запросы, команда рискует потратить время впустую: например, искать корневую причину вместо того, чтобы сначала вернуть доступ пользователям, или наоборот — закрывать симптом перезапуском сервера раз за разом, не разбираясь, почему сбой повторяется.
Работа с инцидентом начинается с первого сообщения о сбое и заканчивается, когда сервис восстановлен и результат проверен. Между этими точками команде нужно оценить последствия, найти решение и при необходимости подключить коллег.
Общий путь выглядит так:
Некоторые этапы могут идти параллельно. Например, инженеры могут искать причину сбоя, пока поддержка собирает обращения, а пользователям сообщают о ходе работ на протяжении всего инцидента.
Сообщение об инциденте может прийти от пользователя, сотрудника или системы мониторинга. Главное — сразу зафиксировать его в общей системе, чтобы обращение не потерялось, а команда видела, сколько людей затронул сбой. На старте достаточно зафиксировать:
Не стоит превращать этот этап в длинный опросник — дополнительные сведения можно собрать уже во время диагностики.
Сначала специалист поддержки относит инцидент к подходящей категории — например, сеть, доступы или конкретное приложение. Так обращение попадет к тем, кто сможет его проверить и исправить.
Дальше команда присваивает инциденту приоритет. Для этого оценивают два фактора:
Например, если уведомления о комментариях не приходят, но сами комментарии доступны в приложении, работу можно продолжать. Если же пользователи не получают код доступа и не могут попасть в сервис, приоритет будет выше.
Приоритет может меняться по ходу инцидента. Например, если сначала сбой заметил один пользователь, а через 10 минут выяснилось, что сервис недоступен всем клиентам, его нужно пересмотреть.
Похожий подход к маршрутизации и приоритизации обращений выстроило у себя рейтинговое агентство «Эксперт РА» — там критичность и тип обращения определяют, попадет ли задача на первую линию поддержки или сразу уйдет команде разработки:
У каждого инцидента должен быть ответственный — как правило, это дежурный инженер или специалист первой линии поддержки, который принял обращение. Он не обязательно сам устраняет сбой, но следит за ходом работы: кто подключен, что уже проверили и какой следующий шаг. Если инцидент сложный и требует разных специалистов — например, сетевого инженера и разработчика приложения, — ответственный координирует их действия, а не решает все в одиночку.
Отдельный случай — массовый инцидент : сбой, из-за которого за короткое время поступает сразу несколько связанных обращений. Например, у десятков пользователей одновременно перестает открываться личный кабинет. Для таких инцидентов роли в команде лучше распределить заранее — чтобы в момент сбоя не терять время на то, кто за что отвечает.
При этом массовый инцидент — не всегда критичный. Массовость показывает масштаб, а критичность — последствия. Сбой может затронуть много пользователей, но не остановить работу. И наоборот, проблема у одного пользователя может полностью остановить важный бизнес-процесс.
Если специалисту не хватает знаний, доступа или ресурсов, инцидент нужно эскалировать — иными словами подключить тех, кто сможет помочь.
Эскалация бывает двух типов:
Чтобы вовремя подключать нужных специалистов или руководителей, критерии эскалации стоит определить заранее. Инцидент передают на следующий уровень, если, например, за отведенное на диагностику время не удалось найти решение, сбой затронул больше пользователей или появился риск нарушить согласованный срок восстановления. Так работает ИТ-команда российского подразделения Julius Meinl — производителя кофе и чая.
Когда причина сбоя понятна, выберите способ быстро и безопасно восстановить работу сервиса:
Выбор лучше делать исходя из того, что быстрее и безопаснее для пользователей прямо сейчас — полный разбор причины можно продолжить уже после восстановления.
Если сервис снова работает и проверка пройдена, сообщите об этом пользователям — там же, где они узнали о сбое: в статус-странице сервиса, чате поддержки, рассылке или канале, который компания обычно использует для таких уведомлений (например, канал в мессенджере, баннер в приложении или на сайте). Если есть ограничения или от пользователей требуются дополнительные действия, укажите это сразу. Например: «Отправка уведомлений восстановлена. Новые сообщения приходят в обычном режиме. Отдельно проверяем письма, которые задержались во время сбоя».
Внутри команды запись об инциденте фиксируют в системе, где ведется работа с задачами и инцидентами — например, в карточке в Кайтене. Так запись останется доступной всей команде и ее можно будет найти при похожем сбое в будущем. В записи укажите:
Здесь главная цель — найти слабые места в процессе, а не виноватого. Такой подход, например, применяют в Google . Акцент лучше делать на конкретных улучшениях: добавить мониторинг, новую проверку перед релизом или обновить инструкцию восстановления.
Чтобы оценить работу команды, нужно заранее определить, за какое время она должна отреагировать на сбой.
Эти требования фиксируют в SLA (Service Level Agreement) — соглашении об уровне обслуживания между поставщиком ИТ-услуг и заказчиком. В нем определяют, какого качества услуг может ожидать заказчик, в том числе как быстро команда должна реагировать на инциденты и устранять их последствия.
Например, критичный сбой нужно взять в работу за 10 минут и восстановить сервис за час, а для некритичного можно установить более длинный срок. Конкретные значения зависят от важности сервиса и допустимого времени простоя.
Соблюдение SLA показывает, выполняет ли команда договоренности. А разобраться, где возникают задержки и что можно улучшить, помогают метрики:
Рост MTTA может означать, что инциденты слишком долго ждут ответственного, а рост MTTR — что время теряется на диагностике, эскалации или восстановлении. Если одни и те же сбои повторяются, стоит уже отдельно разбираться с их причиной.
При этом важно смотреть не только на средние значения. Например, среднее время первого ответа может составлять 5 минут, хотя часть обращений регулярно остается без реакции гораздо дольше. Поэтому стоит смотреть и на долю инцидентов, которые команда не успевает обработать в установленный срок.
В Kaiten процесс управления инцидентами можно собрать из модуля «Службы поддержки» ( Service Desk ), досок, карточек, SLA и автоматизаций.
Внедрите систему управления инцидентами, чтобы собирать обращения. Служба поддержки принимает заявки из почты, мессенджеров и веб-формы и создает по ним карточки. В них команда ведет работу и переписку с заявителем.
Настройте этапы процесса под свою команду. Например: «Новые» → «Диагностика» → «Восстановление» → «Проверка» → «Закрыто». Категорию и приоритет можно хранить в полях или метках, а критические инциденты — выделить отдельной дорожкой. Чтобы не создавать пространство с нуля, воспользуйтесь бесплатным шаблоном для работы с инцидентами и разбора причин от команды Kaiten — его можно адаптировать под процессы вашей команды.
Добавьте SLA. В Kaiten можно задать сроки первой реакции, выполнения заявки и отдельных этапов, учитывать рабочий календарь и следить за таймерами.
Свяжите работу нескольких команд. Например, команда биржи грузоперевозок в России и СНГ ATI.SU создала отдельную доску для обращений по SLA, а задачи между отделами связала через дочерние карточки. Такой же подход можно использовать для инцидентов: в основной карточке хранить общий статус, а в связанных — работу отдельных специалистов.
Автоматизируйте рутину. Начните там, где теряется время. Скажем, для критических инцидентов можно автоматически назначать ответственного, добавлять участников и применять SLA, а при эскалации — перемещать карточку нужной команде. Настройки описаны в автоматических правилах .
Фиксируйте решения и анализируйте метрики. Типовые способы устранения сбоев можно хранить в базе знаний Kaiten , а статистику по SLA и срокам использовать для отчетности. Например, раньше ИТ-команда сети ветклиник «Белый клык» и «Центр» получала заявки через почту и мессенджеры, поэтому часть запросов терялась, а сроки было сложно контролировать. С Kaiten команда отслеживает время решения инцидентов: некритичные в среднем закрывают за 12–13 дней, а 75% всех инцидентов — менее чем за 20 дней.
Только знакомитесь с Кайтеном? Попробуйте готовый шаблон службы поддержки Скопируйте шаблон бесплатно и проверьте процесс на реальных обращениях. Клиентам не нужна регистрация, чтобы подать заявку. Попробовать бесплатно Типичные ошибки при работе с инцидентами Оставлять обращения в личных сообщениях. Такие заявки легко потерять: их не видит команда, нельзя передать коллеге или проконтролировать срок. Переносите обращения в общую систему и продолжайте работу там.
Назначать приоритет по должности заявителя. Приоритет инцидента должен зависеть от влияния и срочности: сколько пользователей затронуто, какие процессы остановились и сколько времени есть на восстановление.
Не сообщать о ходе работ. Если пользователи не понимают, что происходит, они начинают писать повторно. Сообщайте текущий статус и время следующего обновления, даже если причина сбоя пока неизвестна.
Не фиксировать решение. Сохраняйте, что сделали для восстановления и как проверили результат. Типовые решения стоит добавлять в базу знаний, чтобы не пришлось повторять диагностику заново.