metodología

La mayoría de nosotros no elegimos ser DBAs por vocación mística. Llegamos aquí porque alguien tenía que entender por qué un backup no se hace solo, por qué los datos importan más que los informes bonitos y, sobre todo, porque hacía falta alguien que no creyera que «un DELETE sin WHERE es una buena idea». Y dentro de esa jungla, un tema que siempre vuelve, como los bugs tras una actualización mayor, es el de los SLAs. Sí, esos compromisos tan bienintencionados que se convierten en promesas grabadas en piedra cuando algo explota.

SLAs, KPIs y demás siglas que no son lo mismo

Antes de definir cómo establecer un SLA decente, conviene aclarar de qué demonios estamos hablando. Un SLA (Service Level Agreement) es un compromiso formal sobre el nivel de servicio que se debe prestar. En otras palabras: una promesa escrita, medible y revisable sobre tiempos de respuesta, disponibilidad o calidad.

Un KPI (Key Performance Indicator), por su parte, es un indicador que nos permite medir cómo de bien (o mal) estamos cumpliendo esos compromisos. El SLA es el contrato; el KPI, el termómetro. Confundirlos es como pensar que tener fiebre es lo mismo que firmar un seguro médico.

Por ejemplo, si el SLA dice que debemos restaurar una base de datos crítica en menos de 1 hora, el KPI será la métrica que nos dirá cuántas veces lo conseguimos, cuántas nos pasamos de tiempo y cuál es el promedio. Así de simple. Y así de importante.

¿Por qué definir SLAs para incidencias y peticiones?

Los SLAs son como las condiciones de una hipoteca: poca gente los entiende del todo, pero todos los firman y luego lloran cuando llega la letra pequeña. Para nosotros, definir SLAs no es solo una cuestión de burocracia. Es la única forma de establecer expectativas claras (y razonables) entre quien mantiene los sistemas y quien espera que todo funcione como Netflix un sábado por la noche.

SLAs mal definidos acaban en alertas fantasma, restauraciones “urgentes” de bases de datos de hace cinco años y discusiones bizarras sobre por qué una petición enviada a las 18:59 no puede resolverse “antes de irnos”. Así que vamos a ver cómo definirlos bien, con precisión, malicia técnica y sentido común.

Clasificación técnica para SLAs útiles

Lo primero es entender que no todo es “alta prioridad”. Si todo es urgente, nada lo es. Aquí es donde muchos equipos se estampan contra el muro del caos. No es lo mismo que falle un servidor de producción que una petición para crear una base de datos para pruebas. Y sin embargo, en demasiadas empresas, ambas llegan al DBA con el mismo subject: “URGENTE”.

Así que toca clasificar. Podemos dividir las solicitudes en dos grandes grupos: incidencias y peticiones. Las incidencias afectan a la continuidad del servicio. Las peticiones, en cambio, suelen ser mejoras, configuraciones nuevas, cambios programados… todo eso que también puede romper algo, pero con elegancia.

Dentro de cada grupo hay que establecer niveles de prioridad. Una clasificación útil (aunque no la única) sería: 

• Crítica: Pérdida total de servicio o datos. El tipo de cosa que hace que los móviles empiecen a sonar y los jefes pregunten si tenemos backup. Aquí el SLA tiene que ser inmediato. Y sí, esto se traduce en “se deja todo y se arregla”.
• Alta: Impacto serio pero parcial. Por ejemplo, una base de datos de BI que no carga el ETL nocturno. No es producción directa, pero alguien se va a cabrear en cuanto llegue a la oficina. El SLA aquí puede estar en torno a las 4 horas.
• Media: Afecta a una parte del sistema, pero tiene alternativas o workarounds. Por ejemplo, un job de mantenimiento que falla pero no impide operar. SLA de 1 día laboral.
• Baja: Nada crítico. Solicitudes de cambios planificados, creación de logins, ampliaciones de espacio no urgentes. Aquí hablamos de resolverlo en 2-3 días laborables, dependiendo de la carga del equipo.

¿Y los horarios?

Todo esto es muy bonito pero, si vamos a hacer esto bien, hay que dejar claro también dos cosas que en muchos sitios se omiten por pereza (o por miedo a la verdad): qué niveles activan la guardia, y si los SLAs se miden en tiempo real o en horas laborables.

