Главная | Обратная связь | Поможем написать вашу работу!

Нефункциональные требования безотказности

Во многих системных спецификациях требования безотказности тщательно не выписаны. Часто требования безотказности субъективны и неизмеряемы. Например, утверждение "программное обеспечение должно быть безотказным при нормальных условиях эксплуатации" бессмысленно. Квазиколичественные утверждения "программное обеспечение должно иметь не более N сбоев на 1000 строк программного кода" бесполезны. Невозможно измерить число сбоев на 1000 строк кода, так как нельзя сказать, когда эти сбои будут обнаружены. Эти утверждения ничего не говорят о поведении системы в процессе работы.

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

Таблица 17.2. Классификация отказов

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

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

Приведем последовательность шагов по определению требований безотказности.

1. Для каждой подсистемы необходимо определить возможные системные отказы и проанализировать их последствия.

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

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

4. Формулируются функциональные требования безотказности таким образом, чтобы уменьшить вероятность критических отказов.

В качестве примера специфицирования требований безотказности рассмотрим требования к безотказности банкоматов, объединенных в сеть. Примем во внимание, что каждый банкомат используется приблизительно 300 раз в день. Срок службы оборудования – восемь лет, программное обеспечение обычно модифицируется каждые два года. Следовательно, до выпуска новой версии программного обеспечения, каждый банкомат обработает приблизительно 200 тыс. транзакций. Банк имеет в сети 1000 банкоматов. Это означает, что центральная база данных обрабатывает 300 тыс. транзакций в день (или 100 млн. ежегодно).

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

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

Таблица 17.3. Требования безотказности для сети банкоматов

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

В идеале сбои, разрушающие базу данных, никогда не должны возникать за весь срок службы программного обеспечения. Поэтому требование безотказности в этом случае такое: вероятность разрушающего отказа должна быть меньше 1 отказа на 200 млн. транзакций. Тогда за весь срок службы одной версии ПО не должно произойти отказов, приводящих к разрушению базы данных. Но подобное требование безотказности фактически невозможно проверить. Пусть каждая транзакция занимает 1 секунду машинного времени и для сети банкоматов построен имитатор. Время моделирования транзакций, проходящих через сеть банкоматов за один день, равно 300 тыс. секунд. Это приблизительно 3,5 дня. Ясно, что это время можно сократить, уменьшая период обработки транзакций и используя несколько имитаторов, но в этом случае очень трудно проверить, насколько имитируемая система удовлетворяет требованиям безотказности.

Также невозможно проверить качественные требования, определяющие очень высокий уровень безотказности. Например, если система является критической по обеспечению безопасности, то за весь срок ее службы не должно произойти ни одного сбоя. Предположим, что должны быть установлены 1000 копий системы и что система "выполняется" 1000 раз в секунду. Срок службы системы составляет 10 лет. Следовательно, общее прогнозируемое число "выполнений" системы приблизительно равно 3 * 10¹⁴. Нет смысла определять частоту отказа как один сбой на 10¹⁵ "выполнений" (что обеспечит безопасность системы), поскольку для обоснования такого уровня безотказности невозможно протестировать систему.

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

Для рассматриваемой системы можно определить два типа отказов.

1. Случайные отказы, которые пользователь может устранить самостоятельно (например, перезапустив или настроив систему). Допустимая вероятность отказа не должна превышать 0,002. В этом случае на 500 запросов к системе может произойти один отказ. Это означает, что возможен сбой приблизительно один раз в 3,5 дня.

2. Перманентные отказы, которые требуют восстановления системы разработчиком. Вероятность такого типа отказа должна быть намного ниже – приблизительно один раз в год. В этом случае вероятность отказа должна быть не больше чем 0,00002.

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

⇐ Предыдущая 115 116 117 118 119120121 122 123 124 Следующая ⇒