{"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 di rete (non) sono necessari","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Significa questo che i professionisti di rete non sono pi\u00f9 necessari ai tempi delle nuvole dominanti, di Docker, Kubernetes e del pubblico WiFi sempre presente?
\nCerchiamo di capire (c)<\/p>\n

\"I
\n<\/a><\/noindex>
\nFacciamo conoscenza. Mi chiamo Aleksey e sono un professionista di rete. <\/p>\n

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

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

Tutto quanto scritto qui pu\u00f2 e deve essere considerato come un'opinione personale dell'autore, non pretensiosa di verit\u00e0 assoluta e neanche di una ricerca completa. Tutti i personaggi sono inventati, ogni somiglianza \u00e8 puramente casuale.<\/p><\/blockquote>\n

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

Dove si possono incontrare i networker?<\/h3>\n

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

L'esperienza qui \u00e8 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 \u00e8 molto scriptato e c'\u00e8 poco spazio per la creativit\u00e0). 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 \u00e8 sempre presente, poich\u00e9 il turnover \u00e8 una realt\u00e0. Questo \u00e8 buono e cattivo allo stesso tempo: ci sono sempre posti vacanti, ma d'altra parte, spesso, i pi\u00f9 attivi\/intelligenti se ne vanno rapidamente per promozioni o per posizioni pi\u00f9 \"comfortevoli\".<\/p>\n

2. Il cosiddetto \"enterprise\"<\/b>. Non importa se la sua attivit\u00e0 principale \u00e8 legata all'IT o meno. L'importante \u00e8 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\u00ec 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 \u00e8 piccola, o se viene gestita da un fornitore esterno); e l'ingegnere di rete, se presente, pu\u00f2 anche occuparsi della telefonia e del SAN (senza entrare nei dettagli). Le retribuzioni variano notevolmente, a seconda della marginalit\u00e0 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 \u00e8 notevolmente inferiore e sar\u00e0 quasi sicuramente incentrata su un forte vendor-lock o su 'come fare qualcosa dal nulla'. Personalmente, mi \u00e8 sembrato molto noioso, anche se a molti piace \u2014 tutto va abbastanza calmo e prevedibile (se parliamo di grandi aziende), 'dora\u010da-bahato' e cos\u00ec 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\u00e0 \u00e8 che, anche astrarsi dal costo della soluzione, gli ingegneri di rete non potranno andarsene. S\u00ec, forse, invece della console ci sar\u00e0 nuovamente un'interfaccia web (ma non per un singolo dispositivo, bens\u00ec per un grande sistema che gestisce decine o centinaia di tali dispositivi), ma le conoscenze 'su come tutto \u00e8 organizzato all'interno' saranno comunque necessarie.<\/p>\n

3. Aziende di prodotto<\/b>, il cui profitto deriva dallo sviluppo (e, spesso, dalla gestione) di qualche software o piattaforma \u2013 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. <\/p>\n

In cosa si differenzia un network engineer da un sistemista?<\/h3>\n

\nNella percezione delle persone che non provengono dal mondo IT \u2013 non ci sono differenze. Entrambi guardano a uno schermo nero e digitano qualche formula magica, talvolta imprecando sottovoce. <\/p>\n

Nella percezione degli sviluppatori \u2013 solo per l'ambito di specializzazione. I sistemisti gestiscono server, mentre i network engineer gestiscono switch e router. A volte lo fanno male, e tutti perdono l'accesso. E in caso di strane anomalie, le colpe ricadono comunque sui network engineer. Just because fuck you, that's why.<\/p>\n

In realt\u00e0, 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, \u00e8 possibile realizzare un'operazione (all'interno di un singolo fornitore) solo in un modo, tutta la configurazione del dispositivo \u00e8 qui, a portata di mano. Il costo di un errore \u00e8 elevato, e a volte molto elevato (ad esempio, pu\u00f2 essere necessario percorrere centinaia di chilometri per riavviare un router, e nel frattempo migliaia di persone resteranno senza connessione \u2014 una situazione piuttosto comune per un operatore di telecomunicazioni).<\/p>\n

A mio avviso, per questo motivo gli ingegneri di rete sono, da un lato, estremamente motivati alla stabilit\u00e0 della rete (e le modifiche sono il principale nemico della stabilit\u00e0), e dall'altro, le loro conoscenze si approfondiscono pi\u00f9 che ampliarsi (non \u00e8 necessario sapere come configurare decine di diversi demoni; \u00e8 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 \u00e8 ancora un ingegnere di rete. E difficilmente sar\u00e0 in grado di supportare (e risolvere i problemi) una rete anche solo leggermente complessa in modo efficace. <\/p>\n

Ma a cosa serve un network engineer se avete gi\u00e0 l'host<\/a>?<\/b><\/p>\n

Per un costo aggiuntivo (e se siete un cliente molto importante e preferito \u2014 potrebbe anche essere gratuito, \u00abper amicizia\u00bb), 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<\/a> per l'annuncio).<\/p>\n

