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

Одной из основных проблем при передаче практик отказоустойчивости сообществу практиков является отсутствие общего представления о том, что такое отказоустойчивость и как она может помочь в разработке надежных систем. Одним из шагов к тому, чтобы сделать отказоустойчивость более понятной, является предоставление концептуальной основы. Цель этого документа состоит в том, чтобы предложить такую структуру. Этот документ начинается с обсуждения того, что представляет собой система. Оттуда разрабатывается стандартный словарь системной отказоустойчивости, где возможно используется общепринятая терминология (например, Laprie 92). Словарные термины проиллюстрированы примерами компьютерных систем и альтернативным набором примеров из совершенно другого типа системы, моста. Далее в документе обсуждается, как системы выходят из строя, включая классы неисправностей. Затем следует краткое изложение существующих подходов к реализации отказоустойчивости. В заключительном разделе вновь рассматриваются ключевые концепции статьи и предлагаются некоторые правила проектирования отказоустойчивых систем.

Что такое система?

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

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

2.1 Надежные системы

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

Хотя эти системные атрибуты можно рассматривать изолированно, на самом деле они взаимозависимы. Например, ненадежная система также недоступна (по крайней мере, когда она работает неправильно). Защищенная система, которая не допускает санкционированного доступа, также недоступна. Ненадежная система управления ядерными реакторами, вероятно, также небезопасна.

2.2 Подходы к обеспечению надежности

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

2.2.1 Предотвращение ошибок

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

2.2.2 Устранение неисправности

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

2.2.3 Отказоустойчивость

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

2.2.4 Уклонение от ошибок

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

2.3 Характеристики надежности

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

2.3.1 Количественные цели

Количественная цель по надежности обычно выражается как максимально допустимая частота отказов. Например, для бортовых компьютерных систем гражданских самолётов типичная целевая величина — менее 10^-9 отказов в час. Проблема такого подхода в том, что крайне сложно достоверно проверить достижение этого уровня. Как указывает Батлер (Butler, 1991), стандартные статистические методы не позволяют доказать подобную надёжность ни для обычного, ни для отказоустойчивого ПО. Очевидно и то, что случайное тестирование не даёт возможности с достаточной уверенностью подтвердить соответствие системы столь жёсткой цели. Тем не менее, требования в таком виде встречаются достаточно часто.

2.3.2 Качественные цели

Альтернативой является задание характеристик надежности в качественной форме. Типичные варианты:

• Отказобезопасность (fail-safe) — система при заданном числе отказов переходит в безопасный режим. Пример: железнодорожная сигнализация проектируется так, чтобы при сбое все поезда останавливались.
• Работоспособность при отказах (fail-operational) — при заданном числе отказов система сохраняет хотя бы часть функциональности.
• Отсутствие единственной точки отказа — отказ любого одного компонента не должен приводить к отказу системы. Как правило, предусматривается возможность замены или ремонта отказавшего элемента до возникновения следующего сбоя.
• Согласованность — вся выдаваемая системой информация эквивалентна информации, которую выдала бы исправная система.

¹Речь про Рики В. Батлера — старшего инженера-исследователя Исследовательского центра НАСА в Лэнгли. И его статью "Невозможность экспериментальной количественной оценки надежности жизненно важного программного обеспечения"