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

Системы с повышенными
требованиями к
надежности: основные
понятия, спецификации
Функциональная надежность

Величина, на которую
пользователи
критической системы
доверяют ей
Концепция надежности

Для критических систем надежность является
самым важным свойством системы

Надежность системы отражает степень доверия
пользователя к системе.

Применимость системы и ее надежность – не одно
и то же. Система не обязана быть удобной и
практичной.
Параметры надежности
Надежность
Работоспособность
Безотказность
Безопасность
Защищенность
Удобство сопровождения



Атрибут системы, соответствующий простоте
восстановления системы после отказа или
изменения системы для добавления новых свойств
Очень важно для критических систем, так как
отказы системы случаются часто из-за проблем
сопровождения
Удобство сопровождения отличается от других
параметров надежности тем, что это статический
атрибут системы, а не динамический
Способность к выживанию

Способность системы к продолжению
предоставления своих услуг пользователям при
случайных или намеренных атаках на систему

Способность к выживанию включает в себя понятие –
способность к восстановлению системой своих
функций – возможность продолжать работать и в том
случае сбоя компонентов системы
Стоимость и надежность
Coost
Dependability
Loo
ww
Mediiumm
u
Hiigh
Very
hiig h
Ultrahiig h
Стоимость надежности

Стоимость обеспечения надежности имеет
тенденцию к возрастанию экспоненциально по
отношению к уровню надежности, который
необходимо достичь


Использование более дорогих средств разработки и
оборудования, которые необходимы для достижения
более высокого уровня надежности
Увеличивающийся объем тестирования и валидации
системы, которые необходимы для убеждения клиента в
том, что нужный уровень надежности системы достигнут
Надежность vs
производительность





Не заслуживающие доверия системы могут быть
отвергнуты пользователем (Не заслуживает доверия =>
Непригодна)
Стоимость отказа системы может быть очень высока
Очень трудно отладить систему так, чтобы она стала
более надежной («модификация надежности», к
сожалению, невозможна)
Плохую производительность можно компенсировать
(надежность - нельзя)
Ненадежные системы могут привести к потере важной
информации
Экономика надежности



Из-за очень высокой стоимости достижения
определенного уровня надежности может быть
более экономически эффективно принять к
использованию ненадежную систему и оплачивать
стоимость отказов
Репутация продукта, которому не доверяют, может
подорвать будущий бизнес.
Зависит от типа системы, особенно для бизнессистем, в которых уровень системы должен быть
адекватен представлениям
Работоспособность и
безотказность



Безотказность
 Способность безотказной работы системы в
течение определенного времени в данной среде
для достижения данных задач
Работоспособность
 Способность системы в определенной точке
времени быть работоспособной и
предоставляющей запрошенные услуги
Оба этих атрибута могут быть рассчитаны численно
Работоспособность и
безотказность (2)

Иногда возможно соотнести работоспособность
системы и безотказность системы



Обычно если система не работоспособна, то она не
предоставляет запрашиваемые специфические сервисы
Однако, возможно создать систему с низкой
безотказностью, которая будет работоспособной.
Системные сбои могут быть исправлены очень
быстро и не повреждать данные, поэтому низкая
безотказность может не быть проблемой
Работоспособность учитывает время ремонта
Терминология безотказности
Отказы и сбои


Отказы обычно являются результатом системных
ошибок, которые являются следствием сбоя в
системе
Тем не менее, сбои необязательно ведут к
системным ошибкам


Сбойное состояние системы может измениться и
«выровняться» до появления ошибки
Ошибки необязательно приводят к отказам системы


Ошибки могут быть исправлены встроенным
определителем ошибок
Повторное возникновение сбоев может быть
предотвращено встроенными средствами защиты
Представление об
отказоустойчивости

Формальное определение отказоустойчивости не всегда отражает
пользовательские представления об отказоустойчивости системы

Представления о среде, в которой может использоваться система,
могут быть неверными
 Использование системы в офисной обстановке может быть
совершенно иным, чем использование той же системы в полевых
условиях

Последствия системных отказов влияют на понимание
отказоустойчивости


Отказывающие увлажнители ветровых стекол могут оказаться
бесполезными в сухом климате
Отказы, которые имеют серьезные последствия (такие, как
поломка двигателя в машине), значат для пользователя больше,
чем отказы, просто причиняющие неудобства
Достижение надежности



Предотвращение сбоев
 Средства разработки, которые снижают возможность
