Надежность изделия: НАДЕЖНОСТЬ ИЗДЕЛИЯ | это… Что такое НАДЕЖНОСТЬ ИЗДЕЛИЯ?

8. Надежность изделия и пути ее обеспечения.

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

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

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

Безотказность
– это свойство изделия сохранять
работоспособность в течение некоторой
наработки без вынужденных перерывов.

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

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

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

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

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

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

Частичный отказ
– отказ, обычно связанный с ухудшением
какой-либо одной из характеристик
(параметров) элемента.

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

Параметрические
отказы

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

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

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

Постепенные
отказы

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

Устойчивые отказы
– отказы, устраняющиеся только в
результате ремонта или регулировки,
либо замены отказавшего элемента.

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

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

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

Показатели
надежности неремонтируемых
изделий

это вероятность
безотказной работы, средняя наработка
до отказа, частота и интенсивность
отказов,
а
для ремонтируемых
изделий

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

Вероятность
безотказной работы

изделий p(t)
– это вероятность того, что в заданном
интервале времени и при заданных условиях
эксплуатации не произойдет отказа. Для
определения надежности можно пользоваться
также вероятностью отказа Q(t)=1-
p(t)

P
Q

Рис.
19

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

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

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

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

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

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

t

Рис
20

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

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

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

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

Надежность — ремонтируемое изделие — Большая Энциклопедия Нефти и Газа, статья, страница 1

Cтраница 1

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

Надежность ремонтируемых изделий, а также насосов в целом оценивается аналогично; в частности, функция надежности — t ( j / для всего насоса может быть рассчитана указанным выше методом. При этом полезно использовать рекомендации, изложенные в справочнике / 16 /, касающиеся метода сбора и обработки статистических данных.
 [2]

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

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

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

Дополнительными характеристиками надежности ремонтируемых изделий являются долговечность и ремонтопригодность.
 [6]

Для оценки надежности ремонтируемых изделий рассматриваются потоки отказов и их характеристики, а также законы распределения, которые находят применения в теории надежности.
 [7]

Зависимость общей стоимости С от надежности Р.
 [8]

Для оценки показателей надежности ремонтируемых изделий проводят наблюдения за испытаниями или эксплуатацией N изделий.
 [9]

К количественным показателям надежности ремонтируемого изделия или машины относится также наработка на отказ Н и интенсивность отказов К.
 [10]

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

График изменения вероятности безотказной работы в зависимости от времени ( Т — время технического ресурса.
 [12]

Для опытного определения показателей надежности ремонтируемых изделий проводят наблюдения за испытаниями или эксплуатацией изделий в заданных условиях. При этом определяют Р следующие показатели надежности.
 [13]

График последовательного анализа с односторонней границей.
 [14]

В настоящем разделе излагается методика контроля уровня надежности дорогостоящих ремонтируемых изделий по методу последовательного анализа с односторонней границей для одного заданного уровня надежности.
 [15]

Страницы:  

   1

   2

Надежность продукта — вопрос перспективы? | Эндрю Хэтч | Блог SEEK

Опубликовано в

·

Чтение: 15 мин.

·

12 февраля 2019 г.

Вспомните время, когда вы купили дорогой товар в интернет-магазине. Вы добавляете товары в корзину, нажимаете кнопку «Оплатить», а затем — бум! Возникает уродливая ошибка страницы. В панике вы нажимаете кнопку «Назад», но на странице не отображается информация о том, были ли списаны средства или нет. Думаешь минуту, надеешься, что это была просто ошибка и снова нажимаешь «Оплатить». Теперь вы получаете другое сообщение об ошибке! Мысли сразу проносятся в голове:

  • Безопасен ли сайт?
  • Что делать, если данные моей кредитной карты плавают на каком-то иностранном сервере?
  • Моя личная информация была скомпрометирована?
  • С меня дважды списали деньги?
  • Я получу то, что хотел, или что-то еще?

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

Фото Кристиана Эрфурта на Unsplash

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

А теперь представьте, если вместо уродливых и запутанных страниц вы получите:

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

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

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

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

    Надежный продукт — это то, что обеспечивает стабильный и предсказуемый опыт при использовании или наблюдении. Если происходит сбой или непредвиденные проблемы, пользователь не остается с плохим опытом, таким как уродливая ошибка «Страница не найдена» или пустой экран с вращающимся автоматическим изображением. Он должен давать положительную обратную связь в случае сбоя  — например, обнадеживающее сообщение со ссылкой на вашу транзакцию, которую вы можете проверить позже, или обещание продолжить работу с помощью другого средства связи (например, SMS или электронной почты), как только все вернется на круги своя.

    Источник: CustomerExperienceInsight

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

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

    G-образный зажим, изготовленный моим дедом Альфредом Хэтчем где-то в 1950-х годах на фабрике в Мельбурне — он до сих пор отлично работает

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

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

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

    Но цифровой продукт, созданный такой компанией, как SEEK, не так прост, как G-образный зажим. Даже продукты, которые на первый взгляд кажутся тривиальными, на самом деле довольно сложны  — если учесть их проектирование, проектирование и тестирование. Кроме того, после того как они развернуты в производственной среде для использования Клиентами, на их производительность влияют колебания нагрузки, возлагаемой на них как клиентским, так и неклиентским трафиком. Кроме того, от них зависят и другие продукты и услуги SEEK. Другими словами, подумайте о G-Clamp, пытающемся зажать два объекта, которые могут трансформироваться в разные материалы, веса и даже формы по желанию. В то же время этими объектами одновременно пользуются от нескольких сотен до тысячи человек!

    Photo by Sheldon Nunes on Unsplash

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

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

    Отказоустойчивость обычно можно рассматривать как подмножество Надежности и определяется как:

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

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

    Photo by John Schnobrich on Unsplash

    Непрерывное развитие технологий, таких как облачные вычисления, означает, что в последнее время базовый уровень отказоустойчивости стало проще достигать «из коробки» (или, по крайней мере, легче настроить). То, что началось на уровне инфраструктуры с виртуальных серверов и программно-определяемых сетей 5–10 лет назад, все чаще становится доступным на уровне исполняемого кода (широко известное как бессерверная технология или технология «функция как услуга»), где вся вычислительная инфраструктура и среды выполнения управляются облачными поставщиками и оплачиваются как коммунальные услуги, такие как газ или электричество. Другими словами, отказоустойчивость ваших решений может быть сужена, чтобы больше сосредоточиться на вашем фактическом коде и на том, насколько хорошо вы можете настроить облачные платформы, которые они используют. Необязательно учитывать, насколько хорошо вы умеете размещать в стойках, прокладывать кабели и настраивать физическое оборудование.

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

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

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

    Разработчики тесно сотрудничают с нашими менеджерами по продукту в SEEK

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

    Совет. Не устанавливайте вслепую единый набор правил SLO для управления всем, а затем управляйте всем этим централизованным комитетом!⁴

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

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

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

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

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

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

    В ходе этих бесед мы сделали следующие выводы:

    1. Каждый может согласиться с тем, что неудача неизбежна, даже менеджеры по продукции, но мы абсолютно не хотим, чтобы клиент ощущал простои или деградацию, когда они происходят, и негативный опыт использования наших продуктов
    2. Замедленные ответы и случайные пропадания так же плохи, как и полные сбои, если не больше, так как их нелегко обнаружить, а радиус взрыва того, кто затронут, может быть трудно определить.
    3. «Что-то пошло не так, нажмите кнопку «Назад» и повторите попытку!»
    4. Не знать, что что-то выходит из строя, — это плохо. Нам не нравится концепция «системы мониторинга клиентов», т. е. когда клиент узнает, что что-то сломалось, прежде чем мы это сделаем, и позвонит в службу поддержки⁷
    5. Менеджеры по продуктам не являются экспертами в области ИТ, поэтому мы полагаемся на инженеров, которые обеспечивают правильный мониторинг и метрики, чтобы сообщить нам, когда наши клиенты подвергаются негативному воздействию
    6. Хорошее управление инцидентами и процесс проверки после инцидента — отличная идея, мы должны делать это все время, сопоставлять данные и использовать их для принятия решений
    7. Держаться за устаревшие системы, которые идти на компромисс или идти на компромиссы при создании новых продуктов — отстой. Если нам нужно от чего-то избавиться, скажите нам, но сделайте это на языке, который мы можем понять, в соответствии с процессами, которым мы можем следовать

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

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

    Итак, как мы можем эффективно измерить надежность нашей продукции, зная эти руководящие принципы?

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

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

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

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

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

    Photo by Jeremy Bishop on Unsplash

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

    Но поскольку мы говорим о создании программных продуктов, а не о полетах самолетов, вот несколько проверенных программных продуктов. Опережающие индикаторы:

    • Время выполнения — время, которое требуется от идеи до поставки или от идентификации проблемы до решения. Чем короче, тем лучше
    • Частота развертывания — частота развертывания программного обеспечения. Регулярные развертывания, независимо от изменений, гарантируют, что неотслеживаемые изменения не будут увеличиваться с течением времени.
    • Среднее время восстановления (MTTR) — время, необходимое для восстановления системы после сбоя. Чем короче, тем лучше ПРИМЕЧАНИЕ: речь идет не о количестве сбоев , а о том, насколько быстро вы их устраняете
    • Процент неудачных изменений — частота изменений, вызывающих сбой, в процентах от скорости развертывания. Чем ниже, тем лучше — высокие значения указывают на то, что показатели качества нуждаются в улучшении

    Все это проверенные показатели для повышения скорости и качества¹¹

    Вы также можете найти их полезными:

    • Незапланированная работа по сравнению с запланированной — Незапланированная работа является тихим убийцей производительности, она замедляет скорость изменений и отвлекает внимание людей от важной работы¹²
    • Выплата задолженности по техническому долгу — вы движетесь к техническому банкротству или добиваетесь поддающихся количественному измерению улучшений устойчивости?
    • Хаос-инженерия¹³ — Практика упреждающего сбоя в работающих системах для измерения отказоустойчивости

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

    Ожидайте неожиданного — Источник

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

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

    Распознавание опасностей и успешное управление операциями системы, чтобы оставаться в допустимых пределах производительности, требует тесного контакта с отказом. Более устойчивая производительность системы, скорее всего, будет достигнута в системах, в которых операторы могут различить «край конверта».¹⁶

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

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

    Начните с:

    1. Установите руководящие принципы, основанные на пути клиента и опыте (полученном благодаря взаимодействию с вашими продуктовыми командами)
    2. Используйте опережающие индикаторы для управления усилиями по проектированию устойчивости
    3. Установите SLO в отдельных продуктовых командах
    4. обучение непрерывному совершенствованию циклов поставки программного обеспечения.

    Вот простое, но вдохновляющее заявление о видении, которое поможет вам начать — удачи:

    «<вставьте здесь название вашей компании> клиенты не будут сталкиваться с простоями или снижением производительности наших сайтов и услуг при использовании наших Продуктов»

    [1] D. Woods : Resilience is a Verb

    [2] M.Kagan : INSPIRED: Как создавать технические продукты, которые нравятся клиентам 9000 3

    [3] B. Meyers : Проектирование надежности объекта

    [4] S. Dekker : Анархист по безопасности Опираясь на человеческий опыт и инновации, снижая бюрократию и соответствие требованиям

    [5] Участие полевых экспертов : Системное мышление для обеспечения безопасности

    [6] С. Деккер : Почему все идет хорошо?

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

    [8] Индикаторы опережения и отставания

    [9] T Mathis: Ошибки в басне о безопасности

    [10] D. Heuther: Индикаторы опережения и отставания

    [11] N. Forsgren, J Humble: Accelerate: The Science of Lean Software and DevOps

    [12] Э. Голдратт. Цель. Процесс непрерывного улучшения

    [13] Принципы Chaos Engineering

    [14] Дж. Оллспоу: Темный долг — выдержка из http://stella.report

    [15] К. Перроу — Теория обычных аварий

    [16] Р. Кук: Как сложные системы терпят неудачу

    [17] Благодарственный запрос

    Надежность продукта: определение, измерение и улучшение

    РЕКЛАМА:

    Прочитав эту статью, вы узнаете о:- 1. Определение надежности 2. Измерение надежности 3. Улучшение.

    Определение надежности:

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

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

    Измерение надежности :

    ОБЪЯВЛЕНИЯ:

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

    Для повышения надежности продукции; собираются данные/информация, связанные с отказами в течение заданного периода времени; анализируются и принимаются корректирующие меры. Измерение надежности зависит от типа продукции.

    Например:

    (i) Некоторые изделия функционируют только один раз, например предохранитель в электрической или электронной цепи.

    ОБЪЯВЛЕНИЯ:

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

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

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

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

    ОБЪЯВЛЕНИЯ:

    С помощью таблиц легко ответить на следующие вопросы:

    (i) Какие изменения следует внести в конструкцию изделия для повышения его надежности,

    (ii) Какой предмет следует проверять и когда?

    (iii) Какой компонент или машина должны быть проверены и когда?

    ОБЪЯВЛЕНИЯ:

    (iv) Насколько конкретное инвестиционное предложение окажется финансово жизнеспособным?

    (v) Насколько надежен продукт, машина, процесс или компонент и как можно повысить его надежность?

    (vi) Каким образом следует максимально эксплуатировать завод, машины или оборудование и т.