En la mayoría de entornos serios, solo las incidencias críticas (reales, no las autoasignadas por usuarios con complejo de urgencia) justifican una llamada fuera del horario. Si alguien quiere soporte 24×7 para problemas de prioridad media, lo lógico es que también financie un equipo 24×7. Milagros, aquí, los justos.

Y respecto al cómputo del SLA, no es lo mismo “4 horas” que “4 horas laborables”. Si no se especifica, el usuario siempre asumirá que el reloj corre todo el día, todos los días. Por eso, al definir un SLA, hay que dejar claro el calendario de servicio aplicable. ¿Es de lunes a viernes de 9 a 18h? ¿Incluye festivos? ¿Hay soporte en fines de semana? Todo eso tiene que estar negro sobre blanco. Porque si no, luego llegan los correos del domingo a las 7:12 con copia a dirección general preguntando por qué “aún no se ha resuelto”.

Prioridad, entorno y contexto: el barro donde se hunden muchos SLAs

Sería maravilloso vivir en un mundo donde la prioridad depende solo del tipo de incidencia, y no del entorno donde ocurre. Pero eso es teoría. En la práctica, los entornos importan, y mucho. No es lo mismo que se caiga producción que un entorno de desarrollo, ¿verdad? Bueno… depende.

Sí, la regla general dice que los entornos de producción son los únicos donde una incidencia puede alcanzar el nivel crítico. Pero hay excepciones. ¿Puede haber una incidencia crítica en un servidor de test? Sí, si ese entorno es parte esencial de una cadena de despliegue continuo, de validación de procesos regulados o si es el único sitio donde se puede reproducir un bug crítico que bloquea el negocio. No es lo habitual, pero pasa. Y cuando pasa, más vale tener el SLA bien definido y que el equipo no lo desprecie por ser «solo pre».

¿Y qué pasa con los entornos de desarrollo? Pues que en muchas empresas de desarrollo de software, el entorno de dev es tan vital como producción. Si el equipo de desarrollo está bloqueado porque no puede compilar, probar o desplegar por culpa de una base de datos caída, eso no es un problema menor. Igual no es crítico según la jerarquía clásica, pero es de alta prioridad. El mundo real no siempre cabe en una tabla de 2×2.

Restauraciones: ¿petición o incidencia?

Luego está el problema de que lo que para otros es una incidencia para nosotros puede ser una petición. Por ejemplo, clásico de los clásicos, “He borrado una tabla entera sin querer. ¿Esto es una incidencia o una petición?” Técnicamente es una petición (al menos para nuestro equipo), porque no es una caída del sistema. El sistema está funcionando perfectamente… demasiado bien, de hecho. Que tu tengas una incidencia a nivel de aplicación no significa que exista ningún problema a nivel servidor de base de datos. Pero, si lo miramos operativamente tiene impacto inmediato, y no tratarlo con urgencia puede ser un error de bulto. Si no actuamos rápido, el problema para la empresa (quien nos paga) puede escalar a categoría épica.

Por eso, más allá de la matriz estándar de SLAs, es necesario aplicar juicio técnico. No todo cabe en una checklist. Los equipos que sobreviven no son los que aplican normas rígidas a martillazos, sino los que saben cuándo saltarse la regla para evitar un incendio. Y, por supuesto, dejar constancia del por qué.

SLAs de respuesta vs. SLAs de resolución: no es lo mismo

Uno de los errores clásicos al definir SLAs es confundir respuesta con resolución. Responder rápido no significa resolver rápido. A veces basta con confirmar que hemos recibido la solicitud y que estamos en ello (sí, eso cuenta como “respuesta”).

El truco está en comprometerse solo a lo que podemos cumplir. No prometas restaurar un backup en 15 minutos si sabes que el fichero está en cinta y necesitas abrir un ticket a soporte, que luego vienen los lloros.

Una fórmula útil es definir ambos tiempos por separado. Por ejemplo: respuesta en 1 hora, resolución en 4. Así evitamos malentendidos del tipo “pero si dijiste que lo tendrías ya”.

¿Quién prioriza los SLAs y cómo evitar el caos?

