Что такое наработка на отказ оборудования

MTBF — откуда берется «миллион часов MTBF»

Просто удивительно то, насколько велико непонимание вокруг такого широко распространенного понятия, как MTBF (Mean Time Between Failure — «Время между сбоями» или «наработка на отказ» ), насколько смысла этой величины не понимают, зачастую, даже специалисты в области хранения данных.

Казалось бы — что может быть проще. «Наработка на отказ» это время беспроблемной работы, от первого включения нового диска, до момента отказа, посчитанная в часах.
Почти любой, кто поинтересуется значением, приводимым производителями, в качестве MTBF современных дисков, и с легкостью сделает несложные подсчеты, будет удивлен странной его величиной.
На сегодня величина MTBF приводится в миллион или даже полтора миллиона часов.
В году — примерно 8760 часов, значит, исходя из нашего понимания «физического смысла» этого значения, производитель планирует «наработку на отказ» для любого такого диска более ста лет (114 лет, для миллиона часов MTBF), что является очевидной нелепостью для каждого, у кого подыхали жесткие диски.

Тогда что это за «миллион часов», где и каким образом он измерен?
Конечно же производитель не гоняет диск 114 лет, оценка производится искусственно, но откуда вообще взялась величина в «миллион часов»?

Дело в том, что MTBF измеряется для всей эксплуатируемой «дисковой популяции», и распространяется на период объявленного гарантийного срока для данного типа дисков. Оба выделенных момента являются важными, и часто опускаются в описании, что и приводит к принципиальному непониманию.

Представим себе, что мы поставили в сервер жесткий диск, который проработал 3 года гарантийного срока, и, будучи исправным, был заменен на новый. Следующий проработал три года, и был заменен по истечении гарантийного срока, и так далее. И вот на 38-м диске вы вправе ожидать, что до конца гарантийного срока он не доработает.

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

Строго говоря, на практике, вместо MTBF гораздо практичнее пользоваться параметром AFR — Annual Failure Rate, или «ежегодная вероятность сбоев», выводимом из MTBF.
Он вычисляется как: AFR = 1-exp(-8760/MTBF)
Величина AFR для диска с миллионом часов MTBF составляет 0,87%, что, в принципе, хоть и чуть завышено (Google в известном исследовании 2007 года показывает для новых дисков в пределах гарантийного срока как раз AFR в районе 1%), но, все же уже довольно хорошо согласуется с практикой.

Любопытно, что, например, такой производитель жестких дисков как WD теперь вовсе перестал указывать величину MTBF, перейдя на указание другого параметра: «power on/off cycles», по видимому не в последнюю очередь именно в связи с явно видимым непониманием и неочевидностью применения указываемой величины MTBF пользователями.

Источник

Наработка на отказ

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

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

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

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

Наработка — продолжительность или объем работы объекта, измеряемая в часах, мото-часах, гектарах, километрах пробега, циклов включений и др.

Измеряется статистически, путём испытания множества приборов, или вычисляется методами теории надёжности.

где t_i — наработка i-го объекта между отказами; m — число отказов.

Содержание

Определение по ГОСТ

ГОСТ 27.002-89 определяет данные параметры следующим образом:

Зарубежная терминология

Системы, связанные с обеспечением безопасности, можно условно подразделить на две категории:

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

Значение SIL (англ.) русск. для систем обеспечения безопасности с низкой частотой запросов непосредственно зависит от диапазонов порядков средней вероятности того, что она не сможет удовлетворительно выполнить свои функции по обеспечению безопасности по запросу, или, проще говоря, от вероятности отказа при запросе (PFD). Значение SIL для систем обеспечения безопасности, работающих в режиме высокой частоты запросов (непрерывно) непосредственно зависит от вероятности возникновения опасного отказа в час (PFH).

PFD (Probability of Failure on Demand, Вероятность отказа при запросе) — средняя вероятность того, что система не выполнит свою функцию по запросу. PFH (Probability of Failure per Hour, Вероятность возникновения отказа за час) — вероятность возникновения в системе опасного отказа в течение часа. MTTR (Mean Time to Restoration, Среднее время до восстановления работоспособности) — среднее время, необходимое для восстановления нормальной работы после возникновения отказа. DC (Diagnostic Coverage, Диагностическое покрытие) — отношение количества обнаруженных отказов к общему числу отказов.

