Confiabilidade de Sistemas

Documentos relacionados
Fiabilidade de Sistema Informáticos

Bruno R. N. Matheus. Engenharia de Software Prof. Paulo Masiero

Sistemas Distribuídos

5 Fidedignidade Disponibilidade Confiabilidade Segurança Proteção Privacidade Integridade

Engenharia de Software Sistemas Sociotécnicos

falhas em sistemas distribuídos

Sistemas Distribuídos Aspectos de Projeto de SD. Aspectos de Projeto em SD. Transparência 14/03/12. ! Transparência; ! Abertura; !

Sistemas Críticos. Centro de Informática - Universidade Federal de Pernambuco Engenharia da Computação Kiev Gama

Designing Data Intensive Applications

Confiabilidade de software. Qualidade de Software. Confiança: Funcionalidade. Falhas provocam custos

Segurança Atualmente. Prof. Paulo Cesar F. de Oliveira, BSc, PhD

Disciplina: Engenharia de Software. 4 Bimestre Aula 3: CONFIANÇA E PROTEÇÃO

Análise da Dependabilidade em Redes Utilizando Reliability Block Diagram

Unidade III. Unidade III. Existe uma tendência dos sistemas de informação a funcionarem cada vez mais em Intranets e na Internet.

Segurança Informática em Redes e Sistemas

Sistemas Distribuídos. Plano de Curso. Plano de Curso 04/03/12 ! EMENTA:

Técnicas para obtenção de Tolerância a Falhas

Engenharia de Software I Confiança do sistema

Segurança e Controle em Sistemas de Informação. Profa. Ellen Francine ICMC-USP

falhas em sistemas distribuídos

Tolerância a Falhas. Sumário. December 18, Introdução e Terminologia. Modelos de Falha

Apresentação da Disciplina de Engenharia de Software II

Apresentação do Curso de Engenharia de Software /2

Apresentação do Curso de Engenharia de Software 2

TESTES DE SOFTWARE 1. Fundamentos sobre testes de software

MEIC Sistemas Distribuídos

Introdução aos Testes de Software

Sistemas Distribuídos

Sistemas Distribuídos Capítulo 8 - Aula 13

Desenvolvimento de Aplicações Distribuídas

Engenharia de Software

Meios para obter e validar a dependabilidade

Tolerância a falha. Edy Hayashida

Confiança. Objetivos. Reflete o grau de confiança do usuário no sistema

Sistemas Distribuídos

1- Confiabilidade ( 2 ) Proteção contra perdas e estragos. 2- Integridade ( 3 ) Proteção contra interferência de cortes de funcionamento

Também conhecidos como programas. Conjunto de instruções organizadas que o processador irá executar. É o software que torna o computador útil.

Apresentação do Curso de Engenharia de Software 2

Engenharia de Software I

ENGENHARIA CONFIABILIDADE DE SOFTWARE

Engenharia de Software 1

Teste de Software. Competência: Entender as técnicas e estratégias de testes de Software

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar

MÓDULO 4 DEPENDABILIDADE. Curso de Especialização em Transporte Ferroviário de Carga

Um estudo sobre a relação entre processos de engenharia de software com a dependabilidade e previsão de falhas em sistemas

Gerência de Redes Áreas Carlos Gustavo Araújo da Rocha. Gerência de Redes

Avaliação quantitativa de riscos em projetos de desenvolvimento de software. Aluno: Camila Gomes Orientador: Eduardo Tavares

Políticas de Qualidade em TI

SISTEMAS OPERACIONAIS

Apresentação do Curso de Engenharia de So5ware II

3. Engenharia dos requisitos de software

Análise e Projeto de Software

SIST706 Sistemas Distribuídos

Aspectos importantes como a autenticação e autorização. Tipos de ameaças: Atividade não autorizada; Downloads não autorizados; Redes: local de transmi

Segurança e Auditoria de Sistemas. Prof. Alessandra Bussador

Análise e projeto de sistemas

Qualidade de Software QUALIDADE DE SOFTWARE PRODUTO

Avaliação da Disponibilidade de Infraestrutura de Sincronização de Dados

Arquitetura de sistemas distribuídos

1 Introdução. 1.1 Contextualização

Apresentação do Curso de Engenharia de So5ware II

Apresentação do Curso de Gerência de Projetos de So7ware

ENGENHARIA DE SOFTWARE O QUE SÃO TESTES? TESTES TESTES TESTES 26/08/2014. São pontuais; São previsíveis; São finitos;

