Cloud

Vamos con otro artículo de metodología aplicada a SQL Server. Hoy toca una metodología menos conocida pero para mi de gran valor, LEAN. Lean es la palabra mágica que hace que cualquier presentación aburrida parezca una revolución. Hay quien piensa que Lean consiste en ponerse una camiseta con el logo de Toyota (precursores de esta metodología) y hablar de “mejora continua” sin decir nada concreto. Pero aquí no venimos a vender humo ni a repetir mantras vacíos. Aquí hablamos de cómo aplicar Lean en serio a nuestro trabajo como DBAs. Sin PowerPoints. Sin pegatinas. Y, sobre todo, sin tragarnos otro cursillo que acaba recomendando reuniones diarias de 15 minutos para no hacer nada nuevo.

Porque sí, los principios de Lean se pueden aplicar, y deben aplicarse, a la administración de bases de datos. Y no hablamos de crear un Value Stream Map con forma de sushi. Hablamos de identificar lo que no aporta valor a nuestros sistemas, a nuestros usuarios o a nuestra paz mental. De dejar de hacer tareas inútiles solo porque “siempre se han hecho así”. De eliminar el desperdicio, y hacerlo con método.

El “desperdicio” en el mundo real de un DBA

En Lean, la palabra clave es waste. Desperdicio. Actividades que consumen tiempo, recursos o esfuerzo y no generan valor. Y en nuestro día a día, eso abunda.

¿Ejemplos? Te doy algunos, pero seguro que te suenan demasiado: backups completos diarios de bases de datos que no han cambiado en una semana, scripts de mantenimiento que indexan sin sentido aunque la fragmentación no supere el 5%, checks automáticos que revisan tablas ya desactivadas o de sistemas obsoletos, informes que se generan cada madrugada y van directos a una carpeta compartida… donde nadie entra desde 2019 o jobs heredados con nombres como job1, job2, no_borrar, PRUEBA, nuevo2_FINAL.sql.

Eso es desperdicio. En todos los sabores posibles. Y lo peor: lo hemos normalizado. Hacemos backups duplicados “por si acaso”. Aceptamos tareas inútiles como “proceso estándar”. Nos aferramos a jobs zombis porque “nadie sabe si siguen siendo importantes”.

Lean propone lo contrario: identificar, reducir y eliminar lo que no aporta valor. Y no, eso no significa automatizarlo todo o borrarlo a lo loco. Significa mirarlo de frente y preguntarse: “¿Esto sirve para algo? ¿Alguien lo necesita? ¿Tiene impacto?”.

Cómo detectar el desperdicio sin parecer el saboteador oficial

Eliminar tareas inútiles es fácil. Hacerlo sin que te acusen de sabotaje o de romper el sistema, no tanto. Porque muchos de estos desperdicios vienen envueltos en la bandera del “mejor prevenir que curar” o del “esto siempre ha estado así”.

La clave está en aplicar los principios de Lean sin ir con la motosierra. Hay que actuar con estrategia.

Primero: identifica lo inútil con datos. No digas “este job es una chorrada”. Di: “Este job tarda 45 minutos, genera 0 filas y no ha dado una alerta útil en 18 meses”. Luego, muestra el coste: CPU, disco, tiempo, mantenimiento. Y plantea la pregunta correcta: “¿Qué pasa si lo quitamos?”. Si la respuesta es “nada”, ya tienes vía libre. Si la respuesta es “ni idea”, entonces hay que hacer una revisión seria.

Segundo: prioriza por impacto. No empieces por el informe de marketing que solo ocupa 5 MB. Empieza por la base de datos duplicada que se respalda a diario con 500 GB inútiles. Eliminar lo pequeño está bien, pero eliminar lo grande se nota.

Tercero: documenta todo lo que limpias. Sí, sabemos que nadie lee los tickets, pero si en dos meses alguien te pregunta “qué pasó con el job que hacía el backup de la base de pruebas de 2017”, necesitas tener una traza clara. Borrarlo sin dejar rastro es receta para el desastre (y para que te culpen de todo lo que falle después, aunque no tenga nada que ver).

Y cuarto: no esperes permiso para mejorar. Pide permiso para probar, no para pensar. En Lean, la mejora continua no se hace en reuniones. Se hace observando el sistema y actuando con criterio.

