Что такое MTTR и как он отличается от других показателей управления инцидентами?

Содержание статьи:
● Что означает управление инцидентами?● В чем разница между всеми значениями MTTR?- Среднее время для ответа- Среднее время для ремонта- Среднее время для решения или исправления- Среднее время для восстановления● Разница между MTTR и другими метриками DevOps- Среднее время обнаружения (MTTD)- Среднее время для признания (MTTA)- Среднее время до отказа (MTTF)- Среднее время между отказами (MTBF)● Как измерить MTTR и сократить время реакции на инцидент с помощью AI и автоматизации? 

Поддерживать сетевую систему в рабочем состоянии⁠ — критическая задача. Для ее исполнения DevOps и ITOps команды полагаются на показатели управления инцидентами, такие как среднее время для ремонта (mean time to repair, или MTTR), время безотказной работы, время простоя, количество инцидентов, время между инцидентами и время для ответа и решения проблемы.

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

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

Давайте рассмотрим, что означает каждый показатель управления инцидентами и как они связаны с другими
показателями DevOps, такими как MTTA, MTTF и MTBF.

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

ІТ-инцидент — это непредсказуемое или неожиданное событие, которое вызывает сбой или отключение в работе службы, что прерывает бизнес операции. У него есть четыре основных этапа:
Идентификация: выявление и запись подробностей произошедшего, определение приоритетности инцидентов с точки зрения влияния и срочности и оценка уровня влияния на клиентов и бизнес. Для идентификации необходимы показатели среднего времени обнаружения — MTTD и среднего времени подтверждения — MTTA.Карантин: совершение действий для защиты пострадавших систем, быстрое решение инцидентов и передача события по необходимости другим командам. Для этого этапа важны показатели среднего времени на ответ и средней продолжительности ремонта.Решение: завершение исправлений и определение окончания воздействия на бизнес. В этом случае показателем является время решения.Техническое обслуживание: уменьшение риска повторного возникновения инцидента посредством анализа первопричины и постоянного усовершенствования системы. Здесь показателями являются интервал между инцидентами, то есть среднее время между отказами – MTBF и среднее время до отказа – MTTF.
Для оптимального клиентского сервиса большинство систем управления ІТ-инцидентами используют определенную форму приведенных показателей для эффективной обработки инцидентов и поддержки бесперебойного обслуживания.

Illustration

В чем разница между всеми значениями MTTR?

MTTR может означать среднее время для ответа (response), ремонта (repair), решения (resolve) и восстановления (recover). Каждое из них отличается и занимает свое место в системе управления инцидентами.

  • Среднее время для ответа

    Среднее время для ответа (mean time to respond) — это время, которое требуется командам DevOps для ответа после получения уведомления.

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

    Замер MTTR происходит с момента обнаружения инцидента командой до момента запуска (или завершения) плана ремонта или исправления. Далее это время делят на количество уведомлений, на которые команда ответила за определенный промежуток времени.

    MTTR часто используется в кибербезопасности вместе со средним временем обнаружения (mean time to detect, или MTTD). Это позволяет измерять успех команды в нейтрализации системных атак, а также способность предусматривать и предотвращать будущие нарушения безопасности.

  • Среднее время для ремонта

    Среднее время для ремонта (mean time to repair) – это среднее время, необходимое для восстановления неисправного компонента, программы или службы.

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

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

    Организации часто включают MTTR в договор на техническое обслуживание или соглашение об уровне обслуживания (SLA). Если с одинаковым временем между отказами одна система имеет MTTR 24 часа, а другая — три дня, первая система более ценна, поскольку ее доступность выше.

  • Среднее время для решения или исправления

    Среднее время для устранения/исправления (mean time to resolve/remediate) — это время, необходимое для полной диагностики и устранения неисправности в системе.

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

    Чтобы рассчитать показатель, добавьте время, необходимое для диагностики и разрешения инцидентов в течение определенного периода времени, а затем разделите его на количество инцидентов. Если системы не работали в течение двух часов в течение 24-часового периода, а команды потратили два часа на диагностику и устранение сбоя, время для решения составляет четыре часа.

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

  • Среднее время для восстановления

    Среднее время восстановления (mean time to recovery) показывает все время, необходимое для восстановления работоспособности пораженной сети или системы.

    Замер времени начинается, когда впервые срабатывает предупреждение, и заканчивается, когда все пораженные системы функционируют в обычном режиме.

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

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

Разница между MTTR и другими метриками DevOps

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

  • Среднее время обнаружения (MTTD)

    Среднее время обнаружения (mean time to detect) измеряет, сколько времени проблема существует прежде чем проявится.

    MTTD является ключевым показателем эффективности для DevOps и IT-команд. MTTD также называют средним временем идентификации (mean time to identify, MTTI). MTTD – это время, необходимое для обнаружения инцидента или получения уведомления о нем.

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

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

  • Среднее время для признания (MTTA)

    Среднее время до подтверждения (mean time to acknowledge) – это промежуток времени между тем, когда система генерирует оповещение и когда член команды отвечает.

    MTTA отображает, сколько времени требуется члену команды, чтобы начать работу над проблемой после получения оповещения.

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

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

  • Среднее время до отказа (MTTF)

    Среднее время до отказа (mean time to failure) отображает промежуток, в который актив, не подлежащий ремонту, еще функционирует до полного отказа. Когда актив выходит из строя, команда заменяет его.

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

  • Среднее время между отказами (MTBF)

    Среднее время между отказами (mean time between failures) измеряет средний интервал между отказами систем, подлежащих ремонту. MTBF — это способ измерения надежности системы.

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

Как измерить MTTR и сократить время реакции на инцидент с помощью AI и автоматизации?

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

Платформа Dynatrace Software Intelligence отслеживает весь облачный стек. Dynatrace автоматически определяет проблемы и учитывает контекст при определении их причин, используя анализ дерева отказов.

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

Ваша команда DevOps может установить любой из показателей управления инцидентами как цель уровня обслуживания (service level objective или SLO), чтобы автоматизировать реагирование на инциденты и сократить MTTR. Воспользуйтесь формой ниже, чтобы получить доступ к платформе Dynatrace, чтобы испытать все ее возможности мониторинга систем и автоматизации обнаружения проблем.

Узнайте больше про Dynatrace

Illustration

2 года с Dynatrace - полет нормальный. Опыт OTP Bank Ukraine

Как устроен IT-мониторинг: о задачах, проблемах, подрядчиках, плохом коде, мониторинге, новых технологиях и "Кровавом enterprise" на практике от Артема Логвиненко, Head Of IT Operations Department, OTP Bank.

Illustration

Автоматизация рутины в ИТ с помощью AI

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

Illustration

Мониторинг Dynatrace в Kapital Bank: история успеха

Запись вебинара о том, как крупнейший банк Азербайджана реализовалмониторинг сложных приложений на базе Dynatrace.

Illustration

12-й раз подряд Лидер Gartner Magic Quadrant for APM & Observability 2022

Платформа Dynatrace является решением, которое дает наиболее исчерпывающую информацию о производительности в гибридной инфраструктуре.
Аналитики Gartner® в этом году выделили следующие конкурентные преимущества Dynatrace:● Мощная аналитика на базе искусственного интеллекта на уровне кода● Объединение Application Monitoring и Application Security● Уникальная архитектура и простота развертывания Dynatrace OneAgent

Испытайте пробную версию в своей инфраструктуре

● 15 дней абсолютно бесплатно● Не нужно вводить данные карты ● Установите и начните использовать менее чем через 5 минут