Come prendere il controllo della tua infrastruttura di rete. Primo capitolo. Presa

Questo articolo è il primo di una serie di articoli "Come assumere il controllo della propria infrastruttura di rete". È possibile trovare il contenuto di tutti gli articoli della serie e i collegamenti qui.

Ammetto pienamente che esiste un numero sufficiente di aziende in cui un tempo di inattività della rete di un'ora o anche di un giorno non è critico. Sfortunatamente o fortunatamente non ho avuto l'opportunità di lavorare in posti del genere. Ma, ovviamente, le reti sono diverse, i requisiti sono diversi, gli approcci sono diversi, eppure, in una forma o nell’altra, l’elenco seguente in molti casi sarà effettivamente un “must-do”.

Quindi, le condizioni iniziali.

Hai un nuovo lavoro, hai ricevuto una promozione o hai deciso di rivedere le tue responsabilità. La rete aziendale è la tua area di responsabilità. Per te, questa è per molti versi una sfida e una novità, il che in qualche modo giustifica il tono di mentoring di questo articolo :). Ma spero che l'articolo possa essere utile anche a qualunque ingegnere di rete.

Il tuo primo obiettivo strategico è imparare a resistere all'entropia e mantenere il livello di servizio fornito.

Molti dei problemi descritti di seguito possono essere risolti in vari modi. Non sollevo volutamente il tema dell'implementazione tecnica, perché... in linea di principio, spesso non è così importante come hai risolto questo o quel problema, ma ciò che è importante è come lo usi e se lo usi del tutto. Ad esempio, il tuo sistema di monitoraggio costruito professionalmente è di scarsa utilità se non lo guardi e non rispondi agli avvisi.

Attrezzatura

Per prima cosa bisogna capire dove sono i rischi maggiori.

Ancora una volta, può essere diverso. Ammetto che da qualche parte, ad esempio, questi saranno problemi di sicurezza, e da qualche parte, problemi legati alla continuità del servizio, e da qualche parte, forse, qualcos'altro. Perché no?

Ipotizziamo, per intenderci, che si tratti pur sempre di continuità di servizio (è stato così in tutte le aziende in cui ho lavorato).

Quindi è necessario iniziare con l'attrezzatura. Ecco un elenco di argomenti a cui prestare attenzione:

  • classificazione delle apparecchiature per grado di criticità
  • backup delle apparecchiature critiche
  • supporto, licenze

È necessario pensare a possibili scenari di guasto, soprattutto con le apparecchiature in cima alla classificazione di criticità. Di solito si trascura la possibilità di doppi problemi, altrimenti la soluzione e il supporto potrebbero diventare irragionevolmente costosi, ma nel caso di elementi di rete veramente critici, il cui guasto potrebbe influire in modo significativo sull'azienda, è necessario pensarci.

esempio

Diciamo che stiamo parlando di uno switch root in un data center.

Poiché abbiamo concordato che la continuità del servizio è il criterio più importante, è ragionevole fornire un backup “a caldo” (ridondanza) di questa apparecchiatura. Ma non è tutto. Devi anche decidere per quanto tempo, se il primo interruttore si rompe, è accettabile per te vivere con un solo interruttore rimanente, perché c'è il rischio che si rompa anche quello.

Importante! Non devi decidere tu stesso questo problema. È necessario descrivere i rischi, le possibili soluzioni e i costi al management o alla direzione aziendale. Devono prendere decisioni.

