Questu articulu hè u primu in una seria di articuli "Cumu piglià u cuntrollu di a vostra infrastruttura di rete". U cuntenutu di tutti l'articuli in a serie è i ligami ponu esse truvati .
Admettu cumplettamente chì ci hè un numeru abbastanza di cumpagnie induve un downtime di a rete di una ora o ancu un ghjornu ùn hè micca criticu. Per disgrazia o furtuna, ùn aghju micca avutu l'uppurtunità di travaglià in tali lochi. Ma, sicuru, e rete sò diverse, i requisiti sò sfarenti, l'approcciu sò diffirenti, è ancu, in una forma o l'altru, a lista sottu in parechji casi serà veramente un "must-do".
Dunque, e cundizioni iniziali.
Sò in un novu travagliu, avete ricevutu una prumuzione, o avete decisu di piglià un novu sguardu à e vostre rispunsabilità. A reta di a cumpagnia hè a vostra zona di rispunsabilità. Per voi, questu hè in parechje manere una sfida è nova, chì ghjustifica un pocu u tonu di mentoring di questu articulu :). Ma spergu chì l'articulu pò ancu esse utile à qualsiasi ingegnere di rete.
U vostru primu scopu strategicu hè di amparà à resiste à l'entropia è mantene u livellu di serviziu furnitu.
Parechje di i prublemi descritti quì sottu ponu esse risolti da parechji mezi. Ùn aghju micca deliberatamente suscitatu u tema di l'implementazione tecnica, perchè ... in principiu, hè spessu micca cusì impurtante cumu si risolve questu o quellu prublema, ma ciò chì hè impurtante hè cumu l'utilizate è s'ellu l'utilizate in tuttu. Per esempiu, u vostru sistema di surviglianza custruitu prufessiunali hè di pocu utilità s'ellu ùn vede micca è ùn risponde micca à l'alerta.
Equipment
Prima ci vole à capisce induve sò i risichi maiò.
In novu, pò esse diversu. Admessu chì in qualchì locu, per esempiu, questi seranu prublemi di sicurità, è in qualchì locu, prublemi ligati à a continuità di u serviziu, è in qualchì locu, forsi, qualcosa altru. Perchè nò?
Assumimu, per esse chjaru, chì questu hè sempre a continuità di serviziu (questu era u casu in tutte e cumpagnie induve aghju travagliatu).
Allora avete bisognu di principià cù l'equipaggiu. Eccu un elencu di temi per attente à:
- classificazione di l'equipaggiu per u gradu di criticità
- copia di salvezza di l'equipaggiu criticu
- supportu, licenze
Avete bisognu di pensà à i pussibuli scenarii di fallimentu, in particulare cù l'equipaggiu in cima di a vostra classificazione di criticità. Di solitu, a pussibilità di doppiu prublemi hè trascurata, altrimenti a vostra suluzione è u supportu pò esse diventate irragionevolmente caru, ma in u casu di elementi di rete veramente critichi, u fallimentu di quale puderia influenzà significativamente l'affari, avete da pensà à questu.
Esempiu:
Dicemu chì parlemu di un switch radicali in un centru di dati.
Siccomu avemu accunsentutu chì a continuità di u serviziu hè u criteriu più impurtante, hè ragiunate per furnisce una copia di salvezza "calda" (redundanza) di stu equipamentu. Ma questu hè micca tuttu. Avete ancu bisognu di decide quantu tempu, se u primu switch si rompe, hè accettatu per voi di campà cù un solu switch restante, perchè ci hè u risicu chì si rompe ancu.
Impurtante! Ùn avete micca bisognu di decisu stu prublema sè stessu. Duvete descriverà i risichi, i pussibuli suluzioni è i costi per a gestione o a gestione di a cumpagnia. Hanu da piglià decisioni.
Allora, s'ellu hè statu decisu chì, datu a piccula probabilità di un doppiu fallimentu, travaglià per 4 ore nantu à un interruttore hè, in principiu, accettabile, allura pudete simpricimenti piglià u supportu adattatu (sicondu chì l'equipaggiu serà rimpiazzatu in 4). ore).
Ma ci hè un risicu chì ùn anu micca rializatu. Sfurtunatamente, avemu trovu una volta in una tale situazione. Invece di quattru ore, l'equipaggiu hà viaghjatu per una settimana !!!
Per quessa, stu risicu ancu deve esse discutitu è, forsi, serà più currettu per voi per cumprà un altru switch (terzu) è mantene in un pacchettu di pezzi di ricambio (copia di salvezza "frid") o l'utilizanu per u laboratoriu.
Impurtante! Fate un spreadsheet di tuttu u supportu chì avete cù e date di scadenza è aghjunghje à u vostru calendariu per avè un email almenu un mesi in anticipu chì duvete cumincià à preoccupassi di rinnuvà u vostru supportu.
Ùn vi sarà micca perdonatu s'ellu vi scurdate di rinnuvà u vostru supportu è u ghjornu dopu finisce u vostru hardware rompe.
U travagliu d'urgenza
Qualunque cosa succede in a vostra reta, idealmente duvete mantene l'accessu à u vostru equipamentu di rete.
Impurtante! Duvete avè l'accessu di cunsola à tutti l'equipaggiu è questu accessu ùn deve micca dipende da a salute di a reta di dati di l'utilizatori.
Avete ancu avè previstu pussibuli scenarii negativi in anticipu è documentà l'azzioni necessarii. A dispunibilità di stu documentu hè ancu criticu, perchè ùn deve micca solu esse publicatu nantu à una risorsa cumuni per u dipartimentu, ma ancu salvatu in u locu in l'urdinatori di l'ingegneri.
Ci deve esse
- infurmazione necessaria per apre un bigliettu cù supportu di venditore o integratore
- infurmazione nantu à cumu ghjunghje à qualsiasi equipamentu (console, gestione)
Di sicuru, pò ancu cuntene ogni altra infurmazione utile, per esempiu, una descrizzione di a prucedura di aghjurnamentu per diversi equipaghji è cumandamenti di diagnostichi utili.
Партнеры
Avà avete bisognu di valutà i risichi assuciati cù i partenarii. Di solitu questu
- Fornitori di Internet è punti di scambiu di trafficu (IX)
- fornitori di canali di cumunicazione
Chì dumande duvete dumandà sè stessu? Cum'è cù l'equipaggiu, diversi scenarii d'emergenza deve esse cunsideratu. Per esempiu, per i fornituri di Internet, puderia esse qualcosa cum'è:
- chì succede se u fornitore di Internet X cessà di furnisce u serviziu per una certa ragione?
- L'altri fornituri anu abbastanza larghezza di banda per voi?
- Quantu serà bona a cunnessione?
- Quantu indipindenti sò i vostri fornituri d'Internet è un seriu outage di unu d'elli causarà prublemi cù l'altri?
- quanti input ottici in u vostru centru di dati?
- chì succede se unu di l'inputs hè cumplettamente distruttu?
In quantu à l'inputs, in a mo pratica in duie cumpagnie diverse, in dui centri di dati diffirenti, un escavatore hà distruttu pozzi è solu per miraculu a nostra ottica ùn era micca affettata. Questu ùn hè micca un casu cusì raru.
E, sicuru, ùn avete micca solu dumandà queste dumande, ma, di novu, cù u sustegnu di a gestione, per furnisce una suluzione accettabile in ogni situazione.
Backup
A prossima priorità pò esse una copia di salvezza di e cunfigurazioni di l'equipaggiu. In ogni casu, questu hè un puntu assai impurtante. Ùn vi elencu micca quelli casi quandu pudete perde a cunfigurazione; hè megliu fà una copia di salvezza regulare è ùn pensate micca. Inoltre, e copie di salvezza regulare ponu esse assai utili in u seguimentu di i cambiamenti.
Impurtante! Fate una copia di salvezza ogni ghjornu. Questu ùn hè micca cusì grande quantità di dati per salvà nantu à questu. In a matina, l'ingegnere di turnu (o voi) deve riceve un rapportu da u sistema, chì indica chjaramente se a copia di salvezza hè stata successu o micca, è se a copia di salvezza ùn hè micca successu, u prublema deve esse risolta o un bigliettu deve esse creatu ( vede i prucessi di u dipartimentu di a rete).
Versioni di u software
A quistione di s'ellu vale a pena aghjurnà u software di l'equipaggiu ùn hè micca cusì chjaru. Da una banda, e versioni antichi sò cunnisciuti bugs è vulnerabili, ma da l'altra banda, u novu software hè, prima, micca sempre una prucedura d'aghjurnamentu indolore, è in segundu, novi bug è vulnerabili.
Quì avete bisognu di truvà a megliu opzione. Uni pochi cunsiglii evidenti
- stallà solu versioni stabili
- Eppuru, ùn deve micca campà nantu à versioni assai vechji di software
- fate un segnu cù infurmazione nantu à induve si trova qualchì software
- leghje periodicamente rapporti nantu à vulnerabili è bug in versioni di software, è in casu di prublemi critichi, duvete pensà à l'aghjurnamentu
À questu stadiu, avè l'accessu di cunsola à l'equipaggiu, infurmazione nantu à u supportu è una descrizzione di a prucedura di aghjurnamentu, site, in principiu, prontu per questu passu. L'opzione ideale hè quandu avete l'equipaggiu di laboratoriu induve pudete verificà tutta a prucedura, ma, sfurtunatamenti, questu ùn succede micca spessu.
In u casu di l'equipaggiu criticu, pudete cuntattà u supportu di u venditore cù una dumanda per aiutà vi cù l'aghjurnamentu.
Sistema di bigliettu
Avà pudete guardà intornu. Avete bisognu di stabilisce prucessi per l'interazzione cù altri dipartimenti è in u dipartimentu.
Questu pò esse micca necessariu (per esempiu, se a vostra cumpagnia hè chjuca), ma ricumandemu assai di urganizà u travagliu in modu chì tutti i travaglii esterni è interni passanu per u sistema di bigliettu.
U sistema di u bigliettu hè essenzialmente a vostra interfaccia per cumunicazioni interna è esterna, è duvete descriverà sta interfaccia in abbastanza dettagliu.
Pigliemu un esempiu di un compitu impurtante è cumunu di apertura di l'accessu. Descriveraghju un algoritmu chì hà travagliatu perfettamente in una di e cumpagnie.
Esempiu:
Cuminciamu cù u fattu chì spessu accede à i clienti formulanu i so desideri in una lingua incomprensibile per un ingegnere di rete, vale à dì, in a lingua di l'applicazione, per esempiu, "dammi accessu à 1C".
Dunque, ùn avemu mai accettatu dumande direttamente da tali utilizatori.
È questu era u primu requisitu
- e dumande d'accessu duveranu vene da i dipartimenti tecnichi (in u nostru casu, questi eranu Unix, Windows, ingegneri di helpdesk)
U secondu requisitu hè questu
- stu accessu deve esse registratu (da u dipartimentu tecnicu da quale avemu ricevutu sta dumanda) è cum'è una dumanda ricevemu un ligame à questu accessu logged
A forma di sta dumanda deve esse comprensibile per noi, i.e.
- a dumanda deve cuntene infurmazione nantu à quale subnet è à quale l'accessu subnet deve esse apertu, è ancu u protocolu è (in u casu di tcp / udp) porti
Hè ancu esse indicatu quì
- descrizzione di perchè stu accessu hè apertu
- temporale o permanente (se temporanea, finu à quale data)
È un puntu assai impurtante hè l'appruvazioni
- da u capu di u dipartimentu chì hà iniziatu l'accessu (per esempiu, contabilità)
- da u capu di u dipartimentu tecnicu, da induve sta dumanda hè ghjunta à u dipartimentu di a rete (per esempiu, helpdesk)
In questu casu, u "proprietariu" di questu accessu hè cunsideratu cum'è u capu di u dipartimentu chì hà iniziatu l'accessu (cuntabili in u nostru esempiu), è hè rispunsevule per assicurà chì a pagina cù accessu logged per questu dipartimentu resta à ghjornu. .
Logging
Questu hè qualcosa chì pudete affucà. Ma s'è vo vulete implementà un accostu proattivu, allura vi tocca à amparà à trattà cù stu diluve di dati.
Eccu alcuni cunsiglii pratichi:
- avete bisognu di rivisione i logs ogni ghjornu
- in u casu di una rivisione pianificata (è micca una situazione d'urgenza), pudete limità à i livelli di gravità 0, 1, 2 è aghjunghje mudelli selezziunati da altri livelli se cunsiderà necessariu.
- scrivite un script chì analizza i logs è ignora quelli logs chì i mudelli chì avete aghjustatu à a lista d'ignore
Stu approcciu vi permetterà, cù u tempu, di creà una lista ignurata di logs chì ùn sò micca interessanti per voi è lasciate solu quelli chì veramente cunsiderà impurtanti.
Hà travagliatu bè per noi.
Monitoramentu
Ùn hè pocu cumu per una cumpagnia di manca di un sistema di surviglianza. Pudete, per esempiu, s'appoghjanu nantu à i logs, ma l'equipaggiu pò solu "morte" senza avè u tempu di "dice" nunda, o u pacchettu udp syslog protokollu pò esse persu è ùn ghjunghje micca. In generale, sicuru, u monitoraghju attivu hè impurtante è necessariu.
I dui esempii più populari in a mo pratica:
- surviglianza di a carica di i canali di cumunicazione, ligami critichi (per esempiu, cunnessione à i fornituri). Permettenu di vede in modu proattivu u prublema potenziale di a degradazione di u serviziu per via di a perdita di trafficu è, dunque, evitari.
- grafici basati nantu à NetFlow. Facenu fàciule per truvà anomalie in u trafficu è sò assai utili per a deteczione di certi tipi simplici ma significativi di attacchi di pirate.
Impurtante! Configurate notificazioni SMS per l'avvenimenti più critichi. Questu hè applicà à u monitoraghju è à u logu. Se ùn avete micca un turnu di serviziu, i sms duveranu ancu ghjunghje fora di l'ore di travagliu.
Pensate à u prucessu in tale manera di ùn svegliate micca tutti l'ingegneri. Avemu avutu un ingegnere di turnu per questu.
Cambia u cuntrollu
In my opinion, ùn hè micca necessariu di cuntrullà tutti i cambiamenti. Ma, in ogni casu, duvete esse capace, se ne necessariu, di truvà facilmente quale hà fattu certi cambiamenti in a reta è perchè.
Alcuni consigli:
- Aduprate un sistema di bigliettu per detallà ciò chì hè statu fattu nantu à quellu bigliettu, per esempiu copiendu a cunfigurazione applicata in u bigliettu
- aduprate capacità di cumentu nantu à l'equipaggiu di rete (per esempiu, cummentate cummentarii nantu à Juniper). Pudete scrive u numeru di u bigliettu
- utilizate diff di e vostre backups di cunfigurazione
Pudete implementà questu cum'è un prucessu, rivisendu tutti i biglietti ogni ghjornu per i cambiamenti.
I prucessi
Avete bisognu di furmalizà è discrive i prucessi in a vostra squadra. Sè avete ghjuntu à questu puntu, allora a vostra squadra duveria digià avè almenu i seguenti prucessi in esecuzione:
I prucessi di ogni ghjornu:
- travaglià cù i biglietti
- travaglià cù logs
- cambià u cuntrollu
- fogliu di cuntrollu di ogni ghjornu
Prucessi annuali:
- estensione di garanzie, licenze
Processi asincroni:
- risposta à diverse situazioni di emergenza
Conclusioni di a prima parte
Avete nutatu chì tuttu questu ùn hè ancu di cunfigurazione di a rete, micca di cuncepimentu, micca di protokolli di rete, micca di routing, micca di sicurità... Hè qualcosa intornu. Ma questi, ancu s'è forse boring, sò, sicuru, elementi assai impurtanti di u travagliu di una divisione di rete.
Finu a ora, cum'è pudete vede, ùn avete micca migliuratu nunda in a vostra reta. S'ellu ci era vulnerabilità di sicurezza, allora restavanu; s'ellu ci era un cattivu disignu, allora restava. Finu à avè applicatu e vostre cumpetenze è cunniscenze cum'è un ingegnere di rete, nantu à quale avete assai prubabilmente passatu una grande quantità di tempu, sforzu, è qualchì volta soldi. Ma prima avete bisognu di creà (o rinfurzà) a fundazione, è dopu principià a custruzzione.
E seguenti parti vi diceranu cumu truvà è eliminà l'errori, è dopu migliurà a vostra infrastruttura.
Di sicuru, ùn avete micca bisognu di fà tuttu in sequenza. U tempu pò esse criticu. Fate in parallelu se i risorse permettenu.
È un aghjuntu impurtante. Comunicate, dumandate, cunsultate cù a vostra squadra. In fine, sò quelli chì sustenenu è facenu tuttu questu.
Source: www.habr.com