MTBF и MTTR: почему час ремонта может означать четыре часа недоступности

Начните с решения и функции оборудования

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

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

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

Дайте каждому времени собственное название

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

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

IBM в своём определении MTTR включает уведомление, подготовку, ремонт и проверку перед запуском. Поэтому чужую подпись «MTTR» следует читать вместе с правилами расчёта. В нашем журнале оба показателя названы полностью, чтобы час активного ремонта не подменял полный срок восстановления. IBM: MTTR и MTBF.

Учебный журнал: сто часов и два отказа

Все числа вымышлены. Наблюдаем одно устройство в непрерывном требуемом окне от часа 0 включительно до часа 100, не включая правую границу. Когда устройство исправно, оно работает; простоя из-за отсутствия заказа, планового обслуживания и других исключений нет. Два инцидента целиком лежат внутри окна и не пересекаются.

• Отказ F1 произошёл в час 10. Ремонт начался в 11, закончился в 11,75; проверка и возврат завершены в 12. Полная недоступность — 2 часа, активный ремонт — 0,75 часа.
• Отказ F2 произошёл в час 60. Ремонт шёл с 64 до 65,25; проверка закончилась в 66. Полная недоступность — 6 часов, активный ремонт — 1,25 часа.

Суммарно ожидание до ремонта занимает 1 + 4 = 5 часов, ремонт — 0,75 + 1,25 = 2, проверка — 0,25 + 0,75 = 1. Контроль: 5 + 2 + 1 = 8 часов недоступности. Наработка в выбранном окне: 100 − 8 = 92 часа.

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

Три результата из одних событий

Наблюдаемая наработка на зарегистрированный отказ равна 92 / 2 = 46 часов. Именно отношение суммарного времени работы к числу отказов используется для оценки MTBF в модели постоянной интенсивности, рассмотренной NIST. Отношение можно проверить по журналу; вывод о будущей надёжности дополнительно требует подходящих предпосылок. Два отказа сами по себе их не подтверждают. NIST: оценка MTBF и доверительные границы.

Средняя полная длительность восстановления двух завершённых инцидентов равна (2 + 6) / 2 = 4 часа. Средний активный ремонт — 2 / 2 = 1 час. Эти результаты отвечают на разные вопросы и могут одновременно быть правильными.

Наблюдаемая доступность в принятом окне равна 92 / 100 = 92%. В этом специально согласованном примере тот же результат даёт 46 / (46 + 4). Подстановка одного часа активного ремонта даст 46 / 47 ≈ 97,87%, но оставит за пределами расчёта ожидание и проверку. Такая подмена не улучшила устройство.

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

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

Изменим пример: дополнительно возникает F3 в час 98, а на срезе в час 100 устройство ещё не восстановлено. Внутри окна уже есть 2 часа этого простоя. Общая недоступность становится 8 + 2 = 10 часов, наработка — 90, наблюдаемая доступность — 90%.

Среднее по двум завершённым восстановлениям по-прежнему равно четырём часам, но рядом требуется показать один открытый случай и не менее двух часов уже прошедшего ожидания. Деление 10 / 3 не даёт среднего полного срока восстановления трёх отказов: для F3 известна только часть.

Если F3 завершится в час 110, его полная длительность составит 12 часов. Среднее по когорте этих трёх начавшихся инцидентов станет (2 + 6 + 12) / 3 ≈ 6,67 часа. При этом доступность первоначального окна 0–100 останется 90%: последующие десять часов относятся уже к следующему интервалу наблюдения.

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

Не складывайте несколько заявок как несколько простоев

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

Если на одном устройстве интервалы недоступности 10–12 и 11–13 описаны разными задачами, их объединение составляет три часа, а не четыре. При этом два разных устройства, каждое недоступное два часа, дают четыре машино-часа. Их нельзя делить на календарное окно одного устройства.

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

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

Как выбрать проверяемое улучшение

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

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

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

Не назначайте профилактику «каждые 46 часов» из учебного среднего. Выбор политики замены требует отдельной постановки и заранее разрешённых технических вариантов.

Данные и приёмочный чек-лист

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

1. Для F1 и F2 восстанавливаются 8 часов недоступности и 92 часа работы.
2. MTBF-подобное наблюдаемое отношение равно 46 часам, полное восстановление — четырём, активный ремонт — одному.
3. Доступность 92% подтверждается прямым делением времени.
4. В сценарии с F3 доступность окна падает до 90%, а незавершённое восстановление остаётся открытым.
5. Несколько документов одного отказа не увеличивают число отказов.
6. Перекрывающиеся интервалы одного устройства не удваивают простой.
7. История наработки и технические ограничения не меняются ради улучшения показателя.

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

Короткие ответы

MTTR всегда означает только работу мастера?

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

Если отказы реже, доступность обязательно выше?

Не обязательно: восстановление может стать дольше. Проверьте обе части и прямое время недоступности в одном окне.

Можно по MTBF обещать дату следующей поломки?

Нет. Среднее отношение не является календарным предсказанием конкретного отказа или безопасным сроком обслуживания.

Источники и границы примера

• NIST: constant repair rate model — оценка по суммарной наработке, предпосылки и неопределённость.
• IBM: MTTR vs. MTBF — различие показателей и состав полного восстановления.

Проверено 11 октября 2026 года. Журнал, числовые сценарии, правила разметки и приёмочные проверки разработаны как учебный операционный пример. Они не являются данными клиента или инструкцией по физическому ремонту.