Lo que Lean puede enseñarnos (sin que nos convirtamos en coaches de LinkedIn)

En esencia, Lean te invita a mirar tus procesos con una pregunta clara: ¿Esto aporta valor? Y si la respuesta es no, entonces no debería existir.

Como DBAs, eso significa: 

• Analizar el uso real de las tareas programadas. ¿Se consultan? ¿Se consumen?
• Medir el retorno del mantenimiento. ¿Indexar cada noche mejora algo? ¿Detectar fragmentación mínima vale la pena?
• Revisar scripts heredados. ¿Siguen siendo necesarios? ¿Tienen un propósito actual?
• Validar backups. ¿Se pueden restaurar? ¿Se necesitan todos? ¿Con qué frecuencia?

Y sí, a veces eliminar un backup inútil es más útil que implementar otro monitor de backups. A veces evitar una ejecución innecesaria es más valioso que documentarla. Lean no va de “hacer más cosas mejor”. Va de hacer menos cosas inútiles.

¿Lean sin post-its? Sí, gracias

Si algo nos enseña Lean es que mejorar un sistema no siempre requiere grandes cambios. A veces solo hace falta dejar de hacer lo innecesario. Y eso, en el mundo de un DBA, es un superpoder.

No necesitamos mapas de valor ni ceremonias de reflexión semanal. Solo necesitamos aplicar sentido común técnico y tener el coraje de cuestionar lo establecido. Porque mantener jobs inútiles por costumbre no es precaución. Es ruido.

Así que sí, aplica Lean. Pero hazlo como lo haría un DBA: con logs, con datos, con impacto medible. Sin tanto adorno. Y si de paso te quitas unas cuantas tareas absurdas de encima, mejor aún.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Solo pronunciar la palabra ITIL en una reunión técnica ya provoca dos reacciones inmediatas: o la mirada perdida del que recuerda noches eternas rellenando formularios, o el entusiasmo contenido del que cree que un diagrama de flujo puede resolver cualquier crisis. Ni tanto, ni tan poco. ITIL no es el enemigo, pero tampoco es la salvación definitiva. Y en el mundo de SQL Server, si sabemos adaptar sus principios con criterio, puede marcar la diferencia entre sobrevivir y gestionar con cabeza.

Sí, ITIL nació en un entorno más orientado a servicios IT generales, con vocación de biblioteca pesada y burocracia estructurada. Pero entre tanta sigla y proceso hay ideas útiles, aplicables a nuestro día a día como DBAs. El truco está en no convertirlo en un ministerio de tickets que nadie entiende, sino en un marco de trabajo razonable que nos ayude a ser menos reactivos y más estratégicos.

Vamos a bajar ITIL al barro del SQL Server. Y a hacerlo sin perder el alma en el intento.

Incidencias, problemas en ITIL: el arte de no confundir las cosas

Una de las primeras cosas que ITIL pone sobre la mesa —y que en el mundo DBA muchas veces ignoramos por pereza o costumbre— es la diferencia entre una incidencia y un problema. Parece menor, pero no lo es.

Una incidencia es un evento que interrumpe un servicio o reduce su calidad. Ejemplo: el job de backups ha fallado esta noche. Salta alerta, lo reejecutamos, y listo. Un problema, en cambio, es la causa raíz de una o más incidencias. Si ese job falla cada martes a las 2:00 porque coincide con una tarea de antivirus que bloquea el acceso al disco, eso es un problema.

Y aquí viene la parte divertida: si tratamos cada incidencia como un caso aislado, nos convertimos en técnicos de soporte en bucle, reiniciando servicios y ejecutando scripts hasta la eternidad. Pero si aplicamos la gestión de problemas de ITIL con cabeza, empezamos a ver patrones, causas reales y soluciones permanentes.

En resumen: no todo lo que rompe un proceso requiere abrir un post-mortem. Pero tampoco todo lo que se resuelve fácil está realmente arreglado.

Gestión de cambios en ITIL: ni todos los cambios necesitan CAB ni todo vale en producción

¿Has hecho un cambio menor en una base de datos y se ha caído media aplicación? Bienvenido al club. La gestión de cambios de ITIL no es solo para empresas con equipos de 200 personas y reuniones semanales de CAB (Change Advisory Board) donde nadie sabe qué se está aprobando. También tiene su lugar en entornos más pequeños y técnicos, si la aplicamos con lógica.

