Operaçõesסֵבֶר פָּנִים
ITIL 4 com IA no atendimento: receber cada pessoa com rosto bom
Como a cadeia de valor do ITIL 4 organiza o atendimento, onde a IA classifica, sugere e aprende, e quais métricas o usuário realmente sente.
לְהַעֲלֹת נֵר תָּמִיד
leha'alot ner tamid · para fazer subir uma luz contínua · Shemot 27:20
Blog/Artigos · Operações
Operações de tecnologia com IA: a luz contínua tem orçamento
SLO, error budget e burn rate como base, e a IA correlacionando, diagnosticando e propondo mitigação em cima deles.
A luz do Mishkan precisava ficar acesa sempre, e mesmo assim alguém tinha de preparar o azeite, limpar o pavio e acender de novo todas as tardes. Disponibilidade contínua funciona do mesmo jeito: é um resultado mantido por rotina. Quando cheguei na operação atual, o monitoramento olhava só infraestrutura e produzia centenas de falsos positivos por mês. Trocar isso por 9 SLOs com error budget foi o que deu base para qualquer IA ajudar depois.
Disponibilidade é um número com preço
Um SLO de 99,9% num mês de 30 dias permite 43,2 minutos de indisponibilidade. Cada nove a mais divide esse orçamento por dez, e custa bem mais que dez vezes em redundância, processo e plantão. Por isso a primeira conversa com o negócio é sobre quanto de falha a jornada suporta, antes de falar de ferramenta.
O SLO precisa medir o que o usuário sente: requisição que deu certo, dentro do tempo, na jornada que importa. CPU alta com cliente satisfeito é informação, e fica fora da página. Cliente sem conseguir pagar com a CPU tranquila é incidente. Um SLI bem escolhido separa esses dois casos sem discussão.
Figura 1Orçamento de indisponibilidade por mês, conforme a meta de SLO
Burn rate: alertar pelo ritmo de consumo do orçamento
Burn rate é a velocidade com que o orçamento está sendo gasto. Burn 1 consome exatamente o orçamento no fim da janela de 30 dias. Burn 14,4 consome 2% do orçamento mensal em uma hora, e isso justifica acordar alguém. Burn 1 sustentado por três dias consome 10%, e isso justifica um ticket para o horário comercial.
A combinação de janela longa com janela curta resolve os dois defeitos clássicos do alerta por limiar. A longa garante que o problema é real e relevante. A curta garante que ele ainda está acontecendo, então o alerta para sozinho quando a mitigação funciona.
Figura 2Alertas de burn rate em múltiplas janelas, para SLO de 30 dias
| Burn rate | Janela longa | Janela curta | Orçamento consumido | Ação |
|---|---|---|---|---|
| 14,4 | 1 hora | 5 minutos | 2% | página para o plantão |
| 6 | 6 horas | 30 minutos | 5% | página para o plantão |
| 1 | 3 dias | 6 horas | 10% | ticket no horário comercial |
O orçamento visto como curva
A curva de orçamento restante mostra o que o número isolado esconde. Consumo em ritmo 1 termina o mês em zero, exatamente como planejado. Ritmo 2 esgota o orçamento na metade do mês e deixa quinze dias sem margem nenhuma. Um incidente grande no dia 10 cria um degrau, e o ritmo normal depois dele termina o orçamento dez dias antes do fim.
É essa curva que sustenta a política de error budget. Com orçamento sobrando, o time tem licença para arriscar mudança. Com orçamento acabando, mudança de risco congela e o esforço vai para confiabilidade. A decisão deixa de ser opinião de quem grita mais alto na reunião.
Figura 3Orçamento restante ao longo de um mês, em três cenários
- consumo em ritmo 1
- consumo em ritmo 2
- ritmo 1 com incidente de 30% no dia 10
Ver os dados da figura
| dia do mês | consumo em ritmo 1 | consumo em ritmo 2 | ritmo 1 com incidente de 30% no dia 10 |
|---|---|---|---|
| 0 | 100 | 100 | 100 |
| 10 | 66,7 | ||
| 10,2 | 36,7 | ||
| 15 | 0 | ||
| 21,2 | 0 | ||
| 30 | 0 | 0 | 0 |
Onde a IA entra na operação
AIOps costuma ser vendido como detecção mágica. Na minha experiência o ganho real está depois do alerta: juntar os sinais que pertencem ao mesmo problema, levantar hipóteses de causa com base no que já aconteceu antes e preparar a mitigação para quem está de plantão.
Para o diagnóstico funcionar, o modelo precisa de memória institucional. Runbook, postmortem, histórico de mudança e topologia de dependência entram numa base consultada por RAG, com cada resposta citando o documento de origem. Sem citação, o plantonista não consegue verificar em dois minutos, e hipótese que não se verifica em dois minutos não serve às 3h da manhã.
Figura 4Ciclo de resposta com IA, do sinal ao aprendizado
- 01Detectarburn rate do SLO dispara, anomalia chega como contexto
- 02IACorrelacionaragrupa alertas, mudanças e dependências do mesmo problema
- 03IADiagnosticarhipóteses com citação de runbook e postmortem
- 04IAMitigarrollback ou failover preparado, executado com aprovação
- 05Aprenderpostmortem sem culpado vira ação, teste e documento na base
cada postmortem entra na base consultada pelo diagnóstico do próximo incidente.
O humano no circuito, pelo critério certo
A pergunta sobre o que automatizar costuma ser feita em termos de confiança no modelo. Eu prefiro dois critérios mais objetivos: o tamanho do estrago se a ação estiver errada e a facilidade de desfazer. Reiniciar um pod sem estado é barato e reversível. Apagar dado, mexer em DNS de produção ou alterar permissão exigem gente.
Essa matriz vira política escrita, revisada em GMUD, e cada automação declara em qual quadrante está. Quando alguém quer mover uma ação de quadrante, a mudança passa pelo mesmo rito de qualquer outra mudança em produção.
Figura 5Quanto a IA pode fazer sozinha, conforme impacto e reversibilidade
Impacto se a ação estiver errada
Facilidade de desfazer
Só humanoalto impacto e difícil de desfazer: apagar dado, alterar DNS, mudar permissão. A IA prepara o contexto.
IA propõe, humano aprovaalto impacto e fácil de desfazer: rollback de deploy, failover ensaiado.
IA sugere com evidênciabaixo impacto e difícil de desfazer: limpeza de recurso, rotação fora de hora.
Automatizarbaixo impacto e fácil de desfazer: reiniciar réplica sem estado, escalar horizontalmente.
Para levar
IA em operação funciona quando a operação já tem estrutura: SLO medindo o que o usuário sente, alerta por burn rate, runbook e postmortem escritos e uma política clara de quem pode fazer o quê. Com essa base, o modelo correlaciona, diagnostica e prepara a mitigação. Sem ela, ele só acelera o ruído que já existia.
Quem escreve: Juliano Vince de Campos
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
