A Engenharia do Site Confiável – Parte 1

Introdução

Nesta série de 4 artigos, quero mostrar com criar um site confiável, um que você possa dormir a noite sem preocupações ou que não te faça pensar se ele está travando muito depois que você deixou ele lá no seu ex-emprego.

Exisitem metodologias prontas para isso, como a chamada DevOPs ou a Site Reliability Engineering – SRE, do Google. Obstante a implementá-las ou dizer que elas não funcionam, só tenho a certeza de que

Talvez quando você pense em ter um sistema confiável, à prova de falhas, logo te venha a mente coisas como Testes Unitários ou Testes Integrados, QA, e tudo mais do que está na moda na tão badalada cultura DevOps, certo?

Porém, é verdade que muitas vezes, mesmo com esteira CI/CD toda implementada, às vezes mesmo assim não nos sentimos seguros em relação ao funcionamento confiável do nosso sistema, e isso não é por acaso. Na verdade você sabe lá no fundo que sempre vai faltar um teste, ou o cara do QA vai deixar passar algo, e quando você menos esperar um problema ocorrerá no funcionamento do seu sistema.

E o DevOps não ajuda? Ajuda… Mas não garante tanto a confiabilidade pois é focado na integração entre entre Dev e Ops, tendo como resultado final a entrega contínua, já o SRE foca justamente em manter sistemas escaláveis e confiáveis.

SLO, um passo antes do SRE

Para implementar uma solução de SRE precisamos definir primeiro os Service Level Objectives (SLOs), ou Objetivo de Nível de Serviço em português. Ok, agora temos uma nova sigla, mas então o que é SLO e porque o SRE precisa dele?

O SLO é um documento que define a qualidade e o desempenho que um serviço deve ter, como um compromisso de nível de serviço, com o cliente, ou seja, o SLO define o que é aceitável para o usuário em termos de qualidade do serviço, para então o SRE ter um guia para agir.

Afinal, como vamos criar nossos esforços com SRE sem saber onde devemos chegar ou o que queremos alcançar? 

Coisas como: “Garantimos o tempo de disponibilidade da aplicação em 99,97% do mês” ou “As respostas do BD devem ter tempo de resposta máximo de 500ms” são objetivos que são definidos pelos SLOs.

SREs usam SLOs para entender se uma métrica foi alcançada, e usam isso para:

• Detectar problemas
• Tomar decisões (lançar uma nova versão ou fazer um rollback)
• Priorizar tarefas de engenharia de software 

Se ainda não está claro, SRE é a engenharia para manter serviços confiáveis e o SLO são os objetivos de qualidade do serviço que o SRE deve obdecer.

Por fim, vale ressaltar que para além de manter seu software confiável, o SRE deve usar o SLO para priorizar tarefas que estejam violando mais a SLO, assim se você tem dois problemas, você pode ver qual está violando uma SLO (ou qual está violando mais) e resolvê-lo primeiro.

Por que SRE?

Este tópico é útil para responder ao seu chefe, quando ele perguntar quais vantagens implementar o SRE traria para os negócios. E resposta é a seguinte:

• Extinguir ou reduzir tempo de indisponibilidade da aplicação, evitando desgastes para a empresa
• Ajudar em oferer uma boa expêriencia ao cliente, oferencendo uma aplicação estável
• Melhorar a efeciência da equipe de tecnologia, automatizando tarefas operacionais, deixando assim os profissionais com mais tempo livre para atender demandas de negócio
• Preservar uma boa reputação para a aplicação da empresa, através do seu bom funcionamento, evitando perda de clientes
• Redução de custos a longo prazo alcançado através de menor indisponibilidade da aplicação e maior tempo disponível para atender o negócio.

4 pontos a serem observados pelo SRE:

Os 4 pontos principais ou como alguns preferem os 4 “golden signals” (pontos de ouro em português),  para o SRE observar são: Latência, Tráfego, Erros e Saturação. Vamos ver um resumo de cada ponto a seguir.

Latência:

Mede o tempo que aplicação, leva para responder uma solicitação, verificando se o tempo de retorno é considerado aceitável. Pode ser checado aqui desde o ping para o servidor, até o tempo de resposta de uma requisição para uma API, o retorno de uma query para o BD, ou mesmo o tempo de carregamento do front-end web.

Tráfego:

Indica a quantidade de solicitações que o sistema está recebendo, como já dito, o intuito é verificar se os valores são considerados aceitáveis, de acordo com o estabelecido.

Erros:

Mede o número de solicitações que não foram processadas com sucesso. 

Saturação:

Indica o nível de utilização dos recursos do sistema, como CPU e memória.