Aquest article és el primer d'una sèrie d'articles "Com prendre el control de la vostra infraestructura de xarxa". Es pot trobar el contingut de tots els articles de la sèrie i els enllaços .
Admeto plenament que hi ha un nombre suficient d'empreses on un temps d'inactivitat de la xarxa d'una hora o fins i tot un dia no és crític. Per desgràcia o per sort, no vaig tenir l'oportunitat de treballar en aquests llocs. Però, per descomptat, les xarxes són diferents, els requisits són diferents, els enfocaments són diferents i, tanmateix, d'una forma o una altra, la llista següent en molts casos serà realment un "imprescindible".
Per tant, les condicions inicials.
Estàs en una feina nova, has rebut una promoció o has decidit fer una nova mirada a les teves responsabilitats. La xarxa de l'empresa és la teva àrea de responsabilitat. Per a tu, això és en molts aspectes un repte i nou, que justifica una mica el to de mentoria d'aquest article :). Però espero que l'article també pugui ser útil a qualsevol enginyer de xarxes.
El vostre primer objectiu estratègic és aprendre a resistir l'entropia i mantenir el nivell de servei prestat.
Molts dels problemes que es descriuen a continuació es poden resoldre per diferents mitjans. Deliberadament no plantejo el tema de la implementació tècnica, perquè... en principi, sovint no és tan important com heu resolt aquest o aquell problema, però l'important és com l'utilitzeu i si ho feu servir. Per exemple, el vostre sistema de monitorització creat professionalment no serveix de res si no el mireu i no responeu a les alertes.
Оборудование
Primer cal entendre on són els riscos més grans.
De nou, pot ser diferent. Admeto que en algun lloc, per exemple, seran qüestions de seguretat, i en algun lloc, qüestions relacionades amb la continuïtat del servei, i en algun lloc, potser, alguna cosa més. Perquè no?
Suposem, que quedi clar, que això encara és continuïtat del servei (això va ser el cas de totes les empreses on vaig treballar).
Aleshores cal començar amb l'equip. Aquí teniu una llista de temes als quals cal prestar atenció:
- Classificació dels equips segons el grau de criticitat
- còpia de seguretat dels equips crítics
- suport, llicències
Heu de pensar en possibles escenaris de fallada, especialment amb equips al capdavant de la vostra classificació de criticitat. En general, es descuiden la possibilitat de problemes dobles, en cas contrari, la vostra solució i el vostre suport poden arribar a ser excessivament cars, però en el cas d'elements de xarxa realment crítics, la fallada dels quals podria afectar significativament el negoci, hauríeu de pensar-hi.
Exemple
Suposem que estem parlant d'un commutador d'arrel en un centre de dades.
Com que vam acordar que la continuïtat del servei és el criteri més important, és raonable proporcionar una còpia de seguretat "calenta" (redundància) d'aquest equip. Però això no és tot. També heu de decidir quant de temps, si es trenca el primer interruptor, és acceptable que visqueu amb només un interruptor restant, perquè hi ha el risc que també es trenqui.
Important! No cal que decidiu aquest tema vosaltres mateixos. Heu de descriure els riscos, les possibles solucions i els costos per a la direcció o la direcció de l'empresa. Han de prendre decisions.
Per tant, si es va decidir que, donada la petita probabilitat d'una fallada doble, treballar durant 4 hores en un interruptor és, en principi, acceptable, simplement podeu prendre el suport adequat (segons el qual l'equip es substituirà en 4 hores).
Però hi ha el risc que no ho facin. Malauradament, una vegada ens vam trobar en una situació així. En lloc de quatre hores, l'equip va viatjar durant una setmana!!!
Per tant, també s'ha de parlar d'aquest risc i, potser, serà més correcte comprar un altre interruptor (tercer) i guardar-lo en un paquet de recanvis (còpia de seguretat "fred") o utilitzar-lo amb finalitats de laboratori.
Important! Fes un full de càlcul de tot el suport que tens amb dates de caducitat i afegiu-lo al vostre calendari perquè rebeu un correu electrònic amb almenys un mes d'antelació que us hauríeu de començar a preocupar per renovar el vostre suport.
No se us perdonarà si oblideu renovar el vostre suport i l'endemà que finalitzi el vostre maquinari es trenca.
Treball d'emergència
Passi el que passi a la vostra xarxa, l'ideal és mantenir l'accés al vostre equip de xarxa.
Important! Heu de tenir accés a la consola a tots els equips i aquest accés no hauria de dependre de la salut de la xarxa de dades de l'usuari.
També hauríeu de preveure amb antelació possibles escenaris negatius i documentar les accions necessàries. La disponibilitat d'aquest document també és fonamental, per la qual cosa no només s'ha de publicar en un recurs compartit per al departament, sinó també desar-lo localment als ordinadors dels enginyers.
Hi ha d'haver
- informació necessària per obrir un bitllet amb el suport del venedor o de l'integrador
- informació sobre com arribar a qualsevol equip (consola, gestió)
Per descomptat, també pot contenir qualsevol altra informació útil, per exemple, una descripció del procediment d'actualització de diversos equips i ordres de diagnòstic útils.
Afiliats
Ara cal avaluar els riscos associats als socis. Normalment això
- Proveïdors d'Internet i punts d'intercanvi de trànsit (IX)
- proveïdors de canals de comunicació
Quines preguntes t'has de fer? Igual que amb els equips, s'han de considerar diferents escenaris d'emergència. Per exemple, per als proveïdors d'Internet, podria ser alguna cosa com:
- Què passa si el proveïdor d'Internet X deixa de proporcionar-te servei per algun motiu?
- Altres proveïdors tindran prou amplada de banda per a tu?
- Fins a quin punt es mantindrà la connectivitat?
- Què tan independents són els vostres proveïdors d'Internet i una interrupció greu d'un d'ells causarà problemes amb els altres?
- quantes entrades òptiques al vostre centre de dades?
- què passarà si una de les entrades es destrueix completament?
Pel que fa als inputs, a la meva pràctica en dues empreses diferents, en dos centres de dades diferents, una excavadora va destruir pous i només per miracle no es va veure afectada la nostra òptica. Aquest no és un cas tan rar.
I, per descomptat, no només cal fer aquestes preguntes, sinó, de nou, amb el suport de la direcció, oferir una solució acceptable en qualsevol situació.
Còpia de seguretat
La següent prioritat pot ser una còpia de seguretat de les configuracions de l'equip. En qualsevol cas, aquest és un punt molt important. No enumeraré els casos en què podeu perdre la configuració; és millor fer còpies de seguretat periòdiques i no pensar-hi. A més, les còpies de seguretat periòdiques poden ser molt útils per controlar els canvis.
Important! Feu còpies de seguretat diàriament. Aquesta no és una quantitat tan gran de dades per estalviar-hi. Al matí, l'enginyer de guàrdia (o vostè) hauria de rebre un informe del sistema, que indiqui clarament si la còpia de seguretat ha tingut èxit o no, i si la còpia de seguretat no ha tingut èxit, s'hauria de resoldre el problema o s'hauria de crear un bitllet ( veure processos del departament de xarxa).
Versions de programari
La qüestió de si val la pena o no actualitzar el programari de l'equip no és tan clara. D'una banda, les versions antigues són errors i vulnerabilitats coneguts, però d'altra banda, el nou programari és, en primer lloc, no sempre un procediment d'actualització indolor, i en segon lloc, nous errors i vulnerabilitats.
Aquí has de trobar la millor opció. Unes quantes recomanacions òbvies
- instal·leu només versions estables
- Tot i així, no hauríeu de viure amb versions molt antigues de programari
- feu un cartell amb informació sobre on es troba algun programari
- Llegiu periòdicament informes sobre vulnerabilitats i errors en versions de programari i, en cas de problemes crítics, hauríeu de pensar en actualitzar
En aquesta etapa, tenint accés a la consola a l'equip, informació sobre el suport i una descripció del procediment d'actualització, en principi esteu preparat per a aquest pas. L'opció ideal és quan es disposa d'un equip de laboratori on es pot comprovar tot el procediment, però, malauradament, això no passa sovint.
En el cas d'equips crítics, podeu contactar amb el servei d'assistència del venedor amb una sol·licitud per ajudar-vos amb l'actualització.
Sistema de bitllets
Ara pots mirar al teu voltant. Cal establir processos d'interacció amb altres departaments i dins del departament.
Pot ser que això no sigui necessari (per exemple, si la vostra empresa és petita), però us recomano molt organitzar el treball de manera que totes les tasques externes i internes passin pel sistema de tickets.
El sistema de bitllets és essencialment la vostra interfície per a comunicacions internes i externes, i hauríeu de descriure aquesta interfície amb prou detall.
Prenguem un exemple d'una tasca important i comuna d'obrir l'accés. Descriuré un algorisme que va funcionar perfectament en una de les empreses.
Exemple
Comencem pel fet que sovint els clients d'accés formulen els seus desitjos en un llenguatge incomprensible per a un enginyer de xarxa, és a dir, en l'idioma de l'aplicació, per exemple, "doneu-me accés a 1C".
Per tant, mai hem acceptat sol·licituds directament d'aquests usuaris.
I aquest va ser el primer requisit
- les sol·licituds d'accés haurien de provenir dels departaments tècnics (en el nostre cas eren enginyers d'unix, windows, helpdesk)
El segon requisit és això
- aquest accés ha de ser registrat (pel departament tècnic del qual hem rebut aquesta sol·licitud) i com a sol·licitud rebem un enllaç a aquest accés registrat.
La forma d'aquesta sol·licitud ha de ser entenedora per a nosaltres, és a dir.
- la sol·licitud ha de contenir informació sobre quina subxarxa i a quina subxarxa ha d'estar oberta l'accés, així com el protocol i els ports (en el cas de tcp/udp).
També s'ha d'indicar allà
- descripció de per què s'obre aquest accés
- temporal o permanent (si és temporal, fins a quina data)
I un punt molt important són les aprovacions
- del cap del departament que va iniciar l'accés (per exemple, comptabilitat)
- del cap del departament tècnic, d'on va arribar aquesta sol·licitud al departament de xarxa (per exemple, servei d'assistència)
En aquest cas, el "titular" d'aquest accés es considera el responsable del departament que va iniciar l'accés (comptant en el nostre exemple), i s'encarrega de garantir que la pàgina amb accés registrat d'aquest departament es mantingui actualitzada. .
Enregistrament
Això és una cosa que et pots ofegar. Però si voleu implementar un enfocament proactiu, heu d'aprendre a fer front a aquest diluvi de dades.
Aquí teniu algunes recomanacions pràctiques:
- heu de revisar els registres diàriament
- en el cas d'una revisió planificada (i no d'una situació d'emergència), podeu limitar-vos als nivells de gravetat 0, 1, 2 i afegir patrons seleccionats d'altres nivells si ho considereu necessari
- escriviu un script que analitzi els registres i ignori aquells registres els patrons dels quals heu afegit a la llista d'ignorar
Aquest enfocament us permetrà, amb el temps, crear una llista ignorada de registres que no us interessen i deixar només aquells que considereu realment importants.
Ens va funcionar molt bé.
Seguiment
No és estrany que una empresa no tingui un sistema de seguiment. Podeu, per exemple, confiar en els registres, però l'equip pot simplement "morir" sense tenir temps de "dir" res, o el paquet de protocol udp syslog es pot perdre i no arribar. En general, és clar, un seguiment actiu és important i necessari.
Els dos exemples més populars a la meva pràctica:
- supervisió de la càrrega dels canals de comunicació, enllaços crítics (per exemple, connexió amb proveïdors). Permeten veure de manera proactiva el possible problema de degradació del servei per pèrdua de trànsit i, en conseqüència, evitar-lo.
- gràfics basats en NetFlow. Faciliten la recerca d'anomalies en el trànsit i són molt útils per detectar alguns tipus d'atacs de pirates informàtics senzills però significatius.
Important! Configura notificacions per SMS per als esdeveniments més crítics. Això s'aplica tant al seguiment com al registre. Si no teniu un torn de servei, els sms també haurien d'arribar fora de l'horari laboral.
Penseu en el procés de manera que no despertar tots els enginyers. Teníem un enginyer de servei per a això.
Canvia el control
Al meu entendre, no cal controlar tots els canvis. Però, en qualsevol cas, hauríeu de poder, si cal, trobar fàcilment qui ha fet determinats canvis a la xarxa i per què.
Alguns consells:
- utilitzeu un sistema de bitllets per detallar què es va fer en aquest bitllet, per exemple, copiant la configuració aplicada al bitllet
- utilitzar les capacitats de comentaris a l'equip de xarxa (per exemple, fer comentaris a Juniper). Podeu anotar el número del bitllet
- utilitzeu diff de les vostres còpies de seguretat de configuració
Podeu implementar-ho com un procés, revisant tots els bitllets diàriament per veure'n els canvis.
Процессы
Has de formalitzar i descriure els processos del teu equip. Si heu arribat a aquest punt, el vostre equip ja hauria de tenir almenys els processos següents en execució:
Processos diaris:
- treballant amb bitllets
- treballant amb registres
- control de canvis
- full de control diari
Processos anuals:
- ampliació de garanties, llicències
Processos asíncrons:
- resposta a diferents situacions d'emergència
Conclusió de la primera part
T'has adonat que tot això encara no és de configuració de xarxa, ni de disseny, ni de protocols de xarxa, ni d'encaminament, ni de seguretat... Hi ha alguna cosa. Però aquests, encara que potser avorrits, són, per descomptat, elements molt importants del treball d'una divisió en xarxa.
Fins ara, com podeu veure, no heu millorat res a la vostra xarxa. Si hi havia vulnerabilitats de seguretat, romanien; si hi havia un mal disseny, es mantenia. Fins que no hagis aplicat les teves habilitats i coneixements com a enginyer de xarxes, en els quals probablement hagis dedicat una gran quantitat de temps, esforç i, de vegades, diners. Però primer cal crear (o reforçar) la base i després començar la construcció.
Les parts següents us indicaran com trobar i eliminar errors i, a continuació, millorar la vostra infraestructura.
Per descomptat, no cal que ho feu tot de manera seqüencial. El temps pot ser crític. Feu-ho en paral·lel si els recursos ho permeten.
I un afegit important. Comunicar, preguntar, consultar amb el seu equip. Al final, són ells els que donen suport i fan tot això.
Font: www.habr.com