Conceitos e terminologia de segurança quanto à disponibilidade

Gerenciamento de Redes. Introdução

PLANEJAMENTO DAS DISCIPLINAS DE SISTEMAS DIGITAIS NA EC3. Workshop de Graduação do PCS Prof. Edson S. Gomi 31 de julho de 2018

Apresentação do Curso de Engenharia de So5ware II

Cliente-servidor Código móvel Agentes de software Processos pares. Prof a Ana Cristina B. Kochem Vendramin DAINF / UTFPR

Requisitos de Interfaces para Sistemas Críticos

Introdução aos Sistemas Distribuídos

Computação Distribuída

Componente de aplicação. Figura 1 - Elementos funcionais de uma aplicação sendo executados de forma distribuída

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar

Fundamentos de Segurança da Internet. Cristine Hoepers, D.Sc. Klaus Steding-Jessen, D.Sc. 30/03/2016

Engenharia de Requisitos

Engenharia de Software I

Introdução a Teste de Software

INTRODUÇÃO A ENGENHARIA DE SOFTWARE

TS01. Teste de Software INTRODUÇÃO À QUALIDADE DE SOFTWARE. COTI Informática Escola de Nerds

Aula 8 Segurança em Redes Sem-fio

SSC 0721 Teste e Validação de Software

Engenharia de Software

Teste de Software. Prof. Wylliams Barbosa Santos Laboratório de Programação

Tolerância a Falhas. June 2, 2010

Sistema de Software Distribuído

Segurança Corporativa utilizando Sistema de Detecção de Intrusão (IDS)

Teste de Software. Prof. Camila. Pedro de Assis Sobreira Jr.

AN INTRODUCTION TO SOFTWARE ENGINEERING

Especificação de confiabilidade e segurança. Paulo C. Masiero Livro Sommerville

Sistemas Distribuídos

Falta Erro Falha. Motivação. Teste de Software. Falha, Falta e Erro. Falha, Falta e Erro. Falha, Falta e Erro. Falha, Falta e Erro 6/6/11

Sistemas Distribuídos

Sistemas Distribuídos

Gerenciamento e Interoperabilidade de Redes. Gestão de Segurança da Informação Prof. João Henrique Kleinschmidt

UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA

Transcrição:

Motivação Confiabilidade de Sistemas Avelino Zorzo Manter o serviço apesar da existência de falhas o que são falhas? Eliminartodas (?) as falhas O usuário não deve ser o responsável por tolerar a falha Perspectiva Componentes de hardware cada vez mais confiáveis Software e projetos cada vez menos confiáveis devido a complexidade e rapidez para o desenvolvimento Variedade de plataformas Motivação Palms Sensores Cliente Servidor Escalável Nesse ambiente qualidade passa a ser um diferencial: O acesso a produtos concorrentes é facilitado. Não se toleram pequenos problemas. É preciso manter os produtos sempre atualizados e com qualidade. Baseado em apresentação dos profs. Flávio e Bernardo Exemplos Ariane 5 1

Ariane 5 Ariane 5 e sua carga foram destruídos 37 segundos depois de levantar vôo Erro devido a uma falha de software: Conversão de número em ponto flutuante para inteiro de 16 bits Conversão gerou uma exceção que não foi tratada Custo total do projeto: Us$ 7B Custo da carga: Us$ 500M Ariane 5 "The failure of the Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift-off). This loss of information was due to specification and design errors in the software of the inertial reference system. The internal SRI* software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. " *SRI stands for Système de Référence Inertielle ou Sistema de Referência Inercial. Ariane 5 SRI Therac-25 Laser Gyro Aceleradores Computador OBC Programa de vôo Therac-25 Therac-25 é um acelerador de partículas para tratamento com radioterapia. Dependia de software para segurança (diferente do Therac-20, Therac-6). Máquina foi utilizada inúmeras vezes sem problemas, mas causou queimaduras e mortes. Problemas de software: Sem proteção para variáveis compartilhadas (race conditions). Interface com usuário sensível a velocidade do usuário. Therac-25 2

