1 Confiabilidade de Sistemas Exemplos Ariane 5
Propaganda
Motivação Confiabilidade de Sistemas Avelino Zorzo Variedade de plataformas Escalável • Manter o serviço apesar da existência de falhas – o que são falhas? • Eliminar todas (?) 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 Motivação • 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. Servidor Cliente Palms Sensores 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 Therac-25 SRI Laser Gyro Aceleradores Computador OBC Programa de vôo Therac-25 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. 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 Fundamentos básicos para dependabilidade • Interação humano-computador ▪ Complexidade, diferentes dispositivos • Gerência de riscos 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 • Sistema Conceitos • Função do 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 ▪ 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 Falhas Ameaças Dependabilidade Atributos Formas de atingir Ameaças Erros Defeitos 4 Ameaças Ameaças - cadeia • Defeito no serviço ▪ É o evento que acontece quando o serviço desvia de seu correto funcionamento • Erro FALHA ▪ Parte do estado do sistema que pode levar o sistema a apresentar um defeito ERRO ativação DEFEITO propagação FALHA causa • Falha ▪ Hipótese da/ou considerado como a causa de um erro Ameaças - propagação Componente B Componente A Disponibilidade Falha dormente ativação Atributos propagação erro erro propagação Confiabilidade erro Interface do serviço Atributos Falha externa Serviço correto Segurança (safety) Integridade defeito Serviço incorreto defeito Manutenibilidade Serviço correto Atributos • 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 Atributos • 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 Prevenção de falhas Formas de atingir • Prevenção de falhas ▪ Prevenir a ocorrência ou introdução de falhas Tolerância a falhas • Tolerância de falhas Formas de atingir Remoção de falhas ▪ Evitar a ocorrência de defeitos nos serviços na presença de falhas Previsão de falhas Formas de atingir Dependabilidade Falhas • Remoção de falhas Ameaças ▪ Reduzir o número de falhas e gravidade das falhas Erros Defeitos Disponibilidade • Previsão de falhas Dependabilidade ▪ Estimar o número atual, a incidência futura, e as prováveis conseqüências das falhas Atributos 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 Classificação para falhas • 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 Classificação para falhas • 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 Classificação para falhas • 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 Classificação para falhas • 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 Classificação para falhas • 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 Classificação para falhas • 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 Classificação para falhas • 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 Classificação para falhas • 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 Defeitos • 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 Classificação para defeitos Domínio Detectabilidade Defeitos Consistência Classificação para defeitos • 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 Conseqüências Classificação para defeitos • 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 Classificação para defeitos • 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 Classificação para defeitos • Quanto à consistência Classificação para defeitos • Quanto à conseqüê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 ▪ 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 Classificação para defeitos Classificação para defeitos Defeitos de conteúdo • 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 Domínio Tempo e conteúdo Defeitos menores Defeitos Detectabilidade Defeitos catastróficos Consistência ▪ Redundância ▪ Estado errôneo não ser necessário para entrega do serviço Defeitos menores Defeitos catastróficos Conseqüências Defeitos menores Defeitos catastróficos 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 Defeitos de tempo Classificação para erros • 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
