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

Одной из основных проблем при передаче практик отказоустойчивости сообществу практиков является отсутствие общего представления о том, что такое отказоустойчивость и как она может помочь в разработке надежных систем. Одним из шагов к тому, чтобы сделать отказоустойчивость более понятной, является предоставление концептуальной основы. Цель этого документа состоит в том, чтобы предложить такую структуру. Этот документ начинается с обсуждения того, что представляет собой система. Оттуда разрабатывается стандартный словарь системной отказоустойчивости, где возможно используется общепринятая терминология (например, 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 отказов в час. Проблема с установлением требований надежности таким образом заключается в том, что трудно понять, когда они были достигнуты. Батлер¹ указал, что стандартные статистические методы не могут быть использованы для демонстрации такой надежности ни со стандартным, ни с отказоустойчивым программным обеспечением. Также ясно, что невозможно добиться уверенности в том, что система соответствует такой цели надежности, путем выборочного тестирования. Тем не менее цели надежности часто выражаются таким образом.

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

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

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

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

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

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

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