Automações¶

Abrir na plataforma

Uma automação liga um gatilho a uma ação: quando algo acontece (um alerta, um chamado, um horário), a plataforma manda um runbook rodar num agente. Esta página explica os gatilhos, os dois tipos de automação (por alerta e por chamado), mais os agendamentos e o histórico de execuções.

Acesse por DevOps → Automações.

Quem usa¶

SRE e plantão: cria automações de auto-remediação para os alertas mais repetitivos.
Suporte e operação: automatiza o atendimento de chamados de rotina e roda runbooks sob demanda.

A lista¶

A tela mostra as automações em cards, agrupadas por família: Observabilidade (disparadas por alerta) e Gestão de Serviços (disparadas por chamado). Cada card leva a Configurar e a Execuções. O botão Adicionar abre a paleta de tipos disponíveis para o seu tenant.

Lista de automações em cards

Os gatilhos¶

O gatilho é o "quando" da automação. Existem três, e a mesma biblioteca de runbooks serve os três:

Gatilho	Dispara quando	Configurado em
Alerta	o monitoramento detecta um problema no escopo que você definiu	automação de Observabilidade (abaixo)
Chamado	um chamado entra numa categoria que você definiu	automação de Gestão de Serviços (abaixo)
Agendamento	chega o horário marcado (a cada N minutos ou diário)	Job Scheduler

Cada agente reúne, num só lugar, tudo que o aciona: no menu do agente em Agentes e Identidades, a opção Gatilhos lista os alertas, chamados e agendamentos que disparam trabalho nele.

Automação por alerta (Observabilidade)¶

É a auto-remediação clássica: um alerta dispara e o agente age. O detalhe da automação tem quatro abas: Ação, Gatilho, Executar agora e Execuções.

Aba Ação¶

Define o que roda: o agente e o runbook. Aqui você também vê quais dados do alerta são enviados ao script (hostname, nome do alerta, severidade, status, id do alerta e tags) e pode adicionar parâmetros fixos extras.

Aba Ação com agente, runbook e dados enviados

Os dados do alerta chegam ao runbook em SP1_PARAMS (a lista completa dos campos está em Runbooks → Quais campos você recebe). O script lê o que precisa; nada disso é tratado como código.

Aba Gatilho¶

Define quando roda. O primeiro campo escolhe o modo:

Por alerta: dispara sozinho quando um alerta casa o escopo (o caso normal).
Só manual: nunca dispara sozinho, só pela aba Executar agora. Útil para um runbook que você quer ter à mão mas não automatizar.

No modo por alerta, você desenha o escopo com quatro filtros:

Filtro	O que faz	Exemplo
Host	limita aos hosts que casam o padrão (aceita curinga `*`)	`web*` pega web01, web02, webproxy
Nome do alerta	limita aos alertas cujo nome casa (aceita curinga); vazio casa qualquer alerta	`CPU`, `Serviço parado*`
Severidade	um ou mais níveis	Crítico, Alto
Tags	casa se o alerta tiver qualquer uma das tags	`apache, http`

Aba Gatilho com escopo do alerta

Os filtros se somam (E), as tags se juntam (OU)

A automação só dispara quando o alerta bate todos os filtros preenchidos ao mesmo tempo (host e nome e severidade). Dentro do campo Tags, basta uma das tags casar. Deixe um filtro vazio para não restringir por ele. Comece restrito (um host, uma severidade) e vá abrindo, é mais seguro que o contrário.

Ainda no Gatilho, dois pontos importantes:

Mirar o host que alertou: adicione, na aba Ação, um parâmetro chamado limit mapeado para o campo hostname. Assim, num runbook Ansible, o --limit restringe a execução ao host exato que disparou, em vez de rodar no grupo inteiro.
Na recuperação: escolha se a automação também roda quando o alerta se resolve (Executar novamente) ou se ignora a recuperação (o padrão). Rodar na recuperação é útil, por exemplo, para reabrir tráfego depois que um serviço volta.

Aba Executar agora¶

Roda a automação na hora, sem esperar o gatilho. Serve para validar o runbook ou agir sob demanda. Informe parâmetros opcionais no formato chave=valor (ex.: host=web03), clique em Executar agora e o log aparece ali, ao vivo.

Aba Executar agora com o console de log

Aba Execuções¶

O histórico desta automação: quando rodou, o status, a origem e o log de cada execução.

Automação por chamado (Gestão de Serviços)¶

