Как выбрать ключевые показатели эффективности и метрики управления инцидентами

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

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

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

Предположим, что компания стремится к разрешению всех инцидентов в течение 30 минут, но вашей команде это удается в среднем за 45 минут. Без конкретных показателей трудно понять, в чем проблема. Система оповещения срабатывает слишком медленно? В процессе что-то не работает? Нужны более современные диагностические инструменты? Эта проблема связана с командой или оборудованием?

Теперь добавьте показатели. Если точно известно, сколько времени требуется системе оповещения для срабатывания, вы сможете понять, является ли она причиной проблемы. Если диагностика занимает больше половины времени, вы можете сосредоточиться на устранении неполадок в ней. Если команда B работает на 25 % медленнее, чем команды A, C и D, можно попытаться понять, почему это происходит.

Количество созданных оповещений

Если вы используете инструмент оповещения, полезно знать, сколько оповещений генерируется за определенный период времени. С помощью решения Jira Service Management вы сможете отправлять оповещения, а также создавать отчеты и дашбоарды для их отслеживания.

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

Количество инцидентов за определенный период времени

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

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

MTBF

MTBF (средняя наработка на отказ) — среднее время работы технического продукта между устранимыми сбоями. С помощью этого показателя можно отслеживать доступность и надежность всех продуктов.

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

МТТА

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

Если выяснилось, что скорость реагирования недостаточно высокая, можно задать новые вопросы. Почему значение MTTA так велико? Команды перегружены, отвлекаются или не могут понять, кому адресовано оповещение? С помощью MTTA можно определить проблему, а подобные вопросы помогут добраться до ее сути.

MTTD

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

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

MTTR

MTTR может означать среднее время исправления, решения, реагирования или восстановления. Пожалуй, наибольшую пользу представляет среднее время решения. Этот показатель позволяет зафиксировать не только время, затраченное на диагностику и устранение непосредственной проблемы, но и время на предотвращение повторения такой проблемы в будущем. Восстановление является главным показателем DevOps; именно его, по мнению программы DevOps Research and Assessment (DORA), можно использовать для оценки стабильности команды DevOps.

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

Восстановление является главным показателем DevOps; именно его, по мнению программы DevOps Research and Assessment (DORA), можно использовать для оценки стабильности команды DevOps. Это совокупное время, которое уходит на обнаружение проблемы, смягчение ее последствий и полное устранение.

Время дежурства

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

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

sla

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

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

SLO

SLO (цель по уровню обслуживания) — это соглашение в рамках SLA о целевом значении того или иного показателя, например времени безотказной работы. Как и в случае с соглашением SLA, SLO являются важными показателями, которые нужно отслеживать, чтобы гарантировать, что компания выполняет свою часть соглашения в вопросах обслуживания клиентов.

Временная метка (или временная шкала)

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

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

Время бесперебойной работы

Время безотказной работы — это количество времени (в процентах), в течение которого системы доступны и работоспособны.

С расширением взаимосвязей онлайн-сервисов и ростом сложности самих систем стало понятно, что гарантия безотказной работы в течение 100 % времени невозможна. В случае с большинством продуктов стремятся обеспечить высокую доступность, то есть создать такую систему или продукт, которые могут работать без перерыва в течение длительного времени. Согласно отраслевому стандарту, безотказная работа в течение 99,9 % времени — это очень хороший результат, а в течение 99,99 % — отличный.

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

Чего стоит бояться в аналитике инцидента

У KPI есть недостатки. Так, можно легко попасть в зависимость от малосодержательных данных. Если ваша команда разрешает инциденты недостаточно быстро, для решения проблемы потребуется нечто большее, чем простое осознание этого факта. Вам нужно понимать, как и почему команда решает или не решает проблемы. Кроме того, нужно знать, сопоставимы ли проблемы, которые вы сравниваете.

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

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