Alertas bem elaborados

Alertar é o que nos notifica quando um problema surge ou está prestes a surgir, para que a ação possa ser tomada.

Criar alertas oportunos e significativos não são fáceis, mas são necessários, já que as pessoas tendem a ignorar os alertas quando sentem que não são precisos .

Alertas são problemas

Primeiro, alertas que requerem a atenção de um humano, muitas vezes conhecido como Pages, ou também aqueles alertas que vão acordar alguem de madrugada ou tirar a atenção de alguem durante o dia devem ser urgentes, importantes, passiveis de ação e reais. O problema de ter o over-monitoring ou mais alertas do que podemos controlar significa que que os analistas responsaveis vão parar de dar atenção para os alertas, ignorar eles quando acontecerem.

Um resumo é que um alerta tem que representar um PROBLEMA, e esse problema deve ter uma ação relacionada a ele. As ações podem ser conduzir uma investigação, alguma ação como remover um servidor defeituoso do balanceamento, criar uma ação de bugfix, ou até mesmo disparar uma ação de capacity planning.

Alertas bem elaborados

• Precisão :
  • Basicamente é a taxa de verdadeiro positivo
  • 100% de precisão significa que cada alerta corresponde a um evento significativo.
• Recall :
  • 100% de recall significa que todo evento significativo gerou um alerta.Ou seja, com isso não temos eventos significativos acontecendo que não estamos alarmando.
  • Ele é a proporção de eventos significativos que são detectados e transformados em alertas. 
• Tempo de detecção :
  • Quanto tempo leva para uma condição ser detectada e transformada em alertas
• Tempo de reinicialização :
  • Quanto tempo leva para que os alertas parem de disparar depois que a condição raiz for resolvida.
• Alertas baseados em sintomas
  • Seus usuários se importam se seus servidores MySQL está com alto consumo de CPU? Não, eles se importam se suas consultas estão demorando
  • Seus usuários se importam se um binário de suporte (ou seja, caminho sem serviço) está em um loop de reinicialização? Não, eles se importam se seus recursos estão falhando.
  • Os usuários, em geral, se preocupam com um pequeno número de coisas:
    • Disponibilidade e correção básicas. sem “Oops!”, sem 500s, sem solicitações travadas ou páginas carregadas pela metade ou Javascript ou CSS ausentes ou imagens ou vídeos. Qualquer coisa que interrompa o serviço principal de alguma forma deve ser considerada indisponibilidade.
    • Latência. Rápido, mas somente o suficiente.
    • Completude/frescura/durabilidade. Os dados de seus usuários devem estar seguros, devem retornar quando você solicitar e os índices de pesquisa devem estar atualizados. Mesmo que esteja temporariamente indisponível, os usuários devem ter total fé de que ele voltará.
    • Features. Seus usuários se preocupam que todos os recursos do serviço funcionem – você deve monitorar qualquer coisa que seja um aspecto importante do seu serviço, mesmo que não seja a funcionalidade/disponibilidade principal
• Runbooks
  • Importante que os alertas tenham playbooks ou runbooks, com informações sobre o que fazer, diagramas, informações sobre logs, dashboards etc. Devemos desenvolver sistemas como se quando eles derem problema seremos acordados a noite, e para evitar o esforço cognitivo de quem esta acabando de acordar eles devem conter bons runbooks, com os problemas conhecidos e melhores praticas de throbleshotting.
• Rastreaveis
  • Os alertas precisam ser rastreáveis. Precisamos conseguir chegar facilmente na fonte do alerta.

Princípios da jornada de SRE

O que faz um SRE? 

A principal característica de um sistema deve ser a confiabilidade. O foco do SRE está na confiabilidade do sistema. O papel do SRE, de uma forma bem alto nível são somente dois: Medir e Garantir. E para isso existe uma série de princípios que devem ser compreendidos. Além de auxiliar no ciclo de vida do produto.

Principios para SRE

• Aceitando os riscos
• SLx
• Eliminando Toil
• Monitoração
• Automação
• Engenharia de Release
• Simplicidade
• Design de Sistema (Grandes) Não Abstrato (NALSD)

