[MÚSICA]
Hola y bienvenidos a ITIL 4 Sin Filtros.
Soy Julián y conmigo está mi coanfitriona, Alex.
Alex, hoy tenemos un tema súper interesante.
Así es, Julián.
Nos sumergimos en el mundo del monitoreo y la gestión de
eventos.
Este tema es uno de esos que muchas organizaciones piensan
que entienden y luego se dan cuenta de que hay mucho más de
lo que parece.
Exacto.
Manténganse atentos porque vamos a hablar de casos reales,
mejores prácticas y algunos errores que, ay, creanme,
he visto demasiadas veces en entornos de TI.
Así que, todos en alerta.
Muy bueno ese juego de palabras, Julián.
Imaginen que están escuchando alertas constantemente en el
fondo mientras hablamos.
Esos pitidos, esas notificaciones,
esos son exactamente el tipo de eventos de los que vamos a
hablar hoy.
Claro, porque los eventos están sucediendo constantemente en
nuestros entornos de TI.
Y la pregunta del millón es, ¿estamos realmente prestando
atención?
O mejor dicho, ¿estamos prestando atención a lo
correcto?
Bueno, empecemos con lo básico.
Porque la gestión de eventos en ITIL 4 es, básicamente,
el proceso de monitorear todos los eventos que ocurren a lo
largo de la infraestructura y servicios de TI.
Pero aquí está la cosa.
Y esto es súper importante.
Un evento no es necesariamente algo malo.
Así es, Alex.
Y eso es algo que muchas personas no entienden bien.
La gente tiende a pensar que los eventos son solo, ya saben,
problemas.
O esas alertas rojas que parpadean por toda la pantalla
como en las películas.
Pero la realidad es muy diferente.
Así es.
Un evento puede ser cualquier cosa que sea detectable o
discernible y que tenga significado para la gestión de
la infraestructura de TI o la entrega de servicios.
O sea, estamos hablando de, bueno,
de completar una tarea programada exitosamente.
Eso es un evento.
Un usuario que inicia una sesión en el sistema.
También un evento.
Correcto.
El uso de CPU que alcanza un umbral del 75%.
Definitivamente un evento.
Una transacción que tarda más de lo esperado en completarse.
Como ya se imaginan, otro evento.
Lo clave es entender que no todos los eventos requieren
acción inmediata.
Exactamente.
Algunos son simplemente informativos.
Es como si el sistema nos estuviera diciendo, oye,
quiero que sepas que esto pasó.
Es información.
No necesariamente una crisis que requiere que despertemos a
alguien a las 3 de la mañana.
Poco más porque en ITIL 4,
generalmente categorizamos los eventos en 3 tipos principales.
Y esta categorización es crucial para saber cómo responder
adecuadamente.
Perfecto.
Empecemos con los eventos informativos.
Estos son eventos que no requieren acción inmediata,
pero es importante saber sobre ellos para tener contexto
completo.
Por ejemplo, cuando un respaldo se completa exitosamente o
cuando un usuario se conecta al sistema.
Son como notificaciones tranquilas que nos confirman que
todo está funcionando como debe ser.
Y déjenme contarles una historia rápida aquí.
Esa historia es buena.
Estaba trabajando con esta organización hace unos meses y
estaban literalmente ahogándose en alertas.
El equipo de operaciones estaba agotado, frustrado y empezando a
ignorar notificaciones importantes.
Cuando hicimos el análisis,
resultó que como el 60% de sus notificaciones urgentes eran
solo eventos informativos que habían sido clasificados como
críticos.
Y eso nos lleva a una lección súper importante.
La clasificación importa, gente.
No todos los VIPs son emergencias.
De hecho, la mayoría no lo son.
Y si tratan todo como urgente, al final nada es urgente.
Exacto.
Luego tenemos los eventos de advertencia.
Estas son como las luces amarillas del semáforo,
por así decirlo.
Son eventos que indican que algo inusual ha ocurrido,
pero no necesariamente está causando interrupción del
servicio en este momento.
Me gusta esa analogía del semáforo.
Es como, bueno, como el indicador de gasolina en su
carro cuando está en un poco menos de la mitad del tanque.
Todavía no es crítico.
No se van a quedar varados ahí mismo.
Pero definitivamente vale la pena vigilar y planear una
parada en la gasolinera pronto.
Buen ejemplo.
Veamos algunos de TI.
Si el uso de CPU llega al 80% por un periodo breve.
Esa es una advertencia.
Si el espacio en disco alcanza el 85%.
Advertencia.
Estos eventos nos están diciendo, oye,
manténganse atentos a esto porque podría convertirse en un
problema si no le prestamos atención.
Y la clave con las advertencias es encontrar ese equilibrio
entre no ignorarlas completamente,
pero tampoco entrar en pánico.
Son indicadores tempranos de que algo podría necesitar
atención pronto, pero no necesariamente ahora.
Y finalmente tenemos los eventos de excepción.
Estas son sus alertas rojas.
Sus situaciones de dejen todo lo que están haciendo y ocúpense
de esto ahora mismo.
Interrupciones de servicio, rechas de seguridad,
caídas del sistema.
Estos sí requieren respuesta inmediata.
Estos sí son los que justifican despertar a alguien a las 3 de
la mañana.
Pero aquí está lo interesante.
Y es aquí donde muchas organizaciones realmente la
proliferan.
Tratan absolutamente todo como un evento de excepción.
Es un problema enorme.
Cada pitido, cada notificación recibe el mismo nivel de
urgencia y eso lleva directamente a lo que llamamos
fatiga de alerta.
La gente empieza a ignorar las alertas porque simplemente hay
demasiadas sonando constantemente.
Es exactamente como el cuento del niño que gritaba lobo,
¿verdad?
Cuando todo es urgente, al final,
nada es realmente urgente.
Y cuando llegue una emergencia real,
nadie va a estar prestando atención.
Entonces, ¿cómo funciona todo esto en la práctica?
Porque una cosa es entender la teoría y otra muy diferente es
implementarlo en un entorno de producción.
El proceso de la gestión de eventos típicamente sigue
varios pasos clave.
¿Y te parece que lo veamos uno a uno?
Claro.
Primero tenemos la detección y notificación de eventos.
Es aquí donde necesitamos detectar que algo pasó.
Obviamente.
Esto podría ser a través de herramientas de monitoreo
automatizadas, reportes de usuarios que nos llaman o mandan
tickets o incluso observación manual de alguien que nota algo
raro.
Lo clave aquí es tener cobertura completa a través de su
infraestructura.
Y cuando digo completa, me refiero a que, bueno,
siempre le digo a la gente, si no pueden verlo,
no pueden gestionarlo.
Es así de simple.
Así que asegúrense de que sus herramientas de monitoreo estén
realmente monitoreando las cosas que importan para el negocio.
No sirve de nada monitorear 500 métricas diferentes si ninguna
de ellas les dice si sus usuarios pueden hacer su trabajo
efectivamente.
Buen consejo.
Luego viene el filtrado de eventos, que es, bueno,
posiblemente uno de los pasos más importantes y más ignorados.
No todos los eventos necesitan llegar a la atención humana.
De hecho, la mayoría no deberían.
Así es.
Aquí es donde aplicamos reglas y filtros inteligentes para
determinar qué eventos necesitan procesamiento adicional y
cuáles pueden ser simplemente registrados para referencia
futura.
Piénsenlo como el filtro de spam de su email.
Excelente analogía.
Su filtro de email está automáticamente revisando
miles de mensajes y solo les muestra los que realmente
necesitan ver.
Un buen sistema de filtrado puede reducir el ruido en un 80% o
incluso 90%, dejándoles solo con los eventos que realmente
necesitan su atención.
Y sin filtrado apropiado, van a terminar literalmente
ahogándose en un mar de notificaciones irrelevantes.
¿Receta segura para el desastre operacional?
Categorizar y priorizar es el próximo paso.
Una vez que un evento pasa el filtro,
necesitamos categorizarlo.
¿Es informativo?
¿Advertencia?
¿O es una excepción?
Luego priorizamos.
¿Qué tan urgente es esto para el negocio?
Sabes, Julián, aquí es crucial tener buenos acuerdos de niveles
de servicio para priorizar en base al impacto al negocio.
Porque seamos honestos, no todas las organizaciones son
iguales, ni todos los sistemas tienen el mismo significado
para el negocio.
Correcto.
El servidor que maneja las nóminas de la empresa es
definitivamente más crítico que el que actualiza el menú de la
cafetería corporativa.
Se prioriza en base a las necesidades y requerimientos
del negocio.
Esto requiere entender profundamente qué servicios de
TI respalan qué procesos de negocio.
Sin esa conexión clara, estás básicamente volando a ciegas y
adivinando prioridades.
Ya categorizado y priorizado el evento,
viene la respuesta y escalamiento.
Para eventos que requieren acción,
necesitamos responder apropiadamente.
A veces eso significa respuestas automatizadas.
Tal vez reiniciar un servicio automáticamente o limpiar
espacio en disco.
Otras veces significa involucrar a la gestión de incidentes o la
habilitación del cambio.
La clave aquí es tener procedimientos claros y bien
definidos para cada tipo de evento.
Y aquí está algo súper importante.
Mucha gente no entiende que la respuesta no siempre significa
"arréglalo ahora mismo".
A veces la respuesta más apropiada es reconocer el
evento y programar una acción para la próxima ventana de
mantenimiento.
O investigar más a fondo durante las horas hábiles del negocio.
Estas también son respuestas perfectamente válidas.
Dependen del impacto y la urgencia real del evento.
Exactamente.
Lo importante es que cada evento reciba la respuesta apropiada
basada en su impacto real y urgencia verdadera.
No solo en qué tan fuerte pita la alerta o qué color tiene en
la pantalla.
Bueno, ahora hablemos de herramientas por un minuto,
porque la realidad es que ya no pueden hacer gestión de
eventos efectiva manualmente.
Los entornos de TI modernos son simplemente demasiado
complejos y generan demasiados eventos para que los humanos los
procesen todos a mano.
Están herramientas tradicionales de monitoreo como Nagios,
SolarWinds, PRTG.
Estas han existido por décadas y funcionan muy bien para
monitoreo básico de infraestructura.
Son como los caballos de batalla confiables del mundo del
monitoreo.
Son excelentes paramétricas fundamentales como uso de CPU,
memoria, espacio en disco, conectividad de red.
Todas esas cosas básicas, pero esenciales.
Son confiables, han sido probadas en batalla durante
años y la mayoría de los equipos de TI ya saben cómo
usarlas.
Pero también tienen limitaciones para entornos modernos más
complejos.
Herramientas más nuevas como Datadog, New Relic, Splunk,
están más enfocadas en monitoreo de aplicaciones y en la
experiencia del usuario final.
Son herramientas que pueden rastrear transacciones de
usuario de extremo a extremo, analizar logs de aplicaciones
en tiempo real y proporcionar insights más profundos sobre lo
que realmente está experimentando el usuario.
No solo que algo está lento, sino en dónde exactamente se
crea el cuello de botella en el flujo completo de la
transacción.
Algunas incluyen capacidades de inteligencia artificial y
machine learning para detección automática de anomalías.
Eso sí, pueden ser muy costosas y complejas de implementar y
mantener.
Pero para aplicaciones críticas de negocio,
la inversión generalmente se justifica por la visibilidad
adicional que proporcionan.
Pero aquí está la clave y esto es súper importante.
La herramienta en sí misma no es la solución mágica.
He visto organizaciones gastar literalmente mucho dinero en
herramientas súper sofisticadas y luego--
Y luego no las configuran apropiadamente,
no les dan mantenimiento regular,
no entrenan a su gente y terminan siendo básicamente un
registro de actividades muy caro que nadie realmente usa
efectivamente.
Exactamente.
El valor real viene de cómo configuran, afinan y realmente
integran estas herramientas en sus procesos de ITSM.
Necesitan entrenamiento continuo,
configuración apropiada, mantenimiento regular e
integración real con sus otros sistemas.
Así que no solo compren la herramienta más cara del
mercado y esperen que ocurra magia automáticamente.
La magia viene del trabajo duro, la configuración inteligente y
el uso consistente a lo largo del tiempo.
Así es.
Julian, hemos cubierto mucho terreno hasta aquí,
desde qué son realmente los eventos hasta cómo detectarlos
y las herramientas que necesitan.
Pero ahora viene la parte donde muchas organizaciones,
donde realmente se define el éxito o el fracaso.
Sí, porque una cosa es entender la teoría y otra muy diferente
es llevarlo a la práctica.
En la segunda parte de Con los ojos bien abiertos,
vamos a hablar sobre mejores prácticas,
recomendaciones y orejitas que pueden ayudarle.
Vamos a hablar de errores comunes que hemos visto una y
otra vez, casos de estudios reales y, por supuesto,
cómo empezar si están apenas comenzando este viaje.
Así que estén atentos a la segunda parte.
Esto es ITIL 4 sin filtros.
Hasta la próxima.
[MÚSICA]