Este artículo es el primero en una serie titulada 'Cómo tomar el control de la infraestructura de red'. El contenido de todos los artículos de la serie y los enlaces se pueden encontrar .
No dudo que haya suficientes empresas donde una red simple no sea crítica en una hora o incluso en un día. Desafortunadamente o afortunadamente, no he trabajado en tales lugares. Pero, por supuesto, las redes son diferentes, los requisitos son distintos, los enfoques varían y, aun así, de una forma u otra, la lista a continuación será en muchos casos un 'must-do'.
Así que, las condiciones iniciales.
Te encuentras en un nuevo trabajo o has recibido un ascenso o decidiste ver tus responsabilidades desde una nueva perspectiva. La red de la empresa es tu área de responsabilidad. Para ti, en gran medida, esto es un desafío y algo nuevo, lo que justifica un tono mentor en este artículo :). Pero, espero que el artículo también pueda ser útil para cualquier ingeniero de red.
Tu primer objetivo estratégico es aprender a resistir la entropía y mantener el nivel de servicio proporcionado.
Muchas de las tareas descritas a continuación pueden resolverse mediante diferentes medios. Intencionalmente no abordo el tema de la implementación técnica, ya que a menudo no importa tanto cómo resuelves una tarea determinada, sino cómo la utilizas y si la utilizas en absoluto. Por ejemplo, no tiene mucho sentido tener un sistema de monitoreo profesionalmente diseñado si no lo miras y no respondes a las alertas.
Hardware
Primero necesitas entender dónde están los mayores riesgos.
De nuevo, puede variar. Admito que en algunos lugares, por ejemplo, serían las cuestiones de seguridad, mientras que en otros podrían ser cuestiones relacionadas con la continuidad del servicio, y en otros tal vez algo más. ¿Por qué no?
Supongamos para ser precisos que, en efecto, se trata de la continuidad del servicio (así fue en todas las empresas en las que trabajé).
Entonces, debes comenzar con el hardware. Aquí hay una lista de temas a los que debes prestar atención:
- clasificación del hardware según su criticidad
- redundancia del hardware crítico
- soporte, licencias
Debes considerar las posibles fallas, especialmente con el equipo que se encuentra en la parte superior de tu clasificación de criticidad. A menudo, se subestima la probabilidad de problemas dobles, de lo contrario, tu solución y soporte pueden volverse innecesariamente costosos, pero en el caso de elementos realmente críticos de la red, cuya falla puede afectar significativamente el negocio, debes pensar también en esto.
Ejemplo
Supongamos que estamos hablando del conmutador principal en el centro de datos.
Dado que hemos acordado que la continuidad del servicio es el criterio más importante, es razonable asegurar la «redundancia» (redundancy) de este equipo. Pero eso no es todo. También debes determinar cuánto tiempo, en caso de que falle el primer conmutador, es aceptable para ti trabajar solo con el conmutador restante, ya que existe el riesgo de que también falle.
¡Importante! No debes resolver este asunto tú solo. Debes describir los riesgos, las posibles soluciones y los costos a tu gerencia o a la dirección de la empresa. Ellos deben tomar las decisiones.
Así, si se decidió que, dada la pequeña probabilidad de una doble falla, trabajar durante 4 horas con un solo conmutador es, en principio, aceptable, entonces puedes simplemente contratar el soporte correspondiente (donde el equipo será reemplazado en un plazo de 4 horas).
Pero hay riesgo de que no se entregue. Lamentablemente, una vez nos encontramos en una situación así. ¡En lugar de cuatro horas, el equipo tardó una semana en llegar!
Por lo tanto, este riesgo también debe ser discutido y, tal vez, para ti sería más correcto comprar otro conmutador (el tercero) y mantenerlo como repuesto («reserva fría») o usarlo para fines de laboratorio.
¡Importante! Crea una tabla de todos los soportes que tienes, con fechas de vencimiento, y añádelos a tu calendario para que al menos un mes antes recibas un correo que te indique que debes comenzar a preocuparte por la renovación del soporte.
No te lo perdonarán si olvidas renovar el soporte y al día siguiente de que expire, tu equipo se descompone.
Trabajos de emergencia
Independientemente de lo que suceda en tu red, idealmente, debes mantener el acceso a tu equipo de red.
¡Importante! Debe tener acceso de consola a todo el equipo y este acceso no debe depender del funcionamiento de la red de transmisión de datos.
También debe prever posibles escenarios negativos y documentar las acciones necesarias. La disponibilidad de este documento también es crítica, por lo que debe estar no solo en un recurso público del departamento, sino también guardado localmente en las computadoras de los ingenieros.
Debe incluir obligatoriamente
- información necesaria para abrir un ticket de soporte con el proveedor o integrador
- información sobre cómo acceder a cualquier equipo (consola, gestión)
También puede contener cualquier otra información útil, como una descripción del procedimiento de actualización de diferentes equipos y comandos de diagnóstico útiles.
Socios
Ahora debe evaluar los riesgos asociados con los socios. Generalmente, esto incluye
- proveedores de Internet y puntos de intercambio de tráfico (IX)
- proveedores de canales de comunicación
¿Qué preguntas debe hacerse? Al igual que con el equipo, debe considerar diferentes opciones en situaciones de emergencia. Por ejemplo, para los proveedores de Internet, esto puede ser algo como:
- ¿qué sucederá si el proveedor de Internet X deja de ofrecerle servicio por alguna razón?
- ¿será suficiente el ancho de banda de los demás proveedores?
- ¿qué tan buena seguirá siendo la conectividad?
- ¿son independientes sus proveedores de Internet y una grave falla en uno de ellos causará problemas a los demás?
- ¿cuántas entradas ópticas tiene su centro de datos?
- ¿qué pasará si una de las entradas se destruye por completo?
En cuanto a las entradas, en mi experiencia en dos compañías diferentes, en dos diferentes data-centros excavadoras dañaron los pozos y por milagro nuestra fibra óptica no se veía afectada. No es un caso tan raro.
Y, por supuesto, no solo necesita hacerse estas preguntas, sino que, nuevamente contando con el apoyo de la dirección, debe garantizar una solución aceptable en cualquier situación.
Copia de seguridad
El siguiente en prioridad puede ser la copia de seguridad de las configuraciones del equipo. En cualquier caso, este es un punto muy importante. No enumeraré los casos en los que puede perder la configuración, es mejor hacer copias de seguridad regularmente y no pensar en ello. Además, una copia de seguridad regular puede ser muy útil para el control de cambios.
¡Importante! Realice copias de seguridad a diario. No es un volumen tan grande de datos como para escatimar en ello. Por la mañana, el ingeniero de guardia (o usted) debe recibir un informe del sistema que indique claramente si la copia de seguridad fue exitosa o no, y en caso de que la copia de seguridad no se haya realizado con éxito, el problema debe ser resuelto o debe crearse un ticket (véase los procesos del departamento de red).
Versiones de software
La cuestión de si se debe o no actualizar el software del hardware no es tan sencilla. Por un lado, las versiones antiguas tienen errores y vulnerabilidades conocidas, pero por otro lado, el nuevo software no siempre es un procedimiento indoloro de actualización, y además, puede introducir nuevos errores y vulnerabilidades.
Aquí se necesita encontrar la opción óptima. Varias recomendaciones obvias
- instalar solo versiones estables
- no se debe vivir con versiones de software demasiado antiguas
- elabore una tabla con información sobre qué software está instalado en cada máquina
- lee periódicamente los informes sobre vulnerabilidades y errores en las versiones del software, y en caso de problemas críticos, debe considerar una actualización
En esta etapa, teniendo acceso por consola al hardware, información sobre el soporte y una descripción del procedimiento de actualización, en principio, está listo para este paso. Lo ideal es tener un equipo de laboratorio donde pueda probar todo el procedimiento, pero, desafortunadamente, eso no sucede a menudo.
En el caso de hardware crítico, puede comunicarse con el soporte del proveedor para pedir ayuda en la realización de la actualización.
Sistema de tickets
Ahora puede mirar a su alrededor. Necesita establecer procesos de interacción con otros departamentos y dentro del departamento.
Puede que no sea obligatorio (por ejemplo, si su empresa es pequeña), pero le recomendaría encarecidamente organizar el trabajo de manera que todas las tareas externas e internas pasen por el sistema de tickets.
El sistema de tickets es, en esencia, su interfaz para las comunicaciones internas y externas, y debe describir esta interfaz con suficiente grado de detalle.
Tomemos como ejemplo una tarea importante y común relacionada con la apertura de accesos. Describo el algoritmo que funcionó muy bien en una de las empresas.
Ejemplo
Empecemos por decir que a menudo los clientes formulan su solicitud de acceso en un idioma incomprensible para un ingeniero de redes, es decir, en el lenguaje de la aplicación, por ejemplo, "ábreme el acceso a 1C".
Por lo tanto, nunca aceptamos solicitudes directamente de tales usuarios.
Y esta fue la primera exigencia.
- Las solicitudes de acceso deben provenir de los departamentos técnicos (en nuestro caso, fueron ingenieros de unix, windows, helpdesk).
La segunda exigencia es que
- este acceso debe ser documentado (por el departamento técnico que nos hizo la solicitud) y como solicitud recibimos un enlace a este acceso documentado.
La forma de esta solicitud debe ser comprensible para nosotros, es decir,
- la solicitud debe contener información sobre desde qué y a qué subred debe abrirse el acceso, así como sobre el protocolo y (en el caso de tcp/udp) los puertos.
También debe indicarse
- una descripción de para qué se abre este acceso,
- temporal o permanente (si es temporal, hasta qué fecha).
Y un punto muy importante son las aprobaciones,
- del jefe del departamento que inició el acceso (por ejemplo, de contabilidad),
- del jefe del departamento técnico del cual llegó esta solicitud al departamento de redes (por ejemplo, helpdesk).
A su vez, el "propietario" de este acceso es considerado el jefe del departamento que inició el acceso (contabilidad en nuestro ejemplo), y es responsable de mantener actualizada la página con los accesos documentados para este departamento.
Registro
Esto es algo en lo que se puede hundir uno. Pero si deseas implementar un enfoque proactivo, debes aprender a manejar este flujo de datos.
Aquí hay algunas recomendaciones prácticas:
- revisar los registros debe hacerse a diario.
- En caso de una revisión planificada (y no una situación de emergencia), se puede limitar a los niveles de criticidad (severity) 0, 1, 2 y añadir patrones seleccionados de otros niveles si lo considera necesario.
- escriba un script que analice los registros e ignore aquellos patrones que ha añadido a la lista de ignorados.
Este enfoque permitirá con el tiempo crear una lista de ignorados de registros que no le interesan y dejar solo aquellos que realmente considera importantes.
Esto funcionó muy bien para nosotros.
Monitoreo
No es raro que una empresa carezca de un sistema de monitoreo. Puedes, por ejemplo, confiar en los registros, pero el equipo puede simplemente "morir" sin decir nada, o un paquete UDP del protocolo syslog puede perderse y no llegar. En general, claro, el monitoreo activo es importante y necesario.
Dos ejemplos que son los más demandados en mi práctica:
- monitoreo de la carga de los canales críticos de comunicaciones (por ejemplo, la conexión con proveedores). Permiten ver proactivamente un posible problema de degradación del servicio debido a la pérdida de tráfico y, por lo tanto, evitarlo.
- gráficas basadas en NetFlow. Permiten encontrar fácilmente anomalías en el tráfico y son muy útiles para detectar ciertos tipos de ataques de hackers que son simples pero significativos.
¡Importante! Configure alertas SMS para los eventos más críticos. Esto se aplica tanto al monitoreo como al registro. Si no tiene un turno de guardia, las alertas SMS también deben llegar fuera del horario laboral.
Planifique el proceso de tal manera que no despierte a todos los ingenieros. Nosotros tuvimos un ingeniero de guardia para eso.
Control de cambios
En mi opinión, no es necesario controlar todos los cambios. Pero, de todos modos, debe tener la capacidad de encontrar fácilmente quién y por qué realizó ciertos cambios en la red, si es necesario.
Algunos consejos:
- utilice un sistema de tickets para describir detalladamente lo que se hizo en el marco de este ticket, por ejemplo, copiando la configuración aplicada en el ticket
- utilice las capacidades de comentario en el equipo de red (por ejemplo, el comentario de commit en Juniper). Puede registrar el número del ticket
- utilice diff de sus copias de seguridad de configuración
Puede introducir esto como un proceso, revisando diariamente todos los tickets en busca de cambios.
Procesos
Debes formalizar y describir los procesos en tu equipo. Si has llegado a este punto, ya deben estar funcionando al menos los siguientes procesos en tu equipo:
Procesos diarios:
- trabajo con tickets
- trabajo con registros
- control de cambios
- lista de verificación diaria
Procesos anuales:
- renovación de garantías, licencias
Procesos asincrónicos:
- reacción a diversas situaciones de emergencia
Conclusión de la primera parte
¿Te has dado cuenta de que todo esto no tiene que ver con la configuración de la red, el diseño, los protocolos de red, el enrutamiento o la seguridad...? Es algo más grande. Pero, aunque puede parecer aburrido, son elementos muy importantes en el funcionamiento de un departamento de red.
Por ahora, como puedes ver, no has mejorado nada en tu red. Si había vulnerabilidades de seguridad, siguen ahí; si había un mal diseño, continúa igual. Hasta que no apliques tus habilidades y conocimientos como ingeniero de red, en los que seguramente has invertido mucho tiempo, esfuerzo y a veces dinero. Pero primero necesitas crear (o fortalecer) la base antes de comenzar a construir.
Sobre cómo buscar y resolver problemas, y luego mejorar tu infraestructura, trataremos en las siguientes partes.
Por supuesto, no es necesario hacer todo de manera secuencial. El tiempo puede ser crítico. Hazlo en paralelo si los recursos lo permiten.
Y un importante recordatorio: comunícate, pregunta, consulta con tu equipo. Al final, son ellos quienes deben mantener y llevar a cabo todo esto.
Fuente: habr.com
