1. Perché servono metriche e SLO in una ChatGPT App
Immaginate due stati della squadra.
Nel primo tutti vivono secondo il principio «sembra che funzioni». Finché gli utenti non scrivono al supporto e non postano tweet arrabbiati — tutto ok. Di tanto in tanto qualcuno dà un’occhiata ai log, scorre un «lenzuolo» di righe, annuisce e chiude la scheda.
Nel secondo la squadra ha alcuni pannelli semplici:
- p95 della latenza dello strumento MCP principale.
- error‑rate per MCP e per il checkout.
- disponibilità dei webhook.
- conversione al pagamento lungo il funnel.
E ci sono 3–5 SLO: «Il 95% delle chiamate allo strumento recommend_gifts — più veloce di 2 secondi», «quota di errori degli MCP‑tools < 1%», «disponibilità del checkout ≥ 99.5%», «conversione dal widget al pagamento riuscito ≥ 10%».
Nel secondo scenario voi:
- capite rapidamente che con l’app c’è qualcosa che non va, ancora prima delle lamentele;
- potete misurare l’effetto di qualsiasi modifica (nuovo algoritmo di raccomandazione, migrazione dell’SDK, nuovo piano del provider);
- e quando arriverete al modulo su Store e review, potrete dire onestamente: «abbiamo criteri di qualità e sappiamo quanto li rispettiamo».
Parleremo di cose molto ovvie: cos’è p95, perché è migliore della media, come calcolare error‑rate e availability, quali metriche sono importanti per la parte commerce con i webhook e come da tutto questo ricavare SLO semplici ma utili. Analizzeremo tutto sull’esempio della nostra app didattica GiftGenius — uno scenario commerce con uno strumento MCP di raccomandazioni, checkout e webhook di pagamento.
2. Metriche di base per una ChatGPT App: cosa misurare
Latenza: p50/p95/p99 invece della «media generica»
La latenza è il tempo dall’inizio di un’operazione alla sua fine logica. Nel nostro stack ci sono diverse operazioni del genere:
- chiamata dello strumento MCP recommend_gifts (selezione dei regali);
- chiamata dello strumento che crea il checkout intent in ACP;
- elaborazione del webhook di pagamento riuscito.
È importante capire che il ritardo complessivo percepito dall’utente in ChatGPT lo controlliamo solo in parte. C’è la quota della piattaforma (inferenza del modello, latenze di rete OpenAI) e c’è la nostra — strumenti, backend, DB, gateway di pagamento. Per lo SLI (Service Level Indicator — indicatore misurabile del livello del servizio) sulla latenza in genere si misura proprio la nostra parte: dall’ingresso della richiesta nell’App/MCP alla risposta pronta del nostro server.
Il tempo medio di risposta è fuorviante. Se il 90% delle richieste arriva in 100 ms e il 10% in 5 secondi, la media sarà circa mezzo secondo e il grafico sembrerà «verde». Ma un utente su dieci vede un freeze di 5 secondi — l’UX ne risente parecchio.
Perciò si usano i percentili: p50 (mediana), p95, p99. p95 è il valore sotto il quale rientra il 95% delle richieste. Come sottolineano le guide SRE, i percentili «non lasciano che gli outlier si nascondano nella media» e rendono visibile la vita di quel 5–10% di utenti sfortunati che finiscono sempre in coda alla distribuzione.
Il modo più semplice di pensarci: p50 dice come vive «l’utente medio», mentre p95/p99 dicono quanto soffrono le persone pazienti a cui «qualcosa va sempre lento».
Error‑rate: quota di richieste non riuscite
Error‑rate è il rapporto tra il numero di richieste non riuscite e il numero totale di richieste in un periodo. La fonte principale dei dati sono di solito o i log strutturati, o metriche con label status="success" | "error".
Nel nostro stack ci sono diversi error‑rate naturali:
- a livello di MCP‑tools: quota di chiamate a recommend_gifts concluse con errore (eccezione, HTTP 5xx di un’API esterna, timeout);
- a livello ACP/checkout: quota di tentativi di ordine non riusciti (errore API, indisponibilità del gateway di pagamento);
- a livello di handler dei webhook: quota di webhook per cui l’elaborazione si è conclusa con errore.
C’è una sottigliezza: nelle ChatGPT App capitano errori «silenziosi». Per esempio, lo strumento MCP restituisce un errore, il modello si scusa e prosegue il dialogo senza far emergere l’errore tecnico nel titolo. Formalmente ChatGPT mostra una risposta «umana», ma dal punto di vista dell’affidabilità il vostro stack ha fallito. Perciò per l’error‑rate è importante contare gli stati ingegneristici, non la «risposta UX finale di GPT».
Availability: disponibilità dei servizi
Availability è la percentuale di richieste servite con successo in un periodo. Concettualmente è lo stesso error‑rate, ma con segno opposto: «quante riuscite», non «quante non riuscite». Esempio classico: availability = successful_requests / total_requests * 100%.
Applicato al nostro stack:
- disponibilità del server MCP: quante chiamate JSON‑RPC da ChatGPT si sono concluse con una risposta corretta nell’ultima ora;
- disponibilità del checkout‑API: quale quota di richieste a /api/checkout si è conclusa con HTTP 2xx;
- disponibilità dell’endpoint dei webhook: quale quota di webhook in ingresso dal gateway di pagamento ha ricevuto da noi una risposta corretta (di solito HTTP 200).
Se la documentazione del provider di pagamento promette, per esempio, 99.9% di disponibilità e voi avete 97%, probabilmente il problema non è loro.
Metriche commerce: conversione e funnel
GiftGenius è uno scenario commerce. Qui non conta solo la tecnica (risposte rapide, pochi errori), ma anche il risultato di business — quanto spesso le raccomandazioni si trasformano in ordini pagati.
Qui entra in gioco il funnel di conversione:
- utenti a cui è mostrato il widget (view);
- utenti che hanno scelto un regalo (selection);
- utenti che hanno cliccato «effettua l’ordine» (checkout started);
- utenti il cui stato ordine è diventato «pagato» (paid).
Da questo funnel si può calcolare la conversione «dal widget al pagamento»; anche questo è uno SLI — un indicatore misurabile della qualità del servizio. Per esempio, «conversione pagamenti riusciti / utenti che hanno visto il widget nelle 24 ore = 7%». Se la latenza aumenta all’improvviso, o il checkout a volte cade in timeout, il funnel inizierà a restringersi in punti inattesi.
Se usate Instant Checkout
Tutte le metriche commerce descritte si applicano anche a Instant Checkout basato su Agentic Commerce Protocol. In questo caso al posto del vostro /api/checkout avete un Agentic Checkout API standardizzato: ChatGPT chiama i vostri endpoint REST POST /checkout_sessions, POST /checkout_sessions/{id}, POST /checkout_sessions/{id}/complete (e opzionalmente — cancel e GET), ottenendo ogni volta da voi lo stato «veritiero» del carrello e del checkout.
Per le metriche non cambia nulla: p95 della latenza, error-rate e availability li conterete non su un /api/checkout arbitrario, ma su questi endpoint standard. Gli SLO del tipo «p95 della latenza del checkout < 3 secondi, error-rate < 2%» si applicano semplicemente alle chiamate checkout_sessions, non a un API fatto in casa.
Un mondo a parte: metriche dei webhook
I webhook sono eventi asincroni (per esempio, payment_succeeded dal gateway di pagamento) che fanno avanzare l’ordine nel suo ciclo di vita. Se i webhook vengono elaborati male, l’app può raccomandare i regali in modo perfetto, ma gli ordini rimarranno «bloccati» con lo stato «in attesa di pagamento» o in una condizione indefinita.
Se vi integrate non direttamente con Stripe/il gateway, ma tramite Instant Checkout, il ruolo dei «webhook del gateway» è assunto dagli order events di Agentic Checkout: il vostro backend invia a OpenAI eventi come order.created e order.updated a un URL di webhook dedicato. È esattamente la stessa classe di entità: eventi asincroni da cui dipende lo stato finale dell’ordine, solo che il destinatario non è il vostro frontend, ma ChatGPT.
Di conseguenza, le stesse metriche — success rate, latency, error-rate — le conterete non sui webhook di Stripe, ma sui vostri webhook di order event verso OpenAI. Negli SLO potete scrivere esplicitamente «almeno il 99% degli eventi order.* viene consegnato ed elaborato con successo in 7 giorni, p95 della latenza di elaborazione < 500 ms» — ed è uno SLI/SLO corretto proprio per Instant Checkout.
Per i webhook di solito si guarda a:
- webhook success rate — quota di webhook per cui la business logic si è conclusa con successo (inclusi i retry);
- webhook latency — tempo dall’ingresso del webhook alla fine dell’elaborazione;
- webhook error rate — quota di casi in cui l’elaborazione del webhook è terminata con errore (validazione fallita, DB non disponibile, timeout, ecc.).
Per esempio, si può definire uno SLO: «almeno il 99% dei webhook è elaborato con successo in 7 giorni» e «p95 della latenza di elaborazione del webhook < 500 ms».
3. Come misurare tecnicamente le metriche in GiftGenius
Passiamo dalla teoria al codice. Dobbiamo capire dove inserire le misurazioni, per poi aggregare i dati in p95, error‑rate e altre metriche.
Per non portare in questa lezione un Prometheus o un Datadog specifico, supponiamo di avere una funzione semplice logMetric o un logging di eventi JSON. Sopra a questo, qualsiasi sistema di osservabilità costruirà i grafici necessari.
Misuriamo la latenza dello strumento MCP
Supponiamo di avere un server MCP GiftGenius in TypeScript e lo strumento recommend_gifts. Incartiamo la business logic con un timer:
// mcp/tools/recommendGifts.ts
import { logMetric } from "../observability/metrics"; // helper fittizio
export async function recommendGiftsTool(input: RecommendInput) {
const startedAt = performance.now(); // ora di inizio
try {
const result = await recommendGifts(input); // logica di business
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;
}
}
Qui logMetric può semplicemente scrivere un log JSON su stdout:
// observability/metrics.ts
export function logMetric(
name: string,
value: number,
labels: Record<string, string | number>
) {
// Nella realtà qui ci sarà un client Prometheus/DataDog
console.log(
JSON.stringify({
type: "metric",
name,
value,
labels,
timestamp: new Date().toISOString(),
})
);
}
Con questo approccio ottenete un flusso di eventi tool_latency_ms, in cui, già tramite le label tool e status, potete calcolare il p95 solo sulle chiamate riuscite o, al contrario, osservare quanto durano le richieste che finiscono in errore.
Calcoliamo l’error‑rate
In modo analogo si può loggare una metrica di errori separata:
// dentro lo stesso handler dello strumento
logMetric("tool_error_total", 1, {
tool: "recommend_gifts",
error_type: "external_api_timeout",
});
E per le richieste riuscite:
logMetric("tool_success_total", 1, {
tool: "recommend_gifts",
});
Poi nel sistema di metriche costruite error_rate = tool_error_total / (tool_error_total + tool_success_total) per il periodo. Questo si aggrega già lato sistema di metriche; nell’app è importante solo emettere correttamente gli eventi.
Se volete il minimo indispensabile, potete cavarvela anche con i soli log senza una error_total separata. Allora l’error‑rate si calcola dal campo status.
Metriche del checkout/ACP
Per l’endpoint di checkout in Next.js la logica è la stessa: incartiamo l’handler con un timer e contiamo gli 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); // chiamata ad 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 }
);
}
}
Ora potete osservare il p95 su checkout_latency_ms e l’error‑rate su checkout_total. Sulla base di questi SLI è semplice impostare SLO del tipo «p95 < 3 secondi, error‑rate < 2%».
Metriche dei webhook
E naturalmente i webhook. Abbiamo già discusso quali metriche ci servono (vedi sezione 2), ora vediamo come rilevarle nel codice. Qui è particolarmente importante non solo il tempo, ma anche l’esito dell’elaborazione: altrimenti l’utente paga, ma l’ordine non passa a «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(); // dati grezzi
const sig = req.headers.get("stripe-signature") || "";
const event = verifyStripeSignature(payload, sig); // validazione
await handlePaymentEvent(event); // aggiorniamo l'ordine
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 });
}
}
Su questi eventi potete definire degli SLI:
- webhook success rate = success / (success + error);
- p95 di webhook_latency_ms per payment_succeeded.
E poi definire per essi degli SLO, per esempio «il 99% dei webhook è elaborato con successo in 7 giorni, p95 < 500 ms».
4. Statistiche dei percentili: un po’ più a fondo
Abbiamo già citato più volte p50/p95/p99, ora vediamo in modo un po’ più formale cosa rappresentano. Nella pratica i percentili saranno calcolati dal sistema di metriche, ma è utile capire cosa succede dietro le quinte.
Il percentile pX è il valore sotto il quale cade X percento delle misurazioni. Se ordinate l’array delle latenze in modo crescente, il p95 starà verso la «coda», vicino ai valori massimi. In codice (per esempio su Node, se voleste calcolare localmente il p95 per un set di valori) può apparire più o meno così:
// funzione semplice per calcolare un percentile
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))];
}
Una funzione del genere può essere usata nei test o in uno script semplice che giochi con i dati e mostri quanto il p95 differisca dalla media. In produzione questo compito lo svolgeranno Prometheus, Datadog, New Relic e altri strumenti maturi.
5. SLI, SLO e SLA: in parole semplici
Tre sigle che possono sembrare minacciose, ma in realtà sono molto semplici.
SLI — Service Level Indicator
SLI è un indicatore misurabile concreto, una formula. Per esempio:
- p95(latency) dello strumento recommend_gifts nelle ultime 24 ore;
- error‑rate degli strumenti MCP negli ultimi 7 giorni;
- conversione widget → pagamento riuscito per settimana.
SLI non è un obiettivo né una promessa, è solo un «termometro».
SLO — Service Level Objective
SLO è un obiettivo per uno SLI, in sostanza una condizione di «salute» del servizio. Per esempio:
- «p95(latency di recommend_gifts) < 2 secondi su finestra di 7 giorni»;
- «error‑rate di tutti gli MCP‑tools < 1% su finestra di 30 giorni»;
- «disponibilità del checkout API ≥ 99.5% per trimestre»;
- «conversione dal widget al pagamento riuscito ≥ 15% al mese».
Buona prassi — misurare prima il livello attuale e impostare uno SLO leggermente più rigoroso di ciò che già riuscite a mantenere, altrimenti diventerà o una «missione impossibile», o un «va già bene così».
SLA — Service Level Agreement
SLA non è più un obiettivo interno, ma un accordo esterno con utenti o partner. Nello SLA si scrivono gli impegni (per esempio, «99.9% di uptime») e le conseguenze delle violazioni (compensi, penali, estensione dell’abbonamento, ecc.). Lo SLO è spesso più severo dello SLA, per avere margine nel «budget di errore».
Nel contesto didattico di GiftGenius, probabilmente uno SLA non vi serve, ma è importante capire la scaletta:
SLI → SLO → SLA
metrica → obiettivo → promessa esterna
Error budget (budget degli errori)
Error budget è, semplificando, la quantità ammissibile di «non perfezione». Se avete uno SLO «disponibilità 99.9% su 30 giorni», allora lo 0.1% è il budget di errore che potete «consumare» per:
- rilasci programmati con downtime;
- esperimenti;
- incidenti imprevisti.
Quando il budget è «bruciato» (per esempio, il dato reale del mese è disponibilità 99.5%), è il momento di rallentare le nuove feature e sistemare la stabilità.
6. Metriche speciali per GiftGenius: commerce + webhook
Mettiamo insieme tutto e guardiamo a GiftGenius come a un prodotto completo.
Funnel e conversione
Immaginiamo un percorso utente semplice:
flowchart TD A[Aperta l'App con il widget GiftGenius] --> B[Ricevute le raccomandazioni] B --> C[Scelto il regalo] C --> D[Clic su 'procedi al pagamento'] D --> E[Pagamento riuscito]
Per ogni passo possiamo loggare un 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",
});
Poi, conoscendo il numero di eventi ai passi widget_view e checkout_paid, possiamo calcolare la conversione: paid / view * 100%. E impostare uno SLO: «conversione ≥ 10%». Se improvvisamente la conversione scende al 3%, ma gli SLI tecnici (latency/error‑rate) sembrano normali, forse il problema è nell’UX, nelle istruzioni per il modello o nella qualità del feed di prodotto, non nell’infrastruttura.
Metriche dei webhook come parte della conversione
Abbiamo già parlato delle metriche tecniche dei webhook e della loro implementazione. Ora è importante collegarle alla conversione: per gli scenari commerce i webhook sono critici. L’utente vede «pagamento effettuato», ma lo stato finale dell’ordine dipende da quanto rapidamente il vostro backend riceve ed elabora payment_succeeded.
SLI per i webhook:
- webhook success rate;
- webhook latency p95;
- disponibilità grezza di webhook_endpoint_availability.
Se il success rate dei webhook scende, state letteralmente perdendo ordini.
7. Alert semplici sopra gli SLO
Un sistema di alerting completo è un tema più vicino ai moduli operativi, ma possiamo già delineare la base.
L’idea è inviare alert non per ogni singolo errore, ma per la violazione di uno SLO. È ciò che spesso si chiama symptom‑based alerts — alert legati ai sintomi di degrado del servizio: non vi interessa «c’è stato un errore», ma «il servizio ha iniziato a funzionare sistematicamente peggio del promesso».
Esempi tipici:
- error‑rate degli MCP‑tools negli ultimi 5 minuti > 2% con SLO < 1%;
- p95(latency di recommend_gifts) negli ultimi 10 minuti > 3 secondi con SLO 2 secondi;
- negli ultimi 15 minuti non c’è nessun checkout_paid riuscito — sospetto di un down dell’integrazione;
- webhook success rate negli ultimi 10 minuti < 95%.
Il testo dell’alert deve essere comprensibile, non «Alert: metric 123 > 456». Esempio di «notifica in Slack» per 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.
Messaggi del genere sono legati agli SLO e aiutano lo sviluppatore on‑call a capire rapidamente l’impatto.
8. Mini‑pratica: definiamo degli SLO per GiftGenius
Proviamo a formulare un set di SLO per la nostra app. Si può fare anche su carta, senza un sistema di metriche completo.
Esempio di «partenza»:
- Per lo strumento MCP principale recommend_gifts:
- SLI: p95(latency) delle chiamate riuscite negli ultimi 7 giorni.
- SLO: p95(latency) < 2 secondi.
- Per gli errori degli strumenti MCP:
- SLI: error‑rate = errors / (errors + successes) su 30 giorni.
- SLO: error‑rate < 1%.
- Per il checkout API:
- SLI: availability = quota di HTTP 2xx sul totale delle richieste.
- SLO: availability ≥ 99.5% al mese.
- Per i webhook di pagamento:
- SLI: webhook success rate.
- SLO: almeno il 99% di elaborazioni di webhook riuscite in 7 giorni; p95 della latenza di elaborazione < 500 ms.
- Per il risultato di business:
- SLI: conversione widget → ordine pagato per mese.
- SLO: conversione ≥ 10–15% (a seconda della nicchia).
Anche un set così piccolo dà già un «telaio» per prendere decisioni: se rilasciate una nuova versione del modello, cambiate il prompt o l’algoritmo di raccomandazione e vedete che p95 ed error‑rate restano entro gli SLO, mentre la conversione cresce — probabilmente l’esperimento è riuscito.
Se invece del vostro endpoint di checkout usate Instant Checkout, allora «checkout API» sono di fatto le chiamate all’Agentic Checkout (/checkout_sessions create/update/complete), e i «webhook di pagamento» sono i vostri order events (order.created, order.updated) verso OpenAI. Metriche e formulazioni degli SLO restano le stesse, cambia solo il protocollo specifico.
9. Errori tipici nel lavoro con metriche e SLO
Errore n. 1: misurare solo il tempo di risposta medio.
La media è comoda, ma pericolosa. Maschera facilmente la coda di richieste lente. Nelle ChatGPT App è critico: anche se la maggior parte degli utenti riceve tutto rapidamente, lag di 5–10 secondi regolari per una piccola percentuale saranno percepiti come «l’app è sempre lenta». Per la latenza usate sempre almeno p50 e p95, non solo la mean.
Errore n. 2: confondere SLI, SLO e SLA nella testa e nella documentazione.
A volte gli sviluppatori scrivono «il nostro SLA — p95 < 2 secondi», quando in realtà non è fissato da nessuna parte per gli utenti esterni e non è accompagnato da alcun impegno. In realtà quello è uno SLO. Lo SLA è un accordo con i clienti, con conseguenze in caso di violazione. Se mescolate tutto, non sarà chiaro cosa promettete davvero e a chi.
Errore n. 3: nessun collegamento tra alert e SLO.
La trappola classica — impostare alert «per ogni errore», per ogni timeout, per qualsiasi deviazione della metrica di 0.01. Il risultato è che l’ingegnere on‑call vive in un inferno di notifiche e smette di guardarle. Molto più utile costruire alert sulla violazione degli SLO: se l’error‑rate cresce ben oltre il livello target o il p95 «esce» dai limiti, allora ha senso svegliare le persone.
Errore n. 4: ignorare le metriche dei webhook e delle parti asincrone.
Un problema separato, ma già noto, è ignorare le metriche dei webhook e dell’elaborazione in background. Molti team monitorano solo le risposte HTTP degli API principali, ma non guardano i webhook e i worker. Negli scenari commerce è proprio lì che si nascondono i bug più spiacevoli: pagamento effettuato, webhook non elaborato, ordine «bloccato». Senza metriche di success rate e latency sui webhook si può pensare a lungo che «tutto funziona», finché i numeri in contabilità e nel DB non iniziano a divergere molto.
Errore n. 5: SLO irrealistici o totale assenza di SLO.
A volte gli SLO vengono formulati in stile «100% uptime» o «nessun errore mai». In pratica è irrealizzabile e demotivante. L’estremo opposto — non formulare affatto gli SLO e vivere in modalità «più o meno ok». La via di mezzo — iniziare misurando gli SLI attuali, impostare un obiettivo un po’ più rigoroso ma raggiungibile e irrigidirlo gradualmente man mano che il sistema matura.
Errore n. 6: metriche solo per fare numero, senza legame con il prodotto.
Capita anche questo: nel sistema di metriche ci sono tanti grafici, p95, p99, decine di dashboard, ma nessuno sa rispondere alla domanda semplice: «Se questa linea sale — cosa ne soffre? L’utente? I ricavi? La reputazione?» Soprattutto nei prodotti LLM è importante collegare gli indicatori tecnici (latency, error‑rate) alle metriche di business (conversione, pagamenti riusciti). Altrimenti l’osservabilità diventa una TV bella da vedere, ma inutile.
GO TO FULL VERSION