Observabilidade O deploy não é a linha de chegada. É onde o sistema começa a ser cobrado.

A partir da entrada em produção, o sistema deixa de ser promessa e passa a ser medido: disponibilidade, erro, tempo de resposta, custo de IA por consulta. Quando algo sai do normal, ele tenta se recuperar sozinho. E quando não pode fazer isso com segurança, chama gente.

Toda entrega da Steply sobe instrumentada. Monitoramento nunca é etapa separada nem item opcional na proposta.

O que acontece entre o alerta e o conserto.

Cinco passos, e o humano aparece no quarto. Nunca antes, para não virar plantão de madrugada; nunca depois, para nenhuma mudança de comportamento entrar em produção sem alguém responder por ela.

O ciclo, em ordem

  1. contínuo

    Medir

    O sistema publica os próprios sinais desde a primeira etapa: disponibilidade, latência, taxa de erro, fila, custo de IA por consulta. Sem isso, "está tudo bem" é opinião de quem construiu.

  2. em segundos

    Detectar o desvio

    O limite não é um número redondo escolhido no chute: é o comportamento normal daquele sistema, aprendido nas primeiras semanas. Fila crescendo fora de hora dispara igual a erro, muitas vezes antes dele.

  3. automático

    Isolar e tentar de novo

    Boa parte das falhas de produção é temporária: a API do parceiro caiu por 40 segundos, o banco travou numa fila. O sistema espera, tenta de novo com intervalo crescente e desliga o caminho quebrado antes de derrubar o resto junto.

  4. sempre humano

    Propor e revisar

    Quando repetir não resolve, o sistema não decide por conta própria: descreve o que viu, aponta a causa provável e sugere o ajuste. Alguém com nome revisa e aprova. Só o rollback seguro roda sem espera: desligar o que está causando o problema.

  5. vira etapa

    Virar melhoria com escopo

    Se a causa é estrutural e não um soluço, ela entra na fila como etapa, com entregável, data e valor, como qualquer outra. Correção de emergência que não vira melhoria escrita volta a acontecer no mês seguinte.

O fluxo real

O desenho por trás do alerta que chega no seu canal

Este é o fluxo de operação que a Steply roda, não uma ilustração de marketing. Entrada de eventos, validação, repetição com espera crescente, roteamento por severidade e envio por canal. Cada canal se recupera sozinho e tudo termina em trilha de auditoria. Use o zoom: ele é denso de propósito.

01 · TRIGGERS02 · MERGE03 · SDD VALIDATION04 · SELF-HEAL ENGINE05 · ROUTING06 · PROCESSORS07 · ENRICH08 · CHANNEL OUTPUT + SELF-HEAL POR CANALvalidinvalidretry 3×failgithubnormalcriticalformatslackwhatsappdiscordgithubfailretrycircuit breakaudit + metrics⏱ SCHEDULEcron 5min→ WEBHOOK HTTPPOST /entry⌥ GITHUB EVENTSPR · issue · pushMERGEpassthrough✓ SDD VALIDATORJSON schema⤴ ROUTERvalid / invalid200 OKWebhook response⟳ RETRY + CBbackoff exp✕ ERROR LOGaudit + alertEVENT TYPErouter · rules⌥ GITHUB PROCPR / issueSTD PROCdefault flow⚠ CRITICALpage on-callPRIORITYenricherlevels · weightMESSAGEformatterCHANNELrouter✉ SLACKpost message⌖ WHATSAPPz-api send⌬ DISCORDcreate channel⌥ GH STATUScommit checkSELF-HEALper-channel⏸ BACKOFFwait + retry⚡ FALLBACKdiscord channel📊 AUDIT+ metrics
  • Fluxo normal
  • Automação verificada
  • Anomalia / alerta
  • Recuperação e revisão humana

O que fica aberto para você, e não só para quem construiu.

Painel de cliente costuma ser uma versão resumida do painel de verdade, com os números bons e sem os incômodos. Aqui é o mesmo painel, com os mesmos alertas e o mesmo histórico.

  • Os sinais em tempo real

    Disponibilidade, tempo de resposta, taxa de erro e custo de IA por consulta, com a série histórica. Não é um resumo mensal: é o que a nossa equipe olha quando o alerta toca.

  • O histórico de incidentes

    Cada desvio detectado, o que o sistema tentou sozinho, o que precisou de gente e quanto tempo levou até normalizar. Inclusive os que ninguém percebeu de fora. Principalmente esses.

  • O histórico de entregas

    Qual etapa entrou em produção, quando, o que mudou e se algum indicador se mexeu depois disso. É o que permite ligar uma entrega a um efeito, em vez de acreditar que ela funcionou.

FAQ

Perguntas sobre operar depois da entrega.

O sistema toma decisões sozinho em produção?

Só as reversíveis. Quando algo é detectado, o sistema isola, tenta de novo e, se não resolver, descreve a causa provável e sugere o ajuste, mas quem aprova é uma pessoa. A única classe de ação que roda sem espera é o rollback seguro: pausar ou reverter o que está causando o problema, que é sempre desfazer, nunca criar comportamento novo.

Monitoramento é cobrado à parte depois da entrega?

Não. Instrumentar faz parte da etapa: sistema sem medição não conta como entregue, então não existe versão "sem monitoramento" mais barata. O que tem custo próprio é a evolução: cada melhoria entra como etapa, com escopo, data e valor, na mesma régua de qualquer outra.

E se a gente quiser operar isso com o time interno?

É o desenho preferível quando existe time interno. O painel, os alertas e as regras de detecção rodam no seu ambiente, com as chaves em seu nome. A Steply não é intermediária de nada. O que costuma ficar conosco é a evolução por etapa e o plantão nas partes que a gente construiu, enquanto fizer sentido.

Quanto tempo depois da entrega vocês continuam acompanhando?

Enquanto o sistema estiver no ar e o acompanhamento estiver contratado. Mas o ponto é outro: mesmo se a Steply sair, o painel, os alertas e o histórico continuam, porque nunca estiveram do nosso lado. Acompanhamento que só existe enquanto o fornecedor está presente não é observabilidade, é dependência.

Seu sistema atual avisa antes do cliente?

Se a resposta for "descobrimos quando alguém liga", esse é o primeiro gargalo, e ele quase sempre é mais barato de resolver do que parece. O diagnóstico mede quanto essa cegueira custa por ano.

Começar pelo diagnósticoVer a engenharia por trás