Padronizando um sistema de alertas e operando-o com IaC
(engineering.ab180.co)Introdução
À medida que o serviço crescia, também aumentavam os sinais que precisávamos verificar durante a operação. Neste artigo, apresento o processo de gerenciar Alerts como código e de padronizar o fluxo de resposta que passa por Slack e PagerDuty.
O objetivo inicial era simples: tornar os Alerts mais fáceis de criar, enviá-los de forma mais legível e deixar claro quem deveria vê-los. Depois, conforme seguimos operando, também refinamos os Alerts agrupados, as definições repetidas, a automação de respostas e até a estabilidade do sistema de monitoramento.
Motivação
Há várias formas de aumentar a disponibilidade de um serviço e reduzir o impacto sobre os usuários
Entre elas, este trabalho se concentrou na melhoria do sistema de Alerts
Alerts são mais próximos de uma interface operacional que conecta prevenção e resposta a incidentes. Ao identificar sinais de risco mais cedo, é possível agir antes que eles se tornem incidentes reais; e, mesmo depois que um incidente ocorre, os responsáveis conseguem percebê-lo mais rapidamente e iniciar a resposta
A direção que queríamos seguir também estava clara na época. Queríamos capturar melhor os sinais de risco, fazer com que os responsáveis os percebessem mais rapidamente, conectá-los imediatamente à investigação e à resposta e reduzir fluxos de resposta repetitivos
Não começamos medindo tudo quantitativamente desde o início, mas tínhamos uma consciência clara do problema: Alerts não deveriam ser simples notificações, e sim um sistema operacional que previne incidentes e os conecta à resposta
O papel dos Alerts
Para manter um serviço estável, prevenir incidentes é importante, mas detectar rapidamente sinais anormais em um serviço em operação também é
Alerts desempenham dois papéis nesse ponto. Antes que um incidente aconteça, ajudam a perceber rapidamente sinais de risco e agir com antecedência antes que eles se transformem em um incidente real; depois que um incidente acontece, informam o responsável sobre o problema e conectam a próximos passos como contexto, Runbook, Dashboard, Log e Silence, necessários para entender a situação
Ou seja, um Alert não é apenas uma notificação dizendo "houve um problema", mas algo mais próximo de uma interface operacional que conecta prevenção e resposta a incidentes
Pontos fracos dos Alerts existentes
Havia três grandes pontos fracos nos Alerts existentes: eram difíceis de criar, eram difíceis de entender imediatamente ao recebê-los e não estava claro quem deveria responder a eles e gerenciá-los
Era difícil criar Alerts
Na época, a criação e entrega de Alerts envolvia vários sistemas, como Grafana, Slack, PagerDuty, CloudWatch, EventBridge e Lambda, e as fontes de dados também eram variadas, incluindo NewRelic, VictoriaMetrics, Steampipe, OpenSearch, Druid e MySQL
O modo de trabalho também variava de um Alert para outro. Alguns Alerts eram enviados diretamente do Grafana para o Slack; outros tinham uma Lambda acoplada depois de um CloudWatch Alarm; outros consultavam o estado de recursos da AWS via Steampipe para tomar uma decisão; e, quando era necessário integrar com o PagerDuty, ainda era preciso considerar configurações adicionais
O problema era a falta de convenções em nível organizacional. Ainda não estava bem definido onde cada Alert deveria ser gerenciado, se ele deveria ser enviado apenas ao Slack ou também conectado ao PagerDuty, quais descrições e links deveriam entrar na mensagem, e onde seriam gerenciados o time responsável e a rota de entrega
Como resultado, Alerts eram criados sempre que necessário, mas, com o tempo, as formas de criação e gestão foram ficando cada vez mais fragmentadas
Era difícil ler os Alerts
Criar um Alert não significava que a mensagem real no Slack sempre teria um formato fácil de ler. O formato e a qualidade das informações variavam conforme a pessoa que criava e o sistema, alguns Alerts tinham títulos longos e complexos, e valores internos como Value ou Labels às vezes eram expostos sem tratamento
Mesmo quando havia links, nem sempre ficava claro o que deveria ser visto primeiro; e, em alguns casos, embora houvesse botões de Dashboard ou Log, a integração real não funcionava. Além disso, muitas vezes faltava contexto no Alert, fazendo com que o responsável tivesse de procurar novamente o serviço, o cluster, o recurso e o intervalo de tempo
Em uma situação de incidente, uma diferença de poucos minutos parece grande. Por isso, no momento em que alguém recebe um Alert, deveria ser possível entender imediatamente qual é o problema, quão importante ele é, qual serviço e recurso estão envolvidos, onde verificar primeiro e qual é o próximo passo
Era difícil gerenciar a responsabilidade pela resposta ao Alert
Quando um Alert disparava, também havia casos em que não estava claro quem deveria verificá-lo e responder. Se o time ou a pessoa responsável não aparecesse, quem visse o Alert precisava primeiro decidir "sou eu que devo olhar isso?", "a quem devo perguntar?", e, em uma situação de incidente, até esse breve julgamento podia atrasar a resposta
Além da responsabilidade pela resposta depois que o Alert disparava, também era importante saber quem era dono e gerenciava o próprio Alert. Precisava ficar visível a qual time o Alert relacionado a um serviço pertencia, quem poderia alterar as condições, como revisar a mensagem ou os limites, e quem removeria Alerts antigos
Em resumo, a situação que queríamos melhorar era a seguinte
- A forma de criar e gerenciar Alerts estava fragmentada
- Mesmo recebendo um Alert, era difícil entender seu significado de relance
- Quando um Alert disparava, era ambíguo quem deveria verificá-lo e responder
- Também não estava claro qual time deveria ser dono e gerenciar o próprio Alert
O que e como melhoramos
Havia três direções de melhoria: padronizar a forma de criar Alerts, fornecer as informações necessárias nas mensagens do Slack em uma estrutura consistente e organizar a estrutura para que responsáveis e rotas de entrega ficassem explícitos em cada Alert
Padronizar a forma de criar e gerenciar Alerts
Primeiro, unificamos a forma de criar e gerenciar Alerts. A avaliação e execução das regras de Alert foram unificadas no Grafana; a integração entre Grafana, Slack e PagerDuty foi abstraída em Terraform Modules; e todas as definições de Alert passaram a ser gerenciadas como IaC no diretório alerts/ do repositório interno de alerts. A conexão com canais do Slack, a integração com PagerDuty, o formato das mensagens e a criação de botões comuns também foram organizados para serem tratados por módulos compartilhados
Agora, em vez de precisar entender todo o pipeline de Alerts, quem escreve um Alert consegue se concentrar mais em qual condição detectar, qual é a criticidade do Alert, quem deve verificá-lo e quais informações são necessárias para a resposta
Dentro do repositório, também mantivemos o modo de escrita, a estrutura de diretórios, os campos necessários e as convenções recomendadas; e, ao gerenciar Alerts como código, revisões e histórico de mudanças passaram a ficar registrados por PRs e commits
Estrutura de diretórios dos Alerts
Organizamos todos os Alerts para seguir a estrutura {main-category}/{sub-category}/{severity}/{alert-name}.yml
Por exemplo
infra/kubernetes/critical/pod-unhealthy.ymldata/airflow/warning/task-failed.ymlfinops/aws/warning/cost-increase.yml
Com essa estrutura, só de olhar a localização do arquivo passou a ser possível entender a qual área o Alert pertence e com que nível de severidade ele deve ser tratado. Ela também pôde ser usada como critério para reunir Alerts de uma área específica, verificar Alerts duplicados ou antigos e conectar canais do Slack, PagerDuty Service e CODEOWNERS
Forma de definir Alerts
Cada arquivo de Alert inclui informações como datasource, query, threshold, condition e message
Não criamos uma DSL separada. Era algo próximo de representar em YAML o conteúdo serializado em JSON de um Grafana Alert; graças a isso, se um Alert podia ser definido no Grafana, na maioria dos casos ele também podia ser convertido para IaC com a mesma estrutura
Recentemente, também estamos usando LLMs. Quando uma pessoa explica em linguagem natural "em quais condições e com qual mensagem quero receber um Alert", a LLM consulta exemplos existentes e convenções para criar um rascunho de definição de Alert em YAML. Com isso, quem escreve Alerts consegue se concentrar mais em o que detectar e por que isso é necessário do que em um formato de serialização complexo
Fazer com que a mensagem do Alert pudesse ser entendida e acionada imediatamente
Também vimos a mensagem de Alert como uma interface. Como em uma situação de incidente não há muito tempo para interpretar a mensagem com calma, precisávamos conseguir verificar o mesmo tipo de informação no mesmo lugar, independentemente de qual Alert chegasse
Por isso, organizei a estrutura das mensagens no Slack de forma consistente. O título passou a incluir o nome do alerta, o status e a severidade; no corpo, coloquei uma descrição que uma pessoa pudesse entender de imediato, além de responsável, equipe, serviço, região, nome do recurso e principais labels. Também dividi os botões entre botões comuns e opcionais: por padrão, oferecemos IaC, PagerDuty, Silence e, só quando necessário, exibimos Runbook, Dashboard, Log.
Os botões comuns passaram a ser gerados automaticamente pelo sistema e vinculados aos destinos correspondentes, e todas as mudanças de estado do alerta também passaram a ficar registradas em uma thread do Slack. Assim, dá para ver em um único fluxo quem deu Acknowledge, se o tratamento foi feito pelo Slack ou pelo PagerDuty, quando foi resolvido e quais anotações foram deixadas durante a resposta.
Como resultado, independentemente de quem criasse um alerta, o formato exibido no Slack ficou parecido, e os membros da equipe passaram a conseguir decidir mais rapidamente para onde olhar.
Deixar clara a estrutura de responsabilidade dos alertas
Tão importante quanto entender um alerta de imediato era deixar visível quem deveria assumir a responsabilidade por verificá-lo.
Por isso, usamos as informações de tags e labels dos recursos no fluxo de resposta. Em vez de definir diretamente uma equipe ou uma pessoa responsável para cada alerta, usamos metadados como serviço, equipe, recurso e ambiente para que a equipe e a pessoa responsáveis fossem mencionadas automaticamente na mensagem do Slack.
O caminho de entrega também foi organizado dentro da mesma regra. Com base na classificação e na severity do alerta, o canal do Slack, o PagerDuty Service e a Escalation Policy passaram a ser conectados automaticamente. Alertas de nível Warning eram enviados apenas ao canal do Slack, enquanto alertas Critical, com impacto para usuários ou alta possibilidade de incidente, também criavam um PagerDuty Incident.
Também usamos CODEOWNERS em conjunto. Os arquivos de alerta foram separados em diretórios de acordo com categoria e área de serviço, e as equipes responsáveis por cada caminho foram definidas no CODEOWNERS, deixando claro dentro do repositório qual equipe era dona de cada área de alertas.
Com isso, a responsabilidade pelos alertas passou a ser gerenciada em dois pontos. Quando o alerta realmente disparava, a equipe e a pessoa responsáveis eram mencionadas com base em tags e labels; e, ao alterar a definição do alerta, era possível verificar a qual equipe aquela área pertencia com base na estrutura de diretórios e no CODEOWNERS.
O papel do proxy de alertas
Para que essa estrutura funcionasse de fato, era necessária uma camada intermediária que interpretasse e encaminhasse os alertas. Por isso, colocamos um proxy baseado em AWS Lambda entre Grafana, Slack e PagerDuty.
O Grafana avalia a regra de alerta e envia um webhook. O proxy recebe esse webhook, interpreta o contexto do alerta, como category, severity, label, annotation e fingerprint, e decide para qual canal do Slack enviar, qual PagerDuty Incident criar, quem mencionar, quais botões anexar, como atualizar a thread existente no Slack e como gerenciar o ciclo de vida de Ack/Resolve.
Ou seja, se o módulo Terraform e a estrutura de diretórios padronizaram "como definir alertas", o proxy ficou responsável por conectar essa definição para que ela aparecesse e se comportasse da mesma forma no fluxo operacional real.
Graças ao proxy, conseguimos gerenciar de forma consistente, em um só lugar, o formato das mensagens no Slack, as menções a responsáveis, a integração com o PagerDuty, as atualizações de threads no Slack e as interações de Ack/Resolve. Depois disso, também ficou mais fácil expandir melhorias como alertas agrupados, botões de ação personalizados, integração com agentes de IA e um modelo comum de alertas.
O que ainda deixava a desejar
Depois da primeira melhoria, as definições de alerta passaram a ser gerenciadas como IaC, e as mensagens no Slack e os caminhos de entrega também passaram a funcionar sob regras consistentes. Mas um sistema de alertas não é uma ferramenta que se cria uma vez e pronto. Após quase um ano de operação, conforme o número de alertas aumentava, começaram a aparecer novos problemas: como exibir várias instâncias geradas dentro do mesmo alerta, como gerenciar definições repetidas de alertas, o que permitir que uma pessoa faça de fato depois de ver um alerta e como garantir e validar a estabilidade do próprio sistema de alertas.
Quando o mesmo alerta dispara ao mesmo tempo para vários alvos, fica difícil de visualizar
À medida que ficou mais fácil criar alertas, a quantidade de alertas também aumentou naturalmente. Nesse momento, o que era especialmente incômodo eram os casos em que uma única regra de alerta disparava simultaneamente para vários alvos.
No Grafana, mesmo que seja a mesma regra, se os valores de labels como region, name, node, pod e app forem diferentes, cada um é tratado como uma instância de alerta separada. Por exemplo, quando há um alerta de Pod unhealthy, se vários pods ficam unhealthy ao mesmo tempo, uma instância de alerta é criada para cada pod.
O Grafana já tinha um recurso de Alert Grouping, mas simplesmente juntar em um grupo não era suficiente. O importante era mostrar o estado dos alertas agrupados de uma forma fácil para o operador entender: quais alvos existem dentro do grupo, quais ainda estão firing, quais acabaram de ser resolvidos, se há novos alvos adicionados e se as mudanças de estado do mesmo grupo seguem como um único fluxo.
As definições repetidas de alertas aumentaram
Conforme as definições de alerta aumentavam, a abordagem de copiar YAML e alterar pequenas partes também começou a mostrar limites. Alertas como SQS lag, CloudWatch error log, Pod OOM, ALB 5xx e erro/throttle de Lambda passaram a ser criados repetidamente; no começo, bastava copiar um arquivo existente e mudar nome, query, threshold e label.
Mas, com muitos arquivos, ficou difícil corrigir comportamentos comuns, e surgiram problemas em que alertas com a mesma intenção tinham pequenas diferenças em links de dashboard, composição de labels e forma de expressar thresholds. Por isso, era necessária uma estrutura capaz de reutilizar padrões recorrentes.
Mesmo depois de ver o alerta, ainda havia distância até a próxima ação
Adicionar botões de Runbook, Dashboard, IaC e PagerDuty às mensagens do Slack ajudou, mas em respostas reais a incidentes, só links muitas vezes não eram suficientes. Em especial, o Runbook tinha um efeito claro, mas não era fácil anexar um bom Runbook a todos os alertas e mantê-los sempre atualizados.
Além disso, nas respostas reais, tarefas de investigação parecidas se repetem sempre: verificar logs do Kubernetes, checar o estado de pods, consultar o histórico de rollout, verificar métricas de SQS e Lambda, conferir error logs. A maior parte dessas tarefas acontecia fora da mensagem do Slack; a pessoa responsável precisava ler labels e valores no alerta, ir para outra ferramenta, copiar os valores e depois compartilhar o resultado de volta na thread do Slack.
No fim, a primeira melhoria fez com que os alertas ficassem mais fáceis de ler, mas a investigação e a resposta ainda permaneciam muito fora da mensagem de alerta.
Os SPOFs no sistema de monitoramento aumentaram
Ao organizar o sistema de alertas, os pontos que poderiam se tornar SPOF também aumentaram. A definição e o deploy das regras de alerta ficaram concentrados no repositório de alerts e no Terraform; a avaliação das regras ficou a cargo do Grafana; e as mensagens no Slack, os PagerDuty Incidents e o ciclo de vida de Ack/Resolve passaram a ser gerenciados pelo proxy.
A clareza dos papéis foi uma boa mudança, mas também aumentou a possibilidade de que, se um desses pontos falhasse, todo o fluxo de alertas fosse afetado. O mais difícil é que esse tipo de falha pode não aparecer de forma evidente. Se o caminho que avisa sobre anomalias em outros sistemas parar silenciosamente, um incidente real pode acontecer sem que ninguém perceba.
No fim, isso levou à pergunta: "quem monitora o sistema de monitoramento?"
Segunda melhoria
Com a primeira melhoria, a estrutura básica do sistema de alertas ficou definida, mas, à medida que criar e enviar alertas ficou mais fácil, os problemas a observar durante a operação também mudaram.
Na segunda melhoria, focamos em quatro pontos: agrupar em uma única visão as mudanças de estado quando vários alvos disparam ao mesmo tempo a partir da mesma regra de alerta, permitir reutilizar definições repetidas de alertas como padrões comuns, complementar os Runbooks conectando investigações recorrentes e ações limitadas de mitigação a botões no Slack e medir e validar a estabilidade dos caminhos de definição, avaliação e entrega dos alertas, que poderiam se tornar SPOFs.
Tratar corretamente alertas agrupados
Primeiro, melhoramos a forma de representar Alerts agrupados. Quando várias instâncias disparam ao mesmo tempo a partir da mesma regra de Alert, enviar cada uma como uma mensagem independente deixa o canal do Slack confuso; por outro lado, se tudo for agregado em um único grupo, fica fácil perder de vista qual recurso de fato está com problema.
O ponto central é agrupar, mas sem perder o estado do que está dentro do grupo. No Slack, passamos a mostrar o Alert agrupado como uma mensagem representativa, mas exibindo junto os alvos atualmente afetados; quando um novo alvo é adicionado ou um alvo existente é resolvido, essa mudança fica registrada na mesma thread. Quando muitas mudanças de estado acontecem de uma vez, elas são mostradas em lote, e o lado do PagerDuty também foi ajustado para apontar para o mesmo problema visto no Alert agrupado no Slack.
Com isso, vários Alerts originados da mesma causa passaram a ser vistos no Slack como um único fluxo.
Reduzindo definições repetidas de Alert
O modelo de copiar e alterar pequenos trechos aumenta o custo de manutenção e a chance de erros conforme a quantidade de Alerts cresce. Para reduzir isso, adicionamos global/templates e matrix.
global/templates é um recurso para definir estruturas repetidas de Alert como templates comuns, e matrix é um recurso para expandir o mesmo Alert em várias combinações de região, queue, datasource e service, gerando múltiplos Alerts.
Transformamos padrões repetidos — como lag de queue SQS, logs de erro do CloudWatch, Pod OOM em vários clusters, ALB 5xx, erros/throttling de Lambda e memória/CPU/capacidade máxima de ECS — em templates, deixando para informar na matrix apenas os valores que variam, como nome da queue, region, cluster, threshold e variáveis de dashboard.
Com isso, passamos a conseguir ajustar em um só lugar a estrutura comum das mensagens, os botões, o tratamento de links de Runbook/dashboard e a forma de lidar com datasources, além de reduzir inconsistências e custos de manutenção que surgem conforme o número de Alerts aumenta.
Começando a responder diretamente pela mensagem do Slack
Em seguida, aumentamos o que era possível fazer dentro da mensagem do Slack. Links para Runbook e dashboard continuam importantes, mas queríamos reduzir, dentro da própria mensagem do Slack, consultas repetitivas e ações limitadas de mitigação que eram feitas de forma parecida todas as vezes.
Por isso, além dos botões existentes, adicionamos um custom action button. Ao definir um comando em message.actions no YAML do Alert, ele aparece como um botão na mensagem do Slack; ao clicar no botão, o proxy executa o comando por meio de uma invocação separada de Lambda e deixa, na mesma thread do Slack, um comentário com quem clicou em qual botão e o resultado da execução.
Com esse botão, passamos a oferecer operações como consulta de logs, verificação do status de rollout no Kubernetes, rollout restart em situações limitadas, execução de um único comando e execução sequencial de vários comandos.
A parte que recebeu mais atenção foi a segurança. Quando o nome do botão termina com !, exibimos uma caixa de confirmação do Slack; valores de labels como ${labels.namespace} e ${labels.pod} são substituídos no comando com shell quoting aplicado para evitar command injection; e operações que exigem permissões adicionais passam a assumir um IAM role por meio de actionRole. O uso de roles não permitidas é tratado como fail-closed, e tanto webhooks quanto interações do Slack são validados com Bearer token, assinatura HMAC-SHA256 e proteção contra replay.
Integração com o agente de IA
Também queríamos reduzir o processo de coletar as informações necessárias depois de receber um Alert. Por isso, conectamos o agente de IA interno, abot, ao fluxo de Alerts.
Quando o botão do abot na mensagem do Slack é acionado, o proxy reúne o nome do Alert, a descrição, labels, values, links de IaC e o contexto adicional informado pelo usuário no modal, e envia uma solicitação de análise. O abot opera com a identity baseada em OAuth da pessoa que clicou no botão, de modo que, mesmo ao consultar informações necessárias no Grafana, AWS, Kubernetes etc., ele busque apenas aquilo que o usuário realmente poderia ver.
O resultado da análise fica como comentário na mesma thread do Slack. Também passamos a registrar quais métricas e logs foram verificados, quais hipóteses podem ser investigadas primeiro e quais pistas valem ser incluídas em uma RCA, reduzindo o tempo gasto abrindo vários sistemas e reunindo informações novamente.
Monitorando o sistema de monitoramento
Na segunda melhoria, incluímos como alvo de observabilidade o próprio processo de definir, avaliar e entregar Alerts.
Primeiro, coletamos métricas operacionais do proxy. Passamos a coletar métricas como tempo até o Ack, tempo até o Resolve, número de Alerts ativos no momento, há quanto tempo um Alert está ativo e quantas vezes o mesmo Alert voltou a disparar; também adicionamos um watchdog para detectar quando a Lambda se aproxima do timeout. Se o proxy falhar durante o processamento, ele passa a registrar o stack trace completo junto com o payload original do evento.
Mas havia um limite em fazer o próprio proxy enviar notificações. Se o proxy morrer antes mesmo de enviar essa notificação, o Alert que deveria ter sido enviado pode simplesmente ser perdido.
Por isso, colocamos mecanismos de detecção fora do proxy, apoiados em sistemas diferentes. Um deles é o Grafana: as métricas enviadas pelo proxy são avaliadas como Alerts no domínio de monitoring para expor anomalias. Porém, como Grafana e VictoriaMetrics ficam no mesmo EKS, se o EKS ou o Grafana cair por completo, isso não pode ser detectado.
O outro foi um deadman switch. Quando o Grafana está saudável, ele emite /api/health como heartbeat, e esse heartbeat é recebido pelo CloudWatch, que é independente do EKS. Se o heartbeat cair ou ficar ausente, o CloudWatch alarm considera isso uma falha e, nesse caso, notifica diretamente o PagerDuty e o Slack, sem passar pelo Grafana nem pelo proxy.
Ou seja, quem detecta e quem é detectado ficam em infraestruturas diferentes; com isso, enquanto EKS e CloudWatch não caírem ao mesmo tempo, conseguimos saber quando o sistema de monitoramento está fora do ar.
Próximas melhorias
A segunda melhoria foi concluída, mas ainda há pontos a evoluir.
Usar melhor as métricas operacionais coletadas
Com o proxy coletando métricas operacionais dos Alerts, passamos a poder responder com dados a perguntas como: em qual canal quais Alerts disparam e com que frequência, se um responsável ou time específico está recebendo Alerts em excesso, ou se há Alerts que apenas repetem firing e auto resolve sem nenhuma interação.
Mas conseguir ver os dados e, com base neles, realmente refinar os Alerts são coisas diferentes. Ainda não avançamos de forma estruturada em melhorias como ajuste de thresholds, agrupamento de Alerts semelhantes, remoção de Alerts desnecessários, redução de noisy alerts e redução efetiva do tempo de percepção e de resolução.
Melhorias no IaC de Alerts
Atualmente, as definições de Alert são implantadas via CI/CD a partir do repositório de alerts, mas ainda dependem do recurso grafana_rule_group do Grafana Terraform provider. O problema é que, mesmo quando apenas uma rule muda, o PR parece mostrar a alteração do rule group inteiro, dificultando a leitura do diff; além disso, como interval_seconds é definido no nível do rule group, é preciso dividir os groups em partes menores para dar ciclos de avaliação diferentes a cada Alert.
Recentemente, o Grafana passou a ter uma nova API de alerting que trata Alert rules como recursos do Kubernetes, e o Terraform provider adicionou o recurso grafana_apps_rules_alertrule_v0alpha1. Como ainda está em alpha, estamos adiando a adoção imediata, mas pretendemos avaliar a migração a partir do grafana_rule_group quando ele ficar estável.
O que esperamos é claro: definir rule groups e rules separadamente, obter um diff limpo que mostre apenas a mudança quando uma única rule é alterada, ajustar com granularidade o ciclo de avaliação por rule e usar os recursos de monitoramento de forma mais eficiente.
Encerrando
O objetivo inicial era simples: tornar Alerts mais fáceis de criar, mais fáceis de entender de relance quando recebidos e deixar claro quem é responsável por eles.
Na primeira melhoria, reunimos as definições de Alert como IaC, padronizamos as mensagens do Slack e as rotas de entrega, conectamos mentions dos responsáveis ao CODEOWNERS e organizamos o gerenciamento do ciclo de vida Slack/PagerDuty por meio do proxy.
Os problemas que apareceram ao longo da operação foram tratados em uma segunda rodada de melhorias. Alertas disparados pela mesma rule passaram a ser agrupados em uma única visualização, definições repetitivas foram reduzidas com template e matrix, ficou possível iniciar a investigação e a mitigação dentro da mensagem do Slack, e também foi criado um mecanismo para perceber quando o próprio sistema de monitoramento parasse.
Com isso, criar, enviar e responder a alertas ficou mais fácil do que antes.
Ainda assim, conseguir visualizar os dados e usar esses dados como base para melhorar a operação na prática são coisas diferentes. Se até agora o trabalho foi padronizar o sistema de alertas e torná-lo mensurável, daqui em diante resta reduzir e refinar de fato olhando para esses números.
Há conteúdos que não puderam ser incluídos neste texto por questão de extensão. Para quem quiser mais detalhes, recomendo ler também o artigo original.
Ainda não há comentários.