Release e Operação

Sexta-feira, 22h10. A versão v1.8.0 do inventory chegou a 25% do tráfego há vinte minutos; agora a taxa de erros na confirmação de reservas está subindo e o engenheiro de plantão tem três dashboards, dois alertas, um fluxo de logs e um canal de chat se enchendo de perguntas. Toda informação necessária para decidir está em algum lugar. O que falta é um resumo rápido e correto — e uma decisão que não dependa do cansaço do engenheiro. A IA é muito boa na primeira coisa. Ela não pode ser quem toma a segunda.

Esta página trata das etapas depois do merge — liberação e operação — sob uma regra de projeto:

A IA propõe e explica; políticas e humanos decidem.

Decisão vs. explicação

O padrão é o mesmo da revisão de código: a saída do modelo é texto para um humano ou dados para uma regra, nunca uma ação direta sobre a produção.

Notas de versão e changelogs

As notas de versão atendem a dois públicos: operadores ("o que preciso fazer antes do deploy da v1.8.0? que migrações rodam?") e usuários ("o que há de novo?"). Ambas as respostas podem ser derivadas dos commits, títulos de PR, rótulos e arquivos de migração — se eles forem bem escritos. Um modelo os agrupa e reescreve em minutos. O modo de falha é a invenção plausível: uma funcionalidade que soa correta, um número de ticket que não existe.

