O Elo Mais Fraco: Como Dependências Encadeadas Afetam o Risco do Sistema

Ao avaliar cenários de risco de sistemas, é muito fácil ignorar as dependências “encadeadas”. Somos treinados a observar o risco no nível de um “nó”, perguntando “qual a probabilidade de esta única coisa falhar”. Mas o risco do sistema é muito mais complicado do que isso.

Na maioria dos sistemas, há alguns componentes que dependem de outros componentes. O lugar mais comum em que observamos isso é no projeto de armazenamento para servidores, mas isso ocorre em qualquer projeto de sistema. Outro bom exemplo é como as aplicações web precisam tanto de hosts de aplicação quanto de hosts de banco de dados para funcionar.

É mais fácil explicar dependências encadeadas com um exemplo. Vamos analisar um projeto padrão de virtualização com armazenamento SAN para compreender onde existem as fronteiras dos domínios de falha e onde existem dependências encadeadas, e qual papel a redundância desempenha na mitigação de risco no nível do sistema.

Em um projeto padrão de SAN (storage area network, rede de área de armazenamento) para virtualização, você tem hosts de virtualização (que chamaremos de “servidores” por simplicidade), switches SAN (switches dedicados à rede de armazenamento) e os próprios arrays de discos. Cada uma dessas três “camadas” depende das outras para que o sistema, como um todo, funcione. Se tivéssemos o conjunto mais simples possível, com um servidor, um switch e um array de discos, teríamos muito claramente três dispositivos representando três pontos distintos de falha. A falha de qualquer um dos três faz com que todo o sistema falhe. Nenhuma peça é útil por si só. Isso é uma dependência encadeada, e a corrente é tão forte quanto seu elo mais fraco.

Em nosso exemplo simplista, cada dispositivo representa um domínio de falha. Podemos mitigar o risco melhorando a confiabilidade de cada domínio. Podemos adicionar um segundo servidor e implementar uma estratégia de alta disponibilidade ou de tolerância a falhas na camada de virtualização para reduzir o risco de falha de servidor. Isso melhora a confiabilidade de um domínio de falha, mas deixa dois intocados e tão arriscados quanto eram antes. Podemos então abordar a camada de switching adicionando um switch redundante e configurando uma estratégia de multi-pathing para lidar com a perda de um único caminho de switching, reduzindo o risco nessa camada. Agora, dois domínios de falha foram abordados. Por fim, temos de abordar o domínio de falha de armazenamento, o que é feito, de forma semelhante, adicionando redundância por meio de um segundo array de discos que é espelhado no primeiro e capaz de fazer failover de forma transparente em caso de falha.

Agora que reforçamos nosso sistema, ainda temos três domínios de falha em uma corrente de dependência. O que fizemos foi tornar cada “elo” da corrente, cada domínio de falha, mais resiliente por si só. Mas a corrente ainda existe. Isso significa que o sistema, como um todo, é muito menos confiável do que qualquer domínio de falha isolado dentro da corrente. Fizemos algo muito melhor do que tínhamos no início, mas ainda temos muitos domínios de falha. Esses riscos se somam.

O que é difícil ao determinar o risco geral é que devemos avaliar o risco de cada item, depois determinar o novo risco após a mitigação (por meio da adição de redundância) e, então, encontrar o risco cumulativo de cada um dos domínios de falha em conjunto, em uma corrente, para determinar o risco total de todo o sistema. É extremamente difícil determinar o risco dentro de cada domínio de falha, já que a forma de mitigação de risco desempenha um papel significativo. Por exemplo, um cluster de arrays de discos de armazenamento que faz failover de forma lenta demais pode resultar em uma falha geral do sistema, mesmo quando o próprio cluster de armazenamento parece ter funcionado corretamente. Até mesmo definir uma falha clara pode, portanto, ser desafiador.

Frequentemente é tentador adotar uma avaliação de risco com uma visão “de cima”, o que é muito perigoso, mas muito comum entre pessoas que não são praticantes regulares de avaliação de risco. A tendência aqui é olhar para o risco observando apenas o domínio de falha “mais ao topo” – geralmente os servidores em um caso como este, e ignorando quaisquer riscos que estejam abaixo desse ponto, considerando-os “por baixo do capô” em vez de parte da avaliação de risco. É fácil ignorar os componentes mais técnicos, menos expostos e mais mal compreendidos, como rede e armazenamento, e concentrar-se nos aspectos de confiabilidade relativamente fáceis de entender e fortemente comercializados da camada superior. Essa “visão de cima” significa que os riscos abaixo do nível superior ficam obscurecidos e geralmente são ignorados, levando a um alto risco sem uma boa compreensão do porquê.

Compreender o conceito de dependências encadeadas explica por que sistemas complexos, mesmo com estratégias complexas de mitigação de risco, frequentemente acabam sendo muito mais frágeis do que sistemas mais simples. Em nosso exemplo acima, poderíamos fazer várias coisas para “colapsar” a corrente, resultando em um sistema mais confiável como um todo.

O componente mais óbvio que pode ser colapsado é o domínio de falha de rede. Se removêssemos os switches por completo e conectássemos o armazenamento diretamente aos servidores (nem sempre possível, é claro), eliminaríamos efetivamente um domínio de falha inteiro e removeríamos um elo de nossa corrente. Agora, em vez de três correntes, cada uma com algum potencial de falha, temos apenas duas. Mais simples é melhor, mantendo-se iguais todas as demais condições.

Poderíamos, em teoria, também colapsar o domínio de falha de armazenamento, passando do armazenamento externo para o uso de armazenamento local aos próprios servidores, levando-nos essencialmente de dois domínios de falha para um único domínio de falha – o único domínio restante, é claro, carrega mais complexidade do que antes do colapso, mas a complexidade geral do sistema é bastante reduzida. Novamente, isso é com todos os demais fatores permanecendo iguais.

