Um sistema na internet tem que estar no ar o tempo todo. Ele precisa estar acessível em qualquer horário do dia e da noite. Nós, como usuários, não cogitamos qualquer outra opção. Do outro lado, de quem desenvolve, manter um software no ar sem falhas é uma tarefa bem difícil, praticamente impossível.
Desenvolver software é uma atividade complexa. O desafio começa antes de qualquer criação de código. As regras precisam ser definidas com a visão do que o software deverá fazer. Todas as regras devem estar claras e precisam ser codificadas com precisão. Um software gera erro ou não funciona direito se uma regra for mal definida ou mal codificada. Os mínimos detalhes podem afetar o comportamento do software. É como uma equação matemática, se trocar um sinal ou um simples algarismo, o resultado é outro.
Diversos métodos foram criados para ajudar a desenvolver um software. Há métodos que ajudam a melhor entender as regras para construir um software, outros são focados em como desenvolver, em como codificar. Há métodos ágeis e outros com bastante detalhes e inúmeras etapas. Todos eles visam ajudar a transformar uma ideia em algo concreto, com a máxima exatidão.
Um software precisa ser testado para garantir que cada regra tenha sido codificada corretamente. Existem softwares para testarem outros softwares. Há equipes ou até mesmo empresas próprias focadas apenas em testar softwares. Eles validam cada regra. Simulam o uso esperado e usos não esperados para cada função. Testam até mesmo se o software consegue aguentar o acesso de vários usuários ao mesmo tempo.
Situações inesperadas, mas, obviamente, pensadas de antemão, podem ser planejadas com medidas alternativas. Em caso de uma falha no software ou computador principal, por exemplo, um software alternativo ou outro computador pode ser usado. Até diferentes provedores de internet podem ser usados caso algum falhe.
Contudo, ainda assim, um software pode falhar, ou não ficar disponível. Pode ser uma falha no seu próprio código ou pode ser uma falha em outros softwares de que ele depende. Pode haver falha por que um banco de dados gerou uma inconsistência, o sistema operacional travou, um arquivo corrompeu. Pode, também, haver falha no computador ou nos equipamentos que ligam o computador à internet. Há muitas camadas de hardware e software que podem gerar alguma falha.
Se já sabemos que um software poderá falhar mesmo com planos alternativos, o que podemos fazer então?
Pois é, enfrentamos essa dúvida no início da Knewin. Vários dos nossos clientes usavam os sistemas principalmente durante a madrugada. Os sistemas precisavam funcionar sem falhas 24 horas por dia, de segunda a segunda. Durante o dia nós monitorávamos os sistemas, olhando gráficos e analisando os arquivos de logs (informações que descrevem qualquer anormalidade em um software). O problema era durante à noite e nos finais de semana.
Em algumas situações fomos acordados por clientes no meio da noite nos avisando que havia problema em algum sistema. Uma situação bem desagradável para o cliente e para nós também. E, para piorar, o tempo de resolução podia não ser tão rápido, pois ainda tínhamos que identificar onde estava o problema para, então, resolver. Dez ou quinze minutos para um sistema fora do ar na internet é muito tempo.
A solução foi criarmos um sistema de vigilância, também chamado de sistema de monitoramento, que disparasse alarmes. Esse sistema, chamado Sentinela, monitorava nossos outros sistemas — aqueles que não podiam falhar de jeito nenhum. Em caso de qualquer falha o Sentinela nos enviava um alarme.
Os tipos de falhas eram os mais diversos possíveis, desde algum erro no código até falhas no acesso à internet. Definimos a importância de cada falha e o respectivo tipo de alarme. Se uma falha fosse pequena, como um erro momentâneo, o Sentinela nos enviava apenas um e-mail de alerta. Caso a falha fosse grande, o Sentinela também enviava uma mensagem SMS para nossos celulares. Assim, éramos avisados durante dia e noite, de segunda à segunda.
Percebemos, também, que vários problemas podiam ser antecipados e, portanto, resolvidos antes de falhar. Com isso, conseguíamos prever algumas falhas com mais de uma hora de antecedência. Por exemplo, o Sentinela extraía algumas estatísticas das notícias capturadas com base no histórico e nos enviava um alarme se notasse alguma variação no volume de coleta.
Há casos em que o Sentinela também resolvia o problema por conta própria. Em algumas situações, ele identificava que algo falhou ou iria falhar e sabia o que fazer para corrigir. Um computador na cloud, por exemplo, que apresentava alguma instabilidade podia ser trocado automaticamente por outro computador sem qualquer intervenção nossa ou percepção dos clientes.
Os sistemas também tiverem que ser mudados, para que pudessem ser monitorados. Isso foi um desafio, pois o Sentinela tinha que ficar em um computador separado e ao mesmo tempo precisava testar funções de cada sistema que, inicialmente, não eram acessíveis por computadores externos. Essa separação era condição para que o Sentinela fizesse vários tipos de testes como, por exemplo, verificar se o acesso à internet estava funcionando e se as funções estavam respondendo com rapidez.
Os sistemas também tiverem que ser mudados, para que pudessem ser monitorados. Isso foi um desafio, pois o Sentinela tinha que ficar em um computador separado e ao mesmo tempo precisava testar funções de cada sistema que, inicialmente, não eram acessíveis por computadores externos. Essa separação era condição para que o Sentinela fizesse vários tipos de testes como, por exemplo, verificar se o acesso à internet estava funcionando e se as funções estavam respondendo com rapidez.
Cada nova função a ser codificada nos sistemas passava por uma análise nossa e, se fizesse sentido, a função era monitorada pelo Sentinela. Uma das regras era bem simples: uma função deveria ser integrada ao Sentinela se houvesse risco dos clientes serem afetados enquanto estivessem usando o sistema. Definimos várias outras regras que foram evoluindo com o tempo.
A criação do Sentinela nos impactou de várias formas. Temos mais tranquilidade uma vez que se houver um problema em algum dos nossos sistemas seremos avisados. Os sistemas ficaram mais estáveis por que passamos a resolver a causa de cada falha — melhoria contínua. A equipe técnica adquiriu a disciplina de analisar cada alarme e tomar ações mais estruturadas com casos ainda não monitorados. As novas funções críticas já são integradas ao Sentinela ainda na fase de construção.
Hoje, também usamos outros sistemas de vigilância além do Sentinela. A nuvem, onde hospedamos nossas aplicações, nos permite monitorar falhas na infraestrutura (i.e., computadores e acesso à internet). Temos, também, um sistema de terceiro, chamado Zabix, que usamos para falhas genéricas. Criamos inúmeros alarmes para centenas de cenários.
O próximo passo é tornar o Sentinela mais autônomo. Com inteligência artificial iremos identificar, com mais antecedência, se uma falha poderá ocorrer ao se analisar todos os passos de cada função. Ao se deparar com um problema, ele conseguirá resolve-lo com total autonomia. E vamos além, ele poderá nos indicar o que fazer para resolver a causa de um problema — um software precisa evoluir sempre.
O fato de termos entendido que um software pode falhar nos permitiu olhar a situação por ângulos diferentes. A criação do Sentinela foi uma solução criativa e inteligente que possibilitou reduzir o impacto das falhas em nossos softwares. A qualidade e confiança dos nossos sistemas melhorou muito com o uso dessa solução. Nossa equipe técnica desenvolveu atitudes mais pró-ativas quanto às falhas e reforçou a disciplina para melhorar sempre.
Nós temos que garantir nossos sistemas no ar o tempo todo. Os clientes são beneficiados assim como nós mesmos, na Knewin. Nos sentimos mais seguros e tranquilos ao saber que alarmes podem disparar em casos atípicos. Todavia, nosso objetivo é termos cada vez menos alarmes disparados — a busca pela perfeição é contínua.
Ah, também temos alarme para o Sentinela.
Novas postagens no endereço fbeppler.com.