Aquí es donde se separan los SLAs útiles de las cartas a los Reyes Magos. No podemos dejar que sea el usuario quien marque la prioridad. No porque no sepa lo que necesita, sino porque siempre va a considerar su problema como el más importante del universo. Y porque si le dejas elegir, todas las solicitudes serán “urgentes, críticas y con impacto en negocio”.

La clasificación debe estar en manos del equipo técnico, o al menos ser revisada por él. Idealmente, con criterios claros, objetivos y documentados. Sí, documentados. Aunque nos duela.

Y si hay un catálogo de servicios (y debería haberlo), que incluya ejemplos de cada tipo de incidencia o petición con su prioridad y su SLA correspondiente.

Qué hacer si un SLA no se cumple

Lo vamos a decir sin rodeos: si no hay consecuencias por incumplir SLAs, entonces son solo papel mojado. Ahora bien, tampoco se trata de irse al extremo contrario y penalizar con sangre y fuego a quien llega tarde a resolver un bug.

La clave está en el seguimiento. Medir los SLAs, revisarlos con regularidad, identificar por qué se incumplen (si se incumplen) y actuar. Puede que no se cumplan porque el equipo está desbordado. O porque el sistema de alertas es más pesado que útil. O porque alguien sigue mandando incidencias al correo personal del DBA “porque así va más rápido”.

Hacer seguimiento no es buscar culpables, es afinar procesos. Aunque si descubrimos que todas las incidencias llegan marcadas como críticas por el mismo usuario… bueno, ya sabemos a quién regalarle un curso de lectura de SLAs.

Cómo definir SLAs realistas sin usar magia negra

Definir buenos SLAs requiere conocer bien la infraestructura, los recursos disponibles y las prioridades del negocio. No podemos copiarlos de otro departamento ni improvisarlos en una reunión con PowerPoint. Hay que sentarse, medir tiempos reales de resolución, analizar históricos y, a ser posible, usar herramientas que permitan registrar y categorizar incidencias de forma estructurada.

Y si alguien insiste en que hay que tener un SLA de resolución de 15 minutos para restaurar cualquier base de datos, podemos responder con otra petición: “Vale, ¿me das almacenamiento dedicado y restauraciones «preindexadas» también?”. Spoiler: no lo hará.

Conclusión

Los SLAs no son una varita mágica ni una forma elegante de decir “hazlo rápido”. Son un acuerdo técnico con implicaciones reales. Si los definimos bien, nos ahorran dolores de cabeza, discusiones bizantinas y promesas incumplidas. Si los dejamos al azar, acabaremos apagando fuegos a todas horas y con la sospecha constante de que nos están tomando por el servicio técnico de la impresora.

Así que toca hacer el trabajo sucio: clasificar, medir, escribir, negociar. Con criterio, con datos, y sin miedo a decir que no cuando un SLA no tiene sentido. Porque, como ya hemos aprendido todos a estas alturas, prometer lo imposible es la forma más rápida de acabar con una alerta crítica… y un ticket de recursos humanos.

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!

Llevamos varias semanas dedicando los viernes a hablar de metodología, hemos visto Six Sigma, ITIL, Agile, Lean y hasta procesos DevOps. Hoy no vamos a hablar de ningún procedimiento en concreto sino de buenas prácticas generales a la hora de gestionar un cambio. En resumen, hacer las cosas con sentido común.

Decir “vamos a cambiar algo en producción” nunca debería sonar como “crucemos los dedos y a ver qué pasa”. Y sin embargo, más veces de las que nos gusta admitir, ese es exactamente el procedimiento. Porque claro, todo empieza con buena intención: una mejora de rendimiento, una corrección pequeña, “solo un índice” (maldita frase). Pero luego llega el drama, el monitor rojo, el jefe preguntando y el log lleno de errores que no deberían estar ahí.

En este artículo vamos a hablar de cómo gestionar el cambio en sistemas de bases de datos sin que acabe en desastre. O al menos, sin que tengamos que tomar antiinflamatorios a puñados. Porque cambiar en producción es inevitable. Lo que no debería serlo es sufrir cada vez como si estuviéramos lanzando un cohete a Marte con una escoba.

Antes del cambio: sospecha, planifica y valida

