Estratégias para reduzir o Downtime de Sistemas Informáticos

À medida que as empresas e ou organizações dependem cada vez mais de serviços baseados na internet, programadores e administradores de sistemas estão concentrados na criação de infraestrutura confiavéis que minimizem o downtime dispendioso.

Um site, API ou outro serviço que não está disponível poderá ter custos monetários significativos resultantes de vendas perdidas e clientes insatisfeitos. Além disso, o tempo de inatividade pode levar a:

• Clientes e utilizadores insatisfeitos: os utilizadores esperam serviços estáveis. As interrupções podem levar a pedidos de suporte de grande volume e a uma perda geral de confiança na organização/empresa.
• Produtividade perdida: se os funcionários dependem de um serviço para executar o seu trabalho, o downtime significa a perda de produtividade para a organização. Além disso, os empregados estão a despender o seu tempo a reiniciar os servidores e a combater o downtime do serviço, ou seja estão parados sem produzir.
• Empregados insatisfeitos: os alertas de downtime frequentes podem levar a uma maior fadiga por parte de toda a equipa de trabalho, pois estão a lutar para resolver todos os problemas e pode ter um impacto grande sobre toda a equipa psicologicamente.

Um artigo que foi criado para resolver estes problemas é chamado de Site Reliability Engineering ou SRE. O SRE foi criado pela Google a partir do ano de 2003, e as estratégias que eles decidiram implementar foram reunidas num artigo/livro intitulado de Site Reliability Engineering. Ler este artigo é uma boa forma para ajudar a reduzir o downtime nas organizações.

Neste artigo, iremos discutiremos três áreas para melhorar os sistemas informáticos que podem levar a uma redução significativa de downtime nas empresas/organizações.

1. Monitoring and Alerting

A monitorização correta das infraestruturas permitirá monitorizar de uma forma proativa questões iminentes, alertar as equipas de administração sobre certos problemas e investigar de uma forma mais fácil as causas anteriores de downtime. A monitorização envolve a agregação de um registo de estatísticas, como a utilização de recursos do sistema e as métricas do desempenho das aplicações. Os alertas incidem nesta coleção de métricas ao avaliar constantemente as regras dos alertas em relação às métricas atuais estabelecidas para determinar quando é necessário intervir nos sistemas.

A monitorização geralmente é implementada em cada host que reúne métricas e relatórios de desempenho que redireciona para um servidor central. As métricas são armazenadas numa time series database (uma base de dados que se especializa em armazenar e pesquisar dados numéricos) e disponibilizados para gráficos, pesquisas e alertas. Alguns exemplos de software de monitorização são:

• Prometheus pode tirar dados de uma grande variedade de clientes oficiais e apoiados pela comunidade (chamados de os exportadores ). É altamente escalável, possui alertas integrados e possui bibliotecas disponíveis para a maioria das linguagens de programação.
• A grafite fornece uma API agora omnipresente que é suportada por dezenas de linguagens e aplicações de programação. As métricas são enviadas para os nós com destino á instalação central do Grafite, onde são guardadas e representadas graficamente.

Também é comum enviar arquivos de log para um servidor central e analisá-los para obter informações relevantes, como exceções e taxas de erro. A Elastic Stack (Elasticsearch, Logstash, Kibana) e Graylog são exemplos de software stacks que podem facilitar a análise de arquivos de log.

Quais as métricas para monitorizar

Quais são as métricas mais úteis a serem recolhidas para tentar aumentar a fiabilidade e reduzir o tempo de inatividade dos sistemas?

A maioria dos clientes de monitorização terá um conjunto de métricas por defeito que serão um bom ponto de partida, mas a aplicação ou serviço terá necessidades exclusivas e o SysAdmin poderá considerar ao decidir quais as medidas a serem exportadas para análise. Felizmente, o artigo SRE tem algumas diretrizes gerais onde explicam quais são as métricas mais úteis para usar na monitorização. Essas métricas são agrupadas nos chamados Os Quatro Sinais de Ouro, resumidos aqui no artigo SRE :

• Latency: quanto tempo leva para responder a um pedido. Por exemplo, o tempo de resposta de um servidor para uma solicitação do protocolo HTTP.
• Traffic: o quanto sobrecarregado está o sistema actualmente. Esta poderia ser a taxa de solicitações para um servidor web, logins por segundo ou transações por segundo para uma base de dados.
• Errors: a taxa de falhas de transações ou pedidos. É preciso ter em mente que nem todos os erros são tão claros quanto um erro HTTP 500. Por exemplo, pode existir uma politica onde os clientes recebam as respostas em 500ms ou menos . Qualquer resposta com maior latency deve aparecer como um erro neste caso.
• Saturation: o quanto um serviço se encontra “cheio”. Isto poderia ser medido por exemplo, pelo espaço disponível num HDD, a taxa de transferência de rede ou mesmo qual a percentagem de CPU que está disponível num serviço vinculado ao mesmo.

