Transformar las historias de terror de la CMDB en estrategias de éxito informático

Sean Dawson: Bienvenidos todos al Podcast de la Destilería de Barricas, donde liberamos todo el potencial de ServiceNow con ideas expertas y estrategias prácticas, sólo aquí en el Podcast de la Destilería de Barricas. Y hoy, tenemos un episodio espeluznante, ¡porque se acerca Halloween!

Y por eso queríamos tomarnos un momento y reunirnos con Chris Padmore, que es mi invitado especial de hoy -que es nuestro director de práctica ITOM aquí en Cask- y hablar de algunas de las historias de miedo que pueden ocurrir dentro de CMDB. Bienvenido, Chris. Gracias por sacar tiempo de su apretada agenda, a pesar de que en realidad resultó ser un poco de última hora. Así que gracias. 

Chris Padmore: Gracias por invitarme, Sean. 

Sean Dawson: No te preocupes. Así que, vamos a entrar de lleno en ella, porque quiero que hables un poco sobre algunas historias y algunas cosas que pueden ir terriblemente mal con CMDB, y la primera que habíamos pensado era la historia del incidente "Phantom Update", así que habla un poco sobre eso para nosotros.

Chris Padmore: Oh sí, esta es buena, y mucha gente probablemente se ha encontrado con esto en algún momento, pero quiero que te imagines esto: Usted tiene un gran equipo de TI de la empresa, ¿verdad? Y están haciendo sus típicas actualizaciones de la CMDB. Y luego tienen una nueva persona, y han hecho sus cambios. Están haciendo sus actualizaciones. Pero cometen un error, un error muy pequeño. No crees que sea para tanto. Pero entonces, la tragedia comienza a suceder. Una aplicación se cae. Nadie sabe por qué. Otra aplicación se cae. Nadie lo sabe. Y están tratando de averiguarlo. Esto nunca había sucedido antes. Y la gente está buscando, y están buscando. Están comprobando la CMDB, y están comprobando los tickets, y no saben por qué todas estas cosas se están cayendo. 

Y resulta que el culpable fue un error en la actualización de la CMDB. Así que cuando hicieron que el último cambio en la CMDB, que accidentalmente eliminado una de las dependencias básicas del servidor que se estaban ejecutando en. Así que todas estas cosas estaban sucediendo en el lado del servidor, y no estaba relacionado de nuevo a todos los servicios de aguas arriba. Así que podían ver claramente que ese servidor tenía un problema; esa base de datos no funcionaba. Todas esas aplicaciones no se daban cuenta de que dependían de esa base de datos. Y todo porque alguien involuntariamente cambió una dependencia sin saberlo.

Sean Dawson: Vaya. En tu opinión, ¿cómo se puede garantizar una asignación precisa de las dependencias en la CMDB para evitar que esto ocurra? 

Chris Padmore: Por lo tanto, su amigo allí va a ser la herramienta Discovery. Se asegurará de que, mientras escanea y ve dependencias entre los componentes de TI, esas dependencias se asocien correctamente en la CMDB. Así que incluso si tuviera que ir y eliminar esa dependencia manualmente, cuando Discovery se ejecute la próxima vez, la volverá a poner en su sitio, y no tendrás que preocuparte por las configuraciones que faltan y por no saber cuáles son los impactos aguas arriba y aguas abajo de algo. 

Sean Dawson: Estupendo. Gracias por eso. Entonces, la siguiente situación aterradora con la que nos podemos encontrar es el servidor fantasma. Háblame un poco de lo que se trata y lo que puede suceder. 

Chris Padmore: Oh, sí, pero mucha gente ha visto esto también. Estás sentado en tu mesa de ayuda, y recibes una llamada diciendo: "Oye, parece que el servidor 123 está caído". Y vas y buscas el servidor 123, y está en la CMDB, pero no está haciendo ping. No ves ningún ticket asociado a él. No ves ninguna aplicación ejecutándose en él. No ves a nadie solicitándolo excepto por esta llamada fantasma. Y te preguntas: "Bueno, ¿de dónde ha salido este servidor? ¿Por qué está aquí?" Intentas escanearlo con Discovery y no pasa nada. Pides al equipo del servidor que se conecte y te dicen: "Bueno, esa dirección IP no existe. Dice: "No se ha encontrado nada". Resulta que ese servidor solía ser un servidor, solía existir en la CMDB. Pero fue dado de baja. Y en algún momento, cuando alguien estaba haciendo su trabajo de desmantelamiento, rompiendo sus dependencias, dejaron algo intacto.

