Ogni pochi mesi un servizio importante si guasta in un modo che trascina con sé una fetta consistente di internet, e la causa si rivela essere qualcosa nello strato che tutti davano per assorbito nell'astrazione.
L'astrazione nasconde lo strato, non lo cancella
La narrazione raccontata sull'infrastruttura negli ultimi quindici anni è che sia sparita nel cloud. I server sono diventati istanze, poi container, poi funzioni. Le reti sono diventate configurazione. Lo storage è diventato un'interfaccia.
Ognuno di questi passaggi è reale e utile, e nessuno ha eliminato nulla. Il pacchetto deve comunque raggiungere una destinazione. Il nome deve comunque risolversi. Il certificato deve comunque essere valido e aggiornato. Il disco ha comunque una capacità. L'orologio deve comunque essere allineato con gli altri orologi.
Ciò che è cambiato è chi se ne accorge quando una di queste cose si guasta, e quanto è difficile vederlo.
L'astrazione allontana il guasto da chi lo subisce, il che rende il problema più difficile da trovare e la persona in grado di trovarlo più preziosa.
Questo è l'argomento di fondo per questa direzione. Non nostalgia per il montaggio dei server, ma l'osservazione che il numero di persone in grado di ragionare su cosa sta davvero succedendo sotto è calato più in fretta del bisogno che ne abbiamo.
Cosa copre la direzione
L'ambito: sistemi operativi, hardware, reti, server, amministrazione e troubleshooting.
Quattro aree.
Rete. Indirizzamento, instradamento, risoluzione dei nomi, bilanciamento del carico, firewall e il percorso che una richiesta compie davvero.
Sistemi operativi. Processi, permessi, filesystem, servizi e log, sulle piattaforme che l'organizzazione utilizza.
Identità e directory. Autenticazione, autorizzazione, certificati e i sistemi che li emettono.
Operations. Monitoraggio, backup e ripristino, capacità, patching e troubleshooting strutturato.
È sempre il DNS, e perché quella battuta è vera
La battuta ricorrente tra gli ingegneri di infrastruttura punta a qualcosa di reale su come si guastano i sistemi.
La risoluzione dei nomi sta sotto quasi tutto, è invisibile quando funziona, e produce sintomi che sembrano tutt'altro. Un'applicazione appare lenta quando la risoluzione va in timeout. Un servizio appare offline quando un record punta a un indirizzo dismesso. Una modifica si propaga in modo irregolare per via del caching su più strati, così il sistema è rotto per alcuni utenti e a posto per altri, il pattern di guasto più difficile da diagnosticare.
Altri tre membri della stessa famiglia causano una quota simile di incidenti per lo stesso motivo.
Certificati. Scadono. In una data nota con anni di anticipo. Gravi disservizi in grandi organizzazioni sono stati causati esattamente da questo, ripetutamente, perché il rinnovo era manuale e la persona che se ne ricordava se n'era andata.
Orario. La deriva dell'orologio rompe i protocolli di autenticazione, invalida i controlli sui certificati, corrompe la correlazione dei log e fa comportare i sistemi distribuiti in modo incoerente. Si presenta come un problema di autenticazione, così le persone indagano sull'autenticazione.
Instradamento e percorso. Percorsi asimmetrici, cambi di percorso, regole firewall aggiunte per uno scopo e che ne toccano un altro. I sintomi compaiono a intermittenza e solo per alcune sorgenti.
Ciò che li accomuna è che ognuno è infrastruttura da cui tutti dipendono e che nessuno possiede, e ognuno produce sintomi in uno strato lontano dalla causa. Gli ingegneri che sanno controllare questi elementi per primi risolvono in minuti ciò che altrimenti richiede una giornata.
Dove si colloca nel dominio
Sistemi IT e reti di computer è la settima di otto direzioni nel dominio IA, dati e computing di Astra Trainer, e funziona come linea di rifornimento per tutto il resto. Cloud computing e DevOps, cybersecurity e platform engineering reclutano tutti da qui, e tutti poggiano sulla comprensione che questa direzione costruisce.
Si collega più direttamente all'informatica per il modello di sistema operativo e di rete, e alla cybersecurity, dove la capacità di ragionare su cosa fa davvero un sistema è il fondamento del rilevamento e della risposta. Puoi vedere qui le otto direzioni.
Il troubleshooting è un metodo, non un talento
La capacità più trasferibile e meno insegnata di questa direzione. Viene trattata come qualcosa che si ha o non si ha, ed è invece una procedura.
Stabilisci cosa è cambiato davvero. I sistemi che funzionavano ieri e falliscono oggi di solito sono cambiati, anche quando tutti dicono che non è cambiato nulla. Deployment, rinnovi di certificati, aggiornamenti di regole, credenziali scadute, un disco pieno che ha superato una soglia.
Definisci l'ambito con precisione. Tutti gli utenti o solo alcuni. Tutte le sedi o una sola. Sempre o a intermittenza. Ogni risposta elimina intere categorie di causa, e l'imprecisione qui è il motivo per cui le indagini vagano.
Lavora lungo il percorso. Una richiesta attraversa una sequenza nota di componenti. Fai un test in vari punti lungo il percorso e determina dove il comportamento smette di rispettare le attese. Questo trasforma un problema aperto in una ricerca con una risposta finita.
Cambia una cosa alla volta. Cambiarne diverse e scoprire che funziona ti lascia senza sapere perché, il che significa che non puoi prevenirlo né risolverlo la prossima volta.
Leggi i log nel modo giusto. Non l'ultimo errore, che spesso è un effetto a valle, ma la prima anomalia e la sequenza intorno a essa, con gli orari correlati tra i sistemi.
Sappi quando ripristinare invece che diagnosticare. Durante un disservizio, ripristinare il servizio e indagare in seguito è spesso la scelta corretta. Confondere il ripristino con la causa radice è il motivo per cui lo stesso incidente si ripete.
Insegnato esplicitamente, questo rende ingegneri ordinari drasticamente più efficaci. Lasciato implicito, le persone lo sviluppano in anni o mai.
Il vero problema di carriera di questa direzione
Vale la pena nominarlo apertamente, perché è il vincolo reale e non è tecnico.
Il lavoro di infrastruttura viene trattato come overhead. Appare nei budget come costo, viene misurato dall'assenza di problemi, e viene notato quasi esclusivamente quando qualcosa si guasta. Lo sviluppo costruisce cose che vengono annunciate. L'infrastruttura mantiene le cose in funzione, il che non produce annunci.
Ne seguono quattro conseguenze.
Retribuzione e status restano indietro rispetto a ruoli affini con difficoltà comparabile o minore, il che spinge fuori dalla disciplina le persone capaci.
Gli investimenti arrivano dopo gli incidenti e diminuiscono in seguito, così la capacità si costruisce in modo reattivo.
L'esternalizzazione ha eliminato il terreno di formazione. I ruoli junior dove si costruiva la comprensione dell'infrastruttura sono stati esternalizzati in molte organizzazioni, lo stesso blocco della pipeline descritto nella direzione sulla cybersecurity.
La conoscenza è non documentata e personale. Quali sistemi contano, come appare la normalità, dove sta la dipendenza strana. Se ne va con la persona, e il sostituto la ricostruisce lentamente e a caro prezzo.
Un'organizzazione che vuole capacità cloud, di sicurezza e di piattaforma dovrebbe riconoscere che sta sottoinvestendo nella popolazione da cui quelle discipline reclutano, e che è una decisione che può invertire a basso costo.
I ruoli, nominati
Amministratori di sistema, su tutte le principali piattaforme.
Ingegneri e architetti di rete.
Ingegneri di infrastruttura.
Specialisti di identità e directory.
Ingegneri di storage e backup, la cui importanza diventa ovvia esattamente una volta.
Specialisti di virtualizzazione.
Ingegneri di end user computing ed endpoint.
Service desk e supporto tecnico, il punto d'ingresso più comune nell'intero dominio.
Tecnici di data center, una popolazione tornata a crescere con l'espansione della capacità di calcolo.
Chi può essere formato per questo
Personale di service desk e supporto. Il percorso classico e ancora il migliore. Vedono già l'intero parco macchine, sanno cosa si rompe e hanno un istinto per il troubleshooting che la formazione strutturata trasforma in metodo.
Tecnici delle telecomunicazioni. Verso la rete, con lo strato fisico e di trasmissione già in mano.
Personale militare di comunicazioni e sistemi informativi. Spesso eccellente, con competenza tecnica e disciplina operativa già in dotazione.
Elettricisti e tecnici degli impianti degli edifici. Verso il lavoro di data center e infrastruttura fisica.
Chiunque abbia amministrato sistemi in modo informale, in una piccola azienda o come la persona a cui tutti chiedono. Capacità reale senza riconoscimento formale.
Sviluppatori. Verso ruoli di infrastruttura e piattaforma, con bisogno della metà operativa che non hanno mai ricevuto.
Chi cambia carriera da ruoli operativi in logistica, produzione o utility, dove disciplina di processo e lavoro a turni si trasferiscono direttamente.
Accesso, controllo dei cambiamenti e obblighi di continuità. L'accesso amministrativo ai sistemi di produzione è una posizione ad alto privilegio governata da requisiti di change management, logging e separazione dei compiti, e nei settori regolamentati da framework di controllo specifici. La capacità di backup e ripristino è soggetta a obblighi legali e contrattuali in molti settori, e i backup mai testati hanno ripetutamente fallito quando servivano. Astra Trainer costruisce capacità tecnica e consapevolezza di dove si applicano questi obblighi. Non conferisce alcuna autorizzazione ad accedere a nessun sistema e non sostituisce i requisiti di controllo organizzativo.
Cosa portare a casa
Le astrazioni del cloud hanno spostato l'infrastruttura dietro un'interfaccia senza eliminarla, il che ha reso i guasti più difficili da individuare e più preziose le persone capaci di individuarli.
Risoluzione dei nomi, certificati, orario e instradamento causano una quota sproporzionata dei disservizi perché sono invisibili finché non si guastano e presentano sintomi lontani dalla causa.
Il troubleshooting è un metodo insegnabile più che un talento, e insegnarlo esplicitamente è uno degli interventi tecnici a maggior rendimento disponibili.
Il vero vincolo qui è status e pipeline più che domanda, e l'esternalizzazione ha eliminato i ruoli junior dove si costruiva questa comprensione.
E ogni team cloud, DevOps e sicurezza recluta da questa popolazione. Sottoinvestire qui significa sottoinvestire in tutti loro.
Il cloud ha reso obsolete le competenze di infrastruttura?
No. Ha spostato l'infrastruttura dietro un'interfaccia. Reti, sistemi operativi, risoluzione dei nomi e storage esistono ancora e si guastano ancora, e l'astrazione allontana il guasto dal sintomo, il che rende più difficile la diagnosi.
Perché DNS, certificati e orario causano così tanti disservizi?
Perché tutto dipende da loro, nessuno li possiede, sono invisibili quando funzionano, e i loro guasti producono sintomi in uno strato completamente diverso. La scadenza dei certificati in particolare ha causato ripetuti disservizi gravi in date note con anni di anticipo.
Il troubleshooting si può insegnare?
Sì. Stabilisci cosa è cambiato, definisci l'ambito con precisione, testa lungo il percorso della richiesta, cambia una cosa alla volta, leggi i log a partire dalla prima anomalia invece che dall'ultimo errore, e distingui il ripristino del servizio dalla ricerca della causa radice.
Perché l'infrastruttura è sottovalutata?
Perché si misura dall'assenza di problemi e si nota solo durante i guasti, quindi appare nei budget come costo. Retribuzione e status restano indietro rispetto a ruoli affini, gli investimenti arrivano in modo reattivo dopo gli incidenti, e l'esternalizzazione ha eliminato i ruoli junior che costruivano la competenza.
Chi si converte bene verso ruoli di infrastruttura?
Prima il personale di service desk e supporto, poi i tecnici delle telecomunicazioni verso la rete, il personale militare di comunicazioni, gli elettricisti verso il lavoro di data center, gli amministratori informali, e gli sviluppatori con bisogno della metà operativa.