La gestión del cambio empieza mucho antes del cambio. Empieza con la duda. Si alguien te dice que es un cambio trivial, deberías activar inmediatamente el protocolo de escepticismo técnico. Los “solo era un índice” son los nuevos “yo controlo”.

Antes de tocar nada, necesitamos entender qué cambia, por qué y qué puede romperse. Parece obvio, pero demasiadas veces se ejecuta sin tener esto claro. Haz preguntas. ¿A qué objetos afecta? ¿Qué procesos dependen de esto? ¿Qué pasa si el cambio no se aplica bien? ¿Hay rollback?

Una vez identificados los riesgos, toca planificar. Y eso incluye mucho más que escribir el script. Hay que definir ventanas, implicar a los equipos afectados, coordinar timings y sobre todo, preparar el entorno. Tener backups recientes, estadísticas actualizadas, y entornos de prueba que sean de verdad representativos (no una base de 50 MB donde todo va rápido porque no hay nada).

En este paso, valida todo lo que puedas antes del cambio. Ensaya el script. Simula el rollback. Comprueba el rendimiento. Documenta las dependencias. Y si no tienes claro cómo validar algo, ya tienes un indicio de que el cambio es más peligroso de lo que parecía.

Durante el cambio: foco, trazabilidad y sangre fría

El momento del cambio no es para improvisar. Es para ejecutar con precisión quirúrgica. Nada de “ah, ya que estamos, meto esto también”. No. Eso no es una ventana de mantenimiento, eso es un ataque a la estabilidad del sistema.

Durante el cambio hay que asegurarse de que todo esté monitorizado. Logs activos, ejecución paso a paso si procede, y alguien siguiendo cada resultado. Si algo tarda más de lo esperado, se para, se revisa y se decide. No se reza, no se ignora. Se actúa.

La trazabilidad es crítica. Ejecuta los scripts con logging detallado. Si algo falla, hay que saber exactamente en qué punto estábamos. Nada de copiar/pegar desde un bloc de notas con modificaciones “on the fly”. Si hay que adaptar algo, se documenta, se explica y se versiona. Lo contrario es una receta para la amnesia operativa.

Y sobre todo, mantén la sangre fría. No importa lo mucho que presionen. Si algo no va bien, se detiene y se evalúa. Porque más vale un rollback a tiempo que una explicación al día siguiente con café y cara de insomnio.

Después del cambio: valida, comunica y documenta (sin convertirte en notario)

Una vez aplicado el cambio, viene la parte que más se salta: la validación post-despliegue. Porque claro, como no ha explotado nada, parece que ya hemos terminado. Error. Muchas veces, los efectos secundarios no se notan hasta que los jobs nocturnos empiezan a gritar.

Valida el sistema. Comprueba rendimiento, bloqueos, integridad. Ejecuta consultas clave. Mira los logs. Pregunta a los usuarios si todo responde como debería. Y si algo parece raro, investígalo. Porque si lo dejas pasar, mañana puede ser peor.

Después viene la documentación. No, no hace falta escribir una novela. Pero sí registrar qué cambió, por qué, cómo, cuándo, quién lo aprobó y qué efectos tuvo. ¿Es burocrático? Sí. ¿Es útil cuando en seis meses alguien pregunta qué demonios pasó ese día? También.

Y sobre todo, hazlo accesible. Nada de carpetas perdidas con nombres tipo “scripts_nuevos_OK_def_3_final.sql”. Usa sistemas de control de cambios, añade comentarios claros y deja constancia de las lecciones aprendidas. Documentar no es ser notario. Es dejar herramientas para no tropezar dos veces con el mismo script.

Y, por cierto, si todo fue bien… agradece al equipo, recoge feedback y ajusta el proceso. La gestión del cambio no es un evento. Es una práctica continua.

Cómo sobrevivir al “pero si solo era un índice”

La frase maldita. Todos la hemos oído. Y todos hemos visto lo que puede hacer un índice mal colocado: planes de ejecución destrozados, consultas que pasaban en milisegundos ahora eternas, deadlocks nuevos como setas. Porque no, un índice no es “solo” un índice. Es una reescritura de cómo el motor piensa. Y el motor, cuando se confunde, no avisa: simplemente arrastra al sistema al abismo.

