NetOps toma nota do foco do SRE no MTTR para perceber a disponibilidade

Engenheiro de Confiabilidade do Site (SRE) é uma função relativamente nova – geralmente em engenharia ou operações – focada em manter, sem surpresa, a confiabilidade do site. Isso geralmente significa disponibilidade de aplicativos, mas também inclui desempenho. Isso faz sentido, já que aplicativos que não respondem são considerados indisponíveis pela maioria dos usuários finais hoje em dia.

Ao analisar o Relatório SRE 2018 da Catchpoint , fiquei impressionado com os gráficos que comparam indicadores de nível de serviço e métricas de SRE. Normalmente, quando você vê “disponibilidade” como um indicador de nível de serviço de nível superior, você também vê “tempo de atividade” ou “tempo de inatividade” como uma métrica. Não é o caso dos SREs nesta pesquisa. 

Quando perguntados sobre quais indicadores de nível de serviço eram mais importantes para seus serviços, 84% declararam “disponibilidade para o usuário final” como número um. A latência ficou em segundo lugar, com 61%, e a taxa de erro em terceiro, com 60%. Desempenho – descrito como tempo de resposta do usuário final no relatório – obteve impressionantes 58% das respostas.

Agora observe as métricas usadas para definir o sucesso. No mundo da infraestrutura e das operações, estamos mais acostumados a ver métricas como “tempo de atividade” e frases de efeito como “5 9s”.

Os SREs tendem a ver o sucesso em termos de taxas de incidentes e MTTR. Considerando que o mesmo relatório observou que 41% dos SREs estavam em uma função de “Engenheiro de DevOps” antes de se tornarem SREs, isso não deveria ser surpreendente. O DevOps em si está mais preocupado com o MTTR do que com o cálculo do tempo de atividade, pois presume-se que haverá tempo de inatividade . O segredo é minimizá-lo resolvendo-o rapidamente em vez de perder tempo tentando evitá-lo.

Ainda assim, leitores atentos notarão que, ao minimizar o MTTR, você estará minimizando o tempo de inatividade. Resolução mais rápida, menos tempo de inatividade.

A diferença sutil entre os dois é que os seres humanos tendem a otimizar aquilo com que são medidos. Se você for medido em linhas de código, você vai escrever muitas linhas de código – quer você precise delas ou não. Se você for medido em incidentes de segurança, você vai bloquear tudo e gritar NÃO a qualquer mudança que possa encorajar uma violação. Se você medir as pessoas em termos de tempo de atividade, as operações se concentrarão em manter os sistemas ativos e disponíveis, mas não em arquitetar e instrumentar sistemas e aplicativos que diminuam o MTTR.

Este é um dos aspectos "culturais" do DevOps - uma mudança na maneira como abordamos as operações - que precisa ser transferido para o NetOps. Se continuarmos otimizando o tempo de atividade, perderemos a oportunidade de implementar o alerta e a observabilidade (como monitoramento e registro robusto) que reduzem o tempo médio de resolução e atingem nossa meta de minimizar o tempo de inatividade.

Analisar registros — mesmo os centralizados — não é um meio eficiente de chegar ao cerne de um problema e resolvê-lo. O monitoramento e o alerta em tempo real sobre variáveis-chave que afetam a disponibilidade, como capacidade, conectividade e desempenho em todo o caminho de dados (rede, infraestrutura, aplicativo) invariavelmente reduzirão o tempo necessário para resolver problemas se você estiver ciente de sistemas ou serviços que estão se degradando ou falharam abruptamente.

A NetOps precisa adotar essa abordagem com relação à confiabilidade no pipeline de produção porque é uma abordagem geral melhor para lidar com falhas inevitáveis e está alinhada com suas contrapartes DevOps. Afinal, há uma razão pela qual só alcançamos 5 9s, não é? Porque reconhecemos que o fracasso acontece não importa o quanto tentemos e que a perfeição é impossível.

A mudança do tempo de atividade/inatividade para o MTTR como uma métrica de sucesso incentiva a colaboração entre equipes e o uso de ferramentas de observabilidade em todo o pipeline de produção. Há uma razão pela qual as ferramentas de monitoramento e alerta estavam no topo das “ferramentas essenciais” para SREs na pesquisa. Observabilidade (com o objetivo de alertar sobre erros/incidentes) mais colaboração é uma fórmula melhor para garantir que todos – NetOps, DevOps e App Dev também – possam atingir seu objetivo de manter os aplicativos rápidos e disponíveis.