APM 2021: monitoraggio applicazioni per PMI con team tech

Hai mai ricevuto la telefonata di un cliente alle 22:30 di sera che ti dice “il vostro gestionale non risponde” e tu stavi cenando, senza la minima idea che ci fosse un problema? Oppure ti è mai capitato di scoprire dai social network che un competitor sta sfruttando un disservizio del tuo SaaS B2B per fare campagne di switching? Nel 2021 il monitoraggio applicativo non è più un lusso per le grandi enterprise: secondo una survey di Gartner pubblicata a gennaio 2014 e ribadita nei report successivi, ogni minuto di downtime di un servizio business-critical costa in media $5.600, con punte oltre i $9.000 al minuto per i settori finance e retail.

Aggiungiamoci che il Black Friday 2021 italiano è atteso per il 26 novembre con volumi di traffico previsti in crescita del 18-22% rispetto al 2020 (fonte: Netcomm), e che molte PMI software italiane gestiscono carrelli, gestionali cloud o portali B2B che in quel weekend lavorano con picchi 10x rispetto alla media. Senza un sistema di Application Performance Monitoring serio diventa impossibile distinguere un rallentamento del database da una saturazione del thread pool, un errore HTTP 500 sporadico da un’epidemia di timeout sul gateway di pagamento, una latenza p95 in deriva da un picco isolato.

Questa guida è pensata per engineering manager, DevOps e IT manager di PMI software italiane che hanno già un team tecnico (anche piccolo, 5-30 persone) e devono decidere come monitorare le proprie applicazioni nel 2021 con un budget realistico, scegliendo tra SaaS a canone e stack open source auto-gestito.

Cos’è l’APM (Application Performance Monitoring): definizione operativa

L’APM, acronimo di Application Performance Monitoring (talvolta letto come “Application Performance Management”), è la disciplina che combina strumenti software e pratiche operative per misurare, diagnosticare e ottimizzare il comportamento di un’applicazione in produzione dal punto di vista di chi la usa e di chi la mantiene.

Tre obiettivi pratici di un sistema APM nel 2021:

• Disponibilità (uptime): l’applicazione risponde alle richieste? In quale percentuale del tempo (SLO al 99,9% = 43 minuti di downtime ammesso al mese)?
• Performance: quanto tempo impiega a rispondere? Sotto quali condizioni di carico? Quali endpoint sono lenti?
• Affidabilità: quanti errori produce per minuto? Su quali utenti, geografie, dispositivi? Quali sono le root cause più frequenti?

A differenza del classico infrastructure monitoring (CPU, RAM, disco, rete) tipico di Nagios, Zabbix o Icinga, l’APM è centrato sul codice applicativo e sul percorso della singola richiesta dell’utente attraverso microservizi, database, code di messaggi e servizi esterni. L’agente APM si installa nell’applicazione (Java, Node.js, Python, .NET, PHP, Go, Ruby) come libreria o sidecar e raccoglie automaticamente metriche, log strutturati e tracce distribuite.

Per una PMI software italiana che gestisce un gestionale ERP custom o un SaaS verticale, l’APM rappresenta il “tachimetro + diagnostica OBD” dell’applicazione: senza di esso si guida a fari spenti e si scopre un problema solo quando il cliente reclama. Per approfondire come strutturare l’osservabilità lato applicazione su un gestionale personalizzato rimandiamo alla nostra pagina dedicata.

APM vs Logging vs Tracing vs Metrics: i 3 pillar dell’observability

Nel 2021 la community SRE (Site Reliability Engineering) consolida il concetto dei three pillars of observability codificato dal libro “Distributed Systems Observability” di Cindy Sridharan (O’Reilly, 2018):

