Sorvegliare i sistemi in termini di disponibilità e velocità, e segnalare le anomalie prima che gli utenti ne subiscano le conseguenze, è un compito che può essere largamente affidato all'IA. Non perché l'IA capisca improvvisamente di infrastruttura, ma perché il compito stesso è da anni strutturato attorno a metriche, soglie e ripetizione. Si tratta di una conclusione diversa rispetto a quella relativa a compiti in cui il giudizio o la negoziazione costituiscono il nucleo centrale.
Tre assi sono qui decisivi: volume, strutturazione e costo degli errori.
Il volume è elevato. Il monitoraggio è continuo, giorno e notte, su centinaia o migliaia di punti di misurazione. Una persona che dovesse tenerne traccia manualmente guarderebbe le dashboard a intervalli, perdendo ciò che accade nel frattempo. Un sistema che misura ogni secondo e confronta con un valore soglia non perde nulla.
La strutturazione è elevata. Il compito consiste in: misurare, confrontare con una norma e, in caso di anomalia, emettere un segnale. Si tratta di una procedura fissa, non di un problema aperto. Si confronti questo con la gestione di una richiesta di un utente sul software, dove la domanda è formulata ogni volta in modo diverso e richiede contesto.
Il costo degli errori è basso o medio. Una segnalazione mancata o in ritardo è fastidiosa, ma quasi sempre recuperabile: il sistema invia un nuovo avviso non appena l'anomalia persiste, e la maggior parte delle soglie è impostata con un margine. Ciò è diverso da un compito in cui un singolo passaggio mancato lascia immediatamente un utente senza un'applicazione funzionante, come nella risoluzione di un incidente IT di primo livello.
Due assi frenano il quadro: lo spazio di giudizio e la creatività si collocano rispettivamente a 2 e 1.
Segnalare un'anomalia è diverso dal comprendere cosa significhi tale anomalia per l'organizzazione. Un picco nell'uso della memoria può essere innocuo, oppure l'inizio di un problema che entro due ore blocca il negozio online. Determinare quel significato, e decidere di far intervenire un ingegnere, resta un lavoro umano. L'IA segnala l'anomalia; una persona con conoscenza dell'ambiente valuta cosa vale quella anomalia.
È anche per questo che questo compito non è isolato. Il segnale emesso da uno strumento di monitoraggio deve trovare un punto di arrivo: come incidente registrato con l'urgenza corretta. Il prosieguo di questo processo è descritto in Registrare e assegnare priorità agli incidenti IT, un compito leggermente meno strutturato del monitoraggio in sé.
La valutazione è: un agente. Non uno script isolato che controlla una singola soglia, ma un sistema che misura continuamente, combina più segnali e determina autonomamente se un pattern merita una segnalazione prima che una persona lo veda. Si tratta di un passo oltre il semplice alerting, e un passo indietro rispetto all'autonomia completa: l'agente segnala e categorizza, un amministratore decide cosa fare con il segnale.
Due condizioni determinano se ciò funziona. Devono esserci soglie configurate, calibrate su ciò che è normale per quegli specifici sistemi: una soglia sufficientemente rigorosa per un'applicazione può, per un'altra, generare costantemente falsi allarmi. E deve esserci un sistema di alerting automatizzato che consegni effettivamente il segnale a qualcuno. Senza questi due elementi non c'è nulla da automatizzare: nessuna norma con cui confrontarsi, nessun canale per trasmettere il segnale.
In un'azienda con pochi server e un orario d'ufficio fisso, il monitoraggio è spesso ancora una questione di controlli occasionali. Il guadagno in termini di volume derivante dall'automazione è in tal caso limitato, semplicemente perché il volume è basso. In un'azienda con molti sistemi, clienti che si aspettano accesso in qualsiasi momento della giornata, e una storia di incidenti avvenuti di notte, il quadro è diverso: lì la capacità in termini di fte che si libera grazie a una sorveglianza automatizzata continua cresce rapidamente, poiché l'alternativa è una persona che deve rimanere permanentemente disponibile.
Anche l'asse dei costi degli errori varia da azienda ad azienda. In un ambiente di test interno, una segnalazione mancata non ha conseguenze. In un sistema che riguarda direttamente le transazioni di pagamento o i dati medici, il livello di conformità richiesto è più alto, e ciò spinge ulteriormente l'asse della conformità, già a 4 in questo caso, verso la registrazione obbligatoria e il follow-up dimostrabile.
Questa non è un'affermazione sul personale. Se e come un'organizzazione impieghi diversamente la capacità liberata di un amministratore di sistema è una scelta del datore di lavoro, con propri requisiti legali laddove riguardi decisioni relative alle funzioni. Questa pagina descrive solo il lavoro, non le persone che oggi lo svolgono.
Il monitoraggio è raramente un compito isolato. È collegato all'esecuzione e al controllo dei backup, alla gestione degli incidenti, e alla pianificazione di chi deve essere disponibile e quando per il follow-up. Chi desidera una visione più ampia di ciò che l'IA può assumere nella funzione IT nel suo complesso trova un punto di partenza nella pagina sul lavoro e la pianificazione.
Questa pagina fornisce una valutazione basata sul compito nella sua forma generale. Quanto ciò significhi per una specifica azienda dipende dal numero di sistemi, dalle soglie configurate e dalle conseguenze di una segnalazione mancata. Un'indicazione per la propria situazione si può ottenere con la quickscan gratuita: dodici domande, senza account, con un'indicazione della quota di ore in questo profilo che oggi può essere affidata all'IA. La scansione completa del lavoro, che analizza il lavoro di un'intera azienda suddividendolo in compiti, è ancora in fase di sviluppo.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.