Post on 05-Jul-2015
description
transcript
Un modello SLA orientato al Service Management
Milano/Trento, 9 settembre 2014 Nicola Zanella
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 2
Indice
Il contesto
Obiettivi
Principi di ridefinizione del modello
Realizzazione del modello
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 3
La Società
• 1983 costituzione su iniziativa della Provincia autonoma di Trento e di altri Enti pubblici del Trentino
• 2006 diventa società “in house”
Gli Azionisti (al 2.04.2014)• Provincia autonoma di Trento (87,2568%)• Regione Autonoma Trentino-Alto Adige (1,7199%)• Comune di Trento (1,2433%)• Camera di Commercio Industria Artigianato e Agricoltura (1,2433%)• Comune di Rovereto (0,7063%)• 15 Comunità di Valle (5,0046%)• altri 200 Comuni (2,8258%)
Fatturato: 55 mil ioni di euro Dipendenti: 301
220 Socinella compagine azionaria
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 4
Il piano industriale 2007-2011 decide la trasformazione della società in erogatrice di servizi ICT per tutti gli enti pubblici del Trentino citando espressamente le best practices ITIL come paradigma di riferimento.
•2010 Riorganizzazione che porta alla costituzione del CST (Centro Servizi Territoriali)
•2012 Introduzione dei processi ITIL® v3 compliant
•2014 Nuovo impianto contrattuale con PAT
Alcuni numeri
• 180.000 contatti (ticket)
gestiti ogni anno
• 12.500 posti di lavoro serviti
• 730 server in data center
proprietario
• 300 servizi in erogazione
La Società
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 5
I servizi erogati da Informatica Trentina coprono la quasi totalità degli ambiti di business della Pubblica Amministrazione
• Acquisti• Agricoltura• Catasto e Libro Fondiario• Comunicazione• Contabilità / Ammin. / Bilancio• Cultura• Customer Service• Demografico• Foreste• Formazione• Governo• Imprese
• Interventi economici e sociali• Istruzione• Organizzazione• Patrimonio• Personale• Riscossione tributi• Sanità• Sicurezza• Tecnologico DTM /DC • Territorio• Trasporti• Turismo
La Società
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 6
I l contesto
• Da gennaio 2012 Sostituzione di gran parte dei processi con processi
ITIL®v3 standard Sostituzione del tool di ticketing con un tool di sostegno ai
processi Costituzione del Service Catalogue e del CMDB Copertura non completa del Service Lifecycle
Introduzione best practices ITIL® v3
Informatica Trentina compie una trasformazione da
Software House a Service Provider
1
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 7
I l contesto
• Servizio IT Esprime una risposta ad una esigenza di business Accorpa tutte le componenti che lo costituiscono
(hw, sw, organizzazione, sourcing, misurazione) Ha un Service Owner Garantisce dei l ivell i di servizio
Il Cliente e l’Utente si possono concentrare sui propri processi di business lasciando ad Informatica Trentina la soluzione delle
problematiche di ciascuna componente
Introduzione best practices ITIL® v31
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 8
I l contesto
• Entrata in vigore ad aprile 2013• Basata sul concetto di servizio IT• Definisce tre famiglie di servizi
Servizi di consulenza Servizi applicativi (sviluppo e gestione) Servizi infrastrutturali di base
Nuova Convenzione PAT / Informatica Trentina
La presentazione interessa questi
servizi
Con l’introduzione della nuova Convenzione si sono introdotti paradigmi diversi rispetto alla struttura contrattuale precedente
2
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 9
I l contesto
• Gestione dei servizi applicativi e infrastrutturali Canone annuo “opaco” omnicomprensivo di tutte le
componenti afferenti all’erogazione di un servizio (Design to cost)
Ufficializzazione del Service Catalogue
SLA da individuare e ufficializzare nel contratto annuale Modello individuato e condiviso nel 2° semestre 2013 Implementato e reso operativo nel corso del 1° semestre 2014 Operativo dal 2° semestre 2014
Nuova Convenzione PAT / Informatica Trentina2
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 10
Indice
Il contesto
Obiettivi
Principi di ridefinizione del modello
Realizzazione del modello
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 11
Obiett ivi
La formulazione del nuovo modello “SLA” ha cercato diperseguire questi obiettivi:
• Offrire degli indicatori rappresentativi e r iconoscibil i
• Semplif icare passando da un sistema di singoli indicatori (calcolati complessivamente a livello aziendale) a indicatori che accorpano le varie componenti (Hw, Sw, organizzazione) e che si riferiscono al singolo servizio
Nella Convenzione precedente esistevano degli indicatori relativi:alla difettosità del software complessivi e non divisi su ciascuna applicazioneai tempi di correzione del software, anche in questo caso complessivoall’uptime dei serverai tempi di esecuzione delle assistenze DTM
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 12
Obiett ivi
• Gli indicatori identificati sono basati sull ’esperienza Utente e si allontanano da una visione solamente tecnologica
Uptime vs Availabil i ty Correttiva sw vs Incident Bloccante e non bloccante
Indicatori rappresentativi
• Classi r idotte di indicatori più comprensibili• Ottimizzazione dei flussi di lavoro (Correttiva e
Deploy)
Semplif icazione
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 13
Indice
Il contesto
Obiettivi
Principi di ridefinizione del modello
Realizzazione del modello
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 14
Principi di r idefinizione del modello
Il nuovo modello si è basato su questi principi:1. Esistenza di un Impatto diverso di ciascun servizio sui
processi di business del Cliente2. Condivisione di un Perimetro di applicazione degli SLA3. Necessità di un campione signif icativo4. Distinzione fra malfunzionamento bloccante e non
bloccante5. Efficacia di una soglia 100%6. Definizione di una Struttura SLA standard
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 15
Principi di r idefinizione del modello
Impatto del servizio sui processi PAT1
Formalizzazione dei 254 servizi in Service CatalogueA ciascun servizio è stato associato:
• Un livello di crit icità (L1/L2/L3/L4)Rappresenta l’importanza che il servizio riveste per i processi di business dei Clienti e – conseguentemente – il livello di servizio richiesto (SLR) e il prezzo che il Cliente è disposto a pagare.
• Una f inestra di erogazioneRappresenta l’intervallo temporale per il quale è garantito che il servizio sia disponibile.
24x724x7 Tutti i giorni dalle 00.00 alle 23.59 14x6 14x6 Dal lun al sab dalle 8 alle 22 esclusi i festivi del Comune TN 9x5 9x5 Dal lun al ven dalle 8 alle 17 esclusi i festivi del Comune TN
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 16
Viene condiviso che ai servizi applicativi viene applicato il perimetro del Data Center
Perimetro di applicazione
Principi di r idefinizione del modello
2
Network Provider
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 17
• Deve esserci un numero significativo di eventi nel periodo di osservazione
• Poca attività non è rappresentativa dell’effettiva qualità del servizio erogato per questo i servizi L1 (impatto esteso/molto diffuso) sono sempre soggetti allo SLA
Campione significativo
Principi di r idefinizione del modello
3
I livelli di servizio non vengono applicati a tutti i servizi in erogazione
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 18
Esistono malfunzionamenti bloccanti, che devono essere risolti il prima possibile e malfunzionamenti non bloccanti, la cui soluzione può essere posticipata.
Un malfunzionamento è bloccante quando:• impedisce all’utente di lavorare e di percorrere il processo
di businesse
• quel che deve fare non è assolutamente differibile
Malfunzionamento bloccante e non bloccante
Un malfunzionamento bloccante deve essere risolto i l prima possibile in qualunque modo, anche con un workaround
Principi di r idefinizione del modello
4
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 19
La soglia del 100% sugli indicatori non viene applicata• Si eliminano le code dei ticket la cui soluzione è lunga per
natura• Non si entra nella situazione di SLA irraggiungibili
Soglia del 100%
Principi di r idefinizione del modello
5
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 20
• Per ogni servizio contrattualizzato possono essere definiti due Agreement, ciascuno per tipologia di controllo:
• AvailabilityAvailability(disponibilità del servizio)
• Incident e Request FulfilmentIncident e Request Fulfilment (malfunzionamenti, supporto utenza e service request)
• Ciascun Agreement rappresenta un macroelemento di controllo che consente una verif ica rapida e signif icativa della situazione
Struttura dello SLA
Principi di r idefinizione del modello
6
I livelli di servizio hanno la medesima struttura ma soglie differenti per ciascuna fascia di criticità
(ad esclusione della fascia L4 per cui non si calcolano i livelli di servizio)
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 21
Ogni Agreement presenta una serie di attributi :• Periodo di rendicontazione
annuale / semestrale / trimestrale
• Percentuale di compliance garantitaindica quanti eventi devono rispettare, nel periodo di osservazione, le soglie definite al proprio interno da uno o più Service Target, ciascuno per il proprio peso.
• Service Targetsingoli obbiettivi a raggiungere e vengono raggruppati all’interno di un Agreement
Principi di r idefinizione del modello
Struttura dello SLA6
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 22
• I Service Target sono singoli obiettivi da raggiungere e vengono raggruppati all’interno di un Agreement.
Ciascun target, a seconda della propria importanza, può assumereun peso diverso all’interno dell’Agreement.Calibrando opportunamente i pesi di ciascun Target è possibileprivilegiare il controllo di alcuni aspetti rispetto ad altri.
• Ogni Service Target presenta una serie di attributi: Finestra di servizio
24x7 / 14x6 / 9x5 Target da raggiungere Campione minimo signif icativo
25 ticket
Struttura dello SLA
Principi di r idefinizione del modello
6
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 23
Indice
Realizzazione del modello
Obiettivi
Principi di ridefinizione del modello
Il contesto
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 24
• Esprime la capacità di gestire i malfunzionamenti segnalati dall'utenza indipendentemente dalla tipologia di malfunzionamento e di gestire le richieste di aiuto o supporto da parte dell'utenza
Agreement “Incident”1
Realizzazione del modello
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 25
Realizzazione del modello
L’agreement “Incident” viene applicato ai servizi secondo
questo schema:• Tutt i i servizi L1 (sono 4)• I servizi L2 che hanno raggiunto i 100 t icket
complessivi nei 12 mesi precedenti al nuovo periodo di osservazione (sono 14)
• I servizi L3 che hanno raggiunto i 250 t icket complessivi nei 12 mesi precedenti al nuovo periodo di osservazione (sono 8)
• Nessun servizio L4
Agreement “Incident”1
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 26
1 2 3 41 Critical Critical High High2 Critical High High Medium3 High Medium Medium Medium4 Low Low Low Low
Urg
enza
Impatto
VIP o parzialmente bloccante
Valorizzato inizialmente con impatto servizio
Ad un ticket di INC è associata una priorità calcolata in base alla combinazione dei valori di Impatto e Urgenza dichiarati.
Bloccante
Realizzazione del modello
Agreement “Incident”1
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 27
• Esprime la disponibilità di un servizio verso l’utenza sul confine del Data Center
Agreement “Availabil ity”2
Finestra di servizio 24x7 - 14x6 - 9x5dipendentemente dal Servizio
Rendicontazione Annuale
Vincolo tutti
Compliance 99% 96% 93%
L4L1 L2 L3
Realizzazione del modello
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 28
La misura della disponibilità avviene attraverso un sistema di monitoraggio configurato per verificare se un servizio è “up & run” dal punto di vista dell’utilizzatore.Esiste un meccanismo di verifica, ad opera dei gruppi di Service Support, che verifica se l’outage è da considerarsi vera indisponibilità
Agreement “Availabil ity”2
Realizzazione del modello
Outage Outage
certi f icato
SLMSistema
MonitoraggioService Support
Report
L’Availabil ity è garantita per TUTTI i servizi L1/L2/L3
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 29
• Periodo di sperimentazione di 6 mesi• Condivisione continua con il Cliente del significato di
servizio e dei suoi attributi • Pubblicazione periodica di un
“Report di servizio” Report sintetico e leggibile dei
livelli di servizio Report quanti/qualitativo
dei servizi afferenti ad uno specifico ambito
I l report di servizio3
Realizzazione del modello
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 30
Realizzazione del modello
Underpinning Contract (UC) e OLA4
• La revisione degli SLA ha reso necessario rivedere anche il meccanismo degli UC
• Sono state sviluppate 4 tipologie di Agreement: Incident e Request Fulfilment Manutenzione Software (Change e Incident 3° livello) Sviluppo Software (Change) Manutenzione Hardware (Incident 3° livello) Sviluppo Hardware (Change)
• I medesimi agreement verranno utilizzati anche come OLA
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 31
Realizzazione del modello
Underpinning Contract (UC) e OLA4
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 32
• Consapevolezza del concetto di “servizio IT” e condivisione di un percorso
All’interno (tutte le strutture) All’esterno (Clienti)
• Meccanismo di taratura difficile Peso dei Service Target vs. numerosità degli eventi Misurazione della disponibilità “dal punto di vista
dell’utente” non sempre efficace (falsi positivi)
• Esperienza down totale del Data Center
Punti di attenzione5
Realizzazione del modello
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 33
Domande?
Nicola Zanellanicola.zanella@infotn.it+39 0461.800205http://about.me/nicolazanella
Vrae?Afrikaans
Questions?English
¿Preguntas?Spanish
Domande?I ta lian
Вопросы?Russian Ερωτήσεις;
Greek
tupoQghachmey?Klingon
質問?Japanese
أسئلة؟Arabic
問題呢 ?Chinese
?שאלותJewish
Questions?French
Fragen?German
पश?HindiQuaestio?
Latino
Nicola Zanella è il responsabile della staff “Metodi e Strumenti” di Informatica Trentina.
E’ il responsabile dei processi di Service Level Management, Service Catalogue Management e Service Asset and Configuration Management
Informatica Trentina spa – Nicola Zanella - Milano, 9 settembre 2014 34