Al momento della scrittura di questo articolo, una ricerca su un noto sito di lavoro per la parola chiave "Ingegnere di rete" restituiva circa trecento annunci in tutta la Russia. A titolo di confronto, la ricerca per la frase "amministratore di sistema" restituisce quasi 2.5 mila annunci, mentre "ingegnere DevOps" quasi 800.
Significa questo che i professionisti di rete non sono più necessari ai tempi delle nuvole dominanti, di Docker, Kubernetes e del pubblico WiFi sempre presente?
Cerchiamo di capire (c)
Facciamo conoscenza. Mi chiamo Aleksey e sono un professionista di rete.
Ho oltre 10 anni di esperienza nelle reti e oltre 15 anni di lavoro con vari sistemi *nix (ho avuto modo di lavorare sia su Linux che su FreeBSD). Ho lavorato in operatori di telecomunicazioni, in grandi aziende che di solito si definiscono "enterprise", e recentemente lavoro in una fintech "giovane e intraprendente", dove nuvole, DevOps, Kubernetes e altre parole spaventose potrebbero rendere me e i miei colleghi superflui. Un giorno. Forse.
disclaimer: "Nella nostra vita non tutto è sempre e ovunque, ma alcune cose, a volte e in determinati luoghi" (c) Maxim Dorofeev.
Tutto quanto scritto qui può e deve essere considerato come un'opinione personale dell'autore, non pretensiosa di verità assoluta e neanche di una ricerca completa. Tutti i personaggi sono inventati, ogni somiglianza è puramente casuale.
Benvenuti nel mio mondo.
Dove si possono incontrare i networker?
1. Operatori di telecomunicazioni, aziende di servizi e altri integratori. Qui è piuttosto semplice: la rete per loro è un affare. Vendono direttamente la connettività (operatori) o offrono servizi per l'implementazione/manutenzione delle reti dei loro clienti.
L'esperienza qui è vasta, mentre i soldi non abbondano (a meno che tu non sia un direttore o un manager delle vendite di successo). Tuttavia, se ti piacciono le reti e sei solo all'inizio, una carriera nel supporto di un operatore non troppo grande potrebbe essere, anche ora, il punto di partenza ideale (nelle grandi aziende tutto è molto scriptato e c'è poco spazio per la creatività). E le storie di chi riesce a passare da ingegnere di supporto a manager di livello C in pochi anni sono assolutamente reali, anche se rare, per motivi comprensibili. La domanda di personale è sempre presente, poiché il turnover è una realtà. Questo è buono e cattivo allo stesso tempo: ci sono sempre posti vacanti, ma d'altra parte, spesso, i più attivi/intelligenti se ne vanno rapidamente per promozioni o per posizioni più "comfortevoli".
2. Il cosiddetto "enterprise". Non importa se la sua attività principale è legata all'IT o meno. L'importante è che abbia un proprio reparto IT che si occupa della gestione dei sistemi interni dell'azienda, inclusi la rete negli uffici, i canali di comunicazione verso le filiali, e così via. Nelle aziende di questo tipo, le funzioni di un ingegnere di rete possono essere 'complementari' a quelle di un amministratore di sistema (se l'infrastruttura di rete è piccola, o se viene gestita da un fornitore esterno); e l'ingegnere di rete, se presente, può anche occuparsi della telefonia e del SAN (senza entrare nei dettagli). Le retribuzioni variano notevolmente, a seconda della marginalità del business, delle dimensioni dell'azienda e della sua struttura. Ho lavorato con aziende dove i router Cisco erano caricati di lavoro, e con aziende dove la rete era costruita con materiali di fortuna, bastoni e nastro adesivo blu; e i server non venivano mai aggiornati (senza dire che non c'erano riserve previste). L'esperienza in questo ambito è notevolmente inferiore e sarà quasi sicuramente incentrata su un forte vendor-lock o su 'come fare qualcosa dal nulla'. Personalmente, mi è sembrato molto noioso, anche se a molti piace — tutto va abbastanza calmo e prevedibile (se parliamo di grandi aziende), 'dorača-bahato' e così via. Non meno di una volta all'anno qualche grande fornitore annuncia di aver ideato un'altra super mega-sistema che automatizza tutto e che i sistemisti e gli ingegneri di rete possono essere licenziati, lasciando solo un paio di persone a premere pulsanti in un'interfaccia bella. Tuttavia, la realtà è che, anche astrarsi dal costo della soluzione, gli ingegneri di rete non potranno andarsene. Sì, forse, invece della console ci sarà nuovamente un'interfaccia web (ma non per un singolo dispositivo, bensì per un grande sistema che gestisce decine o centinaia di tali dispositivi), ma le conoscenze 'su come tutto è organizzato all'interno' saranno comunque necessarie.
3. Aziende di prodotto, il cui profitto deriva dallo sviluppo (e, spesso, dalla gestione) di qualche software o piattaforma – quel prodotto stesso. Di solito sono piccole e agili, lontane dall'ampiezza delle aziende enterprise e dalla loro burocrazia. Proprio qui si trovano in massa quei famosi devops, kubernetes, docker e altre parole spaventose che renderanno la rete e gli ingegneri di rete un relitto obsoleto.
In cosa si differenzia un network engineer da un sistemista?
Nella percezione delle persone che non provengono dal mondo IT – non ci sono differenze. Entrambi guardano a uno schermo nero e digitano qualche formula magica, talvolta imprecando sottovoce.
Nel linguaggio dei programmatori è solo un dominio di applicazione. Gli amministratori di sistema gestiscono i server, gli amministratori di rete gestiscono gli switch e i router. A volte lo fanno male e tutto smette di funzionare. Beh, in caso di problemi strani, la colpa ricade comunque sui networker. Just because fuck you, that’s why.
In realtà, la principale differenza risiede nell'approccio al lavoro. Probabilmente, tra i professionisti del networking, si riscontra la maggior parte dei sostenitori dell'approccio "Funziona, non toccare!". Di norma, è possibile realizzare un'operazione (all'interno di un singolo fornitore) solo in un modo, tutta la configurazione del dispositivo è qui, a portata di mano. Il costo di un errore è elevato, e a volte molto elevato (ad esempio, può essere necessario percorrere centinaia di chilometri per riavviare un router, e nel frattempo migliaia di persone resteranno senza connessione — una situazione piuttosto comune per un operatore di telecomunicazioni).
A mio avviso, per questo motivo gli ingegneri di rete sono, da un lato, estremamente motivati alla stabilità della rete (e le modifiche sono il principale nemico della stabilità), e dall'altro, le loro conoscenze si approfondiscono più che ampliarsi (non è necessario sapere come configurare decine di diversi demoni; è importante conoscere le tecnologie e la loro implementazione da parte di un determinato produttore di apparecchiature). Per questo motivo, un amministratore di sistema che ha trovato su Internet come configurare un VLAN su Cisco non è ancora un ingegnere di rete. E difficilmente sarà in grado di supportare (e risolvere i problemi) una rete anche solo leggermente complessa in modo efficace.
Ma a cosa serve un network engineer se avete già l'host?
Per un costo aggiuntivo (e se siete un cliente molto importante e preferito — potrebbe anche essere gratuito, «per amicizia»), gli ingegneri del data center configureranno i vostri switch secondo le vostre esigenze e, possibilmente, vi aiuteranno anche a stabilire un peering BGP con i fornitori (se avete la vostra subnet indirizzi ip per l'annuncio).
Il problema principale è che il data center non è il tuo reparto IT, ma un'azienda separata il cui obiettivo è generare profitto. Anche a spese tue, come cliente. Il data center fornisce rack, li alimenta elettricamente e li raffredda, e offre anche una certa connettività «di default» a Internet. Sulla base di questa infrastruttura, il data center può ospitare la tua attrezzatura (colocation), affittarti un server (dedicated server) o fornirti un servizio gestito (come OpenStack o K8s). Tuttavia, il business del data center (di solito) non include l'amministrazione delle infrastrutture dei clienti, perché questo processo è piuttosto laborioso, difficile da automatizzare (mentre in un data center normale è automatizzato tutto ciò che è possibile), e ancor più difficile da uniformare (ogni cliente è unico) ed è generalmente soggetto a lamentele («hai configurato il server per me e ora è andato giù, è tutta colpa tua!!!111»). Pertanto, se il fornitore di hosting ti aiuterà in qualche modo, cercherà di farlo nel modo più semplice e «basic» possibile. Infatti, fare le cose in modo complesso non è vantaggioso, almeno dal punto di vista delle ore di lavoro degli ingegneri di quel fornitore (ma le situazioni possono variare, vedere il disclaimer). Questo non significa che il fornitore di hosting farà necessariamente tutto male. Ma non è affatto certo che farà esattamente ciò di cui avevi realmente bisogno.
Sembrerebbe un aspetto piuttosto ovvio, ma ho incontrato diverse volte nella mia esperienza aziende che iniziavano a fare affidamento sul proprio fornitore di hosting un po' troppo, e questo non portava a nulla di buono. È stato necessario spiegare a lungo e in dettaglio che nessun SLA copre le perdite da inattività (ci sono eccezioni, ma di solito ciò è molto, MOLTO costoso per il cliente) e che il fornitore di hosting non è a conoscenza di ciò che accade nell'infrastruttura dei clienti (eccetto indicatori molto generali). E il fornitore non effettua nemmeno i backup per voi. La situazione è ancora peggiore se avete più di un fornitore di hosting. In caso di problemi tra di loro, di certo non si preoccuperanno di scoprire cosa è realmente andato storto.
In effetti, le motivazioni sono esattamente le stesse che si presentano nella scelta tra "il proprio team di amministratori vs outsourcing". Se i rischi sono stati calcolati, la qualità è soddisfacente e l'azienda è d'accordo, perché non provare? D'altra parte, la rete è uno dei livelli di infrastruttura più fondamentali, e difficilmente vale la pena delegarla a ragazzi esterni, se tutto il resto lo gestite già da soli.
In quali casi è necessario un esperto di rete?
Ora parleremo specificamente delle moderne aziende di prodotto. Con gli operatori e le imprese, la situazione è più o meno chiara: non ci sono stati molti cambiamenti negli ultimi anni e i professionisti di rete sono sempre stati necessari, e lo sono ancora. Ma con quelli che definiamo "giovani e audaci", le cose non sono così chiare. Spesso posizionano completamente la loro infrastruttura nel cloud, quindi non hanno particolarmente bisogno di amministratori, a parte quelli dei cloud, ovviamente. L'infrastruttura, da un lato, è piuttosto semplice nella sua struttura, ma dall'altro è ben automatizzata (ansible/puppet, terraform, ci/cd... insomma, sapete di cosa parlo). Ma anche in questo caso, ci sono situazioni in cui non si può fare a meno di un ingegnere di rete.
Esempio 1, classico
Supponiamo che un'azienda inizi con un server con un indirizzo IP pubblico, posizionato in un data center. Poi il numero di server aumenta a due. Poi a tre… Prima o poi, si presenta la necessità di una rete privata tra i server. Perché il traffico "esterno" è limitato sia in termini di banda (non più di 100 Mbit/s, ad esempio) sia in termini di volume di dati scaricati/inviati al mese (diversi provider hanno tariffe diverse, ma la banda verso il mondo esterno è generalmente molto più costosa rispetto a una rete privata).
L'hosting provider aggiunge schede di rete supplementari ai server e le collega ai suoi switch in un vlan separato. Tra i server si crea una rete locale "flat". Comodo!
Il numero di server cresce, anche il traffico nella rete privata aumenta — backup, repliche, ecc. L'host offre di separarvi in switch dedicati, in modo che non interferiate con gli altri clienti e viceversa. L'host installa alcuni switch e li configura in modo probabilmente da lasciare una rete piatta tra tutti i vostri server. Tutto funziona bene, ma a un certo punto iniziano i problemi: periodicamente aumentano i tempi di latenza tra gli host, nei log ci sono segnalazioni su un numero eccessivo di pacchetti ARP al secondo, e il pentester durante l'audit ha compromesso l'intera vostra rete locale, rompendosi solo un server.
Cosa bisogna fare?
Dividere la rete in segmenti: VLAN. Configurare ogni VLAN con la propria attribuzione degli indirizzi e definire un gateway che instraderà il traffico tra le reti. Sul gateway, impostare le ACL per limitare l'accesso tra i segmenti o, in alternativa, posizionare un firewall separato.
Esempio 1, continuazione
I server sono connessi alla rete locale con un solo cavo. Gli switch nelle rack sono in qualche modo collegati tra loro, ma in caso di guasti in una rack, anche tre rack vicine possono scollegarsi. Esistono schemi, ma ci sono dubbi sulla loro attualità. Ogni server ha il proprio indirizzo pubblico, fornito dal fornitore di hosting e associato alla rack. Pertanto, nel caso di spostamento del server, è necessario cambiare l'indirizzo.
Cosa bisogna fare?
Collegare i server tramite LAG (Link Aggregation Group) con due cavi agli switch nella rack (anch'essi devono essere ridondanti). Riservare le connessioni tra le rack e modificarle in un layout a "stella" (o il moderno CLOS), in modo che il guasto di una rack non influisca sulle altre. Scegliere rack "centrali" in cui sarà collocato il nucleo di rete, e dove saranno connesse le altre rack. Inoltre, sistemare l'indirizzamento pubblico, richiedere al fornitore di hosting (o a un RIR, se possibile) una subnet da annunciare autonomamente (o tramite il fornitore di hosting) al mondo.
Può un "normale" amministratore di sistema senza profondi conoscimenti di rete fare tutto questo? Non ne sono sicuro. Lo farà l'hoster? Potrebbe, ma avrai bisogno di un briefing abbastanza dettagliato, che dovrà essere redatto da qualcuno. E poi dovrai controllare che tutto sia stato fatto correttamente.
Esempio 2. Cloud
Supponiamo che tu abbia una VPC in qualche cloud pubblico. Per accedere dalla tua rete aziendale o dalla parte on-prem della tua infrastruttura alla rete interna della VPC, devi configurare una connessione tramite IPSec o una linea dedicata. Da un lato, IPSec è più economico, poiché non è necessario acquistare hardware aggiuntivo; puoi configurare un tunnel tra il tuo server con indirizzo pubblico e il cloud. Tuttavia, ci sono ritardi, prestazioni limitate (poiché il canale deve essere crittografato) e una connettività non garantita (poiché l'accesso avviene tramite internet normale).
Cosa bisogna fare?
Attivare una connessione tramite un canale dedicato (ad esempio, da AWS è chiamato Direct Connect). Per fare ciò, è necessario trovare un partner operativo che ti collega, determinare il punto di accesso più vicino a te (sia per il tuo operatore sia per l'operatore cloud), e infine configurare tutto. È possibile fare tutto questo senza un ingegnere di rete? Sicuramente sì. Ma come risolvere eventuali problemi senza di lui è già meno chiaro.
Possono sorgere anche problemi di connettività tra i cloud (se hai una configurazione multi-cloud) o problemi di latenza tra diverse regioni, e così via. Naturalmente, ci sono molti strumenti attualmente disponibili che aumentano la trasparenza di ciò che accade nel cloud (come Thousand Eyes), ma questi sono strumenti per un ingegnere di rete, non una loro sostituzione.
Potrei fornire ancora un'altra decina di esempi dalla mia esperienza, ma penso sia chiaro che, a partire da un certo livello di sviluppo dell'infrastruttura, ci deve essere una persona nel team (meglio se più di una) che sa come funziona la rete, può configurare l'equipment di rete e risolvere eventuali problemi se sorgono. Fidati, avrà di che occuparsi.
Cosa deve sapere un network engineer?
Non è affatto necessario (e anzi, a volte può essere controproducente) che un ingegnere di rete si occupi esclusivamente delle reti e nient'altro. Anche senza considerare l'opzione di un'infrastruttura che vive quasi interamente nel cloud pubblico (che, in fin dei conti, sta diventando sempre più popolare), e prendendo in esempio i cloud on-premise o privati, basarsi esclusivamente su "conoscenze a livello CCNP" non basta.
Oltre alle reti stesse, c'è un campo praticamente infinito da esplorare, anche se ci si concentra solo su un singolo settore (reti di provider, enterprise, data center, WiFi…).
Naturalmente, molti di voi penseranno a Python e alla "network automation", ma questo è solo un requisito necessario, ma non sufficiente. Perché un ingegnere di rete possa "integrarsi con successo nel team", deve saper comunicare allo stesso modo con sviluppatori e colleghi amministratori/devops. Cosa significa?
- deve saper lavorare non solo in Linux come utente, ma anche amministrarlo, almeno a livello di sysadmin junior: installare il software necessario, riavviare un servizio che è andato in crash, scrivere un semplice unit di systemd.
- Comprendere, anche solo in linea generale, come funziona lo stack di rete in Linux, come è strutturata la rete nei hypervisor e nei container (lxc / docker / kubernetes).
- Naturalmente, saper lavorare con ansible/chef/puppet o un altro sistema SCM.
- È importante menzionare separatamente l'SDN e le reti per i cloud privati (ad esempio, TungstenFabric o OpenvSwitch). Questo è un altro grande ambito di conoscenza.
In sintesi, ho descritto un tipico specialista di tipo T (come si usa dire oggi). Sembrerebbe nulla di nuovo, tuttavia, dalla mia esperienza durante i colloqui, molti ingegneri di rete non possono vantarsi di avere conoscenze su almeno due argomenti della lista sopra. In pratica, la mancanza di conoscenze in "settori correlati" rende molto difficile non solo la comunicazione con i colleghi, ma anche la comprensione delle esigenze che il business richiede alla rete, considerata la parte infrastrutturale più basica del progetto. Senza questa comprensione, diventa più difficile sostenere la propria opinione in modo argomentato e "venderla" al business.
D'altra parte, l'abitudine di "capire come funziona il sistema" fornisce ai networker un notevole vantaggio rispetto ai vari "specialisti polivalenti", che conoscono le tecnologie grazie a articoli su Habr/Medium e chat su Telegram, ma non hanno assolutamente idea dei principi su cui si basa un determinato software. E come è noto, la conoscenza di alcune regole può sostituire con successo la conoscenza di molti fatti.
Conclusioni, o semplicemente TL;DR
- L'amministratore di rete (proprio come il DBA o l'ingegnere VoIP) è uno specialista piuttosto specifico (a differenza degli admin di sistema/devops/SRE), la cui necessità non si presenta immediatamente (e in realtà potrebbe non presentarsi affatto per un lungo periodo). Ma quando si presenta, è difficile sostituirlo con l'esperienza esterna (outsourcing o normali admin generalisti, che "si occupano anche della rete"). Ciò è un po' più triste: la domanda per tali specialisti è bassa e, in una compagnia di 800 programmatori e 30 devops/admin, potrebbero esserci solo due esperti di rete che svolgono perfettamente il loro lavoro. In altre parole, il mercato è stato e rimane molto ristretto, e per quanto riguarda buone retribuzioni — è ancora minore.
- D'altra parte, un buon esperto di rete nel mondo moderno deve conoscere non solo le reti (e come automatizzare la loro configurazione), ma anche come interagiscono con i sistemi operativi e il software che opera su di esse. Senza questa conoscenza, sarà estremamente difficile capire cosa chiedono i colleghi e comunicare (in modo ragionevole) le proprie esigenze e requisiti a loro.
- Non esiste il cloud, è solo il computer di qualcun altro. È importante comprendere che l'uso di cloud pubblici/privati o di servizi di hosting 'chiavi in mano' non elimina il fatto che la tua applicazione utilizza ancora una rete e i problemi di rete influenzeranno il funzionamento della tua applicazione. È una tua scelta dove posizionare il centro di competenza che si occuperà della rete del tuo progetto.
Fonte: habr.com