Así que aunque el servidor esté ahí, no se comunica con nada, nadie puede acceder a él, y alguien tiene que bajar físicamente al sótano y desconectar ese servidor de las instalaciones. Pero da miedo porque tienes a tu gente de riesgo diciendo: "Bueno, ¿quién puso el servidor aquí? ¿Quién tiene acceso a él? ¿Alguien entró y conectó algo cuando nadie miraba?". Resulta que es sólo un servidor sobrante que se supone que debe estar allí. Y ahora alguien puede ir y apagarlo. 

Sean Dawson: Bien. Entonces, ¿cuál es un proceso que alguien puede garantizar que los activos desmantelados son realmente completamente, verdaderamente retirados?

Chris Padmore: Así que intentamos hacer un par de cosas. Tenemos algo llamado "proceso de cambio de bucle cerrado". Así que, ahí es donde estamos haciendo algo como actualizar o eliminar un componente. La última cosa que quieres hacer es escanear ese componente. Y luego asegurarse de que la CMDB refleja con precisión sus actualizaciones.

En este caso, con el desmantelamiento, lo que debería haber ocurrido es que Discovery debería haber visto que ese servidor había desaparecido por completo. Alguien debería haberlo marcado como "desmantelado" en la CMDB. Y entonces alguien del equipo de servidores debería haber bajado y haber hecho una tarea del tipo "desenchufar de la pared". Y entonces usted habría tenido que completa. No sólo el desmantelamiento completamente ejecutado, sino también la documentación y los tickets diciendo que, "Sí, esta persona bajó y lo desenchufó durante esta fecha. Y confirmamos que Discovery ya no lo ve".

Sean Dawson: Estupendo. Hablemos de la siguiente. La "Catástrofe de la Deriva de Configuración Invisible".

Chris Padmore: Oh sí, esto es, de nuevo, estas son cosas que la gente probablemente tienen pesadillas acerca de si han estado involucrados con ellos. Pero imagina esto: Tenemos nuestros sistemas centrales, y estamos escaneando ellos. El equipo sabe cómo están configurados, y por lo general no tenemos ningún problema con ellos. Están zumbando. Están funcionando bien. Y entonces, empiezas a ver cambios, empiezas a ver que se comportan de manera diferente. Y entonces, sólo para asegurarse de que no eres tú, vas y miras y lo ves, como, "Oye, esto dice que estamos usando dos servidores Linux, pero veo dos servidores Windows ejecutando estas aplicaciones". "Oye, esto dice que estamos en el parche 14, pero veo que estamos en el parche 8. ¿Qué está pasando?" Y así, lo que puede suceder es que, por la razón que sea, las configuraciones básicas de ese sistema están empezando a cambiar. Las cosas se están desactualizando. Las cosas no coinciden con lo que la gente ha planeado. Y alguien está preocupado de que alguien está en el sistema haciendo algo que se supone que no debe hacer. 

Pero no es el caso. Esto podría ocurrir cuando el código incorrecto se empuja hacia fuera durante una actualización de rutina. Y esas son cosas que podemos detectar fácilmente con la herramienta Discovery. Podemos rastrear los archivos de configuración del núcleo. Podemos rastrear cuándo se están actualizando, qué los está actualizando y cuáles son las diferencias entre la última vez que se ejecutó Discovery. Y entonces podemos tener alertas automatizadas generadas, diciendo: "Hey, esto parece que este archivo de configuración cambiado. No cambió durante una de sus ventanas de cambio principales. Hagamos que alguien le eche un vistazo y vea qué está pasando realmente".

Sean Dawson: Estupendo. Y en realidad respondiste a mi pregunta, "¿Cómo podemos prevenirlo?" De acuerdo. Entonces, ¿qué pasa con el desastre del efecto dominó de la dependencia? 

Chris Padmore: Ah, sí. Este es uno que yo personalmente experimenté hace muchas, muchas lunas, pero imagina que tú y tu equipo estáis haciendo vuestro trabajo normal, y sólo estáis haciendo actualizaciones menores. Tienes diez servidores que parcheas regularmente, y es ese momento otra vez. Así que, es un viernes por la tarde, estás haciendo tus parches, terminas por hoy, cierras y te vas a casa. Te vas a la cama pensando que vas a disfrutar del fin de semana. Y entonces te despiertas y tienes 50 llamadas de teléfono sin leer, y tienes cientos y cientos de Slacks y un correo electrónico diciendo: "Hey, este sistema no funciona. Este sistema está fallando. ¿Qué está pasando?" Y usted está entrando en pánico porque se acordó de que acaba de empujar una actualización en antes de ir a casa. Y empiezas a pensar: "Bueno, no puede ser mi actualización. El mío es un sistema aislado. Es sólo una pequeña actualización". Y te conectas, y esta aplicación está, abajo esta aplicación está abajo, y estás flipando. Usted es como, "No hay manera de que podría ser yo. No hay manera de que podría ser yo ". Y entonces sucede que vas y miras y ves que de los 10 servidores que actualizaste, el último servidor se suponía que era el servidor 22 de CMDB, y en realidad actualizaste el servidor 2022 de CMDB, que no es tu servidor. Es el servidor de otra persona. 

