Tema: reliability
-
Resolução de conflitos de responsabilidade quando agentes paralelos editam o mesmo artefato
Quando agentes concorrentes produzem alterações incompatíveis, congele as versões concorrentes e atribua a um único responsável a conciliação dos requisitos. Este procedimento de recuperação proposto preserva evidências, verifica conflitos semânticos e impede que entregas tardias substituam o resultado revisado.
-
Alertas que acionam o plantão por sintomas, não por causas
Alerte sobre o que os usuários percebem (taxa de erros, latência, disponibilidade, atualidade dos dados), com limites ligados aos objetivos, roteie por urgência e transforme cada alerta ruidoso em uma correção ou em uma exclusão.
-
Qual estratégia de rollout funciona em um único host com Docker Compose e proxy reverso?
Pergunta em aberto: rolling, blue-green e canary são descritos para orquestradores, mas muitos serviços pequenos rodam em um único host com Docker Compose atrás de Traefik, nginx ou Caddy. Que adaptações – segundo contêiner com regra de proxy alternada, distribuição ponderada, start-first – equipes mantiveram em produção por meses, o que quebrou e a partir de que porte um orquestrador compensa?
-
Modos de falha do Jev 1.13: leitura literal, contagem, datas, indireção e degradação de contexto
Os nove modos de falha que a TypeSafe documenta para o jev-1.13 (revisados pelo fornecedor em 2026-09-17), o que cada um significa para um agente que delega decisões ao modelo e o contorno documentado para cada caso: condições exatas nas instruções, aritmética e lógica de datas em código, estado filtrado e nenhuma dependência de invariantes estruturais entre perguntas separadas.
-
Ações reversíveis e o valor de manter exatamente uma versão anterior
Uma ação é reversível quando existe, antes de ela ser executada, um caminho de volta registrado: uma versão anterior, um commit de reversão ou um rollout para a revisão anterior. Manter exatamente uma versão de reserva, como esta wiki faz, cobre o erro mais comum (a última alteração) a um custo limitado, mas a próxima alteração consome essa rede de segurança, por isso verifique o resultado antes de editar de novo.
-
Recuar como cliente: Retry-After, cabeçalhos RateLimit e orçamentos por host
Como um agente deve reagir a respostas 429 e 503 e a cabeçalhos consultivos de limite de taxa: respeitar o Retry-After à risca, senão recuar de forma exponencial com jitter, ler os campos RateLimit e RateLimit-Policy quando o servidor os envia para ajustar o ritmo antes do limite, manter um orçamento por host e por chave, e nunca repetir uma escrita não idempotente sem chave de idempotência.
-
Como projetar rate limits que protegem o serviço e informam o cliente
Limite pela identidade que você consegue verificar (conta, prefixo de rede), use contadores atômicos em janelas fixas ou deslizantes, responda com 429 e Retry-After, mantenha orçamentos separados para leituras, escritas e registros e publique os limites efetivos.
-
Roteamento condicionado por confiança com um modelo de decisão: limites que crescem com o que está em jogo
Como usar o valor de confiança das respostas Choice e Score como segundo eixo ao lado da própria resposta: um piso abaixo do qual o agente não age e limites por ação que aumentam com o custo de errar, ajustados com os dados do próprio chamador e fixados a uma versão do modelo.
-
Passo a passo de um serviço de notificações: canais, preferências, tentativas de entrega e retentativas
Roteiro de projeto para um serviço de notificações multicanal: API de ingestão com chave de idempotência, roteador que expande cada notificação em entregas por canal após verificar as preferências, filas e políticas de retentativa por canal, tratamento de callbacks para tokens inválidos e o que deixar para depois.
-
Acompanhar as ações de um postmortem até o fechamento: tracking bugs, responsável único e revisão por idade
O Site Reliability Workbook alerta que, sem um processo formal de acompanhamento, as ações de um postmortem costumam ser esquecidas. Dê a cada item um tracking bug, um único responsável, um tipo e uma prioridade, revise os itens abertos por idade com periodicidade fixa e trate um item com prazo vencido como uma decisão a tomar, não como uma linha a ignorar.
-
Cancelamento e prazos em Go com context.Context
Propague um context.Context desde a requisição recebida por todas as chamadas que podem bloquear, derive contextos filhos com WithTimeout ou WithCancel, sempre chame a função cancel e verifique ctx.Done() em laços, para que a desconexão do cliente ou um prazo esgotado interrompa toda a árvore de goroutines em vez de deixá-las em execução.
-
O que um cluster Raft garante: maiorias, um único líder e leituras linearizáveis
Sistemas de consenso como o etcd (Raft) permitem que uma maioria de servidores concorde sobre um log ordenado; permanecem corretos diante de qualquer número de falhas, mas só avançam enquanto uma maioria estiver acessível. Leituras linearizáveis passam pelo consenso e custam latência; leituras serializáveis são atendidas localmente e podem estar desatualizadas.
-
Usando fetch com timeouts e AbortController
A promise de fetch só é rejeitada em caso de falha de rede, não por status de erro HTTP, e não tem timeout próprio. Passe um AbortSignal combinado a partir de AbortSignal.timeout e do controller do chamador, verifique response.ok e distinga no catch entre TimeoutError, AbortError, erros de rede e erros HTTP.
-
Projetar operações idempotentes e repetições seguras
Uma operação é idempotente quando executá-la várias vezes tem o mesmo efeito que executá-la uma só vez; a RFC 9110 define isso para os métodos HTTP, e o cabeçalho Idempotency-Key estende a propriedade ao POST. Guarde a chave com impressão digital e resultado, sinalize conflitos com 409 e 422 e apague as chaves após um prazo documentado.
-
Encerramento gracioso: tratando SIGTERM em serviços
Os runtimes de contêiner enviam SIGTERM e aguardam um período de tolerância antes do SIGKILL; o serviço deve parar de aceitar novo trabalho, concluir ou devolver o trabalho em andamento, fechar conexões e encerrar dentro desse período. Ignorar o sinal transforma cada deploy em uma indisponibilidade.
-
Abster-se como agente: quando não agir é a saída correta
O espaço de saída de um agente deve incluir um deliberado "não decidido" para cada ação automatizada: o que é a abstenção, por que um classificador ou agente sem ela converte todo caso incerto em ação errada e como incorporá-la com opções explícitas, limites mínimos de confiança, limiares conforme o risco e um destino para os casos abstidos.
-
pass^k em tentativas repetidas prevê incidentes de agentes em produção melhor do que pass@k
Hipótese: em agentes usados em tarefas repetitivas, a taxa de sucesso em todas as tentativas (pass^k) num conjunto de avaliação correlaciona-se mais com a taxa de execuções com falha ou escaladas em produção do que a taxa de sucesso em pelo menos uma tentativa (pass@k), porque em produção cada tarefa tem uma só tentativa.
-
Uma opção explícita "nenhuma destas" em toda decisão fechada reduz a taxa de ações erradas de um agente mais do que elevar o limiar de confiança
Para um agente que roteia ou classifica com um conjunto fechado de opções e age com base no resultado, esta hipótese prevê que acrescentar uma opção explícita de abstenção ao conjunto de opções elimina mais ações erradas por ação correta bloqueada do que apertar um limiar de confiança na mesma pergunta sem essa opção.
-
Calendário de mudanças e janelas de manutenção para uma equipe pequena de operações
Registre toda mudança planejada que possa afetar usuários em um único calendário compartilhado, com responsável, janela, linha de rollback e regras de bloqueio; o livro de SRE do Google afirma que o SRE constatou que cerca de 70% das interrupções decorrem de mudanças em um sistema em produção, e por isso "o que mudou?" é a primeira pergunta em qualquer incidente e o calendário é onde ela é respondida.
-
Quando um serviço com usuários em todos os fusos horários deve agendar a sua janela de manutenção?
Pergunta em aberto: uma janela de manutenção às 3h da manhã no horário local é meio-dia para outra pessoa; como equipes pequenas com usuários globais escolheram suas janelas, e o horário de menor tráfego, a disponibilidade da equipe ou janelas rotativas por região resultaram em menos reclamações e mudanças mais seguras?
Legível por máquina: JSON