Outra abordagem a considerar é tornar nós individuais mais confiáveis por si sós. É moda hoje olhar para sistemas maiores e abordar a mitigação de risco dessa maneira, adicionando nós redundantes e de baixo custo para aumentar a confiabilidade dos domínios de falha. Mas, tradicionalmente, esse não era o caminho padrão adotado para a confiabilidade. Era muito mais comum no passado, como mostra a antiga prevalência de mainframes e sistemas de classe semelhante, embutir altos graus de confiabilidade em um único nó. Mainframes e sistemas de armazenamento de ponta, por exemplo, ainda fazem isso hoje. Essa pode, na verdade, ser uma abordagem extremamente eficaz, mas não consegue abordar muitos cenários e geralmente é extremamente cara, frequentemente agravada pela necessidade de ter sistemas parcial ou até completamente mantidos pelo fornecedor. Isso tende a dar certo apenas em circunstâncias de nicho especiais e não é prático em um escopo mais geral.

Portanto, em qualquer sistema dessa natureza, temos três estratégias-chave de mitigação de risco a considerar: melhorar a confiabilidade de um único nó, melhorar a confiabilidade de um único domínio ou reduzir o número de domínios de falha (elos) na corrente de dependência. Combinar essas estratégias conforme for prudente pode nos ajudar a alcançar o nível de mitigação de risco apropriado para nosso cenário de negócio.

Onde a verdadeira dificuldade existe, e continuará a existir, é na comparação de diferentes estratégias de mitigação de risco. O risco de um único nó geralmente pode ser estimado com algum nível de confiança. Uma estratégia de redundância dentro de um único domínio tem uma capacidade muito menor de ser estimada – algumas estratégias de redundância são altamente eficazes, criando domínios de falha extremamente confiáveis, enquanto outras podem, na verdade, sair pela culatra e reduzir a confiabilidade de um domínio! A complexidade que frequentemente acompanha as estratégias de redundância nunca vem sem ressalvas e, embora normalmente compense, raramente carrega o grau de benefício de confiabilidade que se espera inicialmente. Estimar o risco de uma corrente de dependência é, portanto, ainda mais difícil, pois requer uma compreensão clara dos riscos associados a cada um dos domínios de falha individualmente, bem como uma compreensão da oportunidade de falha existente nas fronteiras dos domínios (como a falha por atraso de failover de armazenamento mencionada anteriormente).

Vamos explorar as questões em torno da determinação do risco em duas abordagens muito comuns ao mesmo cenário, com base no que discutimos acima.

Dois exemplos extremos da mesma situação que viemos discutindo são um único servidor com armazenamento interno usado para hospedar máquinas virtuais versus uma “corrente” de seis dispositivos com dois servidores e usando uma solução de alta disponibilidade na camada de servidores, dois switches com redundância na camada de switching e dois arrays de discos fornecendo alta disponibilidade na camada de armazenamento. Se alterarmos qualquer fator importante aqui, geralmente conseguimos fornecer uma estimativa bastante clara de risco relativo – se qualquer um dos domínios de falha carecer de redundância confiável, por exemplo – podemos determinar com bastante clareza que o servidor único é o sistema geral mais confiável, exceto nos casos em que uma quantidade extrema de confiabilidade de nó único é atribuída a um único nó, o que geralmente é uma estratégia inviável financeiramente. Mas, com cada domínio de falha mantendo redundância, somos forçados a comparar os riscos relativos da confiabilidade intra-domínio (a corrente redundante) versus a confiabilidade inter-domínio (a corrente colapsada, servidor único).

Com as duas abordagens inteiramente diferentes, não há maneira razoável de avaliar os riscos comparativos dos dois meios de mitigação de risco. É geralmente aceito que a abordagem de seis (ou mais) nós com extensa mitigação de risco intra-domínio é a mais confiável das duas abordagens, e isso é quase certamente verdade, de modo geral. Mas nem sempre é verdade e raramente essa abordagem supera a estratégia de nó único por uma margem verdadeiramente significativa, ao passo que comumente custa de quatro a dez vezes mais do que a estratégia de servidor único. Esse é, potencialmente, um custo muito alto para o que provavelmente é um pequeno ganho em confiabilidade e um pequeno risco potencial de uma perda de confiabilidade. Cada peça adicional de redundância acrescenta complexidade que um ser humano deve implementar, monitorar e manter, e com a complexidade e a interação humana vem cada vez mais risco. Evitar o erro humano pode frequentemente ser mais importante do que evitar a falha mecânica.

Também devemos considerar o custo da recuperação. Se uma falha vier a ocorrer, geralmente é trivial recuperar-se da falha de um sistema simples. Um sistema extremamente complexo, tendo falhado, pode exigir um grande grau de esforço para ser restaurado a uma condição de funcionamento. Sistemas complexos também exigem graus muito mais amplos e profundos de experiência e confiança para serem mantidos.

Não há resposta fácil para determinar a confiabilidade dos sistemas. Os sistemas modernos de entrega de informação são simplesmente grandes e complexos demais, com fatores indetermináveis demais, para poderem ser avaliados em todos os casos. Com uma boa compreensão das dependências encadeadas, no entanto, e uma compreensão das estratégias de mitigação de risco, podemos tomar medidas práticas para determinar níveis de risco aproximadamente relativos, ver como cenários de risco semelhantes se comparam em custo, identificar pontos de fragilidade, reconhecer domínios de falha e correntes de dependência, e compreender como mudanças no projeto do sistema nos moverão claramente em direção à confiabilidade ou para longe dela.