Verificando as métricas

Depois de configurado o sistema de monitorização, é necessário visualizar os dados que estão a ser recolhidos. Grafana é um pacote de software que oferece uma análise flexível de métricas através de gráficos e painéis interativos. As visualizações podem ser agregadas a partir de várias fontes de dados do backend, incluindo Grafite, Prometheus e Elasticsearch.

Configurando os Alertas

Além da visualização das métricas,  também será necessário configurar de alguma forma de alertar automaticamente a equipa de administração de sistemas para quando surgirem problemas seja mais fácil e rápido efetuar alguma acção. Grafana possui capacidades de alerta, assim como o Prometheus através do componente Alertmanager . Outros pacotes de software que permitem definir regras relativos aos alertas são : Nagios e Sensu .

A forma como é estruturado o sistema de alertas dependerá muito da organização alvo. Se existir várias equipas de administração de sistemas, os alertas podem ser encaminhados diretamente para a equipa responsável pelo serviço em causa. Ou poderá existir um tipo de rotação onde se irá lidar com todos os alertas por um período de tempo específico . Os alertas podem ser enviados por e-mail, push notifications ou um serviço de paginação de terceiros.

É importante referir que o objetivo deve ser alertar o mínimo possível, e apenas para eventos em que a equipa de administração pode efetuar medidas imediatas para resolver o problema. Muitos alertas, ou alertas para situações que não são realmente corrigíveis por parte da equipa de IT.

O artigo SRE resume alguns princípios a ter em mente ao configurar os alertas :

• Every time the pager goes off, I should be able to react with a sense of urgency. I can only react with a sense of urgency a few times a day before I become fatigued.
• Every page should be actionable.
• Every page response should require intelligence. If a page merely merits a robotic response, it shouldn’t be a page.
• Pages should be about a novel problem or an event that hasn’t been seen before.

Se o alerta não respeitar estes critérios , então é melhor enviá-los para o ticketing system de baixa prioridade , ou para um arquivo de logs, ou então remover o alerta definitivamente.

2. Improving Software Deployments

Outra área que pode ter um grande impacto no tempo de inatividade dos sistemas é a estratégia de deployments de software. Se o processo de deployment requer várias etapas manuais para a sua conclusão ou, de outra forma, é excessivamente complicado, o ambiente de produção provavelmente ficará para trás do ambiente de desenvolvimento. Isto pode levar a lançamentos de software mais arriscados, uma vez que cada deployment se torna num conjunto muito maior de alterações com complicações de potencial elevado. Isto, por sua vez, leva a erros, retarda a velocidade de desenvolvimento e pode resultar no deployment involuntário de serviços degradados ou indisponíveis.

É provável que se demore algum tempo o planeamento para suavizar os deployments, mas, no final, ao criar-se uma estratégia que permita automatizar o fluxo de trabalho de integração, teste e deployments de código, leva a que um ambiente de produção combine com o desenvolvimento .

 CI / CD – Melhores Práticas

É importante seguir as boas práticas de continuous integration (CI) continuous delivery (CD) . Algumas dessa boas práticas são:

• Apenas um repositório: todos os utilizadores devem alojar o código regularmente no mesmo repositório, o que deve conter tudo o que for necessário (incluindo testes e arquivos de configuração) para criar o projeto numa máquina relativamente limpa(sem nenhuma alteração) ou num ambiente CI. Isto garante que todos possam trabalhar numa base de código similar, as integrações são relativamente indolentes, e todos podem testar e desenvolver as suas alterações com bastante facilidade.
• Automatizar Testes e Desenvolvimento: o software ou serviço CI deve ser capaz de executar testes e criar o seu projeto automaticamente.
• Automatize o Deployment: o software CI deve ser capaz de implementar e testar uma compilação num ambiente de testes que seja parecido ao ambiente de produção final.

Estas práticas descrevem um continuos integration and delivery system .

Blue-Green Deployments

Um blue-green deployment envolve a criação de dois ambientes de produção idênticos por trás de um mecanismo que pode facilmente alternar o tráfego entre os dois. Este mecanismo pode ser um endereço floating IP que pode ser alternado rapidamente entre um green or blue server ou um load balancer para alternar entre clusters inteiros de vários servidores.

Em qualquer momento, apenas um dos ambientes – digamos o blue server neste caso – é ativado e recebe o tráfego de produção. O processo para o lançamento de uma nova versão é:

• Colocar toda a compilação para um ambiente inativo (green server, para este exemplo).
• Testar a parte de compilação neste ambiente de produção.
• Se todos os testes forem aprovados, reduz-se o tráfego para o green server atualizando a configuração do load balancer ou atribuindo um floating IP ao green server.

Esta técnica tem o benefício adicional de fornecer um mecanismo simples para reverter para uma versão anterior, caso no decorrer do processo aconteça algum problema. Manter as versões anteriores guardadas para caso seja necessário repor , ou até que a versão final esteja nas melhores condições. Se for necessário reverter este estado, atualiza-se novamente o load balancer ou o floating IP para retomar ao estado anterior.

Mais uma vez, existem várias maneiras de alcançar o objetivo de automatização dos processos de deployment de uma forma segura e tolerante a falhas.

3. Implementing High Availability

Para finalizar, uma estratégia para minimizar o tempo de inatividade é aplicar o conceito de High Availability à infra-estrutura alvo. O termo High Availability encapsula alguns princípios de concepção de sistemas redundantes e resilientes. Estes sistemas normalmente devem ter:

• Eliminate Single Points of Failure: geralmente isto significa servidores múltiplos redundantes ou containerized services. Também está em consideração a possibilidade de espalhar a infraestrutura entre vários datacenters nas mais variadas regiões. O quão profundo se irá para eliminar esses bottlenecks  irá variar dependendo da tolerância ao custo e complexidade desta operação, e as necessidades da organização alvo. Nem todos os serviços irão necessitar de load balancers redundantes e failover automático entre locais, por exemplo.
• Seamlessly Redirect Traffic: para minimizar o tempo de inatividade, o corte no tráfego entre os servidores deve ser bastante rápido, com interrupção mínima no serviço.
• Detect the Health of the Redundant Systems: para proceder á informação de uma decisão para quando redirecionar o tráfego, o próprio sistema deve poder determinar quando um serviço está em falha e a trespassar problemas.

Atualizar Servidores Web com um Load Balancer

Um exemplo de atualização para uma infraestrutura altamente disponível passaria de um único servidor web para vários servidores da Web e um load balancer. O load balancer  irá executar as health checks regularmente nos servidores o Web e irá encaminhar o tráfego para fora daqueles que estão a a apresentar problemas. Essa infraestrutura também poderá permitir deployments de código mais contínuas, conforme discutido na seção anterior.

Aumento da Database Resilience

Outro exemplo de adicionar resiliência e redundância é a replicação de bases de dados. O servidor de base de dados MySQL, por exemplo, tem várias configurações de replicação diferentes. A replicação de grupo é interessante, pois permite operações de leitura e escrita num cluster de servidores redundantes. Em vez de ter todos os  dados num único servidor, vulnerável ao downtime, pode-se replicar entre vários servidores. O MySQL irá detectar automaticamente estes servidores com falhas e irá rotear o problema em causa.

As base de dados mais recentes, como o CockroachDB, estão a ser criadas desde o início com estes recursos de replicação redundante como primeiro foco, permitindo o acesso á base de dados com High Availability em várias máquinas e em vários datacenters.

Utilizando Floating IP’s e um Hot Spare Server

Por último , temos um exemplo de arquitetura de High Availability utilizando um floating IP para cancelar o tráfego de um Hot Spare Server . Muitos provedores de soluções na cloud possuem endereços IP especiais que podem ser rapidamente reatribuídos a diferentes servidores ou load balancers usando uma API. Um Hot Spare é um servidor redundante que está sempre pronto para ser ativado, mas não recebe  nehum tráfego até que o servidor primário falhe numa health check. Neste ponto, o IP flutuante é reatribuído ao Hot Spare e o tráfego segue o seu caminho pré estabelecido. Para implementar estas health checks e as chamadas aos floating IPs da API , é necessário instalar e configurar alguns softwares adicionais, tais como a keepalived ou o heartbeat .

Conclusão

Neste artigo, analisámos três áreas em que é possível implementar melhorias nos processos ou infraestrutura que podem levar uma redução do downtime, mais vendas e uma quantidate superior de utilizadores felizes e satisfeitos. Monitorizar métricas, melhorar os deployments e aumentar a disponibilidade das infraestruturas são bons locais para começar a investir nas mudanças que se podem implementar para tornar as aplicações ou serviços preparados para produção/comercialização e resiliência.

Estes 3 pontos são apenas alguns dos parâmetros que se pode melhorar/implementar no dia a dia de um SysAdmin. Para mais detalhes aconselhamos a leitura do livro : The Practice of System and Network Administration.