ошибок или выявляют ошибки до того, как они
приведут к отказу системы
Определение отказов и устранение их
 Verification & validation увеличивают возможность
обнаружения и исправления ошибок до ввода
системы в эксплуатацию
Обеспечение отказоустойчивости
 Технологии, которые позволяют убедиться в том, что
сбои системы не приводят к ошибкам и/или ошибки
системы не приводят к сбоям системы
Моделирование
отказоустойчивости



Вы можете смоделировать систему как карту ввода-вывода,
для которой отдельные входные данные служат результатом
ошибочных выходных данных
Отказоустойчивость системы основывается на возможности
того, что отдельные входные данные являются частью набора
других входных данных, ведущих к ошибочным выходным
данным
Разные люди используют систему различными способами, так
что эта возможность не является статическим атрибутом
системы, но зависит от окружения системы
Карта ввода-вывода
Представление
отказоустойчивости
Совершенствование
отказоустойчивости



Исправление X% отказов в системе не обязательно
исправляет отказоустойчивость системы на X%.
Исследования IBM показали, что 60% исправленных
дефектов системы приводят лишь к 3% увеличения
отказоустойчивости
Дефекты программы могут быть в редко используемых
разделах кода так, что они никогда не будут получены при
обычной работе. Исправление таких дефектов никак не
отразится на отказоустойчивости системы
Программа с известными заранее отказами может
рассматриваться, как достаточно надежная для ее
пользователей.
Безопасность



Безопасность – это такое свойство системы, которое
отражает способность системы работать, нормально или
ненормально, без возможности причинить вред или смерть
людям и без повреждений окружающей среды
Особенно важно учитывать безопасность системы при том,
что все больше и больше устройств включаются в системы
контроля, основанные на ПО
Требования безопасности – это эксклюзивные требования,
так как они исключают нежелательные ситуации чаще, чем
специфические сервисы системы
Критическая безопасность

Первичные критически-безопасные системы
–

Встроенные системы ПО, отказ которых
может вызывать отказ связанного с ним
оборудования и непосредственно
воздействовать на людей.
Вторичные критически-безопасные системы
–
Системы, чьи отказы приводят к отказам
других систем, что может привести к
воздействию на людей (база данных
лекарств)
Безопасность и
отказоустойчивость




Безопасность и отказоустойчивость связаны, но
отличны друг от друга
В общих чертах, безопасность и
отказоустойчивость – необходимое, но не
достаточное условие для защиты системы
Отказоустойчивость связана с соответствием
имеющейся спецификации и предоставление услуг
Безопасность связана с возможностью системы не
причинять вреда не зависимо от того,
соответствует она спецификации или нет.
Небезопасные
отказоустойчивые системы



Ошибки спецификации
 Если спецификация неверна, то система может
вести себя, как предполагалось, но все равно
привести к инцидентам
Отказы оборудования могут генерировать ложные
входные данные
 Это сложно отразить в спецификации
Контекстно-зависимые команды могут быть
неправильно поняты в определенное время
 Часто результат операторской ошибки
Терминология безопасности
Достижение безопасности



Предотвращение несчастного случая
 Система создана так, что некоторые категории
несчастных случаев просто не могут произойти
Обнаружение и исправление повреждения
 Система сконструирована так, что сбои
обнаруживаются и исправляются до того, как они
могли бы повлечь за собой несчастный случай
Ограничение повреждений
 Система включает в себя такие свойства
безопасности, которые уменьшают повреждения,
которые могут быть получены в результате несчастных
случаев
Accidents


Выходы из строя в комплексных системах редко имеют
единичную причину возникновения, так как эти системы
спроектированы быть надежными до первой точки отказа
 Конструирование системы так, чтобы первая точка отказа
не приводила к выходу из строя – это фундаментальный
принцип построения безопасных систем.
Как правило, выход из строя является результатом комбинации
случаев неправильного функционирования
Защищенность



Защищенность системы – это такое системное
свойство, которое отражает способность системы
защитить себя от от случайных или плановых внешних
атак
Защищенность становится особенно важной для
систем, работающих в сети, так как к ним возможен
удаленный доступ
Защищенность – это обязательное свойство для
достижения отказоустойчивости, работоспособности и
безопасности системы
Фундаментальные
положения защищенности


