A Essência da Engenharia de Confiabilidade

Princípios de confiabilidade de Software

Se você nunca ouviu falar de SRE ou Site Reliability Engineering, foi o termo criado por Benjamin Treynor, atual vice-presidente do Google, quando o mesmo era Engenheiro de Software em 2003 e precisou gerenciar uma equipe de operações, foi nessa ocasião em que teve a idéia de aplicar conceitos de Engenharia de Software no seu dia-a-dia.

Com uma missão de descobrir maneiras de proteger, fornecer e melhorar as aplicações para que as mesmas fossem escaláveis, confiáveis e eficientes, foram criados os princípios de SRE, o que com o sucesso da proposta acabou criando uma profissão que vem ganhando cada vez mais espaço no mercado mundial e brasileiro, tornando-se cada vez mais comum a divulgação de vagas.

Esperança não é uma estratégia

Durante meus primeiros anos com desenvolvimento de software não me orgulho de dizer que alguns códigos que escrevi foram para um ambiente produtivo com o mínimo de cuidado e cruzando os dedos na esperança de nada errado acontecer durante a implantação.

Esse “medo” é simplesmente o reflexo da falta de confiança na aplicação desenvolvida, por mais que o famoso “na minha maquina funciona” seja um meio de se esquivar de alguns desenvolvedores, quando utilizamos princípios de SRE percebemos que o software desde seu fundamento, nos passa maior segurança, nos estimulando em confiar mais em testes, CI e alertas e que se tudo dar errado vamos ser os primeiros a saber e não nosso cliente nos ligando as 3h da manhã reclamando que algo que fizemos não esta dando o retorno esperado.

Hierarquia da Confiabilidade de Serviço

Os Engenheiros de Confiabilidade(SREs) rodam serviços e são responsáveis por manter um software saudável e isso engloba uma ampla gama de atividades e ferramentas para suprir uma necessidade de controle.

Essas necessidades podem ser comparadas a necessidade humana categorizada na pirâmide de Abraham Maslow, em que se olharmos da base, vamos do mais básico até o mais avançado princípio para tornar um software realmente confiável.

Monitoramento

O primeiro procedimento é simplesmente visualizar sua aplicação como ela é, e para isso é extremamente importante em um primeiro momento definir seus Níveis de Serviço de maneira que você consiga encaixar e metrificar a sua aplicação corretamente.

Sem um bom monitoramento você não tem meios de saber se seu serviço esta funcionando, é como voar com os olhos vendados, talvez todos os usuários estejam usando o seu produto, talvez não, por isso monitorar sua aplicação é extremamente importante no caminho de ter confiabilidade de seu software é como se as saídas válidas de sua aplicação, seja ela um alerta, ticket ou log, fossem sua matéria prima para tomada de decisões no futuro.

Se você não sabe por onde começar a monitorar você pode começar pelos The Four Golden Signals (Os quatro sinais de ouro), que são latência, tráfego, erros e saturação com esses sinais você já consegue ter um bom começo.

Tendo o mínimo de monitoramento você pode focar em seus níveis de serviço, estes que vão definir qual os comportamentos esperados ou não de sua aplicação.

SLI

Service Level Indicator ou Nível Indicador de Serviço é o primeiro passo na definição de níveis de serviços para softwares resilientes, o SLI nada mais é do que o átomo do monitoramento ou a unidade básica de todos os níveis de serviço.

O mesmo é algo quantitativo e palpável, um valor que pode ser coletado por diversas ferramentas como Prometheus, Newrelic, Cloudwatch ou Datadog e que dão uma visão para a área de engenharia de indicadores como latência, CPU, memória, disco, rede etc.

Um SLI pode ser uma métricas de negócio previamente definida pelo time, por exemplo, a quantidade de pedidos gerados em um E-commerce, vendas efetivadas, quantidade de acessos em um site, o ponto é observar que os indicadores coletados tem de de ser mensuráveis.

SLO

Service Level Objective ou nível de objetivo de serviço é uma meta que você coloca para seu software com base nos indicadores coletados, o SLO pode ter uma visão técnica como o percentil de requests que falham em um sistema, a disponibilidade de uma API, a media de seu tempo de resposta ou saturação ou a nível de negócio por exemplo uma meta de venda ou média de quantidade de pedidos feitos por um hora.

Quando você configura um SLO para seu software é recomendado que quando qualquer dos limites de SLO fixados são extrapolados, dispare um gatilho para que algo aconteça, afinal monitoramento não é cinema, esse gatilho pode ser um autoscale em sua aplicação ou resultar em uma promoção de determinado produto para trazer suas vendas de volta a meta, ou uma maneira de acordar o desenvolvedor para resolver um processo crítico, o importante é traçar os objetivos de forma responsável e de acordo com sua realidade, se você tem uma API pouco utilizada e traça um plano de 20000 rpm isso não é ser prudente é ter desperdício de recurso.

SLA

O SLA ou Acordo de nível de serviço não é algo comum de ser definido por desenvolvedores, pois o mesmo pode implicar em punições para a empresa que disponibiliza um serviço. Um SLA disparado quando vc ultrapassa um SLO crítico, como disponibilidade do serviço, se no seu contrato é de X% de disponibilidade e você quebra essa regra, pode ser que você tenha punições como multas ou processos judiciais.

Muitos desenvolvedores tem dificuldade de diferenciar um SLO de um SLA, uma maneira interessante é respondendo uma pergunta muito simples “o que acontece se os SLO não forem atendidos?”, se a resposta não for nada catastrófico, você quebrou um SLO e não SLA.

