1. Por que métricas e SLO são necessários no ChatGPT App
Imagine dois estados de uma equipe.
No primeiro, todos vivem pelo princípio “parece que funciona”. Enquanto os usuários não reclamam no suporte e não publicam tuítes furiosos — está tudo ok. De tempos em tempos, alguém abre os logs, rola uma “rolagem interminável” de linhas, acena com a cabeça e fecha a aba.
No segundo, a equipe tem alguns painéis simples:
- p95 da latência da principal MCP‑ferramenta.
- error‑rate do MCP e do checkout.
- disponibilidade dos webhooks.
- conversão para pagamento ao longo do funil.
E há 3–5 SLO: “95% das chamadas da ferramenta recommend_gifts — mais rápidas que 2 segundos”, “taxa de erros dos MCP‑tools < 1%”, “disponibilidade do checkout ≥ 99.5%”, “conversão do widget até o pagamento bem-sucedido ≥ 10%”.
No segundo cenário, você:
- percebe rapidamente que há algo errado com o aplicativo, mesmo antes das reclamações;
- consegue medir o efeito de qualquer mudança (novo algoritmo de recomendação, migração de SDK, novo plano do provedor);
- e, quando chegar ao módulo sobre Store e review, poderá dizer honestamente: “temos critérios de qualidade e sabemos o quanto estamos aderentes a eles”.
Vamos falar de coisas bem óbvias: o que é p95, por que ele é melhor do que a média, como calcular error‑rate e availability, quais métricas são importantes para a parte de commerce com webhooks e como juntar tudo isso em SLO simples, porém úteis. Vamos analisar tudo isso usando nosso app didático GiftGenius — um cenário de commerce com uma MCP‑ferramenta de recomendações, checkout e webhooks de pagamento.
2. Métricas básicas para ChatGPT App: o que medir exatamente
Latência: p50/p95/p99 em vez da “média geral”
Latência é o tempo do início de uma operação até seu término lógico. No nosso stack, há várias operações desse tipo:
- chamada da MCP‑ferramenta recommend_gifts (seleção de presentes);
- chamada da ferramenta que cria o checkout intent no ACP;
- processamento do webhook de pagamento bem-sucedido.
É importante entender que a latência total que o usuário vê no ChatGPT é apenas parcialmente controlada por nós. Há a parcela da plataforma (inferência do modelo, latências de rede da OpenAI) e a nossa parcela — ferramentas, backend, BD, gateway de pagamento. Para o SLI (Service Level Indicator — indicador mensurável de qualidade de serviço) de latência, mede-se, em geral, a nossa parte: da entrada da requisição no App/MCP até a resposta pronta do nosso servidor.
A média do tempo de resposta é enganosa. Se 90% das requisições chegam em 100 ms e 10% em 5 segundos, a média ficará em torno de meio segundo e o gráfico parecerá “verde”. Mas um em cada dez usuários vê uma pausa de 5 segundos — o UX sofre bastante.
Por isso é comum usar percentis: p50 (mediana), p95, p99. p95 é o limite abaixo do qual ficam 95% das requisições. Como destacam os guias de SRE, os percentis “não deixam os outliers se esconderem na média” e tornam visível a vida daqueles 5–10% de usuários menos afortunados que caem o tempo todo na cauda da distribuição.
É mais fácil pensar assim: p50 diz como vive o “usuário médio”, e p95/p99 — o quão ruim fica para as pessoas pacientes que sempre sentem que “algo está lento”.
Error‑rate: proporção de requisições malsucedidas
Error‑rate é a relação entre o número de requisições malsucedidas e o total de requisições em um período. A principal fonte de dados geralmente são logs estruturados ou métricas com labels status="success" | "error".
No nosso stack, há vários error‑rate naturais:
- no nível de MCP‑tools: proporção de chamadas de recommend_gifts que terminaram com erro (exceção, HTTP 5xx de API externa, timeout);
- no nível de ACP/checkout: proporção de tentativas malsucedidas de finalizar um pedido (erro de API, indisponibilidade do gateway de pagamento);
- no nível do handler de webhook: proporção de webhooks cuja execução terminou com falha.
Um detalhe sutil: no ChatGPT App, podem ocorrer “erros silenciosos”. Por exemplo, a MCP‑ferramenta retornou um erro, o modelo se desculpou e continuou o diálogo sem expor o erro técnico no cabeçalho. Formalmente, o ChatGPT mostra uma resposta humana ao usuário, mas do ponto de vista de confiabilidade, seu stack falhou. Por isso, para error‑rate, é importante contar justamente os status de engenharia, e não a “resposta final de UX do GPT”.
Availability: disponibilidade dos serviços
Availability é a porcentagem de requisições atendidas com sucesso em um período. Conceitualmente, é o mesmo que error‑rate, só que com sinal invertido: “quantas foram bem-sucedidas”, e não “quantas foram malsucedidas”. Exemplo clássico: availability = successful_requests / total_requests * 100%.
Aplicado ao nosso stack:
- disponibilidade do servidor MCP: quantas chamadas JSON‑RPC do ChatGPT terminaram com resposta correta na última hora;
- disponibilidade do checkout‑API: qual a proporção de acessos a /api/checkout que terminou com HTTP 2xx;
- disponibilidade do endpoint de webhook: qual a proporção de webhooks recebidos do gateway de pagamento que obteve de nós uma resposta correta (geralmente HTTP 200).
Se a documentação do provedor de pagamento promete, digamos, 99.9% de disponibilidade e você tem 97%, o problema provavelmente não é com eles.
Métricas de commerce: conversão e funil
O GiftGenius é um cenário de commerce. Aqui, não importa só a parte técnica (respostas rápidas, poucos erros), mas também o resultado de negócio — com que frequência as recomendações se transformam em pedidos pagos.
Aqui entra em jogo o funil de conversão:
- usuários para os quais o widget foi exibido (view);
- usuários que escolheram um presente (selection);
- usuários que clicaram em “finalizar pedido” (checkout started);
- usuários cujo status do pedido se tornou “pago” (paid).
A partir desse funil, dá para determinar a conversão “do widget ao pagamento”, e isso também é um SLI — indicador mensurável de qualidade do serviço. Por exemplo, “conversão de pagamentos bem-sucedidos / usuários que viram o widget por dia = 7%”. Se de repente a latência aumentar, ou o checkout cair às vezes por timeout, o funil começará a afunilar em pontos inesperados.
Se você usa o Instant Checkout
Todas as métricas de commerce descritas também se aplicam ao Instant Checkout com base no Agentic Commerce Protocol. Nesse caso, em vez do seu próprio /api/checkout, você tem o Agentic Checkout API padronizado: o ChatGPT chama seus endpoints REST POST /checkout_sessions, POST /checkout_sessions/{id}, POST /checkout_sessions/{id}/complete (e opcionalmente — cancel e GET), recebendo de você a cada vez o estado “verdadeiro” do carrinho e do checkout.
Para as métricas isso não muda nada: você calculará p95 de latência, error-rate e availability não para um /api/checkout arbitrário, mas para esses endpoints padrão. SLOs do tipo “p95 de latência do checkout < 3 segundos, error-rate < 2%” simplesmente se aplicam às chamadas de checkout_sessions, e não a um API próprio.
Um mundo à parte: métricas de webhooks
Webhooks são eventos assíncronos (por exemplo, payment_succeeded do gateway) que movem o pedido ao longo do ciclo de vida. Se os webhooks forem processados de forma ruim, o aplicativo pode recomendar presentes lindamente, mas os pedidos “ficarão presos” com status “aguardando pagamento” ou em algum estado indefinido.
Se você não se integra diretamente ao Stripe/gateway, mas via Instant Checkout, o papel dos “webhooks do gateway” é assumido pelos order events do Agentic Checkout: seu backend envia à OpenAI eventos como order.created e order.updated para uma URL de webhook dedicada. É exatamente a mesma classe de entidades: eventos assíncronos dos quais depende o status final do pedido, só que o destinatário não é seu frontend, e sim o ChatGPT.
Consequentemente, as mesmas métricas — success rate, latência, error-rate — você calculará não para os webhooks do Stripe, mas para seus webhooks de order events em direção à OpenAI. No SLO, dá para escrever literalmente “pelo menos 99% dos eventos order.* são entregues e processados com sucesso em 7 dias, p95 da latência de processamento < 500 ms” — e isso será um SLI/SLO correto justamente para o Instant Checkout.
Para webhooks, normalmente observa-se:
- webhook success rate — proporção de webhooks cuja lógica de negócio terminou com sucesso (incluindo retries);
- webhook latency — tempo da chegada do webhook até o fim do processamento;
- webhook error rate — proporção de casos em que o processamento do webhook terminou com erro (falha de validação, BD indisponível, timeout e assim por diante).
Por exemplo, pode-se definir um SLO: “pelo menos 99% dos webhooks são processados com sucesso em 7 dias” e “p95 da latência de processamento do webhook < 500 ms”.
3. Como medir tecnicamente as métricas no GiftGenius
Vamos da teoria ao código. Precisamos entender onde inserir as medições para depois agregar dados em p95, error‑rate e outras métricas.
Para não trazer, nesta aula, um Prometheus ou Datadog específico, vamos supor que temos uma função simples logMetric ou logs de eventos JSON. Por cima disso, qualquer sistema de observabilidade montará os gráficos necessários.
Medindo a latência da MCP‑ferramenta
Suponha que temos um servidor MCP do GiftGenius em TypeScript, e a ferramenta recommend_gifts. Envolvemos a lógica de negócio com um timer:
// mcp/tools/recommendGifts.ts
import { logMetric } from "../observability/metrics"; // helper hipotético
export async function recommendGiftsTool(input: RecommendInput) {
const startedAt = performance.now(); // hora de início
try {
const result = await recommendGifts(input); // lógica de negócio
const duration = performance.now() - startedAt;
logMetric("tool_latency_ms", duration, {
tool: "recommend_gifts",
status: "success",
});
return result;
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("tool_latency_ms", duration, {
tool: "recommend_gifts",
status: "error",
error_type: "exception",
});
throw error;
}
}
Aqui, logMetric pode simplesmente escrever um log JSON no stdout:
// observability/metrics.ts
export function logMetric(
name: string,
value: number,
labels: Record<string, string | number>
) {
// Na prática aqui haveria um cliente de Prometheus/DataDog
console.log(
JSON.stringify({
type: "metric",
name,
value,
labels,
timestamp: new Date().toISOString(),
})
);
}
Com essa abordagem, você recebe um fluxo de eventos tool_latency_ms, no qual, pelos labels tool e status, já é possível calcular p95 apenas para chamadas bem-sucedidas ou, ao contrário, ver quanto tempo duram as requisições que terminam com erro.
Calculando o error‑rate
De modo semelhante, é possível registrar uma métrica separada de erros:
// dentro do mesmo handler da ferramenta
logMetric("tool_error_total", 1, {
tool: "recommend_gifts",
error_type: "external_api_timeout",
});
E para requisições bem-sucedidas:
logMetric("tool_success_total", 1, {
tool: "recommend_gifts",
});
Depois, no sistema de métricas, você calcula error_rate = tool_error_total / (tool_error_total + tool_success_total) para o período. Isso já é agregado no lado do sistema de métricas; no aplicativo, o importante é emitir os eventos com cuidado.
Se quiser ser bem minimalista, dá até para ficar só com logs, sem um error_total separado. Nesse caso, o error‑rate é calculado pelo campo status.
Métricas do checkout/ACP
Para o endpoint de checkout no Next.js, a lógica é a mesma: envolvemos o handler com um timer e contamos os status.
// app/api/checkout/route.ts
import { NextRequest, NextResponse } from "next/server";
import { logMetric } from "@/observability/metrics";
export async function POST(req: NextRequest) {
const startedAt = performance.now();
try {
const body = await req.json();
const result = await createCheckoutSession(body); // chamada ao ACP/Stripe
const duration = performance.now() - startedAt;
logMetric("checkout_latency_ms", duration, { status: "success" });
logMetric("checkout_total", 1, { status: "success" });
return NextResponse.json(result, { status: 200 });
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("checkout_latency_ms", duration, { status: "error" });
logMetric("checkout_total", 1, { status: "error" });
return NextResponse.json(
{ error: "Checkout failed" },
{ status: 500 }
);
}
}
Agora já dá para observar o p95 de checkout_latency_ms e o error‑rate de checkout_total. Com base nesses SLI, fica fácil definir SLO do tipo “p95 < 3 segundos, error‑rate < 2%”.
Métricas de webhooks
E, claro, os webhooks. Já discutimos quais métricas importam (ver seção 2), agora vamos ver como medi-las no código. Ali é especialmente importante não só o tempo, mas o fato do processamento bem-sucedido: caso contrário, o usuário pagou, mas o pedido não mudou para “paid”.
// app/api/webhooks/payment/route.ts
import { NextRequest, NextResponse } from "next/server";
import { logMetric } from "@/observability/metrics";
export async function POST(req: NextRequest) {
const startedAt = performance.now();
try {
const payload = await req.text(); // dados brutos
const sig = req.headers.get("stripe-signature") || "";
const event = verifyStripeSignature(payload, sig); // validação
await handlePaymentEvent(event); // atualizamos o pedido
const duration = performance.now() - startedAt;
logMetric("webhook_latency_ms", duration, {
type: event.type,
status: "success",
});
logMetric("webhook_total", 1, {
type: event.type,
status: "success",
});
return new NextResponse("ok", { status: 200 });
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("webhook_latency_ms", duration, {
type: "unknown",
status: "error",
});
logMetric("webhook_total", 1, {
type: "unknown",
status: "error",
});
return new NextResponse("error", { status: 500 });
}
}
Com base nesses eventos, é possível definir SLI:
- webhook success rate = success / (success + error);
- p95 de webhook_latency_ms para payment_succeeded.
E então estabelecer SLO para eles, por exemplo: “99% dos webhooks são processados com sucesso em 7 dias, p95 < 500 ms”.
4. Estatística de percentis: um pouco mais fundo
Já nos apoiamos várias vezes em p50/p95/p99, então vamos olhar um pouco mais formalmente o que exatamente eles significam. Na prática, quem calculará os percentis será o sistema de métricas, mas é útil entender o que acontece ali.
O percentil pX é o valor abaixo do qual ficam X por cento das medições. Se você ordenar um array de latências em ordem crescente, o p95 estará em algum ponto da “cauda”, mais próximo dos valores máximos. Em código (por exemplo, no Node, caso você queira calcular localmente o p95 para um conjunto de valores), isso pode ficar mais ou menos assim:
// função simples para calcular percentil
export function percentile(values: number[], p: number): number {
if (values.length === 0) return 0;
const sorted = [...values].sort((a, b) => a - b);
const index = Math.ceil((p / 100) * sorted.length) - 1;
return sorted[Math.max(0, Math.min(index, sorted.length - 1))];
}
Essa função pode ser usada em testes ou em um script simples que brinque com os dados e mostre o quanto o p95 difere da média. Em produção, esse trabalho fica por conta de Prometheus, Datadog, New Relic e outros players mais maduros.
5. SLI, SLO e SLA: em linguagem simples
Três siglas que parecem assustadoras, mas são muito simples na prática.
SLI — Service Level Indicator
SLI é um indicador mensurável concreto, uma fórmula. Por exemplo:
- p95(latency) da ferramenta recommend_gifts nas últimas 24 horas;
- error‑rate das MCP‑tools nos últimos 7 dias;
- conversão widget → pagamento bem-sucedido por semana.
SLI não é uma meta nem uma promessa; é apenas um “termômetro”.
SLO — Service Level Objective
SLO é a meta para o SLI, na prática a condição de “saúde” do serviço. Por exemplo:
- “p95(latency de recommend_gifts) < 2 segundos na janela de 7 dias”;
- “error‑rate de todas as MCP‑tools < 1% na janela de 30 dias”;
- “disponibilidade do checkout API ≥ 99.5% por trimestre”;
- “conversão do widget até o pagamento bem-sucedido ≥ 15% por mês”.
Boa prática é primeiro medir o nível atual e definir o SLO um pouco mais rigoroso do que aquilo que você já sustenta; caso contrário, vira ou “missão impossível” ou “já está bom assim”.
SLA — Service Level Agreement
SLA já não é uma meta interna, mas um acordo externo com usuários ou parceiros. No SLA são definidas as obrigações (por exemplo, “99.9% de uptime”) e as consequências por violação (compensação, multas, extensão de assinatura etc.). O SLO costuma ser mais rigoroso que o SLA, para haver espaço no “error budget”.
No contexto didático do GiftGenius, você provavelmente não precisa de SLA, mas é importante entender a escadinha:
SLI → SLO → SLA
métrica → meta → promessa externa
Error budget (orçamento de erros)
Error budget é, de forma simplificada, o volume aceitável de “não ideal”. Se você tem um SLO de “disponibilidade 99.9% em 30 dias”, então 0.1% é o orçamento de erros que pode ser “consumido” com:
- releases planejados com downtime;
- experimentos;
- incidentes imprevistos.
Quando o orçamento “queimou” (por exemplo, no mês a disponibilidade ficou em 99.5%), é hora de desacelerar novas features e consertar a estabilidade.
6. Métricas especiais para o GiftGenius: commerce + webhooks
Vamos juntar tudo e olhar para o GiftGenius como um produto completo.
Funil e conversão
Vamos imaginar um fluxo simples do usuário:
flowchart TD A[Abriu o App com o widget do GiftGenius] --> B[Recebeu recomendações] B --> C[Escolheu um presente] C --> D[Clicou em 'ir para o pagamento'] D --> E[Pagamento bem-sucedido]
Para cada etapa, podemos registrar um evento:
logMetric("funnel_step_total", 1, {
step: "widget_view",
});
logMetric("funnel_step_total", 1, {
step: "gift_selected",
});
logMetric("funnel_step_total", 1, {
step: "checkout_started",
});
logMetric("funnel_step_total", 1, {
step: "checkout_paid",
});
Depois, conhecendo a quantidade de eventos no passo widget_view e em checkout_paid, podemos calcular a conversão: paid / view * 100%. E definir um SLO: “conversão ≥ 10%”. Se, de repente, a conversão cair para 3% e os SLI técnicos (latency/error‑rate) parecerem normais, talvez o problema esteja no UX, na instrução para o modelo ou na qualidade do feed de produto, e não na infraestrutura.
Métricas de webhooks como parte da conversão
Já falamos sobre métricas técnicas de webhooks e sua implementação. Agora é importante conectá-las à conversão: para cenários de commerce, webhooks são críticos. O usuário vê “pagamento concluído”, mas o status final do pedido depende de quão rápido seu backend recebe e processa o payment_succeeded.
SLI para webhooks:
- webhook success rate;
- p95 de webhook latency;
- disponibilidade bruta webhook_endpoint_availability.
Se o success rate dos webhooks cair, você literalmente perde pedidos.
7. Alertas simples em cima de SLO
Um sistema completo de alertas é tema mais próximo de módulos operacionais, mas já dá para esboçar a base.
A ideia é enviar alertas não para cada erro isolado, mas sim para a violação de SLO. Isso é o que frequentemente se chama de symptom‑based alerts — alertas baseados em sintomas de degradação do serviço: interessa menos “ocorreu um erro” e mais “o serviço começou a operar sistematicamente pior do que o prometido”.
Exemplos típicos:
- error‑rate das MCP‑tools nos últimos 5 minutos > 2% com SLO < 1%;
- p95(latency de recommend_gifts) em 10 minutos > 3 segundos com SLO de 2 segundos;
- nos últimos 15 minutos não houve nenhum checkout_paid bem-sucedido — suspeita de queda da integração;
- webhook success rate em 10 minutos < 95%.
O texto do alerta deve ser humano, não “Alert: metric 123 > 456”. Exemplo de “notificação no Slack” para o GiftGenius:
[ALERT][GiftGenius] High error rate on MCP tools:
error_rate = 3.2% (>1% SLO) for last 5 minutes.
Impact: part of users cannot receive gift recommendations.
Actions: check MCP logs and external gift API health.
Mensagens assim estão vinculadas a SLO e ajudam a pessoa de on‑call a entender rapidamente a dimensão do problema.
8. Mini prática: definindo SLO para o GiftGenius
Vamos tentar formular um conjunto de SLO para o nosso aplicativo. Dá para fazer isso até no papel, sem um sistema de métricas implantado.
Exemplo de “pontapé inicial”:
- Para a MCP‑ferramenta principal recommend_gifts:
- SLI: p95(latency) de chamadas bem-sucedidas nos últimos 7 dias.
- SLO: p95(latency) < 2 segundos.
- Para os erros das MCP‑tools:
- SLI: error‑rate = errors / (errors + successes) em 30 dias.
- SLO: error‑rate < 1%.
- Para o checkout API:
- SLI: availability = fração de HTTP 2xx sobre todas as requisições.
- SLO: availability ≥ 99.5% por mês.
- Para webhooks de pagamento:
- SLI: webhook success rate.
- SLO: pelo menos 99% de processamento bem-sucedido de webhooks em 7 dias; p95 da latência de processamento < 500 ms.
- Para o resultado de negócio:
- SLI: conversão widget → pedido pago por mês.
- SLO: conversão ≥ 10–15% (dependendo do nicho).
Mesmo um conjunto pequeno como esse já fornece uma “estrutura” para a tomada de decisões: se você lança uma nova versão do modelo, muda o prompt ou o algoritmo de recomendações e vê que p95 e error‑rate se mantiveram dentro dos SLO, e a conversão aumentou — provavelmente o experimento deu certo.
Se, em vez do seu endpoint de checkout, você usa o Instant Checkout, então “checkout API” é, na prática, as chamadas do Agentic Checkout (/checkout_sessions create/update/complete), e “webhooks de pagamento” — são seus order events (order.created, order.updated) em direção à OpenAI. As métricas e formulações de SLO permanecem as mesmas; o que muda é apenas o protocolo específico.
9. Erros típicos ao trabalhar com métricas e SLO
Erro nº 1: medir apenas o tempo médio de resposta.
A média é conveniente, mas perigosa. Ela facilmente mascara a cauda de requisições lentas. No ChatGPT App, isso é crítico: mesmo que a maioria dos usuários receba tudo rapidamente, atrasos regulares de 5–10 segundos para uma pequena parcela de pessoas serão percebidos como “o app está sempre lento”. Por isso, para latência, sempre use ao menos p50 e p95, e não só a média (mean).
Erro nº 2: confundir SLI, SLO e SLA na cabeça e na documentação.
Às vezes, desenvolvedores escrevem “nosso SLA — p95 < 2 segundos”, sendo que isso não está formalizado para usuários externos nem acompanhado de quaisquer obrigações. Na verdade, isso é um SLO. SLA é um acordo com clientes, com consequências por violações. Se tudo se misturar, ficará obscuro o que vocês realmente prometem a quem.
Erro nº 3: falta de conexão entre alertas e SLO.
Armadilha clássica — configurar alertas “para cada erro”, cada timeout, qualquer desvio de métrica de 0.01. Como resultado, o engenheiro de on‑call vive no inferno das notificações e para de prestar atenção nelas. Muito mais útil é construir alertas sobre a violação do SLO: se o error‑rate subiu substancialmente além do nível-alvo, ou o p95 “saiu” dos limites, aí sim faz sentido acordar as pessoas.
Erro nº 4: ignorar métricas de webhooks e partes assíncronas.
Problema já conhecido, mas que merece destaque — ignorar as métricas de webhooks e do processamento assíncrono. Muitas equipes monitoram apenas as respostas HTTP dos principais APIs, mas não observam os webhooks e o processamento em background. Em cenários de commerce, é justamente aí que se escondem os bugs mais desagradáveis: o pagamento ocorreu, o webhook não foi processado, o pedido “ficou preso”. Sem métricas de success rate e latência de webhooks, dá para achar por muito tempo que “está tudo funcionando”, até que os números na contabilidade e no banco de dados comecem a divergir bastante.
Erro nº 5: SLOs irreais ou sua completa ausência.
Às vezes, SLO são formulados no estilo “100% de uptime” ou “nenhum erro”. Na prática, isso é inviável e desmotiva a equipe. O outro extremo — não formular SLO algum e viver no modo “parece bom”. O meio-termo é começar medindo os SLI atuais, definir uma meta um pouco mais rigorosa porém alcançável e ir apertando aos poucos conforme o sistema amadurece.
Erro nº 6: métricas só para cumprir tabela, sem vínculo com o produto.
Também acontece: no sistema de métricas há um monte de gráficos, p95, p99, dezenas de dashboards, mas ninguém responde a uma pergunta simples: “Se esta linha subir — o que sofre? Usuário? Dinheiro? Reputação?” Especialmente em produtos com LLM, é importante conectar indicadores técnicos (latency, error‑rate) às métricas de negócio (conversão, pagamentos bem-sucedidos). Caso contrário, a observabilidade vira uma TV bonita, mas inútil.
GO TO FULL VERSION