Если система является сетевой и не является
защищенной, то положения о ее
отказоустойчивости и ее безопасности
недостоверны
Эти положения зависят от выполняющейся
системы и разработанной системы, которая
является той же самой системой. Однако,
вторжение может изменить и систему и/или данные
системы
Терминология
защищенности
Повреждения при
отсутствии защищенности



Отказ служб
 Система приводится в состояние, когда обычные сервисы
недоступны или когда результат выполнения значительно
деградировал
Повреждение программ или данных
 Программы или данные могут быть изменены
неавторизованным путем
Потеря конфиденциальной информации
 Информация, используемая в системе, становится
доступной людям, не имеющим права ее читать или
использовать
Гарантия защищенности



Предотвращение отказов
 Система создана так, что отсутствует возможность отказа.
Например, отсутствие соединения со внешней сетью
исключает атаки извне
Выявление атак и устранение опасности
 Система разработана так, что атаки обнаруживаются и
нейтрализуются до того, как они привели к потере
работоспособности системы. Например, антивирусная
программа находит и удаляет вирусы до того, как они заразят
систему
Ограничение воздействия
 Система сконструирована так, что последствия успешной
атаки минимальны. Например, политика резервного
копирования сохраняет данные от повреждения
Спецификация надежной
системы

Процессы и средства создания
спецификации для безопасности,
защищенности,
работоспособности и
безотказности системы
Функциональные и
нефункциональные требования

Функциональные
требования
могут
быть
сформулированы для определения проверки
ошибок и возможностей восстановления, которые
обеспечивают защиту от отказов системы.

Нефункциональные требования могут быть
сформулированы для определения необходимых
отказоустойчивости
и
работоспособности
системы.
Спецификация отказоустойчивости
системы

Отказоустойчивость оборудования


Отказоустойчивость ПО


Какова возможность отказа компонентов аппаратуры, и как
долго будет производиться ремонт компонентов?
Какова возможность того, что ПО будет причиной неверных
выходных результатов? Отказы ПО отличаются от отказов
оборудования, программа продолжает работать даже после
выдачи неверных результатов.
Отказоустойчивость оператора

Какова вероятность того, что оператор системы сделает
ошибку?
Построение
отказоустойчивой системы


Существует дисциплина в системной инженерии,
которая связана с оценкой отказоустойчивости
системы
Она принимает во внимание возможности отказов
различных компонентов системы и их комбинаций
 Для системы с 2–мя компонентами A и B, где
возможности отказа А - P (A) и возможности
отказа B - P (B).
Возможности отказов



Так как компонентов 2 и работа системы зависит
от обоих из них, то возможность отказа всей
системы составляет
 P (S) = P (A) * P (B)
Если число компонентов растет, то растет и
вероятность отказа системы
Если компоненты дублируются, то возможность
отказа составит
n
 P (S) = P (A) (могут отказать все компоненты)
Требования функциональной
отказоустойчивости

Предварительно определенная область всех
значений, которые вводятся оператором, должна
быть описана, и система должна проверять
соответствие вводимых оператором данных.

Система должна проверять все диски на сбойные
участки перед инициализацией.

Система должна быть
статического анализа
проверена
методами
Спецификация
нефункциональной
отказоустойчивости



Необходимый уровень отказоустойчивости должен быть
описан численно
Отказоустойчивость – динамический атрибут системы –
связь спецификации отказоустойчивости и исходного кода
бессмысленна.
Подходящие метрики отказоустойчивости должны быть
выбраны в соответствии с обеспечением
отказоустойчивости всей системы
Метрики
отказоустойчивости



Метрики отказоустойчивости есть единицы для измерения
отказоустойчивости системы
Отказоустойчивость системы определяется подсчетом числа
оперативных отказов и, при необходимости, соотнесения их
с требованиями, предъявленными к системе и ко времени, в
течение которой система должна быть в рабочем состоянии
Для обеспечения отказоустойчивости критических систем
необходимы программы протяженных по времени измерений
Метрики
отказоустойчивости (2)
Metric
POFOD
Probability of failure
on demand
Explanation
The likelihood that the system will fail when a service
request is made. For example, a POFOD of 0.001
means that 1 out of a thousand service requests may
result in failure.
ROCOF
The frequency of occurrence with which unexpected
Rate of failure
behaviour is likely to occur. For example, a ROCOF of
occurrence
2/100 means that 2 failures are likely to occur in each
100 operational time units. This metric is sometimes
called the failure intensity.
MTTF
The average time between observed system failures.
Mean time to failure For example, an MTTF of 500 means that 1 failure can
be expected every 500 time units.
MTTR
The average time between a system failure and the
Mean time to repair return of that system to service.
AVAIL
The probability that the system is available for use at a
Availability
given time. For example, an availability of 0.998
means that in every 1000 time units, the system is
likely to be available for 998 of these.
Работоспособность