В свою очередь, λ = частота отказов = 1/ MTBF

Среднее время безотказной работы системы

Пределы несобственного интеграла изменяются от 0 до ∞, так как время не может быть отрицательным; — есть плотность вероятности возникновения отказов системы или её невосстанавливаемого элемента. — есть вероятность безотказной работы в интервале времени . В начальный момент вероятность Р(T) равна единице. В конце времени работы системы вероятность равна нулю. Вероятность связана с плотностью вероятности возникновения отказов системы или её невосстанавливаемого элемента следующим образом:

.

Проинтегрировав выражение для по частям, получим:

Графически полученное выражение для представлено на рисунке как площадь под графиком вероятности безотказной работы Р(T) от времени T. В начальный момент вероятность Р(T) равна единице. В конце времени работы системы вероятность P(T) равна нулю.

Здесь — случайное время работы системы до отказа или наработка на отказ для невосстанавливаемого элемента или системы.

Источник

Что такое MTTR, MTBF, MTTF и MTTA? Руководство по метрикам управления инцидентами

Опубликовано: Февраль 09, 2021

Обновлено: октябрь 15, 2021

В этом сообщении в блоге

Амартья Гупта

Менеджер по маркетингу продукции

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

Давайте углубимся в каждую метрику.

Что такое среднее время ремонта (MTTR)?

В Управление ИТ-услугами промышленность, R в MTTR не всегда символизирует ремонт. Это также может означать выздоровление, ответ или решение. Несмотря на то, что все эти показатели соответствуют друг другу, они имеют свои последствия, поэтому всегда полезно уточнить, какой MTTR следует использовать. Давайте кратко рассмотрим, что означает каждое из них.

Как вы рассчитываете MTTR?

MTTR = общее время, затраченное на ремонт в течение данного периода / количество ремонтов

Предположим, что в системе было 6 сбоев, и обслуживание, необходимое для восстановления системы до полной функциональности, заняло 3 часа, что составляет 180 минут. Итак, MTTR будет,

MTTR = 180/6 = 30 минут

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

Что такое среднее время наработки на отказ (MTBF)?

Как вы рассчитываете MTBF?

Среднее время безотказной работы = общее время безотказной работы между отказами / общее количество отказов

Предположим, система отлично работает 13 часов. В течение этого периода произошло 3 отказа, в результате чего общее время простоя составило 1 час. Итак, MTBF будет,

Среднее время безотказной работы = (13-1) / 3 = 4 часа

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

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

Как мы упоминали ранее, MTBF используется для отслеживания отказов в ремонтируемых системах. Для отслеживания отказов, требующих замены системы, используется показатель, называемый «Среднее время до отказа» (MTTF).

Что такое среднее время до отказа (MTTF)?

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

Как вы рассчитываете MTTF?

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

MTTF = общее количество часов работы / общее количество отказов

MTTF = (14 + 16 + 12) / 3 = 14 часов.

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

Что такое среднее время подтверждения (MTTA)?

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

Как вы рассчитываете MTTA?

MTTA = общее время, прошедшее между предупреждением и подтверждением / общее количество инцидентов

Допустим, в организации произошло 5 инцидентов, и между предупреждением и подтверждением для всех инцидентов прошло в общей сложности 30 минут, тогда MTTA будет

MTTA = 30/5 = 6 минут

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

Заключение

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

Источник

Что такое наработка на отказ оборудования

НАДЕЖНОСТЬ В ТЕХНИКЕ

Термины и определения

Industrial product dependability. General concepts.
Terms and definitions

Дата введения 1990-07-01

1. РАЗРАБОТАН И ВНЕСЕН Институтом машиноведения АН СССР, Межотраслевым научно-техническим комплексом «Надежность машин» и Государственным Комитетом СССР по управлению качеством продукции и стандартам

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 15.11.89 N 3375

4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

Обозначение НТД, на который даны ссылки

Вводная часть, 5.1, 5.3

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

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

