Программная компонента поддержки принятия решений по типовым аварийным ситуациям и способам их устранения
Курсовой проект - Компьютеры, программирование
Другие курсовые по предмету Компьютеры, программирование
а систему (например, количества одновременно подключившихся пользователей) с последующей быстрой стабилизацией нагрузки.
б) постепенный отказ - отказ, вызванный постепенным изменением одного из параметров системы или обрабатываемых системой данных. Такой отказ может возникать, например, при переполнении внутреннего буфера, хранящего информацию о состоянии системы в каждый момент времени. Если время работы системы больше размера буфера или не предусмотрена его очистка - рано или поздно возникнет переполнение.
в) перемежающийся отказ - многократно возникающий самоустраняющийся сбой одного и того же характера. Поскольку в данном случае речь идет уже о систематически проявляющемся дефекте системы, то можно говорить именно об отказе, а не о серии сбоев.
г) деградационный отказ - отказ, обусловленный естественным износом оборудования, на котором функционирует программная система, даже при соблюдении всех норм и правил проектирования, эксплуатации и сопровождения системы. Эти отказы не вызваны конструктивными дефектами системы, однако, для их предупреждения в состав системы может входить модуль мониторинга ее состояния, сообщающий о превышении степени износа частей системы. В случае, если планируется длительная эксплуатация системы, отсутствие требований и реализации такого модуля должно быть выявлено в процессе верификации.
По причинам:
а) ресурсный отказ - отказ, в результате которого система достигает предельного состояния, т.е. такой отказ вызван в первую очередь нехваткой ресурсов (например, дискового пространства) для работы системы. Ситуации, вызывающие такие отказы, могут моделироваться при нагрузочном тестировании.
б) конструктивный отказ - отказ, вызванный нарушением процесса проектирования и разработки системы или неверным проектированием. Процесс верификации и тестирования в первую очередь направлен на обнаружение дефектов, вызывающих конструктивные отказы.
в) производственный отказ - отказ, связанный с нарушением процесса производства или сопровождения системы. В применении к программным системам производственные отказы могут возникать в случае неверного выполнения профилактических работ при сопровождении системы. Например, в результате выполнения профилактических работ могут быть утеряны файлы настройки системы, в результате чего она переходит в режим работы по умолчанию, несовместимый с текущими настройками оборудования. Предупреждение таких отказов состоит в первую очередь в корректном составлении эксплуатационной документации и документации сопровождения, которая должна быть верифицирована.
г) эксплуатационный отказ - отказ, связанный с нарушением правил эксплуатации. Причины, вызывающие данный вид отказов, связаны в первую очередь с человеческим фактором. Поэтому основные способы выявления таких отказов - проведение тестирования системы на удобство использования, верификация эксплуатационной документации, введение в систему защитных механизмов, блокирующих потенциальные ошибки оператора.
По способу обнаружения:
а) явный отказ - отказ, который обнаруживается сразу после его возникновения штатными средствами контроля состояния системы.
б) скрытый отказ - отказ, который не обнаруживается штатными средствами контроля состояния системы, либо обнаруживается ими спустя некоторое время после возникновения отказа. Такой отказ может послужить причиной для одного или нескольких зависимых отказов.
По связи с другими отказами:
а) независимый отказ - отказ, возникновение которого не обусловлено другими отказами.
б) зависимый отказ - отказ, возникновение которого вызвано другими отказами.
Процесс верификации не гарантирует отсутствия в системе всех дефектов, которые могут вызвать сбои, отказы или аварии - речь идет только об определенном уровне отсутствия этих дефектов. Поэтому когда речь идет о системах, к надежности которых предъявляются повышенные требования, для повышения их надежности кроме верификации используются различные методы разработки устойчивого кода.
При этом в результате верификации из системы устраняются дефекты, которые могут быть выявлены при анализе требований и/или кода, а методы разработки устойчивого кода дают дополнительную гарантию того, что система сохранит работоспособность в случаях, не предусмотренных требованиями. Однако, не следует расценивать эти методы как замену верификации или грамотного проектирования.
Примеры произошедших инцидентов:
Транспорта СОД-А:
а) TATL 03А *** Неверен адрес УНО= в кодограмме
Причина. Принята кодограмма с адресом получателя, отсутствующим в Адресной книге МКТК.
Действия оператора. Сообщить Администратору МКТК.
б) TATL 04А *** НС НЕ ГОТОВО
Причина. Информация оператору о переходе направления связи в неготовность по инициативе абонента.
Действия оператора. Не требуются.
в) TATL 10А *** Адресат не найден
Причина. Информация оператору об отсутствии адреса получателя в Адресной книге МКТК.
Действия оператора. Исправить параметры объекта и перезапустить МКТК.
д) TATL 11А *** Получен запрет по НС=
Причина. Информация оператору о запрете приема кодограмм указанной категории срочности.
Действия оператора. Не требуются.
е) TATL 80Е *** Ошибка выборки интерфейсного блока из очереди, RC=
Причина. Информация оператору об ошибке выборки интерфейсного блока из очере