Neste artigo continuarei abordando os conceitos de gerenciamento de operações de serviços aplicado pelo Google. Ainda dentro do capítulo 3 – Embracing Risk, do livro Site Reliability Engineering, escreverei acerca do conceito de Error Budget, ou Orçamento de Erro.
Em outros artigos já citamos que tradicionalmente times de desenvolvimento e de operações possuem objetivos conflitantes. Enquanto o desempenho dos times de desenvolvimento é medido com base na velocidade de inovação e quanto de código novo é enviado para produção, o desempenho do time operacional é avaliado com base na disponibilidade e confiabilidade do serviço, o que implica em evitar alterações em um ambiente já estável. Considerando também que o perfil destes profissionais é diferente, não é difícil de perceber que eles terão visões diferentes, como por exemplo:
O quão rígido deve ser o serviço para eventos inesperados? Tão pouco a ponto de o sistema não parar em pé ou tão rígido que teremos um produto defasado, com poucas funcionalidades e que ninguém queira usá-lo?
Optamos por fazer o mínimo de testes e correr o risco de indisponibilidades e vazamento de dados ou gastaremos tanto tempo fazendo testes que perderemos o time to market?
Toda atualização gera riscos operacionais. Qual deve ser nosso empenho na redução desse risco?
Canary é um conceito de deploy de software onde uma nova versão do sistema é disponibilizada apenas para poucos usuários e, gradativamente, aumenta-se a quantidade de usuários até que todos estejam acessando a nova versão. Neste caso podem surgir os conflitos entre os times quando se pensa na quantidade de usuários que serão usados para o teste e por quanto tempo deve-se esperar para avançar com o deploy.
Em equipes tradicionais de desenvolvimento e operações, geralmente existe um consenso para equilibrar esforço versus riscos. O problema é que não existe um método para a decisão e, portanto, não é possível afirmar que a decisão correta é a mais adequada para a confiabilidade do serviço.
Times de SRE definem uma métrica clara e objetiva, em acordo com ambos os times, que possa ser usada para orientar as decisões de forma metódica e reproduzível, baseada em informações. Não existe achismo.
Para definir esta métrica, times de Produtos e SRE se reunem para definir em conjunto um orçamento de erro trimestral com base no objetivo de nível de serviço (SLO). Este orçamento de erro é uma métrica clara e objetiva que determina quanto tempo dentro desses 3 meses o serviço poderá ficar indisponível (ou não-confiável).
Essa métrica, definida previamente e em conjunto acaba com o stress da politicagem e de negociações entre times de desenvolvimento e operações para definir qual o nível de risco que se deve assumir em uma atualização do serviço.
No caso do google, o time de gerenciamento do produto define o SLO para o serviço, que é quanto tempo de de disponibilidade o serviço pode ter no trimestre.
O sistema de monitoramento é responsável por medir de forma fiel e imparcial essa disponibilidade.
A diferença entre o SLO estabelecido e a disponibilidade real do serviço é o orçamento de erro que ainda falta ser gasto no trimestre.
Enquanto o tempo de disponibilidade do serviço, que é medido pela ferramenta de monitoramento, estiver maior que o SLO, então é possível continuar fazendo atualizações no ambiente em produção.
Para exemplificar, digamos que o serviço Gmail tenha um SLO que permita uma indisponibilidade de até 4 horas no trimestre. Se, após 1 mês houve apenas 2 horas de indisponibilidade, então o time de produtos, juntamente com o time de SRE ainda pode continuar aplicando atualizações no serviço desde que não extrapole as 4 horas dentro do trimestre. Porém, se logo no primeiro mês houve mais do que 4 horas de indisponibilidade, então o serviço entrará em freeze até o final do trimestre, não podendo sofrer alterações que coloquem em risco sua confiabilidade.
O principal benefício é o alinhamento de objetivos entre os times de produtos e de SRE, para que encontrem o equilíbrio adequado entre inovação e confiabilidade.
Este equilíbrio pode ser visto quando, por exemplo, o time de desenvolvimento de produtos opta por reduzir o tempo gasto na etapa de testes para aumentar a velocidade de entrega de código novo em produção. Enquanto o orçamento de erro está alto, então eles podem optar por se arriscarem mais e acelerar a inovação. Porém, quando o orçamento já está baixo, próximo a estourar, os próprios desenvolvedores serão bem mais cautelosos, se policiando para fazerem mais testes e mandar atualizações para produção com menor frequência.
Tanto o time de produtos quanto o time de SRE são responsáveis pelo orçamento de erro, portanto uma falha ocasionada por problemas na infraestrutura impactará neste indicador e afetará o roadmap de entregas de todo o trimestre.