SLA - Livelli di servizio - istes web site

 

Data ultima modifica:  25/01/2018
Cerca
Vai ai contenuti

Menu principale:

SLA - Livelli di servizio

Link utili

Gli SLA, o Service Level Agreement, sono documenti che dovrebbero rientrare nel'ambito di qualsiasi contratto con un nuovo fornitore o per un nuovo servizio IT. Rappresentano il punto di contatto tra le esigenze dell'azienda cliente - quindi in livello di servizio che essa si aspetta di ottenere - e quello che il fornitore si impegna a garantire.
Deve anche indicare precisamente le metriche in base al quale il servizio stesso verrà valutato: sono quelle a indicare se l'impegno preso con lo SLA è stato o meno rispettato. E se qualcosa va storto, lo SLA deve anche indicare le compensazioni previste per i disservizi subiti.
Uno SLA è quindi un elemento molto importante nella relazione cliente-fornitore (ma ci sono SLA anche tra dipartimenti interni della medesima azienda). Di solito si vede sopratutto il lato che rassicura l'utente, ma agire su una base certa di cosa è disservizio e cosa no, è un elemento positivo anche dal punto di vista del fornitore. Un Service Level Agreement dovrebbe infatti scoraggiare comportamenti impropri da entrambe le parti, ad esempio considerando che un disservizio potrebbe essere causato da modifiche apportate dal cliente alla sua rete e non comunicate al fornitore.
Ancora molte aziende - specie quelle di dimensioni contenute ed esigenze apparentemente più semplici - sottovalutano gli SLA, dedicando loro un'attenzione relativa. Meglio invece concentrarsi sugli aspetti che elenchiamo qui di seguito.

Da chi arriva lo SLA

Spesso è il provider, più che il cliente, a mettere sul tavolo la definizione di un Service Level Agreement. Di solito i provider hanno vari tipi di SLA generici predefiniti che propongono ai clienti e che vanno però considerati solo un punto di partenza. L'azienda cliente deve esaminarli attentamente per capire come adattarli alle proprie esigenze e deve sottoporli anche al proprio dipartimento o consulente legale. In questo modo si può arrivare a un documento che sia in linea con i requisiti dell'azienda e non solo una proposta generica, per quanto corretta formalmente.

Particolare attenzione deve essere posta a scenari sempre più frequenti che una volta non erano considerati. Oggi ad esempio accade spesso che ciò che l'azienda utente considera come "un" servizio, non sia gestito in maniera monolitica da un solo provider ma derivi dalla combinazione dei servizi di più realtà. Raramente si possono vincolare contrattualmente fra loro provider generici usando un super-SLA che li comprenda tutti, si può però definire un cosidetto OLA (Operating Level Agreement) che delinei e monitori le interrelazioni fra loro.
Non è sempre semplice nemmeno la gestione di uno SLA personalizzato quando si ha a che fare con un cloud provider. Questo tipo di operatori è decisamente orientato all'adozione di Service Level Agreement standard per (quasi) tutti i clienti, banalmente perchè opera su grandi numeri e la differenziazione comporta sempre un costo. Ma se si ha una buona forza contrattuale, si può provare. Altrimenti, gli SLA non modificabili vanno esaminati con particolare attenzione prima di sottoscriverli.

Cosa ci deve essere in uno SLA

Un Service Level Agreement deve per forza di cose essere molto chiaro, altrimenti non serve quasi a niente. Una parte deve descrivere con precisione che cosa si intende come servizio fornito e coperto dallo specifico SLA, ed eventualmente anche cosa non è compreso (per evitare fraintendimenti). Va poi indicato il punto chiave: l'impegno preso dal provider per il livello di qualità e/o disponibilità preso per il servizio, specificato eventualmente per periodi e fasce orarie. E ovviamente il tipo di indennizzi o compensazioni previste per le violazioni dello SLA.
Il documento deve comprendere anche una estesa parte dedicata alla gestione operativa degli obblighi sottoscritti da azienda cliente e fornitore. Serve cioè definire precisamente - tra l'altro - cosa e come misurare per verificare il rispetto dello SLA, le procedure di escalation in caso di necessità, come si esegue il reporting "ufficiale" delle metriche e con che periodicità. Bisogna tenere sempre presente che quello che non è definito con chiarezza potrebbe essere, un giorno, motivo di discussione.

