Gli accordi sui livelli di servizio (SLA) specificano il servizio concordato che gli MSP e i dipartimenti IT interni devono fornire ai clienti. Il monitoraggio SLA misura il grado di raggiungimento degli obiettivi da parte dei tecnici, ma eseguirlo manualmente può essere noioso e ripetitivo. Questa guida illustra come configurare le dashboard RMM per una panoramica in tempo reale e per il monitoraggio della conformità agli SLA, automatizzando il processo complessivo.
Automatizza il monitoraggio degli SLA con gli strumenti di scripting multipiattaforma di NinjaOne.
Combinare dashboard RMM e strumenti di monitoraggio SLA
Gli RMM forniscono una panoramica delle metriche di conformità, consentendo di rilevare automaticamente i problemi e di porre rimedio rapidamente alle violazioni. Oltre al monitoraggio, queste dashboard tengono traccia degli indicatori chiave di prestazione, generando automaticamente report di conformità e di audit.
📌 Prerequisiti:
- Piattaforma RMM con dashboard e funzionalità di avviso.
- Criteri e parametri SLA esistenti e ben definiti.
- Accesso ai dati telemetrici dei dispositivi.
- Diritti di amministratore.
📌 Strategie di implementazione consigliate:
Scegliere una sezione | 💻 Più adatto per utenti individuali | 💻💻💻 Più adatto per ambienti enterprise |
| Monitoraggio degli SLA direttamente dalle dashboard RMM | ✓ | |
| Metodo 1: Utilizzo di PowerShell per monitorare le metriche SLA critiche | ✓ | ✓ |
| Metodo 2: Utilizzo di CMD per il monitoraggio e il logging delle prestazioni SLA di base | ✓ | ✓ |
| Metodo 3: Controllo dei valori del registro per il monitoraggio della configurazione SLA | ✓ | ✓ |
| Metodo 4: Sfruttare i Criteri di gruppo per applicare le impostazioni conformi agli SLA | ✓ |
Monitoraggio degli SLA direttamente dalle dashboard RMM
📌 Caso d’uso: La maggior parte degli RMM dispone di dashboard configurabili che forniscono un monitoraggio in tempo reale attraverso widget che possono essere personalizzati per la conformità agli SLA.
Tempo di attività del dispositivo e frequenza di check-in dell’utente finale
Gli RMM possono tenere traccia del tempo di attività e di non attività dei dispositivi, e queste metriche possono indicare problemi di sistema che richiedono un’indagine e un intervento correttivo. Il monitoraggio della frequenza di check-in degli agenti fornisce ulteriori informazioni sulle prestazioni degli endpoint, in quanto check-in irregolari possono segnalare problemi.
Stato di conformità delle patch degli endpoint
Gli RMM possono individuare le patch o gli aggiornamenti critici mancanti, facendo in modo che gli endpoint mantengano una solida igiene di sicurezza e rispettino la conformità alle patch.
Tempo di risposta e risoluzione dei ticket
Le piattaforme RMM automatizzano il monitoraggio dei ticket, fornendo dati misurabili sui tempi di risoluzione dei ticket, ideale per mantenere la conformità agli SLA.
Avvisi di soglia hardware
Gli MSP e i tecnici IT possono impostare avvisi quando le risorse di sistema superano i limiti delle prestazioni. Il rilevamento precoce dell’utilizzo al limite delle risorse può prevenire arresti o rallentamenti che possono causare tempi di inattività e frustrazione dei clienti.
Stato dei servizi critici
Le piattaforme RMM monitorano i servizi critici, come antivirus e sistemi di backup, assicurandone il funzionamento. Se questo aspetto non viene monitorato, può avere un grave impatto sui piani di riduzione dei rischi legati alle minacce e di disaster recovery, fino a compromettere la conformità agli SLA durante gli incidenti di sicurezza.
Best practice di personalizzazione delle dashboard RMM:
- Filtra le dashboard per cliente, livello SLA o regione.
- Ordina i segmenti delle dashboard per evidenziare le informazioni importanti sui clienti, garantendo la qualità del servizio, la gestione delle priorità e il monitoraggio basato sulla posizione.
- Imposta indicatori visivi per gli avvisi basati su soglie.
- La codifica a colori degli indicatori di urgenza, come rosso, giallo o verde, fornisce una rapida comprensione dello stato dell’endpoint.
- Configura i dati della dashboard per il reporting automatico degli SLA.
- Automatizza il monitoraggio utilizzando dashboard per semplificare la documentazione sulla conformità agli SLA e ridurre il lavoro manuale.
💡 Nota: Gli RMM offrono ampie capacità di monitoraggio, ma l’accesso a una vasta gamma di integrazioni può fornire un controllo più approfondito della conformità agli SLA.
Metodo 1: Utilizzo di PowerShell per monitorare le metriche SLA critiche
Gli script PowerShell lavorano fianco a fianco con le dashboard RMM, raccogliendo metriche di conformità di cui queste ultime non possono tenere traccia in modo nativo.
📌 Caso d’uso: Gli RMM possono eseguire regolarmente script in modo automatico per registrare, avvisare e intervenire in caso di violazioni della conformità senza necessità di interazione manuale.
📌 Prerequisito: Piattaforme RMM con supporto per scripting e distribuzione PowerShell.
⚠️ Importante: La sintassi e l’accuratezza dei cmdlet sono fondamentali per evitare errori quando si utilizzano gli script PowerShell. (Fai riferimento alla sezione ⚠️ Cose da tenere d’occhio. )
Esempi di script PowerShell per il monitoraggio delle metriche SLA:
Windows non registrerà gli eventi relativi a un’origine inesistente. Prima di procedere, crea origini di eventi come Monitoraggio SLA o Tracker SLA per evitare di incorrere in errori.
- Verifica il tempo di attività dei servizi critici interrogando Windows Defender Firewall (MpsSvc).
| $svc = Get-Service -Name “MpsSvc” if ($svc.Status -ne “Running”) { Write-EventLog -LogName Application -Source “SLA Monitor” -EventID 1001 -EntryType Warning -Message “Windows Defender Service is not running.” } |
- Script PowerShell per registrare il ritardo di risposta dei ticket nei log eventi.
| $created = Get-Date “2024-07-16 08:00” if (((Get-Date) – $created).TotalMinutes -gt 15) { Write-EventLog -LogName Application -Source “SLA Tracker” -EventID 2002 -EntryType Warning -Message “Ticket response time exceeded SLA.” }Get-WinEvent -LogName Application | Where-Object { $_.ProviderName -eq ‘SLA Tracker’ } |
Metodo 2: Utilizzo di CMD per il monitoraggio e il logging delle prestazioni SLA di base
Gli script basati su CMD, come i file BAT, possono monitorare gli indicatori SLA di base, come il tempo di attività, lo stato del servizio e la connettività di rete.
📌 Caso d’uso: Utilizza gli RMM per pianificare script BAT che monitorino e registrino gli indicatori SLA per un monitoraggio passivo e automatizzato.
📌 Prerequisiti: RMM con supporto di script batch *(.BAT).
⚠️ Importante: CMD è limitato solo ai comandi di base e non supporta la logica complessa offerta dalle moderne CLI (per esempio PowerShell). (Fai riferimento alla sezione ⚠️ Cose da tenere d’occhio. )
Esempi di script CMD per il monitoraggio degli indicatori SLA:
- Per riavviare il servizio Windows Update (wuauserv), in modo da verificare il ripristino dei tempi di attività o identificare i guasti ricorrenti.
net start wuauserv
echo %DATE% %TIME% – wuauserv restarted >> C:\SLA\service_log.txt
- Per registrare lo stato del ping in modo da verificare la connettività dell’endpoint.
ping 8.8.8.8 -n 1 >nul && echo %DATE% %TIME% – Online >>
C:\SLA\network_log.txt || echo %DATE% %TIME% – Offline >> C:\SLA\network_log.txt
💡 Nota: Crea un percorso di registro designato prima di eseguire gli script CMD per registrare le metriche di conformità SLA (per esempio, C:\SLA). Se non esiste, puoi crearlo con un comando di base, come mkdir C:\SLA. .
Metodo 3: Controllo dei valori del registro per il monitoraggio della configurazione SLA
Il Registro contiene chiavi e valori che gli amministratori possono controllare per garantire la conformità agli SLA in un ambiente.
📌 Casi d’uso: Pianifica gli script PowerShell per le verifiche periodiche del registro, l’attivazione di avvisi o il logging di eventi relativi alle metriche SLA utilizzando l’automazione RMM.
Esempi di script PowerShell
- Per verificare se Windows Update è disattivato su un endpoint:
| $key = “HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU” $value = Get-ItemProperty -Path $key -Name NoAutoUpdate -ErrorAction SilentlyContinueif ($value.NoAutoUpdate -eq 1) { Write-EventLog -LogName Application -Source “SLA Monitor” -EventID 3001 -EntryType Warning -Message “Automatic Updates are disabled, violating SLA.” } |
💡 Nota: La chiave di registro di cui sopra non è sempre presente per impostazione predefinita. Assicurati che il percorso specificato esista prima dell’esecuzione.
- Per verificare se l’agente di backup è installato localmente:
| $key = “HKLM:\SOFTWARE\BackupAgent\Install” $value = Get-ItemProperty -Path $key -Name Status -ErrorAction SilentlyContinueif ($value.Status -ne “Installed”) { Write-EventLog -LogName Application -Source “SLA Monitor” -EventID 3002 -EntryType Warning -Message “Backup Agent is missing or not properly installed.” } |
💡Nota: La chiave di registro BackupAgent è specifica per gli ambienti. Se il software non è installato al momento dell’esecuzione, lo script restituirà risultati imprecisi.
⚠️ Avvertenza: Sebbene l’interrogazione dei valori del Registro di sistema sia generalmente sicura, gli input errati degli script possono alterare accidentalmente le configurazioni, violando potenzialmente la conformità agli SLA. (Fai riferimento alla sezione ⚠️ Cose da tenere d’occhio. )
Metodo 4: Sfruttare i Criteri di gruppo per applicare le impostazioni conformi agli SLA
La distribuzione di GPO garantisce configurazioni conformi agli SLA su tutti gli endpoint connessi al dominio. Inoltre, l’applicazione dei Criteri di gruppo ripristina le modifiche accidentali o la manomissione delle configurazioni di base per la conformità.
📌 Caso d’uso: Gli MSP e i tecnici IT possono distribuire GPO per configurare le impostazioni di base, garantendo la conformità agli SLA negli ambienti gestiti.
📌 Prerequisiti:
- Accesso alla console di gestione dei criteri di gruppo
- Ambiente unito al dominio
- Unità Organizzative (OU) ordinate per un efficiente targeting degli endpoint client
⚠️ Importante: Testa i GPO localmente in un ambiente controllato prima della distribuzione. (Fai riferimento alla sezione ⚠️ Cose da tenere d’occhio. )
Esempi di aree GPO per l’applicazione della configurazione SLA
- Windows Update: Le impostazioni di questo percorso di criterio impongono pianificazioni di aggiornamento automatico, riducendo al minimo la necessità di scansioni manuali delle patch.
Percorso: Configurazione del computer > Modelli amministrativi > Componenti di Windows > Windows Update
- Conservazione e auditing dei log eventi: Questo garantisce la conservazione dei log critici per gli audit di conformità.
Percorso: Configurazione del computer > Impostazioni di Windows > Impostazioni di sicurezza > Configurazione avanzata dei criteri di audit
- Applicazione dell’avvio dei servizi: Richiede l’esecuzione di servizi critici come antivirus, backup e RMM.
Percorso: Configurazione del computer > Preferenze > Impostazioni del pannello di controllo > Servizi
⚠️ Cose da tenere d’occhio
| Rischi | Potenziali conseguenze | Possibilità di tornare alla configurazione precedente |
| Esecuzione di script imprecisi | Gli script imprecisi possono involontariamente mascherare le violazioni degli SLA attraverso avvisi mancati e audit non riusciti. | Controlla sempre l’accuratezza della sintassi degli script, poiché i caratteri errati e i comandi sbagliati possono causare errori e configurazioni non corrette. |
| Limitazioni dello scripting CMD | I file batch sono ideali per i controlli rapidi e di base delle prestazioni SLA, ma sono insufficienti per le attività di monitoraggio più complesse. | Sfrutta gli script PowerShell, soprattutto se hai bisogno di una logica avanzata per il monitoraggio automatico e la risoluzione dei problemi. |
| Scambio accidentale di cmdlet quando si utilizza PowerShell | Alcuni cmdlet, come Set-ItemProperty e Get-ItemProperty, possono essere scambiati erroneamente, causando potenzialmente configurazioni non corrette. | Per una maggiore chiarezza, quando scrivi gli script utilizza nomi espliciti e commenti. Inoltre, utilizza il cmdlet -WhatIf per verificare l’effetto degli script prima dell’esecuzione. |
| Distribuzione di GPO non testati | Le configurazioni errate possono facilmente nascondersi all’interno di GPO non testati, e causare una mancata conformità in un ambiente una volta distribuite. | Testa i GPO localmente in ambienti controllati per assicurarti che applichino le configurazioni di base corrette e conformi agli SLA per gli endpoint. |
| Chiavi e valori di registro mancanti | Gli script possono fallire quando si interrogano chiavi e valori del Registro di sistema inesistenti. | Verifica che il servizio da monitorare sia installato correttamente e utilizza gli script per creare le chiavi e i valori mancanti. |
Considerazioni sull’utilizzo degli RMM come strumenti di monitoraggio SLA
Il monitoraggio degli endpoint è fondamentale per rilevare le violazioni degli SLA e soddisfare le aspettative dei clienti. Il miglioramento del monitoraggio degli SLA con SLA filtrati, consapevolezza dei fusi orari e informazioni dettagliate contribuisce a migliorare l’efficienza operativa e l’erogazione dei servizi.
Ordinare gli SLA per livello
In genere, gli SLA sono offerti in diversi livelli, poiché i clienti hanno aspettative e budget diversi. Ordinare i dati nelle dashboard RMM in base ai livelli aiuta i tecnici a dare priorità ai problemi e a rispettare i tempi di risposta concordati per ogni cliente.
Configurazione dei timer di risposta in base ai fusi orari dei clienti
Alcuni MSP e team IT gestiscono clienti in diversi fusi orari, il che influisce sul calcolo dei tempi di risposta e risoluzione. Se questo aspetto non viene gestito, i tecnici potrebbero pensare di rispettare gli SLA, ma i clienti subirebbero comunque ritardi.
Correlazione degli eventi
Un aggiornamento di Windows non riuscito può causare diversi problemi apparentemente non correlati, come arresti anomali del servizio e disconnessioni di rete. I risultati degli script di log sugli endpoint consentono di individuare la causa principale delle violazioni degli SLA, prevenendo a lungo termine future violazioni.
Risoluzione dei problemi relativi al monitoraggio delle prestazioni SLA
Problema 1: Dati mancanti o imprecisi
Verifica che l’agente RMM sia correttamente distribuito sugli endpoint di destinazione, in quanto una distribuzione errata può impedire la ricezione delle metriche in tempo reale. Inoltre, assicurati che le impostazioni di telemetria degli endpoint consentano al tuo RMM di raccogliere e mostrare i dati di monitoraggio.
Problema 2: Attivazione ritardata degli avvisi e SLA
Gli avvisi tardivi fanno sì che i problemi si protraggano oltre i tempi di risposta concordati, con una possibile conseguente violazione delle soglie contrattuali SLA. Per evitare questo problema, imposta gli intervalli di avviso e di polling in modo che corrispondano ai tempi di risposta previsti dai client.
Problema 3: Gli script falliscono dopo l’esecuzione
Verifica la presenza di errori nelle attività pianificate, che potrebbero impedire agli script di rispettare i tempi di esecuzione. Verifica il criterio di esecuzione degli script e che l’account disponga di ampi privilegi amministrativi per la distribuzione degli script.
Sfrutta i servizi NinjaOne per un monitoraggio SLA continuo
NinjaOne offre servizi che possono aiutare a rafforzare il monitoraggio SLA, la conformità e la reportistica:
| Servizio NinjaOne | Definizione | Come aiuta il monitoraggio SLA |
| Dashboard personalizzate | Le dashboard personalizzate consentono agli MSP e ai tecnici di visualizzare le informazioni più importanti per il loro servizio. | La dashboard personalizzabile di NinjaOne fornisce metriche cruciali e accesso agli strumenti all’interno di una singola interfaccia centralizzata. |
| Scripting automatizzato | Lo scripting automatizzato consente agli MSP e ai tecnici di scrivere, eseguire e pianificare script sugli endpoint. | Questo servizio offre un supporto multilingue e consente la distribuzione automatizzata degli script di monitoraggio su dispositivi Windows, macOS e Linux. |
| Condizioni dei criteri | Questa funzione consente agli amministratori di specificare regole e criteri che attivano un’azione specifica quando vengono soddisfatti. | Le condizioni dei criteri automatizzano i flussi di lavoro di risposta quando determinate soglie SLA sono raggiunte o non raggiunte, per tempi di risposta più rapidi. |
| Avvisi e monitoraggio in tempo reale | Questa funzione invia avvisi automatici in tempo reale con flussi di lavoro di risoluzione attivati quando si verificano problemi. | Monitora costantemente gli endpoint, attiva avvisi in tempo reale e automatizza la risoluzione dei problemi prima che causino violazioni degli SLA. |
| Monitoraggio dell’integrità dei dispositivi | Il monitoraggio dello stato di integrità dei dispositivi aiuta a identificare l’hardware malfunzionante e il software poco performante, prevenendo potenziali tempi di inattività. | NinjaOne offre una dashboard che mostra lo stato di integrità dei dispositivi a livello centrale, attivando automaticamente gli script di correzione quando un dispositivo entra in uno stato non integro. |
Migliora la visibilità dei tuoi SLA e pianifica il monitoraggio delle metriche più importanti.
Inizia una prova gratuita o guarda una demo di NinjaOne RMM.
Utilizza le dashboard RMM per ottimizzare le pratiche di monitoraggio degli SLA
Il rispetto dei requisiti SLA è fondamentale per gli MSP e per i dipartimenti IT interni, poiché le violazioni dei contratti sono sinonimo di tempi di inattività o di penali legate agli SLA. Un sistema di monitoraggio efficiente delle metriche SLA rafforza la fiducia dei clienti e supporta la fornitura di servizi coerenti nel tempo.
Grazie alle piattaforme RMM, il monitoraggio della conformità agli SLA e la risoluzione dei problemi associati possono essere automatizzati, massimizzando l’efficienza e riducendo al minimo l’intervento manuale. Combina script, applicazione efficace dei criteri e servizi RMM per un monitoraggio proattivo della conformità agli SLA.
Argomenti correlati:
