Системы / программы / распределенные алгоритмы / ... часто описываются с помощью предиката, устойчивого или отказоустойчивого .
В чем разница?
Детали:
Когда я гуглю на + надежный + "отказоустойчивый", я получаю только два попадания, оба бесполезные.
Когда я прибегаю к поиску терминов, я нахожу много статей, в названии которых есть оба термина. К сожалению, они точно не определяют термины :( Но так как они используют оба термина, кажется, что ни один не подразумевает другого.
Ответы:
Оба описывают согласованность поведения приложения, но «надежность» описывает ответ приложения на его входные данные , а «отказоустойчивость» описывает ответ приложения на его среду .
Приложение является надежным, когда оно может работать согласованно с противоречивыми данными. Например: приложение карт является надежным, когда оно может анализировать адреса в различных форматах с различными ошибками и возвращать полезное местоположение. Музыкальный проигрыватель надежен, когда он может продолжить декодирование MP3 после обнаружения искаженного кадра. Редактор изображений является надежным, когда он может изменять изображение со встроенными метаданными EXIF, которые он может не распознать, особенно если он может вносить изменения в изображение, не разрушая данные EXIF.
Приложение отказоустойчиво, когда оно может работать согласованно в несовместимой среде. Приложение базы данных отказоустойчиво, когда оно может получить доступ к альтернативному фрагменту, когда основной недоступен. Веб-приложение отказоустойчиво, когда оно может продолжать обрабатывать запросы из кэша, даже если хост API недоступен. Подсистема хранения является отказоустойчивой, когда она может возвращать результаты, рассчитанные по четности, когда элемент диска находится в автономном режиме.
В обоих случаях ожидается, что приложение останется стабильным, будет вести себя равномерно, сохранять целостность данных и предоставлять полезные результаты даже в случае возникновения ошибки. Но при оценке надежности вы можете найти критерии, связанные с данными, а при оценке отказоустойчивости вы найдете критерии, связанные с временем безотказной работы.
Одно не обязательно ведет к другому. Мобильное приложение для распознавания голоса может быть очень надежным, предоставляя сверхъестественную способность распознавать речь последовательно в различных региональных акцентах с огромным количеством фонового шума. Но если это бесполезно без быстрого сотового соединения для передачи данных, это не очень отказоустойчиво. Точно так же приложение веб-публикации может быть чрезвычайно отказоустойчивым, с множеством избыточностей на каждом уровне, способным без потерь потерять целые центры обработки данных, но если оно удаляет пользовательскую таблицу и аварийно завершает работу, когда кто-то регистрируется с апострофом в своей фамилии не совсем крепкий
Если вы ищете научную литературу, которая поможет описать это различие, вы можете обратиться к конкретным областям, в которых используется программное обеспечение, а не программное обеспечение в целом. Исследования распределенных приложений могут быть плодотворной почвой для критериев отказоустойчивости, и Google опубликовал некоторые из своих исследований, которые могут оказаться актуальными. Исследования моделирования данных, вероятно, затрагивают вопросы надежности, поскольку ученые особенно заинтересованы в свойствах надежности, которые дают воспроизводимые результаты. Вы, вероятно, можете найти статьи, описывающие статистические приложения, которые могут быть полезны, например, в моделировании климата, моделировании распространения радиочастот или секвенировании генома. Вы также найдете инженеров, обсуждающих «надежный дизайн» в таких вещах, как системы управления.
В техническом описании файловой системы Google описывается их подход к проблемам отказоустойчивости, который обычно предполагает допущения о том, что сбои компонентов являются обычными, и поэтому приложение должно адаптироваться к ним:
Этот проект для класса в Rutgers поддерживает ориентированное на «компонент-сбой» определение «отказоустойчивости»:
Есть множество статей по «робастному моделированию XYZ», в зависимости от области, которую вы исследуете. Большинство из них опишут свои критерии «робастности» в аннотации, и вы обнаружите, что все это связано с тем, как модель работает с входными данными.
Это краткое изложение климатолога НАСА описывает устойчивость как критерий для оценки климатических моделей:
В этом документе от исследователя MIT рассматриваются приложения беспроводного протокола, область, в которой отказоустойчивость и надежность перекрываются, но авторы используют «надежный» для описания приложений, протоколов и алгоритмов, в то время как они используют «отказоустойчивость» в отношении топологии и компоненты:
источник
Мне очень нравится ответ @ johnnyb и одобряю его четкие определения. Но, проработав в этой области несколько десятилетий, я узнаю другой (гораздо менее формальный и точный) способ, которым эти термины часто используются:
Как неофициальные точки вдоль континуума от «ненадежного» до «совершенно надежного».
Не существует системы, приложения или службы, которые могли бы гарантировать ее постоянную и постоянную работу («постоянно доступны» или «постоянно доступны»). «Отказоустойчивость» давно заменяет «мы сделали все возможное, используя современные технологии, чтобы убедиться, что эта штука продолжает работать правильно».
Такие слова, как «надежный», «закаленный» и «высокодоступный», используются в качестве более мягких вех в достижении этой цели непрерывной работы. Они отражают растущий уровень усилий, инвестиций и уверенности.
Поскольку эти термины используются неофициально, не существует полностью канонического порядка. «Высокая доступность» обычно является сильным требованием, просто под «отказоустойчивость» или «отказоустойчивость». Но лучше ли "закаленные", чем "крепкие"? Или наоборот? Это зависит от контекста. Они также часто используются в качестве маркетинговых претензий, со всеми вытекающими отсюда похвальными и преднамеренными неточностями.
Обычно организации, работающие над достижением этих целей, имеют собственную согласованную последовательность действий, обычно, по крайней мере, примерно связанную с целями / результатами проекта и внешними показателями, такими как «три девятки» или «шесть девяток».
@johnnyb также затрагивает критическое различие: различие между состоянием вверх / вниз платформы (доступность), с одной стороны, и атрибутами алгоритма, приложения или службы - с другой.
Я говорю «атрибуты», потому что их много: производительность, корректность и невозмутимость - вот лишь некоторые ключевые. Является ли система разумно доступной и правильной, если она работает всего на 10% от номинальной производительности? Не по словам владельцев бизнеса, если это напряженный сезон! В системе, которая действительно никогда не выйдет из строя, нет большого достоинства, но она также дает неверные ответы большую часть времени. Наконец, работает ли система анализа данных «правильно», если отклонение на входе в 0,2% дает 3400% другой ответ? Возможно ... но многим это покажется довольно капризной и неудовлетворительной моделью. Я не буду проходить через расширенный список атрибутов, но общие проблемы - это целостность данных, безопасность данных, конфиденциальность данных и другие вопросы правильности и безопасности. (Если вы очень большая организация или государственное учреждение, Вы все больше беспокоитесь о сохранении этих атрибутов не в течение нескольких лет или циклов производства, а в течение десятилетий или даже столетий. Пока еще нет проверенных архитектур, процессов или подходов для достижения этой цели.)
Эти возможные различия между «включенным и работающим» и «делающим, что мы хотим» - и тем, как определять, измерять и предотвращать такие отклонения - долгое время были проблемой, даже после того, как избыточность, усиление и другие шаги к отказу терпимость были приняты. И в неформальном использовании «бег» и различные формы «бега, как я хочу» объединяются, без каких-либо четких различий, которые хотелось бы.
источник