Настоящий стандарт должен применяться совместно с ГОСТ 18322.

1. Стандартизованные термины с определениями приведены в табл.1.

2. Для каждого понятия установлен один стандартизованный термин.

Применение терминов-синонимов стандартизованного термина не допускается.

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

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

2.3. В случаях, когда в термине содержатся все небходимые и достаточные признаки понятия, определение не приведено и в графе «Определение» поставлен прочерк.

2.4. В табл.1 в качестве справочных приведены эквиваленты стандартизованных терминов на английском языке.

3. Алфавитные указатели содержащихся в стандарте терминов на русском языке и их английских эквивалентов приведены в табл.2-3.

5. В приложении даны пояснения к терминам, приведенным в настоящем стандарте.

1.1. Надежность
Reliability, dependability

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

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

1.2. Безотказность
Reliability, failure-free operation

Свойство объекта непрерывно сохранять работоспособное состояние в течение некоторого времени или наработки.

1.3. Долговечность
Durability, longevity

Свойство объекта сохранять работоспособное состояние до наступления предельного состояния при установленной системе технического обслуживания и ремонта

1.4. Ремонтопригодность Maintainability

Свойство объекта, заключающееся в приспособленности к поддержанию и восстановлению работоспособного состояния путем технического обслуживания и ремонта

1.5. Сохраняемость
Storability

Свойство объекта сохранять в заданных пределах значения параметров, характеризующих способности объекта выполнять требуемые функции, в течение и после хранения и (или) транспортирования

2.1. Исправное состояние
Исправность
Good state

Состояние объекта, при котором он соответствует всем требованиям нормативно-технической и (или) конструкторской (проектной) документации

2.2. Неисправное состояние Неисправность
Fault, faulty state

Состояние объекта, при котором он не соответствует хотя бы одному из требований нормативно-технической и (или) конструкторской (проектной) документации

2.3. Работоспособное состояние Работоспособность
Up state

Состояние объекта, при котором значения всех параметров, характеризующих способность выполнять заданные функции, соответствуют требованиям нормативно-технической и (или) конструкторской (проектной) документации

2.4. Неработоспособное состояние
Неработоспособность
Down state

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

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

2.5. Предельное состояние Limiting state

Состояние объекта, при котором его дальнейшая эксплуатация недопустима или нецелесообразна, либо восстановление его работоспособного состояния невозможно или нецелесообразно

2.6. Критерий предельного состояния
Limiting state criterion

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

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

3. ДЕФЕКТЫ, ПОВРЕЖДЕНИЯ, ОТКАЗЫ

Событие, заключающееся в нарушении исправного состояния объекта при сохранении работоспособного состояния

Событие, заключающееся в нарушении работоспособного состояния объекта

3.4. Критерий отказа
Failure criterion

Признак или совокупность признаков нарушения работоспособного состояния объекта, установленные в нормативно-технической и (или) конструкторской (проектной) документации

3.5. Причина отказа
Failure cause

Явления, процессы, события и состояния, вызвавшие возникновение отказа объекта

3.6. Последствия отказа
Failure effect

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

3.7. Критичность отказа
Failure criticality

Совокупность признаков, характеризующих последствия отказа.

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

3.8. Ресурсный отказ
Marginal failure

Отказ, в результате которого объект достигает предельного состояния

3.9. Независимый отказ
Primary failure

Отказ, не обусловленный другими отказами

3.10. Зависимый отказ
Secondary failure

Отказ, обусловленный другими отказами

3.11. Внезапный отказ
Sudden failure

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

3.12. Постепенный отказ
Gradual failure

Отказ, возникающий в результате постепенного изменения значений одного или нескольких параметров объекта

3.13. Сбой
Interruption

Самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора

3.14. Перемежающийся отказ
Intermittent failure

Многократно возникающий самоустраняющийся отказ одного и того же характера

3.15. Явный отказ
Explicit failure

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

3.16. Скрытый отказ
Latent failure

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

3.17. Конструктивный отказ
Design failure

Отказ, возникший по причине, связанной с несовершенством или нарушением установленных правил и (или) норм проектирования и конструирования

3.18. Производственный отказ
Manufacturing failure

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

