Al momento della scrittura di questo articolo, la ricerca su un popolare sito di lavoro con la frase "Ingegnere di rete" restituiva circa trecento annunci in tutta la Russia. In confronto, la ricerca con la frase "amministratore di sistema" restituisce quasi 2.5 mila annunci, mentre "ingegnere DevOps" quasi 800.
Significa questo che i professionisti delle reti non sono più necessari ai tempi delle nuvole vincenti, di Docker, di Kubernetes e del Wi-Fi pubblico onnipresente?
Diamo un'occhiata (c)
Piacere di conoscervi. Mi chiamo Alexey e sono un professionista delle reti.
Da più di 10 anni mi occupo di reti e da oltre 15 anni lavoro con diversi sistemi *nix (ho avuto modo di lavorare sia con Linux che con FreeBSD). Ho lavorato per operatori di telecomunicazioni, grandi aziende considerate "enterprise", e recentemente lavoro in una startup fintech "giovane e sfacciata", dove ci sono nuvole, DevOps, Kubernetes e altri termini spaventosi che sicuramente renderanno me e i miei colleghi non necessari. Un giorno. Forse.
dichiarazione: "Nella nostra vita non tutto è sempre e ovunque, e alcune cose, a volte e in alcuni luoghi" (c) Maxim Dorofeev.
Tutto quanto scritto qui di seguito può e deve essere considerato un'opinione personale dell'autore, che non pretende di essere la verità definitiva e nemmeno uno studio completo. Tutti i personaggi sono frutto dell'immaginazione, ogni coincidenza è puramente casuale.
Benvenuti nel mio mondo.
Dove si possono incontrare i professionisti delle reti?
1. Operatori di telecomunicazioni, aziende di servizi e altri integratori. Qui è tutto semplice: la rete per loro è un business. Vendono direttamente connettività (operatori) o forniscono servizi per l'avvio / la manutenzione delle reti dei loro clienti.
Ci sono molte opportunità, ma pochi soldi (se non sei un direttore o un manager vendite di successo). Tuttavia, se ti piacciono le reti e sei solo all'inizio del tuo percorso, una carriera nel supporto di un operatore non molto grande sarà, anche adesso, il punto di partenza ideale (in quelli federali tutto è molto scriptato e c'è poco spazio per la creatività). Inoltre, le storie su come si può crescere da ingegnere di turno a manager C-level in pochi anni sono del tutto reali, anche se rare, per motivi comprensibili. La necessità di personale c'è sempre, perché il turnover è un fattore reale. Questo è sia positivo che negativo allo stesso tempo: ci sono sempre offerte di lavoro, ma d'altra parte spesso i più attivi/intelligenti se ne vanno abbastanza rapidamente, sia per promozioni che per posti più "caldi".
2. Presunto "enterprise". Non importa se la sua attività principale sia legata all'IT o meno. L'importante è che abbia un proprio reparto IT, che si occupa di garantire il funzionamento dei sistemi interni dell'azienda, tra cui rete negli uffici, canali di comunicazione verso le filiali, ecc. Le funzioni di un ingegnere di rete in tali aziende possono essere svolte
3. Aziende produttrici, il cui profitto è generato dallo sviluppo (e, spesso, dall'operazione) di qualche software o piattaforma — proprio quel prodotto. Di solito sono piccole e agili, lontane anni luce dalle dimensioni delle grandi imprese e dalla loro burocratizzazione. È in questo contesto che si trovano in gran numero DevOps, Kubernetes, Docker e altri termini misteriosi, che renderanno sicuramente le reti e gli ingegneri di rete un residuo superfluo.
Qual è la differenza tra un ingegnere di rete e un sistemista?
Nella comprensione delle persone che non provengono dall'IT — niente. Entrambi guardano uno schermo nero e scrivono qualche tipo di formule, a volte imprecando sottovoce.
Nella comprensione dei programmatori — a meno che non si tratti di un'area specifica. Gli amministratori di sistema gestiscono i server, i tecnici di rete gestiscono gli switch e i router. A volte gestiscono male e tutto va in crash. Beh, in caso di stranezze è colpa anche dei tecnici di rete. Giusto perché vaffanculo, ecco perché.
In realtà, la principale differenza è l'approccio al lavoro. Probabilmente, tra i tecnici di rete si trovano più sostenitori dell'approccio 'Se funziona, non toccarlo!'. Solitamente, per realizzare una certa cosa (all'interno di un unico vendor) si può fare solo in un modo, tutta la configurazione della scatola — ecco, sta nel palmo della mano. Il costo dell'errore è alto, a volte anche molto alto (ad esempio, sarà necessario percorrere diverse centinaia di chilometri per riavviare un router, mentre nel frattempo migliaia di persone resteranno senza connessione — una situazione abbastanza comune per un operatore di rete).
A mio avviso, è proprio per questo che gli ingegneri di rete, da un lato, sono estremamente motivati alla stabilità della rete (e i cambiamenti sono il principale nemico della stabilità), e dall'altro, le loro conoscenze vanno più in profondità che in ampiezza (non è necessario saper configurare decine di diversi demoni, è necessario conoscere le tecnologie e la loro implementazione presso un determinato produttore di hardware). È per questo motivo che un amministratore di sistema che ha googlato come configurare una VLAN su Cisco non è ancora un tecnico di rete. E difficilmente sarà in grado di gestire (e risolvere problemi) una rete abbastanza complessa in modo efficace.
Ma a cosa serve un tecnico di rete, se hai un hoster?
Per una somma extra (e se sei un cliente molto grande e amato — potrebbe anche essere gratis, 'per amicizia') gli ingegneri del data center configureranno i tuoi switch per le tue esigenze e, forse, ti aiuteranno persino a stabilire una connessione BGP con i provider (se hai la tua subnet di indirizzi IP da annunciare).
Il problema principale è che il data center non è il vostro reparto IT, ma un'azienda separata il cui obiettivo è generare profitto. Anche a spese di voi come cliente. Il data center fornisce rack, garantisce elettricità e refrigerazione, e offre anche una certa "connettività predefinita" a Internet. Sulla base di questa infrastruttura, il data center può ospitare la vostra attrezzatura (colocation), affittarvi un server (dedicated server) o fornire servizi gestiti (ad esempio, OpenStack o K8s). Ma l'amministrazione dell'infrastruttura dei clienti non è (di solito) il business del data center, perché questo processo è piuttosto dispendioso in termini di risorse, non si automatizza bene (e in un data center normale tutto ciò che è possibile è automatizzato), si unifica ancora peggio (ogni cliente è unico) e comporta, in generale, possibili contestazioni ("mi avete configurato il server, ma ora è andato giù, è tutta colpa vostra!!!111"). Pertanto, se l'hoster vi aiuterà in qualcosa, cercherà di farlo nel modo più semplice e "standardizzato" possibile. Infatti, fare le cose in modo complesso non è vantaggioso, almeno dal punto di vista delle risorse degli ingegneri di questo stesso hoster (ma le situazioni possono variare, si veda il disclaimer). Questo non significa che l'hoster farà necessariamente tutto male. Ma non è affatto garantito che farà esattamente ciò di cui avevate realmente bisogno.
Sembra una cosa piuttosto ovvia, ma nella mia esperienza ho incontrato più volte aziende che iniziavano a fare troppo affidamento sul proprio provider di hosting, più di quanto fosse opportuno, e ciò non portava a nulla di buono. Ho dovuto spiegare a lungo e in dettaglio che nessun SLA coprirà le perdite da downtime (ci sono eccezioni, ma di solito sono molto, MOLTO costose per il cliente) e che l'hoster non è affatto a conoscenza di ciò che sta accadendo nell'infrastruttura dei clienti (a parte indicatori molto generali). Inoltre, l'hoster non effettua backup per conto vostro. È ancora peggio se avete più di un hoster. In caso di problemi tra di loro, di certo non si metteranno a chiarire per voi cosa sia andato storto.
In effetti, i motivi qui sono gli stessi che nella scelta tra «il proprio team di amministratori vs outsourcing». Se i rischi sono stati valutati, la qualità è soddisfacente e l'azienda non è contraria — perché non provare? D'altra parte, la rete è uno degli strati più fondamentali dell'infrastruttura, e difficilemente vale la pena affidarla a persone esterne, se tutto il resto è già sotto il tuo controllo.
Quando è necessario un ingegnere di rete?
In seguito parleremo specificamente delle aziende produttrici moderne. Con gli operatori e l'enterprise è tutto piuttosto chiaro — lì non è cambiato molto negli ultimi anni, e gli ingegneri di rete erano necessari in passato, lo sono ancora adesso. Ma con quelle «giovani e audaci» le cose non sono così univoche. Spesso, esse collocano interamente la loro infrastruttura nelle nuvole, quindi non hanno nemmeno troppi amministratori — a parte gli amministratori delle stesse nuvole, ovviamente. L'infrastruttura, da un lato, è abbastanza semplice nella sua struttura, dall'altro è ben automatizzata (ansible/puppet, terraform, ci/cd... insomma, lo sappiamo). Ma anche qui 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, collocato in un data center. Poi i server diventano due. Poi di più... Prima o poi, sorge la necessità di una rete privata tra i server. Perché il traffico "esterno" è limitato sia in termini di banda (non più di 100Mbit/s, ad esempio) che di volume di dati scaricati/inviati al mese (ogni provider ha tariffe diverse, ma la banda verso l'esterno è generalmente molto più costosa rispetto a una rete privata).
Il provider aggiunge ai server schede di rete aggiuntive e le collega ai propri switch in un VLAN separato. Tra i server appare una rete LAN "flat". Comodo!
Il numero di server sta aumentando, il traffico nella rete privata anche — backup, repliche, ecc. L'hoster propone di separarvi su switch dedicati, in modo che non disturbiate altri clienti e viceversa. L'hoster installa alcuni switch e li configura in qualche modo — con tutta probabilità lasciando una rete piatta tra tutti i vostri server. Tutto funziona bene, ma a un certo punto iniziano i problemi: periodicamente le latenze tra gli host aumentano, nei log ci sono avvisi riguardo a un numero eccessivo di pacchetti arp al secondo, e il pentester durante l'audit ha avuto la meglio su tutta la vostra rete locale, compromettendo un solo server.
Cosa bisogna fare?
Dividere la rete in segmenti — vlan. Configurare un indirizzamento specifico per ciascun vlan, assegnare un gateway che traferirà il traffico tra le reti. Configurare acl sul gateway per limitare l'accesso tra i segmenti, oppure posizionare un firewall separato.
Esempio 1, continuazione
I server sono connessi alla rete locale tramite un cavo. Gli switch nelle rack sono collegati tra loro in qualche modo, ma in caso di guasto in un rack si scollegano anche tre rack vicini. Ci sono schemi esistenti, ma ci sono dubbi sulla loro attualità. Ogni server ha un proprio indirizzo pubblico, fornito dall'hoster e associato al rack. Cioè, spostando il server, è necessario cambiare indirizzo.
Cosa bisogna fare?
Collegare i server tramite LAG (Link Aggregation Group) con due cavi agli switch nel rack (è necessario riservarli anche). Riservare le connessioni tra i rack, riconfigurandole in una “stella” (o il più attuale CLOS), affinché il guasto di un rack non influisca sugli altri. Definire rack “centrali” in cui si troverà il nucleo di rete, e dove verranno collegati altri rack. Inoltre, mettere ordine nell'indirizzamento pubblico, ottenere dall'hoster (o dal RIR, se possibile) un sottoinsieme che sarà annunciato nel mondo in modo autonomo (o tramite l'hoster).
Può tutto questo essere fatto da un “normale” amministratore di sistema, senza conoscenze approfondite in reti? Non sono sicuro. Lo farà l'hoster? Potrebbe farlo, ma avrete bisogno di un capitolato molto dettagliato che dovrà essere redatto da qualcuno, e poi controllare che tutto sia stato fatto correttamente.
Esempio 2. Cloud
Supponiamo di avere un VPC in qualche cloud pubblico. Per accedere dall'ufficio o dalla parte on-prem della infrastruttura alla rete locale all'interno del VPC, è necessario configurare una connessione tramite IPSec o un circuito dedicato. Da un lato, l'IPSec è più economico, poiché non è necessario acquistare hardware aggiuntivo e si può configurare un tunnel tra il server con indirizzo pubblico e il cloud. Tuttavia, ci sono ritardi, prestazioni limitate (poiché il canale deve essere cifrato) e una connettività non garantita (poiché l'accesso avviene attraverso l'ordinario internet).
Cosa bisogna fare?
Stabilire una connessione tramite circuito dedicato (ad esempio, da AWS è chiamato Direct Connect). Per fare ciò, trovare un operatore partner che vi colleghi, decidere il punto di accesso più vicino a voi (sia dall'operatore che dal cloud) e, infine, configurare tutto. È possibile fare tutto questo senza un ingegnere di rete? Sicuramente sì. Ma come si risolvono i problemi in sua assenza è già meno chiaro.
Possono anche sorgere problemi di accessibilità tra i cloud (se avete un multicloud) o problemi di latenza tra diversi regioni, ecc. Certamente, sono stati sviluppati molti strumenti che aumentano la trasparenza di ciò che sta accadendo nel cloud (lo stesso Thousand Eyes), ma questi sono strumenti per il tecnico di rete, non una sua sostituzione.
Potrei anche elencare altri dieci esempi dalla mia pratica, ma penso sia chiaro che in un team, a partire da un certo livello di sviluppo dell'infrastruttura, dovrebbe esserci una persona (e meglio più di una) che sa come funziona la rete, può configurare l'equipaggiamento di rete e comprendere i problemi se sorgono. Credetemi, avrà molto da fare.
Cosa deve sapere un ingegnere di rete?
Non è affatto necessario (e a volte persino dannoso) che un ingegnere di rete si occupi esclusivamente della rete e di nulla altro. Anche se non prendiamo in considerazione l'infrastruttura che vive quasi completamente nel cloud pubblico (che, in ogni caso, sta diventando sempre più popolare), e prendiamo ad esempio on-premise o cloud privati, dove non si possono andare lontani solo con "conoscenze a livello CCNP".
Oltre alle reti stesse, c'è un campo infinito per l'apprendimento, anche se ci si concentra solo su una particolare direzione (reti di provider, enterprise, data center, wifi...)
Naturalmente, molti di voi penseranno subito a Python e ad altra «network automation», ma questa è solo una condizione necessaria, non sufficiente. Perché un ingegnere di rete possa «integrarsi con successo nel team», deve essere in grado di parlare la stessa lingua sia con gli sviluppatori che con i colleghi amministratori/devops. Cosa significa questo?
- Essere in grado non solo di lavorare in Linux come utente, ma anche di amministrarlo, almeno a livello di amministratore junior: installare il software necessario, riavviare un servizio caduto, scrivere un semplice systemd-unit.
- Comprendere (almeno 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 con un altro sistema SCM.
- È necessario dedicare una nota separata a SDN e reti per il cloud privato (ad esempio, TungstenFabric o OpenvSwitch). Questo rappresenta un altro vasto campo di conoscenze.
In breve, ho descritto il tipico specialista T-shape (come si suole dire oggi). Non sembra nulla di nuovo, tuttavia, dalle esperienze dei colloqui, non tutti gli ingegneri di rete possono vantare conoscenze su almeno due argomenti della lista sopra. Nella 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 l'infrastruttura a livello più basso del progetto. E senza questa comprensione diventa più difficile sostenere argomentatamente il proprio punto di vista e «venderlo» al business.
D'altra parte, quell'abitudine a «capire come funziona il sistema» offre ai professionisti di rete un notevole vantaggio rispetto ai vari «specialisti a tutto tondo», che conoscono le tecnologie grazie ad articoli su Habr/MEDIUM e chat su Telegram, ma non hanno idea dei principi su cui si basa un certo software. E conoscere alcune regole, come è noto, sostituisce efficacemente la conoscenza di molti fatti.
Conclusioni, o semplicemente TL;DR
- L'amministratore di rete (come un DBA o un ingegnere VoIP) è uno specialista di profilo piuttosto ristretto (a differenza degli amministratori di sistema/devops/SRE), la cui necessità non sorge immediatamente (e in realtà potrebbe non sorgere per molto tempo). Ma se una volta sorge, è difficile sostituirlo con esperienza esterna (outsourcing o normali amministratori a profilo ampio, "che si occupano anche della rete"). Ciò che è un po' più triste è che la necessità di tali specialisti è bassa e, in una società di 800 programmatori e 30 devops/amministratori potrebbero esserci solo due reti di cui si occupano splendidamente delle loro responsabilità. Cioè, il mercato è stato e rimane piuttosto e piuttosto piccolo e, per quanto riguarda uno stipendio decente, è addirittura più ridotto.
- D'altra parte, un buon specialista di rete nel mondo moderno deve sapere non solo le reti (e come automatizzarne la configurazione), ma anche come interagiscono con i sistemi operativi e il software che girano su queste reti. Senza questo, sarà estremamente difficile capire cosa chiedono i tuoi colleghi e comunicare (in modo giustificato) le tue richieste/esigenze a loro.
- Non esiste un cloud, è solo un computer di qualcun altro. Bisogna capire che l'uso di cloud pubblici/privati o servizi di hosting "che fanno tutto per voi" non annulla il fatto che la vostra applicazione utilizza ancora una rete e i problemi con essa influenzeranno il funzionamento della vostra applicazione. La vostra scelta è dove si troverà il centro di competenza che sarà responsabile della rete del vostro progetto.
Fonte: habr.com