• Metrics: valori numerici aggregati nel tempo (es. richieste/secondo, errori/minuto, latenza p95). Costo storage basso, query veloci, ottime per dashboard e alert. Tool tipici: Prometheus, Datadog Metrics, InfluxDB, Graphite.
• Logs: eventi testuali strutturati o non strutturati emessi dall’applicazione (es. “user=42 action=login result=fail reason=password”). Costo storage alto, query potenti su cardinalità arbitraria. Tool tipici: Elasticsearch + Kibana, Loki, Splunk, Graylog.
• Traces: catena di “span” che descrivono il percorso di una singola richiesta attraverso n servizi (es. richiesta web → API → microservizio ordini → database → microservizio fatturazione → coda Kafka). Tool tipici: Jaeger, Zipkin, Tempo, Datadog APM, New Relic Distributed Tracing.

L’APM come categoria commerciale del 2021 (Datadog APM, New Relic One, Dynatrace, AppDynamics) tipicamente copre tutti e tre i pillar in un’unica piattaforma, mentre lo stack open source richiede di comporre componenti separati (Prometheus per metriche, Loki per log, Tempo per tracce, Grafana come UI unificata).

Una distinzione importante: il logging “classico” alla stdout di Heroku o un file Apache access.log non è observability. L’observability nasce quando i log sono strutturati (es. JSON con trace_id correlato), le metriche hanno label ad alta cardinalità (es. http_requests_total{route="/checkout", status="500", region="eu-west"}) e le tracce sono propagate attraverso ogni hop del sistema.

I 4 indicatori RED: Rate, Errors, Duration + Saturation (USE method)

Quando un engineering manager deve decidere cosa misurare per primo, nel 2021 esistono due metodologie consolidate e complementari:

Il metodo RED, proposto da Tom Wilkie (Weaveworks, poi Grafana Labs) intorno al 2015 e ormai standard de facto per i servizi request-driven, si focalizza su tre metriche per ogni servizio:

• Rate: richieste al secondo gestite dal servizio (throughput). Esempio: il servizio “ordini” sta ricevendo 240 richieste/sec.
• Errors: numero o percentuale di richieste fallite (5xx, eccezioni applicative, timeout). Esempio: tasso errori al 2,1% sopra la soglia dello 0,5%.
• Duration: distribuzione della latenza, idealmente in percentili (p50, p95, p99). Esempio: p95 a 820 ms contro un SLO di 500 ms.

Il metodo USE, proposto da Brendan Gregg (Netflix) intorno al 2012 e centrato sulle risorse (CPU, memoria, dischi, rete, thread pool, connessioni DB), misura per ogni risorsa:

• Utilization: percentuale di tempo in cui la risorsa è occupata.
• Saturation: lavoro extra in coda non ancora servito (es. lunghezza della queue del thread pool).
• Errors: errori di sistema legati alla risorsa (es. ECONNREFUSED sul pool DB).

Nella pratica del 2021 RED si usa per i servizi applicativi (microservizi HTTP, gRPC, GraphQL) e USE per l’infrastruttura sottostante. Aggiungere Saturation agli indicatori RED rende il sistema robusto a scenari di “lenti ma senza errori” (es. thread pool saturo che fa code crescenti).

Apdex score: il punteggio sintetico di soddisfazione utente

L’Apdex score (Application Performance Index) è uno standard aperto definito nel 2004 dall’Apdex Alliance e ancora attivamente usato nel 2021 da New Relic, AppDynamics, Datadog (come metrica derivata) e Dynatrace. Trasforma la distribuzione delle latenze in un singolo numero tra 0 (pessimo) e 1 (eccellente) leggibile anche dal CEO non tecnico.

La formula:

Apdex = (Satisfied + Tolerating/2) / TotalSamples

Dove rispetto a una soglia T (target time, es. 500 ms):

• Satisfied: richieste sotto T (utente soddisfatto).
• Tolerating: richieste tra T e 4T (utente tollera).
• Frustrated: richieste sopra 4T (utente frustrato).

Una griglia di interpretazione tipica:

• Apdex > 0,94 → eccellente
• 0,85 – 0,94 → buono
• 0,70 – 0,84 → accettabile
• 0,50 – 0,69 → mediocre, agire
• < 0,50 → inaccettabile, fermare le release

Il limite dell’Apdex è la scelta arbitraria di T: 500 ms su una landing page marketing è troppo lasco, su una API di pagamento è troppo stretto. Nel 2021 molti team SRE preferiscono SLO espliciti sui percentili (es. “p95 < 400 ms al 99% del mese”) ma Apdex resta utile come sintetico per dashboard executive.

Tool APM SaaS 2021: Datadog, New Relic, Dynatrace, AppDynamics, Honeycomb

Il mercato SaaS del monitoraggio applicativo nel 2021 è dominato da player consolidati e da challenger orientati all’observability moderna:

• Datadog APM: piattaforma unificata che combina infrastruttura, APM, log, RUM (Real User Monitoring) e synthetics. IPO settembre 2019, nel 2021 è il riferimento per startup e scale-up cloud-native. Agenti per ~30 linguaggi, integrazione nativa con AWS/GCP/Azure/Kubernetes.
• New Relic One: rebrand della suite avvenuto a luglio 2020 con il passaggio al pricing per “user + data ingested” anziché per host. Punto di forza storico: distributed tracing maturo e NRQL come linguaggio di query unificato.
• Dynatrace: leader Gartner Magic Quadrant 2021 nel quadrante APM/observability per il sesto anno consecutivo. Architettura “OneAgent” + Davis AI (causation engine basato su grafo di topologia, NON LLM). Target enterprise con contratti annuali.
• AppDynamics: acquisita da Cisco nel 2017 per $3,7 miliardi. Nel 2021 punta sul concetto di “Business iQ” che correla performance tecnica e impatto business (revenue, conversion rate). Forte presenza nel banking e telco.
• Honeycomb: fondata da Charity Majors e Christine Yan (ex Facebook Scuba), lanciata pubblicamente nel 2016. Nel 2021 rappresenta il riferimento per “observability moderna” basata su eventi strutturati ad alta cardinalità e debugging interattivo. Series C da $50M annunciata a settembre 2021.
• Lightstep: fondata da Ben Sigelman (co-autore Dapper paper, OpenTracing, OpenTelemetry). A dicembre 2021 viene acquisita da ServiceNow, ma nel periodo che ci interessa è ancora vendor indipendente, focalizzato su distributed tracing su larga scala e change intelligence.
• Splunk APM: nasce dal rebrand di SignalFx (acquisita da Splunk nel 2019 per $1,05 miliardi) e da Omnition (tracing). Integrazione nativa con Splunk Enterprise per log e con Splunk On-Call (ex VictorOps) per alerting.

Per una PMI italiana il criterio di scelta SaaS nel 2021 ruota intorno a: (a) presenza di agenti per il tuo stack tecnologico, (b) pricing prevedibile rispetto alla crescita, (c) tempo di onboarding (Datadog tipicamente 1-3 giorni vs Dynatrace 2-4 settimane), (d) qualità del supporto in fascia EMEA.

Tool APM open source 2021: Prometheus, Grafana, OpenTelemetry, Jaeger, Elastic APM

Sul fronte open source il 2021 è un anno di consolidamento per uno stack ormai maturo:

• Prometheus: progetto CNCF graduated dal 2018, è lo standard de facto per le metriche pull-based con cardinalità medio-alta. PromQL come linguaggio di query, Alertmanager per le notifiche.
• Grafana: dashboard universale, Grafana Labs rilascia Grafana 8.0 a giugno 2021 con il nuovo sistema di alert unificato che migra da Alertmanager.
• Loki: log aggregation system “à la Prometheus” (indicizza solo metadata, non il body dei log) annunciato da Grafana Labs nel 2018, raggiunge GA con la versione 2.0 nel 2020 e nel 2021 è ampiamente production-ready.
• Tempo: backend di distributed tracing di Grafana Labs annunciato a ottobre 2020 e portato a GA a giugno 2021 con la versione 1.0. Supporta nativamente OpenTelemetry, Jaeger, Zipkin.
• OpenTelemetry (OTel): merge tra OpenTracing e OpenCensus, entra in CNCF incubation a febbraio 2021. Nel 2021 le specifiche per traces sono in beta/GA, metrics in alpha/beta, logs ancora in disegno. Diventa il riferimento per l’instrumentazione vendor-neutral.
• Jaeger: distributed tracing nato in Uber nel 2015, donato a CNCF nel 2017, graduated nel 2019. Backend collaudato con storage Elasticsearch o Cassandra.
• Zipkin: il “nonno” del distributed tracing open source (Twitter, 2012), ancora attivamente mantenuto nel 2021 ma in calo di adozione rispetto a Jaeger.
• Elastic APM: incluso nello stack Elastic (Elasticsearch + Kibana + Beats) dal 2018, nel 2021 è una soluzione “all in one” particolarmente attraente per chi già usa ELK per i log.
• Apache SkyWalking: progetto APM cinese (Apache Software Foundation top-level dal 2019) con forte adozione in Asia, supporta service mesh e database observability.
• Pinpoint: APM open source di Naver (Corea del Sud), focalizzato su JVM languages, attivo dal 2012 e ancora aggiornato nel 2021.

La combinazione Prometheus + Grafana + Loki + Tempo instrumentata con OpenTelemetry è la scelta più solida nel 2021 per chi vuole evitare lock-in vendor mantenendo flessibilità futura, a patto di avere almeno 0,5-1 FTE dedicato all’observability platform.

OpenTelemetry: lo standard emergente del 2021

Vale la pena dedicare un paragrafo a OpenTelemetry (OTel) perché nel 2021 sta diventando il pivot della strategia di osservabilità di praticamente tutti i vendor. Nato dalla fusione di OpenTracing (CNCF dal 2016) e OpenCensus (Google, 2018), OTel diventa CNCF incubating project a febbraio 2021 e rilascia durante l’anno:

• SDK stabili per Java, Python, JavaScript/Node.js, .NET, Go, Ruby (alpha/beta a seconda del linguaggio).
• Specifica OTLP (OpenTelemetry Protocol) come protocollo nativo di esportazione.
• Collector con architettura receiver → processor → exporter che consente di accettare dati da Jaeger, Zipkin, Prometheus e di esportarli verso qualsiasi backend (Datadog, New Relic, Dynatrace, Honeycomb, Lightstep, Splunk APM, Tempo).
• Auto-instrumentation per Java agent e Node.js senza modifiche al codice applicativo.

Il vantaggio strategico per una PMI è che instrumentare l’applicazione con OTel oggi significa non legarsi a un vendor: domani si può passare da Jaeger self-hosted a Honeycomb cloud cambiando una riga di configurazione del Collector, senza rifare l’instrumentation in 800k righe di codice.

Pricing APM 2021: confronto realistico per PMI

Confrontare i prezzi APM nel 2021 è un mestiere a parte perché ogni vendor usa unità di misura diverse. Ecco i listini pubblici di riferimento al novembre 2021:

• Datadog APM: $31/host/mese in fatturazione annuale, $40/host/mese on-demand. Si aggiungono $0,10 per 10.000 span indicizzati oltre la quota inclusa. Per una PMI con 15 host applicativi: ~$465/mese ≈ 410 €/mese.
• New Relic One: dopo il pricing change di luglio 2020, $99/user/mese per ogni Full Platform User, più $0,25/GB di dati ingeriti oltre i 100 GB/mese gratuiti. Una PMI con 8 ingegneri full user e 50 GB/mese: $792/mese ≈ 700 €/mese.
• Dynatrace: pricing non pubblico, contratti enterprise annuali, ordini di grandezza da $21/host/mese per 8GB di memoria a salire. Sotto i 50 host raramente sotto i $25k/anno ≈ 22.000 €/anno.
• AppDynamics: pricing per “agent type” (Pro, Enterprise, Real User Monitoring) tipicamente $60-90/agent/mese in contratto annuale. Per 15 agenti: ~$13k/anno ≈ 11.500 €/anno.
• Honeycomb: piano free 20M eventi/mese, Pro $100/mese per 50M eventi, Enterprise custom. Per una PMI mid-size 50-200M eventi/mese: $200-600/mese ≈ 180-530 €/mese.
• Splunk APM: $60/host/mese in contratto annuale (rebrand di SignalFx Premium APM).
• Elastic APM: free se self-hosted (parte dello stack Elastic free tier), oppure Elastic Cloud da $95/mese per la configurazione minima production con 4 GB di RAM.
• Stack open source (Prometheus + Grafana + Loki + Tempo + OTel): licenza zero, costo infra cloud variabile. Una stima realistica per 15 host applicativi e ~50 GB log/mese su AWS: $300-500/mese ≈ 265-440 €/mese, MA serve aggiungere il costo umano di 0,3-0,5 FTE per la gestione (€2-4k/mese).

Conclusione operativa: sotto i 20 host applicativi e con un team che non ha una persona dedicata all’observability platform, il SaaS (Datadog APM o New Relic One) costa meno dello stack open source self-hosted quando si conta il costo del personale. Sopra i 100 host o con dati molto sensibili (regolamentazione finanziaria, sanità) lo stack open source diventa competitivo.

Use case concreti: anomaly detection, SLO/error budget, alerting smart

Nel 2021 tre use case definiscono il valore concreto di un APM ben configurato:

1) Anomaly detection sulla latenza. Configurare alert statici sulla p95 latency (es. “alert se p95 > 500 ms”) è un’arma a doppio taglio: di notte il traffico è basso e la p95 oscilla naturalmente. Datadog dal 2018 e New Relic da febbraio 2021 con Applied Intelligence offrono algoritmi di anomaly detection (basati su decomposizione stagionale, NON su LLM) che rilevano deviazioni rispetto al pattern settimanale. Esempio: alle 22:00 di martedì la p95 normalmente è 320 ms; un’anomalia che porta a 580 ms scatena alert anche se sotto la soglia statica di 600 ms.

2) Error budget e SLO. Il framework SLO/SLI/error budget codificato dal libro Google SRE (O’Reilly, 2016) e dal seguito “The Site Reliability Workbook” (O’Reilly, 2018) è ormai adottato anche dalle PMI mature. Esempio per una PMI fintech italiana:

• SLI: percentuale di richieste HTTP 2xx sotto i 400 ms per endpoint /api/pagamenti.
• SLO: 99,5% al mese (calcolato su finestra 28 giorni rolling).
• Error budget: 0,5% × ~3M richieste/mese = 15.000 richieste “fallibili” al mese.
• Burn rate alert: scatta se il budget viene consumato a velocità 14,4x (= esaurimento in 1 ora se prosegue).

L’error budget diventa lo strumento con cui il management bilancia velocità di release e affidabilità: budget abbondante = via libera ai deploy aggressivi, budget esaurito = freeze release e focus su affidabilità.

3) Alerting smart e anti-fatigue. Nel 2021 il principale fattore di burnout dei team on-call è l’alert fatigue. Un APM ben configurato segue tre regole d’oro:

• Symptom-based, non cause-based: si alerta sull’esperienza utente (es. “checkout fallisce”) e non su ogni componente intermedio.
• Actionable: ogni alert ha un runbook collegato; se non si sa cosa fare ricevuto l’alert, l’alert non doveva partire.
• Multi-window burn rate: combinare finestre brevi (rilevamento veloce di incident gravi) e lunghe (rilevamento di degradi lenti) come descritto nel capitolo 5 del Site Reliability Workbook.

