{"id":97373,"date":"2020-10-17T14:42:32","date_gmt":"2020-10-17T12:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/seteviki-ne-nuzhny"},"modified":"2020-10-17T14:42:32","modified_gmt":"2020-10-17T12:42:32","slug":"seteviki-ne-nuzhny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"I professionisti delle reti (non) sono necessari","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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.<\/p>\n

Significa questo che i professionisti delle reti non sono pi\u00f9 necessari ai tempi delle nuvole vincenti, di Docker, di Kubernetes e del Wi-Fi pubblico onnipresente?
\nDiamo un'occhiata (c)<\/p>\n

\"I
\n<\/a><\/noindex>
\nPiacere di conoscervi. Mi chiamo Alexey e sono un professionista delle reti. <\/p>\n

Da pi\u00f9 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.<\/p>\n

dichiarazione: \"Nella nostra vita non tutto \u00e8 sempre e ovunque, e alcune cose, a volte e in alcuni luoghi\" (c) Maxim Dorofeev.<\/p>\n

Tutto quanto scritto qui di seguito pu\u00f2 e deve essere considerato un'opinione personale dell'autore, che non pretende di essere la verit\u00e0 definitiva e nemmeno uno studio completo. Tutti i personaggi sono frutto dell'immaginazione, ogni coincidenza \u00e8 puramente casuale.<\/p><\/blockquote>\n

Benvenuti nel mio mondo.<\/p>\n

Dove si possono incontrare i professionisti delle reti?<\/h3>\n

\n1. Operatori di telecomunicazioni, aziende di servizi e altri integratori<\/b>. Qui \u00e8 tutto semplice: la rete per loro \u00e8 un business. Vendono direttamente connettivit\u00e0 (operatori) o forniscono servizi per l'avvio \/ la manutenzione delle reti dei loro clienti. <\/p>\n

Ci sono molte opportunit\u00e0, 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\u00e0, anche adesso, il punto di partenza ideale (in quelli federali tutto \u00e8 molto scriptato e c'\u00e8 poco spazio per la creativit\u00e0). Inoltre, le storie su come si pu\u00f2 crescere da ingegnere di turno a manager C-level in pochi anni sono del tutto reali, anche se rare, per motivi comprensibili. La necessit\u00e0 di personale c'\u00e8 sempre, perch\u00e9 il turnover \u00e8 un fattore reale. Questo \u00e8 sia positivo che negativo allo stesso tempo: ci sono sempre offerte di lavoro, ma d'altra parte spesso i pi\u00f9 attivi\/intelligenti se ne vanno abbastanza rapidamente, sia per promozioni che per posti pi\u00f9 \"caldi\".<\/p>\n

2. Presunto \"enterprise\"<\/b>. Non importa se la sua attivit\u00e0 principale sia legata all'IT o meno. L'importante \u00e8 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<\/p>\n

3. Aziende produttrici<\/b>, il cui profitto \u00e8 generato dallo sviluppo (e, spesso, dall'operazione) di qualche software o piattaforma \u2014 proprio quel prodotto. Di solito sono piccole e agili, lontane anni luce dalle dimensioni delle grandi imprese e dalla loro burocratizzazione. \u00c8 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. <\/p>\n

Qual \u00e8 la differenza tra un ingegnere di rete e un sistemista?<\/h3>\n

\nNella comprensione delle persone che non provengono dall'IT \u2014 niente. Entrambi guardano uno schermo nero e scrivono qualche tipo di formule, a volte imprecando sottovoce. <\/p>\n

Nella comprensione dei programmatori, si tratta al massimo di un'area tematica. 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. In caso di problemi strani, la colpa ricade anche sui tecnici di rete. Solo perch\u00e9 puoi, ecco perch\u00e9.<\/p>\n

In realt\u00e0, la principale differenza \u00e8 l'approccio al lavoro. Probabilmente, tra i tecnici di rete si trovano pi\u00f9 sostenitori dell'approccio 'Se funziona, non toccarlo!'. Solitamente, per realizzare una certa cosa (all'interno di un unico vendor) si pu\u00f2 fare solo in un modo, tutta la configurazione della scatola \u2014 ecco, sta nel palmo della mano. Il costo dell'errore \u00e8 alto, a volte anche molto alto (ad esempio, sar\u00e0 necessario percorrere diverse centinaia di chilometri per riavviare un router, mentre nel frattempo migliaia di persone resteranno senza connessione \u2014 una situazione abbastanza comune per un operatore di rete).<\/p>\n

A mio avviso, \u00e8 proprio per questo che gli ingegneri di rete, da un lato, sono estremamente motivati alla stabilit\u00e0 della rete (e i cambiamenti sono il principale nemico della stabilit\u00e0), e dall'altro, le loro conoscenze vanno pi\u00f9 in profondit\u00e0 che in ampiezza (non \u00e8 necessario saper configurare decine di diversi demoni, \u00e8 necessario conoscere le tecnologie e la loro implementazione presso un determinato produttore di hardware). \u00c8 per questo motivo che un amministratore di sistema che ha googlato come configurare una VLAN su Cisco non \u00e8 ancora un tecnico di rete. E difficilmente sar\u00e0 in grado di gestire (e risolvere problemi) una rete abbastanza complessa in modo efficace. <\/p>\n

Ma a cosa serve un tecnico di rete, se hai un hoster<\/a>?<\/b><\/p>\n

Per una somma extra (e se sei un cliente molto grande e amato \u2014 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<\/a> da annunciare).<\/p>\n

Il problema principale \u00e8 che il data center non \u00e8 il vostro reparto IT, ma un'azienda separata il cui obiettivo \u00e8 generare profitto. Anche a spese di voi come cliente. Il data center fornisce rack, garantisce elettricit\u00e0 e refrigerazione, e offre anche una certa \"connettivit\u00e0 predefinita\" a Internet. Sulla base di questa infrastruttura, il data center pu\u00f2 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 \u00e8 (di solito) il business del data center, perch\u00e9 questo processo \u00e8 piuttosto dispendioso in termini di risorse, non si automatizza bene (e in un data center normale tutto ci\u00f2 che \u00e8 possibile \u00e8 automatizzato), si unifica ancora peggio (ogni cliente \u00e8 unico) e comporta, in generale, possibili contestazioni (\"mi avete configurato il server, ma ora \u00e8 andato gi\u00f9, \u00e8 tutta colpa vostra!!!111\"). Pertanto, se l'hoster vi aiuter\u00e0 in qualcosa, cercher\u00e0 di farlo nel modo pi\u00f9 semplice e \"standardizzato\" possibile. Infatti, fare le cose in modo complesso non \u00e8 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\u00e0 necessariamente tutto male. Ma non \u00e8 affatto garantito che far\u00e0 esattamente ci\u00f2 di cui avevate realmente bisogno.<\/p>\n

Sembra una cosa piuttosto ovvia, ma nella mia esperienza ho incontrato pi\u00f9 volte aziende che iniziavano a fare troppo affidamento sul proprio provider di hosting, pi\u00f9 di quanto fosse opportuno, e ci\u00f2 non portava a nulla di buono. Ho dovuto spiegare a lungo e in dettaglio che nessun SLA coprir\u00e0 le perdite da downtime (ci sono eccezioni, ma di solito sono molto, MOLTO costose per il cliente) e che l'hoster non \u00e8 affatto a conoscenza di ci\u00f2 che sta accadendo nell'infrastruttura dei clienti (a parte indicatori molto generali). Inoltre, l'hoster non effettua backup per conto vostro. \u00c8 ancora peggio se avete pi\u00f9 di un hoster. In caso di problemi tra di loro, di certo non si metteranno a chiarire per voi cosa sia andato storto.<\/p>\n

In effetti, i motivi qui sono gli stessi che nella scelta tra \u00abil proprio team di amministratori vs outsourcing\u00bb. Se i rischi sono stati valutati, la qualit\u00e0 \u00e8 soddisfacente e l'azienda non \u00e8 contraria \u2014 perch\u00e9 non provare? D'altra parte, la rete \u00e8 uno degli strati pi\u00f9 fondamentali dell'infrastruttura, e difficilemente vale la pena affidarla a persone esterne, se tutto il resto \u00e8 gi\u00e0 sotto il tuo controllo.<\/p>\n

Quando \u00e8 necessario un ingegnere di rete?<\/b><\/p>\n

In seguito parleremo specificamente delle aziende produttrici moderne. Con gli operatori e l'enterprise \u00e8 tutto piuttosto chiaro \u2014 l\u00ec non \u00e8 cambiato molto negli ultimi anni, e gli ingegneri di rete erano necessari in passato, lo sono ancora adesso. Ma con quelle \u00abgiovani e audaci\u00bb le cose non sono cos\u00ec univoche. Spesso, esse collocano interamente la loro infrastruttura nelle nuvole, quindi non hanno nemmeno troppi amministratori \u2014 a parte gli amministratori delle stesse nuvole, ovviamente. L'infrastruttura, da un lato, \u00e8 abbastanza semplice nella sua struttura, dall'altro \u00e8 ben automatizzata (ansible\/puppet, terraform, ci\/cd... insomma, lo sappiamo). Ma anche qui ci sono situazioni in cui non si pu\u00f2 fare a meno di un ingegnere di rete.<\/p>\n

Esempio 1, classico<\/b><\/p>\n

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\u00f9... Prima o poi, sorge la necessit\u00e0 di una rete privata tra i server. Perch\u00e9 il traffico \"esterno\" \u00e8 limitato sia in termini di banda (non pi\u00f9 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 \u00e8 generalmente molto pi\u00f9 costosa rispetto a una rete privata).<\/p>\n

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!<\/p>\n

Il numero di server sta aumentando, il traffico nella rete privata anche \u2014 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 \u2014 con tutta probabilit\u00e0 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.<\/p>\n

Cosa bisogna fare?<\/i><\/p>\n

Dividere la rete in segmenti \u2014 VLAN. Configurare un'indirizzamento diverso per ogni VLAN, designare un gateway che instrader\u00e0 il traffico tra le reti. Sul gateway impostare ACL per limitare l'accesso tra i segmenti, oppure mettere a fianco un firewall separato.<\/p>\n

Esempio 1, continuazione<\/b><\/p>\n

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\u00e0. Ogni server ha un proprio indirizzo pubblico, fornito dall'hoster e associato al rack. Cio\u00e8, spostando il server, \u00e8 necessario cambiare indirizzo.<\/p>\n

Cosa bisogna fare?<\/i><\/p>\n

Collegare i server tramite LAG (Link Aggregation Group) con due cavi agli switch nel rack (\u00e8 necessario riservarli anche). Riservare le connessioni tra i rack, riconfigurandole in una \u201cstella\u201d (o il pi\u00f9 attuale CLOS), affinch\u00e9 il guasto di un rack non influisca sugli altri. Definire rack \u201ccentrali\u201d in cui si trover\u00e0 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\u00e0 annunciato nel mondo in modo autonomo (o tramite l'hoster).<\/p>\n

Pu\u00f2 tutto questo essere fatto da un \u201cnormale\u201d amministratore di sistema, senza conoscenze approfondite in reti? Non sono sicuro. Lo far\u00e0 l'hoster? Potrebbe farlo, ma avrete bisogno di un capitolato molto dettagliato che dovr\u00e0 essere redatto da qualcuno, e poi controllare che tutto sia stato fatto correttamente.<\/p>\n

Esempio 2. Cloud<\/b><\/p>\n

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, \u00e8 necessario configurare una connessione tramite IPSec o un circuito dedicato. Da un lato, l'IPSec \u00e8 pi\u00f9 economico, poich\u00e9 non \u00e8 necessario acquistare hardware aggiuntivo e si pu\u00f2 configurare un tunnel tra il server con indirizzo pubblico e il cloud. Tuttavia, ci sono ritardi, prestazioni limitate (poich\u00e9 il canale deve essere cifrato) e una connettivit\u00e0 non garantita (poich\u00e9 l'accesso avviene attraverso l'ordinario internet). <\/p>\n

Cosa bisogna fare?<\/i><\/p>\n

Stabilire una connessione tramite circuito dedicato (ad esempio, da AWS \u00e8 chiamato Direct Connect). Per fare ci\u00f2, trovare un operatore partner che vi colleghi, decidere il punto di accesso pi\u00f9 vicino a voi (sia dall'operatore che dal cloud) e, infine, configurare tutto. \u00c8 possibile fare tutto questo senza un ingegnere di rete? Sicuramente s\u00ec. Ma come si risolvono i problemi in sua assenza \u00e8 gi\u00e0 meno chiaro. <\/p>\n

Possono anche sorgere problemi di accessibilit\u00e0 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\u00f2 che sta accadendo nel cloud (lo stesso Thousand Eyes), ma questi sono strumenti per il tecnico di rete, non una sua sostituzione.<\/p>\n

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\u00f9 di una) che sa come funziona la rete, pu\u00f2 configurare l'equipaggiamento di rete e comprendere i problemi se sorgono. Credetemi, avr\u00e0 molto da fare. <\/p>\n

Cosa deve sapere un ingegnere di rete?<\/b><\/p>\n

Non \u00e8 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\u00f9 popolare), e prendiamo ad esempio on-premise o cloud privati, dove non si possono andare lontani solo con \"conoscenze a livello CCNP\". <\/p>\n

Oltre alle reti, c'\u00e8 un vasto campo di studio, anche se ci si concentra solo su una singola area (reti per fornitori, enterprise, data center, Wi-Fi\u2026)<\/p>\n

Naturalmente, molti di voi penseranno subito a Python e ad altra \u00abnetwork automation\u00bb, ma questa \u00e8 solo una condizione necessaria, non sufficiente. Perch\u00e9 un ingegnere di rete possa \u00abintegrarsi con successo nel team\u00bb, deve essere in grado di parlare la stessa lingua sia con gli sviluppatori che con i colleghi amministratori\/devops. Cosa significa questo?<\/p>\n