Therac-25 Therac-25 Acidentes 3 de junho de 1985: paciente recebeu overdose 26 de julho de 1985: paciente recebeu queimaduras graves morreu em novembro Dezembro de 1985: paciente recebe overdose 21 de março de 1986: acidente paciente morreu 11 de março de 1986: acidente paciente morreu 17 de janeiro de 1987: nova overdose Desafios Bugs no projeto de hardware e software Complexidade dos sistemas Clusters e Grids, sistemas ubíquos Alto grau de paralelismo Computação móvel e computação distribuída Baixa potência, tempo real Desafios Novas tecnologias Computação quântica, nanotecnologia, biotecnologia, RFID Interação humano-computador Complexidade, diferentes dispositivos Gerência de riscos Fundamentos básicos para dependabilidade Baseado no artigo: A. Avizienis, J-C. Laprie, B. Randell, C. Landwehr. Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 11-33, Jan. 2004. 3

Conceitos Conceitos Sistema Entidade que interage com outras entidades Outros sistemas (hardware, software, pessoas, mundo físico, ) Estes outros sistemas compõem o Ambiente Limite do Sistema Fronteira entre o Sistema e o Ambiente Função do sistema Aquilo para o qual o sistema foi desenvolvido Comportamento do sistema Aquilo que o sistema faz para implementar sua função conjunto de estados Estrutura do sistema Aquilo que habilita o sistema a gerar seu comportamento Conceitos Dependabilidade Habilidade de entregar um serviço que pode, justificadamente, ser confiado. SISTEMA AMBIENTE Habilidade de evitar defeitos no serviço que são mais freqüentes e mais severos do que é aceitável. LIMITES DO SISTEMA Dependabilidade Ameaças Ameaças Falhas Dependabilidade Ameaças Erros Formas de atingir Defeitos 4

Ameaças Defeito no serviço É o evento que acontece quando o serviço desvia de seu correto funcionamento Erro Parte do estado do sistema que pode levar o sistema a apresentar um defeito Falha Hipótese da/ou considerado como a causa de um erro Ameaças - cadeia FALHA ERRO DEFEITO FALHA ativação propagação causa Ameaças - propagação Falha dormente ativação Falha externa Componente A Serviço correto erro propagação erro Interface do serviço Componente B erro defeito Serviço incorreto propagação Serviço correto defeito Disponibilidade Confiabilidade Segurança (safety) Integridade Manutenibilidade Disponibilidade (availability) Estar pronto para executar o serviço corretamente Confiabilidade (reliability) Manter o serviço funcionando corretamente Segurança (safety) Ausência de conseqüências catastróficas sobre o usuário ou sobre o ambiente Integridade Ausência de alterações impróprias do sistema Manutenibilidade Habilidade do sistema passar por modificações e reparos Outros: Testabilidade, performabilidade, confidencialidade,... 5

Formas de atingir Formas de atingir Formas de atingir Prevenção de falhas Tolerância a falhas Remoção de falhas Previsão de falhas Prevenção de falhas Prevenir a ocorrência ou introdução de falhas Tolerância de falhas Evitar a ocorrência de defeitos nos serviços na presença de falhas Formas de atingir Dependabilidade Remoção de falhas Reduzir o número de falhas e gravidade das falhas Previsão de falhas Estimar o número atual, a incidência futura, e as prováveis conseqüências das falhas Dependabilidade Ameaças Falhas Erros Defeitos Disponibilidade Confiabilidade Segurança (safety) Integridade Manutenibilidade Prevenção de falhas Formas de atingir Tolerância a falhas Remoção de falhas Previsão de falhas Falhas Falha pode ser: Ativa: quando causa um erro Dormente: quando ainda não causou um erro Podemos classificar falhas de acordo com oito perspectivas Algumas falhas podem ser classificadas segundo diversas destas perspectivas combinação delas Fase de criação ou ocorrência Falhas de desenvolvimento Ocorre durante o desenvolvimento do sistema, ou manutenção durante a fase de uso, ou geração de procedimentos para operar ou manter o sistema Ex: furos de software, bombas lógicas Falhas operacionais Ocorre durante a entrega do serviço da fase de uso Ex: tentativas de intrusão, vírus, entradas incorretas 6

