Engenharia de Confiabilidade: programando sistemas confiáveis

Disponibilidade e Confiabilidade 

Considerando que o sistema é algo que fornece algum tipo de serviço (enviar mensagens, registrar pagamentos, reproduzir músicas, por exemplo), podemos considerar que a disponibilidade se refere a esse serviço estar ou não ativo e funcional, enquanto a confiabilidade se refere ao sistema apresentar ou não os resultados corretos. As definições mais específicas, segundo Ian Sommerville, são:

1. Confiabilidade: A probabilidade de operação isenta de falhas ao longo de um período especificado, em um determinado ambiente, para um propósito específico. 
2. Disponibilidade: A probabilidade de que um sistema, em algum momento, estará operacional e será capaz de prestar serviços requisitados

A confiabilidade do sistema não é um número absoluto porque depende de onde e de como o sistema é utilizado. Ao testar um sistema em um ambiente de escritório e em um ambiente universitário, obteremos resultados bem diferentes. Isso ocorre porque haverá distintos níveis de interesse e comportamento dos usuários, o que pode resultar em mais ou menos falhas de sistema. Portanto as percepções de confiabilidade do sistema em cada um desses ambientes são variáveis. 

A definição de confiabilidade se baseia em uma ideia de operar sem falhas. E a falha, por sua vez, é um comportamento que não está em conformidade com a especificação do sistema. Sommerville ressalta dois problemas nesta definição: 

1. As especificações de software frequentemente estão completas ou incorretas e é responsabilidade dos engenheiros de software interpretar como o sistema deveria se comportar. Em via de regra, eles não são especialistas do domínio e podem não implementar o comportamento que o usuário espera. Assim o software pode se comportar conforme as especificações técnicas, mas disforme das expectativas dos usuários.
2. Além dos desenvolvedores, quase ninguém lê as documentações de especificação de software. Consequentemente, os usuários podem prever que o software se comporte de uma maneira quando a especificação estabelece algo divergente.

Considerando esses pontos, a falha não é algo que pode ser definido objetivamente, mas sim um julgamento feito pelos usuários do sistema. Por esse motivo, usuários não têm a mesma impressão de confiabilidade e os defeitos que a afetam podem nunca aparecer nitidamente para eles.

Já a disponibilidade de um sistema não depende apenas do seu número de falhas, como também do tempo necessário para consertar as causas dessas falhas. Vamos imaginar um sistema A que falha apenas uma vez por ano e um sistema B que falha uma vez por mês. Inicialmente pode-se imaginar que A é mais confiável que B. Porém, se B leva 5 minutos para reiniciar após uma falha e A leva 6 horas, a disponibilidade do sistema B é muito maior do que a do sistema A. 

A quantidade de tempo em que o sistema está indisponível não é o único fator que gera perturbação: o momento em que o sistema falha também é muito importante! Se o sistema estiver indisponível por uma hora todo dia entre 01h00 e 02h00 da manhã pode não afetar os usuários. Entretanto, se a disponibilidade falhar por 10 minutos durante o horário comercial o efeito será muito maior.

Apesar da confiabilidade e da disponibilidade estarem intimamente relacionadas, às vezes uma pode ter mais prioridade do que a outra. Se é indispensável para os usuários usufruir do serviço contínuo do software, então o requisito de alta disponibilidade tem precedência sobre a confiabilidade. Isso pode acarretar em falhas mais frequentes, mas se o sistema puder se recuperar rapidamente delas, sem perder dados do usuário, então essas falhas podem não afetar tanto os usuários. 

Um bom exemplo de um cenário em que a disponibilidade é mais importante do que a confiabilidade são as centrais telefônicas que encaminham chamadas. Os usuários esperam realizar chamadas quando tirarem o telefone do gancho ou ativar em um aplicativo. Portanto o sistema tem requisitos de alta disponibilidade. Ocorrendo um defeito no sistema enquanto a conexão estiver sendo estabelecida, sua correção costuma ser simples e rápida. Switches na estação básica reiniciam o sistema e tentam novamente a conexão. Assim, os usuários podem nem notar que houve uma falha. Além disso, mesmo se a chamada for interrompida, as consequências geralmente não são graves. Os usuários podem simplesmente reconectar se isso acontecer.

Métricas de Confiabilidade

Pode-se considerar a confiabilidade com uma probabilidade de ocorrência de falha no sistema quando eles tiverem uso em um ambiente operacional específico. Imagine que um sistema falhe 1 a cada 1000 transações. Nesse caso teríamos uma probabilidade de falha de 0,001. O que não determina que sempre haverá uma falha a cada mil transações, mas sim que se você observar N mil transações o número de falhas deve ser de aproximadamente N x 0,001. 

Existem três métricas principais empregadas para especificar a confiabilidade e a disponibilidade:

1. Probabilidade de falha sob demanda (POFOD, sigla em inglês para probability of failure on demand):  O uso dessa métrica estabelece a probabilidade de que uma demanda por serviço de um sistema resulte em uma falha. Assim, uma POFOD igual a 0,001 significa que há chance de 1/1000 de que uma falha ocorra quando houver demanda. 
2. Taxa de ocorrência de falha (ROCOF, do inglês, rate of occurrence of failures):  Essa métrica estabelece o provável número de falhas de um sistema que tendem a ser observadas em relação a um certo período - por exemplo uma hora, um minuto um dia - ou a quantidade de exceções do sistema. O inverso da ROCOF é o tempo médio até a falha (MTTF, mean time of failure). Uma ROCOF de duas falhas por hora equivale a um MTTF de 30 minutos. 
3. Disponibilidade (AVAIL, do inglês availability): É a probabilidade de um sistema estar operacional quando houver uma demanda por um serviço. Desta forma, uma disponibilidade de 0,9999 significa que em média o sistema estará disponível em 99,99% do tempo de operação.

O POFOD é utilizado em situações onde a falha sob demanda pode levar a uma falha grave do sistema, independentemente da frequência das demandas. Um sistema de proteção que monitora um reator químico e interrompe a reação se ele estiver superaquecido deve ter a sua confiabilidade especificada usando POFOD, por exemplo. Comumente, as demandas sobre um sistema de proteção desse tipo são pouco frequentes porque o sistema é a última linha de defesa após todas as outras estratégias de recuperação terem falhado. Desta forma, uma POFOD de 0,01 poderia parecer arriscado. Apesar disso, se houver apenas duas demandas do sistema em toda a sua vida útil, então provavelmente esse sistema jamais falhará.

Por sua vez, a ROCOF, deve ser utilizada quando as demandas do sistema acontecem periodicamente, em vez de irregular ou imprevisível. Imagine um sistema que opere grandes quantidades de transações. Uma ROCOF de 10 falhas por dia significaria aceitar que, em média, 10 transações por dia não serão executadas com sucesso e terão de ser canceladas ou reenviadas. Caso o ambiente de uso priorize o tempo absoluto entre falhas, pode-se especificar a confiabilidade em MTTF.

Programação para Confiabilidade