Come scegliere le metriche

La definizione corretta delle metriche da misurare per valutare l'osservanza dello SLA è un fattore critico, prevedibilmente, e lo è da vari punti di vista. Il primo e più ovvio è che le metriche devono rispecchiare fedelmente la qualità del servizio erogato e devono essere affidabili. Non ci deve cioè essere ambiguità sulla valutazione che in ogni momento si dà del servizio regolato dallo SLA.
Un secondo punto di vista meno ovvio è che le metriche scelte devono essere collegate direttamente ai processi del provider e all'attività delle sue persone, altrimenti lo SLA perde di significato. Non serve cioè puntare a metriche magari formalmente corrette ma legate a processi o eventi che non sono sotto il completo controllo del fornitore.

Un terreno particolarmente sdrucciolevole è rappresentato dalle metriche legate anche alle persone o ai processi dell'azienda cliente: qui uno SLA deve essere equo e definire gli obblighi da entrambe le parti. Ad esempio non si può imporre a un provider la colpa di aver reagito con poca sollecitudine a un problema se questo è stato comunicato in ritardo dal personale dell'azienda.
Le metriche più indicate sono quelle che si possono monitorare con continuità e semplicità e in tempi ottimali (meglio se in automatico), anche se magari non sono quelle tecnicamente migliori. Inutile poi cercare di raccogliere troppi parametri, meglio concentrarsi su quelli più critici perché nella operatività quotidiana raramente si avrà il tempo di analizzare informazioni più complesse.

Quando qualcosa va storto

Può capitare che a un certo punto il servizio oggetto di SLA non funzioni più come è previsto che accada. Se, fatte le debite verifiche, si conclude che il provider non ha rispettato lo SLA questi è sottoposto alle penali che sono delineate nel Service Level Agreement stesso. Va peraltro sottolineato che nella grande maggioranza dei casi l'atteggiamento dell'azienda cliente non è "punitivo". I possibili motivi per cui un provider non riesce a soddisfare uno SLA che ha sottoscritto sono molti e non ascrivibili per forza a una mancanza da sanzionare.
Da questo punto di vista aver "mancato" lo SLA deve essere lo spunto per riesaminare le prestazioni del servizio e capire come lavorare insieme per migliorarlo. Specialmente se la relazione tra provider e azienda cliente è costruttiva e a lungo termine, uno SLA non deve essere visto come un contratto capestro. Questo ovviamente non vuol dire che sia tutto comunque tranquillo in caso di violazione dello SLA. Per alcune imprese, ad esempio gli ecommerce, avere un calo di operatività si traduce direttamente in mancato business e questo deve essere in qualche modo recuperato.
Attenzione poi alle cosiddette indemnification clause, o clausole di risarcimento, che nello SLA devono essere previste. Quando la violazione dello SLA comporta un danno ai clienti dell'azienda utente, questa è costretta a risarcirli e deve potersi rivalere sul fornitore del servizio. La definizione di una clausola del genere non va lasciata a formulazioni standard (troppo vaghe) ma deve essere oggetto di analisi e trattativa.

Il tempo passa

Un Service Level Agreement non cambia spesso, però deve essere mantenuto in linea con l'evoluzione del servizio che copre, dell'azienda utente e anche del provider. Un livello di servizio considerato elevato al momento della stipula del SLA potrebbe diventare la norma, le tecnologie evolvono e così anche le loro possibilità, il business cambia e anche le sue necessità in termini di livelli di servizio. Uno SLA deve quindi essere rivisto periodicamente e prevedere le modalità con cui essere modificato, anche durante il lasso di tempo coperto dal contratto di servizio a cui è collegato.
Infine, attenzione alle acquisizioni. Se il nostro provider viene acquisito da un altro operatore non è affatto scontato che lo SLA sottoscritto in origine sia ancora valido. Può essere necessario rinegoziarlo e comunque è assai meglio verificare esplicitamente quali sono gli obblighi in merito per la nuova "proprietà".



Cosa faremo noi per l'anno 2018