Falhas acontecem

Nem o mais prudente engenheiro de software do planeta esta a salvo das falhas sistêmicas, e por mais importante que seja o esforço para evita-las, é necessário estar preparado para quando os problemas acontecerem, e eles vão acontecer e o importante nesse momento é manter a calma, se você tem o mínimo de monitoramento para que você seja avisado por um SLO quebrado, ótimo, se você foi acionado por seu chefe, até ai tudo bem, mas tente evitar o máximo possível ser avisado por seu cliente/usuário pois isso mexe diretamente com a confiança que ele tem do seu produto e confiança não é algo barato de se conseguir.

Mas acontece, independente de como você ficou sabendo, a falha aconteceu e você tem que colocar a faca entre os dentes e partir pra cima, lembre-se que o ideal nesse momento não é ser o herói, resolva o problema, coloque a aplicação de pé novamente, seja uma solução bonita ou não, escale mais maquinas, realize o lindo e famoso update/delete na base, mas faça tudo para não deixar seu cliente na ponta com um experiência ruim, lembre-se que ele pode estar realizando uma compra.

Nesse passo não é hora de analisar o por que parou, a causa raiz vem depois, e caso você não se sinta confortável com a situação envolva mais pessoas ao problema, divida as responsabilidades, enquanto um faz a alteração o outro facilita a comunicação com a área, o outro pede a pizza, enfim, mova montanhas para resolver a dor de dente de seu cliente independente da beleza da ação.

Postmortem

Conheci alguns desenvolvedores que não estão acostumados a documentar as grandes falhas (ou quase nada) de sua própria aplicação, talvez por orgulho, ou por não achar necessário e útil, princípio de escrever Postmortens do SRE não prega ser vergonhoso ou desonroso se escrever a respeito de um bug que você mesmo criou, nosso software pode ter parado pela linha de código implementada por você ou não ou a alteração na base de dados feita minutos antes, o ensinamento aqui é o famoso aprender com seus erros, e o ato de documentar friamente o que aconteceu é muito mais benéfico por sua prevenção para que aquilo não aconteça novamente e muito menos do que pela vergonha de colocar seu erro em evidência afinal o custo do fracasso é a educação.

Uma grama de prevenção vale por um quilo de cura

Se você não testou seu software, pressupomos que vc tem uma falha escondida nele, afinal uma das maneiras de medirmos a confiabilidade de um software é através do indicador de cobertura de testes do seu código, é comum traçarmos um objetivo/meta de cobertura para um código entre 90~95% mas não deixe isso te assustar, a idéia é garantir a resiliência com testes de qualidade e não deixar esse número bonito.

O código escrito por um desenvolvedor passar por um teste não quer dizer muito sobre confiabilidade, mas um teste apresenta falhas geralmente sim. Existe diversos tipos de testes, testes de unidade, testes de integração, teste sistêmico ou produção, o foco desse post não é esmerilhar sobre eles, mas sim precavê-los da importância de ter um sistema bem testado.

Esteja pronto

Tradicionalmente toda empresa deveria estar ciente da complexidade de suas aplicações, se você testa, estressa, monitora e esta preparado para o que der e vier parabéns, mas conheça as particularidades do seu software, capacidade e limitações do mesmo, lembre-se de atualizar seus níveis de serviço de acordo com o crescimento orgânico da sua ferramenta, por exemplo trace um plano de autoscale para possíveis aumentos repentinos de acessos de seu site, seja um lançamento de uma nova funcionalidade ou uma grande promoção, esteja preparado para esse crescimento, afinal você não precisa ter um grande servidor o ano inteiro por causa de grande liquidação no final do ano, evite o desperdício de recurso e dinheiro.

Planejar a capacidade de seu software vai além de CPU e memória, afinal o crescimento orgânico de sua equipe não deve estar diretamente ligado com o crescimento inorgânico de seu serviço, o legal é esse crescimento de time ser linear e o do seu software ser exponencial, isso exige um árduo e contínuo trabalho de automação de tarefas, processos e ferramentas que diminuem a ineficiência no dia-a-dia da equipe.

Ter um pipeline de desenvolvimento que abstraia seus operacionais tornando tanto seu software quanto sua equipe escalável junto com um planejamento de capacidade consciente é um princípio importante para evitar dor de cabeça no futuro.

Lançouuuu

O lançamento de uma versão, seja para um novo produto ou funcionalidade é um momento de extrema tensão para qualquer empresa, afinal é nesse momento que meses de esforços são colocados a prova, estar preparado para isso, é um dos princípios do SRE, e uma opção simples de manter a calma nesse momento é ter orquestrado um bom plano/checklist de lançamento, um plano que seja solido e que possa possa responder se aquela release está em condições de subir para produção seguindo algumas diretivas como:

• Arquitetura
• Servidores
• Performance
• Plano de Rollback
• Monitoramento
• Segurança
• Automação
• Questões de crescimento

Com esses itens, seu deploy fica mais tranquilo e sua equipe tem o software mais na mão evitando certos problemas em um momento tão crítico.

Conclusão

O SRE esta se tornando uma área muito interessante no atual ambiente de desenvolvimento de software, mesmo carregando muitas skills de um DevOps percebo que o objetivo do SRE é muito mais nobre, onde você pode olhar para seus problemas como bugs e traçar planos para se ter uma alta disponibilidade e perfomance sem ter de se descabelar por isso, afinal se seus sistemas ficarem mais autônomos sobra mais tempo para uma cervejinha :)