Измерение интервала времени, в течение которого
система остается в рабочем состоянии
Учитывает время на восстановление и рестарт
системы
Работоспособность на 0.998 означает, что ПО
находится в рабочем состоянии в течение 998 из
1000 временных интервалов
Подходит для систем, работающих без останова
 Телефонные станции, станции слежения на
транспорте
Возможность отказа по
требованию (POFOD)



Существует возможность отказа системы при
запросе сервиса. Используется, если запросы
сервиса не частые и нерегулярные
Подходит для систем защиты, где сервисы
запрашиваются от случая к случаю и где нет
отчетливой последовательности вызовов сервиса
Используется для многих критических систем с
компонентами, управляющими исключениями
 Аварийная система отключения на химической
фабрике
Частота возникновения отказа
(ROCOF)



Отражает частоту возникновения отказов системы
ROCOF 0.002 означает 2 отказа на протяжении
1000 временных единиц работы, т.е. 2 отказа на
1000 часов работы
Используется для операционных систем и систем,
использующих транзакции, в которых должнл
производить большое число похожих запросов с
достаточно большой частотой.
 Система обработки кредитных карт, система
заказов билетов
Время до отказа (MTTF)



Время между замеченными сбоями системы. Это
значение, обратное ROCOF для стабильных систем
MTTF 500 означает, что время между отказами –
500 временных единиц
Используется для систем с длительными
транзакциями, т.е. Там, где действие системы
продолжительны по времени. MTTF должна быть
больше, чем время транзакции
Последствия отказа



Измерения отказоустойчивости не принимают во
внимание последствий отказа
Отказы могут не иметь реальных последствий, но
часть из них приводит к потере или повреждению
данных или потерю системных сервисов.
Может понадобиться определить несколько
классов отказов и использовать разные типы
метрик для каждого из них. Спецификация
отказоустойчивости в этом случае должна быть
структурирована.
Последствия отказа (2)



При определении отказоустойчивости мы должны
учитывать не только сами отказы, их частоту и
количество, но и последствия этих отказов
Отказы, которые имеют серьезные последствия,
являются более опасными, чем те, ремонт и
восстановление после которых несложно.
В некоторых случаях должны быть определены
спецификации отказоустойчивости для различных
типов отказов.
Классификация отказов
Failure class
Transient
Permanent
Recoverable
Unrecoverable
Non-corrupting
Corrupting
Description
Occurs only with certain inputs
Occurs with all inputs
System can recover without operator intervention
Operator intervention needed to recover from failure
Failure does not corrupt system state or data
Failure corrupts system state or data
Создание спецификации
отказоустойчивости





Для каждой подсистемы проанализируйте
последствия возможных отказов.
В результате анализа разделите отказы на
классы.
Для каждого класса отказов определите
отказоустойчивость на основе подходящих
метрик.
Разные метрики должны быть использованы в
случае различных требований
отказоустойчивости
Определите требования функциональной
отказоустойчивости для уменьшения шансов
критических отказов.
Банковская система
Каждая машина в сети используется 300 раз в день
 У банка всего 1000 машин
 Время жизни ПО 2 года
 Каждая машина производит около
200 000 транзакций
 Всего 300 000 транзакций в день

Пример спецификации
отказоустойчивости
Failure class
Example
Permanent,
The system fails to operate with
non-corrupting. any card which is input. Software
must be restarted to correct failure.
Transient, non- The magnetic stripe data cannot be
corrupting
read on an undamaged card which
is input.
Transient,
A pattern of transactions acrossthe
corrupting
network
causes database
corruption.
Reliability metric
ROCOF
1 occurrence/1000 days
POFOD
1 in 1000 transactions
Unquantifiable! Should
never happen in the
lifetime of the system
Валидация спецификации



Невозможна эмпирическая валидация
спецификаций с высокой
отказоустойчивостью
Отсутствие повреждений в базе данных
означает POFOD менее, чем 1 на 200
миллионов
Если транзакция занимает 1 секунду, то
симуляция транзакций 300 000 машин в
течении дня займет 3.5 дня