Princípios e práticas fundamentais da SRE: ciclos virtuosos
Se é realmente verdadeiro que, de alguma forma, “você é o que você faz”, então, chegamos ao ponto central deste módulo. Nesta unidade, vamos examinar duas das práticas que geralmente são consideradas fundamentais para a prática da SRE. Ambas se originam do princípio de que é importante criar “ciclos virtuosos". Nesse contexto, ciclos virtuosos são práticas que criam loops de feedback em uma organização que ajudam essa organização a aprimorar continuamente. Haverá módulos de acompanhamento inteiros exatamente sobre essas duas práticas. Portanto, vamos apenas abordá-las superficialmente com uma visão geral de cada uma aqui.
Ciclo virtuoso nº 1: SLIs e SLOs
Anteriormente neste módulo, enfatizamos nosso ponto sobre o trabalho em busca do “nível apropriado de confiabilidade”. Esta seção é precisamente o lugar em que esse conceito é trazido à tona.
Digamos que você tenha um novo serviço que pretende colocar em produção (um que foi construído ou que ainda esteja em processo de planejamento). Como parte desse processo, é importante tomar algumas decisões sobre a confiabilidade desejada dele. Se você não estiver escrevendo todo o código por conta própria, essas decisões serão tomadas (e esse ponto é crucial) em colaboração com os desenvolvedores que estão trabalhando nisso.
A primeira decisão a ser tomada é: o que devemos usar como indicadores da integridade do serviço (um Indicador de Nível de Serviço ou SLI)? Outra maneira de perguntar isso é “Como saber quando ele está funcionando e tendo um bom desempenho?”. Há muitas maneiras de acompanhar o SLI, e vamos explorar algumas delas mais detalhadamente daqui a pouco. Porém, esses indicadores normalmente são:
- Medidas de sucesso versus falha. O serviço conclui com sucesso uma operação em algum percentual do tempo?
- Medidas de tempo. Retornamos uma resposta dentro de determinado limite de tempo?
- Medidas de produtividade. Processamos determinado volume de dados?
Ou uma combinação de todas essas medidas.
Para obter um exemplo simples, podemos dizemos que um SLI para nosso serviço é a frequência com que ele retorna o sucesso, indicado por um código HTTP 200 (versus um código 500 ou outro).
Agora que temos um indicador claro que nos informa sobre o desempenho do serviço. Queremos decidir qual nível de confiabilidade esperamos ou desejamos dele. Por exemplo, em um período de um dia, esperamos ver uma taxa de falha de 20% do serviço? Estamos usando números grandes e redondos aqui porque eles são mais fáceis de calcular no início. Nos módulos posteriores, aumentaremos a complexidade e a precisão de declarações como esta (“Quais usuários veem essa taxa de erro? Alguns deles? A maioria deles?” etc.). Essa expectativa, criada em colaboração com o desenvolvedor do serviço, é um SLO (Objetivo de Nível de Serviço).
O SLO precisa ser algo que possa ser medido com precisão e representado no sistema de monitoramento. Ele foi projetado para ser um objetivo, uma meta bem compreendida para a confiabilidade do serviço. Qual número é bom o bastante? Aqui não há espaço para “Bem, acho que o desempenho do serviço está razoável na última semana ou mais, mas é difícil dizer”. O serviço está atendendo seu SLO ou não e os dados devem estar claros. Se ele não atender a seu SLO (especialmente repetidas vezes durante um período), isso indicará que algo está errado e precisa ser resolvido.
Orçamentos de erro
Podemos entender que uma organização poderá entrar em ação se um serviço não atender ao SLO. No entanto, a SRE leva esse conceito para outro patamar para os casos em que o SLO está sendo atingido ou excedido. Algumas organizações usam SLOs para construir o que elas chamam de “orçamentos de erro”.
Para demonstrar essa ideia, vamos usar o serviço de exemplo que estamos abordando e seu SLO de sucesso de 80% (imagine isso como “deve estar ativo até 80% do tempo”). Com o SLO de 80% de tempo de atividade, declaramos que nosso serviço deve estar ativo 80% do tempo. Mas e quanto aos outros 20%? Se o nosso serviço estiver inativo nos outro 20%, isso não nos “interessará” porque decidimos que estar ativo nesses 20% extras não é importante para nós como uma meta de serviço.
Se não nos importarmos com o que acontece durante esse tempo, o que poderemos fazer com o serviço? Uma coisa que podemos certamente fazer é interromper o serviço em execução atualizando-o, talvez com uma nova versão que adiciona alguns recursos. Se essa nova versão permanecer ativa e não adicionar nenhum tempo de inatividade, isso será ótimo. Se essa nova versão fizer com que o serviço seja menos estável e retorne erros nos outros 10% do tempo conforme ele for depurado, isso ainda será aceitável. Estamos dentro do nosso orçamento de não confiabilidade permitida.
Um orçamento de erro é a diferença entre a confiabilidade perfeita potencial do serviço e sua confiabilidade desejada (100% – 80% = 20%). Nesse caso, o orçamento de erro nos dá um fundo de 20% de não confiabilidade, 20% de tempo durante o qual “não nos importamos se ele está ativo porque ele ainda está dentro da especificação”. Podemos utilizar e gastar esses 20% de tempo de qualquer maneira desejada (talvez com mais versões) até que seja esgotado, assim como qualquer outro orçamento.
Os orçamentos de erro também são usados em algumas organizações para o caso menos feliz, aquele em que você não está fazendo seu SLO. Nesse caso, você pode optar por fazer algo um pouco mais rígido do que simplesmente “executar uma ação”. Digamos que nosso serviço tenha tido alguns problemas e tem estado ativo apenas por 60% do tempo, conforme indicado pelo SLI que escolhemos anteriormente. Não cumprimos nosso objetivo (o SLO). Nosso serviço esgotou o orçamento de erro. A organização pode optar por manter um lançamento planejado porque sabe que se ela interromper ainda mais o sistema neste momento, haverá a probabilidade de que a situação de confiabilidade piore ainda mais. Normalmente, os orçamentos de erro são calculados por determinado período: um mês, um trimestre etc. De forma contínua, portanto, se a confiabilidade do serviço melhorar, o orçamento retornará.
Durante esse tempo de versões restritas, a organização pode optar por afastar alguns recursos de engenharia do desenvolvimento de recursos em direção ao trabalho de confiabilidade. Com o objetivo de ajudar a descobrir e aprimorar a origem dos problemas que fizeram com que o serviço excedesse o SLO.
O motivo pelo qual dizemos “algumas organizações” quando se trata de orçamentos de erro é que a sua implementação, especialmente no caso em que ele é usado para versões restritas, exige determinada aceitação institucional. Diante de uma decisão de lançamento, a organização deverá estar disposta a reter a versão se a confiabilidade do serviço até o momento não tiver sido suficiente. Essa não é uma decisão que todas as organizações estão dispostas a tomar. Também não é a única resposta possível para um orçamento de erro esgotado, mas é a mais comentada.
Em um módulo separado, falaremos consideravelmente com mais detalhes sobre os SLIs, os SLOs e os orçamentos de erro. Mas vale a pena destacar o aspecto de ciclo virtuoso dessas práticas. Em teoria, ele fornece um modo de uma organização descrever, comunicar e tomar decisões sobre a confiabilidade de um serviço. Fazendo isso de uma forma que faça com que todos trabalhem em direção a uma melhor confiabilidade. Esse loop de comentários pode ser incrivelmente importante.
Ciclo virtuoso nº 2: análises post-mortem sem a finalidade de encontrar culpados
A ideia de uma análise post-mortem – a análise retrospectiva de um evento significativo, geralmente indesejado – não é mesmo remotamente específico à engenharia de confiabilidade de sites. Não é incomum, mesmo para o cenário de operações. Uma coisa que está mais próxima de ser diferenciada é a insistência por parte da SRE de que as análises post-mortem precisam ser isentas de “acusação”. Elas precisam se concentrar na falha do processo ou da tecnologia durante o incidente, não nas ações de pessoas específicas. “O que houve de errado com o processo implementado que permitiu que X realizasse a ação que levou à falha? Quais informações não estavam disponíveis para essa pessoa, nem mesmo estando proeminentes no momento que a levou a chegar à conclusão incorreta? Quais tipos de proteções deveriam ter sido implementadas para que não fosse possível ter uma falha catastrófica como essa?” Esses são o tipo de perguntas feitas em uma análise post-mortem sem a finalidade de encontrar culpados.
O teor e a direção dessas perguntas são fundamentais. Estamos buscando maneiras de aprimorar os sistemas ou os processos, não maneiras de punir os indivíduos cujo uso desses sistemas ou processos, de boa-fé, contribuiu para a interrupção. É importante lembrar-se de que “você não pode atingir a confiabilidade imediatamente”. Pela nossa experiência, uma organização que demite uma pessoa sempre que há um incidente de produção (com poucas exceções) não aprende com esses incidentes. Em vez disso, ela acabará com uma pessoa apenas, tremendo no canto, com receio de fazer qualquer mudança.
Mas um processo post-mortem que funciona bem em uma organização cria um ciclo virtuoso. Isso permite que a organização aprenda com as interrupções e aprimore continuamente os sistemas (desde que a análise e o acompanhamento adequados sejam feitos).
Essa relação com as falhas e os erros, adotada pela organização como oportunidades de aprendizado e melhoria, é um princípio fundamental da engenharia de confiabilidade do site. A construção de ciclos virtuosos para fazer uso dessas oportunidades e orientar a organização em busca de uma maior confiabilidade é outro.
Vamos explorar alguns princípios e práticas, centralizados no lado humano da SRE, em nossa próxima unidade.