Яка різниця між стійкістю та відмовою?


12

Системи / програми / розподілені алгоритми / ... часто описуються присудком надійним або стійким до відмов .

Яка різниця?


Деталі:

Коли я переглядаю google за + robust + "fault-tolerant", я отримую лише два звернення, обидва непридатні.

Коли я переглядаю терміни, я знаходжу багато паперів, які мають у своєму заголовку обидва терміни. На жаль, вони не чітко визначають терміни :( Але оскільки вони використовують обидва терміни, схоже, що жодне з них не означає.



Так, це було однією з перших речей, які я прочитав, щоб з’ясувати їх значення. На жаль, обидва описують те саме на абстрактному рівні, не посилаючись на інше. Ось чому я прошу тут.
DaveFar

Відповіді:


33

Обидва описують послідовність поведінки програми, але "надійність" описує відповідь програми на її вклад , тоді як "стійкість до відмов" описує реакцію програми на її оточення .

Додаток надійний, коли він може працювати послідовно із суперечливими даними. Наприклад: додаток карт надійний, коли він може аналізувати адреси у різних форматах з різними написаннями помилок та повертати корисне місцеположення. Музичний плеєр надійний, коли він може продовжувати розшифровувати MP3 після зіткнення з неправильним кадром. Редактор зображень є надійним, коли він може змінювати зображення за допомогою вбудованих метаданих EXIF, які він може не розпізнавати, особливо якщо він може вносити зміни до зображення, не руйнуючи дані EXIF.

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

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

Один не обов'язково веде до іншого. Мобільний додаток для розпізнавання голосу може бути дуже надійним, забезпечуючи незграбну здатність послідовно розпізнавати мовлення в різних регіональних акцентах з величезною кількістю фонового шуму. Але якщо без швидкого зв’язку стільникових даних це марно, воно не дуже вірогідне. Аналогічно, додаток для веб-публікацій може бути надзвичайно стійким до помилок, із безліччю надмірностей на кожному рівні, здатним втрачати цілі центри обробки даних, не виходячи з ладу, але якщо він скидає таблицю користувачів і впаде в перший раз, коли хтось реєструється з апострофом на своє прізвище , це зовсім не надійно.

Якщо ви шукаєте наукову літературу, яка допоможе описати відмінність, ви можете шукати в конкретних областях, які використовують програмне забезпечення, а не широко програмне забезпечення взагалі. Дослідження розповсюджених програм можуть бути благодатною основою для критеріїв відмовостійкості, і Google опублікувала деякі свої дослідження, які можуть бути актуальними. Дослідження моделювання даних, ймовірно, стосуються питань надійності, оскільки вчених особливо цікавлять властивості стійкості, які дають відтворювані результати. Ви, ймовірно, можете знайти документи, що описують статистичні програми, які можуть бути корисними, наприклад, в кліматичному моделюванні, моделюванні РЧ-розповсюдження або в послідовності геному. Ви також знайдете інженерів, які обговорюють "надійний дизайн" у таких речах, як системи управління.

Біла книга файлової системи Google описує їх підхід до проблем з відмовою, що, як правило, передбачає припущення, що збої компонентів є звичайними, і програма повинна адаптуватись до них:

Цей проект для класу в Rutgers підтримує орієнтоване на "компонент-відмова" визначення "відмовостійкості":

Існує безліч паперів про "надійне моделювання XYZ", залежно від галузі, яку ви досліджуєте. Більшість описує свої критерії "надійного" в рефераті, і ви знайдете, що це стосується того, як модель поводиться з інформацією

Цей короткий опис вченого клімату NASA описує надійність як критерій оцінки кліматичних моделей:

У цьому документі дослідник MIT вивчає програми бездротового протоколу, домен, в якому відхилення та стійкість перекриваються, але автори використовують "надійний" для опису програм, протоколів та алгоритмів, тоді як вони використовують "відмовостійкість" стосовно посилання на топологію та компоненти:

  • http://people.csail.mit.edu/grishac/papers/allerton.pdf ("Коротше кажучи, для цього використання потрібні надійні програми, які завжди працюють правильно, навіть у непередбачуваних умовах.")

0

Мені дуже подобається відповідь @ johnnyb і схвалюю її за чіткі визначення. Але пропрацювавши в цій галузі кілька десятиліть, я визнаю ще один (набагато менш формальний і точний) спосіб, який часто використовують ці терміни:

Як неформальні вказівки уздовж континууму від "ненадійного" до "абсолютно надійного".

Не існує жодної системи, програми чи послуги, які могли б гарантувати, що вона завжди і назавжди буде працювати ("постійно доступний" або "постійно доступний"). "Відмовостійкість" давно стала принципом "ми зробили все можливе по-людськи за допомогою сучасних технологій, щоб переконатися, що ця річ працює належним чином".

Слова на кшталт "міцний", "загартований" та "високодоступний" використовуються як більш м'які віхи до цієї мети безперервної роботи. Вони відображають зростаючий рівень зусиль, інвестицій та впевненості.

Оскільки ці терміни використовуються неофіційно, не існує цілком канонічного впорядкування. "Високодоступний", як правило, є сильним претензією, лише за "вини стійкі до помилок" або "відмовостійкість". Але чи «загартоване» краще, ніж «міцне»? Або навпаки? Це залежить від контексту. Вони також часто використовуються як претензії щодо маркетингу товарів, з усією вихвалянням та навмисною неточністю.

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

@johnnyb також торкається критичного розрізнення: різниця між статусом "вгору / вниз" платформи (доступність) з одного боку, і алгоритмом, додатком або атрибутами служби з іншого.

Я кажу "атрибути", тому що їх багато: продуктивність, правильність та незмінність - лише кілька ключових. Чи є система доступною та коректною, якщо вона працює лише на 10% від номінальної продуктивності? Не за словами власників бізнесу, якщо це найнапруженіший сезон! Немає великої чесноти в системі, яка справді ніколи не знижується, але це також дає неправильні відповіді велику частину часу. Нарешті, чи працює система аналітики даних "правильно", якщо варіація введення 0,2% дає відповідь на 3400%? Можливо ... але це здасться багатьом досить примхливою і незадовільною моделлю. Я не буду проходити через розширений список атрибутів, але цілісність даних, безпека даних, конфіденційність даних та інші питання правильності та безпеки - це спільні проблеми. (Якщо ви дуже велика організація чи державне агентство, ви все більше переживаєте за збереження цих атрибутів не лише протягом декількох років або циклів продукції, а протягом десятиліть чи, можливо, навіть століть. Досі не існує перевірених архітектур, процесів чи підходів до цього.)

Ці можливі розбіжності між "вгору і запуском" і "робити те, що ми хочемо" - і як конкретизувати, вимірювати та запобігати подібним відхиленням - давно стали викликом, навіть коли надмірність, загартовування та інші кроки до вини - толерантність були прийняті. І в неофіційному використанні "біг" і різні форми "бігу так, як я цього хочу" поєднуються, без усіх чітких відмінностей, які хотіли б.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.