Roberto Carrancio

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!