Close

Управление инцидентами для высокоскоростных команд

Что такое управление инцидентами?

Управление инцидентами — это процесс реагирования на незапланированное событие или прекращение предоставления услуги с целью возобновить предоставление этой услуги. Данный процесс реализуется командами разработчиков и группами по эксплуатации ИТ.

В Atlassian мы определяем инцидент как событие, которое приводит к нарушению или снижению качества работы сервиса и требует незамедлительных действий. В командах, которые придерживаются практик ITIL или ITSM, такое событие могут называть «серьезным инцидентом».

Справочник по управлению инцидентами

Загрузите наш справочник по управлению инцидентами

Скачайте PDF-файл, чтобы изучить принципы и методы управления инцидентами, а также научиться применять эти знания в Jira Service Management.

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

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

Важность управления инцидентами

Ценность управления инцидентами

Ценность управления инцидентами в Atlassian

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

При работе с инцидентом команде необходим план:

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

Хотите узнать, как Atlassian справляется с крупными инцидентами? Мы опубликовали наш внутренний справочник по управлению инцидентами. Вы можете свободно использовать его для обучения или в своей работе.

Виды процессов управления инцидентами

Различные компании все чаще используют разные процессы управления инцидентами. Не существует универсального процесса, подходящего для всех, так что вы не найдете одинаковых процессов в разных компаниях.

Многие команды полагаются на более традиционные процессы управления инцидентами в ИТ, например процессы, описанные в сертификациях ITIL. Другие команды больше склоняются к таким процессам управления инцидентами, как SRE или DevOps.

Процесс управления инцидентами в ИТ

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

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

Шаги процесса управления инцидентами

Выявите инцидент и зарегистрируйте его

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

  • Имя человека, сообщающего об инциденте
  • Дата и время сообщения об инциденте
  • Описание инцидента (что не работает или работает не так, как должно)
  • Уникальный идентификационный номер, присвоенный инциденту, для отслеживания

Категория

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

Расставляйте приоритеты

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

Реагируйте

  • Первоначальная диагностика. В идеале ваша команда поддержки должна вести инцидент от его начала до закрытия, но если они не справляются, то они должны собрать полную запись информации по инциденту и передать ее команде выше по уровню.
  • Передача. При помощи полученных данных об инциденте следующая команда продолжит его диагностику, и, если она не справится, то его нужно передать следующей команде.
  • Коммуникация. Команда должна регулярно сообщать об обновлениях статуса внешним и внутренним заинтересованным лицам, на которых влияет инцидент.
  • Изучение и диагностика. Изучение и диагностика инцидента должны продолжаться, пока он не будет разрешен. Иногда команды могут привлечь внешние ресурсы или специалистов из других отделов, чтобы проконсультироваться и получить помощь в решении проблемы.
  • Разрешение и восстановление после инцидента. На этом шаге команда завершает диагностику и выполняет все необходимое, чтобы разрешить инцидент. Определяющим критерием при восстановлении после инцидента является время, которое будет затрачено на полное восстановление всех функций, так как уже после успешного восстановления может потребоваться установить и протестировать некоторые исправления (например, исправления багов).
  • Закрытие. Если инцидент разрешен, он передается обратно в службу поддержки для закрытия. Закрывать инциденты могут только сотрудники службы поддержки. Это позволяет поддерживать высокое качество обслуживания и последовательность в решении проблем. Владелец инцидента должен связаться с тем, кто сообщил о нем, и убедиться, что найденное решение является удовлетворительным и что инцидент действительно можно закрывать.

Процесс управления инцидентами в DevOps и SRE

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

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

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

Три принципа управления инцидентами в командах DevOps

  • Дежурство по очереди. Обычно команды DevOps не назначают конкретных членов команды на разрешение конфликтов, а создают график дежурств и распределяют его между членами команды.
  • Кто разработал, тот лучше всего подходит для внесения исправлений. Основная идея принципа «кто разработал, тот и запускает» заключается в том, что люди, которые больше знакомы с сервисом (разработчики), лучше всего подходят для исправления перебоев в его работе.
  • Разрабатывайте быстро, но не забывайте сообщать о прогрессе. Когда разработчики понимают, что они и их команда теряют время при сбое в работе, появляется стимул писать более качественный код.

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

В нашем Справочнике по управлению инцидентами мы описываем подход к управлению инцидентами, подходящий именно командам DevOps.

Инструменты управления инцидентами

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

  • Отслеживание инцидентов. Каждый инцидент должен отслеживаться и регистрироваться, чтобы в дальнейшем можно было выявлять закономерности при сравнении с другими инцидентами.
  • Комната чата. Канал для обмена текстовыми сообщениями в режиме реального времени, основной инструмент совместной диагностики и устранения инцидента в команде. Она также предоставляет подробную информацию для последующего анализа.
  • Видеочат. Видеочат дополняет текстовый чат для ведения нескольких инцидентов. В нем команда может обсудить свои выводы и определить стратегию реагирования.
  • Система оповещения. Такие инструменты, как Jira Service Management, могут быть подключены к вашей системе мониторинга и управлять дежурствами и эскалациями.
  • Инструмент ведения документации. Такие инструменты, как Confluence, могут использоваться для документирования текущего состояния инцидента и ретроспективы после разрешения.
  • Statuspage. Информирование клиентов и заинтересованных лиц внутри компании о ходе ситуации с помощью Statuspage позволяет держать всех в курсе дела.

Об управлении инцидентами

Обучающие руководства

Хотите узнать об управлении инцидентами в Jira Service Management?

Зарегистрируйтесь, чтобы получать дополнительные статьи и руководства

Thank you for subscribing

продолжение темы
IT service continuity management