Objetivos de Nível do Serviço: A API para suas equipes

Se o nosso trabalho envolve liderança direta com as equipes de engenharia, gerenciando como, e o que fazem, certamente iremos nos deparar com situações nas quais a pressão para entregar venceu e levou à baixa confiabilidade dos serviços. Provavelmente tivemos o fluxo de trabalho interrompido pela interferência de gerentes sobre pequenos problemas individuais. Ou vimos ou ouvimos os executivos questionando o trabalho planejado da equipe para reduzir a dívida técnica ou melhorar os processos de entrega.

Esses tipos de conflitos são extremamente comuns nas equipes de engenharia e de gerência, bem como entre as equipes de engenharia. São todas as manifestações de um único problema: A necessidade de uma melhor camada de abstração para pessoas e equipes que estão tentando interagir ou colaborar entre elas. Essa camada de abstração é chamada de Objetivos de Nível de Serviço (ou SLOs, Service Level Objectives).

Muito provavelmente esteja com um ponto de interrogação na cabeça, pensando "mas eu imaginei que os SLOs eram para usuários! Não é uma ferramenta técnica?"

Em vez de estender a definição de SLIs (Service Level Indicators, Indicadores de Nível de Serviço em português), SLOs ou SLAs (Service Level Agreements, Acordos de Nível de Serviço em português) neste artigo (há muita documentação disponível), segue um resumo rápido:

• Um SLI é o indicador da bondade;
• O SLO é o objetivo de quantas vezes podemos nos dar ao luxo de falharmos;
• E um SLA é um acordo com os usuários.

O que quero focar aqui é, por que os SLOs são necessários e, em particular, como podem beneficiar os relacionamentos entre a equipe e outros indivíduos e equipes?

O problema comum nos exemplos acima, é que cada um deles descreve um limite confuso entre papéis e equipes. Por exemplo, o trabalho de um vice-presidente não deve ser especificar a ordem na qual resolveremos as tarefas ou entender todos os picos nos monitores e indicadores da área técnica. Mas esse desejo geralmente vem com boas intenções, onde as pessoas realmente se importam e esse tipo de interação pode ser o único sinal disponível sobre como as coisas estão indo ou como um usuário está experimentando nosso sistema.

Então, precisamos dar a esses colaboradores, algo melhor para se preocupar.

Estabeleça os limites da equipe

Precisamos estabelecer os limites da equipe, assegurá-lo, criar pontos de entrada e regras para ir e vir, e garantir a responsabilidade das pessoas pelo uso correto. E, em seguida, ignorar ou rejeitar as tentativas de violação dos limites, as comunicações por canais não autorizados ou aceitá-los em casos de exceção. Os SLOs podem nos ajudar nessa empreitada. Quando passamos pelo processo de identificação do que é importante para os negócios, estabelecendo e concordando através dos SLOs e os SLIs associados, teremos uma estrutura gerencial com o que é exigido da equipe e como essas demandas serão tratadas.

Para que esses limites sejam mantidos, todos os stakeholders devem concordar com os SLIs e com o SLO, também devemos verificar e medi-los de maneira adequada. Essa não é uma tarefa fácil, mas, para os propósitos do foco deste artigo, vamos supor que façamos isso e todos tenham concordado com um número em que acreditam. Por exemplo, talvez tenhamos concordado com um SLO afirmando que, para cada 90 dias, para 99,9% dos usuários do nosso site, a página inicial carregará "com rapidez suficiente" com base no SLI que a equipe de engenharia identificou quanto à latência nessa situação, que pode ser de "dez segundos".

Compartilhe a responsabilidade pela Excelência em Produção

Além do valor em garantir a prestação de serviços consistentes e previsíveis, os SLOs são uma arma poderosa contra micro gerenciadores, intrometidos e Gerentes de Projeto famintos por funcionalidades. É por isso que é tão importante que todos participem e assinem o SLO. Quando assinam, estão todos de acordo de que a primeira responsabilidade é manter o serviço com uma certa qualidade. Se o serviço estiver deteriorado em confiabilidade e disponibilidade, também concordaram que é a principal prioridade restaurá-lo.

Garantir um desempenho adequado do serviço requer um conjunto de habilidades que as pessoas e equipes precisam desenvolver continuamente ao longo do tempo, como medir a qualidade da experiência dos usuários, entender a integridade da produção com observabilidade, compartilhar conhecimentos, manter um ambiente irrepreensível para a resolução de incidentes e post-mortems, resolver problemas estruturais que representam um risco para o desempenho do serviço. Eles exigem foco na excelência da produção e um orçamento (em tempo) para a equipe adquirir as habilidades necessárias. A boa notícia é que esse investimento agora é justificado pelos SLOs com os quais a administração concordou. A discussão deve se afastar de quais trabalhos estão sendo priorizados para quais objetivos de serviço estamos tentando alcançar e manter com o passar do tempo.

Vejamos três cenários possíveis de como isso pode acontecer na vida real.

Cenário: Deu a louca no gerente

A equipe mantém um painel com erros e latência. Isso é ótimo na maioria das vezes, mas quando o chefão da empresa passa e percebe um aumento nos erros, ele se apavora e começa a falar com o líder de engenharia ou perguntar ao engenheiro mais próximo o que está acontecendo.

Agora, a equipe precisa alocar um tempo valioso do dia para explicar o que está errado ou explicar que nada está errado e que isso apenas parece ruim porque é um comportamento inesperado do usuário. É demorado e atrapalha a resolução das coisas. A gerência sênior pode não entender que cinquenta mil coisas por dia estão quebradas, e a equipe não pode parar e consertar ou se preocupar com cada uma delas.

Os SLOs ajudam a treinar os gerentes para se preocuparem com as coisas importantes e deixar as demais sem importância de lado. Podemos lembrá-los da página que mostra os SLIs e SLOs da equipe, para que possam ver onde a equipe está no orçamento de erros.

Cenário: O CEO Pula Algumas Prioridades

O CEO envia uma mensagem ao líder de engenharia algumas vezes por semana porque um usuário enviou uma mensagem ao CEO no Twitter para reclamar de um problema que afeta o aplicativo de celular. O CEO quer saber o que está errado e quando pode dizer ao usuário que o problema estará resolvido.

Ocasionalmente, isso pode ser útil, quando nos ajuda a detectar problemas que o monitoramento ainda não detectou, mas com muita frequência significa apenas que o bug trivial de um usuário ultrapassa o trabalho mais importante que está em nosso roteiro. Ou um dos engenheiros gastará tempo enviando uma única correção para esse usuário e, em seguida, precisamos corrigi-la outras vezes.

Então, como poder negociar com o CEO para que esses tipos de interrupção ocorram com menos frequência?

Verifique se este não é um exemplo de um problema real à espreita ou de que não foi capturado pelos SLOs. Digamos que o tempo limite para que o aplicativo seja exibido nos dispositivos móveis seja de 5 segundos. Portanto, algum segmento de tráfego para o celular não pode carregar a página com o SLI de 10 segundos, mas esses usuários não estão sendo identificados. Se conseguirmos rastreá-los, precisamos garantir ao CEO que isso está dentro do nosso orçamento de erros e será verificado quando for apropriado. Caso contrário, podemos incluir na nossa revisão periódica do SLO para poder adicionar um novo SLI ou contabilizá-lo no SLO daqui para frente.

Cenário: Frenesi de funcionalidades

Como gerente de engenharia, precisamos manter o volume de plantão razoável e proteger a capacidade da equipe de dormir durante a noite. Mas podemos ter dificuldade em recuar quando os executivos e todos os stakeholders desejam que os recursos sejam analisados e os bugs corrigidos, para dedicar tempo de desenvolvimento contíguo suficiente para resolver problemas de arquitetura subjacentes, fortalecer o pipeline de implantação e assim por diante. Esse tipo de trabalho nunca é a coisa mais urgente a qualquer momento, embora, a longo prazo, possa ser a coisa mais importante.

Como recuperaremos tempo o suficiente para lidar com as dívidas técnicas? E como podemos impedir que os stakeholders gerenciem nosso planejamento?

Conforme combinado, o primeiro trabalho é conhecer o SLO. Todos os outros trabalhos com funcionalidades ou correção de bugs é secundário a isso. Um SLO é a qualidade da disponibilidade que comprometemos a fornecer aos usuários. Isso significa que é o que comprometemos do que a equipe irá entregar. Isso tem implicações para o que e quando escolhemos construir.

Com base nesse contrato, aqueles que solicitam tempo já reconheceram que as solicitações que querem ser feitas são de menor prioridade até que o trabalho que a equipe está realizando para estabilizar o processo de implantação seja concluído, por exemplo. Talvez precisemos que a equipe trabalhe na redução do tempo de implantação para que uma correção de bug possa ser implantada na produção por meio de um pipeline de implantação em menos de 10 minutos, caso contrário, o SLO correspondente para a restauração do serviço será interrompido.

A via é de mão dupla

Conversely, some engineering teams will go on tinkering and refactoring forever in a quest for perfection, when you really need them shipping new features. How can you tell whether it's time to stop polishing and time to get back to shipping new stuff? When you are exceeding your SLO you can stand to add more chaos to the system, so turn the knob back up.

Por outro lado, algumas equipes de engenharia continuarão alterando e refatorando em busca da perfeição, quando realmente é necessário o envio de novas funcionalidades. Como podemos saber se é hora de parar de refatorar e voltar a enviar novos recursos? Quando excedemos o nosso SLO, pode ser que adicionemos mais caos ao sistema, então precisamos dar marcha ré.

Os SLOs são o nível certo de abstração para acordos entre equipes de uma empresa pelos mesmos motivos que são úteis entre as empresas. Não nos importamos com os detalhes da implementação de nosso provedor de rede, só queremos saber que estará disponível 99,95% do tempo e a comunicação é clara quando estiver inativo e em processo de backup. Treinar a gerência e as demais equipes para interagir conosco no mesmo nível de abstração e confiança, é muito importante. O Google tem um excelente documento de política sobre como lidar com violações de SLO.

Dessa maneira, os SLOs são úteis nas equipes, pois podem ajudar os perfeccionistas a dizerem quando está bom, dando a eles a capacidade de relaxar um pouco, e podem guiar as pessoas a saber quando é hora de controlar e medir duas vezes, e refatorar uma.

Uma fonte de conforto... e mais capacidade de foco

Depois de nos acostumarmos a pensar dessa forma, será um grande alívio. Em vez de precisar entender e avaliar profundamente o risco de cada situação, temos uma linguagem comum e simples para avaliar os riscos relacionados a erros de orçamentos. Os SLOs economizam tempo e energia para todos os envolvidos, nos dando a capacidade de redirecionar os recursos para coisas mais importantes, como manter nossos clientes satisfeitos.

Sobre a autora

Charity Majors (@mipsytipsy) é co-fundadora e engenheira da Honeycomb.io, uma startup que combina a velocidade das séries temporais com o poder bruto de eventos ricos para oferecer depuração interativa e iterativa para sistemas complexos. Trabalhou em empresas como o Facebook, a Parse e o Linden Lab como engenheira de sistemas e gerente de engenharia, e aparentemente acaba sempre responsável pelos bancos de dados também.