Al momento della stesura di questo articolo, una ricerca su un popolare sito di lavoro con la frase “Ingegnere di rete” ha restituito circa trecento posti vacanti in tutta la Russia. Per fare un confronto, la ricerca della frase "amministratore di sistema" restituisce quasi 2.5 mila posti vacanti e "ingegnere DevOps" - quasi 800.
Ciò significa forse che i networker non sono più necessari in tempi di cloud vittoriosi, Docker, Kubernetes e Wi-Fi pubblico onnipresente?
Scopriamolo (c)
È tempo di familiarizzare. Mi chiamo Alexey e sono un networker.
Sono coinvolto nelle reti da più di 10 anni e lavoro con vari sistemi *nix da più di 15 anni (ho avuto la possibilità di armeggiare sia con Linux che con FreeBSD). Ho lavorato in operatori di telecomunicazioni, grandi aziende considerate "enterprise", e recentemente ho lavorato nel fintech "giovane e audace", dove cloud, devops, kubernetes e altre parole spaventose che renderanno sicuramente inutili me e i miei colleghi . Un giorno. Forse.
disclaimer: "Nella nostra vita, non tutto è sempre e ovunque, ma qualcosa, a volte in alcuni punti" (c) Maxim Dorofeev.
Tutto ciò che è scritto di seguito può e deve essere considerato l'opinione personale dell'autore, che non pretende di essere la verità ultima e nemmeno uno studio a tutti gli effetti. Tutti i personaggi sono fittizi, tutte le coincidenze sono casuali.
Benvenuto nel mio mondo.
Dove puoi incontrare i networker?
1. Operatori di telecomunicazioni, società di servizi e altri integratori. Qui tutto è semplice: la rete per loro è un business. Vendono direttamente connettività (operatori) o forniscono servizi per il lancio/mantenimento delle reti dei propri clienti.
C'è molta esperienza qui, ma non molti soldi (a meno che tu non sia un direttore o un responsabile delle vendite di successo). Eppure, se ti piacciono le reti, e sei solo all'inizio del tuo percorso, una carriera a supporto di qualche operatore non molto grande sarà, anche adesso, un punto di partenza ideale (in quelle federali è tutto molto sceneggiato, e lì c'è poco spazio per la creatività). Ebbene, anche le storie su come si può passare da ingegnere in servizio in pochi anni a manager di livello C sono abbastanza reali, sebbene rare, per ovvie ragioni. C'è sempre bisogno di personale, perché c'è turnover. Questo è allo stesso tempo un bene e un male - ci sono sempre posti vacanti, d'altra parte - spesso i più attivi/intelligenti partono rapidamente per una promozione o verso altri posti "più caldi".
2. Condizionale “impresa”. Non importa se la sua attività principale è legata all'IT o meno. La cosa principale è che dispone di un proprio reparto IT, che garantisce il funzionamento dei sistemi interni dell’azienda, compresa la rete negli uffici, i canali di comunicazione con le filiali, ecc. Le funzioni di un ingegnere di rete in tali aziende possono essere svolte "part-time" da un amministratore di sistema (se l'infrastruttura di rete è piccola o è gestita da un appaltatore esterno), e uno specialista di rete, se presente, può a sua volta allo stesso tempo occuparsi della telefonia e della SAN (non va bene). Pagano diversamente: dipende in gran parte dalla redditività dell'azienda, dalle dimensioni dell'azienda e dalla struttura. Ho lavorato con aziende in cui i sistemi Cisco venivano regolarmente “caricati in barili”, e con aziende in cui la rete era costruita con feci, bastoncini e nastro blu, e i server non venivano mai aggiornati (inutile dire che non venivano nemmeno fornite riserve) . C’è molta meno esperienza qui, e quasi certamente riguarderà l’area del rigido vincolo del fornitore, o “come creare qualcosa dal nulla”. Personalmente, l'ho trovato estremamente noioso, anche se piace a molte persone: tutto è abbastanza misurato e prevedibile (se parliamo di grandi aziende), "dorakha-bahato", ecc. Almeno una volta all'anno, alcuni dei principali fornitori affermano di aver escogitato un altro mega-super-duper sistema che automatizzerà tutto ora e tutti gli amministratori di sistema e i networker potranno essere dispersi, lasciando un paio a premere i pulsanti in una bellissima interfaccia. La realtà è che, anche ignorando il costo della soluzione, i networker non andranno da nessuna parte da lì. Sì, forse al posto della console ci sarà di nuovo un'interfaccia web (ma non un componente hardware specifico, ma un grande sistema che gestisce decine e centinaia di tali componenti hardware), ma la conoscenza di "come funziona tutto all'interno" sarà comunque essere necessario.
3. Società prodotto, il cui profitto deriva dallo sviluppo (e, spesso, dal funzionamento) di alcuni software o piattaforme: quello stesso prodotto. Di solito sono piccoli e agili, sono ancora lontani dalle dimensioni delle imprese e dalla loro burocratizzazione. È qui che si trovano in massa quelle stesse devops, cubers, docker e altre parole terribili, che renderanno sicuramente la rete e gli ingegneri di rete un rudimento inutile.
In cosa differisce un networker da un amministratore di sistema?
Nella comprensione delle persone non IT - niente. Entrambi guardano lo schermo nero e scrivono alcuni incantesimi, a volte imprecando in silenzio.
Nella comprensione dei programmatori, forse per area tematica. Gli amministratori di sistema amministrano i server, i networker amministrano switch e router. A volte l'amministrazione è pessima e tutto crolla per tutti. Ebbene, se succede qualcosa di strano, la colpa è anche dei networker. Solo perché vaffanculo, ecco perché.
In effetti, la differenza principale è l'approccio al lavoro. Forse è proprio tra i networker che si trovano i maggiori sostenitori dell’approccio “Se funziona, non toccarlo!”. Di norma, qualcosa può essere fatto (all'interno di un fornitore) in un solo modo; l'intera configurazione della scatola è proprio lì, nel palmo della tua mano. Il costo di un errore è elevato, e talvolta molto elevato (ad esempio, dovrai percorrere diverse centinaia di chilometri per riavviare il router e in questo momento diverse migliaia di persone rimarranno senza comunicazione - una situazione abbastanza comune per un operatore di telecomunicazioni) .
A mio parere, questo è il motivo per cui gli ingegneri di rete, da un lato, sono estremamente motivati per la stabilità della rete (e il cambiamento è il principale nemico della stabilità), e dall'altro, la loro conoscenza va più in profondità che in ampiezza (non si è necessario essere in grado di configurare decine di demoni diversi, è necessario conoscere le tecnologie e la loro implementazione da parte di uno specifico produttore di apparecchiature). Ecco perché un amministratore di sistema che ha cercato su Google come registrare una vlan su un sistema Cisco non è ancora un networker. Ed è improbabile che riesca a supportare efficacemente (oltre a risolvere i problemi) una rete più o meno complessa.
Ma perché hai bisogno di un networker se hai un hoster?
Per soldi aggiuntivi (e se sei un cliente molto grande e amato, magari anche gratuitamente, "come amico"), gli ingegneri del data center configureranno i tuoi switch in base alle tue esigenze e forse ti aiuteranno anche a stabilire un'interfaccia BGP con i provider (se disponi di una propria sottorete di indirizzi IP per l'annuncio).
Il problema principale è che il data center non è il tuo dipartimento IT, è un'azienda separata il cui obiettivo è realizzare un profitto. Anche a spese tue come cliente. Il data center fornisce rack, fornisce loro elettricità e freddo e fornisce anche una connettività "predefinita" a Internet. Sulla base di questa infrastruttura, il data center può ospitare la tua attrezzatura (colocation), noleggiarti un server (server dedicato) o fornire un servizio gestito (ad esempio OpenStack o K8s). Ma l'attività di un data center (di solito) non è l'amministrazione dell'infrastruttura del cliente, perché questo processo è piuttosto laborioso, scarsamente automatizzato (e in un normale data center tutto ciò che è possibile è automatizzato), unificato ancora peggio (ogni client è individuale) e generalmente carico di lamentele (“mi dici che il server era configurato, ma ora è andato in crash, è tutta colpa tua!!!111”). Pertanto, se l'hoster ti aiuta con qualcosa, cercherà di renderlo il più semplice e conveniente possibile. Perché farlo difficile non è redditizio, almeno dal punto di vista del costo della manodopera degli ingegneri di questo stesso hoster (ma le situazioni sono diverse, vedi disclaimer). Ciò non significa che l’hoster farà necessariamente tutto male. Ma non è affatto un dato di fatto che farà esattamente ciò di cui hai veramente bisogno.
Sembrerebbe che la cosa sia abbastanza ovvia, ma più volte nella mia pratica ho riscontrato il fatto che le aziende hanno iniziato a fare affidamento sul proprio provider di hosting un po' più del dovuto, e questo non ha portato a nulla di buono. Ho dovuto spiegare a lungo e in dettaglio che nessuno SLA coprirebbe le perdite derivanti dai tempi di inattività (ci sono delle eccezioni, ma di solito è molto, MOLTO costoso per il cliente) e che l'hoster non è affatto consapevole di ciò che sta accadendo in l'infrastruttura dei clienti (ad eccezione di indicatori molto generali). E l'hoster non esegue nemmeno i backup per te. La situazione è ancora peggiore se hai più di un hoster. In caso di problemi tra loro, sicuramente non scopriranno per te cosa è andato storto.
In realtà, le motivazioni qui sono esattamente le stesse di quando si sceglie “team amministrativo interno o esternalizzazione”. Se i rischi sono calcolati, la qualità è soddisfacente e al business non importa, perché non provarlo. D’altra parte, la rete è uno degli strati più elementari dell’infrastruttura e non vale la pena lasciarla a persone esterne se supporti già tutto il resto da solo.
In quali casi è necessario un networker?
Successivamente parleremo specificamente delle moderne aziende alimentari. Con gli operatori e le imprese tutto è chiaro, più o meno: lì è cambiato poco negli ultimi anni e i networker erano necessari prima e sono necessari ora. Ma con quegli stessi “giovani e audaci” le cose non sono così chiare. Spesso collocano l'intera infrastruttura nei cloud, quindi non hanno nemmeno bisogno di amministratori, ad eccezione degli amministratori di quegli stessi cloud, ovviamente. L'infrastruttura, da un lato, è abbastanza semplice nel design, dall'altro è ben automatizzata (ansible/puppet, terraform, ci/cd... beh, lo sai). 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, situato in un data center. Poi ci sono due server. E poi ancora... Prima o poi ci sarà bisogno di una rete privata tra i server. Poiché il traffico “esterno” è limitato sia dalla larghezza di banda (non più di 100 Mbit/s per esempio) sia dal volume di download/upload al mese (diversi hoster hanno tariffe diverse, ma la larghezza di banda verso il mondo esterno è solitamente molto più costosa di un rete privata).
L'hoster aggiunge ulteriori schede di rete ai server e le include nei loro switch in una vlan separata. Tra i server viene visualizzata un'area locale "piatta". Comodo!
Il numero di server cresce e cresce anche il traffico sulla rete privata: backup, repliche, ecc. L'hoster si offre di spostarti in switch separati in modo che tu non interferisca con altri client e loro non interferiscano con te. L'hoster installa alcuni switch e in qualche modo li configura, molto probabilmente lasciando una rete piatta tra tutti i tuoi server. Tutto funziona bene, ma a un certo punto iniziano i problemi: i ritardi tra gli host aumentano periodicamente, i log lamentano troppi pacchetti arp al secondo e durante un audit il pentester ha fottuto l'intera rete locale, rompendo solo un server.
Cosa dovrei fare?
Dividi la rete in segmenti: vlan. Configura il tuo indirizzamento in ciascuna vlan, seleziona un gateway che trasferirà il traffico tra le reti. Configura ACL sul gateway per limitare l'accesso tra i segmenti o addirittura installa un firewall separato nelle vicinanze.
Esempio 1, continua
I server sono collegati alla LAN con un cavo. Gli interruttori nei rack sono in qualche modo collegati tra loro, ma se si verifica un incidente in un rack, altri tre adiacenti cadono. Gli schemi esistono, ma ci sono dubbi sulla loro rilevanza. Ogni server ha il proprio indirizzo pubblico, che viene rilasciato dall'hoster ed è legato al rack. Quelli. Quando si sposta un server, è necessario modificare l'indirizzo.
Cosa dovrei fare?
Collegare i server utilizzando LAG (Link Aggregation Group) con due cavi agli switch nel rack (devono anche essere ridondanti). Riservare le connessioni tra i rack, convertirli in un tipo “a stella” (o l'ormai di moda CLOS), in modo che la perdita di un rack non influisca sugli altri. Selezionare i rack “centrali” in cui verrà posizionato il nucleo della rete e dove verranno collegati gli altri rack. Allo stesso tempo, metti in ordine l'indirizzo pubblico, prendi dall'hoster (o dal RIR, se possibile) una sottorete, che tu stesso (o tramite l'hoster) annunci al mondo.
Tutto questo può essere fatto da un “comune” amministratore di sistema che non ha una conoscenza approfondita delle reti? Non è sicuro. L'hoster lo farà? Forse sì, ma servirà una specifica tecnica abbastanza dettagliata, che qualcuno dovrà anche stilare. e poi controlla che tutto sia fatto correttamente.
Esempio 2: nuvola
Supponiamo che tu abbia un VPC in un cloud pubblico. Per accedere dall'ufficio o da una parte on-premise dell'infrastruttura alla rete locale all'interno del VPC, è necessario configurare una connessione tramite IPSec o un canale dedicato. Da un lato, IPSec è più economico perché non è necessario acquistare hardware aggiuntivo; puoi creare un tunnel tra il tuo server con indirizzo pubblico e il cloud. Ma - ritardi, prestazioni limitate (poiché il canale deve essere crittografato), oltre a connettività non garantita (poiché l'accesso avviene tramite la normale Internet).
Cosa dovrei fare?
Stabilisci una connessione tramite un canale dedicato (ad esempio, AWS lo chiama Direct Connect). Per fare questo, trova un operatore partner che ti collegherà, decidi il punto di connessione più vicino a te (sia tu all'operatore che l'operatore al cloud) e, infine, configura tutto. È possibile fare tutto questo senza un tecnico di rete? Sicuramente sì. Ma come risolvere senza di lui in caso di problemi non è più così chiaro.
Potrebbero esserci anche problemi con la disponibilità tra cloud (se disponi di un multicloud) o problemi con ritardi tra regioni diverse, ecc. Naturalmente, ora sono comparsi molti strumenti che aumentano la trasparenza di ciò che sta accadendo nel cloud (gli stessi Mille Occhi), ma questi sono tutti gli strumenti di un ingegnere di rete, e non un suo sostituto.
Potrei fare ancora una dozzina di esempi simili tratti dalla mia pratica, ma penso che sia chiaro che il team, a partire da un certo livello di sviluppo dell'infrastruttura, deve avere una persona (preferibilmente più di una) che sappia come funziona la rete e possa configurarla apparecchiature di rete e risolvere eventuali problemi. Credimi, avrà qualcosa da fare
Cosa dovrebbe sapere un networker?
Non è affatto necessario (e talvolta addirittura dannoso) che un ingegnere di rete si occupi solo della rete e nient'altro. Anche se non consideriamo l'opzione con un'infrastruttura che vive quasi interamente nel cloud pubblico (e, comunque si possa dire, sta diventando sempre più popolare), e prendiamo, ad esempio, i cloud on premise o privati, dove sulla “Sola conoscenza a livello CCNP” "Non te ne andrai.
Oltre, appunto, alle reti - anche se esiste semplicemente un campo di studio infinito, anche se ci si concentra su un solo ambito (reti di provider, imprese, data center, Wi-Fi ...)
Naturalmente, molti di voi ora ricorderanno Python e altre "automazioni di rete", ma questa è solo una condizione necessaria, ma non sufficiente. Affinché un ingegnere di rete possa "unirsi con successo al team", deve essere in grado di parlare la stessa lingua sia con gli sviluppatori che con gli altri amministratori/sviluppatori. Cosa significa?
- essere in grado non solo di lavorare su Linux come utente, ma anche di amministrarlo, almeno a livello sysadmin-jun: installare il software necessario, riavviare un servizio guasto, scrivere una semplice unità systemd.
- Comprendere (almeno in termini generali) come funziona lo stack di rete in Linux, come funziona la rete negli hypervisor e nei contenitori (lxc/docker/kubernetes).
- Naturalmente, essere in grado di lavorare con ansible/chef/puppet o un altro sistema SCM.
- Dovrebbe essere scritta una riga separata sull'SDN e sulle reti per cloud privati (ad esempio, TungstenFabric o OpenvSwitch). Questo è un altro enorme livello di conoscenza.
In breve, ho descritto un tipico specialista della forma a T (come va di moda dire adesso). Sembra niente di nuovo, ma in base all'esperienza dei colloqui, non tutti gli ingegneri di rete possono vantare la conoscenza di almeno due argomenti dell'elenco sopra. In pratica, la mancanza di conoscenza “in campi correlati” rende molto difficile non solo comunicare con i colleghi, ma anche comprendere le esigenze che l'azienda pone alla rete, in quanto infrastruttura di livello più basso del progetto. E senza questa comprensione diventa più difficile difendere il proprio punto di vista e “venderlo” alle imprese.
D’altra parte, la stessa abitudine di “capire come funziona il sistema” dà ai networker un ottimo vantaggio rispetto ai vari “generalisti” che conoscono le tecnologie dagli articoli su Habré/medium e dalle chat di Telegram, ma non hanno assolutamente idea di come fare principi su cui funziona questo o quel software? E la conoscenza di determinati modelli, come è noto, sostituisce con successo la conoscenza di molti fatti.
Conclusioni, o semplicemente TL;DR
- Un amministratore di rete (come un DBA o un ingegnere VoIP) è uno specialista con un profilo piuttosto ristretto (a differenza degli amministratori di sistema/sviluppatori/SRE), la cui necessità non si presenta immediatamente (e potrebbe non sorgere per molto tempo, in effetti) . Ma se dovesse verificarsi, è improbabile che venga sostituito da competenze esterne (esternalizzazione o amministratori generali ordinari, “che si occupano anche della rete”). Ciò che è un po' più triste è che la necessità di tali specialisti è piccola e, condizionatamente, in un'azienda con 800 programmatori e 30 devops/amministratori, potrebbero esserci solo due networker che svolgono un ottimo lavoro con le loro responsabilità. Quelli. il mercato era ed è molto, molto piccolo e con un buon stipendio, anche meno.
- D'altra parte, un buon networker nel mondo moderno deve conoscere non solo le reti stesse (e come automatizzarne la configurazione), ma anche come i sistemi operativi e il software che girano su queste reti interagiscono con esse. Senza questo, sarà estremamente difficile capire cosa ti chiedono i tuoi colleghi e trasmettere loro (ragionevolmente) i tuoi desideri/esigenze.
- Non esiste un cloud, è solo il computer di qualcun altro. Devi capire che l'utilizzo di cloud pubblici/privati o dei servizi di un provider di hosting "che fa tutto per te chiavi in mano" non cambia il fatto che la tua applicazione utilizza ancora la rete e che i problemi con essa influenzeranno il funzionamento di la tua applicazione. A te la scelta dove verrà situato il centro di competenza, che sarà responsabile della rete del tuo progetto.
Fonte: habr.com