Отказы в программных и аппаратных компонентах

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

На рис. 7.1 мы отделили аппаратные компоненты от программных, поскольку методы обработки аппаратных сбоев часто отличаются от методов обработки программных ошибок. Здесь также выделены различные уровни ПО. Некоторые из них находятся вне «досягаемости» разработчика (т.е. он не может ими управлять напрямую) и требуют специального рассмотрения процесса обработки исключений и ошибок. На этапах проектирования, разработки и тестирования ПО обязательно следует принимать во внимание возможность аппаратных сбоев и наличия ошибок в различных «слоях» ПО. Для программ, которым присущ параллелизм или состоящих из распределенных компонентов, следует учитывать дополнительные обстоятельства, весьма «благоприятные» для возникновения аппаратных сбоев. Например, в распределенных программах используется взаимодействие аппаратных и программных средств. Ошибка, «закравшался» в компонент, отвечающий за это взаимодействие, может привести к отказу всей системы. Программы, разработанные для параллельной работы процессоров, могут сбоить, если ожидаемое количество процессоров окажется недос-гупным. Даже если средства связи и процессоры прекрасно отработали при загрузке системы, ее отказ возможен в любой момент после начала функционирования. Исключительная ситуация может возникнуть в любом из компонентов оборудования и на любом уровне ПО. Кроме того, каждый программный уровень может содержать дефекты, которые необходимо каким-то образом обрабатывать. На этапе проектирования ПО следует рассматривать возможные исключительные ситуации и ошибки в программах, присущие каждому уровню ПО в отдельности. Ведь варианты восстановления приложения после возникновения исключительных ситуаций и исправления ошибок, которые возможны на уровне 2, отличаются от вариантов, применимых к уровню 3. К сбоям, которые возможны на различных уровнях ПО и в аппаратных компонентах, следует добавить сбои, характеризующиеся архитектурной областью локализации, специфической для каждого приложения. Например, на рис. 7, 2 показано, как по мере увеличения дистанции между задачами возрастает уровень сложности обработки ошибок и исключительных ситуаций.

Чем больше в программных или аппаратных компонентах дистанция между параллельно выполняющимися задачами, тем более высокий уровень организации требуется для проектирования компонентов обработки исключительных ситуаций иошибок. Изучив рис. 7.1 и 7.2, можно понять: для того, чтобы спроектировать и разработать надежное ПО, необходимо прелусмотреть не только, какие возможны исключительные ситуации и ошибки, но и где они могут возникнуть.