¿Cómo se sobrevive a esto? Primero, aprendiendo a no confiar en los cambios “pequeños”. Segundo, aplicando buenas prácticas: revisando planes de ejecución, analizando estadísticas, usando INCLUDE, cuidando el orden de las columnas y verificando los efectos reales. Tercero, no dejando que nadie toque índices en producción sin una revisión decente. Da igual si es el desarrollador senior o el jefe de arquitectura. Todos cometemos errores.

Y por último, con monitorización y rollback. Si tras aplicar un índice todo empieza a ir peor, hay que poder volver atrás rápido. No hay gloria en mantener cambios dañinos solo porque “ya están puestos”. El ego no arregla el rendimiento.

Conclusión

Gestionar el cambio en producción no debería ser una ruleta rusa disfrazada de mejora. Exige preparación, criterio y procesos claros. Antes del cambio, duda y planifica. Durante el cambio, ejecuta con precisión. Después del cambio, valida y aprende.

Y si algo falla, no escondas el error. Documenta, comparte y ajusta. Porque los sistemas viven de la mejora continua, no del miedo al cambio. Eso sí: hagamos las cosas con cabeza. Con backups, con monitorización, y con la certeza de que cada “pequeño cambio” puede tener un impacto brutal.

Cambiar no tiene que doler. Pero si duele, al menos que haya ibuprofeno… y logs detallados.

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! 

El romance entre DevOps y SQL Server es complicado. Como esas parejas que se quieren a gritos, viven juntas, pero uno duerme en el sofá y el otro con el gato. Porque claro, DevOps suena precioso sobre el papel: integración continua, despliegues automáticos, infraestructura como código y todo ese rollo de agilidad infinita. Pero cuando llevamos eso a una base de datos relacional que todavía tiene stored procedures escritos en 2009 por alguien que ya no trabaja en la empresa… el cuento cambia.

Nosotros, los DBAs, vivimos en esa intersección peligrosa entre los mundos del código y los datos. Y cuando alguien decide que ahora todo tiene que ir por pipelines de CI/CD porque “lo ha dicho el consultor de DevOps”, hay que tener cuidado. Porque sí, automatizar es maravilloso. Pero automatizar sin entender es como montar un sistema de riego automático sin comprobar si hay goteras. Spoiler: las hay. Y en producción.

Vamos a ver cómo podemos integrar nuestro trabajo como DBAs en ese ciclo CI/CD sin que todo explote. O al menos, sin que explote demasiado.

DevOps, el síndrome del pipeline perfecto y la realidad del script roto

Hay que empezar aclarando una cosa: el mundo del desarrollo de software y el de las bases de datos no evolucionan igual. Mientras los desarrolladores compilan, versionan y despliegan sin mirar atrás, nosotros lidiamos con sistemas vivos. La base de datos no se borra y se vuelve a levantar como si fuera un contenedor. Cada ALTER TABLE toca datos reales. Y cada script mal planteado puede dejar un sistema en coma.

El enfoque de Database as Code nos ayuda a acercarnos al modelo DevOps. Usar herramientas como SSDT, Flyway, Liquibase, Redgate SQL Change Automation o, incluso, migraciones de Entity Framework, nos permite tener nuestros objetos versionados, controlar los cambios y desplegar de forma coherente. Hasta aquí, todo bien.

Pero claro, la teoría no menciona qué pasa cuando hay diferencias de collation entre entornos, cuando un índice tarda 45 minutos en crearse o cuando un trigger olvidado lanza una tormenta de inserts en cascada. Eso no lo arregla ningún pipeline.

Por eso, antes de lanzarnos a automatizar, necesitamos tener una estrategia de cambios bien pensada, un control de versiones sólido y, sobre todo, scripts que no se limiten a “funcionar en desarrollo”. El típico CREATE TABLE que nadie probó con un insert de 10 millones de filas no es infraestructura como código: es una amenaza.

Automatización con cabeza: lo que sí y lo que no en DevOps

No todo se debe automatizar. Sí, lo he dicho. Y lo repito. Hay tareas que siguen necesitando supervisión humana porque los datos no perdonan errores.

Automatiza los despliegues de cambios de esquema cuando están bien versionados y han pasado por entornos intermedios. Automatiza los backups, los restores de prueba, las revisiones de espacio en disco y las tareas de mantenimiento. Automatiza las revisiones de cumplimiento de convenciones con linting de scripts. Incluso automatiza los unit tests con tSQLt si tienes valor.

