Como vimos al final de la parte 2 de estos artículos, ya que el error humano es el que más contribuye a indisponibilidades, se debe contemplar entre otras cosas dentro de los procedimientos internos de la TI:
- Definir quienes están autorizados a realizar cambios en las configuraciones de los diferentes equipos de la red.
- Contar con un comité de planeación y revisor de los cambios a aplicar y su viabilidad, asi como su plan de contingencia asociado.
- Planear los momentos correctos para el cambio de configuraciones buscando que ello afecte lo menos posible a la operación y disponibilidad de los servicios a los usuarios (ventanas de mantenimiento).
- Mantener una bitácora de quién hizo qué y cuando ayudado por una herramienta para este fin como un servicio de AAA (Tacacs suele ser preferido para esto).
Ahora, las caídas de la red son inevitables, lo que hemos venido viendo es como tratar que sean lo menor posibles y de tiempos muy cortos (MTTR), pero, ¿cómo tener a la mano herramientas o mecanismos que hagan más sencillo y rápido el troubleshooting en estas eventualidades?. Estos son algunos de estos mecanismos que deben tenerse en cuenta como parte integral de la estrategia de una alta disponibilidad de la red:
- Definir mecanismos de respaldo periódico de configuraciones.
- Habilitar mecanismos que agilicen la rápida operación de los módulos de control redundantes ante la caída del módulo principal en operación.
- Habilitar mecanismos que permitan la actualización del sistema operativo de cada equipo en "caliente" o sin sacarlos de operación y mejor aún, que puedan ser solo actualizados los módulos del sistema operativo que se requieran y no todo el sistema.
- Habilitar mecanismos de rollback de configuraciones previas (rollback n).
- Preferir habilitar mecanismos que permitan una más rápida convergencia (ejemplo de ello, habilitar capa 3 en la capa de acceso de la red LAN vs capa 2 que tradicionalmente ha sido el estándar de de facto).
¿Qué otros factores debemos tener en cuenta y que pueden afectar la disponibilidad de la red en su todo? ¿Qué tal las caídas derivadas de aspectos blandos de seguridad? Ejemplo:
- Por accesar utilizando telnet a los equipos y un ataque del tipo "man in the middle" pueda capturar las credenciales para entrar a los equipos y borrar las configuraciones o simplemente darles shutdown, en vez de utilizar una forma segura de acceso como SSHv2.
- O por suplantar la identidad de una PC dentro de la red LAN al generar ataques por la forma de funcionamiento intrínseco del protocolo ARP y no activar mecanismos tales como inspección dinámica de ARP y mecanismos contra IP spoofing.
- Y que tal un ataque de negación de servicio (DoS) al servicio de DHCP por no tener habilitado DHCP snooping en la red LAN.
- Y la facilidad de acceso a la red por no tener habilitados mecanismos en la red LAN como seguridad en puerdo basada en direcciones MAC (port security).
- Y la información no cifrada en la red inalámbrica (WLAN) por seguir usando WEP en vez de WPA2.
- Y más común, dejar por default el autoregistro de teléfonos IP a la red.
- O no habilitar el cifrado de llamadas telefónicas para evitar ser capturadas y reproducidas posteriormente.
Podríamos dedicar un libro entero a detallar solo aspectos que vulneran la seguridad desde los múltiples puntos de vista o torres de servicios que están presentes como parte de la TI en las organizaciones e impactan directamente la disponibilidad del servicio, así que dejaremos hasta aquí esos ejemplos.
Finalizare con un reflexión que parecería "obvia" pero la mayoría de las veces no lo es para los múltiples responsables de la TI inmersos en mantener la disponibilidad que el negocio o la organización demanda...
A partir de cuando empieza la medición de la caída o indisponibilidad de la red, ¿cuando el usuario ya no puede accesar a su aplicación o cuando se cae la infraestructura asociada a la aplicación?
Les asombraría a muchos que la principal respuesta que elígen los responsables de la TI es: a partir de la caída de los elementos tecnológicos a su cargo. ¿Qué problema ven al respecto?, primero, no siempre se caen completamente los componentes que soportan una aplicación o servicio al usuario, motivo por el cual para los responsables de la operación de la TI, no existe del todo una indisponibilidad, y a partir de este punto de vista pueden surgir múltiples discusiones de si tienen razón ellos o los usuarios que no entienden nada de tecnología, ¿verdad?, ¿suena familiar?. Segundo, una aplicación o servicio al usuario, comúnmente depende de múltiples componentes habilitadores e infraestructura asociada que forma parte de múltiples áreas de competencia dentro de la TI (redes, sistemas, telefonía, etc) por tanto para garantizar la disponibilidad que se espera de ella, se deben contemplar las múltiples disponibilidades asociadas a cada área ya que son elementos en serie para fines de la matemática a llevar a cabo, y esto es acotado a través del establecimiento de acuerdos de niveles de servicio internos (OLAs como son definidos en ITIL) que la mayoría de las veces no existen o al menos no son tan claros y del conocimiento de todas las áreas de la TI. Por tanto, la indisponibilidad de una aplicación o servicio al usuario inicia y termina a partir de la falla en la experiencia del usuario y su regreso al funcionamiento esperado, no importando el estado de los componentes individuales (componentes habilitadores del servicio e infraestructura asociada).
Hace unos años, Juniper Networks mostró la siguiente gráfica que detalla lo que acabó de comentar, verán claramente un diferencial entre la disponibilidad de la red vs la disponibilidad real en la aplicación al usuario por las razones comentadas anteriormente.
Hasta aquí, todo lo que hemos hablado tiene que ver con únicamente con los aspectos a considerar en el hardware de la red y algunos mecanismos lógicos al respecto, sin embargo hemos obviado que para llevar a cabo el cálculo completo de disponibilidad aún nos falta considerar como componentes en serie, lo siguiente:
- Software o sistema operativo de los equipos
- Sistemas de energía (UPS, alimentación eléctrica, etc)
- Cableado
¿Cómo calcular la respectiva disponibilidad de los componentes anteriores para tener el cálculo completo?, de los sistemas de respaldo de energía (UPS) pudiese llevarse a cabo si el fabricante respectivo proporcionara el MTBF de sus equipos, del resto de componentes es casi imposible obtener una estimación por lo cual son dejados de lado en el cálculo (salvo casos de infraestructura en centros de datos o DC, en donde la disponibilidad esta regida por el nivel de la certificación o Tier que acredite el Uptime Institute a través del estándar TIA-942).
No hay comentarios.:
Publicar un comentario