Integrazione APM e incident management: PagerDuty, OpsGenie, Splunk On-Call

Un APM senza un sistema di incident management collegato è un libro di letture che nessuno apre. Nel 2021 tre player dominano l’incident management:

• PagerDuty: leader storico (fondata nel 2009, IPO aprile 2019). Offre routing, escalation policy, on-call schedules, integrazioni native con Datadog, New Relic, Dynatrace, Prometheus Alertmanager. Piano Professional $21/user/mese, Business $41/user/mese.
• Atlassian OpsGenie: acquisita da Atlassian a settembre 2018, integrata nella suite Jira Service Management. Pricing aggressivo: Essentials $9/user/mese, Standard $19/user/mese.
• Splunk On-Call: rebrand 2021 di VictorOps (acquisita da Splunk nel 2018). Integrazione nativa con Splunk APM e Splunk Observability Cloud.

L’integrazione tipica nel 2021 è: APM rileva anomalia → invia webhook a PagerDuty/OpsGenie → routing all’on-call attuale via app mobile/SMS/chiamata → engineer apre Slack e canale dedicato all’incident → coordinazione con Zoom/Meet → root cause analysis con dati APM → post-mortem blameless con timeline ricostruita dai trace.

Per una PMI italiana 5-30 persone tech, una configurazione realistica è OpsGenie Essentials + Datadog APM + Slack per la coordinazione: costo totale on-call infrastructure ~200-300 €/mese.

Errori comuni: nessun SLO, alert fatigue, zero correlazione business

Negli ultimi tre anni abbiamo visto decine di rollout APM in PMI italiane, e i pattern di fallimento si ripetono:

• Installare l’agente e basta. Datadog o New Relic mostrano subito belle dashboard, e il team pensa “fatto”. In realtà senza SLO definiti e senza alert configurati, l’APM serve solo a confermare i problemi dopo il fatto.
• Alert su ogni metrica. Si parte entusiasti, si configurano 80 alert in due settimane, dopo un mese il canale Slack #alerts riceve 200 messaggi al giorno e nessuno guarda più nulla. Regola empirica: meno di 10 alert “actionable” per servizio.
• Zero correlazione con il business. La p95 latency è 380 ms e l’errore rate è 0,3%: questi numeri non dicono niente al CEO. Bisogna tradurre: “il checkout sta perdendo il 4% degli utenti per timeout, equivalente a circa 12.000 € di mancato fatturato al giorno”.
• Trascurare il frontend. L’APM tradizionale misura il backend, ma il Real User Monitoring (RUM) sul frontend (browser, mobile) è altrettanto critico. Datadog RUM e New Relic Browser sono inclusi a costo aggiuntivo modesto.
• Non instrumentare i database. Spesso il 60% della latenza p95 di un endpoint è una query Postgres lenta. Senza un APM che mostra il piano di esecuzione e le query top-N per tempo cumulativo, si caccia il fantasma.
• Confondere monitoring e observability. Il monitoring risponde a “il sistema sta funzionando?” con metriche predeterminate; l’observability risponde a “perché sta succedendo X?” interrogando dati ad alta cardinalità. Servono entrambi.

Caso reale: PMI fintech italiana porta il MTTD da 35 a 4 minuti

Vediamo un caso concreto del 2021 (cliente anonimizzato): PMI fintech italiana ~40 dipendenti, gestisce una piattaforma di pagamenti B2B con ~1.500 merchant clienti e volumi di transazione tra 80k e 220k al giorno. Stack: Java Spring Boot su Kubernetes (EKS), PostgreSQL RDS, Redis ElastiCache, Kafka MSK, 12 microservizi.