3.19. Эксплуатационный отказ
Misuse failure, mishandling failure

Отказ, возникший по причине, связанной с нарушением установленных правил и (или) условий эксплуатации

3.20. Деградационный отказ
Wear-out failure, ageing failure

Отказ, обусловленный естественными процессами старения, изнашивания, коррозии и усталости при соблюдении всех установленных правил и (или) норм проектирования, изготовления в эксплуатации

4. ВРЕМЕННЫЕ ПОНЯТИЯ

4.1. Наработка
Operating time

Продолжительность или объем работы объекта.

Примечание. Наработка может быть как непрерывной величиной (продолжительность работы в часах, километраж пробега и т.п.), так и целочисленной величиной (число рабочих циклов, запусков и т.п.).

4.2. Наработка до отказа
Operating time to failure

Наработка объекта от начала эксплуатации до возникновения первого отказа

4.3. Наработка между отказами
Operating time between failures

Наработка объекта от окончания восстановления его работоспособного состояния после отказа до возникновения следующего отказа

4.4. Время восстановления
Restoration time

Продолжительность восстановления работоспособного состояния объекта

Источник

MTBF, MTTR, MTTA и MTTF

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

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

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

Некоторые из наиболее часто отслеживаемых в отрасли метрик: MTBF (средняя наработка на отказ), MTTR (среднее время восстановления, исправления, реагирования или устранения), MTTF (средняя наработка до отказа) и MTTA (среднее время подтверждения) — эти метрики предназначены для того, чтобы помочь техническим командам понять, как часто происходят инциденты и как быстро команда справляется с ними.

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

С другой стороны, MTTR, MTBF и MTTF могут быть хорошей основой или эталоном, с которых стоит начинать обсуждение более глубоких и важных вопросов.

Как профессионалы реагируют на крупные инциденты

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

Оговорка об MTTR

Говоря об MTTR, можно предположить, что это один показатель с одним значением. В действительности за ним скрываются четыре разных показателя. «R» может означать решение (repair), реагирование (respond), устранение (resolve) или восстановление (recovery), и хотя эти четыре показателя перекрываются, каждый имеет собственный смысл и особенности.

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

MTBF: средняя наработка на отказ

Что такое средняя наработка на отказ?

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

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

Как рассчитать среднюю наработку на отказ

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

Итак, предположим, что мы оцениваем 24-часовой период и за этот период мы потеряли два часа из-за двух отдельных инцидентов. Наше общее время безотказной работы составляет 22 часа. Разделим на два и получаем 11 часов. Итак, наша наработка на отказ составляет 11 часов.

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

Происхождение понятия средней наработки на отказ

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

Как и когда использовать среднюю наработку на отказ

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

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

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

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

MTTR: среднее время исправления

Что такое среднее время исправления?

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

Как рассчитать среднее время исправления

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

Итак, предположим, мы считаем эту метрику для ремонта в течение недели. За это время было 10 простоев, и системы активно ремонтировались в течение четырех часов. Четыре часа — это 240 минут. 240 делим на 10 и получаем 24. Что означает, что среднее время ремонта в этом случае будет составлять 24 минуты.

Ограничения среднего времени исправления

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

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

Как и когда использовать среднее время исправления

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

MTTR: среднее время восстановления

Что такое среднее время восстановления?

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

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

Как рассчитать среднее время восстановления

Среднее время восстановления рассчитывается путем суммирования всего времени простоя в работе за определенный период и деления его на количество инцидентов. Итак, предположим, что наши системы были отключены на 30 минут в течение двух отдельных инцидентов за 24-часовой период. 30 делим на два, получаем 15, так что наш MTTR составляет 15 минут.

Ограничения среднего времени восстановления

MTTR используется для измерения скорости полного процесса восстановления. Достаточно ли она высокая? А по сравнению с вашими конкурентами?

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

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

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

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

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

Как и когда использовать среднее время восстановления

MTTR является хорошей метрикой для оценки скорости общего процесса восстановления.

MTTR: среднее время разрешения

Что такое среднее время разрешения?

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

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

Существует сильная связь между этим MTTR и удовлетворенностью клиентов, так что этой метрике нужно уделить особое внимание.

