Giorgio Módulo 1 / 5
API contracts, model registry e compatibility
Separe ID público estável, snapshot imutável e alias móvel. Clientes devem depender do contrato de request/response, não do fornecedor interno. Deprecação precisa de replacement e data de sunset.
Campos de telemetria como requested_model, served_model e provider_model evitam esconder fallback. Se o modelo servido mudou, isso é dado operacional relevante.
Exemplo resolvido · cenário didático
Compatibilidade observável
Um consumidor espera {text:string}. Trocar text por content sem versionar quebra o contrato, mesmo que o conteúdo seja melhor. Mantenha o campo antigo durante a migração ou ofereça uma versão explícita e teste consumidores.
Teste sua compreensão
É seguro remover um campo porque uma interface visível não o usa?
Conferir o raciocínio
Não. Integrações, tarefas e versões antigas podem consumi-lo. Localize consumidores e teste a migração.
Leitura de referência: Google SRE — Handling Overload
Próximo módulo →Módulo 2 / 5
Prefix/semantic caching, invalidation e tenant isolation
Cache de prefixo, retrieval e resposta reduzem custo, mas cada um precisa de chave e invalidação diferentes. Cache de resposta exige considerar modelo, versão, prompt, tools, temperatura e dados dependentes do tempo.
Nunca cacheie silenciosamente uma resposta que depende de identidade ou permissão sem incluir o escopo do usuário na chave.
Exemplo resolvido · cenário didático
A chave define o isolamento
Uma resposta depende de tenant, permissões, versão do corpus, modelo e prompt. Usar apenas o prompt como chave pode reutilizar dados de outro tenant ou uma versão revogada. Valide autorização antes de consultar o cache.
Teste sua compreensão
Um cache semanticamente parecido pode ignorar diferenças de permissão?
Conferir o raciocínio
Não. Similaridade não autoriza acesso nem garante validade da evidência.
Leitura de referência: Google SRE — Handling Overload
Próximo módulo →Módulo 3 / 5
Telemetria, tracing e token accounting
Registre latency por etapa, tokens de entrada/saída, cache hits, tool calls, erros, retries e modelo realmente servido. Trace IDs ligam frontend, gateway, provider e persistência.
Logs não devem armazenar segredos ou chain-of-thought. Observabilidade boa mede estado operacional suficiente para reproduzir falhas sem coletar tudo.
Exemplo resolvido · cenário didático
Custo por entrega
Se 100 tentativas custam 2 unidades monetárias e só 80 concluem a tarefa, custo por tentativa=0,02 e custo por tarefa concluída=0,025. Registre também erros e repetições para entender a diferença.
Teste sua compreensão
Se as mesmas 2 unidades produzem 50 conclusões?
Conferir o raciocínio
O custo por tarefa concluída sobe para 0,04. Menor gasto por chamada não garante menor custo por resultado.
Leitura de referência: Google SRE — Handling Overload
Próximo módulo →Módulo 4 / 5
Backpressure, filas, retries e degraded modes
TPM/RPM/TPD são recursos compartilhados. Governor deve reservar budget antes da chamada, registrar uso real e respeitar Retry-After. Repetir imediatamente um 429 agrava a fila.
Degradação precisa ser explícita: se uma etapa de review foi omitida por budget, marque isso. Não retorne 200 fingindo qualidade completa quando o pipeline falhou.
Exemplo resolvido · cenário didático
Amplificação por retries
Cem pedidos, cada um com até três tentativas totais, podem gerar 300 chamadas. Durante sobrecarga, isso pode piorar a falha. Use limite total, espera com dispersão e respeito a sinais de indisponibilidade.
Teste sua compreensão
Três camadas independentes com três tentativas cada podem gerar quantas chamadas na pior combinação?
Conferir o raciocínio
Até 27 chamadas por pedido original. Coordene o orçamento entre camadas.
Leitura de referência: Google SRE — Handling Overload
Próximo módulo →Módulo 5 / 5
SLOs, custo por tarefa e release engineering
Defina SLOs por experiência: TTFT, completion success, p95, taxa de erro, groundedness ou test pass rate conforme o produto. Um único uptime não captura qualidade do modelo.
Release gates devem combinar regressão de evals, custo e latency. Quando uma versão nova melhora 2% qualidade mas dobra p95, a decisão depende do canal e do valor daquele ganho.
Exemplo resolvido · cenário didático
Orçamento de erro
Em uma janela de 30 dias, um SLO baseado em tempo de 99,9% permite 43,2 minutos fora do objetivo. Esse cálculo não vale automaticamente para SLO baseado em contagem de pedidos; a unidade deve ser declarada.
Teste sua compreensão
E para 99,5% na mesma janela?
Conferir o raciocínio
216 minutos. Defina também o que conta como falha e como são tratados períodos sem tráfego.
Leitura de referência: Google SRE — Handling Overload
Ir para o projeto →Projeto aplicado
API simulada com falhas controladas
- Implemente contrato versionado, IDs de requisição e resposta estruturada de erro.
- Simule lentidão, 429 e timeout; limite fila, tentativas e prazo total.
- Documente SLO, custo por tarefa concluída e gatilhos de rollback.
Critérios para revisar sua entrega
- A execução pode ser reproduzida a partir das instruções e dos arquivos entregues.
- O baseline, as condições e as métricas permitem conferir a comparação.
- O relatório distingue resultado medido, simulação, hipótese e limitação.
Esta rubrica orienta a autoavaliação do projeto; a conclusão e a credencial seguem a avaliação do curso.
Continue com evidências.
Os exemplos numéricos são didáticos. Compare o raciocínio com a referência e registre o que você observou no seu próprio experimento.
Google SRE — Handling Overload ↗Progresso e avaliação
A leitura e o roteiro de exercícios são abertos. Para registrar progresso e realizar a avaliação final do curso, entre na área de estudo.
Abrir minha área de estudo ↗