Princípios e práticas fundamentais de SRE: ciclos virtuosos
Se é verdade que, de certa forma, "tu és o que fazes", então chegamos ao cerne deste módulo. Nesta unidade, vamos analisar duas das práticas que, muitas vezes, são consideradas fundamentais para a prática da SRE. Ambos têm origem no princípio de que é importante criar "ciclos virtuosos". Neste contexto, os ciclos virtuosos são práticas que criam ciclos de feedback numa organização que ajudam essa organização a melhorar continuamente. Temos módulos de seguimento completos sobre exatamente estas duas práticas, por isso vamos apenas analisar a superfície com uma descrição geral de cada um aqui.
Ciclo virtuoso n.º 1: SLIs e SLOs
Anteriormente neste módulo, salientámos o nosso ponto de vista de trabalhar para o "nível adequado de fiabilidade". Esta secção é precisamente o local onde esse conceito é levado a suportar.
Digamos que tem um novo serviço que está a planear trazer para produção (ou um que tenha sido construído ou um que ainda esteja no processo de planeamento). Como parte desse processo, é importante tomar algumas decisões sobre a fiabilidade desejada. Se não estiver a escrever todo o código sozinho, estas decisões são tomadas (e este ponto é crucial) em colaboração com os programadores que fazem a coisa.
A primeira decisão a tomar é: o que devemos utilizar como indicadores do estado de funcionamento do serviço (um Indicador de Nível de Serviço ou SLI)? Outra forma de fazer esta pergunta é "Como sabe quando está a funcionar bem?". Existem várias formas de controlar o SLI e exploramos algumas em detalhe mais tarde. Mas, normalmente, estes indicadores são:
- Êxito vs. medidas de falha. O serviço conclui com êxito uma operação em percentagem do tempo?
- Medidas de temporização. Devolvemos uma resposta dentro de um determinado limiar de tempo?
- Medidas de débito. Processámos uma determinada quantidade de dados?
Ou alguma combinação de todas estas 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 que, durante um período de um dia, veja 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. Nos módulos posteriores, aumentamos a complexidade e precisão de instruções como esta ("que utilizadores veem essa taxa de erros? 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. Destina-se a ser um objetivo, bem compreendido, para a fiabilidade do serviço, qual é o número suficientemente bom? 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 compreender que uma organização pode entrar em ação se um serviço não cumprir o respetivo SLO. Contudo, a SRE dá mais um passo em frente a todo este conceito para os casos em que o SLO está a ser cumprido ou excedido. 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 fique menos estável e devolva erros mais 10% do tempo à medida que é depurado, ainda está 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 do erro dá-nos um fundo de 20% de falta de fiabilidade a 20% de tempo em que "não nos interessa se está ou não em alta porque ainda está em especificação". Podemos aproveitar e gastar esse tempo de 20% como quisermos (talvez com mais lançamentos) até que esteja esgotado 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, 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 erros são calculados durante um determinado período de tempo; um mês, um trimestre, etc. De forma contínua, eventualmente, se a fiabilidade do serviço melhorar, esse orçamento é devolvido.
Durante este período de lançamentos fechados, a organização pode optar por afastar alguns recursos de engenharia do desenvolvimento de funcionalidades para o trabalho de fiabilidade. Com o objetivo de ajudar a descobrir e melhorar a origem dos problemas que fizeram com que o serviço rebentasse com o 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 lançamento, a organização tem de estar disposta a reter a versão se a fiabilidade do serviço até à data não tiver sido suficiente. Esta decisão não é uma decisão 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.
Num módulo separado, falamos consideravelmente mais detalhadamente sobre SLIs, SLOs e orçamentos de erros. No entanto, vale a pena destacar o aspecto virtuoso destas práticas. Em teoria, proporciona uma forma de uma organização descrever, comunicar e agir sobre a fiabilidade de um serviço. Ao fazê-lo de uma forma que faça com que todos estejam a trabalhar para uma melhor fiabilidade. Este ciclo de feedback pode ser extremamente importante.
Ciclo virtuoso n.º 2: post-mortems inocentes
A ideia de uma autópsia ( a análise retrospetiva de um evento significativo, normalmente indesejável) nem sequer é remotamente específica da engenharia de fiabilidade do site. 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 proteções deveriam ter sido implementadas para que não fosse possível ter uma falha tão catastrófica?" Estas perguntas são a ordenação feita numa autópsia sem culpa.
O teor e a direção destas perguntas são cruciais. Estamos à procura de formas de melhorar os sistemas ou processos, não formas de punir os indivíduos cuja utilização 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". Na nossa experiência, uma organização que despede uma pessoa sempre que há um incidente de produção (com poucas exceções) não aprende com esses incidentes. Em vez disso, ficam com um único indivíduo, a tremer no canto, com medo de fazer alterações a qualquer coisa.
No entanto, um processo de post-mortem a funcionar corretamente numa organização cria um ciclo virtuoso. Permite que a organização aprenda com as suas interrupções e melhore continuamente os seus sistemas (desde que seja feita uma análise e seguimento adequados).
Esta relação com falhas e erros adotados pela organização como oportunidades de aprendizagem e melhoria é um princípio fundamental da engenharia de fiabilidade do site. A construção de ciclos virtuosos para utilizar estas oportunidades e orientar a organização para uma maior fiabilidade é outra opção.
Vamos explorar outros princípios e práticas, centrados no lado humano da SRE, na nossa próxima unidade.
Verifique o seu conhecimento
Precisa de ajuda? Veja o nosso guia de resolução de problemas ou faça comentários específicos ao comunicar um problema.