5 etapas para melhorar a disponibilidade do seu aplicativo
Manter seu aplicativo em funcionamento é essencial para as organizações modernas. Siga estas etapas para reduzir o risco de tempo de inatividade que afeta o cliente.
Na terça-feira, 8 de junho de 2021, houve uma grande indisponibilidade de internet que derrubou um número significativo de sites e aplicativos. Como muitas dessas interrupções, esta foi causada por um reprodutor da web relativamente pequeno, Fastly. Fornece rapidamente serviços de nuvem e cache local para a maior parte da Internet. Quando caiu, o impacto foi sentido em toda a internet.
Conforme seu aplicativo é dimensionado, ele também se torna mais complexo. Mais escala e mais complexidade significam maior risco de um problema que pode afetar a disponibilidade.
Uma empresa de monitoramento bem conhecida sofreu sérios problemas de disponibilidade enquanto estava crescendo de uma empresa de pequeno para médio porte. Seu tráfego estava aumentando dramaticamente e a infraestrutura não conseguia acompanhar. Pior ainda, ele nem sempre sabia quando estava tendo um problema e certamente não sabia quando esperar os problemas.
Como você evita problemas de disponibilidade em seu aplicativo? Como você amadurece seu aplicativo à medida que escala para poder atender à crescente demanda de seus clientes?
Não é fácil.
Melhorar a disponibilidade não é escrever o código correto. Melhorar a disponibilidade de aplicativos é muito mais sobre como melhorar os processos operacionais, procedimentos e cultura de sua organização, a fim de incutir as práticas necessárias para manter a disponibilidade.
Existem cinco etapas envolvidas que todas as empresas podem realizar para melhorar a disponibilidade de seus aplicativos e reduzir o risco de um problema operacional.
Etapa 1. Conheça seus riscos
Muitas pessoas não percebem quanto risco é inerente a seus aplicativos. Muito desse risco está na forma de dívida técnica no código, mas parte dele é baseado em decisões conhecidas que foram feitas sobre como o sistema deve operar, o que implica resultados que são desconhecidos.
Donald Rumsfeld, o ex-secretário de Estado dos Estados Unidos, disse a famosa frase de que existem “conhecidos conhecidos” e há “desconhecidos conhecidos”, mas que os problemas com os quais devemos nos preocupar são os “desconhecidos desconhecidos” – os problemas que não temos sabe que não sabemos sobre.
A gestão de riscos consiste em remover o desconhecido e torná-lo conhecido. No caso de aplicativos modernos, o gerenciamento de risco consiste em identificar áreas de preocupação, rotulá-las, quantificá-las e priorizá-las. Em seguida, abordar os riscos que têm o maior impacto para o nosso negócio.
Para fazer isso, cada equipe de desenvolvimento para cada serviço em seu aplicativo deve criar e manter uma matriz de risco. Uma matriz de risco é uma planilha que contém uma lista de tantos problemas e possíveis problemas quanto possível. É um brainstorm de todos com interesse no serviço qualitativo para identificar o maior número de riscos possível. Então, para cada risco, são atribuídos dois números:
- Uma gravidade, que especifica o quão sério seria um problema para o nosso negócio se esse risco acontecesse;
- Uma probabilidade, que especifica a probabilidade de ocorrência do risco.
Um risco pode ter uma gravidade alta, mas uma probabilidade baixa, o que significa que não é provável que aconteça, mas se acontecer, o impacto seria significativo. Pode ter uma probabilidade alta, mas uma gravidade baixa, o que significa que o risco é mais provável de ocorrer, mas não será problema sério.
Os riscos mais preocupantes são aqueles de alta probabilidade e alta gravidade. Eles representam problemas muito sérios para o nosso negócio e podem acontecer. Esses são os riscos de maior impacto.
A matriz de risco fornece um modelo para cada equipe priorizar sua carga de trabalho operacional para entender o que é importante e o que não é. Feito de forma correta e consistente, ele pode ser usado para priorizar riscos entre as equipes e permitir que o gerenciamento aloque recursos para os maiores problemas.
As matrizes de risco dão visibilidade e priorização à dívida técnica e problemas pendentes. Eles são uma ótima ferramenta de comunicação entre equipes de desenvolvimento e gerenciamento.
O uso eficaz de matrizes de risco ajudará a reduzir os problemas de disponibilidade em seu aplicativo.
Etapa 2. Observe seu software
Entender o que seu software e sua infraestrutura operacional estão fazendo a qualquer momento é fundamental para manter a alta disponibilidade. A análise de aplicativos e infraestrutura pode fornecer uma visão sobre o desempenho de seu aplicativo, permitindo que você ajuste e otimize seu ambiente operacional, detecte e resolva problemas operacionais em tempo real e entenda quem está usando seu software e como eles o estão usando.
A configuração corretamente e a análise podem fornecer indicações precoces de problemas de disponibilidade pendentes, permitindo que você corrija um aplicativo ou problema operacional antes que se torne um problema de disponibilidade.
Existem muitos sistemas e serviços gratuitos e pagos que fornecem métricas e análises de aplicativos e infraestrutura. Todos eles têm vantagens e desvantagens. Os sistemas gratuitos são valiosos para aqueles que desejam construir e manter seus próprios sistemas e até mesmo personalizá-los para atender às suas necessidades específicas. Os sistemas pagos podem oferecer uma experiência mais prática, mas geralmente exigem um investimento financeiro significativo. Os sistemas pagos mais modernos oferecem até mesmo sistemas de IA que analisam o desempenho do seu aplicativo para você e fornecem indicadores antecipados de problemas que você pode nem notar entre a profundidade de dados disponíveis.
Um sistema completo para analisar seu software oferece a capacidade de:
- Monitore seu sistema continuamente para saber como está funcionando.
- Examine as mudanças no desempenho das implantações, para ver se uma implantação pode ter introduzido um problema ou para verificar se um problema foi resolvido.
- Informa você por meio de notificações quando anomalias de vários tamanhos ou formas são detectadas, permitindo que você analise dados mais detalhados para determinar o que pode ter dado errado.
- Auxiliar na resolução de um incidente em andamento, usando dados que podem ajudar a entender por que um problema específico está ocorrendo.
A análise também é uma ótima maneira de monitorar os acordos de nível de serviço (SLAs). Isso inclui SLAs públicos (aqueles visíveis para clientes) e SLAs internos (aqueles que descrevem compromissos entre os serviços internos). Analytics são uma ótima ferramenta para comunicação de equipes.
Etapa 3. Reduza seu débito técnico
Assim que tiver a análise em vigor e tiver identificado seu débito técnico e outros problemas por meio de sua matriz de risco e outras ferramentas, você precisa avaliar e reduzir seus problemas de maior impacto. Saber quais são os seus problemas é ótimo, mas não ajuda se você não trabalhar para reduzi-los.
Se você tiver um risco de alta gravidade e alta probabilidade em sua matriz que está gerando problemas de disponibilidade, ele deve ser corrigido. Mas consertar isso não significa necessariamente reescrever para remover o risco. Você pode resolver o problema de disponibilidade reduzindo a gravidade ou a probabilidade do risco.
Em outras palavras, se você não puder remover facilmente uma situação que está causando problemas, faça com que o problema aconteça com menos frequência – para que não seja uma fonte de preocupação frequente – ou reduza o impacto do problema quando ele ocorrer, reduzindo a gravidade. De qualquer forma, o resultado final é que o problema não é mais o principal fator. Ainda pode ser um risco reconhecido, mas a frequência reduzida ou impacto reduzido o torna uma preocupação crítica.
Ter um foco regular na dívida técnica ajuda a manter a disponibilidade em linha. Mas tome cuidado para não buscar a perfeição. Seu objetivo nunca deve ser eliminar todos os débitos técnicos e, portanto, eliminar todos os riscos. A menos que você esteja construindo o software de controle para um avião, foguete ou sistema semelhante, você precisa equilibrar o esforço com o impacto do problema. Focar na redução excessiva da dívida técnica pode indicar que você está gastando muito tempo focando no “aperfeiçoamento” do software ao custo de alguma outra oportunidade de negócio.
Etapa 4. Automatize a recuperação tanto quanto possível
Quando ocorre um incidente, o tempo que leva para se recuperar pode ter um grande impacto na disponibilidade geral do aplicativo. É importante se recuperar rapidamente. Também é importante diagnosticar corretamente o problema e tomar medidas para garantir que ele não ocorra novamente.
Quando ocorre um incidente de disponibilidade, a resposta geralmente envolve as seguintes etapas:
- Você percebe que está ocorrendo um problema (ou você detecta o problema ou um cliente relata o problema);
- Você analisa o que está causando o problema;
- Você implementa uma correção para reduzir ou eliminar o problema;
- Você implementa uma correção permanente, se necessário;
- Você faz uma autópsia do episódio.
Essa mesma sequência de eventos ocorre sempre que há um evento. O problema é que esse processo leva tempo. O tempo entre o momento em que o problema ocorre, ou quando é notado pela primeira vez, e quando uma correção é implementada para remover o problema, é chamado de tempo médio de reparo (MTTR). Quanto mais longo for o MTTR, menor será a disponibilidade. Como os humanos estão envolvidos no diagnóstico e na correção do problema, seu MTTR pode ser bastante longo, afetando a satisfação do cliente.
No entanto, às vezes você está ciente de certos tipos de problemas que podem ocorrer e o processo para corrigi-los pode ser silencioso e automatizado. Ao automatizar o reparo desses tipos de problemas, você pode melhorar drasticamente seu MTTR.
Um exemplo clássico de reparo automatizado é quando uma instância de computador fica offline. Isso pode acontecer devido a um problema de software, um problema de rede ou outra causa. Mas o software de monitoramento pode detectar quando a instância para de responder e a instância pode ser reinicializada imediatamente. Ou, na nuvem, a instância pode ser encerrada e substituída por uma nova instância. Isso pode ocorrer automaticamente. Como um ser humano não precisa estar envolvido, seu MTTR para essa classe de problema pode ser reduzido, o que pode melhorar consideravelmente sua disponibilidade.
Etapa 5. Tente quebrar as coisas regularmente
A melhor maneira de manter seu aplicativo funcionando é tentar interrompê-lo regularmente.
Sim, está certo. Você me ouviu corretamente.
Os operadores dos maiores aplicativos do mundo testam regularmente sua resiliência a problemas tentando interromper seu aplicativo regularmente.
A ideia é esta: Seu software irá falhar. Mas você quer que ele falhe no meio da noite ou em um momento crítico do ponto de vista operacional? Ou você prefere que ele falhe em um momento mais oportuno, com seus engenheiros observando e prontos para detectar e corrigir o problema mais rapidamente?
Em ambos os casos, você ganha uma experiência valiosa sobre como seu aplicativo funciona. No primeiro caso, você fornece uma experiência ruim e um dano potencialmente duradouro para seus clientes enquanto tenta descobrir o que há de errado com o aplicativo. No segundo caso, você sabe o que causou o problema (você o causou) e pode corrigi-lo rapidamente. Seu aprendizado é o mesmo, mas os custos das aulas são muito menores.
Existem duas maneiras comuns de realizar este teste de operação de produção. O primeiro é chamado de dias de jogo. Os dias de jogo são horários programados em que você injeta falhas específicas em sua infraestrutura operacional, a fim de ver como o problema se manifesta e com que rapidez você pode detectar e corrigir o problema. Um cenário comum de teste em um dia de jogo, por exemplo, é desativar um data center inteiro para ver se seu aplicativo pode fazer ¹failover para um data center de backup.
¹Failover em computação significa tolerância a falhas. Quando um sistema, servidor ou outro componente de hardware ou software fica indisponível, um componente secundário assume sem que haja interrupção nos serviços.
O segundo método comum de teste de operação de produção é chamado de teste de caos. O teste de caos envolve a operação de um sistema de software que, de forma aleatória e imprevisível, quebra partes do seu sistema regularmente. Isso pode envolver travar um servidor, quebrar um link de rede ou colocar um balanceador de carga offline. O teste de caos é uma ótima maneira de testar mecanismos de recuperação automatizados e provar a segurança e eficácia de seus processos de recuperação.
Em qualquer um dos casos, o objetivo é identificar problemas de maneira controlada, aprender com os erros e melhorar a qualidade de seu aplicativo para poder se auto-reparar dessas falhas. Os objetivos duplos de ambas as abordagens são melhorar sua confiabilidade operacional e melhorar a disponibilidade de seus aplicativos.
Melhore os processos, melhore a disponibilidade
Melhorar a disponibilidade do aplicativo não significa buscar a perfeição ou eliminar todos os riscos. É muito mais sobre como melhorar seus processos operacionais: trabalhar para reduzir a gravidade e a probabilidade de problemas, monitorar de perto os aplicativos e a infraestrutura, manter o débito técnico sob controle, automatizar os mecanismos de recuperação e testar regularmente esses mecanismos de recuperação. Siga estas etapas e a disponibilidade de seu aplicativo será significativamente melhorada, seus clientes ficarão mais felizes e esses clientes mais felizes significarão mais negócios para sua empresa.
