Методы разработки устойчивого кода

25.1.2. Отказы и аварии

Отказы вызывают длительное нарушение функционирования системы, или, по ГОСТ 27.002-89 [21], приводят ее в предельное состояние. Предельное состояние - это состояние, при котором дальнейшая эксплуатация системы недопустима или нецелесообразна либо восстановление ее работоспособного состояния невозможно или нецелесообразно. Тем самым в ГОСТ 27.002-89 не делается разницы между отказом и аварией. Будем называть отказом состояние системы, при котором восстановление ее работоспособного состояния возможно.

Отказы классифицируются согласно ГОСТ 27.002-89 следующим образом.

По временным характеристикам

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

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

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

По причинам

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

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

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

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

По способу обнаружения

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

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

По связи с другими отказами

Независимый отказ - отказ, возникновение которого не обусловлено другими отказами.

Зависимый отказ - отказ, возникновение которого вызвано другими отказами.

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

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