Tolerância a falhas em software

Os problemas de mascaramento de falhas e fracassos nas comunicações de rede ocorrem já de longa data. No entanto, sabemos que consistência ou atomicidade podem ser mantidas e que a recuperação (resiliency) pode ser suportada apesar das falhas.
Em hardware (HW), as falhas são geralmente causadas por desgaste físico. No entanto, um software (SW) não desgasta com o tempo, ele não tem propriedades físicas, sendo totalmente conceitual. Nele, as falhas são de desenvolvimento e bugs causados por erros humanos.
Outra definição que deve ser observada é que Tolerância a Falhas em Software (TFS) é diferente de Software Tolerante a Falhas (STF), já que este último é uma sub-área do primeiro. Ainda, um STF pode ser visto de duas formas: sobre sistemas uni-processados e sistemas distribuídos, sendo utilizado para detecção de erros de desenvolvimento. O mesmo ainda pode ser: estático: em que programas são executados concorrentemente e o resultado eleito por votação; dinâmico: em que são estabelecidos checkpoints no decorrer da execução do programa.
Índice [esconder]
1 Técnicas
1.1 Mecanismo de Controle de Falhas
1.1.1 Detecção de Erros
1.1.2 Confinamento e Avaliação de Danos
1.1.3 Recuperação de Erros
1.1.4 Tratamento da Falha e Continuação do Serviço
1.2 Defeitos e Erros
2 Abordagens de SW Tolerante a Falhas
2.1 Abordagem Recovery Block (Bloco de Recuperação)
2.2 Programação N-Versões
2.2.1 Comparação de Voto
2.3 Programação N-versões (NV) versus Bloco de Recuperação (RB)
2.4 Outras Abordagems Uni-processadas
2.4.1 Mecanismo de Deadline
2.4.2 Mecanismo de Bloco de Recuperação Distribuído
2.4.2.1 Problemas
2.4.3 Diversidade de Dados
3 Ligações externas
Técnicas[editar]

Mecanismo de Controle de Falhas[editar]
As atividades relacionadas à tolerância a falhas podem ser subdivididas em quatro fases: detecção de erro, confinamento e avaliação de danos, recuperação de erros e tratamento de falhas.
Detecção de Erros[editar]
Principal fator para qualquer