Insights

Notícias, novidades e informações sobre o mundo Hard Tech

Saiba como gerenciar plataformas de missão crítica com as práticas do Google.

por: Inmetrics em

| 10.04.2019

Você já deve ter se perguntado qual é o segredo de empresas como Netflix, Google, Amazon, AWS, AirBnb, para conseguir entregar excelência e qualidade na experiência de usuário dos seus serviços, não é?

Para responder essa pergunta é preciso entender qual é a feature mais importante de um produto. Imagine que você seja usuário do Netflix, e hipoteticamente, alguém te forneça acesso à duas versões diferentes do produto, como mostrado abaixo. Qual deles você prefere?

Netflix do ano de 2016?

 

Netflix 2019, porém com o erro abaixo?

 

Se eu tivesse que apostar, diria que você escolheria o Netflix 2016, não é? Esse pequeno exercício mostra que, para o cliente, a mais importante feature de um produto é que ele funcione. No entanto, não se engane, por mais que esta seja a principal funcionalidade de um produto, é comum as pessoas se esquecerem e só prestarem atenção a ela quando as coisas começarem a falhar.

Antes de entrarmos no tópico em questão, acho importante deixar claro a diferença entre Disponibilidade e Confiabilidade. A primeira trata o tempo que seu serviço está no ar, pronto para atender eventuais requisições. Já a segunda, refere-se a qualidade das interações dos usuários com o seu sistema.

Considerando isso, você pode então concluir que se deve buscar 100% de confiabilidade e disponibilidade, certo? Errado!

Pra quem já estudou um pouco sobre o tema, a tabela abaixo é bem familiar e mostra o tempo que seu serviço pode ficar indisponível dentro do tempo analisado.

Nível de Disponibilidade

 

Se buscamos uma disponibilidade de três 9 (99,9%), por exemplo, dentro de um mês, podemos ficar indisponíveis cerca de 43 minutos. Para cada “9” a mais desejado, existe também um custo exponencial de recursos associados. Esse custo é financeiro ($$$) e também de pessoas.

Por mais que você consiga alcançar esses hipotéticos 100% de disponibilidade, seus usuários não irão sentir essa experiência na totalidade, afinal de contas, quantas vezes você já tentou utilizar um serviço, e seu celular, seu computador ou sua internet não estava funcionando?

As chances são de que, se realmente seu objetivo é alcançar 100% de disponibilidade, você nunca irá lançar novas funcionalidades ou melhorar seu serviço. A tendência diz que seu produto ficará estagnado.

“A busca pela disponibilidade perfeita mata a inovação!”

Experientes CIOs, VPs e donos de produtos críticos entendem o cansaço emocional e prejuízos financeiros resultantes das decisões críticas operacionais. Este dia-a-dia é difícil, cansativo, impreciso e principalmente conflituoso.

É preciso encontrar o equilíbrio certo entre investir em funcionalidades que irão ganhar novos clientes ou manter os atuais, versus investir na confiabilidade e escalabilidade que manterão os mesmos clientes satisfeitos.

 

Mais experimentos x Mais Confiabilidade

 

Agora imagine que esse desafio pode ser resolvido a partir de um problema de matemática? Imagine que você consiga ter uma métrica que consiga alinhar os interesses entre os times de operação, de desenvolvimento e mesmo o time de produtos?

Service Level Objective (SLO) define um objetivo de confiabilidade que um aplicativo precisa atingir para atender às necessidades de seus usuários no negócio. É uma medida do quão bem atendidos estão seus usuários e como seu produto está funcionando corretamente. Alguns exemplos de SLOs são mostrados abaixo:

  • 99,9% do total de requisições HTTP respondem com sucesso
  • 80% do total de requisições HTTP retornam em menos de 700ms
  • 95% das execuções do job crítico ABC da malha batch processa em até 4 horas
  • Disponibilidade de 99,5% (3,6 horas de indisponibilidade)

Idealmente você deve estabelecer objetivos dos quais seus clientes realmente se preocupam, ou melhor, trabalhe com objetivos que estejam diretamente ligados a (boa) experiência do usuário. Por exemplo, você nunca deve utilizar o consumo de CPU como métrica de SLO, mas sim considerar o tempo de sistema que o usuário demora para executar determinada ação.

“SLO é sobre manter seus usuários felizes”

Você pode implementar SLO hoje para sua aplicação, mas isso é apenas a base que permite você a responder à emergências de verdade.

Sendo assim, é preciso avançar mais para encontrar o equilíbrio nas tomadas de decisões. É necessário haver consequência quando não se atinge o SLO alvo, e esta consequência não é no sentido de punição (por exemplo, em achar culpados ou até mesmo financeira), e sim como uma oportunidade para melhorar seu serviço e capacitar sua equipe a se mover o mais rápido possível, sem perder a qualidade.

É aqui que entra o conceito de Error Budget que é, basicamente, a diferença entre a confiabilidade perfeita e o SLO acordado durante um período definido:

Error budget = (1 – SLO)

Portanto, se eu tenho um SLO de 99,9%, há um percentual de 0,1% de error budget. Trazendo para um exemplo mais real, para um serviço que realiza 1B requisições/mês, você tem uma cota de 1M erros/mês.

Implantar o conceito de Error Budget mostra que há uma quantidade pequena, mas não nula, aceitável de falhas. Suas decisões de negócio serão orientadas por dados e com uma métrica que alinha os interesses de todas as tribos envolvidas no negócio e especialmente colocam o cliente (e a experiência de uso dele) no centro.

Adotando a abordagem SLO/Error Budget, é possível resolver boa parte dos conflitos entre novos releases da aplicação e a estabilidade esperada pelos executivos.

Esse método de trabalho foi criado pelo Google, e serve de base para todo framework SRE — Site Reliability Engineering. É uma verdadeira revolução no modo de operar e gerenciar sua operação.

Se quiser entender um pouco mais sobre SRE ou mesmo começar a praticar e implementar a abordagem SLO/Error Budget no seu negócio, converse com a gente.

 

Escrito por: 

Thiago Maciel
Tech specialist Inmetrics