Пришло время поговорить... поговорить о времени решения проблемы и MTTR! Время решения - это метрика, которая существует столько, сколько я себя помню. Хотя время решения проблемы (или MTTR) не является чем-то новым, пришло время взглянуть на него поближе и понять, что на самом деле означает время решения проблемы.
Почему сейчас? Потому что время решения проблемы имеет значение... Очень большое! А время решения проблемы, по своей сути, является показателем удобства использования и пользовательского опыта. Это также один из тех показателей, которые очень плохо понимают и неправильно интерпретируют. Итак, давайте разбираться!
В этом руководстве "Время решать
Что такое "Время решать"?
Что вы имеете в виду под "временем на решение"?
Время решения проблемы (MTTR) дает нам среднее время, необходимое для решения случая или инцидента с тем же симптомом во время отключения или сценария решения проблемы:
Время на устранение = время от инцидента до устранения неполадок в течение времени отключения электроэнергии
По сути, время решения - это показатель, который говорит нам о том, как долго пользователи ждут конкретной ошибки. Неважно, сталкиваются ли люди с одной и той же проблемой или с другой, важно, сталкивались ли они с чем-то подобным раньше и сколько времени им требуется, чтобы восстановить работоспособность, найдя решение.
MTTD и MTTR: в чем разница?
MTTD и MTTR сделаны из одной ткани. Но это не одно и то же! MTTR показывает время, необходимое для восстановления работоспособности системы, в то время как MTTD показывает время с момента возникновения инцидента до его устранения. Для простоты мы сосредоточимся в этой статье на времени устранения инцидента, но я хотел, чтобы вы знали о небольшой разнице между MTTD и MTTR.
MTTD - это время с момента инцидента до момента его разрешения.
MTTR означает время, прошедшее с момента инцидента до момента его разрешения.
Пример: Время инцидента (TOI) и время разрешения (TOR)
Полезно думать о MTTR следующим образом: Проблема возникает в момент времени X, пользователю A требуется в среднем Y времени для поиска решения, а затем проблема решается в момент времени Z.
Также следует помнить, что MTTD означает время с момента возникновения инцидента до его устранения, а MTTR - время с момента возникновения проблемы до момента ее решения. Это может показаться тривиальным, но я думаю, что мы все не раз сталкивались с этой путаницей, поэтому я хотел убедиться, что все предельно ясно.
Когда следует измерять время решения?
Time To Resolve предоставляет нам отличные данные, когда нам нужно понять удовлетворенность пользователей повторяющимися ошибками - теми, которые имеют похожие симптомы. Например:
- Почему мой сайт снова не работает? Это случилось только на прошлой неделе! Я не могу поверить, что вы, ребята, не можете предотвратить это снова и снова...
- После обновления браузера я продолжаю получать это сообщение. Не могли бы вы попросить кого-нибудь взглянуть на это?
- Инструкции, которые вы прислали, не совсем понятны. Может ли кто-нибудь взглянуть на них еще раз?
Если время решения проблемы - это то, что вы можете измерить (а время решения проблемы возможно для всех), то время решения проблемы поможет вам понять, сколько времени требуется вашим пользователям для восстановления работоспособности после сбоя. По сути, сколько времени потребовалось пользователям, прежде чем они смогли снова приступить к работе после возникновения проблемы?
В конце концов, "время" - это деньги! Поэтому давайте посмотрим, как сделать так, чтобы время на решение всегда было доступно для использования ...
Время решения позволяет нам рассчитать время, в течение которого ваши пользователи ожидают решения проблемы. Затем мы можем сравнить эти данные по времени и по разным командам. Существует несколько других ключевых показателей эффективности (KPI), которые используются для определения наличия проблем в этой области - время решения проблемы является одним из них!
Как измерить время до решения?
Прежде всего, для того чтобы использовать время решения проблемы, его необходимо измерить. Время решения проблемы может измеряться одним из трех способов: (1) время с момента инцидента до момента решения проблемы (2) время во время отключения, (3) время с момента инцидента до момента закрытия. У каждого метода есть свои преимущества и недостатки, а также способы отчетности, поэтому имейте их в виду при выборе метода для своей команды. Давайте рассмотрим эти три метода ниже.
1.) Время от инцидента до момента устранения неполадки: Это отличная метрика для команд, которые хотят быстро реагировать на ситуацию, поскольку вы можете быстро получить данные после того, как произошел сбой. Одним из недостатков является то, что вы теряете некоторые исторические данные, если что-то еще не было решено в течение 72 часов (что когда-то считалось хорошей практикой), но это ускоряет работу в течение более длительных периодов времени, что может помочь с временем подготовки отчета. Время решения проблемы во время перерыва в работе - одна из наших самых популярных метрик времени решения проблемы!
2.) Время от инцидента до времени закрытия: Вот пример времени от инцидента до времени или времени закрытия, где видно, что между моментом начала проблемы и моментом, когда пользователю в этом конкретном билете пришло время вернуться к работе, прошло 100 минут. Этот метод занимает больше времени, чем просто сбор данных сразу после сбоя, но он дает нам гораздо больше исторических данных за более длительный период времени. Эти данные могут быть проанализированы различными командами для того, чтобы понять, что является самым длительным (и почему).
3.) Время с момента выявления проблемы до момента ее закрытия: Вот еще один пример времени от момента выявления проблемы до момента ее решения. На этот раз вы видите, что пользователю потребовалось 50 минут, чтобы решить свою проблему, а также видно, что в этот раз были взяты данные за несколько дней, а не за один. Помните, что получить эти данные сложнее, чем в других методах, поскольку проблемы обычно обновляются по мере их прохождения через ваш рабочий процесс - поэтому имейте в виду, что нам нужно не менее 24 часов между обновлениями, прежде чем мы получим какие-либо данные о времени решения.
Обычно Time To Resolution (измерение) относится к одной из этих трех категорий:
- во время простоев (время сбора данных включает время простоя и время, необходимое персоналу для устранения проблемы)
- после отключения (через несколько дней или недель после сбора данных)
- время в очереди (время начала в системе до времени закрытия в системе).
Ваши пользователи ждут, что теперь?
Вот где время решения проблемы становится сложным! Помните, что "время" - это деньги, поэтому важно, чтобы вы не торопились обрабатывать данные и превращать их в нечто полезное. Некоторые вопросы для вас могут быть следующими:
- Насколько велика эта проблема на самом деле?
- Как выглядит эта проблема с течением времени? Наблюдаются ли какие-либо тенденции?
- Улучшается или ухудшается способность моей команды быстро решать проблемы?
Получить данные о времени решения проблемы и превратить их в нечто полезное может быть непросто - иногда у команд есть так много информации, но они знают, что не могут внести изменения без данных о времени решения проблемы. Получив данные о времени решения проблемы, вы сможете не только сравнить себя с коллегами по отрасли, но и увидеть, насколько эффективно используется ваше время в этой области!
Советы по сокращению времени решения проблемы и MTTR
Итак, вы знаете, что такое время на разрешение, как его измерять и отслеживать. Теперь вы хотите уменьшить этот важный показатель. Вот наши любимые советы!
- Не бойтесь прекратить делать то, что отнимает много времени, но не имеет значения. Если вы тратите свое время на множество дел, которые только добавляют время, но не приносят пользы, возможно, пришло время пересмотреть эти виды деятельности.
- Начните использовать (или продолжайте использовать) платформу наблюдаемости или систему управления инцидентами, например Pagerduty, или альтернативные варианты, где меньше возможностей для ошибок, в отличие от электронной почты или электронных таблиц, если вы в настоящее время отслеживаете инциденты именно таким образом. Электронная почта может потеряться или забыться, электронные таблицы становятся беспорядочными и запутанными, и в конечном итоге время будет уходить, пока вы будете ходить туда-сюда, пытаясь решить проблемы.
- Всегда расставляйте приоритеты в работе - начинайте сначала с самых важных задач, поскольку они займут больше всего времени, а затем расставьте приоритеты по времени выполнения задачи для экономии времени.
- Другие способы улучшения времени решения проблемы включают: наличие четкого процесса, которому легко следовать, обеспечение надлежащего обучения вашей команды на всех уровнях и постоянное знание того, какие билеты находятся в очереди - таким образом вы будете точно знать, сколько пользователей ждут вас!
Время до разрешения и MTTR - последние мысли
Время решения проблемы - это отличный показатель качества работы ИТ-отдела. Он используется как индикатор того, что проблемы решаются правильно и с учетом управления временем. Эффективный показатель времени решения означает, что проблемы решаются достаточно быстро для того, чтобы команды могли устранить проблемы, но не слишком быстро, когда они считаются "тушением пожара", а не действительно углубляются в анализ первопричины проблемы. Хороший KPI времени решения помогает командам ответить на вопросы об обслуживании клиентов, эффективности, времени, затраченном на выполнение задач, и т.д. Поэтому важно не просто "сосредоточиться" на времени решения, но и понять, что оно означает для вашей команды!
