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

Разрозненные процессы и технологии

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

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

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

Огромное количество оповещений и инцидентов

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

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

Рост расходов на эксплуатацию

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

Измерение неправильных показателей успеха

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

Даже полезные показатели, такие как среднее время реагирования (MTTR) и средняя наработка на отказ (MTBF), сами по себе не помогут повысить эффективность управления инцидентами. Они помогут выявить проблему, но не ответить на сложные вопросы, которые влияют на качество: почему и как возникают инциденты, как они разрешаются и как улучшить эти показатели.

Устаревшие структуры команды реагирования на инциденты

Вплоть до прошлого десятилетия реагирование на ИТ-инциденты в первую очередь поручали операционным командам. Для реагирования на проблемы, о которых сообщают клиенты или средства мониторинга, в компаниях обычно существовала команда с многоуровневой структурой (уровни 1–3).

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

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

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

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

Как оптимизировать процесс управления ИТ-инцидентами

Очевидно, что пришло время пересмотреть управление инцидентами, а также предложить процессы, структуру команд и методики, которые будут отражать современные реалии бизнеса. Но что именно для этого нужно сделать?

Определение приоритетов и объединение оповещений

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

Создайте график дежурств для ваших команд

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

Используйте автоматизацию везде, где возможно

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

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

Эффективная коммуникация по всем каналам, с любыми заинтересованными лицами

Инциденты несут последствия для различных внутренних и внешних заинтересованных сторон, которые нужно держать в курсе событий. Согласно исследованиям, 87 % заинтересованных сторон в компании хотят получать актуальную информацию об инцидентах (а 56 % больше волнует информирование об инциденте, чем сам факт его возникновения). И клиенты определенно с ними солидарны.

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

Упростите отслеживание метрик

Чем проще отслеживать показатели успеха и просматривать их, тем больше вероятность того, что ваша команда будет идти в ногу с ними. Автоматизируйте отчетность там, где это возможно, и узнайте, какие показатели важны для вашей команды и почему.

Проводите разборы инцидентов без поиска виновных

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

При разборе инцидента в компании Atlassian не ищут виновных. Мы полностью сосредоточены на улучшении производительности и прогрессе и не занимаемся перекладыванием вины.

Выберите технологию, поддерживающую ваши процессы и потребности

Автоматизация. Расстановка приоритетов для оповещений. Составление графиков дежурств. Отслеживание KPI. Эффективность этих процессов зависит от выбранного технического решения. Прежде чем сделать выбор, убедитесь, что вы понимаете свои цели, имеющиеся процессы и потребности команды. Если требуется автоматическая сортировка оповещений, исключение повторений и расстановка приоритетов, выберите решение с соответствующими возможностями, например Jira Service Management.