Princípios e práticas fundamentais da SRE: ciclos virtuosos
Se realmente é verdade que, em algum sentido, "você é o que você faz", então chegamos ao coração deste módulo. Nesta unidade, vamos analisar duas das práticas que muitas vezes são consideradas essenciais para a prática de SRE. Ambos se originam do princípio de que é importante criar "ciclos virtuosos". Ciclos virtuosos neste contexto são práticas que constroem ciclos de feedback em uma organização que ajudam essa organização a melhorar continuamente. Temos módulos de acompanhamento inteiros sobre exatamente essas duas práticas, então vamos apenas folhear a superfície com uma visão geral de cada uma aqui.
Ciclo virtuoso n.º 1: SLIs e SLOs
No início deste módulo, enfatizamos nosso ponto sobre trabalhar para o "nível apropriado de confiabilidade". Esta secção é precisamente o local onde esse conceito é aplicado.
Digamos que você tenha um novo serviço que está planejando trazer para a produção (seja um que foi construído ou um que ainda está em processo de planejamento). Como parte desse processo, é importante tomar algumas decisões sobre a confiabilidade desejada. Se você não está escrevendo todo o código sozinho, essas decisões são tomadas (e este ponto é crucial) em colaboração com os desenvolvedores que fazem a coisa.
A primeira decisão a tomar é: o que devemos usar como indicadores de saúde do serviço (um Indicador de Nível de Serviço ou SLI)? Outra maneira de fazer essa pergunta é "Como você sabe quando está funcionando bem?". Há muitas maneiras de rastrear o SLI e exploramos algumas em detalhes mais tarde. Mas, estes indicadores são normalmente:
- Medidas de sucesso versus fracasso. O serviço conclui com êxito uma operação em alguma porcentagem do tempo?
- Medidas de tempo. Retornamos uma resposta dentro de um determinado prazo de tempo?
- Medidas de rendimento. Processámos uma certa quantidade de dados?
Ou, alguma combinação de todas essas medidas.
Como exemplo simples, podemos dizer que um SLI para o nosso serviço é a frequência com que é fornecido com êxito, indicado através de um código 200 HTTP (em vez de um código 500 ou de outro tipo).
Agora que temos um indicador claro que nos diz como está o serviço. Queremos decidir que nível de fiabilidade esperamos ou desejamos dele. Por exemplo, esperamos ao longo de um período de um dia ver uma taxa de falha de 20% do serviço? Estamos a utilizar números grandes e redondos porque são fáceis de ponderar no início. Em módulos posteriores, aumentamos a complexidade e a precisão de afirmações como esta ("quais usuários veem essa taxa de erro? alguns deles? a maioria deles?" e assim por diante). Essa expectativa, criada em colaboração com o programador do serviço, é um Objetivo de Nível de Serviço (SLO).
O SLO tem de ser algo que possa ser medido e representado com precisão no seu sistema de monitorização. É para ser uma meta objetiva, bem compreendida para a confiabilidade do serviço qual é o número que é bom o suficiente? Não existe "bem, acho que o serviço está a ter um bom desempenho durante a última semana ou assim, mas é difícil saber". Ou o serviço está a cumprir ou não o SLO; os dados devem ser claros. Se não estiver a cumprir o SLO (sobretudo repetidamente ao longo de um intervalo de tempo), algo está errado e tem de ser resolvido.
Orçamentos de erros
Podemos entender que uma organização pode entrar em ação se um serviço não atender ao seu SLO. Mas, a SRE dá mais um passo em frente em todo este conceito para os casos em que o SLO está a ser cumprido ou ultrapassado. Algumas organizações utilizam SLOs para construir o que chamam de "orçamentos de erros".
Para demonstrar esta ideia, vamos utilizar o serviço de exemplo que temos vindo a abordar e o respetivo SLO de 80% de êxito (pense nisto como "tem de estar ativo até 80% do tempo"). Com o SLO de tempo de atividade em 80% declarámos que o nosso serviço tem de estar ativo até 80% do tempo. Mas e os outros 20%? Se o nosso serviço estiver inativo durante os restantes 20%, não nos irá "interessar" porque decidimos que esses 20% extra não são importantes para nós como um objetivo de serviço.
Assim, se não nos interessa o que acontece durante esse tempo, o que podemos fazer com o serviço? Uma coisa que podemos certamente fazer é perturbar o serviço em execução ao atualizá-lo, talvez com uma nova versão que adiciona algumas funcionalidades. Se essa nova versão se mantém ativa e não adiciona qualquer período de inatividade, ótimo. Se essa nova versão fizer com que o serviço seja menos estável e retorne erros mais 10% do tempo à medida que é depurado, tudo bem. Estamos dentro do nosso orçamento de falta de fiabilidade permitida.
Um orçamento de erros é a diferença entre a fiabilidade potencial perfeita do serviço e a fiabilidade desejada (100% - 80% = 20%). Neste caso, o orçamento de erro dá-nos um fundo de 20% de falta de fiabilidade 20% de tempo onde "não nos importamos se está em alta ou não porque ainda está em especificação". Podemos aproveitar e gastar esses 20% de tempo da maneira que quisermos (talvez com mais lançamentos) até que se esgote como qualquer outro orçamento.
Os orçamentos de erros também são utilizados em algumas organizações para casos menos felizes, quando não estiver a atingir o SLO. Nesse caso, você pode optar por fazer algo um pouco mais rigoroso do que apenas "tomar uma ação". Vamos supor que o nosso serviço tem tido alguns problemas e esteve ativo apenas 60% do tempo, conforme indicado pelo SLO que escolhemos anteriormente. Não atingimos o nosso objetivo (o SLO). O nosso serviço esgotou o orçamento de erros. A organização pode optar por reter um lançamento planeado porque sabe que perturbar ainda mais o sistema neste momento apenas vai piorar ainda mais a situação de fiabilidade. Normalmente, os orçamentos de erro são calculados para um determinado período de tempo; um mês, um trimestre e assim por diante. Em uma base contínua, então, eventualmente, se a confiabilidade do serviço melhorar, esse orçamento retorna.
Durante esse período de lançamentos fechados, a organização pode optar por desviar alguns recursos de engenharia do desenvolvimento de recursos para o trabalho de confiabilidade. Com o objetivo de ajudar a descobrir e melhorar a origem dos problemas que fizeram com que o serviço explodisse seu SLO.
O motivo pelo qual dizemos "algumas organizações" quando se trata de orçamentos de erros é a sua implementação, sobretudo no caso em que é utilizada para versões de proteção, precisar de uma determinada compra institucional. Quando confrontada com uma decisão de libertação, a organização tem de estar disposta a atrasar a libertação se a fiabilidade do serviço até à data não tiver estado em dia. Essa decisão não é aquela que todas as organizações estão dispostas a tomar. Esta decisão também não é a única resposta possível a um orçamento de erro esgotado, mas é a mais falada.
Em um módulo separado, falamos com muito mais detalhes sobre SLIs, SLOs e orçamentos de erro. Mas, vale a pena aqui destacar o aspeto do ciclo virtuoso dessas práticas. Em teoria, fornece uma maneira para uma organização descrever, comunicar e agir sobre a confiabilidade de um serviço. Ao fazê-lo de uma forma que faz com que todos trabalhem para uma melhor fiabilidade. Este ciclo de feedback pode ser extremamente importante.
Ciclo virtuoso n.º 2: post-mortems inocentes
A ideia de um post mortem – a análise retrospetiva de um evento significativo, tipicamente indesejado – não é nem remotamente específica da engenharia de confiabilidade do local. Não é sequer invulgar para o mundo de operações. Um aspeto mais próximo de ser distinto é a insistência da SRE de que os post-mortems têm de ser "inocentes". Têm de se concentrar na falha do processo ou na tecnologia durante o incidente e não nas ações de pessoas específicas. "Qual foi o processo que permitiu a X fazer o que originou a falha? Que informações essa pessoa não teve disponíveis, ou até proeminentes no momento que fez com que chegasse à conclusão errada? Que guarda-corpos deveriam ter sido colocados para que não fosse possível ter uma falha tão catastrófica?" Estas perguntas são do tipo feitas num post mortem irrepreensível.
O teor e a direção destas perguntas são cruciais. Estamos procurando maneiras de melhorar os sistemas ou 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 que "não é possível despedir a sua forma de fiabilidade". Em nossa experiência, uma organização que demite uma pessoa toda vez que há um incidente de produção (com poucas exceções), não aprende com esses incidentes. Em vez disso, eles ficam com um único indivíduo, tremendo no canto, com medo de fazer qualquer mudança em qualquer coisa.
No entanto, um processo de post-mortem a funcionar corretamente numa organização cria um ciclo virtuoso. Ele permite que a organização aprenda com suas interrupções e melhore continuamente seus sistemas (desde que a análise e o acompanhamento adequados sejam feitos).
Essa relação com falhas e erros adotados pela organização como oportunidades de aprendizado e melhoria é um princípio fundamental da engenharia de confiabilidade do local. A construção de ciclos virtuosos para utilizar estas oportunidades e orientar a organização para uma maior fiabilidade é outra opção.
Vamos explorar alguns outros princípios e práticas, centrados no lado humano da SRE, na nossa próxima unidade.