SRE

PRINCIPIOS:
ABRAÇANDO O RISCO
Serviços 100% confiáveis parecem muito bons, mas, depois de um certo ponto, o
aumento da confiabilidade é pior para um serviço e seus usuários. Confiabilidade
extrema tem um custo: Maximizar a estabilidade limita a rapidez com que novos
recursos podem ser desenvolvidos e os produtos podem ser entregues aos usuários, e
aumenta drasticamente o custo, o que, por sua vez, reduz o número de recursos que
uma equipe pode oferecer.
Não adianta o Google buscar 100% de confiabilidade nos seus serviços quando a
experiencia do usuário é limitada por um smartphone ou uma conexão com a internet.
Assim, em vez de sair na busca de 100% de confiabilidade, um SRE busca balancear o
risco de indisponibilidade com os objetivos de inovação e operação eficiente dos
serviços, para que a felicidade geral dos usuários – com features, serviços e
performance – seja otimizada.
1. Gerenciando o risco
Sistemas não confiáveis podem corroer a confiança do usuário, assim queremos
diminuir a chance de falha. Contudo, experiencia mostra que a medida que
construímos sistemas, o custo não aumenta linearmente a medida que a confiabilidade
aumenta. Uma melhora incremental na confiabilidade pode custar 100 vezes mais do
que o incremento anterior. O custo tem duas dimensões:

 O custo de redundância de recursos computacionais: Custo associado com

equipamentos de redundância.
 A oportunidade de custo: O custo suportado por uma organização ao alocar
recursos de engenharia para construir sistemas ou features que diminuem o
risco em vez de features que são visíveis ou usáveis pelo usuário final. Esses
engenheiros não mais trabalham em novas features e produtos.
Com sre, gerencia-se a confiabilidade de um serviço por meio do gerenciamento de
risco. O risco é visto com um continuum. Dá-se igual importância a descobrir como
criar maior confiabilidade para sistemas Google e identificar o nível apropriado de
tolerância para os serviços executados. Isso permite fazer uma análise de
custo/beneficio para determinar, por exemplo, onde, num continuum de risco (não
linear) pode-se colocar o Google Search, Ads, Gmail ou Photos. O objetivo é
explicitamente alinhar o risco assumido por um determinado serviço com o risco que o
negócio está disposto a assumir. Assim, um serviço precisa ser confiável de forma
suficiente, não mais do que precisa ser.
2. Medindo o risco do serviço
Para o risco do serviço, não fica tão claro como reduzir todos os fatores potenciais em
uma única métrica. Falhas de serviço trazem muitos efeitos negativos, então fica claro
que alguns desses fatores são difíceis de medir. Para tornar esses problemas tratáveis
e consistentes em muitos tipos de sistemas, temos que nos concentrar no tempo de
inatividade não planejado.
Para a maioria dos serviços, a maneira mais direta de representar a tolerância ao risco
é em termos do nível aceitável de tempo de inatividade não planejado. Esse tempo de
inatividade é capturado pelo nível desejado de disponibilidade do serviço,
normalmente expresso em termos de ‘noves’ no número como 99,99%, 99,999%.
3. Tolerância a riscos
Num ambiente formal a tolerância a riscos dos serviços é normalmente construída
diretamente no produto básico ou na definição do serviço.
Para identificar a tolerância a riscos de um serviço, SRE deve trabalhar com o gerente
de produto para transformar um conjunto de metas de negócios em objetivos
explícitos para os quais podemos projetar. Essas metas de negócios que preocupam
tem um impacto direto no desempenho e na confiabilidade do serviço oferecido.
a. Identificando a tolerância ao risco de serviços ao consumidor
Os serviços ao consumidor têm um time para cada produto os quais atuam
como proprietários de uma aplicação. Eles têm a responsabilidade de entender
os usuários e o negócio e moldam o produto para ter sucesso no mercado. Na
falta de um time dedicado ao produto, os engenheiros que desenvolvem o
sistema desempenham esse papel de forma consciente ou não.
b. Nivel alvo de disponibilidade
O nível de disponibilidade de um dado serviço depende da função que ele
desempenha e como o serviço está posicionado no mercado.
4. Nivel de falhas
Quão resiliente é nosso negócio em relação ao tempo de inatividade do serviço? O que
é pior uma falha baixa e constante ou uma queda ocasional de toda a aplicação?
5. Custo
O custo é constantemente um fator chave para determinar a meta de disponibilidade
apropriada para um serviço.