Nel 2018 NON opereremo per SLA, poiche' abbiamo dati insufficienti e perche' ci aspettiamo feedback dalla tempesta "GDPR".
In particolare, dal 25 maggio 2018 opereremo come il 2017, dando un'assistenza "in coda", cioe' FIFO (first in first out). L'assistenza si dividera' in due macrocategorie, relative a:
  1. Clienti che utilizzano il nostro servizio di ADS (Amministratore di Sistema), e
  2. Clienti che NON utilizzano il nostro servizio di ADS.

La prima macrocategoria e' la più semplice da descivere, poiche' la Cyber Security e la Privacy viene gestita da noi, in quanto demandati dal titolare dei dati e quindi "responsabilizzati" ad un tanto. Di conseguenza l'assistenza, nonche' la formazione
  • sul programma gestionale di nostra produzione e
  • su tutte le procedure a corollario del gestionale medesimo,
  • su applicativi del pacchetto Office di casa Microsoft come Word, Excel, PowerPoint, OneNote, Outlook, Skype for Business, Yammer, SharePoint, OneDrive, PowerApps, ... per il momento,
  • sulle policy di accesso nonche' sulle credenziali,
  • sulla rete LAN e la sua architettura,
  • sulla ibridazione con il Cloud,
  • sui servizi da abilitare o disabilitare, ad esempio in fase di aggiornamento del sistema operativo,
  • sul backup di dati diversi dal backup dei dati del gestionale,
  • sul restore di dati in locazioni specifiche e in dispositivi specifici,
  • sulla gestione delle immagini dei dischi e dei dischi di ripristino,
  • sugli aggiornamenti,
  • sulle scansioni periodiche,
  • sull'attivazione di nuovi criteri o policy, in seguito a sopravvenuti aggiornamenti del sistema del cliente (hardware, software e utenti).
L'operato della nostra azienda sara' riportato al titolare con cadenza da stabilire tra le parti (file di log e report), come richiesto dal regolamento.

La seconda macrocategoria e' un po' più complessa da gestire in ordine a chi deve fare cosa. Per legge, il personale/utente deve essere formato sull'uso della tecnologia utilizzata per la gestione dell'informazione. Proponiamo dei casi di studio come approfondimento.

Caso 1
Un/una dipendente del cliente, ci chiede telefonicamente di intervenire in assistenza: non possiamo intervenire poiche' ci deve essere una richiesta esplicita da parte del titolare dei dati (dominus della piramide GDPR) che ci autorizza all'intervento in maniera temporanea in teleassistenza. La richiesta deve essere effettuata via email con la specifica anomalia, l'incident, poiche' su essa andremo ad operare. ATTENZIONE: il cliente ha il suo ADS nominato, quindi sara' questa figura che gli "dovrebbe" risolvere l'incident rilevato.

Caso 2
Il titolare ci invia la email con l'incident rilevato e la relativa autorizzazione temporanea all'intervento, ma la email l'ha inviata con uno smartphone fuori dall'azienda. Interveniamo. Il titolare o il suo ADS, dovrebbero monitorare e controllare il nostro intervento, quindi per assunto, la nostra azienda opera in assistenza, sicura che dall'altra parte (dispositivo del cliente), ci sia l'ADS quando non è presente il titolare.

Caso 3
La email e' inviata dall'ADS dell'azienda cliente. Interveniamo poiche' l'ADS e' abilitato ad un tanto dal titolare. Ovviamente, come gia' riportato nel Caso 2, l'ADS deve monitorare e controllare l'operato fatto dalla nostra azienda in assistenza.

Dal 2018 la nostra azienda rilascera' due aggiornamenti l'anno (aggiornamenti semestrali - di seguito agli aggiornamenti semestrali del sistema operativo client di casa Microsoft: Windows 10). Questi aggiornamenti possono comprendere il programma, il database o entrambi.
Qualora ci fossero dei malfunzionamenti e/o anomalie del programma o export di dati non coerenti o informazioni non persistenti del DB, il tutto chiamato anche criticita', la nostra azienda indichera' il rimedio temporaneo per sopperire alla criticita' e, in seguito al rilascio della versione aggiornata, esporra' la soluzione.

ATTENDIAMO VOSTRI FEEDBACK

stampa la pagina

Statistiche accessi

Villa Manin - Passariano di Codroipo
Carpa albina "la da la Vanda"
Villa antica Codroipo
 
ISTES Copyright 2017. All rights reserved.
Torna ai contenuti | Torna al menu