Stephen Thorne, engenheiro em confiabilidade do cliente no Google, participou recentemente do DevOps Enterprise Summit London falando sobre o SRE (Site Reliability Engineering) e a quantidade de organizações que não estão conseguindo entender seus benefícios e suas premissas básicas [slides em PDF]. Os principais mal-entendidos que Thorne viu em outras organizações foram: confundir os service level objectives (SLOs), que são focados na detecção antecipada de falhas, com service level agreements (SLAs), que geralmente servem como compensação financeira para incidentes passados; não impondo orçamentos para erros; e não dedicar pelo menos 50% do esforço das equipes de SRE para melhorar os sistemas e as ferramentas, deixando assim, a equipe afundar no trabalho pesado, ou seja, "combater incêndios" em ambiente de produção.
Os SLOs são fundamentais para detectar os problemas de forma precoce, idealmente antes que os efeitos se tornem visíveis para os clientes. Um bom SLO está alinhado com a expectativa do cliente (disponibilidade de serviço ou tempo de resposta, por exemplo) e, portanto, reflete se o sistema (comportamento) está atendendo às necessidades do usuário. O uso de recursos, como a utilização da CPU ou a taxa de transferência da rede, deve ser monitorado, mas não deve ser usado como um SLO em si. Thorne colocou de forma simples como "se o cliente está feliz, então o SLO está sendo cumprido". Os SLOs típicos do Google incluem:
- Tempo de atividade de 99,9% ao mês (ou seja, 43 minutos de inatividade por mês);
- 99,99% das solicitações HTTP em um mês são bem-sucedidas com um 200 OK;
- 50% das solicitações HTTP retornaram em menos de 300 ms.
Os SLAs, por outro lado, normalmente entram em ação quando os clientes já estão insatisfeitos com um serviço, deixando assim, de melhorar proativamente a confiabilidade do sistema. Além disso, os SLAs podem levar a incentivos errados, por exemplo, comparar um SLA de duas horas para corrigir um problema de e-mail com um SLA de um dia para corrigir um incidente grave em ambiente de produção, e começar a trabalhar primeiramente no problema de e-mail sendo que a questão de produção deveria ser prioridade.
Apenas definir SLOs não é suficiente, advertiu Thorne. As políticas de orçamento para erro permitem a junção de SLOs definindo regras claras para ação (não compensação monetária) antes de um sistema se aproximar do limite de um SLO. Isso também minimiza o confronto entre ops e dev quando os sistemas estão falhando em atender às necessidades do usuário. "O orçamento para erro é a lacuna entre a confiabilidade perfeita e o nosso SLO", disse Thorne. Para o Google, uma política de orçamento para erros típicos é proibir o lançamento de novos recursos quando o aplicativo esgotar seu orçamento para erros (por exemplo, neste mês ultrapassamos 43 minutos o orçamento de inatividade) ou dedicar uma sprint a ações corretivas decorrentes de análises prévias de post-mortem.
Thorne ressaltou, no entanto, que o que funciona para o Google não funcionará para todas as organizações: "O SRE precisa de SLOs com consequências que equilibram um nível aceitável de falha com o custo e a velocidade de entrega necessários". Os SLOs e as políticas exatas devem ser adequados para cada organização - não para copiar / colar do Google - e devem se concentrar em melhorar continuamente a experiência dos clientes, e não em estabelecer metas elevadas ou punições duras que possam ser contraproducentes. Thorne deu o exemplo de uma organização que luta para reduzir o tempo de processamento de um sistema de recomendações. Descobrimos que os usuários só veriam essas recomendações quando voltassem ao site, em média, seis horas depois. Um SLO adequado seria processar todas as recomendações dentro de 6 horas, o que significava que elas poderiam economizar o custo de três engenheiros que anteriormente trabalhavam no intervalo na percepção do "problema" do tempo de resposta lento.
Capacitar as equipes de SRE para balancear a carga de trabalho entre o trabalho "diário" (geralmente não planejado) e o trabalho planejado para reduzir o trabalho (conhecido como "combate a incêndios") é a terceira chave para a SRE, disse Thorne. No Google, isso significa que pelo menos 50% do esforço SRE é gasto no trabalho do projeto: Ter uma consultoria antecipada na arquitetura de novos sistemas para identificar antipadrões de resiliência (e evitar mais trabalho mais tarde), melhorando o monitoramento, automatizando tarefas repetitivas ou coordenando implementação de ações corretivas post-mortem.
Thorne referiu ainda alguns claros antipadrões para a implementação do SRE, como simplesmente rebranding da equipe de operações para a equipe SRE ou contratação de engenheiros para SRE sem primeiro implementar os princípios e mecanismos de SRE (SLOs, políticas de orçamento de erros e balanceamento de carga de trabalho) para obter sucesso.
De acordo com Thorne, estes são cinco passos fundamentais para seguir o caminho certo da SRE:
- Definir SLOs contextuais e focados no cliente
- Definir de forma sensata, políticas orçamentárias para erros
- Contratar (internamente ou externamente) SREs e capacitá-los através de suporte de liderança
- Permitir que os SREs ajustem os SLOs e apliquem políticas de orçamento de erro
- Atribuir a responsabilidade pela confiabilidade dos sistemas críticos às equipes de SRE, e a responsabilidade de outros sistemas para equipe de desenvolvimento correspondente
O Google desenvolveu e expandiu internamente a disciplina de engenharia de confiabilidade do site por alguns anos, antes de condensar as lições aprendidas no livro da SRE. Thorne mencionou que um manual de acompanhamento do SRE será lançado no final deste mês.
ATUALIZAÇÃO: A novo documento de trabalho do SRE está disponível gratuitamente neste link (PDF) até 23 de agosto de 2018.