Anomalias de custo como tickets, atribuídas ao time certo antes que alguém leia o Slack

Encaminhe anomalias para o time responsável pelo recurso, como issues no Jira, Linear ou GitHub, com base na severidade, no escopo de faturamento e em como elas foram detectadas.

A detecção de anomalias tem um problema de entrega, não de detecção. O detector dispara, o canal do Slack e a caixa de entrada explodem, e a notificação chega a todo mundo que se inscreveu. Em um time pequeno, isso funciona. Em uma organização onde o time de checkout é dono de um conjunto de contas de faturamento, o time de plataforma de dados é dono de outro e a engenharia de plataforma responde por tudo que for crítico, a mesma notificação atinge quarenta pessoas, das quais trinta e oito não podem fazer nada a respeito. Depois de algumas semanas, o canal é silenciado. Enquanto isso, as duas pessoas que poderiam ter corrigido o agendamento mal configurado só ficam sabendo quando o financeiro pergunta.

Agora o Threads tem regras de automação: você descreve quais anomalias (ou insights) pertencem a qual time e para onde as issues devem ir, e o Cloud Intelligence™ abre o thread no backlog daquele time no momento em que uma anomalia correspondente é detectada.

O que você ganha

Uma regra é um conjunto de condições mais um destino. As condições são os próprios detalhes da anomalia: severidade, o escopo de faturamento em que foi detectada, se veio de dados de faturamento ou de uso em tempo real, seu status de triagem, labels/tags etc. O destino é um projeto, time ou repositório em um tracker (Jira, Linear ou GitHub), junto com o responsável, as labels e o título de issue que você quiser. Assim, "qualquer anomalia crítica" vira uma issue no GitHub para a engenharia de plataforma, "anomalias médias nas contas de faturamento do checkout" vira um ticket no Jira para o time de checkout, e "anomalias em tempo real nos projetos de analytics" vira uma issue no Linear para o time de plataforma de dados. Ninguém mais é acionado. As pessoas que recebem o thread são as que podem mudar alguma coisa.

Você pode pré-visualizar uma regra usando anomalias recentes antes de ativá-la — nada é criado no modo de pré-visualização. As regras são executadas de cima para baixo, e a primeira regra ativa que corresponder trata a anomalia, então basta arrastar as regras específicas para cima das genéricas. Uma regra pode ser pausada sem precisar ser excluída.

A primeira regra que corresponde a uma anomalia cria o Thread principal dela, com as mesmas evidências de um thread criado manualmente: o que foi detectado, onde, quanto foi observado versus esperado, e um link de volta para o pico. Anomalias não são estáticas. Quando uma revisão posterior da mesma anomalia ainda atende às condições, a regra adiciona um comentário à issue existente em vez de abrir uma segunda, mesmo que a issue já esteja fechada, e não mexe no responsável, no status nem em nada que seus engenheiros tenham definido. Cada alteração de regra é mantida como uma revisão imutável, e um log de execução mostra o que disparou, o que foi criado e por quê.

Se o Jira, o Linear ou o GitHub Issues já estiver conectado para o Threads, não há nada novo para instalar. A automação e a criação manual compartilham um único registro, então se um colega abrir um thread manualmente primeiro, a regra reconhece e não cria uma duplicata. Há também um limite diário de criação por conta, para que uma manhã agitada não inunde um backlog.

Comece agora

1. Conecte o Jira, o Linear ou o GitHub Issues, caso ainda não tenha feito isso.
2. Verifique se a detecção de anomalias cobre o escopo que importa para você, incluindo quaisquer alocações que você queira usar nas condições das regras. As regras só enxergam anomalias produzidas pelo detector.
3. Abra o Threads, selecione Thread automation e crie sua primeira regra.

As regras de automação estão disponíveis para qualquer conta com a permissão Thread Manager. O que mais queremos ouvir agora é como suas regras se comportam diante de um mês real de anomalias: quais dispararam quando não deveriam e quais times você ainda não conseguiu alcançar com as condições disponíveis.