IT
ItalianoEnglish

L'IT vero non sta
nelle presentazionimasul campo

Quattro storie dal lavoro di ogni giorno: un venerdì sera che poteva finire male, un guasto che non era un guasto, un trasloco a motori accesi e un assistente che ha convinto tutti restando zitto.

19:40

Il telefono suona alle 19:40 di un venerdì. Dall'altra parte c'è la responsabile amministrativa di un'azienda di distribuzione, una sessantina di persone, tre magazzini, un gestionale che non dorme mai. Dice una frase che chi fa questo mestiere impara a riconoscere al volo: non riesco ad aprire un file, e ha un nome strano.

Alle 19:55 i file con il nome strano sono decine. Alle 20:15 sono centinaia, e su una cartella condivisa compare un documento che spiega, in un inglese cortese e minaccioso, quanto costerebbe riaverli.

Non spegnere niente

La prima decisione è quella che sembra meno naturale: non spegnere i server. Spegnere distrugge le tracce che serviranno a capire cosa è successo, e a volte interrompe una cifratura a metà lasciando i dati in uno stato peggiore.

Si isolano invece le macchine dalla rete, si scollega ciò che va scollegato, si fotografa la situazione. Poi si apre il piano.

Il piano esisteva davvero

Era stato scritto mesi prima insieme al cliente, con l'ordine delle cose da fare e i numeri di telefono delle persone giuste. Ed esistevano i backup. Non quelli di cui tutti dichiarano l'esistenza, ma quelli veri: copie isolate dalla rete, con prove di ripristino eseguite ogni mese e messe a verbale.

L'ultima prova risaliva a diciannove giorni prima. Sapevamo quanto tempo serviva per rimettere in piedi il gestionale, perché lo avevamo già fatto per esercizio.

Un weekend di lavoro

Il sabato è servito a capire da dove fossero entrati: una casella di posta compromessa settimane prima, un accesso rimasto sotto traccia. La domenica a ripristinare, bonificare, cambiare ogni credenziale, chiudere il varco.

Il lunedì alle nove l'azienda lavorava. Ha perso qualche ora di dati, una quantità nota e accettata in anticipo: anche quella era una scelta scritta nel piano, non una sorpresa scoperta a cose fatte.

La differenza

Del riscatto non si è mai discusso, perché non ce n'è stato bisogno. Ed è questo il punto da portarsi via: la differenza tra un incidente e un disastro non si decide quella notte.

Si decide nei mesi tranquilli, quando provare un ripristino sembra tempo perso e segmentare una rete sembra pignoleria.

Quello che resta

Un backup non è quello che salvi: è quello che riesci a ripristinare. E la calma, durante un incidente, non è una dote di carattere. È una procedura scritta prima.

Un fornitore alla volta

C'è un'azienda meccanica, una quarantina di persone, che per anni ha fatto quello che fanno quasi tutte: aggiungere un fornitore ogni volta che nasceva un'esigenza. La posta elettronica la gestiva una società, il gestionale un'altra, la rete un tecnico di fiducia che veniva quando poteva.

Poi il centralino, le stampanti, il sito, la videosorveglianza. Sette fornitori in tutto. Ognuno bravo nel suo pezzo, nessuno responsabile dell'insieme.

Il lunedì della posta

Un lunedì mattina la posta smette di funzionare. Non per tutti: solo per alcuni, il che è peggio, perché rende il problema difficile da descrivere e facile da rimpallare.

Il fornitore della posta dice che il problema è la rete. Il tecnico della rete dice che è il dominio. Chi gestisce il dominio non risponde fino al giorno dopo. Nel frattempo l'azienda non manda ordini, non riceve conferme, e chi risponde al telefono non sa cosa dire ai clienti.

Tre giorni

Il guasto in sé era modesto: un rinnovo non eseguito e una configurazione modificata da qualcuno che non l'aveva documentata. Tre giorni per risolverlo, di cui due e mezzo passati a capire di chi fosse il compito.

Il costo vero non è stato tecnico. È stato il tempo, la figura con i clienti, e la scoperta di non sapere chi comandasse su cosa.

La mappa che non c'era

Quando siamo arrivati, la richiesta era: dateci un preventivo per la posta. La risposta onesta era un'altra: il problema non è la posta. Abbiamo proposto prima un assessment, cioè una mappa.

L'inventario ha fatto emergere ciò che nessuno vedeva più: credenziali che esistevano solo nella memoria di singole persone, apparati fuori supporto da anni, contratti che si sovrapponevano pagando due volte lo stesso servizio.

Un solo responsabile

Il lavoro vero non è stato sostituire i fornitori. Alcuni sono rimasti, perché lavoravano bene. È stato dare all'insieme un responsabile: documentazione unica, credenziali custodite e tracciate, un punto di contatto che risponde sempre e coordina anche gli altri.

Il primo effetto misurabile è arrivato al guasto successivo, qualche mese dopo: un pomeriggio di lavoro, un solo interlocutore, nessun rimpallo.

Quello che resta

Il fornitore più costoso non è quello con la tariffa più alta: è l'insieme di cui nessuno risponde. Prima di chiedere l'ennesimo preventivo, chiediti chi ha la mappa.