Aceitando os riscos

Aceitar o risco significa estabelecer um nível aceitável de confiabilidade, que pese os custos do que está sendo assumido em relação ao risco. E para aceitar o risco a filosofia de usar error budget precisa estar bem establecida para que funcione.

Níveis de serviço

 Coração da engenharia de confiabilidade, os SLO`s, SLI`s e SLA`s e Error Budgets. o SLA, a promessa feita para o cliente, é o mínimo disposto em contrato, os SLO`s são os objetivos que você quer atingir além desse contrato, e os SLI são os indicadores que você vai utilizar pra acompanhar como estão o andamento desses objetivos.

Eliminando Toil

Reduzir as tarefas repetitivas para gastar energia em coisas urgentes com automação e um meta importante para o SRE. Simplesmente se estamos querendo reduzir nosso TOIL precisamos automatizar coisas, mas com o devido planejamento porque algo automatizado erradamente gera ainda mais pŕobelamas. O objetivo de qualificar algo como TOIL justamente indica para onde o esforço com automação deve ir, ou seja, problemas no fluxo de valor não devem ser, a priori, qualificados como TOIL.

Monitoração

Como dito anteriormente, medir e garantir. Todas as decisões tomadas devem estar pautadas em números, ou seja, certifique-se de que seu serviço produz as métricas de que você precisa. Alguns padores como 4 golden signals, RED E LEV podem fornecer o template inicial para algumas métricas.

Automação

Automatize tudo que possa ser automatizado, mas certifique-se de garantir, como qualquer outro código, a qualidade/confiabilidade por meio de testes.

Engenharia de Release

Tenha padrões de lançamento. Monitore as estatísticas sobre seus lançamentos. Entenda bem como continuous integration (CI), continuous delivery(CD) e continuous deployment (CD) funcionam de verdade.

Simplicidade

Sistemas simples tendem a ser confiáveis ​​e fáceis de operar, porem, medir a complexidade dos sistemas não será uma tarefa fácil. Saber com quanto tempo alguém leva para fazer mudanças, ou o tempo que alguém leva pra ter uma visão abrangente de alto nível do serviço pode ajudar.

Design de Sistema (Grandes) Não Abstrato (NALSD)

Com responsabilidades que abrangem as operações de produção e engenharia de produto, a SRE está em uma posição única para alinhar os requisitos do business case e os custos operacionais. As equipes de engenharia de produto podem não estar cientes do custo de manutenção dos sistemas que projetam. Pratique a capacidade de aferir, projetar e avaliar (grandes) sistemas, não deixe nada “abstrato” antes de implementar algo. Deixar de construir um plano de falha para alguma ponta solta pode custar caro, isso não significa implementar, mas sim que evite ser pego de surpresa se algo falhar. Na fase de concepção use perguntas como:

• É possível?
• Isso é viável?
• É resiliente?
• Podemos fazer melhor?

Desta forma estaremos mais perto de construir sistemas saudáveis e duradouros.

[SRE] Por sistemas mais LEV

Este vai ser um post rápido! 😉 
Estou em uma jornada de confiabilidade (SRE) e aprendendo muito. Uma dificuldade inicial tem sido a evangelização das práticas, e, principalmente, a definição de SLO. Pensando nisso, e muito inspirado no VALET da The Home Depot’s, estamos indo em direção ao LEV (Latency, Errors e Volume), onde temos algumas perguntas para ajudar os devs/produto a construir os seus SLO, segue alguns exemplos:

Latency

• O serviço responde rapidamente quando eu o uso?
  •  Quão rápido meu serviço tem que ser?
  •  O que faremos se o serviço estiver demorando mais que o esperado?

Errors

• O serviço gera um erro quando eu o uso?
  • O que faremos se o serviço estiver com mais erro que o esperado?

Volume (traffic)

• Quanto volume de negócios meu serviço pode suportar?
  •  O que faremos se o volume for maior (ou muito menor) que o esperado?

[ update 2023-11 ]

O termo “Let Go” tem parecido mais promissor, já que, para ir para produção (Go) tem que ter o Let (Latency-Errors-Traffic) definido.