Idea principale

Il database delle buste paga sta ormai nell'ambiente Azure del cliente. Una mattina l'applicazione non risponde più. È il motore del produttore, il database SQL Server del cliente, una regola di rete modificata il giorno prima, un certificato, una configurazione IAM, una saturazione delle connessioni, una quota, la latenza?

Rispondere «il database è presso il cliente, non è un problema nostro» non funziona. Per l'utente che non riesce a elaborare le buste paga, è il servizio del produttore a essere fuori uso.

Il contratto ha spostato una responsabilità; la percezione, invece, è rimasta dov'era.

Perché è importante

Ne deriva un obbligo che non discende dal contratto ma dalla situazione: monitorare la risorsa esternalizzata e la sua connettività quanto basta per capire da dove nasce un incidente. Non amministrare l'infrastruttura del cliente, ma disporre dei segnali — disponibilità, latenza, errori di connessione, saturazione, stato di salute.

È un costo che l'accordo non mette in luce quando lo si negozia, e che poi non sparisce più.

Sfumature e limiti

Il monitoraggio non mette il produttore in condizione di intervenire: vedere il guasto e poterlo riparare sono due cose diverse.

E l'obbligo ha un limite: oltre un certo punto, monitorare tutto l'ambiente del cliente equivale a gestirlo, cosa che la ripartizione doveva proprio evitare.

Domande aperte

• Quale livello di monitoraggio basta a fare diagnosi senza invadere la gestione operativa del cliente?