Un trasloco a motori accesi

Sulla carta era una fornitura: un cluster di virtualizzazione a fine supporto da sostituire. Nella realtà era un trasloco a motori accesi.

L'infrastruttura reggeva una settantina di macchine virtuali, tra cui un ERP usato su tre turni, sei giorni su sette. Lo storage era al 92%, le prestazioni calavano da mesi, e nessuno sapeva più dire con certezza cosa si potesse spegnere.

Prima si misura

Il primo mese non abbiamo montato niente. Abbiamo misurato: tre mesi di metriche reali su CPU, memoria, latenze dello storage e profili orari dei carichi. Il dimensionamento fatto sulle dichiarazioni, dove ogni server è per definizione fondamentale, produce cluster sovradimensionati dove non serve e scarsi dove fa male.

Dalle misure sono emerse le sorprese tipiche: catene di snapshot dimenticate da mesi, macchine accese che non servivano più a nessuno, e valori di CPU ready che spiegavano lentezze che gli utenti avevano smesso di segnalare per rassegnazione.

Ondate

Il nuovo cluster è nato affiancato al vecchio, sulla stessa rete, con lo storage nuovo già in produzione. Le migrazioni sono partite dalle macchine meno critiche.

Non per prudenza generica: per collaudare il metodo su ciò che poteva permettersi un errore, e arrivare alle macchine importanti con una procedura già rodata. A ogni ondata, verifica dei backup prima di partire e criteri di ritorno scritti.

Il piano per quando va male

Per l'ERP la finestra concordata era di quattro ore, un sabato notte. Il runbook aveva i minuti scritti accanto a ogni passo, e soprattutto aveva i criteri di rollback decisi prima: se a un'ora precisa il database non risulta allineato, si torna indietro, senza discussioni.

È la parte che nei progetti manca più spesso. Non il piano per quando va tutto bene: il piano per quando va male, deciso quando si è ancora lucidi e nessuno ha fretta.

Quaranta minuti

Il passaggio è durato quaranta minuti delle quattro ore concesse. Il lunedì mattina non è arrivato nessun ticket.

La settimana dopo, una persona dell'amministrazione ha chiesto candidamente se la migrazione fosse stata rimandata. È il miglior complimento che questo lavoro possa ricevere.

Quello che resta

Una migrazione riuscita è un evento noioso, e la noia non è fortuna: è progetto. Se il piano di rollback si decide la notte del passaggio, è già troppo tardi.

Trent'anni di documenti

Il gruppo aveva trent'anni di documenti: procedure, contratti, manuali tecnici, verbali, offerte. E in mezzo, come sempre, cartelle del personale, accordi riservati, un contenzioso.

La richiesta era una di quelle che oggi arrivano ogni settimana: vogliamo un assistente interno che risponda alle domande delle persone usando i nostri documenti.

Il rischio silenzioso

Di questi sistemi si discute quasi sempre un rischio solo, l'errore: la risposta inventata con sicurezza, la cosiddetta allucinazione. Ma negli ambienti aziendali c'è un rischio più silenzioso e più costoso: la risposta giusta data alla persona sbagliata.

Un assistente che ha letto tutto e risponde a tutti non è un progetto di produttività. È un incidente in attesa di accadere.

Permessi prima del modello

Il progetto quindi è cominciato da lì, non dal modello. Il recupero dei documenti è stato costruito per rispettare i permessi d'origine: l'assistente cerca soltanto dove la persona che domanda potrebbe già entrare da sola, con le proprie credenziali.

Ogni risposta cita le fonti, con il collegamento al documento da cui proviene. E quando il contesto non basta a rispondere con fondamento, l'assistente lo dichiara: non lo so, con le informazioni disponibili, è una risposta prevista dal progetto, non un fallimento del sistema.

Il banco di prova

Prima di scrivere una riga di integrazione abbiamo scritto il set di valutazione: alcune centinaia di domande con la risposta attesa, comprese le domande trabocchetto, quelle costruite apposta per invitare il sistema a inventare o a sconfinare dove non deve.

Ogni modifica passa da quel banco di prova prima di arrivare agli utenti. Tutto ciò che l'assistente riceve e risponde viene registrato, perché un sistema che parla con l'azienda deve poter essere verificato come qualunque altro sistema aziendale.

La demo decisiva

La dimostrazione che ha deciso il progetto non è stata una risposta brillante. In riunione, un dirigente ha chiesto all'assistente i dati retributivi di un reparto. L'assistente ha risposto che quei documenti non erano accessibili con il suo profilo, e ha indicato a chi rivolgersi.

C'è stato un momento di silenzio, poi la frase che valeva l'intero lavoro: allora possiamo usarlo davvero.

Quello che resta

Di un sistema che risponde a tutto ci si stanca in fretta; di uno che risponde troppo ci si pente. In azienda l'affidabilità di un'AI si misura anche da ciò che si rifiuta di dire.

Ogni storia comincia da un primo confronto.

Se in una di queste situazioni hai riconosciuto la tua azienda, o vuoi evitare di riconoscerla in futuro, parliamone: senza impegno e senza presentazioni.

Raccontaci la tua situazione