Este artigo é o primeiro dunha serie de artigos "Como tomar o control da túa infraestrutura de rede". Pódense atopar os contidos de todos os artigos da serie e as ligazóns .
Admito plenamente que hai un número suficiente de empresas nas que un tempo de inactividade da rede dunha hora ou mesmo un día non é crítico. Por desgraza ou por sorte, non tiven a oportunidade de traballar neses lugares. Pero, por suposto, as redes son diferentes, os requisitos son diferentes, os enfoques son diferentes e, sen embargo, dunha forma ou doutra, a lista de abaixo en moitos casos será realmente un "imprescindible".
Entón, as condicións iniciais.
Estás nun novo traballo, recibiches un ascenso ou decidiches revisar as túas responsabilidades. A rede da empresa é a súa área de responsabilidade. Para ti, isto é en moitos sentidos un reto e novo, o que xustifica un pouco o ton de mentor deste artigo :). Pero espero que o artigo tamén poida ser útil para calquera enxeñeiro de rede.
O seu primeiro obxectivo estratéxico é aprender a resistir a entropía e manter o nivel de servizo prestado.
Moitos dos problemas descritos a continuación pódense resolver por varios medios. Non abordo deliberadamente o tema da implementación técnica, porque... en principio, moitas veces non é tan importante como resolveches este ou aquel problema, pero o importante é como o usas e se o usas en absoluto. Por exemplo, o teu sistema de vixilancia construído profesionalmente non serve de nada se non o miras e non respondes ás alertas.
Оборудование
Primeiro cómpre comprender onde están os maiores riscos.
De novo, pode ser diferente. Admito que nalgún lugar, por exemplo, serán cuestións de seguridade, e nalgún lugar, cuestións relacionadas coa continuidade do servizo, e nalgún lugar, quizais, outra cousa. Por que non?
Supoñamos, para que quede claro, que isto aínda é continuidade de servizo (así foi o caso de todas as empresas nas que traballei).
Entón cómpre comezar co equipo. Aquí tes unha lista de temas aos que prestar atención:
- clasificación dos equipamentos segundo o grao de criticidade
- copia de seguridade dos equipos críticos
- soporte, licenzas
Debe pensar en posibles escenarios de fallo, especialmente cos equipos na parte superior da súa clasificación de criticidade. Normalmente, escóitase a posibilidade de problemas dobres, se non, a súa solución e soporte poden chegar a ser excesivamente caros, pero no caso de elementos de rede verdadeiramente críticos, cuxo fallo pode afectar significativamente ao negocio, debes pensar niso.
Exemplo
Digamos que estamos a falar dun interruptor raíz nun centro de datos.
Dado que acordamos que a continuidade do servizo é o criterio máis importante, é razoable proporcionar unha copia de seguridade "quente" (redundancia) deste equipo. Pero iso non é todo. Tamén cómpre decidir canto tempo, se se rompe o primeiro interruptor, é aceptable vivir con só un interruptor restante, porque existe o risco de que tamén se rompa.
Importante! Non tes que decidir ti mesmo este asunto. Debe describir os riscos, as posibles solucións e os custos para a dirección ou a dirección da empresa. Deben tomar decisións.
Entón, se se decidiu que, dada a pequena probabilidade dun dobre fallo, traballar durante 4 horas nun interruptor é, en principio, aceptable, entón pode simplemente tomar o apoio adecuado (segundo o que o equipo será substituído dentro de 4 horas).
Pero existe o risco de que non o fagan. Por desgraza, unha vez nos atopamos nunha situación así. En lugar de catro horas, o equipo viaxou unha semana!!!
Polo tanto, este risco tamén debe ser discutido e, quizais, será máis correcto que compre outro interruptor (terceiro) e mantelo nun paquete de recambios (copia de seguridade "en frío") ou o use para fins de laboratorio.
Importante! Fai unha folla de cálculo de todo o soporte que tes con datas de caducidade e engádeo ao teu calendario para que recibas un correo electrónico polo menos cun mes de antelación no que deberías empezar a preocuparte pola renovación do teu soporte.
Non se lle perdoará se esquece renovar o seu soporte e ao día seguinte de que remate o seu hardware rompe.
Traballos de emerxencia
Pase o que pase na súa rede, o ideal é manter o acceso ao seu equipo de rede.
Importante! Debes ter acceso á consola a todos os equipos e este acceso non debe depender da saúde da rede de datos do usuario.
Tamén debe prever posibles escenarios negativos con antelación e documentar as accións necesarias. A dispoñibilidade deste documento tamén é fundamental, polo que non só debería publicarse nun recurso compartido para o departamento, senón tamén gardarse localmente nos ordenadores dos enxeñeiros.
Debe haber
- información necesaria para abrir un ticket co soporte do vendedor ou do integrador
- información sobre como chegar a calquera equipo (consola, xestión)
Por suposto, tamén pode conter calquera outra información útil, por exemplo, unha descrición do procedemento de actualización de varios equipos e comandos de diagnóstico útiles.
Afiliados
Agora cómpre avaliar os riscos asociados aos socios. Normalmente isto
- Provedores de Internet e puntos de intercambio de tráfico (IX)
- provedores de canles de comunicación
Que preguntas debes facerte? Do mesmo xeito que co equipamento, hai que considerar diferentes escenarios de emerxencia. Por exemplo, para os provedores de Internet, podería ser algo así como:
- que pasa se o provedor de Internet X deixa de ofrecerche o servizo por algún motivo?
- Terán o ancho de banda suficiente para ti outros provedores?
- Que boa será a conectividade?
- Que independentes son os teus provedores de Internet e unha interrupción grave dun deles causará problemas cos outros?
- cantas entradas ópticas no seu centro de datos?
- que pasará se unha das entradas é completamente destruída?
Respecto aos insumos, na miña práctica en dúas empresas diferentes, en dous centros de datos diferentes, unha escavadora destruíu pozos e só por milagre non se viu afectada a nosa óptica. Este non é un caso tan raro.
E, por suposto, cómpre non só facer estas preguntas, senón, de novo, co apoio da dirección, proporcionar unha solución aceptable en calquera situación.
Copia de seguranza
A seguinte prioridade pode ser unha copia de seguridade das configuracións do equipo. En calquera caso, este é un punto moi importante. Non vou enumerar os casos nos que pode perder a configuración; é mellor facer copias de seguridade regulares e non pensar niso. Ademais, as copias de seguridade regulares poden ser moi útiles para supervisar os cambios.
Importante! Fai copias de seguridade diariamente. Esta non é unha cantidade tan grande de datos para aforrar isto. Pola mañá, o enxeñeiro de servizo (ou vostede) debería recibir un informe do sistema, que indique claramente se a copia de seguranza foi exitosa ou non, e se a copia de seguridade non foi exitosa, o problema debe resolverse ou debe crearse un ticket ( ver procesos do departamento de rede).
Versións de software
A cuestión de se paga a pena ou non actualizar o software do equipo non é tan clara. Por unha banda, as versións antigas son erros e vulnerabilidades coñecidos, pero, por outra banda, o software novo é, en primeiro lugar, non sempre un procedemento de actualización indolor e, en segundo lugar, novos erros e vulnerabilidades.
Aquí tes que atopar a mellor opción. Algunhas recomendacións obvias
- instalar só versións estables
- Aínda así, non deberías vivir con versións de software moi antigas
- facer un sinal con información sobre onde se atopa algún software
- ler periodicamente informes sobre vulnerabilidades e erros nas versións de software e, en caso de problemas críticos, debería pensar en actualizar
Nesta fase, tendo acceso á consola ao equipo, información sobre soporte e unha descrición do procedemento de actualización, estás, en principio, preparado para este paso. A opción ideal é cando tes equipos de laboratorio onde podes comprobar todo o procedemento, pero, por desgraza, isto non ocorre a miúdo.
No caso de equipos críticos, podes contactar co servizo de asistencia do vendedor cunha solicitude para axudarche coa actualización.
Sistema de tickets
Agora podes mirar ao redor. Debe establecer procesos de interacción con outros departamentos e dentro do departamento.
Isto pode non ser necesario (por exemplo, se a túa empresa é pequena), pero recomendo encarecidamente organizar o traballo de forma que todas as tarefas externas e internas pasen polo sistema de tickets.
O sistema de tickets é esencialmente a túa interface para as comunicacións internas e externas, e deberías describir esta interface con suficiente detalle.
Poñamos un exemplo dunha tarefa importante e común de abrir o acceso. Vou describir un algoritmo que funcionou perfectamente nunha das empresas.
Exemplo
Comecemos polo feito de que a miúdo os clientes de acceso formulan os seus desexos nun idioma incomprensible para un enxeñeiro de rede, é dicir, no idioma da aplicación, por exemplo, "dáme acceso a 1C".
Polo tanto, nunca aceptamos solicitudes directamente destes usuarios.
E ese era o primeiro requisito
- as solicitudes de acceso deberían vir dos departamentos técnicos (no noso caso eran enxeñeiros de Unix, Windows, Helpdesk)
O segundo requisito é que
- este acceso debe estar rexistrado (polo departamento técnico do que recibimos esta solicitude) e como solicitude recibimos unha ligazón a este acceso rexistrado
A forma desta solicitude debe ser comprensible para nós, é dicir.
- a solicitude debe conter información sobre que subrede e a que subrede debe estar aberto o acceso, así como o protocolo e (no caso de tcp/udp) portos
Tamén hai que indicalo alí
- descrición de por que se abre este acceso
- temporal ou permanente (se é temporal, ata que data)
E un punto moi importante son as aprobacións
- do xefe do departamento que iniciou o acceso (por exemplo, contabilidade)
- do xefe do departamento técnico, de onde chegou esta solicitude ao departamento de rede (por exemplo, servizo de asistencia)
Neste caso, considérase que o "titular" deste acceso é o xefe do departamento que iniciou o acceso (contando no noso exemplo), e é o responsable de garantir que a páxina con acceso rexistrado para este departamento estea actualizada. .
Rexistro
Isto é algo no que podes afogar. Pero se queres implementar un enfoque proactivo, entón tes que aprender a xestionar este diluvio de datos.
Aquí tes algunhas recomendacións prácticas:
- cómpre revisar os rexistros diariamente
- no caso dunha revisión planificada (e non dunha situación de emerxencia), pode limitarse aos niveis de gravidade 0, 1, 2 e engadir patróns seleccionados doutros niveis se o considera necesario
- escriba un script que analice os rexistros e ignore aqueles rexistros cuxos patróns engadiu á lista de ignorados
Este enfoque permitirache, co paso do tempo, crear unha lista ignorada de rexistros que non che resulten interesantes e deixar só aqueles que realmente consideres importantes.
Funcionou moi ben para nós.
Seguimento
Non é raro que unha empresa careza dun sistema de vixilancia. Podes, por exemplo, confiar nos rexistros, pero o equipo pode simplemente "morrer" sen ter tempo para "dicir" nada, ou o paquete do protocolo udp syslog pode perderse e non chegar. En xeral, por suposto, un seguimento activo é importante e necesario.
Os dous exemplos máis populares na miña práctica:
- supervisar a carga das canles de comunicación, enlaces críticos (por exemplo, conexión a provedores). Permiten ver de forma proactiva o problema potencial de degradación do servizo debido á perda de tráfico e, en consecuencia, evitalo.
- gráficos baseados en NetFlow. Facilitan a localización de anomalías no tráfico e son moi útiles para detectar algúns tipos simples pero significativos de ataques de hackers.
Importante! Configura notificacións por SMS para os eventos máis críticos. Isto aplícase tanto ao seguimento como ao rexistro. Se non tes quenda de servizo, os sms tamén deberían chegar fóra do horario laboral.
Pense no proceso de forma que non esperte a todos os enxeñeiros. Tiñamos un enxeñeiro de servizo para iso.
Cambiar o control
Na miña opinión, non é necesario controlar todos os cambios. Pero, en calquera caso, debería poder, se é necesario, atopar facilmente quen fixo certos cambios na rede e por que.
Algunhas suxestións:
- use un sistema de tickets para detallar o que se fixo nese ticket, por exemplo, copiando a configuración aplicada no ticket
- utilizar as capacidades de comentarios nos equipos de rede (por exemplo, enviar comentarios en Juniper). Podes anotar o número do billete
- use diff das súas copias de seguridade de configuración
Podes implementar isto como un proceso, revisando todos os tickets diariamente para ver os cambios.
Os procesos
Debes formalizar e describir os procesos no teu equipo. Se chegaches a este punto, o teu equipo xa debería ter en execución polo menos os seguintes procesos:
Procesos diarios:
- traballando con entradas
- traballando con rexistros
- control de cambios
- folla de verificación diaria
Procesos anuais:
- ampliación de garantías, licenzas
Procesos asíncronos:
- resposta a diversas situacións de emerxencia
Conclusión da primeira parte
Observaches que todo isto aínda non se trata de configuración de rede, non de deseño, nin de protocolos de rede, nin de enrutamento, nin de seguridade... Hai algo ao redor. Pero estes, aínda que quizais aburridos, son, por suposto, elementos moi importantes do traballo dunha división en rede.
Ata agora, como podes ver, non melloraches nada na túa rede. Se había vulnerabilidades de seguridade, entón permaneceron; se había un mal deseño, entón permaneceu. Ata que aplicaches as túas habilidades e coñecementos como enxeñeiro de redes, nos que moi probablemente gastaches unha gran cantidade de tempo, esforzo e ás veces diñeiro. Pero primeiro cómpre crear (ou fortalecer) a base e despois comezar a construír.
As seguintes partes indicaránche como atopar e eliminar erros e, a continuación, mellorar a túa infraestrutura.
Por suposto, non tes que facer todo de forma secuencial. O tempo pode ser crítico. Faino en paralelo se os recursos o permiten.
E un engadido importante. Comunícate, pregunta, consulta co teu equipo. Ao final son eles os que apoian e fan todo isto.
Fonte: www.habr.com