Situazione di partenza (Q1 2021): monitoring basato su CloudWatch + Grafana self-hosted con dashboard fatte a mano. Gli incident venivano scoperti tipicamente dalle telefonate dei clienti, con un MTTD (Mean Time To Detect) medio di 35 minuti. MTTR (Mean Time To Recover) medio 2 ore e 15 minuti. Customer success team riportava 4-5 incident “noti ai clienti prima che a noi” al mese.

Intervento Q2-Q3 2021:

• Adozione Datadog APM con auto-instrumentation Java + custom span sui flussi critici (autenticazione, autorizzazione pagamento, settlement).
• Definiti 4 SLO sui servizi critici (autorizzazione: 99,5% sotto 800 ms; settlement: 99,9% sotto 2 s; portal merchant: 99,5% sotto 1 s; webhook out: 99% sotto 5 s).
• Burn rate alert multi-finestra (5 min / 1 ora) integrati con OpsGenie e Slack.
• Anomaly detection abilitata su latenza p95 per endpoint top-15 per traffico.
• Runbook per ogni alert (12 totali) e on-call rotation settimanale con 4 engineer.
• Post-mortem blameless dopo ogni incident con timeline ricostruita dai trace Datadog.

Risultati a 90 giorni dall’attivazione completa (ottobre 2021):

• MTTD da 35 a 4 minuti (-88%).
• MTTR da 135 a 48 minuti (-64%).
• Incident scoperti prima dai clienti: da 4-5/mese a 0-1/mese.
• SLA contrattuale 99,5% rispettato per 6 mesi consecutivi (era stato mancato 2 volte nel 2020).
• Costo Datadog APM + RUM: ~580 €/mese su 18 host equivalenti.

Il payoff economico stimato (penali contrattuali evitate + churn evitato + riduzione tempo on-call) è stato calcolato in ~6,8x il costo del primo anno di Datadog.

Roadmap rollout APM in 60 giorni: piano step-by-step

Per chiudere, ecco una roadmap operativa di 60 giorni testata su PMI italiane con team tech 5-30 persone:

Settimana 1-2 — Discovery e baseline. Inventariare servizi, dipendenze, picchi di traffico storici, SLA contrattuali esistenti. Misurare i KPI attuali (MTTD, MTTR, incident/mese, downtime cumulato). Coinvolgere customer success per la lista dei “soliti sospetti” lato cliente.

Settimana 3 — Scelta tool. POC parallelo tra 2 vendor (es. Datadog vs New Relic, oppure SaaS vs Prometheus+Grafana+Tempo) per 14 giorni su 1 servizio non critico. Valutare: tempo di setup, qualità auto-instrumentation, costo previsto a 12 mesi sul volume reale.

Settimana 4-5 — Instrumentation. Roll-out agente APM su tutti i servizi (auto-instrumentation per Java/Node/Python, manuale per Go). Custom span sui flussi business critici. Configurazione log strutturati JSON con trace_id correlato.

Settimana 6 — Definizione SLO. Workshop con product manager + tech lead per definire 1-3 SLO per servizio critico. Documentare in un SLO doc condiviso. Configurare burn rate alert multi-finestra.

Settimana 7 — Incident management. Setup PagerDuty/OpsGenie con escalation policy e on-call rotation. Integrare con Slack canali #incident e #alerts. Pubblicare runbook su Confluence/Notion per ogni alert.

Settimana 8 — Dry run e go-live. Simulare 2-3 incident in staging usando chaos engineering light (kill di un pod, latenza iniettata su Redis). Verificare che alert, routing, runbook funzionino. Go-live con on-call settimanale.

Settimana 9 — Post-mortem culture. Primo post-mortem blameless su un incident reale. Templates su Notion. Action item tracciate su Jira con SLA risoluzione.

A 60 giorni dalla partenza si dovrebbe avere: APM live, SLO definiti, on-call funzionante, almeno un incident gestito con il nuovo processo. Da lì in poi è iterazione continua su soglie, runbook, copertura RUM frontend e maturazione del processo.

Domande frequenti sull’APM 2021