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.

[SRE] Usando Multiwindow, Multi-Burn-Rate Alerts

Alerta	Janela longa	Janela curta	Duração	Taxa de queima	Orçamento consumido
P1	1h	5m	2m	14.4	2%
P2	6h	30m	15m	6	5%
P3	24h (1d)	2h	1h	3	10%
P4	32h (3d)	6h	3h	1	10%

No contexto tecnológico atual, a implementação de alertas multiwindow e multi-burn-rate representa uma abordagem inovadora para o monitoramento eficiente de sistemas. A capacidade de visualizar simultaneamente várias interfaces, combinada com alertas sensíveis a diferentes intensidades operacionais, oferece uma visão abrangente e em tempo real das operações críticas. Essa integração não apenas melhora a capacidade de resposta a eventos urgentes, mas também permite uma alocação eficiente de recursos, destacando-se como uma solução valiosa para ambientes empresariais que demandam agilidade e adaptabilidade na gestão de sistemas complexos.

Usando Multiwindow, Multi-Burn-Rate Alerts do cap 5 – Alerting on SLOs com as considerações do Björn “Beorn” Rabenstein

Tabela com 30 dias de janela

• Alerta
  • Os alarmes podem ter sua criticidade mais elevada (P1) ou podem ser apenas avisos de algo que não anda bem (P4)
  • Janela longa e Janela curta
    • AS janelas de queima múltipla servem para notificar apenas quando ainda estivermos queimando ativamente o orçamento
    • Uma boa diretriz é fazer com que a janela curta tenha 1/12 da duração da janela longa.
      
• Duração
  • Um tempo arbitrário, que normalmente é a metade da janela curta, pra evitar que um alarme fique sendo acionado com frequência.
    Um tempo arbitrário, que normalmente é a metade da janela curta, pra evitar que um alarme fique sendo acionado com frequência.
    
• Taxa de queima
  • formula: burn rate = budget consumed x period / alert window
    Exemplo:
    budget consumed = 2%
    period = 30 dias = 30*24 = 720
    alert window = 1h (janela de longa duração)
    burn rate = 0.02 * 720 / 1 = 14.4
  • A taxa de erro média é exatamente o fator 1, a taxa de erro que você poderia sustentar sem estourar seu orçamento de erro
  • Com o orçamento de erro de 0,1% (SLO 99.9%), se sua taxa de queima for 14,4% em média ao longo de uma hora (janela lonja), você obtém um alerta P1, e no momento em que a obtém , você queimou 2% do seu orçamento mensal de erros, em apenas uma hora! Isso é muito rápido. É aqui que alguém tem que acordar e consertar.
    
• Orçamento consumido
  • Orçamento consumido na janela prevista. De acordo com a tabela, em 3d com taxa de queima 1 iremos consumir 10% do orçamento

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.