Limites do sistema Falhas internas Originada a partir da parte interna dos limites do sistema Ex: Bombas lógicas, furos de software Falhas externas Originada fora dos limites do sistema e propaga erros para dentro do sistema através de interação ou interferência Ex: interferência física, vermes Causadas por fenômenos Falhas naturais Causada por um fenômeno natural sem a interferência humana Ex: deterioração física, interferência física, radiação Falhas geradas por humanos Resultado de ações de pessoas Ex: interferência física, bombas lógicas Dimensão Falhas de hardware Originadas a partir de, ou que afetam, o hardware Ex: problemas de produção, deterioração física Falhas de software Afeta o software, programas ou dados Ex: entrada incorreta, vírus, bombas lógicas Persistência Falhas permanentes Presença é contínua no tempo Ex: problemas no software, vírus, deterioração física, interferência física Falhas transientes Presença tem tempo limitado Ex: deterioração física, interferência física Objetivo Falhas maliciosas Introduzida no sistema com o objetivo malicioso de causar algum prejuízo ao sistema Ex: Bombas lógicas, vírus, vermes Falhas não-maliciosas Introduzida sem um objetivo malicioso Ex: furos de software, entradas erradas Intenção Falhas deliberadas A partir de decisões erradas com conhecimento e intenção Ex: problemas de produção, vírus Falhas não deliberadas Devido a situações que o operador ou desenvolvedor não tem conhecimento Ex: deterioração física 7

Defeitos Capacidade Falhas acidentais Introduzidas inadvertidamente Ex: furos de software, entradas erradas Falhas por incompetência Resultado da falta de competência por alguém que foi autorizado a fazer algo Ex: furos de software, interferência física Defeito de um serviço é definido como um evento que ocorre quando o serviço não atende sua funcionalidade Mesmo quando o serviço atende a especificação ele pode apresentar um defeito Ex: não está adequado para o usuário Defeito na especificação Classificação a partir de 4 categorias Defeitos Domínio Detectabilidade Consistência Conseqüências Quanto ao domínio Defeito de conteúdo: a informação entregue pela interface do serviço se desvia da função do serviço Defeito de tempo: o tempo da entrega ou duração da informação se desvia da função do sistema Cedo ou tarde Quanto ao domínio Ambos conteúdo e tempo Defeitos de parada (halt): quando o estado externo se torna constante, i.e., a atividade externa, mesmo se existir, não é perceptível ao usuário Defeitos erráticos (erratic): quando o serviço é entregue mas de uma maneira errática Quanto à detectabilidade Defeitos sinalizados: Uma sinalização ocorre na interface do serviço quando um mecanismo verifica a corretude do resultado do serviço Defeitos não sinalizados: Quando o serviço não informa defeitos para o usuário Pode ainda existir alarme falso Serviço pode ser entregue mas em um modo degradado 8

Quanto à consistência Principalmente quando existem dois ou mais usuários Defeitos consistentes: o resultado incorreto do serviço é percebido da mesma forma por todos usuários Defeitos inconsistentes: alguns ou todos usuários recebem resultados diferentes (alguns podem receber inclusive resultados corretos) Defeitos inconsistentes = Defeitos Bizantinos Quanto à conseqüência Defeitos menores: as conseqüências ruins são equivalentes aos benefícios do serviço quando correto : Defeitos catastróficos: as conseqüências são muito maiores, em ordens de magnitude as vezes não calculáveis do que o benefício do serviço quando correto A gravidade (conseqüência) de um defeito pode ser medido por diferentes critérios: Disponibilidade: tempo que fica forado-ar Segurança: possibilidade de vidas humanas estarem envolvidas Confidencialidade: tipo da informação que pode ter sido vazada Integridade: grau de danos aos dados e a possibilidade ou não de recuperação Defeitos Domínio Detectabilidade Consistência Conseqüências Defeitos de conteúdo Defeitos de tempo Tempo e conteúdo Defeitos menores Defeitos catastróficos Defeitos menores Defeitos catastróficos Defeitos menores Defeitos catastróficos Erros Classificação para erros Erro é a parte do estado sistema que pode levar a um defeito Um erro pode ser detectado e então uma mensagem é sinalizada Erros não detectados são chamados de erros latentes Dois fatores - erro não gerar defeito Redundância Estado errôneo não ser necessário para entrega do serviço Pode-se utilizar a mesma de defeitos Conteúdo-tempo; detectado-latente; consistente-inconsistente; menorescatastróficos; Poderiam ainda ser classificados de acordo com padrão de estragos: Simples Duplos Aritmético Byte... 9

ATÉ A PRÓXIMA. Extras Segurança Propriedades de um sistema Safety vs. Security Safety Segurança no sentido de algo que funciona de maneira segura, sem problemas ou acidentes Security Segurança no sentido de: Disponibilidade somente para acessos autorizados Confidencialidade Integridade Safety vs. Liveness Safety Aquilo que o sistema não deve fazer Exemplo: Em um cruzamento duas sinaleiras em vias perpendiculares não devem Liveness Aquilo que o sistema deve fazer. Exemplo: Em um cruzamento qualquer uma das sinaleiras em um determinado momento vai estar verde. Voltar 10