Как рассчитать среднее время разрешения

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

Таким образом, если ваши системы были отключены в общей сложности 2 часа за 24-часовой период из-за одного инцидента и команды потратили еще 2 часа на исправление, чтобы гарантировать, что сбой системы не повторится, в сумме получается 4 часа, потраченных на решение проблемы. Это означает, что ваш MTTR составляет 4 часа.

Заметка об отслеживании среднего времени разрешения

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

Как и когда использовать среднее время разрешения

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

MTTR: среднее время реагирования

Что такое среднее время реагирования?

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

Как рассчитать среднее время реагирования

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

Например: если у вас было 4 инцидента за 40-часовую рабочую неделю и вы потратили на них 1 час (от оповещения до исправления), то MTTR за эту неделю будет составлять 15 минут.

Как и когда использовать среднее время реагирования

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

MTTA: среднее время подтверждения

Что такое среднее время подтверждения?

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

Как рассчитать среднее время подтверждения

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

Например: если у вас было 10 инцидентов и в общей сложности прошло 40 минут между отправкой оповещения и подтверждением его получения для всех 10, вы поделите 40 на 10 и получите в среднем 4 минуты.

Как и когда использовать среднее время подтверждения

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

MTTF: средняя наработка до отказа

Что такое средняя наработка до отказа?

MTTF (средняя наработка до отказа) — среднее время между неремонтируемыми отказами технологического продукта. Например, если автомобильные двигатели марки X исправно работают в среднем 500 000 часов, до того как они полностью выйдут из строя и будут подлежать замене, MTTF двигателей будет составлять 500 000.

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

Как рассчитать среднюю наработку до отказа

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

Например: предположим, вы рассчитываете MTTF лампочек. Как долго лампочки бренда Y в среднем работают, прежде чем они перегорают? Далее предположим, что для расчета у вас есть четыре лампочки (если вам нужны статистически значимые данные, вам понадобится гораздо больше, но, чтобы не перегружать вас расчетами, давайте возьмем всего четыре).

Лампочка А горит 20 часов. Лампочка B — 18. Лампочка C —21. И лампочка D —21 час. Это в общей сложности 80 часов горения лампочки. Делим на четыре и получаем MTTF в 20 часов.

Проблема, связанная со средней наработкой до отказа

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

Но что происходит, когда мы измеряем что-то, что не перегорает так быстро? Что-то, что должно бесперебойно работать в течение долгих лет? Хотя MTTF часто используется и для этих случаев, эта метрика — не лучший выбор. Потому что мы не держим продукт включенным до тех пор, пока он не выйдет из строя; в основном мы запускаем продукт на определенный период времени и измеряем количество выходов из строя.

Например: предположим, что мы пытаемся получить статистику MTTF на планшетах бренда Z. Планшеты по-хорошему рассчитаны на долгие годы, но у бренда Z есть всего шесть месяцев для сбора данных. Поэтому тестируют 100 планшетов в течение шести месяцев. Допустим, один планшет ломается ровно на шестимесячной отметке.

Итак, мы умножаем общее время работы (полгода, умноженное на 100 планшетов) и получаем 600 месяцев. Только один планшет вышел из строя, так что мы разделим значение на один, и наш MTTR будет составлять 600 месяцев, то есть 50 лет.

Прослужат ли планшеты Brand Z в среднем 50 лет каждый? Маловероятно. И поэтому эта метрика не подходит в таких случаях.

Как и когда использовать среднюю наработку до отказа

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

MTBF, MTTR, MTTF и MTTA

Итак, какую метрику лучше использовать, когда дело доходит до отслеживания и улучшения управления инцидентами?

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

Среднее время восстановления показывает, как быстро у вас получается возобновить работу ваших систем.

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

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

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

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

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

Надлежащее управление запросами на обслуживание означает, что вы даете ИТ-команде возможность сосредоточиться на том, что наиболее важно для организации в целом, одновременно повышая качество обслуживания клиентов. Гибкий программный инструмент, такой как Jira Service Management, может помочь вашей команде навести порядок и настроить рабочие процессы согласно потребностям команды.

Источник