Il problema principale \u00e8 che il data center non \u00e8 il tuo reparto IT, ma un'azienda separata il cui obiettivo \u00e8 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\u00e0 \u00abdi default\u00bb a Internet. Sulla base di questa infrastruttura, il data center pu\u00f2 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\u00e9 questo processo \u00e8 piuttosto laborioso, difficile da automatizzare (mentre in un data center normale \u00e8 automatizzato tutto ci\u00f2 che \u00e8 possibile), e ancor pi\u00f9 difficile da uniformare (ogni cliente \u00e8 unico) ed \u00e8 generalmente soggetto a lamentele (\u00abhai configurato il server per me e ora \u00e8 andato gi\u00f9, \u00e8 tutta colpa tua!!!111\u00bb). Pertanto, se il fornitore di hosting ti aiuter\u00e0 in qualche modo, cercher\u00e0 di farlo nel modo pi\u00f9 semplice e \u00abbasic\u00bb possibile. Infatti, fare le cose in modo complesso non \u00e8 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\u00e0 necessariamente tutto male. Ma non \u00e8 affatto certo che far\u00e0 esattamente ci\u00f2 di cui avevi realmente bisogno.<\/p>\n

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. \u00c8 stato necessario spiegare a lungo e in dettaglio che nessun SLA copre le perdite da inattivit\u00e0 (ci sono eccezioni, ma di solito ci\u00f2 \u00e8 molto, MOLTO costoso per il cliente) e che il fornitore di hosting non \u00e8 a conoscenza di ci\u00f2 che accade nell'infrastruttura dei clienti (eccetto indicatori molto generali). E il fornitore non effettua nemmeno i backup per voi. La situazione \u00e8 ancora peggiore se avete pi\u00f9 di un fornitore di hosting. In caso di problemi tra di loro, di certo non si preoccuperanno di scoprire cosa \u00e8 realmente andato storto.<\/p>\n

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\u00e0 \u00e8 soddisfacente e l'azienda \u00e8 d'accordo, perch\u00e9 non provare? D'altra parte, la rete \u00e8 uno dei livelli di infrastruttura pi\u00f9 fondamentali, e difficilmente vale la pena delegarla a ragazzi esterni, se tutto il resto lo gestite gi\u00e0 da soli.<\/p>\n

In quali casi \u00e8 necessario un esperto di rete?<\/b><\/p>\n

Ora parleremo specificamente delle moderne aziende di prodotto. Con gli operatori e le imprese, la situazione \u00e8 pi\u00f9 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\u00ec 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, \u00e8 piuttosto semplice nella sua struttura, ma dall'altro \u00e8 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\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, posizionato in un data center. Poi il numero di server aumenta a due. Poi a tre\u2026 Prima o poi, si presenta 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 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 \u00e8 generalmente molto pi\u00f9 costosa rispetto a una rete privata).<\/p>\n

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

Il numero di server cresce, anche il traffico nella rete privata aumenta \u2014 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.<\/p>\n

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

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

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

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\u00e0. Ogni server ha il proprio indirizzo pubblico, fornito dal fornitore di hosting e associato alla rack. Pertanto, nel caso di spostamento del server, \u00e8 necessario cambiare l'indirizzo.<\/p>\n

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

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

Pu\u00f2 un \"normale\" amministratore di sistema senza profondi conoscimenti di rete fare tutto questo? Non ne sono sicuro. Lo far\u00e0 l'hoster? Potrebbe, ma avrai bisogno di un briefing abbastanza dettagliato, che dovr\u00e0 essere redatto da qualcuno. E poi dovrai controllare che tutto sia stato fatto correttamente.<\/p>\n

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

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 \u00e8 pi\u00f9 economico, poich\u00e9 non \u00e8 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\u00e9 il canale deve essere crittografato) e una connettivit\u00e0 non garantita (poich\u00e9 l'accesso avviene tramite internet normale). <\/p>\n

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

Attivare una connessione tramite un canale dedicato (ad esempio, da AWS \u00e8 chiamato Direct Connect). Per fare ci\u00f2, \u00e8 necessario trovare un partner operativo che ti collega, determinare il punto di accesso pi\u00f9 vicino a te (sia per il tuo operatore sia per l'operatore cloud), e infine configurare tutto. \u00c8 possibile fare tutto questo senza un ingegnere di rete? Sicuramente s\u00ec. Ma come risolvere eventuali problemi senza di lui \u00e8 gi\u00e0 meno chiaro. <\/p>\n

Possono sorgere anche problemi di connettivit\u00e0 tra i cloud (se hai una configurazione multi-cloud) o problemi di latenza tra diverse regioni, e cos\u00ec via. Naturalmente, ci sono molti strumenti attualmente disponibili che aumentano la trasparenza di ci\u00f2 che accade nel cloud (come Thousand Eyes), ma questi sono strumenti per un ingegnere di rete, non una loro sostituzione.<\/p>\n

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\u00f9 di una) che sa come funziona la rete, pu\u00f2 configurare l'equipment di rete e risolvere eventuali problemi se sorgono. Fidati, avr\u00e0 di che occuparsi. <\/p>\n

Cosa deve sapere un network engineer?<\/b><\/p>\n

Non \u00e8 affatto necessario (e anzi, a volte pu\u00f2 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\u00f9 popolare), e prendendo in esempio i cloud on-premise o privati, basarsi esclusivamente su \"conoscenze a livello CCNP\" non basta. <\/p>\n

Oltre alle reti stesse \u2014 un campo praticamente infinito da esplorare, anche scegliendo di concentrarsi su una sola direzione (reti di provider, enterprise, data center, Wi-Fi\u2026)<\/p>\n

Naturalmente, molti di voi penseranno a Python e alla \"network automation\", ma questo \u00e8 solo un requisito necessario, ma non sufficiente. Perch\u00e9 un ingegnere di rete possa \"integrarsi con successo nel team\", deve saper comunicare allo stesso modo con sviluppatori e colleghi amministratori\/devops. Cosa significa?<\/p>\n