Questo articolo è il primo di una serie chiamata «Come prendere il controllo dell'infrastruttura di rete». Puoi trovare il contenuto di tutti gli articoli della serie e i link .
Non escludo che ci siano un numero sufficiente di aziende in cui una rete semplice non rappresenta un problema critico per un'ora o persino un giorno. Sfortunatamente, non ho avuto la fortuna di lavorare in questi posti. Tuttavia, le reti sono diverse, le esigenze sono diverse, gli approcci sono diversi, e comunque, in un modo o nell'altro, l'elenco seguente sarà in molti casi un «must-do».
Quindi, le condizioni iniziali.
Sei in un nuovo posto di lavoro, hai ricevuto una promozione o hai deciso di dare una nuova occhiata alle tue responsabilità. La rete dell'azienda è la tua area di responsabilità. Per te, in gran parte, questa è una sfida e qualcosa di nuovo, il che giustifica in parte il tono di guida di questo articolo :). Ma spero che l'articolo possa essere utile anche a qualsiasi ingegnere di rete.
Il tuo primo obiettivo strategico è imparare a contrastare l'entropia e mantenere il livello del servizio fornito.
Molti dei compiti descritti di seguito possono essere risolti con diversi strumenti. Non solleverò intenzionalmente il tema dell'implementazione tecnica, poiché in linea di massima frequentemente non è così importante come risolvi un determinato compito, ma è importante come lo usi e se lo usi affatto. Ad esempio, non c'è molto da guadagnare dalla tua professionalmente costruita sistema di monitoraggio, se non lo controlli e non reagisci agli avvisi.
Apparecchiatura
In primo luogo, devi capire dove sono i maggiori rischi.
Ancora una volta, potrebbe essere diverso. Ammetto che in alcuni casi ciò potrebbe riguardare domande di sicurezza, in altri questioni legate alla continuità del servizio, e in altri forse qualcos'altro. Perché no?
Supponiamo, per chiarezza, che si tratti comunque di continuità del servizio (è stato così in tutte le aziende in cui ho lavorato).
Allora bisogna iniziare dall'hardware. Ecco l'elenco degli argomenti su cui prestare attenzione:
- classificazione dell'hardware in base al grado di criticità
- ridondanza dell'hardware critico
- supporto, licenze
Devi considerare le possibili opzioni di guasto, specialmente per l'attrezzatura che si trova in cima alla tua classificazione di criticità. Di solito, si sottovaluta la probabilità di problemi doppi; altrimenti, la tua soluzione e il supporto potrebbero diventare ingiustificatamente costosi. Tuttavia, per gli elementi della rete veramente critici, il guasto dei quali potrebbe influenzare significativamente il business, dovresti prendere in considerazione anche questo.
Esempio
Supponiamo di parlare dello switch principale in un data center.
Poiché abbiamo concordato che la continuità del servizio è il criterio più importante, è sensato garantire la ridondanza "calda" di quest'attrezzatura. Ma non è tutto. Devi anche decidere quanto tempo, in caso di guasto del primo switch, consideri accettabile vivere con un solo switch rimanente, poiché c'è il rischio che anche esso si guasti.
Attenzione! Non devi prendere questa decisione da solo. Devi descrivere i rischi, le possibili soluzioni e i costi alla tua direzione o alla direzione dell'azienda. Dovranno essere loro a prendere le decisioni.
Quindi, se è stato deciso che, data la bassa probabilità di guasto doppio, operare per 4 ore su uno switch è, in linea di massima, accettabile, puoi semplicemente avere il supporto corrispondente (secondo il quale l'attrezzatura sarà sostituita entro 4 ore).
Ma c'è il rischio che non venga consegnato. Purtroppo, una volta ci siamo trovati in una situazione simile. Invece di quattro ore, l'attrezzatura è arrivata dopo una settimana!!!
Pertanto, anche questo rischio deve essere discusso e, forse, sarebbe più corretto acquistare un altro switch (il terzo) e tenerlo in un magazzino ("ridondanza fredda") oppure utilizzarlo a scopi di laboratorio.
Importante! Crea un elenco di tutti i supporti di cui disponi, con le date di scadenza, e aggiungili al tuo calendario, in modo che, almeno un mese prima, ti arrivi un'email che ti avvisa che devi iniziare a preoccuparti di rinnovare il supporto.
Non ti perdoneranno se dimentichi di rinnovare il supporto e, il giorno dopo la scadenza, il tuo attrezzatura si guasta.
Lavori di emergenza
Qualunque cosa accada nella tua rete, idealmente, dovresti mantenere l'accesso alla tua attrezzatura 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 degli utenti.
Devi anche considerare in anticipo possibili scenari negativi e documentare le azioni necessarie. La disponibilità di questo documento è critica, quindi deve essere non solo pubblicato su una risorsa condivisa per il reparto, ma anche salvato localmente sui computer degli ingegneri.
Devono essere presenti obbligatoriamente
- informazioni necessarie per aprire una richiesta di supporto al fornitore o all'integratore
- informazioni su come accedere a qualsiasi hardware (console, management)
Può contenere anche qualsiasi altra informazione utile, ad esempio, la descrizione della procedura di aggiornamento di vari apparecchi e comandi diagnostici utili.
Partner
Ora devi valutare i rischi associati ai partner. Di solito sono
- fornitori di servizi Internet e punti di interscambio di traffico (IX)
- fornitori di canali di comunicazione
Quali domande devi porti? Come nel caso dell'hardware, devi considerare diverse opzioni per situazioni di emergenza. Ad esempio, per i fornitori di servizi Internet, potrebbe essere qualcosa come:
- cosa succede se il fornitore di servizi Internet X smette per qualche motivo di fornirti il servizio?
- hai sufficiente larghezza di banda dagli altri provider?
- quanto resterà buona la connettività?
- quanto sono indipendenti i tuoi fornitori di servizi Internet e un grave guasto di uno di essi porterà problemi con gli altri?
- quanti ingressi ottici ha il tuo data center?
- cosa succede se uno degli ingressi viene completamente distrutto?
Per quanto riguarda gli ingressi, nella mia esperienza in due diverse aziende, in due diverse — bassa latenza (ping) escavatori distruggevano i tombini e solo per miracolo la nostra fibra ottica non veniva danneggiata. Non è un caso così raro.
E, naturalmente, non devi solo porsi queste domande, ma, ancora una volta, con il supporto della direzione, garantire una soluzione accettabile in qualsiasi situazione.
Backup
Il prossimo in priorità potrebbe essere il backup delle configurazioni dell'hardware. In ogni caso, questo è un punto molto importante. Non elencherò i casi in cui potresti perdere la configurazione, è meglio effettuare regolarmente un backup e non pensarci. Inoltre, un backup regolare può essere molto utile nel controllo delle modifiche.
Importante! Esegui il backup quotidianamente. Non è un carico di dati così grande da risparmiare su questo. Al mattino, l'ingegnere di turno (o tu) deve ricevere un rapporto dal sistema che indichi chiaramente se il backup è stato eseguito con successo o meno, e in caso di backup non riuscito, il problema deve essere risolto o deve essere aperto un ticket (vedi i processi del reparto rete).
Versioni software
La questione di se sia opportuno aggiornare il software dell'hardware non è così semplice. Da un lato, le versioni vecchie presentano bug e vulnerabilità note, ma dall'altro, il nuovo software non è sempre un processo indolore di aggiornamento e, inoltre, porta con sé nuovi bug e vulnerabilità.
Qui è necessario trovare l'opzione ottimale. Alcuni consigli ovvi
- installare solo versioni stabili
- non è comunque consigliabile utilizzare versioni software troppo obsolete
- preparare una tabella con informazioni su quali software è installato
- leggere periodicamente i rapporti sulle vulnerabilità e sui bug nelle versioni del software, e in caso di problemi critici considerare un aggiornamento
A questo punto, avendo accesso console all'hardware, informazioni sul supporto e una descrizione della procedura di aggiornamento, sei fondamentalmente pronto per questo passo. L'ideale è avere attrezzature da laboratorio dove puoi testare l'intera procedura, ma purtroppo questo non accade spesso.
Nel caso di attrezzature critiche, è possibile contattare il supporto del fornitore per chiedere aiuto nell'eseguire l'aggiornamento.
Sistema di ticketing
Ora puoi guardarti intorno. Devi stabilire processi di interazione con altri reparti e all'interno del dipartimento.
Potrebbe non essere obbligatorio (ad esempio, se la tua azienda è piccola), ma ti consiglierei vivamente di organizzare il lavoro in modo che tutte le attività esterne e interne siano gestite attraverso il sistema di ticketing.
Il sistema di ticketing è essenzialmente la tua interfaccia per le comunicazioni interne ed esterne, e devi descrivere questa interfaccia con un livello sufficiente di dettaglio.
Esaminiamo come esempio un compito importante e comune di apertura dell'accesso. Descriverò l'algoritmo che ha funzionato molto bene in una delle aziende.
Esempio
Iniziamo col dire che spesso i richiedenti accessi formulano le loro richieste in un linguaggio incomprensibile per l'ingegnere di rete, ovvero nel linguaggio dell'applicazione, ad esempio, "aprimi accesso in 1C".
Pertanto, non abbiamo mai accettato richieste direttamente da tali utenti.
E questo è stato il primo requisito
- le richieste di accesso devono provenire dai reparti tecnici (nel nostro caso erano ingegneri unix, windows, helpdesk)
Il secondo requisito è che
- questo accesso deve essere protocollato (dal reparto tecnico da cui abbiamo ricevuto la richiesta) e come richiesta riceviamo un link a questo accesso protocollato
La forma di questa richiesta deve essere comprensibile per noi, cioè
- la richiesta deve contenere informazioni su quale e in quale subnet deve essere aperto l'accesso, oltre al protocollo e (in caso di tcp/udp) alle 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 reparto che ha richiesto l'accesso (ad esempio, la contabilità)
- dal responsabile del reparto tecnico da cui è arrivata questa richiesta al reparto di rete (ad esempio, helpdesk)
In questo caso, il "proprietario" di questo accesso è considerato il responsabile del reparto che ha richiesto l'accesso (la contabilità nel nostro esempio), ed è responsabile di mantenere aggiornata la pagina con gli accessi protocollati per questo reparto.
Registrazione
Questo è ciò in cui si può affondare. Ma se vuoi adottare un approccio proattivo, devi imparare a gestire questo flusso di dati.
Ecco alcuni consigli pratici:
- è necessario controllare i log quotidianamente
- in caso di verifica programmata (e non in situazioni di emergenza) puoi limitarti ai livelli di criticità (severity) 0, 1, 2 e aggiungere modelli selezionati da altri livelli se lo ritieni necessario
- scrivi uno script che analizzi i log e ignori quei log i cui modelli hai aggiunto alla lista nera
Questo approccio ti permetterà nel tempo di creare una lista nera dei log che non ti interessano e mantenere solo quelli che consideri realmente importanti.
Da noi questo ha funzionato molto bene.
Monitoraggio
Non è raro che in un'azienda manchi un sistema di monitoraggio. Puoi, ad esempio, contare sui log, ma l'attrezzatura potrebbe semplicemente "morire", prima di riuscire a "parlare", o il pacchetto UDP del protocollo syslog potrebbe andare perso e non arrivare. In generale, naturalmente, è importante e necessario un monitoraggio attivo.
Due esempi molto richiesti nella mia pratica:
- monitoraggio del carico dei canali di comunicazione e dei link critici (ad esempio, connessione ai fornitori). Permettono di vedere in modo proattivo un potenziale problema di degrado del servizio a causa di perdita di traffico e quindi evitarlo.
- grafici basati su NetFlow. Permettono di individuare facilmente anomalie nel traffico e sono molto utili per rilevare alcuni tipi di attacchi informatici semplici ma significativi.
Importante! Configura avvisi SMS per gli eventi più critici. Questo si applica sia al monitoraggio che al logging. Se non hai un turno di guardia, gli SMS devono comunque arrivare anche fuori orario.
Pensa al processo in modo da non svegliare tutti gli ingegneri. Noi avevamo un ingegnere di guardia per questo.
Controllo delle modifiche
A mio avviso, non è necessario controllare tutte le modifiche. Ma, in ogni caso, dovresti avere la possibilità di trovare facilmente chi e perché ha fatto determinate modifiche nella rete, se necessario.
Alcuni consigli:
- usa 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'attrezzatura di rete (ad esempio, commit comment su Juniper). Puoi annotare il numero del ticket
- usa il diff dei tuoi backup di configurazione
Puoi formalizzare questo come un processo, rivedendo quotidianamente tutti i ticket per eventuali modifiche.
Processi
Devi formalizzare e descrivere i processi nel tuo team. Se sei arrivato a questo punto, nel tuo team dovrebbero già funzionare almeno i seguenti processi:
Processi giornalieri:
- lavorare con i ticket
- lavorare con i log
- controllo delle modifiche
- lista di controllo giornaliera
Processi annuali:
- rinnovo di garanzie, licenze
Processi asincroni:
- reazione a diverse 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 o la sicurezza... È qualcosa di più ampio. Anche se può sembrare noioso, sono elementi molto importanti per il funzionamento di un'unità di rete.
Finora, come puoi vedere, non hai migliorato nulla nella tua rete. Se c'erano vulnerabilità di sicurezza, esse sono rimaste, se c'era un cattivo design, è rimasto tale. Hai ancora bisogno di applicare le tue competenze e conoscenze da ingegnere di rete, che probabilmente hanno richiesto molto tempo, sforzi e talvolta anche denaro. Ma prima devi creare (o rafforzare) le basi, e solo dopo dedicarti alla costruzione.
Sulle modalità di ricerca e risoluzione degli errori, e poi sul miglioramento della tua infrastruttura – questo sarà oggetto delle prossime parti.
Naturalmente, non è necessario fare tutto in sequenza. Il tempo potrebbe essere critico. Fai il lavoro in parallelo, se le risorse lo consentono.
E un'importante aggiunta. Comunica, chiedi, consulta il tuo team. Alla fine, saranno loro a dover supportare e gestire tutto questo.
Fonte: habr.com