Así que, sin saberlo, has liberado un monstruo en tu organización, y no tienes los conocimientos ni la experiencia para entrar y arreglarlo. Así que estás en las llamadas con la gente. Estás en esas llamadas de sala de guerra tratando de resolver el problema. Y tienes que ponerte delante de todo el mundo y decir: "Creo que podría ser este servidor, y creo que este podría ser el cambio que lo causó. Que alguien vaya a echarle un vistazo".

Sean Dawson: ¿Cuáles son las mejores prácticas para gestionar las dependencias en una CMDB? 

Chris Padmore: Una vez más, hay que seguir el proceso de gestión del cambio. Asegúrate de revisar y validar todo el trabajo que estás haciendo.

Cuando usted está haciendo cualquier cambio, usted va a tener una lista de CIs que vas a estar trabajando. Usted quiere asegurarse de que usted está realmente de inicio de sesión en los CIs para empujar sus cambios a-que las tareas que usted está cometiendo durante esas tareas, que desea validar, como, "Hey, es este un-¿Puede captura de pantalla el número de servidor para que podamos confirmar que usted está realmente conectado en el servidor correcto?" Una vez más, usted quiere tener esos cambios de circuito cerrado utilizando Discovery. Así que después de que haya terminado de hacer sus actualizaciones, usted quiere tener Discovery volver a actualizar todo para que pueda asegurarse de que las configuraciones que estaban haciendo realmente se aplican a los CIs que figuran en el cambio. Por lo tanto, si se suponía que ibas a hacer el servidor 20 y redescubres el servidor 20, y dice: "No se detectan cambios", entonces tal vez estabas en el servidor equivocado, y no vas a poder disfrutar de ese fin de semana como estabas planeando. 

Sean Dawson: Sí. ¿Qué hay de la actualización de la CMDB "AI Gone Wrong"? Esta es más reciente, pero podría dar mucho miedo.

Chris Padmore: Sí, la IA en sí misma da bastante miedo si no se está acostumbrado a ella. Pero imaginemos que has iniciado uno de los módulos de aprendizaje automático de ServiceNow, y lo estás utilizando para marcar inconsistencias en tu CMDB. Y acaba de lanzar la siguiente versión. Está realizando sus actualizaciones basándose en algunos cambios recientes. Pero la IA se ha vuelto autoconsciente y cree que sabe más que tú. Así que empieza a marcar los activos de TI como no válidos, incorrectos, no detectables, no operativos, basándose en los cambios realizados anteriormente. Y para cuando tienes la oportunidad de darte cuenta, tienes cientos y cientos de servidores y bases de datos en estados operativos incorrectos. Tienes montones y montones de relaciones eliminadas que no deberían haberse eliminado, y entonces tienes montones y montones de recursos vinculados a servicios a los que no tienen por qué estar vinculados. 

Sean Dawson: Sí. Así que una buena pregunta sería, bueno, ¿cómo se puede integrar de forma segura la IA en la gestión de la CMDB entonces? 

Chris Padmore: Así que usted quiere asegurarse de que usted no va aprendizaje no supervisado completo para empezar con lo que sus actualizaciones CMDB AI. Quieres algo de validación. Aprende observando lo que haces y viendo lo que hay en el sistema. Pero tienes que entrenarla, sobre todo si estás empezando. Usted quiere ir y asegurarse de que las actualizaciones que piensa que está haciendo son válidos. Usted quiere proporcionar que la retroalimentación diciendo: "No, en estas circunstancias, este no es el tipo correcto de actualización que queremos hacer ". Y usted quiere probar estas cosas en el entorno inferior también. Usted quiere asegurarse de que se comporta como se esperaba en el entorno de desarrollo y que puede utilizar esos modelos en la producción sin tener que, ya sabes, revertir un montón de cambios que pensó que debería estar haciendo. 

Sean Dawson: Estupendo. Bueno, gracias, Chris, de nuevo, por el tiempo. Sé que ha sido a última hora, pero queríamos aportar valor a nuestros espectadores y oyentes, independientemente de cómo estén combinando o consumiendo el podcast aquí. Así que muchas gracias, Chris.

Y quiero señalar también que Chris ha estado involucrado con una serie de seminarios web CMDB que vamos a poner el enlace en la parte inferior o por encima o como sea, lo que usted está viendo esto en, que tenemos una serie de CMDB, que ha habido toneladas de gran información. Así que le enviaremos a la página de registro para que pueda obtener en ellos y ver más.

Pero eso es todo por ahora. Que tengan un feliz y seguro Halloween y cuídense. Hasta pronto. 

Chris Padmore: Gracias, Sean. Nos vemos pronto.