Устойчивость к ошибкам

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

1. Истоки концепции динамической избыточности лежат в проектировании аппаратного обеспечения. Один из подходов к динамической избыточности — метод голосования. Данные об­рабатываются независимо несколькими идентичными устройства­ми, и результаты сравниваются. Если большинство устройств выработало одинаковый результат, этот результат и считается правильным. И опять, вследствие особой природы ошибок в про­граммном обеспечении ошибка, имеющаяся в копии программ­ного модуля, будет также присутствовать во всех других его ко­пиях, поэтому идея голосования здесь, видимо, неприемлема. Предлагаемый иногда подход к решению этой проблемы состоит в том, чтобы иметь несколько неидентичных копий модуля. Это значит, что все копии выполняют одну и ту же функцию, но либо реализуют различные алгоритмы, либо созданы разными разра­ботчиками. Этот подход бесперспективен по следующим причинам. Часто трудно получить существенно разные версии модуля, выполняющие одинаковые функции. Кроме того, возникает не­обходимость в дополнительном программном обеспечении для организации выполнения этих версий параллельно или последо­вательно и сравнения результатов. Это дополнительное программ­ное обеспечение повышает уровень сложности системы, что, ко­нечно, противоречит основной идее предупреждения ошибок — стремиться в первую очередь минимизировать сложность.

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

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

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

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

1. Прикладная программа не должна иметь возможности не­посредственно ссылаться на другую прикладную программу или данные в другой программе и изменять их.

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

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

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

5. Прикладные программы не должны иметь возможности ни остановить систему, ни вынудить ее изменить другую приклад­ную программу или ее данные.

6. Когда прикладная программа обращается к операционной системе, должна проверяться допустимость всех параметров, Прикладная программа не должна иметь возможности изменить эти параметры между моментами проверки и реального их ис­пользования операционной системой.

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

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

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

10. Если операционная система обнаруживает ошибку в себе самой, она должна попытаться ограничить влияние этой ошибки одной прикладной программой и в крайнем случае прекратить выполнение только этой программы.

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

Реализация многих из этих принципов влияет на архитектуру лежащего в основе системы аппаратного обеспечения.