Pero no automatices, por ejemplo, la ejecución de un DROP COLUMN en producción sin que nadie revise qué otras vistas o procedimientos dependían de ella. Tampoco automatices sin revisión los despliegues que incluyen cambios destructivos o transformaciones masivas de datos. Y por supuesto, no pongas en un pipeline un script que actualiza 300 millones de registros en una tabla sin particiones y sin índices adecuados. Eso no es DevOps. Eso es sabotaje con CI/CD.

Porque sí, puedes tener despliegues automáticos cada cinco minutos. Pero si lo que despliegas son bombas lógicas, lo que estás haciendo no es integración continua: es desastre continuo.

DevOps si, pero con backups

Convertir la base de datos en código es un avance necesario. Repositorio Git, revisiones con Pull Requests, validaciones automáticas, historial de cambios… todo eso mejora la calidad y la trazabilidad. Nos permite dormir un poco más tranquilos. Por algo SSMS 21 incorpora soporte Git.

Pero ojo: base de datos como código no significa que los datos también lo sean. Los objetos son versionables. Los datos no lo son. No de la misma forma.

Por eso, ningún pipeline que toque la base de datos debería existir sin un buen backup previo. Y no, no vale con el backup nocturno. Un BACKUP DATABASE justo antes del despliegue, con nombre identificable y retención clara. Si algo va mal, hay que poder volver atrás. Nada de rezar a San Point-in-Time-Restore.

Además, si versionamos la base de datos, también hay que versionar los scripts de recuperación. ¿Qué haces si se despliega una función que rompe una lógica crítica? ¿Esperar a que el desarrollador vuelva de comer? No. Hay que tener plan B. Y plan C.

Roles y responsabilidades: DevOps no sustituye al DBA

En algunos modelos DevOps mal entendidos, parece que el DBA es prescindible. “Ya tenemos pipelines”, dicen. Claro. Y también tienes un coche, pero no han desaparecido los talleres mecánicos porque ahora sabes cambiar una rueda.

El rol del DBA en DevOps es más importante que nunca. Porque ahora, además de saber mantener sistemas estables, necesitamos saber cómo se integran en procesos automáticos, cómo se controlan los cambios, cómo se auditan los scripts y cómo se asegura la integridad del sistema en cada paso.

El DBA no solo ejecuta. Diseña el flujo. Revisa los PR. Define los checks de calidad. Valida la coherencia entre entornos. Y, sobre todo, es quien entiende que los datos no son líneas de código: son el corazón del negocio. Si fallan, no hay rollback que salve la reputación.

¿Y si todo explota igual?

Spoiler: alguna vez explotará. No importa lo bueno que sea tu pipeline. Alguien olvidará algo. Un script fallará. Una tabla no tendrá stats. Un índice nuevo matará el plan de ejecución.

Lo importante es que cuando eso pase, tengas herramientas para detectar, reaccionar y recuperar rápido. Logging detallado. Monitores activos. Backups listos. Versionado claro. Y sobre todo, un equipo que sepa que los despliegues no son cosa del azar, sino de la preparación. Herramientas como la de Four9s (sponsor de nuestros eventos online mensuales) ayudan a monitorizar estos cambios.

Porque en DevOps, como en SQL Server, todo funciona… hasta que no.

Conclusión

Integrar SQL Server en un entorno DevOps no es imposible, pero tampoco es trivial. Exige entender los riesgos, planificar con cabeza y automatizar sin perder el control. Versionamos código, sí. Pero protegemos datos. Y eso no se hace con fe ciega en YAMLs.

No somos un estorbo para la agilidad. Somos los que impedimos que se despliegue una migración irreversible a las 18:00 del viernes. Así que, si vamos a vivir en este nuevo mundo de CI/CD, vivamos con dignidad. Con backups. Con validaciones. Y con esa sospecha saludable de que un script sin revisar es una granada sin anilla.

El amor entre DevOps y SQL Server existe. Pero como todo amor real, necesita trabajo, comunicación y saber cuándo decir: “Esto mejor lo revisamos antes de darle al botó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! 

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!