Guida all'implementazione › Esempi di case study › Esempi di modellazione di contratto › Case study 3: tempi di risposta del sistema

Case study 3: tempi di risposta del sistema

I seguenti case study illustrano le metriche dei tempi di risposta. Un contratto può essere modellato in diversi modi, ciascuno con i suoi vantaggi.

Nel seguente esempio vengono esaminati vari metodi di modellazione:

In base alle matrice sopra riportata, qual è il livello di servizio effettivo calcolato?

In base alla definizione della categoria di dominio, sembra che il livello di servizio effettivo sia calcolato come un valore massimo. Questo implica che per tutte le transazioni eseguite durante un mese, viene acquisita la transazione con il valore massimo e questo valore viene confrontato con la destinazione.

Nota: il calcolo del livello di servizio è basato su un'aggregazione di dati non elaborati in un determinato periodo di tempo. Per ogni periodo di tempo, la metrica fornisce un risultato singolo. La destinazione di una metrica non viene confrontata con una singola transazione, ma con un risultato mensile che è un'aggregazione periodica di tutte le transazioni entro tale periodo. Il responsabile contratti deve controllare che il risultato rispecchi da un lato il contratto e dall'altro la qualità del servizio.

Nota: la misurazione del tempo di risposta come valore massimo è un obbligo molto rigido e difficile da raggiungere nella prassi. Misurare un livello massimo significa che una singola transazione di 751 ms su un milione di transazioni eseguite nel corso di un mese è sufficiente per causare una violazione del contratto. Tutte le barre nei report saranno quindi rosse e non rifletteranno la vera qualità del servizio che è stata fornita.

Nella figura seguente viene illustrato un report tipico in queste circostanze.

Qualsiasi transazione che supera la destinazione verrà considerata una violazione del contratto, ma come base per comprendere l'effettiva qualità del servizio fornito è molto scarsa, poiché riflette solo una singola transazione e non si conosce nulla in merito al resto delle transazioni, ad esempio, si è trattato di un errore o di un trend? Se non è stato un incidente isolato, quindi quanti errori si sono verificati, o qual è il rapporto tra le transazioni non riuscite e il numero totale di transazioni eseguite durante il mese? Potrebbe esserci alcuni mesi con tali occorrenze e di conseguenza una violazione del contratto, ma qual è la tendenza? Sta migliorando o peggiorando? Tutte queste sono le domande che il manager del livello di servizio potrebbe chiedere e che il report deve essere in grado di fornire le risposte.

Nota: quando si definiscono la metrica e lo schema di calcolo associato, è molto importante prevedere come i risultati verranno visualizzati in un report. Il report deve fornire due elementi fondamentali:

• Si è verificata una violazione del contratto?
• Deve fornire ai manager sufficiente trasparenza dei dati e la possibilità di esaminare la causa dell'errore e anche offrire ai gestori gli strumenti necessari per comprendere a fondo i componenti del servizio.

Il calcolo del tempo medio di risposta fornisce un'idea migliore della qualità di servizio mensile e allo stesso tempo può ancora possibile riflettere quei mesi con tempi di risposta al limite o non conformi al contratto.

Utilizzando questo metodo, verrà calcolata la percentuale di transazioni completate correttamente entro la soglia di 750 ms durante il periodo specificato, fornita dalla formula:

((Numero di transazioni in 750 ms)/(numero totale di transazioni))*100

L'espressione della garanzia come una percentuale di successo offre la possibilità di mantenere una garanzia ristretta (destinazione al 100%), mentre consente anche il valore effettivo che rappresenta la scarsa o elevata qualità del servizio.

Utilizzando questo metodo, la destinazione non è un limite superiore di 750 MS, ma è il rapporto da conservare. Nei casi in cui la garanzia deve essere ristretta, la destinazione deve essere 100%, che non lascia spazio neanche un singolo errore. Nota: in tal caso, è stata introdotta un'ulteriore variabile, il parametro di metrica. Questo parametro deve essere implementato come parametro di metrica per consentire modifiche semplici, se necessarie.

Un modello alternativo a questo metodo può essere quello di forzare un modello di tipo di escalation:

Le seguenti tre soluzioni definiscono tre metriche invece di una singola, come nelle soluzioni precedenti.

Nel caso in cui sia necessario segnalare l'obbligo contrattuale, nonché il numero di transazioni che superano la soglia di 750 ms, è necessario definire un'ulteriore metrica per contare il numero di transazioni non riuscite.

Nota: ogni metrica genera un singolo risultato per un determinato periodo di tempo. Se è impostata per calcolare la percentuale delle transazioni, non è in grado di specificare il numero di transazioni.

L'unico modo per produrre report aggiuntivi da una metrica è utilizzare gli output dalla business logic. (Fare riferimento alla sezione Output - Tabelle utente in cui sono descritti i risultati di output dalla business logic).