Por Dave Rensin com Betsy Beyer, Niall Richard Murphy e Liz Fong-Jones
Já se passaram 14 anos desde que começamos a praticar SRE no Google. Alguns dos desenvolvimentos nesse período parecem óbvios em retrospecto, enquanto outros foram algo chocantes. Os últimos dois anos desde a publicação do nosso primeiro livro sobre SRE têm sido especialmente interessantes. O número de empresas que agora praticam a disciplina de SRE e o tempo que passamos discutindo sobre isso em conferências e com clientes cresceu além do que poderíamos imaginar anteriormente.
Essa mudança em particular — a rápida expansão do ecossistema fora do Google em torno do SRE — é o desenvolvimento mais empolgante, mas também torna mais difícil prever o futuro da profissão de SRE. Ainda assim, em nosso próprio trabalho de SRE no Google, estamos começando a observar algumas tendências que podem informar um esboço do futuro da profissão. Este capítulo representa nosso esforço para compartilhar o que nós, junto com nossos colegas de SRE ao redor do mundo, temos visto e concluído até agora.
Verdades que consideramos evidentes
A única maneira de fazer algum sentido útil do futuro é começar com um conjunto de princípios e avançar a partir deles. Algumas das coisas que se seguem devem ser incontestáveis. Outras, nem tanto. Em todos os casos, no entanto, esses princípios são baseados em coisas reais que estamos vendo no mundo.
A confiabilidade é a característica mais importante
As pessoas geralmente não discordam muito de nós quando afirmamos que “a confiabilidade é a característica mais importante de qualquer sistema” — desde que nos certifiquemos de destacar que “confiabilidade” muitas vezes abrange uma ampla área.
O argumento é simples:
- Se um sistema não é confiável, os usuários não confiarão nele.
- Se os usuários não confiam em um sistema, quando têm escolha, eles não o usarão.
- Como todos os sistemas de software são governados por efeitos de rede, se um sistema não tem usuários, não vale nada.
- Você é o que você mede, então escolha suas métricas com cuidado.
Seus usuários, não seu monitoramento, determinam sua confiabilidade
Como o valor de um sistema está relacionado aos seus usuários, é razoável concluir que a única medida de confiabilidade que importa é como seus usuários experimentam essa confiabilidade. Se um usuário está preocupado que sua plataforma seja responsável pela instabilidade que estão enfrentando, dizer a eles “nosso monitoramento parece bem; o problema deve estar do seu lado” não os deixará menos irritados. Eles estão experimentando seu sistema como instável, e é isso que lembrarão quando chegar a hora de escolher entre você e seu concorrente. (Esse fenômeno é conhecido como a regra do pico-final.)
Seu monitoramento, logs e alertas são valiosos apenas na medida em que ajudam você a detectar problemas antes que seus clientes o façam.
Se você gerencia uma plataforma, a confiabilidade se torna uma parceria
Se a única forma de alguém usar seu sistema é através de uma interface visual do usuário (por exemplo, uma página web) e seu sistema é consumido apenas por seres humanos reais (ao contrário de máquinas), então a confiabilidade que seus usuários experimentam está quase exclusivamente ligada ao trabalho que você realiza como SRE para manter seu sistema saudável.
No entanto, uma vez que você adiciona uma API e alguns de seus “usuários” são na verdade outras máquinas, você está gerenciando uma plataforma e as regras mudam.
Quando seu produto atua como uma plataforma, a confiabilidade que seus usuários experimentam não se limita às escolhas que você faz. A confiabilidade se torna uma parceria. Se seus usuários constroem ou operam um sistema em sua plataforma que nunca alcança mais do que 99% de disponibilidade — mesmo que você esteja executando sua plataforma com 99.999% de disponibilidade — então a experiência ideal deles será de 98.99901%.
As escolhas que esses usuários fazem afetam diretamente a experiência que eles têm e associam ao seu serviço. Você pode não gostar, mas eles vão responsabilizá-lo pelo que experimentarem — mesmo que não seja “culpa sua”.
Tudo que é importante acaba se tornando uma plataforma
Como o valor do seu sistema aumenta com o número de pessoas que o usam, você vai querer encontrar maneiras de alcançar outros grandes pools de usuários estabelecidas. À medida que você atrai mais usuários, outros sistemas de software também vão querer alcançar seu público.
É aí que outras empresas começam a fazer suas máquinas conversarem com as suas via APIs. Se seu sistema é remotamente popular, a integração se torna um passo inevitável em sua evolução.
Mesmo que você decida que não se importa com outras comunidades de usuários e opte por nunca criar uma API consumível por máquinas, ainda assim não conseguirá evitar esse futuro. Outras pessoas simplesmente envolverão sua interface de usuário em uma API de máquina e a consumirão. A única diferença é que você não terá controle sobre o resultado.
Assim que seu sistema se torna um gateway para uma grande coleção de usuários, ele se torna valioso. APIs — oficiais ou não oficiais — serão parte do seu futuro.
Quando seus clientes enfrentam dificuldades, você precisa diminuir o ritmo
Quando seus clientes enfrentam dificuldades, a frustração deles se transforma em atrito para você. Mesmo que você não tenha os modos tradicionais de suporte (tickets de problema, e-mail, telefone, etc.), ainda assim você gastará tempo triando perguntas e respondendo a reclamações via StackOverflow, ou até mesmo Twitter, Facebook e outras plataformas sociais.
Qualquer energia que você investir em ajudar os usuários durante momentos difíceis é energia que não pode ser investida no avanço do seu sistema. Já vimos muitas equipes (e empresas) permitirem que seu tempo seja lentamente absorvido por problemas de suporte ao cliente — deixando um orçamento de inovação cada vez mais reduzido. Essas equipes são consumidas pelo trabalho árduo.
Uma vez nesse estado, é difícil sair dele (ver Capítulo 6). Um plano melhor é antecipar o trabalho árduo iminente. Você pode estar lendo isso e pensando: “Bem, estou em uma equipe interna de plataforma. Isso não se aplica a mim!“
Lamentamos informar que isso se aplica duplamente a você! No seu caso, seus clientes são os consumidores do seu sistema dentro da sua empresa.
Isso nos leva à próxima conclusão.
Você precisará praticar SRE com seus clientes
Se você quer que seus clientes projetem e operem sistemas confiáveis usando sua plataforma, você precisa ensiná-los a fazer isso. Sim, isso inclui seus clientes internos também. Só porque você trabalha em uma equipe de plataforma interna não significa que você escape dessa dinâmica — na verdade, é mais provável que você encontre isso primeiro.
Mesmo que você consiga destilar perfeitamente essas informações em formas escaláveis de um-para-muitos (livros, posts de blog, diagramas de arquitetura, vídeos, etc.), você ainda precisa descobrir que conteúdo e treinamento incluir. À medida que você cresce e melhora sua plataforma, essas lições vão mudar. Você sempre precisará de uma maneira de manter esses recursos atualizados.
A melhor maneira de aprender essas lições é “fazer SRE” com seus clientes.
Isso não necessariamente significa que você precisa assumir os pagers dos sistemas dos seus clientes, mas você precisa realizar a maior parte do trabalho que normalmente leva à transferência do pager (ou seja, o sistema atingiu certos requisitos mínimos de confiabilidade viável), com pelo menos uma amostra representativa dos seus usuários.
Como fazer: SRE com seus clientes
A ideia de percorrer uma jornada de SRE com seus clientes pode parecer um pouco assustadora. Provavelmente você está lendo este livro porque não tem certeza de como percorrê-la você mesmo! Não se preocupe. É possível fazer ambos ao mesmo tempo. Na verdade, o primeiro pode ajudar a acelerar o segundo.
Aqui estão os passos que gostamos de seguir. Eles funcionam muito bem para nós e achamos que serão úteis para você também.
Passo 1: SLOs e SLIs são a forma como você se comunica
Você quer que seus clientes percebam seu sistema como confiável. Caso contrário, corre o risco de perdê-los. Portanto, é razoável se preocupar muito com como eles formam essas opiniões. O que eles medem? Como eles medem? Mais importante ainda, que promessas eles estão fazendo aos seus clientes?
Sua vida será muito melhor se seus clientes medirem SLIs e alertarem sobre SLOs, e se compartilharem essas medições com você. Caso contrário, você gastará muita energia em conversas como esta:
Cliente: A chamada de API X normalmente leva o tempo T, mas agora está levando o tempo U. Acho que vocês têm um problema. Por favor, verifiquem e me retornem imediatamente.
Você: Essa performance parece estar dentro do que esperamos, e tudo parece bem do nosso lado. É um problema se a chamada de API X levar esse tempo?
Cliente: Eu não sei. Normalmente não leva tanto tempo, então claramente algo mudou e estamos preocupados com isso.
Essa conversa vai girar em círculos e nunca chegar a uma resposta satisfatória. Você vai acabar gastando muito tempo tentando convencer seu cliente de que eles não deveriam se preocupar, ou investigando a causa raiz da mudança para então convencer seu cliente de que eles não deveriam se preocupar. Em ambos os casos, você está gastando muito esforço que poderia estar usando em outro lugar.
A causa raiz desse problema é que o cliente não está usando SLOs para determinar se deve se preocupar com o desempenho que estão vendo. Eles apenas notam uma mudança inesperada e decidem se preocupar com isso. Lembre-se, na ausência de um SLO declarado, seu cliente inevitavelmente vai inventar um e não vai contar para você até que você não o atenda! Você preferiria ter uma conversa como esta:
Cliente: Estamos ultrapassando rapidamente nosso SLO para a aplicação FOO e a aplicação está em risco. Os SLIs X e Y parecem ter caído drasticamente. Ambos dependem da sua API X.
Você: Certo. Deixe-me verificar como a API X está se comportando em nosso sistema e/ou como está se comportando especificamente para você.
Essa é uma conversa muito mais produtiva porque (a) ela ocorrerá apenas quando o SLO estiver ameaçado, e (b) ela se baseia em métricas mutuamente compreendidas (SLIs) e metas (SLOs).
Se você está operando seus sistemas usando práticas de SRE, então você está falando SLOs internamente. Sua vida será melhor e seus clientes ficarão mais felizes se eles também estiverem falando SLOs, porque facilita a comunicação entre vocês dois.
Recomendamos um exercício simples para melhorar significativamente seu relacionamento de trabalho com um cliente: sente-se com seu cliente. Explique SLOs, SLIs e orçamentos de erros — e especialmente como você os prática em suas equipes. Em seguida, ajude-os a descrever as aplicações críticas que eles construíram em sua plataforma nesses termos.
Passo 2: auditar o monitoramento e construir painéis compartilhados
Depois que seus clientes escolherem alguns SLOs básicos para sua aplicação, a próxima questão é se estão medindo as coisas certas para determinar se estão alcançando esses objetivos ou não. Você deve ajudá-los a descobrir se as medições que estão usando são apropriadas.
Em nossa experiência, até metade das coisas que seu cliente está medindo (e alertando) não têm impacto algum em seus SLOs. Sua vida será melhor quando você apontar isso para eles e eles desativarem os alertas ineficazes. Isso significará menos páginas para eles e para você!
As medições restantes são candidatas úteis para SLIs. Ajude seu cliente a reunir essas medições para calcular seus SLOs.
Quando você começar este exercício, rapidamente descobrirá que partes dos SLOs não estão cobertas — não há medições relevantes para dizer algo útil sobre essas dimensões. Você deve ajudar seu cliente a cobrir essas partes de seus SLOs também.
Agora, seus clientes podem começar a avaliar o desempenho do SLO de sua aplicação em sua plataforma.
Por último, construa um conjunto de painéis compartilhados de SLO com seu cliente. Você deve ser capaz de ver os SLOs de aplicação deles, e você deve compartilhar qualquer informação que tenha relevância para como eles estão experimentando o desempenho do seu sistema. Seu objetivo é que sempre que seu cliente entrar em contato porque seu SLO parece ameaçado, você não precise trocar muitas informações adicionais. Toda essa informação deve estar no monitoramento compartilhado.
Passo 3: medir e renegociar
Depois de organizar as medições, você deve coletar dados por um mês ou dois. Esteja preparado para a possibilidade de que seu cliente possa ter uma surpresa desagradável. A aplicação que eles pensavam estar operando com “cinco noves” (99,999%; todo mundo acha que está alcançando cinco noves) provavelmente está alcançando apenas de 99,5% a 99,9% quando medida contra seus novos SLOs reluzentes.
Depois que o choque inicial passar, este é um ótimo momento para apontar que os usuários deles não estão reclamando o tempo todo, então provavelmente nunca precisaram dos cinco noves que na verdade não estavam alcançando.
A pergunta chave é: quão satisfeitos estão os usuários deles com o desempenho da aplicação? Se os usuários estiverem satisfeitos, e não houver evidências de que melhorar o desempenho ou a disponibilidade aumentará a adoção/retenção/usuário, então você está feito. Você deve periodicamente se perguntar esta questão para garantir que seus orçamentos e prioridades ainda estejam corretos. (Veja o Capítulo 2 para uma abordagem mais detalhada deste tópico.)
Se o cliente ainda achar que precisa melhorar um pouco mais, passe para o próximo passo.
Passo 4: revisões de design e análise de riscos
Sente-se com seu cliente e realmente entenda como a aplicação deles é projetada e operada. Eles têm algum ponto único de falha oculto (SPOF)? Os lançamentos e reversões são manuais? Basicamente, conduza o mesmo exercício que você realiza para suas próprias aplicações internas.
Em seguida, classifique os problemas que você encontrar pelo quanto cada item consome do orçamento de erros deles. Preste atenção em quais itens seu cliente escolhe resolver para “recuperar os noves” que desejam (por exemplo, passar de 99,5% para 99,9%).
O que você aprender com essas revisões irá dizer:
- Como seus clientes consomem sua plataforma
- Quais erros de confiabilidade eles cometem ao fazer isso
- Quais trade-offs eles escolhem ao tentar melhorar
Este exercício também ajudará seu cliente a estabelecer expectativas realistas em torno da confiabilidade que devem experimentar com sua aplicação atual. Suas expectativas afetarão suas percepções, então configurá-las adequadamente só pode ajudar a conquistar e manter sua confiança.
Passo 5: pratique, pratique, pratique
O último passo é criar rigor operacional com seu cliente. Pratique problemas simulados (exercícios do “Wheel of Misfortune”, testes de desastre e recuperação, dias de jogos de papel, etc.).
Desenvolva uma memória muscular saudável entre as equipes para maneiras eficazes de se comunicar durante uma crise. É uma ótima maneira de construir confiança, reduzir o MTTR (Mean Time to Recovery) e aprender sobre casos estranhos de borda operacionais que você pode integrar como melhorias nas funcionalidades da sua plataforma.
Quando um incidente ocorrer, não apenas compartilhe seus potsmortems com seu cliente. Realize também postmortems conjuntos. Fazê-lo também construirá confiança e ensinará valiosas lições.
Seja pensativo e disciplinado
Logo se tornará impossível aplicar esses passos a mais do que uma pequena porcentagem de seus clientes. Por favor, não tente estender este modelo para todos. Em vez disso, tome algumas decisões fundamentadas sobre como fará as seleções. Aqui estão algumas abordagens comuns:
Cobertura de receita
Selecione o número mínimo de clientes para representar XX% de sua receita. Se sua receita está concentrada em alguns grandes clientes, essa pode ser a escolha certa para você.
Cobertura de funcionalidades
Selecione o número mínimo de clientes para cobrir mais de XX% das funcionalidades de sua plataforma. Se você opera uma plataforma diversificada com muitos clientes fazendo coisas diferentes, essa abordagem ajudará a evitar surpresas.
Cobertura de carga de trabalho
O uso de sua plataforma pode ser dominado por alguns casos de uso ou tipos de clientes distintos. Talvez nenhum cliente individual nesses tipos seja dominante, mas você pode agrupá-los facilmente em coortes. Nesse caso, amostrar um ou dois clientes de cada coorte é uma boa maneira de obter cobertura da plataforma e descobrir diferenças operacionais entre os casos de uso.
Qualquer que seja a abordagem escolhida, mantenha-se fiel a ela. Misturar e combinar pode confundir seus stakeholders e sobrecarregar rapidamente sua equipe.
Conclusão
Nos últimos anos, a profissão e o papel de SRE se espalharam amplamente para fora dos limites do Google. Embora nunca tenhamos esperado por isso, estamos entusiasmados com esse desenvolvimento. Podemos dizer algo credível sobre como achamos que a disciplina evoluirá dentro do Google, mas fora dele — bem, isso é uma proposição “emocionantemente desconfortável”.
Uma coisa que temos bastante certeza é que, ao adotar os princípios de SRE em sua organização, você atravessará muitos dos mesmos pontos de inflexão que nós atravessamos (e alguns que ainda não atravessamos!) — incluindo a necessidade de borrar mais as linhas entre onde seus clientes terminam e onde você começa.
Engajar-se com clientes individuais neste nível de profundidade operacional é uma nova e gratificante fronteira para nós, e ainda estamos muito envolvidos nesse caminho. Quanto mais avançamos, no entanto, mais certos estamos de que esta é uma jornada que você também precisará seguir.