Quindi, se si decide che, data la piccola probabilità di un doppio guasto, lavorare per 4 ore su un interruttore è, in linea di principio, accettabile, allora si può semplicemente richiedere il supporto appropriato (secondo il quale l'apparecchiatura verrà sostituita entro 4 ore).

Ma c’è il rischio che non mantengano i risultati. Sfortunatamente, una volta ci siamo trovati in una situazione del genere. Invece di quattro ore, l'attrezzatura ha viaggiato per una settimana!!!

Pertanto, anche questo rischio deve essere discusso e, forse, sarà più corretto acquistare un altro interruttore (terzo) e conservarlo in una confezione di pezzi di ricambio (backup “a freddo”) o utilizzarlo per scopi di laboratorio.

Importante! Crea un foglio di calcolo di tutto il supporto che hai con le date di scadenza e aggiungilo al tuo calendario in modo da ricevere un'e-mail con almeno un mese di anticipo in cui dovresti iniziare a preoccuparti di rinnovare il supporto.

Non sarai perdonato se dimentichi di rinnovare il supporto e il giorno dopo la sua scadenza il tuo hardware si rompe.

Lavoro d'emergenza

Qualunque cosa accada sulla tua rete, idealmente dovresti mantenere l'accesso alle tue apparecchiature di rete.

Importante! È necessario avere accesso tramite console a tutte le apparecchiature e tale accesso non deve dipendere dallo stato della rete dati dell'utente.

Dovresti anche prevedere in anticipo possibili scenari negativi e documentare le azioni necessarie. Anche la disponibilità di questo documento è fondamentale, quindi non solo dovrebbe essere pubblicato su una risorsa condivisa per il dipartimento, ma dovrebbe anche essere salvato localmente sui computer degli ingegneri.

Ci deve essere

  • informazioni necessarie per aprire un ticket con il supporto del fornitore o dell'integratore
  • informazioni su come raggiungere eventuali apparecchiature (console, gestionali)

Naturalmente può contenere anche altre informazioni utili, ad esempio la descrizione della procedura di aggiornamento di vari apparecchi e utili comandi diagnostici.

partner

Ora è necessario valutare i rischi associati ai partner. Di solito questo

  • Provider Internet e punti di scambio del traffico (IX)
  • fornitori di canali di comunicazione

Quali domande dovresti porti? Come per le apparecchiature, è necessario considerare diversi scenari di emergenza. Ad esempio, per i provider Internet, potrebbe essere qualcosa del tipo:

  • cosa succede se il provider Internet X smette di fornirti il ​​servizio per qualche motivo?
  • Gli altri provider avranno abbastanza larghezza di banda per te?
  • Quanto sarà buona la connettività?
  • Quanto sono indipendenti i vostri provider Internet e un'interruzione grave di uno di essi causerà problemi con gli altri?
  • quanti ingressi ottici nel tuo data center?
  • cosa accadrebbe se uno degli ingressi venisse completamente distrutto?

Per quanto riguarda gli input, nella mia pratica in due diverse aziende, in due diversi data center, un escavatore ha distrutto dei pozzi e solo per miracolo la nostra ottica non è stata danneggiata. Questo non è un caso così raro.

E, naturalmente, non è necessario solo porre queste domande, ma, ancora una volta, con il supporto del management, fornire una soluzione accettabile in ogni situazione.

di riserva

La priorità successiva potrebbe essere il backup delle configurazioni delle apparecchiature. In ogni caso, questo è un punto molto importante. Non elencherò i casi in cui potresti perdere la configurazione, è meglio fare backup regolari e non pensarci. Inoltre, backup regolari possono essere molto utili per monitorare le modifiche.

Importante! Effettua backup giornalieri. Non si tratta di una grande quantità di dati da salvare su questo. Al mattino, il tecnico di turno (o te) dovrebbe ricevere un report dal sistema, che indica chiaramente se il backup è andato a buon fine o meno e, se il backup non ha avuto successo, il problema dovrebbe essere risolto o dovrebbe essere creato un ticket ( vedere i processi del dipartimento di rete).

Versioni del software

La questione se valga la pena aggiornare il software dell'apparecchiatura non è così chiara. Da un lato, le vecchie versioni presentavano bug e vulnerabilità note, ma dall'altro il nuovo software non è sempre una procedura di aggiornamento indolore e, in secondo luogo, nuovi bug e vulnerabilità.

Qui devi trovare l'opzione migliore. Alcune raccomandazioni ovvie

  • installa solo versioni stabili
  • Tuttavia, non dovresti vivere con versioni molto vecchie del software
  • fare un cartello con le informazioni su dove si trovano alcuni software
  • leggi periodicamente i rapporti sulle vulnerabilità e sui bug nelle versioni del software e, in caso di problemi critici, dovresti pensare all'aggiornamento

A questo punto, avendo accesso tramite console all'apparecchiatura, informazioni sul supporto e una descrizione della procedura di aggiornamento, in linea di principio sei pronto per questo passaggio. L'opzione ideale è quando si dispone di apparecchiature di laboratorio in cui è possibile controllare l'intera procedura, ma sfortunatamente ciò non accade spesso.

Nel caso di apparecchiature critiche, puoi contattare il supporto del fornitore con una richiesta di aiuto con l'aggiornamento.

Sistema di biglietteria

Ora puoi guardarti intorno. È necessario stabilire processi per l'interazione con altri dipartimenti e all'interno del dipartimento.

Questo potrebbe non essere necessario (ad esempio, se la tua azienda è piccola), ma consiglio vivamente di organizzare il lavoro in modo tale che tutte le attività esterne ed interne passino attraverso il sistema di ticket.

Il sistema di ticket è essenzialmente la tua interfaccia per le comunicazioni interne ed esterne e dovresti descrivere questa interfaccia in modo sufficientemente dettagliato.

Facciamo un esempio di un compito importante e comune di apertura dell'accesso. Descriverò un algoritmo che ha funzionato perfettamente in una delle aziende.

esempio

Cominciamo dal fatto che spesso i clienti che accedono formulano i loro desideri in un linguaggio incomprensibile a un ingegnere di rete, vale a dire nel linguaggio dell'applicazione, ad esempio "dammi accesso a 1C".

Pertanto non abbiamo mai accettato richieste direttamente da tali utenti.
E quello era il primo requisito

  • le richieste di accesso dovrebbero provenire dai dipartimenti tecnici (nel nostro caso si trattava di ingegneri unix, windows, helpdesk)

Il secondo requisito è quello

  • questo accesso deve essere registrato (dall'ufficio tecnico da cui abbiamo ricevuto questa richiesta) e come richiesta riceviamo un collegamento a questo accesso registrato

La forma di questa richiesta deve essere per noi comprensibile, ad es.

  • la richiesta deve contenere informazioni su quale sottorete e a quale sottorete deve essere aperto l'accesso, nonché il protocollo e (nel caso di tcp/udp) le porte

Dovrebbe essere indicato anche lì

  • 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 capo del dipartimento che ha avviato l'accesso (ad esempio, contabilità)
  • dal capo dell'ufficio tecnico, da dove è arrivata questa richiesta al dipartimento di rete (ad esempio, helpdesk)

In questo caso, il “proprietario” di questo accesso è considerato il capo del dipartimento che ha avviato l’accesso (contabilità nel nostro esempio), ed è responsabile di garantire che la pagina con accesso registrato per questo dipartimento rimanga aggiornata .

Registrazione

Questo è qualcosa in cui puoi annegare. Ma se vuoi implementare un approccio proattivo, devi imparare come gestire questo diluvio di dati.

Ecco alcuni consigli pratici:

  • è necessario rivedere i registri ogni giorno
  • nel caso di una revisione pianificata (e non di una situazione di emergenza), puoi limitarti ai livelli di gravità 0, 1, 2 e aggiungere modelli selezionati da altri livelli se lo ritieni necessario
  • scrivi uno script che analizzi i log e ignori i log i cui modelli hai aggiunto all'elenco da ignorare

Questo approccio ti consentirà, nel tempo, di creare un elenco da ignorare dei log che non ti interessano e di lasciare solo quelli che ritieni veramente importanti.
Ha funzionato benissimo per noi.

Monitoraggio

Non è raro che un’azienda non abbia un sistema di monitoraggio. Puoi, ad esempio, fare affidamento sui log, ma l'apparecchiatura potrebbe semplicemente "morire" senza avere il tempo di "dire" nulla, oppure il pacchetto del protocollo udp syslog potrebbe andare perso e non arrivare. In generale, ovviamente, il monitoraggio attivo è importante e necessario.

I due esempi più popolari nella mia pratica:

  • monitorare il carico dei canali di comunicazione, collegamenti critici (ad esempio, connessione ai provider). Consentono di vedere in modo proattivo il potenziale problema del degrado del servizio dovuto alla perdita di traffico e, di conseguenza, di evitarlo.
  • grafici basati su NetFlow. Consentono di individuare facilmente anomalie nel traffico e sono molto utili per rilevare alcune tipologie semplici ma significative di attacchi hacker.

Importante! Imposta notifiche SMS per gli eventi più critici. Questo vale sia per il monitoraggio che per la registrazione. Se non hai un turno di servizio, gli sms dovrebbero arrivare anche al di fuori dell'orario di lavoro.

Pensa al processo in modo tale da non svegliare tutti gli ingegneri. Avevamo un ingegnere in servizio per questo.

Cambia controllo

A mio parere, non è necessario controllare tutti i cambiamenti. In ogni caso, se necessario, dovresti essere in grado di trovare facilmente chi ha apportato determinate modifiche sulla rete e perché.

Alcuni consigli:

  • utilizzare un sistema di ticket per dettagliare cosa è stato fatto su quel ticket, ad esempio copiando la configurazione applicata nel ticket
  • utilizzare funzionalità di commento sulle apparecchiature di rete (ad esempio, inviare commenti su Juniper). Puoi annotare il numero del biglietto
  • usa diff dei backup della configurazione

Puoi implementarlo come un processo, rivedendo quotidianamente tutti i ticket per eventuali modifiche.

processi

Devi formalizzare e descrivere i processi nel tuo team. Se hai raggiunto questo punto, il tuo team dovrebbe già avere almeno i seguenti processi in esecuzione:

Processi quotidiani:

  • lavorare con i biglietti
  • lavorare con i log
  • cambiare controllo
  • foglio di controllo giornaliero

Processi annuali:

  • estensione di garanzie, licenze

Processi asincroni:

  • risposta alle varie situazioni di emergenza

Conclusione della prima parte

Hai notato che tutto questo non riguarda ancora la configurazione della rete, non la progettazione, non i protocolli di rete, non l'instradamento, non la sicurezza... È qualcosa in giro. Ma questi, anche se forse noiosi, sono ovviamente elementi molto importanti del lavoro di una divisione di rete.

Finora, come puoi vedere, non hai migliorato nulla nella tua rete. Se c’erano vulnerabilità di sicurezza, allora rimanevano; se c’era una cattiva progettazione, allora rimanevano. Fino a quando non avrai applicato le tue capacità e conoscenze come ingegnere di rete, su cui molto probabilmente hai speso una grande quantità di tempo, impegno e talvolta denaro. Ma prima devi creare (o rafforzare) le fondamenta e poi iniziare a costruire.

Le parti seguenti ti spiegheranno come trovare ed eliminare gli errori e quindi migliorare la tua infrastruttura.

Naturalmente non è necessario fare tutto in sequenza. Il tempo può essere fondamentale. Fatelo in parallelo se le risorse lo consentono.

E un'aggiunta importante. Comunica, chiedi, consulta il tuo team. Alla fine, sono loro che sostengono e fanno tutto questo.

Fonte: habr.com

Aggiungi un commento