La clave está en clasificar los cambios. Un cambio estándar (como añadir una columna no crítica en una tabla interna) no necesita tres aprobaciones y un PowerPoint. Pero un cambio significativo (como migrar índices a un nuevo filegroup, o modificar la lógica de un procedimiento que usan 40 aplicaciones) sí debe planificarse, testearse y validarse. No por gusto, sino porque sabemos lo que puede pasar si no lo hacemos.

¿Necesitamos herramientas carísimas para esto? No. Un control de versiones decente, documentación clara y una mínima validación con otro DBA ya marcan la diferencia. Lo que no se puede seguir haciendo es modificar objetos en producción directamente “porque era urgente”. ITIL no lo permite, y nuestra salud mental tampoco.

SLAs en ITIL: prometer menos, cumplir más

Uno de los capítulos más ignorados de ITIL en entornos de administración de bases de datos es el de los SLA. Y no por falta de interés, sino porque muchos creen que los SLAs son cosas que firman los proveedores con sus clientes, no algo que debamos aplicar en un equipo interno de IT. Error.

Tener acuerdos de nivel de servicio realistas nos permite dejar de correr detrás de expectativas imposibles. Si el SLA dice que las restauraciones completas deben estar disponibles en 1 hora y tú sabes que el backup de 1,2 TB tarda 3 horas en copiarse por red… tenemos un problema. Y no es técnico, es de expectativas mal gestionadas.

Definir SLAs internos para cosas como tiempos de recuperación, respuestas a tickets críticos o disponibilidad de entornos de desarrollo nos da aire. Y, sobre todo, nos da un marco para decir “esto no es un fallo nuestro, es un riesgo aceptado”.

Por cierto, si tu jefe quiere un SLA del 99,999% pero no quiere gastar en alta disponibilidad… enséñale el coste real del «cinco nueves» y deja que saque la calculadora.

Cómo aplicar ITIL sin acabar atrapado en una burocracia kafkiana

La gran crítica a ITIL (y no sin razón) es que si se aplica sin cabeza, se convierte en un monstruo de procesos que matan la agilidad. Pero se puede hacer de forma sensata.

Para la gestión de incidencias, basta con tener un sistema de seguimiento que no sea una libreta o el correo de soporte. Un sistema sencillo, con prioridad real (no todo es “crítico”), histórico y cierre con causa anotada. Un Excel bien estructurado ya es mejor que el caos.

Para la gestión de problemas, necesitamos tiempo y foco. Una revisión semanal o mensual de incidencias repetidas, análisis de tendencias y propuestas de mejora. Nada de reuniones eternas, sino una hora técnica bien aprovechada.

Y para la gestión de cambios, un flujo simple: idea → validación técnica → test → ejecución → revisión. Si podemos automatizar despliegues, mejor. Si no, al menos que haya trazabilidad. Lo importante es que nadie toque sin avisar ni se entere el lunes por los logs de errores.

¿Hay herramientas que nos ayuden?

La buena noticia es que muchas de estas prácticas pueden integrarse en herramientas que ya usamos: Azure DevOps, Jira, ServiceNow, incluso PowerShell con Git. No necesitas montar un ITSM completo si estás en un entorno más técnico o ágil, pero sí necesitas orden, visibilidad y un mínimo de formalidad.

ITIL no va de rellenar formularios absurdos. Va de saber qué pasa, por qué pasa y qué se está haciendo para evitar que vuelva a pasar. En SQL Server, eso se traduce en menos emergencias y más control. Y eso, amigos, se agradece.

Conclusión

ITIL no es una religión, ni una cárcel de procesos. Es una caja de herramientas. Usada con criterio, puede ayudarnos a distinguir entre apagar fuegos y rediseñar el sistema contra incendios.

Como DBAs, podemos ignorarla y seguir a salto de mata, o podemos aplicar sus principios sin convertirnos en burócratas. Si lo hacemos bien, el resultado es menos caos, menos sorpresas y más tiempo para lo que realmente importa: anticiparnos a los problemas antes de que sean noticias en la monitorización.

Y si encima podemos justificar nuestras decisiones con un marco reconocido, mejor que mejor. Aunque nunca llegues a decir que «sigues ITIL», si aplicas sus principios con cabeza, se va a notar. Y eso, en esta profesión, ya es mucho.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!