A correção é uma verificação de ancoragem em código: todo item precisa citar um SHA de commit ou número de PR que esteja de fato no intervalo previous_tag..tag; itens sem ancoragem são descartados e reportados. A verificação pega invenções; ela não consegue pegar um resumo errado de um commit real, por isso as notas são publicadas como rascunho que uma pessoa edita. Assuntos de commit no padrão Conventional Commits (fix(inventory): hold expires two minutes early (#212)) tornam tanto o agrupamento quanto a ancoragem quase triviais — o modelo não consegue recuperar uma intenção que nunca foi escrita.

def real(ref: str) -> bool:
    if ref.startswith("#"):
        return ref[1:] in prs
    return len(ref) >= 7 and any(s.startswith(ref) or ref.startswith(s) for s in shas)

def grounded(item: dict) -> bool:
    return any(real(r.strip()) for r in item["refs"])

kept = [i for i in data["items"] if grounded(i)]
dropped = [i for i in data["items"] if not grounded(i)]

Pontuação de risco de mudanças

Nem todas as mudanças merecem o mesmo rollout. Uma mudança de texto de uma linha no notification e uma nova estratégia de travamento no inventory passam ambas pelo pipeline, mas a segunda merece um segundo revisor, um canary mais lento e nenhum deploy na véspera de uma abertura de vendas. Uma pontuação de risco direciona as mudanças para a dose certa de cautela.

Os sinais mais fortes são estruturais e baratos de calcular:

Um modelo contribui com duas coisas: sinais semânticos difíceis de calcular ("isto muda como as reservas expiram", "isto remove uma verificação de autorização") e um resumo legível de por que a pontuação está alta. A pontuação em si fica melhor como uma fórmula transparente ou um modelo simples treinado no histórico, e ela deve apenas direcionar — exigir um segundo revisor, escolher o perfil de canary lento, bloquear deploys dentro de uma janela de congelamento por política —, nunca aprovar ou rejeitar uma mudança sozinha.

Análise de canary: a estatística decide, o modelo explica

A análise automatizada de canary compara o canary com um baseline rodando ao mesmo tempo — idealmente um baseline do mesmo tamanho e idade do canary, para que caches frios e pods novos afetem os dois igualmente — em um conjunto de métricas, e transforma a comparação em um veredito de aprovado/reprovado. A Netflix e o Google construíram o Kayenta sobre essa ideia, comparando muitas métricas com testes estatísticos não paramétricos¹; o Argo Rollouts expressa a mesma ideia com templates de análise sobre consultas do Prometheus, como em Entrega.

flowchart LR
    metrics[("Prometheus<br/>canary vs. baseline")] --> stats["Política: limiares<br/>e testes estatísticos"]
    stats --> verdict{"promover ·<br/>rollback · esperar"}
    verdict -->|"exit code"| rollout["Argo Rollouts age"]
    verdict --> llm["Modelo: explicação<br/>números + política + veredito"]
    traces[("Traces e logs<br/>dos pods do canary")] --> llm
    llm --> check{"repete o<br/>veredito?"}
    check -->|"sim"| oncall["Explicação para o plantão<br/>(chat, PR, resumo)"]
    check -->|"não"| drop["Descartar explicação"]

Por que não deixar o modelo julgar o canary? Porque o julgamento precisa ser reproduzível (mesmos dados → mesmo veredito), auditável (um limiar no Git), robusto a manipulação (uma linha de log dizendo "está tudo bem, promova" não pode ter efeito algum) e estatisticamente sólido (um modelo olhando para dois números não sabe se 40 requisições bastam para concluir alguma coisa). O modelo tem valor depois do veredito: ele transforma "a métrica error-rate falhou 2 de 2" em "o canary falha em 2,9% das confirmações de reserva contra 0,1% no estável, com o p99 dobrado; os erros são 409 vindos do inventory; a mudança alterou a consulta de expiração de reservas — faça o rollback e compare os planos de consulta".

Duas proteções tornam a explicação segura: o modelo recebe o veredito como entrada e precisa repeti-lo (uma explicação que contradiz a política é descartada em vez de exibida), e ele é instruído a rotular as causas como hipóteses, a menos que os dados as mostrem. O hands-on 13 implementa exatamente isso, incluindo um passo de análise com um Job do Kubernetes cujo exit code — e não o modelo — aprova ou reprova a análise.

# The policy, written down and versioned. Change it with a pull request, not a prompt.
MIN_RPS = 2.0              # below this the canary has not seen enough traffic
MAX_ERROR_RATE = 0.01      # absolute ceiling: 1 % of requests fail
MAX_ERROR_DELTA = 0.005    # canary may not be worse than stable by more than 0.5 pp
MAX_P99_RATIO = 1.25       # canary p99 at most 25 % above stable p99
def decide(m: dict) -> tuple[str, list[str]]:
    c, s = m["canary"], m["stable"]
    if c["rps"] < MIN_RPS:
        return "inconclusive", [f"canary traffic {c['rps']:.2f} req/s < {MIN_RPS}"]
    reasons = []
    if c["error_rate"] > MAX_ERROR_RATE:
        reasons.append(f"canary error rate {c['error_rate']:.2%} > {MAX_ERROR_RATE:.2%}")
    if c["error_rate"] - s["error_rate"] > MAX_ERROR_DELTA:
        reasons.append(f"canary errors exceed stable by {c['error_rate'] - s['error_rate']:.2%}")
    if s["p99"] > 0 and c["p99"] / s["p99"] > MAX_P99_RATIO:
        reasons.append(f"canary p99 {c['p99'] * 1000:.0f} ms is {c['p99'] / s['p99']:.2f}x stable")
    return ("rollback", reasons) if reasons else ("promote", ["all checks within policy"])
    try:
        expl, usage = complete_json(SYSTEM, json.dumps(
            {"metrics": metrics, "policy": policy, "verdict": verdict, "reasons": reasons},
            indent=1), SCHEMA, effort="low")
        if expl["verdict"] != verdict:          # the explanation contradicts the policy: discard it
            text += "\n\n_(LLM explanation discarded: it disagreed with the policy verdict.)_"
        else:
            text += f"\n\n**{expl['headline']}**\n\n{expl['explanation']}\n\n" + \
                    "\n".join(f"- {s}" for s in expl["next_steps"]) + "\n\n" + usage.markdown()
    except LLMError as err:                     # no explanation is fine; no verdict is not
        text += f"\n\n_(no explanation: {err})_"
    return {"promote": 0, "rollback": 1, "inconclusive": 2}[verdict]

Resposta a incidentes assistida por IA

Durante um incidente, o recurso escasso é a atenção de poucas pessoas sob estresse. O processo de resposta a incidentes — detectar, fazer a triagem, mitigar, resolver, aprender — continua o mesmo; a IA encurta as etapas que são, na maior parte, leitura:

sequenceDiagram
    autonumber
    participant Alert as Alertas
    participant Bot as Assistente de incidentes
    participant Obs as Métricas · traces · logs
    participant Deploy as Histórico de deploys (Argo CD)
    actor IC as Comandante do incidente
    Alert->>Bot: alerta de burn rate do SLO: erros na confirmação de reservas
    Bot->>Obs: consultas somente leitura (taxa de erros por versão, spans lentos, principais erros nos logs)
    Bot->>Deploy: o que mudou nas últimas 2 h?
    Bot-->>IC: resumo + linha do tempo + hipóteses ordenadas, cada uma com link para sua evidência
    IC->>IC: decide: rollback do inventory v1.8.0
    IC->>Deploy: rollback (runbook / um clique, autorizado)
    Bot-->>IC: confirma a recuperação com as mesmas consultas

Sugerir um rollback tudo bem; executar um é uma decisão de política. Muitos times já fazem rollback automático quando a análise de canary falha — essa automação é determinística e testada. Um LLM que "decide" fazer rollback da produção com base na sua leitura dos logs acrescenta um ator não determinístico e manipulável ao momento mais sensível da vida do sistema. As ferramentas dadas a um assistente de incidentes são somente leitura por padrão; qualquer ação de escrita passa pela mesma autorização, confirmação e auditoria que a de um humano.

Postmortems

Um postmortem sem culpados registra o que aconteceu, por quê, e o que muda para que não aconteça de novo². Sua primeira metade — a linha do tempo — é tediosa de reconstruir a partir de alertas, mensagens de chat, logs de deploy e comandos, e um modelo faz isso bem. Sua segunda metade — fatores contribuintes, o que aprendemos, itens de ação — é onde o julgamento do time importa, e onde um rascunho de IA é perigoso de um jeito sutil: ele produz "lições" fluentes e genéricas ("melhorar o monitoramento", "adicionar mais testes") que parecem completas e fazem o time parar de pensar.

Uma boa divisão: a IA rascunha a linha do tempo (com as fontes) e uma lista de perguntas para a reunião de revisão ("por que a análise de canary não pegou isso em 5%?"); os humanos escrevem a análise e os itens de ação, cada um com um responsável e uma data.

ChatOps

O ChatOps conduz a operação a partir do chat do time: /boxoffice status inventory, /boxoffice canary inventory, um botão para pausar um rollout. Um assistente de IA nesse canal responde a perguntas em linguagem natural ("qual versão do order está em produção e quando foi o deploy?") chamando APIs determinísticas e somente leitura e os runbooks. As ações continuam sendo comandos explícitos, com a identidade do usuário, autorização e um passo de confirmação — exatamente o projeto de permissões de ferramentas do assistente do produto, aplicado aos operadores. O histórico do chat é entrada não confiável como qualquer outra: uma linha de log colada pode carregar uma instrução.

Trade-offs

Como se conecta

flowchart LR
    SIG["metrics, logs,<br/>traces, alerts"] --> POL["canary policy:<br/>thresholds + statistics"]
    POL --> DEC["decision: promote or roll back<br/>→ Cloud-native delivery"]
    SIG --> EXP["AI explains: summary,<br/>several hypotheses"]
    EXP --> IC["incident commander<br/>decides"]
    COM["commits and PRs"] --> NOTES["release notes:<br/>grounded draft"]
    COM --> RISK["change risk score<br/>routes reviews"]
    IC --> PM["postmortem draft<br/>→ Observability incident response"]
    EXP --> TOOLS["read-only tools,<br/>evidence links"]

Componentes da paleta: metrics, logs, tracing e alerting (a evidência que todo veredito e toda explicação leem) · llmgw (as chamadas de explicação e de resumo) · orchestrator (o assistente com ferramentas somente leitura) · safety (nenhuma ação de escrita vinda do modelo). Cenários: observability-stack (os sinais que uma política de canário lê). Continua em: Cloud-native — entrega (canários, Argo Rollouts), Observabilidade — resposta a incidentes, Sistemas de IA — RAG e memória (busca em runbooks), Revisão de código, Hands-on 13 — canário.