Ambos descrevem a consistência do comportamento de um aplicativo, mas "robustez" descreve a resposta de um aplicativo à sua entrada , enquanto "tolerância a falhas" descreve a resposta de um aplicativo ao seu ambiente .
Um aplicativo é robusto quando pode trabalhar de forma consistente com dados inconsistentes. Por exemplo: um aplicativo de mapas é robusto quando pode analisar endereços em vários formatos com vários erros de ortografia e retornar um local útil. Um music player é robusto quando pode continuar decodificando um MP3 depois de encontrar um quadro malformado. Um editor de imagens é robusto quando pode modificar uma imagem com metadados EXIF incorporados que talvez não reconheça - especialmente se puder fazer alterações na imagem sem destruir os dados EXIF.
Um aplicativo é tolerante a falhas quando pode funcionar de forma consistente em um ambiente inconsistente. Um aplicativo de banco de dados é tolerante a falhas quando pode acessar um fragmento alternativo quando o principal não está disponível. Um aplicativo da Web é tolerante a falhas quando pode continuar manipulando solicitações do cache, mesmo quando um host da API está inacessível. Um subsistema de armazenamento é tolerante a falhas quando pode retornar resultados calculados a partir da paridade quando um membro do disco está offline.
Nos dois casos, espera-se que o aplicativo permaneça estável, se comporte de maneira uniforme, preserve a integridade dos dados e forneça resultados úteis, mesmo quando um erro for encontrado. Porém, ao avaliar a robustez, você pode encontrar critérios que envolvem dados, enquanto que ao avaliar a tolerância a falhas, você encontra critérios que envolvem tempo de atividade.
Um não leva necessariamente ao outro. Um aplicativo de reconhecimento de voz móvel pode ser muito robusto, fornecendo uma capacidade extraordinária de reconhecer a fala de maneira consistente em uma variedade de sotaques regionais com enormes quantidades de ruído de fundo. Mas se for inútil sem uma conexão rápida de dados celulares, não é muito tolerante a falhas. Da mesma forma, um aplicativo de publicação na web pode ser imensamente tolerante a falhas, com várias redundâncias em todos os níveis, capaz de perder datacenters inteiros sem falhar, mas se ele eliminar uma tabela de usuário e travar na primeira vez que alguém se registrar com um apóstrofo em seu sobrenome , não é robusto.
Se você estiver procurando por literatura acadêmica para ajudar a descrever a distinção, procure domínios específicos que fazem uso de software, em vez de software em geral. A pesquisa de aplicativos distribuídos pode ser um terreno fértil para os critérios de tolerância a falhas, e o Google publicou algumas de suas pesquisas que podem ser relevantes. A pesquisa de modelagem de dados provavelmente aborda questões de robustez, pois os cientistas estão particularmente interessados nas propriedades de robustez que produzem resultados reproduzíveis. Você provavelmente pode encontrar trabalhos descrevendo aplicativos estatísticos que podem ser úteis, como na modelagem climática, modelagem de propagação de RF ou sequenciamento de genoma. Você também encontrará engenheiros discutindo "design robusto" em coisas como sistemas de controle.
O whitepaper do Google File System descreve sua abordagem aos problemas de tolerância a falhas, que geralmente envolvem as suposições de que as falhas dos componentes são rotineiras e, portanto, o aplicativo deve se adaptar a elas:
Este projeto para uma classe na Rutgers suporta uma definição orientada para "falha de componente" de "tolerância a falhas":
Existem muitos documentos sobre "modelagem robusta XYZ", dependendo do campo que você investigar. A maioria descreverá seus critérios para "robusto" no resumo, e você descobrirá que tudo isso tem a ver com a maneira como o modelo lida com informações.
Este resumo de um cientista climático da NASA descreve a robustez como um critério para avaliar modelos climáticos:
Este artigo de um pesquisador do MIT examina aplicativos de protocolo sem fio, um domínio no qual a tolerância a falhas e a robustez se sobrepõem, mas os autores usam "robusto" para descrever aplicativos, protocolos e algoritmos, enquanto usam "tolerância a falhas" em referência à topologia e componentes: