Como um gestor de TI deve se preparar para enfrentar falhas e interrupções: lições do caso Google 26/10
A minha ideia aqui é tirar lições úteis do acontecido. Não estou falando em "escolher melhor um provedor de serviços" ou "cuidados com os serviços em nuvem". Usar este caso para falar a favor ou contra essas estratégias seria tendencioso, pois a verdade é que falhas podem ocorrer (e ocorrerão) em qualquer serviço de qualquer modalidade que você escolher.
Entendendo o que estava por trás do problema.
O Google tem uma política de transparência muito maior do que a maioria das empresas do mercado, isso é bom porque ajuda a criar confiança, porém - como era de se esperar - essa transparência tem seu limite. Eles divulgaram alguns detalhes interessantes do problema e, mais interessante ainda, dos efeitos colaterais. Esses efeitos colaterais causaram problemas que atrasaram a recuperação dos serviços.
Pelas informações fornecidas pelo Google o problema começou quando eles tiveram uma falha no sistema de balanceamento de carga. Os serviços de qualquer provedor são atendidos por uma enorme quantidade de servidores, então as requisições geradas pelos usuários precisam ser distribuídas entre esses servidores. Então antes dos servidores existe uma camada de roteadores/balanceadores que decidem para onde será enviada a requisição. Quando esse sistema de balanceamento falhou no Google, os serviços começaram a parar, até ai nenhuma grande surpresa.
Os engenheiros do Google atuaram rapidamente para resolver esse problema, porém durante o período de paralisação as requisições foram se acumulando. Desde empresas tentando realizar negócios B2B até adolescentes tentando compartilhar fotos, milhões e milhões de usuários ficaram tentando repetidamente executar suas tarefas e eles se acumularam com passar do tempo. Quando o serviço de balanceamento retornou, houve um pico de tráfego que afogou os servidores quando eles voltaram a ser acessíveis, isso causou o travamento desses servidores e o ciclo vicioso se repetiu (mais tempo parado, mais acumulo de requisições). A solução foi cortar temporariamente o tráfego vindo da Internet e, lentamente, retornar esse tráfego, dando vazão gradual as requisições e eliminando a carga acumulada, um processo demorado e que exigiu intervenção humana.
Lições para um gestor de TI
Se você é um gestor de TI, seguramente deve se preocupar com os procedimentos de contingência. Porém na maior das vezes as estratégias criadas para essas situações são mais teóricas do que práticas, ou seja, é muito difícil testar essas estratégias na prática. Mesmo quando se faz uma parada programada para testar os procedimentos, em geral se faz fora do horário de pico.
Quando o problema ocorrer de verdade, ele pode ocorrer em qualquer horário (na verdade, por Murphy, ocorrerá sempre no horário de pico). Se a estratégia de recuperação não for bem pensada, podemos ter a recuperação do acesso ao serviço, porém a demanda reprimida durante o tempo de parada pode - como aconteceu com o Google - causar uma nova parada do serviço, dessa vez por sobrecarga.
Dessa forma uma estratégia de recuperação deveria levar em conta também o seguintes:
- Recuperar o serviço, mesmo que parcialmente, o mais rápido possível. É verdade que está regra vale de qualquer maneira, independentemente de se estar preocupado ou não com a demanda reprimida, porém a possibilidade de uma inundação de requisições é mais um fator que deve motivar o investimento em uma estratégia de recuperação rápida - mesmo que parcial.
- Verificar o capacidade dos servidores. O que ocorre se os servidores ficarem sobrecarregados? O serviço fica apenas lentos? O servidor trava? Ou pior, ocorre risco de corromper algum arquivo ou banco de dados que cause ainda mais problemas?
- Ter o poder de dosar o tráfego. Os roteadores ou switches possuem recursos de controle de banda ou ACLs que possam ser usados para limitar o tráfego que possa afogar os servidores? A equipe técnica de plantão sabe usar? Existe documentação e treinamento suficientes para que esses recursos sejam usados?
- Quem será o responsável por decidir limitar esse tráfego? Essa é uma decisão difícil, mas que talvez precise ser tomada em uma emergência. Quem vai responder por essa decisão? E se essa decisão for tomada de maneira inapropriada? Quem assume a responsabilidade?
Moral da história: um plano de contingência tem que ser mais do que simplesmente pensar em rotas e redundâncias, também deve levar em conta as consequências de um pico de tráfego causado pelo eventual represamento das requisições.
Comentários