Aqui o gatilho é um chamado: quando um chamado entra numa categoria que você definiu, o agente executa o runbook, e o runbook pode até responder de volta no próprio chamado (ver Exemplos → Atender um chamado). É o tipo Chamado aciona agente, na família Gestão de Serviços.

Para criar, em Adicionar escolha Gestão de Serviços → Chamado aciona agente. A configuração tem três partes:

Configuração da automação de chamado: agente, runbook, mapa de parâmetros e escopo por categoria

1. Ação (agente e runbook). Escolha o agente que vai executar e o runbook (a lista mostra o catálogo de runbooks ativos do seu tenant).

2. Mapa de parâmetros (opcional). Cada linha manda um campo do chamado para um parâmetro do runbook (a lista completa está em Runbooks → Quais campos você recebe). Para o runbook conseguir responder no chamado depois, mapeie o ID do chamado para um parâmetro (ex.: ticket_id ← ID do chamado).

3. Escopo (qual chamado dispara). É onde entra a categoria:

Tipo de chamado: Incidente ou Requisição.
Idade mínima: só dispara em chamados com mais de X minutos (evita agir num chamado que o solicitante ainda está editando).
Escopo por categoria: Todas, Só estas ou Todas exceto. No modo "Só estas" (ou "Todas exceto"), você seleciona por Família → Serviço → Subcategoria, que é a árvore de categorias do seu Service Desk. As escolhas viram chips, e a automação só age nos chamados dessas categorias.

Sempre valide em simulação primeiro

A automação de chamado tem um modo simulação (dry-run): ligue-o e a automação mostra quais chamados casariam, sem executar nada nem tocar nos chamados. Confira o escopo, depois desligue a simulação. É a rede de segurança para não disparar num escopo largo demais.

O botão Executar agora roda a automação imediatamente sobre os chamados que estão no escopo (respeitando a simulação, se ligada), útil para testar sem esperar um chamado novo.

Requer Service Desk configurado

A automação por chamado só aparece para tenants com o módulo de Service Desk ativo, porque o escopo lê a árvore de categorias do seu Service Desk. Sem ele, você ainda tem as automações por alerta e os agendamentos.

Agendamentos¶

Quando você não quer esperar um alerta nem um chamado, um agendamento roda o runbook em horários fixos: a cada N minutos ou todo dia num horário e dias da semana. É o substituto do cron espalhado por máquina, centralizado e com histórico.

Acesse por DevOps → Job Scheduler.

Lista de agendamentos com cadência e status

Ao criar, escolha o agente, o runbook, a frequência (intervalo ou diário) e ative. Cada disparo entra na fila do agente e aparece em Execuções; o agendamento também aparece nos Gatilhos do agente. Passo a passo em Exemplos → Limpeza agendada.

Agendamento roda em agente, não na plataforma

O trabalho é enfileirado para o agente daquele ambiente, que executa localmente. Se o agente estiver fora do ar, as execuções ficam na fila até ele voltar (e você pode cancelá-las, ver abaixo).

Execuções¶

Toda vez que um runbook roda, seja por alerta, por chamado, por agendamento ou manual, vira uma execução. A tela reúne o histórico de todos os agentes do tenant.

Acesse por DevOps → Agent runs.

Lista de execuções com agente, runbook, origem, status e resultado

Clique numa linha para ver o log completo e os parâmetros. A coluna Origem diz qual gatilho disparou (Manual, Monitoramento, Chamado, Agendada). Execuções na fila de um agente que está offline ganham um aviso e podem ser canceladas (não vão rodar até o agente voltar). Filtre por status e busque por agente ou runbook.

Relatório¶

O Relatório de automação consolida o que as suas automações entregaram no período: chamados auto-tratados, execuções concluídas dos agentes, tempo estimado economizado e agentes online. Cada card, tipo e agente leva ao detalhe (a lista de execuções filtrada).

Acesse por DevOps → Automation report.

Relatório de automação com indicadores e tendência

Execuções concluídas, não enfileiradas

O relatório conta as execuções que terminaram no período. O que ainda está na fila aparece à parte e não infla os números. O tempo economizado parte dos chamados resolvidos pela automação no Service Desk mais as remediações de alerta concluídas, com minutos por ação ajustados ao seu ambiente; passe o mouse no card para ver a conta.

Próximos passos¶

Exemplos prontos

Receitas completas dos dois gatilhos (alerta e chamado), de copiar e ajustar.

Exemplos
Rever os agentes

Instalação, inventário e ciclo de vida do agente que executa tudo isso.

Agentes de automação