Questo articolo è il primo di una serie intitolata «Come avere il controllo sulla tua infrastruttura di rete». Puoi trovare il contenuto di tutti gli articoli della serie e i relativi link. .
È del tutto possibile che esistano aziende in cui una rete semplice non sia critica da gestire in un'ora o persino in un giorno. Purtroppo o fortunatamente, non ho mai lavorato in posti del genere. Tuttavia, le reti sono diverse, i requisiti variano, gli approcci sono vari e, comunque, la lista sottostante sarà in molti casi un vero e proprio «must-do».
Dunque, le condizioni iniziali.
Ti trovi in un nuovo posto di lavoro o hai ricevuto una promozione, o hai deciso di rivedere le tue responsabilità. La rete aziendale è di tua responsabilità. Per te, in gran parte, è una sfida e qualcosa di nuovo, il che giustifica in parte il tono didattico di questo articolo :). Ma spero che l'articolo possa essere utile anche a qualsiasi ingegnere di rete.
Il tuo primo obiettivo strategico è imparare a resistere all'entropia e mantenere il livello di servizio fornito.
Molti compiti descritti di seguito possono essere risolti con vari strumenti. Ho intenzionalmente tralasciato il tema dell'implementazione tecnica, poiché spesso non è così importante come hai risolto un determinato problema, quanto piuttosto come ne fai uso e se te ne occupi davvero. Non ha molto senso, ad esempio, avere un sistema di monitoraggio professionale se non lo controlli e non reagisci agli allarmi.
Attrezzature
Innanzitutto, devi capire dove si trovano i maggiori rischi.
Anche qui può variare. È possibile che in alcuni casi si tratti di questioni di sicurezza, in altri di continuità del servizio, o forse di qualcos'altro. Perché no?
Supponiamo, per chiarezza, che si tratti comunque di continuità del servizio (è stata la priorità in tutte le aziende in cui ho lavorato).
Allora bisogna partire dall'hardware. Ecco un elenco di argomenti su cui prestare attenzione:
- classificazione dell'hardware in base alla criticità
- ridondanza dell'hardware critico
- supporto, licenze
Devi considerare le possibili modalità di guasto, specialmente per l'hardware che si trova al vertice della tua classificazione di criticità. Spesso ci si dimentica della probabilità di problemi duplicati, altrimenti le tue soluzioni e il supporto potrebbero diventare ingiustificatamente costosi, ma nel caso di elementi realmente critici della rete, il cui guasto potrebbe influire notevolmente sul business, devi pensarci.
Esempio
Supponiamo che stiamo parlando di uno switch core nel data center.
Dato che abbiamo concordato che la continuità del servizio è il criterio più importante, è saggio garantire la ridondanza ‘calda’ per questo hardware. Ma non è tutto. Devi anche determinare quanto tempo, in caso di guasto del primo switch, sei disposto a vivere con un solo switch rimasto, dato che c'è il rischio che anche questo si guasti.
Importante! Non devi prendere questa decisione da solo. Devi descrivere i rischi, le soluzioni possibili e i costi alla tua direzione o alla direzione dell'azienda. Devono essere loro a prendere le decisioni.
Quindi, se è stato deciso che, data la bassa probabilità di un guasto doppio, lavorare per 4 ore su uno switch è, in linea di principio, accettabile, puoi semplicemente ottenere il supporto appropriato (con cui l'hardware sarà sostituito entro 4 ore).
Ma c'è il rischio che non venga consegnato. Purtroppo, una volta ci siamo trovati in questa situazione. Invece di quattro ore, l'hardware ha impiegato una settimana!!!
Pertanto, anche questo rischio deve essere discusso e, forse, sarebbe più saggio per te acquistare un altro switch (un terzo) e tenerlo in riserva («ridondanza fredda») o usarlo per scopi di laboratorio.
Importante! Crea un elenco di tutti i contratti di supporto che hai, con le date di scadenza e aggiungili al tuo calendario, in modo che almeno un mese prima ricevi una notifica che devi iniziare a preoccuparti del rinnovo del supporto.
Non te lo perdoneranno se dimentichi di rinnovare il supporto e il giorno dopo la scadenza il tuo hardware si guasta.
Lavori di emergenza
Qualunque cosa accada nella tua rete, idealmente, dovresti mantenere l'accesso al tuo hardware di rete.
Importante! Devi avere accesso alla console di tutto l'hardware e questo accesso non deve dipendere dal funzionamento della rete di trasmissione dei dati.
Dovete anche prevedere in anticipo possibili scenari negativi e documentare le azioni necessarie. L'accessibilità di questo documento è altrettanto critica, quindi deve essere non solo pubblicato su una risorsa comune per il reparto, ma anche salvato localmente sui computer degli ingegneri.
Deve contenere obbligatoriamente
- le informazioni necessarie per aprire una richiesta di supporto presso il fornitore o l'integratore
- le informazioni su come accedere a qualsiasi attrezzatura (console, gestione)
Può contenere anche altre informazioni utili, come la descrizione della procedura di aggiornamento di diverse apparecchiature e comandi diagnostici utili.
Partner
Ora è necessario valutare i rischi associati ai partner. Di solito si tratta di
- fornitori di servizi Internet e punti di interscambio di traffico (IX)
- fornitori di canali di comunicazione
Quali domande dovete porvi? Come nel caso delle attrezzature, bisogna considerare diverse opzioni per situazioni di emergenza. Ad esempio, per i fornitori di servizi Internet, potrebbe essere qualcosa del tipo:
- cosa succede se il fornitore di servizi Internet X smette per qualche motivo di offrirvi il servizio?
- avrete sufficiente larghezza di banda dagli altri fornitori?
- quale sarà la qualità della connettività?
- quanto sono indipendenti i vostri fornitori di servizi Internet e un guasto grave di uno di essi porterà a problemi con gli altri?
- quanti ingressi ottici ha il vostro data center?
- cosa succede se uno degli ingressi viene completamente distrutto?
Riguardo agli ingressi, nella mia esperienza in due diverse aziende, due volte data center affidabili un escavatore ha distrutto pozzetti e solo per miracolo la nostra fibra ottica non è stata colpita. Non è un caso così raro.
E, naturalmente, non dovete solo porvi queste domande, ma, nuovamente, con il supporto della direzione, garantire una soluzione accettabile in qualsiasi situazione.
Backup
Il backup delle configurazioni delle attrezzature può avere la priorità successiva. In ogni caso, questo è un aspetto molto importante. Non elencherò i casi in cui si può perdere la configurazione, meglio fare backup regolarmente e non pensare a questo. Inoltre, un backup regolare può essere molto utile per il controllo delle modifiche.
Importante! Rendete il backup quotidiano. Non è una grande quantità di dati da risparmiare. Al mattino, l'ingegnere di guardia (o voi) dovrebbe ricevere un rapporto dal sistema che indichi chiaramente se il backup è stato effettuato con successo o meno, e in caso di backup non riuscito, il problema deve essere risolto o deve essere aperto un ticket (vedi processi del reparto rete).
Versioni software
La questione se sia opportuno o meno aggiornare il software dell'attrezzatura non è così chiara. Da un lato, le versioni vecchie hanno bug e vulnerabilità noti, ma dall'altro, il nuovo software non sempre è un'operazione indolore e, in secondo luogo, porta con sé nuovi bug e vulnerabilità.
Qui è necessario trovare un'opzione ottimale. Alcuni suggerimenti ovvi
- installare solo versioni stabili
- non si dovrebbe vivere su versioni di software troppo vecchie
- compilare una tabella con informazioni su quale software è installato
- leggere periodicamente i rapporti sulle vulnerabilità e bug nelle versioni del software, e in caso di problemi critici, considerare un aggiornamento
A questo punto, avendo accesso alla console dell'attrezzatura, informazioni sul supporto e una descrizione della procedura di aggiornamento, siete pronti per questo passo. La situazione ideale è avere attrezzatura da laboratorio dove testare l'intera procedura, ma, sfortunatamente, non capita spesso.
In caso di attrezzatura critica, è possibile contattare il supporto del fornitore per chiedere assistenza nell'aggiornamento.
Sistema di ticketing
Ora potete guardare intorno a voi. Dovete stabilire processi di interazione con altre unità e all’interno del dipartimento.
Questo potrebbe non essere obbligatorio (ad esempio, se la vostra azienda è piccola), ma vi consiglio vivamente di organizzare il lavoro in modo che tutte le questioni esterne e interne passino attraverso un sistema di ticket.
Il sistema di ticket è, essenzialmente, la vostra interfaccia per le comunicazioni interne ed esterne, e dovete descrivere questa interfaccia con sufficiente dettaglio.
Prendiamo come esempio un compito importante e comune per aprire l'accesso. Descriverò un algoritmo che ha funzionato molto bene in una delle aziende.
Esempio
Iniziamo dal fatto che spesso i richiedenti di accesso formulano le loro richieste in un linguaggio che non è comprensibile per l'ingegnere di rete, precisamente, nel linguaggio dell'applicazione, ad esempio, "apritemi l'accesso a 1C".
Perciò non abbiamo mai accettato richieste direttamente da tali utenti.
E questo era il primo requisito
- le richieste di accesso devono provenire dai dipartimenti tecnici (nel nostro caso, si trattava di ingegneri unix, windows e helpdesk)
Il secondo requisito è che
- questo accesso deve essere documentato (dal dipartimento tecnico che ha ricevuto la richiesta) e come richiesta riceviamo un link a questo accesso documentato
La forma di questa richiesta deve essere comprensibile per noi, cioè
- la richiesta deve contenere informazioni su quale subnet deve essere aperta e in quale subnet, oltre al protocollo e (nel caso di tcp/udp) le porte
Deve anche essere indicato
- una descrizione del motivo per cui viene aperto questo accesso
- temporaneo o permanente (se temporaneo, fino a quale data)
E un punto molto importante sono le approvazioni
- dal responsabile del dipartimento che ha avviato l'accesso (ad esempio, contabilità)
- dal responsabile del dipartimento tecnico, da cui è pervenuta la richiesta al dipartimento di rete (ad esempio, helpdesk)
In questo caso, il “proprietario” di questo accesso è considerato il responsabile del dipartimento che ha avviato l'accesso (contabilità nel nostro esempio) ed è responsabile di mantenere aggiornata la pagina con gli accessi documentati per questo dipartimento.
Registrazione
Questo è qualcosa in cui si può affondare. Ma se vuoi adottare un approccio proattivo, devi imparare a gestire questo flusso di dati.
Ecco alcune raccomandazioni pratiche:
- esaminare i log deve essere fatto quotidianamente
- in caso di esame programmato (e non in situazioni di emergenza) si può limitare ai livelli di severità (severity) 0, 1, 2 e aggiungere modelli selezionati da altri livelli se lo si ritiene necessario
- scrivi uno script che analizza i log ignorando quelli i cui modelli hai aggiunto alla lista di esclusione
Questo approccio ti permetterà nel tempo di creare una lista di esclusione dei log che non ti interessano, mantenendo solo quelli che ritieni davvero importanti.
Da noi ha funzionato benissimo.
Monitoraggio
Non è raro che in un'azienda manchi un sistema di monitoraggio. Puoi, ad esempio, contare sui log, ma l'attrezzatura potrebbe semplicemente “morire” senza avere il tempo di “parlare”, oppure un pacchetto udp del protocollo syslog potrebbe andare perso e non arrivare. In generale, ovviamente, il monitoraggio attivo è importante e necessario.
Due esempi tra i più richiesti nella mia pratica:
- monitoraggio del carico delle connessioni critiche (ad esempio, collegamenti ai fornitori). Permette di vedere proattivamente un potenziale problema di degradazione del servizio dovuto alla perdita di traffico e quindi di evitarlo.
- grafici basati su NetFlow. Consentono di individuare facilmente anomalie nel traffico e sono molto utili per scoprire alcune semplici, ma significative, forme di attacchi hacker.
Importante! Configura le notifiche sms per eventi critici. Questo vale sia per il monitoraggio che per la registrazione. Se non hai un turno di guardia, le sms devono arrivare anche al di fuori dell'orario lavorativo.
Pensa al processo in modo tale da non svegliare tutti gli ingegneri. Da noi per questo avevamo un ingegnere di guardia.
Controllo delle modifiche
A mio avviso, non è necessario controllare tutte le modifiche. Ma, in ogni caso, devi poter trovare facilmente chi e perché ha fatto determinate modifiche alla rete, se necessario.
Alcuni consigli:
- utilizza un sistema di ticket per descrivere in dettaglio ciò che è stato fatto nel contesto di questo ticket, ad esempio copiando la configurazione applicata nel ticket
- sfrutta le possibilità di commento sull'hardware di rete (ad esempio, commit comment su Juniper). Puoi annotare il numero del ticket
- utilizza diff dei tuoi backup di configurazione
Puoi implementare questo come processo, esaminando quotidianamente tutti i ticket per verificare le modifiche.
Processi
Devi formalizzare e documentare i processi nel tuo team. Se sei arrivato a questo punto, nel tuo team dovrebbero già funzionare almeno i seguenti processi:
Processi quotidiani:
- gestione dei ticket
- gestione dei log
- controllo delle modifiche
- lista di controllo quotidiana
Processi annuali:
- rinnovo di garanzie, licenze
Processi asincroni:
- risposta a varie situazioni di emergenza
Conclusione della prima parte
Hai notato che tutto questo non riguarda ancora la configurazione della rete, il design, i protocolli di rete, il routing, la sicurezza… È qualcosa di diverso. Ma questi, sebbene possano sembrare noiosi, sono sicuramente elementi molto importanti del lavoro del dipartimento di rete.
Come puoi vedere, non hai ancora apportato miglioramenti alla tua rete. Se ci sono state vulnerabilità nella sicurezza, queste sono rimaste, se c'era un cattivo design, questo è rimasto. Finché non applicherai le tue competenze e conoscenze di ingegneria di rete, che probabilmente hanno richiesto molto tempo, sforzi e a volte anche denaro, non otterrai risultati. Ma prima devi creare (o rafforzare) le basi, e solo dopo puoi iniziare a costruire.
Di come cercare e risolvere errori, e poi migliorare la tua infrastruttura, parleranno le prossime parti.
Naturalmente, non è obbligatorio fare tutto in modo sequenziale. Il tempo può essere critico. Procedi parallelamente, se le risorse lo consentono.
E un'importante aggiunta. Comunica, fai domande, consulta il tuo team. Alla fine, saranno loro a dover gestire e mantenere tutto questo.
Fonte: habr.com
