Conforme abordado no artigo anterior, Site Reliability Engineering é o jeito Google de gerir sua operação. Vimos que existem 7 princípios fundamentas que regem os times de SER e o primeiro deles é abraçar o risco. Neste artigo vou apresentar o que achei de mais interessante e prático para o nosso dia-a-dia do conteúdo do capítulo 3 - Embracing Risk, do livro Site Reliability Engineering.
Pode ser difícil medir claramente os riscos operacionais de um serviço e os impactos de uma indisponibilidade. Uma falha no serviço pode ter muitos efeitos, como insatisfação ou perda de confiança dos usuários, perda de receita direta ou indireta, impacto negativo na reputação da empresa e perda de valor de mercado.
No caso de uma empresa do porte do Google, talvez pensemos que seu time operacional busque sempre ter um nível de confiabilidade próximo a 100% dos seus serviços, pois certamente recursos computacionais e financeiros não são necessariamente um problema para ele. Entretanto a visão do SRE é diferente porque focar em aumentar a confiabilidade de um serviço não reflete necessariamente em benefícios para o usuário final. Dois fatores podem explicar isso: Custo e Inovação. Muitas vezes, para usuários dos serviços do Google, eles não conseguem perceber a diferença entre confiabilidade de 99,99% ou de 99,999% e, devido a isso, não faria sentido pagarem a mais por isso. Acerca do item inovação, sabemos que toda vez que fazemos alterações em um ambiente produtivo, existem riscos operacionais inerentes. Portanto, para aumentar ou manter a alta confiabilidade de um serviço, deveria evitar qualquer alteração em um ambiente já estável. Porém isso não é uma opção para o Google, assim como não é uma opção para qualquer empresa de SaaS hoje em dia. Portanto o time de SRE equilibra o nível de confiabilidade com inovações constantes.
Na prática, a principal função do SRE é gerenciar a confiabilidade do serviço através da gestão de riscos. Risco é uma constante na operação de um serviço e o dia-a-dia do time de SRE é manter a confiabilidade do serviço dentro de um range aceitável, equilibrando as demandas de alta inovação e gestão de riscos operacionais.
Essa métrica de confiabilidade do serviço é definida pelo time de SRE em conjunto com cada time de produtos. Quando não existe oficialmente um time de produtos, os próprios engenheiros responsáveis pelo desenvolvimento do produto fazem este papel, mesmo que indiretamente.
Para se definir a tolerância ao risco de um serviço, alguns fatores devem ser considerados, como:
No caso do Google, a meta do nível de disponibilidade para um serviço geralmente depende da função que ele fornece e do posicionado do serviço no mercado. Um serviço para usuários domésticos ou uso não profissional é tratado de forma diferente que um produto corporativo. A lista abaixo inclui algumas questões que devem ser levadas em consideração:
É importante também considerar os diferentes tipos possíveis de falhas e seus respectivos impactos. Nem todas as falhas geram os mesmos tipos de consequências. Algumas podem gerar maior latência no serviço, outras podem gerar indisponibilidade total, enquanto ainda outras podem abrir brechas de segurança e expor dados sensíveis. Todas estas falhas são de tipos diferentes e causam impactos distintos.
O aumento da confiabilidade de um serviço está diretamente relacionado ao custo envolvido para mantê-lo. Para uma operação financeiramente saudável deve-se avaliar se é rentável o investimento financeiro para aumentar sua disponibilidade. Por exemplo, talvez, para aumentar a confiabilidade de um serviço de 99,99% para 99,999% seria necessário um investimento de alguns milhões de reais. O retorno financeiro com base na receita adquirida (ou perdida) com esta mudança, compensa o investimento?
Além das métricas já apresentadas, é importante ter um olhar crítico do serviço e avaliar quais outras métricas devem ser monitoradas com o objetivo de mitigar riscos. Estas métricas serão peculiares do seu serviço e devem estar diretamente relacionadas com seu negócio.
O princípio de abraçar o risco é fundamental para que o time de SRE entregue agilidade ao time de produtos. Este princípio, quando aplicado dentro da empresa, ajuda no alinhamento dos objetivos do time operacional aos objetivos da empresa. O time de produtos poderá entregar suas novas funcionalidades ao mesmo tempo em que o ambiente permanecerá confiável e disponível. Para que isso seja possível é fundamental que da arquitetura da aplicação e da infraestrutura sejam definidas com esta mentalidade.
Outro benefício da aplicabilidade deste princípio é evitar gastos desnecessários na melhoria do serviço quando na verdade isso não refletirá em melhores resultados financeiros.
Uma outra prática adotada pela Google é o Error Budget, que vou apresentar no próximo artigo.