Osservabilità per software B2B custom

Osservabilità vs monitoring tradizionale nel B2B

Il monitoring controlla failure mode noti: disco pieno, rate 5xx, profondità coda. L'osservabilità permette domande nuove con log, metriche e trace correlati quando il failure mode non era previsto. Il B2B aggiunge dimensioni business: tenant_id, site_id, partner integrazione, step workflow. Ogni segnale deve portare questi tag così gli incidenti si filtrano a un cliente senza indovinare. I contratti cliente possono richiedere report uptime e notifiche incident. Il design telemetria deve produrli senza archeologia manuale su spreadsheet.

• Tagga tutti i segnali con tenant e correlation ID
• Definisci journey di business, non solo nomi microservizio
• Separa status page operatori da dashboard engineer
• Ritieni dati abbastanza a lungo per indagini fine mese

Golden signal per journey di business

Scegli tre-sette journey commercialmente rilevanti: login, crea ordine, catena approvazione, post ERP, export report, consegna webhook. Per ciascuno definisci criteri successo, budget latenza ed error budget. Strumenta ai confini: handler API, commit service dominio, chiamata integrazione outbound, completamento job. Span mancanti rendono 'approvazione lenta' impossibile da localizzare. Esempio SLO: 99% post ERP completano entro 60 secondi escluse finestre manutenzione cliente. Misura dall'azione utente ad acknowledgment ERP confermato. Allinea la lista journey ai workflow discovery così l'osservabilità è progettata, non retrofit.

Log strutturati e distributed tracing

Usa log JSON strutturati con nomi campo stabili: timestamp, level, message, tenant_id, user_id, correlation_id, journey, step. Grep free-text su pod non scala oltre tre servizi. Propaga correlation ID da browser o API attraverso job fino ai client integrazione. I ticket supporto devono includere un ID che collega tutta la catena. Il tracing aiuta con più servizi o path async pesanti. Campiona in produzione per costo; traccia sempre errori e journey lenti sopra soglia. Non loggare segreti, PII completa o payload pagamento. Redigi e classifica secondo policy audit e privacy.

Osservabilità per integrazioni e code

Traccia salute per integrazione: success rate, percentile latenza, conteggio retry, messaggio non processato più vecchio, backlog riconciliazione. ERP lento è il tuo incident anche se l'app è 'up'. Dashboard per customer success: vista tenant-scoped ultimo sync riuscito, ultimo errore (sanitizzato), replay self-service se sicuro. Alert su anomalia, non solo soglia: calo improvviso post per un tenant può significare credenziali scadute, non outage globale. I pattern da API design valgono per osservabilità: codici errore stabili nelle label metriche.

• Alert profondità e età dead-letter queue
• Check sintetici su sandbox ERP ogni N minuti
• Link runbook nel payload alert
• Overlay calendario manutenzione per ridurre false page

Alerting, on-call e comunicazione cliente

Pagina umani solo per rischio visibile all'utente o integrità dati. Lag coda dentro SLA va in ticket, non pager. Definisci severità e tempi risposta attesi nei contratti supporto. Runbook per alert top: rotazione credenziali ERP 401, esaurimento connessioni DB, scadenza metadata SSO, job migrazione bloccato. Template comunicazione cliente: scope impatto (quali tenant), workaround, canale aggiornamento ETA, summary post-incident per account enterprise. Hypercare post go-live da migrazione dati richiede soglie più strette temporaneamente.

Debug con isolamento tenant intatto

I tool supporto non devono disabilitare tenancy per comodità. Usa impersonation auditata o viste diagnostiche tenant-scoped. Ricerca cross-tenant è incidente compliance. Fornisci explain plan read-only o viewer trace per un tenant. Export bundle diagnostico che IT cliente può condividere senza accesso DB raw. Nei setup multi-tenant, il rilevamento noisy neighbor protegge clienti grandi: CPU, IO e rate integrazione per tenant.

Scelta tool e controllo costi

Osservabilità gestita (Datadog, Honeycomb, Grafana Cloud, collector OpenTelemetry) scambia costo per velocità. Il volume log è la sorpresa budget usuale; campiona log debug, aggrega metriche, ritieni trace selettivamente. OpenTelemetry dà portabilità se i clienti chiedono export telemetria. Parti da un vendor, strumenta con API OTel dove possibile. Budgetta osservabilità nei costi operativi ongoing, non solo come task di lancio.

Checklist osservabilità prima del lancio

Verifica che gli alert scattino in drill staging. Conferma dashboard per golden journey. Testa correlation ID da banner errore UI a query log. Documenta chi riceve page e backup coverage. Aggiungi al gate production readiness insieme a restore backup e test rollback.

Prossimi passi

Nomina i tre journey business principali e se oggi misuri latenza end-to-end. Aggiungi propagazione correlation ID questo sprint se manca. Vedi altre risorse, esperienza, prenota una call o contattami con sketch architettura, numero integrazioni e tooling attuale per review osservabilità pre-lancio.

Domande frequenti