--- schema_version: "1" id: 6110e9fffa3d4fae03689997d83f9903477bee963ca99be8f5c213d8d267bb64 title: Gestione incidenti - Schemi collection: architect version: current locale: it-it portal_url: https://docs.salesforce.com/architect/current/it-it/well-architected/guides/operational-excellence-incident-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/it-it/well-architected/guide/operational-excellence-incident-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 33aa424cb8fd340eb3a0228e1de15b0a948546b824b9abfcec3bc1367eeccc4f products: - Framework ben progettato - Architect Site Content Repo --- # Gestione incidenti - Schemi Ulteriori informazioni sull'[eccellenza operativa](/docs/architect/it-it/well-architected/guide/operational-excellence.html) ben progettata → [Gestione incidenti](/docs/architect/it-it/well-architected/guide/operational-excellence.html#incident-management) ## Rilevamento e avviso degli incidenti **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Monitoraggio | ✅ L'architettura di avviso include la classificazione della gravità che instrada immediatamente gli incidenti critici (produzione non disponibile, danneggiamento dei dati, compromissione della sicurezza) alla pagina su chiamata | | Piattaforma \| Monitoraggio | ✅ Gli incidenti di elevata gravità (prestazioni deteriorate, guasto parziale) generano notifiche immediate per un'indagine rapida sull'orario di ufficio | | Piattaforma \| Monitoraggio | ✅ Avvisi (approssimazione delle soglie, fluttuazione della configurazione) aggregati in rapporto giornaliero per la riparazione proattiva | | Piattaforma \| Monitoraggio | ✅ L'arricchimento degli avvisi include il contesto diagnostico: conteggio utenti interessati, percentili percentuale di errore, distribuzioni recenti, avvisi correlati e link diretti ai cruscotti digitali | | Piattaforma \| Monitoraggio | ✅ Il contesto di avviso riduce il tempo medio per confermare fornendo una valutazione immediata della situazione senza raccogliere informazioni di base tramite query separate | | Piattaforma \| Monitoraggio | ✅ Il raggruppamento degli avvisi evita le tempeste di avvisi consolidando centinaia di avvisi correlati da un singolo problema sottostante in un'unica notifica con statistiche aggregate | | Piattaforma \| Monitoraggio | ✅ Gli avvisi raggruppati mostrano il conteggio, la percentuale e le transazioni interessate che rivelano lo schema del problema senza risposte schiaccianti | | Piattaforma \| Monitoraggio | ✅ La soppressione degli avvisi impedisce che condizioni transitorie note generino avvisi durante le finestre di manutenzione previste o i periodi di riparazione automatica | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Monitoraggio | ⚠️ L'errore di integrazione genera 100s singoli avvisi in 5 minuti travolgente telefono su chiamata, ogni avviso identico tranne indicazione oraria | | Piattaforma \| Monitoraggio | ⚠️ Gli avvisi mancano di contesto sull'ambito, le modifiche recenti o gli schemi di problemi; il tecnico su chiamata deve raccogliere manualmente le informazioni di base | | Piattaforma \| Monitoraggio | ⚠️ Tutti gli avvisi vengono instradati attraverso lo stesso canale indipendentemente dalla gravità; interruzioni critiche della produzione competono con avvisi minori | | Piattaforma \| Monitoraggio | ⚠️ Gli avvisi vengono attivati durante le finestre di manutenzione pianificata generando falsi positivi che erodono Trust nel sistema di monitoraggio | | Piattaforma \| Monitoraggio | ⚠️ Il raggruppamento degli avvisi non esiste; ogni errore della transazione attiva un avviso separato creando tempeste di avvisi durante gli incidenti | | Piattaforma \| Monitoraggio | ⚠️ Gli avvisi non forniscono link ai cruscotti digitali pertinenti; i soccorritori trascorrono il tempo a trovare strumenti di monitoraggio durante la risposta agli incidenti | ## Rotazione e Runbook su chiamata **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Operazioni | ✅ La rotazione su chiamata è settimanale o bisettimanale che bilancia la distribuzione degli oneri con la conservazione del contesto | | Piattaforma \| Operazioni | ✅ I runbook sono documentati per ogni tipo di avviso, consentendo ai tecnici su chiamata di rispondere in modo efficace senza una profonda esperienza nel dominio | | Piattaforma \| Operazioni | ✅ I Runbook includono la descrizione del problema, le fasi diagnostiche, le procedure di risoluzione, i criteri di inoltro al livello superiore e i link alla documentazione correlata | | Piattaforma \| Operazioni | ✅ Runbooks sono documenti viventi in controllo di versione che evolvono attraverso elementi di azione post-mortem | | Piattaforma \| Operazioni | ✅ Le procedure di trasferimento includono brevi riunioni durante le transizioni di rotazione che trasferiscono il contesto, inclusi problemi attivi, modifiche recenti, rischi noti e manutenzione imminente | | Piattaforma \| Operazioni | ✅ Note di consegna scritte integrano la consegna verbale impedendo la perdita di informazioni durante le transizioni di rotazione | | Piattaforma \| Operazioni | ✅ Frequenza delle pagine, conteggio degli incidenti dopo l'orario di ufficio e tasso di falsi positivi vengono misurati per identificare il carico su chiamata non sostenibile che richiede una riparazione architettonica | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Operazioni | ⚠️ I Runbook non esistono; gli ingegneri su chiamata si affidano a Knowledge tribale e a frequenti inoltri al livello superiore per esperti in materia | | Piattaforma \| Operazioni | ⚠️ I Runbook sono archiviati in documenti personali anziché in un controllo di versione condiviso a cui i membri del team possono accedere e aggiornarli | | Piattaforma \| Operazioni | ⚠️ Le transizioni di rotazione su chiamata avvengono senza riunioni di trasferimento; il tecnico in entrata non ha contesto sui problemi attivi e le modifiche recenti | | Piattaforma \| Operazioni | ⚠️ L’elevato onere su chiamata continua all’infinito attraverso l’eroismo operativo anziché favorire miglioramenti architettonici | | Piattaforma \| Operazioni | ⚠️ Le metriche su chiamata (frequenza delle pagine, incidenti fuori orario, falsi positivi) non vengono tracciate; gli schemi di addebito rimangono invisibili | | Piattaforma \| Operazioni | ⚠️ I Runbook vengono creati una volta durante la distribuzione iniziale e non vengono mai aggiornati man mano che il sistema si evolve o emergono nuove modalità di errore | ## Percorso di inoltro al livello superiore **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Operazioni | ✅ I percorsi tecnici di inoltro al livello superiore definiscono gli esperti in materia che gestiscono specifici domini problematici | | Piattaforma \| Operazioni | ✅ I percorsi di inoltro al livello superiore della gestione definiscono i responsabili che ricevono notifiche per gli incidenti che superano le soglie di gravità o durata | | Piattaforma \| Operazioni | ✅ I percorsi di inoltro al livello superiore del fornitore documentano le procedure di creazione dei casi di assistenza Salesforce e i criteri di gravità | | Piattaforma \| Operazioni | ✅ I percorsi di inoltro al livello superiore dei dirigenti definiscono quali dirigenti ricevono notifiche per incidenti business-critical | | Piattaforma \| Operazioni | ✅ I criteri di inoltro al livello superiore sono espliciti e obiettivi: livelli di gravità, soglie temporali, conteggi utenti interessati, valutazioni dell'impatto aziendale | | Piattaforma \| Operazioni | ✅ I percorsi di inoltro al livello superiore sono documentati nei runbook e accessibili durante gli incidenti senza cercare informazioni di contatto | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Operazioni | ⚠️ I percorsi di inoltro al livello superiore non sono documentati; i tecnici su chiamata perdono tempo a cercare i contatti appropriati durante gli incidenti | | Piattaforma \| Operazioni | ⚠️ I criteri di inoltro al livello superiore sono vaghi ("inoltrare al livello superiore se sembra negativo"); i rispondenti non dispongono di indicazioni chiare su quando inoltrare al livello superiore | | Piattaforma \| Operazioni | ⚠️ La notifica della gestione avviene troppo tardi perché le soglie di gravità non sono definite; i dirigenti vengono a conoscenza degli incidenti dagli utenti | | Piattaforma \| Operazioni | ⚠️ Le procedure di inoltro al livello superiore dell'assistenza Salesforce non sono documentate; i team ritardano l'apertura dei casi di assistenza perdendo tempo di risposta prezioso | | Piattaforma \| Operazioni | ⚠️ I referenti esperti in materia sono superati; gli inoltri al livello superiore raggiungono persone sbagliate o non riescono durante le modifiche della rotazione | ## Processo di riesame post-incidente **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Operazioni | ✅ I riesami post-incidente senza colpa vengono condotti entro 5 giorni lavorativi dopo eventi operativi significativi | | Piattaforma \| Operazioni | ✅ La cultura senza colpa si concentra sui miglioramenti del sistema anziché sulla colpa individuale, creando sicurezza psicologica per una valutazione onesta | | Piattaforma \| Operazioni | ✅ Sequenza temporale include sequenza dettagliata dalle condizioni iniziali fino al primo segnale, rilevamento, conferma, indagine, risposta, recupero e convalida | | Piattaforma \| Operazioni | ✅ Timeline timestamp ogni evento che consente l'analisi della durata delle fasi di rilevamento, risposta e ripristino | | Piattaforma \| Operazioni | ✅ La causa principale identifica il guasto tecnico o la condizione che ha causato direttamente l'incidente, distinto dai fattori che contribuiscono | | Piattaforma \| Operazioni | ✅ L'analisi dei fattori che contribuiscono rivela le condizioni organizzative, di processo o architettoniche che hanno abilitato o amplificato l'impatto dell'incidente | | Piattaforma \| Operazioni | ✅ L'analisi del rilevamento valuta come è stato rilevato l'incidente e se il rilevamento avrebbe potuto essere più rapido | | Piattaforma \| Operazioni | ✅ Valutazione della risposta identifica ciò che è andato bene durante la risposta e ciò che è stato più lento o più difficile del necessario | | Piattaforma \| Operazioni | ✅ Le voci azione sono specifiche, assegnate e limitate nel tempo per impedire la ricorrenza o migliorare la risposta futura | | Piattaforma \| Operazioni | ✅ Le voci azione evitano vaghi miglioramenti ("migliora monitoraggio") a favore di operazioni concrete ("aggiungi avviso per la percentuale di errore API superiore al 5% in 10 minuti") | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Operazioni | ⚠️ La discussione post-incidente conclude che "il processo batch aveva un bug, l'abbiamo risolto" senza documentazione o miglioramenti sistematici | | Piattaforma \| Operazioni | ⚠️ Le revisioni post-incidente si concentrano sulla colpa individuale anziché sui miglioramenti del sistema, distruggendo la sicurezza psicologica | | Piattaforma \| Operazioni | ⚠️ Sequenza temporale priva di indicazioni orarie che impediscono l'analisi della durata; il team non è in grado di identificare se il rilevamento o la risposta è stata lenta | | Piattaforma \| Operazioni | ⚠️ L'analisi delle cause principali non distingue la causa tecnica immediata dai fattori organizzativi o di processo che contribuiscono | | Piattaforma \| Operazioni | ⚠️ L'analisi del rilevamento viene ignorata; le lacune di monitoraggio che hanno consentito agli utenti di segnalare l'incidente per prime non vengono identificate | | Piattaforma \| Operazioni | ⚠️ Le voci azione sono vaghe senza titolari o date di scadenza; i miglioramenti vengono discussi ma mai implementati | | Piattaforma \| Operazioni | ⚠️ Le revisioni post-incidente non vengono condotte entro 5 giorni lavorativi; il contesto viene perso e l'urgenza di miglioramenti svanisce | ## Documentazione e apprendimento post-incidente **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Knowledge Management | ✅ Le revisioni post-incidente sono documentate e condivise ampiamente oltre i soccorritori diretti per l'apprendimento organizzativo | | Piattaforma \| Knowledge Management | ✅ Le recensioni post-incidente sono archiviate in wiki o Knowledge Base condivise con tag che abilitano l'analisi degli schemi in più incidenti | | Piattaforma \| Knowledge Management | ✅ Il completamento dell'elemento azione viene monitorato nelle revisioni successive evitando che le retrospettive diventino discussioni ripetitive senza follow-through | | Piattaforma \| Knowledge Management | ✅ Le percentuali di completamento delle voci azione vengono misurate come indicatori di integrità operativa che rivelano se i miglioramenti sono implementati o solo discussi | | Piattaforma \| Operazioni | ✅ Gli schemi degli incidenti vengono analizzati in più incidenti rivelando problemi sistemici che richiedono investimenti architettonici | | Piattaforma \| Operazioni | ✅ I Runbook vengono aggiornati in base agli apprendimenti post-incidente assicurando che le procedure riflettano l'effettiva esperienza di risposta agli incidenti | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Knowledge Management | ⚠️ Le revisioni post-incidente non sono documentate; gli apprendimenti rimangono con i soccorritori anziché diffondersi in tutta l'organizzazione | | Piattaforma \| Knowledge Management | ⚠️ Le revisioni post-incidente sono archiviate in documenti personali anziché nella Knowledge Base condivisa dove i membri del team possono imparare dalla cronologia | | Piattaforma \| Knowledge Management | ⚠️ Le voci azione sono definite ma mai tracciate; la percentuale di completamento è sconosciuta e i miglioramenti non sono implementati | | Piattaforma \| Knowledge Management | ⚠️ Le basse percentuali di completamento delle voci azione persistono senza riconoscere che le retrospettive sono inefficaci senza follow-through | | Piattaforma \| Operazioni | ⚠️ Gli schemi degli incidenti non vengono analizzati in più incidenti; i problemi sistemici rimangono nascosti perché ogni incidente viene trattato isolatamente | | Piattaforma \| Operazioni | ⚠️ I Runbook non vengono aggiornati dopo gli incidenti; le procedure diventano obsolete man mano che il sistema si evolve ed emergono nuove modalità di errore | ## Metriche e monitoraggio degli incidenti **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Operazioni | ✅ Il tempo medio di rilevamento (MTTD) viene monitorato misurando la durata dal verificarsi dell'incidente al rilevamento | | Piattaforma \| Operazioni | ✅ Il tempo medio per confermare (MTTA) è la durata di misurazione tracciata dal rilevamento al riconoscimento del tecnico su chiamata | | Piattaforma \| Operazioni | ✅ Il tempo medio di ripristino (MTTR) viene monitorato misurando la durata dal rilevamento al ripristino del servizio | | Piattaforma \| Operazioni | ✅ La frequenza degli incidenti viene monitorata con una revisione mensile del trend che rivela se la stabilità sta migliorando o peggiorando | | Piattaforma \| Operazioni | ✅ La percentuale di errori di modifica viene tracciata misurando la percentuale di distribuzioni che causano incidenti di produzione che richiedono una riparazione | | Piattaforma \| Operazioni | ✅ La percentuale di errori di modifica è mantenuta costantemente bassa, una piccola frazione di tutte le distribuzioni | | Piattaforma \| Operazioni | ✅ Le metriche degli incidenti vengono condivise con i team di sviluppo durante la pianificazione degli sprint per informare sulle priorità degli arretrati e sui miglioramenti dell'architettura | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Operazioni | ⚠️ Le metriche degli incidenti non vengono tracciate; il team non ha visibilità sul miglioramento o sul degrado dei tempi di risposta | | Piattaforma \| Operazioni | ⚠️ MTTD, MTTA e MTTR non vengono misurati; i team non sono in grado di identificare se il rilevamento o la risposta è il collo di bottiglia | | Piattaforma \| Operazioni | ⚠️ La percentuale di errori di modifica non viene tracciata; il team non sa se i cancelli di qualità sono efficaci | | Piattaforma \| Operazioni | ⚠️ Le tendenze della frequenza degli incidenti non vengono riviste ogni mese; il deterioramento della stabilità non viene rilevato fino a quando non si verifica un incidente grave | | Piattaforma \| Operazioni | ⚠️ Le metriche degli incidenti rimangono nel team operativo senza condivisione con i team di sviluppo; i problemi architettonici non vengono risolti | | Piattaforma \| Operazioni | ⚠️ Le metriche vengono tracciate ma mai utilizzate per informare le decisioni; la misurazione senza azione spreca fatica e non fornisce alcun valore |