Sistemas que não funcionam, geram prejuízos para o negócio. Entretanto, alguns tipos de sistema são mais críticos do que outros. No e-commerce, por exemplo, a falta de confiabilidade gera prejuízos diretos, sentidos rapidamente, muito além do setor de TI.

Não basta que sejamos capazes de desenvolver sistemas inteligentes e sofisticados. É necessário que eles se comportem, em produção, consistentemente, de acordo com as expectativas. Antes de tudo, é necessário que estejam disponíveis para que cumpram seu propósito. Se, por um lado, velocity é importante – ou seja, os times de desenvolvimento tenham condições de entregar mais features em menos tempo – por outro, isso tem que acontecer sem que instabilidades em demasia sejam causadas.

Um das alternativas mais eficientes para mitigar o conflito entre velocity e estabilidade é, sem dúvidas, a prática da SRE (método de trabalho desenvolvido na Google). Temos obtido ótimos resultados com sua adoção!

No SRE, tudo começa com um acordo sobre o que significa disponibilidade. Este “acordo” é fundamental por “incluir na conversa” pessoas que estão fora da área de TI. Em seguida, a partir do estabelecimento do “acordo” do que disponibilidade significa, trabalha-se para o estabelecimento de SLOs – Objetivos de Nível de Serviço – que expressam quanto de disponibilidade é minimamente aceitável para cada parte do sistema.

Não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende, e não há sucesso no que não se gerencia – Deming

A rotina da SRE é, em boa parte, estabelecer e acompanhar medições que demonstram o atingimento, ou não, dos SLOs. Como esses objetivos estão definidos em termos de negócio, toda empresa tem, além do interesse, condições de acompanhar. No “fim do dia”, se um SLO não está sendo atendido, algo está errado e carece de investigação. 

Em um e-commerce, pouco adianta o site estar “no ar”, se estiver lento. Entretanto, a lentidão para mostrar detalhes de um produto tem consequências diferentes para a venda do que aquela percebida no processamento da cobrança, por exemplo.

Em termos práticos, temos constado que [tweet]o atendimento dos SLOs tem relação direta com o nível de confiança depositado pelo negócio na área de tecnologia.[/tweet]. Além disso, [tweet]os SLOs são excelentes instrumentos para garantir o alinhamento, tão fundamental para a autonomia que todos desejamos.[/tweet]

O estabelecimento dos SLOs, combinados com o acordo sobre o que disponibilidade significa, autoriza a definição de um conjunto de indicadores numéricos fáceis de acompanhar. Geralmente, esses indicadores são construídos a partir da agregação de elementos como response time, throughput e taxas de erro. Esses indicadores, na prática do SRE, são conhecidos como SLIs – Indicadores de nível de serviço.

Os SLIs são “sinais de trânsito” que indicam, em termos mais técnicos, se os SLOs estão sendo atendidos e há sinal verde para fazer experimentações, demandam atenção ou “parada geral” para corrigir algo. [tweet]Se todos os SLIs estiverem bem e, mesmo assim, o negócio entender que os SLOs não estão sendo atingidos, não há alinhamento sobre o que disponibilidade significa.[/tweet]

Há tempos, estamos trabalhando para criar dashboards que tornem nossas SLIs, agrupadas por SLOs, bem visuais e fáceis de acompanhar quase em tempo real. Temos usado, inclusive, códigos de cores (amarelo, azul e vermelho) para termos feedbacks mais rápidos se tudo está bem, ou não.

SRE não tem feito com que não experimentemos falhas. Mas, sem dúvidas, tem feito com que sejamos muito mais eficientes em minimizar os impactos sentidos pelo negócio. Ainda sentimos “dores”, mas elas estão cada vez menos sendo percebidas fora do setor de TI.