Quais são os erros mais comuns ao iniciar com SRE na sua organização

Site Reliability Engineering ou SRE é uma contribuição relevante do gigante Google sobre como a área de TI pode tornar sua operação mais eficiente com foco na confiabilidade e disponibilidade de seus sistemas mais críticos e de maior retorno ao negócio. A principal premissa da prática é de que a funcionalidade mais importante de seu sistema sempre será a confiabilidade, afinal se seus clientes não tiverem uma boa experiência com os serviços que você oferece, eles não poderão tirar o melhor proveito dos recursos que foram implementados com tanto esforço pela equipe de engenharia e, normalmente, esse cenário evolui para a perda de confiança e respeito de sua base de clientes, trazendo consequências desastrosas para o negócio e riscos de perda de relevância no mercado. Por outro lado, a falha em alguns momentos é inevitável em sistemas complexos, com origem em mudanças que introduzem bugs, configurações incorretas ou pela complexidade da arquitetura de sistemas distribuídos que depende da comunicação entre vários componentes físicos e lógicos, aumentando as chances de latência e falhas de rede.

Em um mercado altamente competitivo, a área de TI precisa lidar com uma constante pressão em apresentar novas funcionalidades para impulsionar a aquisição de novos usuários e, como consequência, o aumento de sua receita. Equilibrar isso com a necessidade de manter um sistema estável e confiável é um grande desafio. O SRE apresenta os SLOs — Service Level Objectives — e o Error Budget como poderosas ferramentas para equilibrar essa relação. Elas ajudam as áreas de negócio e TI a entender quando priorizar as atividades com foco na confiabilidade do sistema em relação ao lançamento de novas funcionalidades.

Um exemplo rápido de SLO para um serviço de distribuição de vídeos seria a composição de SLIs — Service Level Indicators — para garantir que uma determinada API responsável por retornar um catálogo de vídeos responda 98% das requisições HTTP com status 200 (OK) e 95% das requisições com um tempo de resposta abaixo de 200ms em um intervalo de 1 mês. O Error Budget ou orçamento para erros informa o quanto é permitido que um sistema esteja não confiável em determinado período de tempo. Se o SLO diz que 98% das requisições HTTP devem ser respondidas com status 200 (OK) em 1 mês, seu Error Budget permite que 2% das requisições sejam respondidas com falhas neste mesmo período. Se você não possui mais budget, você precisa executar ações imediatas para trazer de volta a confiabilidade no seu sistema e garantir a melhor experiência dos usuários.

Entendido os conceitos de SLI, SLO e Error Budget, voltamos ao tema principal que são os erros mais comuns ao implementar o SRE sem seguir premissas importantes da prática:

SLOs de 100% de disponibilidade

Um SLO bem definido para garantir a satisfação de seus clientes deve considerar que 100% de disponibilidade é um objetivo praticamente impossível mesmo que você evite qualquer mudança no seu sistema e que sua infraestrutura possua redundância em várias camadas e mecanismos de recuperação automática. A possibilidade de um ou mais componentes falharem simultaneamente existe, resultando em uma disponibilidade < 100%.

Error Budget precisa ser medido e possuir consequências se esgotado

Normalmente a especificação e implementação das métricas SLIs requer bastante conhecimento sobre como seu cliente interage com o seu sistema, quais são as atividades comuns e críticas, assim como pontos da arquitetura que podem influenciar sobre a qualidade da experiência dos usuários. Porém, ao vencer essa etapa de preparação desses indicadores, é necessário fazer a composição com os SLOs e Error Budget, entendendo que esse último é um acordo formal que envolve diversas áreas da empresa, desde a equipe técnica, stakeholders e, em alguns casos, os executivos para deixar transparente o quanto de risco é aceito assumir com mudanças no sistema, eliminando stress e pressão por desalinhamento de expectativas. Políticas de violação de SLOs e esgotamento de budget precisam ser definidas, documentadas e aprovadas, sendo comum o congelamento do lançamento de novas features, o planejamento do sprint considerar somente ações mapeadas com origem de Postmortem sobre incidentes e o time de desenvolvimento submeter novas releases para revisão do time SRE antes de subida para produção.

SLIs de baixa qualidade

As melhores métricas de SLIs são aquelas que permitem a melhor leitura sobre a felicidade dos usuários com nosso serviço. É preciso avaliar a experiência do usuário o mais diretamente possível. Assumimos que, quando essa experiência é ruim o suficiente, não estamos atendendo às expectativas de nossos usuários quanto à confiabilidade do serviço e, portanto, eles não estão satisfeitos com o nosso serviço. Métricas de sistema como utilização de CPU, uso de memória ou banda de rede são normalmente representadas em gráficos visíveis nos painéis de monitoramento. Alguns tendem a usar essas métricas ao implementar SLIs porque alterações costumam estar associadas a interrupções do serviço. Mas não é uma boa ideia. Na perspectiva de seus usuários, eles não enxergam as CPUs topadas em 100% de utilização de máquinas virtuais ou containers com natureza efêmera e sim experimentam degradação do tempo de resposta até a total indisponibilidade do serviço.

Para serviços que usam HTTP como canal de troca de informações com os usuários a indicação é usar a estratégia dos quatro sinais de ouro:

• Latência mostra quanto tempo a transação levou para ser processada;
• Tráfego mostra a quantidade de requisições que o sistema atendeu em uma faixa de tempo;
• Erros mostram o percentual de erros de processamento das requisições em uma faixa de tempo;
• Saturação mostra a quantidade de recursos computacionais disponíveis até o início de degradação do sistema.

Se o usuário depende que dados sejam processados, provavelmente terá expectativas de que o processamento seja concluído dentro de um prazo razoável e que todos os dados sejam processados sem erros:

• Freshness mostra a proporção de dados que foram atualizados em uma faixa de tempo. Essa métrica conta quantas vezes um usuário acessou os dados, para refletir com mais precisão a experiência do usuário;
• Correctness mostra a proporção de registros que entraram no pipeline e que resultaram em saídas com valores aceitáveis.

Finalmente, se o usuário fornece dados para persistência e que posteriormente possam recuperar esses dados novamente:

• Durabilidade mostra a proporção de registros gravados que podem ser lidos com sucesso. SLIs de durabilidade requer atenção pois os dados que o usuário deseja podem ser apenas uma pequena parte dos dados que estão armazenados. Por exemplo, se você possui 1 milhão de registros de 5 anos anteriores, mas o usuário deseja apenas os registros de hoje e que não estão disponíveis por alguma falha, eles ficarão descontentes, mesmo que quase todos os dados sejam legíveis e recuperáveis.