Vai al contenuto

Collegare gli obiettivi SLA a una procedura di intervento

Una percentuale di disponibilità richiede un ambito di misura chiaro. Un guasto applicativo richiede anche osservazione, responsabilità e ripresa.

Lukas Schneider2 min di lettura
Indicatore semicircolare con una lancetta rossa e una zona evidenziata in verde.

Una percentuale di disponibilità è più facile da confrontare rispetto all’organizzazione di un intervento. Per gestire l’applicazione occorre però chiarire che cosa misura il valore e come un’osservazione rilevante porti a un’azione coordinata.

Google SRE distingue il Service Level Indicator (SLI) come indicatore misurato, il Service Level Objective (SLO) come obiettivo e il Service Level Agreement (SLA) come accordo sul livello di servizio. Una metrica richiede un ambito definito e una finestra di misurazione. La sola denominazione SLA non spiega quale parte del flusso applicativo venga osservata.

Un componente disponibile può nascondere un flusso interrotto

Nell’esempio inventato, un portale usa servizi diversi per l’applicazione web e l’archiviazione dei file. Durante l’evento S-60, la pagina iniziale continua a rispondere. Le nuove richieste con file, invece, non possono essere salvate interamente. Un punto di misura limitato alla pagina iniziale non rappresenta questo impatto.

Il team dovrebbe quindi collegare la misura alla funzione necessaria all’utente. Da ciò non deriva una conclusione su uno specifico accordo con un fornitore: l’esempio riguarda l’osservazione tecnica necessaria per la propria applicazione.

Completare la metrica con l’assegnazione delle attività

Il piano seguente collega l’ambito di misura alla risposta per questo caso.

Aspetto

Da chiarire per il portale

Ruolo responsabile

Osservazione

Si verifica soltanto un componente oppure il flusso completo della richiesta?

Responsabile dell’applicazione

Intervento

Chi riunisce i riscontri, contatta i servizi interessati e coordina le modifiche?

Coordinamento dell’incidente

Ripresa

Chi verifica richiesta, file e lavoro aperto, e decide il successivo passo operativo?

Responsabili di processo e gestione operativa

Sono proposte per l’esempio, non valori di servizio misurati qui o ruoli già assegnati. Una metrica di disponibilità da sola non determina né l’azione tecnica né il momento concreto della ripresa.

Verificare insieme misura e procedura

Organizzare la propria gestione degli incidenti non rende irrilevanti gli impegni di servizio esterni. Aggiunge alla visione dei componenti interessati il lavoro sul flusso completo. Chiarisca quindi insieme misura, canale di contatto e autorità decisionale.

Quando sono coinvolti più servizi, il team ha bisogno di una visione coordinata dell’impatto. Un riscontro tecnico diventa una decisione operativa solida quando è collegato al flusso interessato e l’azione successiva è assegnata a un ruolo responsabile.

Fonti

Scritto da

  • Lukas SchneiderRedattore tecnicoLukas Schneider scrive per ASES di tecnologie cloud e della gestione delle applicazioni. I suoi articoli spaziano dalla scelta dell’infrastruttura alla manutenzione e ai backup, fino al monitoraggio dei sistemi in esercizio.

Seguite ASES

Continuate a leggere

Tutti gli articoli

Cloud & gestione con ASES

Hosting, deployment, manutenzione e assistenza