Reutilización segura de automatizaciones entre clientes MSP

El avance más importante en programación y TI, con diferencia, es Ctrl+C y Ctrl+V. Pero todo tiene un reverso tenebroso. Cuando hablamos de MSPs que crecen, estos deben hacerlo necesariamente sobre los cimientos de automatizaciones reutilizables, porque si no, es imposible. Cuando funciona, es genial y nos sentimos reyes. Pero la tentación de pulsar Ctrl+C y Ctrl+V es poderosa y replicar automatizaciones como si los entornos cliente fueran idénticos abre la Caja de Pandora, nunca mejor dicho en nuestro caso.
Hoy trataremos de navegar esos mares, analizando cómo reutilizar lo que ya funciona sin arrastrar errores, rigideces o herencias envenenadas de un entorno a otro.
Y un pequeño spoiler antes de continuar. Reutilizar no consiste en que las teclas Ctrl, C y V estén desgastadas en el teclado de tanto copiar scripts.
La clave es diseñarlos desde cero para que se puedan reutilizar.

Por qué es necesario reutilizar automatizaciones en un MSP

Básicamente, un MSP que no reutiliza se condena a rehacer idéntico trabajo una y otra vez. El mismo sufrimiento tedioso de Sísifo con su piedra empujando montaña arriba, pero encima, facturando horas que devora un margen de beneficio cada vez más menguante.
Sin reutilización, el coste operativo crece en paralelo a la cartera, por esa necesidad de construir desde cero. El onboarding se eterniza y la consistencia entre entornos se desvanece, porque cada técnico monta las cosas a su manera y con el pie con el que se haya levantado ese día.
La reutilización es lo que permite que escalar no signifique aumentar el equipo técnico al mismo ritmo que la facturación, de modo que es el ingrediente que permite crecer el MSP en lugar de engordar el problema.

El error clásico: copiar y pegar lógica pensada para un solo cliente

En la intro ya intuíamos un problema que conviene desarrollar.
Alguien resuelve un problema para el Cliente A, funciona, es genial, brindamos, nos damos la palmadita en la espalda y ese mismo bloque tiende a replicarse en los clientes B, C y D sin tocar una coma.
Pero en demasiadas ocasiones, esa lógica viene con suposiciones incrustadas que solo eran ciertas para A, de modo que cuando lo reutilizamos tal cual… Ni brindis, ni palmada, ni genialidad, solo desastre.
Los sospechosos habituales en esas automatizaciones no reutilizables son:

• Scripts hardcodeados con rutas, nombres de servidor o identificadores que solo existen en un entorno.
• Umbrales fijos que tenían sentido para una pyme de cinco máquinas y son un disparo en el pie para una fábrica de quinientas.
• Credenciales incrustadas en el código que, además de frágiles, son el desayuno preferido de hackers y script-kiddies.
• Dependencias no documentadas, porque esa librería o servicio previo que es necesario tener instalado y configurado, «se daba por hecho», cuatro palabras que profetizan horas extras en IT.
• Flujos que asumen topologías concretas, como si todos los clientes tuvieran la misma red, cuando en la vida real apenas se parecen.
• Acciones pensadas para un único contexto, que en otro son como poner una bomba bajo la silla y encender la mecha.

El resultado es que una automatización que ahorraba diez minutos en ese cliente A provoca la caída de B y la llamada llena de palabrotas.
Y como los errores de automatizar procesos en un MSP se multiplican por el número de clientes afectados, lo que era una piedra en el camino se convierte en un desprendimiento que nos aplasta.

Qué hace segura una automatización reutilizable

Nada más irritante que señalar problemas sin aportar soluciones, así que empecemos con ellas.
La buena noticia es que la diferencia clave entre una automatización peligrosa y una reutilizable es su diseño, de modo que no se reduce a puro presupuesto o acceso a herramientas arcanas.
Así, una automatización es reutilizable de forma segura cuando cumple los siguientes principios, que también son los que aplicaríamos a cualquier código que queramos mantener con vida:

• Parámetros por cliente o tipología. La organización debe seguir la buena práctica de que la lógica viva en un sitio y los valores que cambian en ella lo hagan en otro. De este modo, la variable $umbral se lee de la configuración del cliente y no resulta un valor concreto tatuado a fuego en la línea 42.
• Separación entre lógica común y variables locales. De nuevo, el qué se hace es algo compartido, pero con qué datos se hace es algo local de cada cliente.
• Control de permisos. Lo que implica que cada automatización actúa solamente donde le corresponde, adaptando esos permisos por cliente.
• Trazabilidad. Fundamental para cuando algo sale mal y comienza el «juego de la culpa». En él es fundamental saber quién ejecutó qué, con qué parámetros y con qué resultado. Sin esto, la auditoría se convierte en una novela de Agatha Christie para descubrir qué ocurrió.
• Validación previa, obviamente, antes de que la reutilización actúe «en vivo» sobre algo que importe.
• Manejo de excepciones, porque asumir que todo irá bien es la fantasía favorita del script casero y, como el resto de fantasías en IT, se nos quedan siempre en eso.
• Rollback. En realidad, todos sabemos que la mejor invención en IT es Ctrl+Z para deshacer nuestros desaguisados. El equivalente de ese atajo debe estar incluido en toda acción crítica y debemos ser capaces de volver atrás en cuanto empecemos a oler el humo del incendio.
• Documentación mínima operativa, para que el técnico que llegue mañana no tenga que descifrar jeroglíficos.

Conviene aquí no confundir el concepto de reutilizar con el de estandarizar servicios sin depender de scripts manuales.
La estandarización tiene como misión definir el comportamiento esperado y unificarlo, mientras que la reutilización lo despliega. No son lo mismo, pero se necesitan, ya que la una sin la otra cojea.

Qué no debería reutilizarse sin adaptación

La eficiencia es maravillosa hasta que borra todos los archivos con un mensaje de: «Ops, lo destruí todo (emoji de sonrisa orgullosa con mofletes rosados)».
Por eso hay cosas que no deberían viajar de un cliente a otro sin pasar antes por una revisión seria.
El criterio para dilucidar qué verificar bien es sencillo: Si el coste de equivocarse es alto y el contexto manda, frenamos y echamos un buen vistazo.
Por eso jamás debemos reutilizar sin adaptar:

• Las acciones sensibles sobre producción. O esas en las que un fallo se mide en el número de demandas que meterá el cliente y no en minutos de downtime.
• Flujos muy dependientes de topologías concretas. Porque si una infraestructura es muy «especial», no permitirá reutilizaciones de otros sobre ella, ni desde ella a otros clientes. Por ejemplo, lo que en una red es trivial, en otra puede ser dejarse el grifo abierto con reutilizaciones ciegas.
• Las remediaciones basadas en señales ambiguas. Estas tienen el mismo problema que un tricorder de Star Trek mal ajustado, de modo que si la lectura no es fiable, la acción tampoco lo será. Así, hemos de evitar actuaciones automáticas sobre datos nebulosos.
• Las automatizaciones con umbrales no validados en el nuevo entorno.
• Las tareas críticas sin seguro de vida. Lo que se traduce en la regla de oro que no me cansaré de repetir: Sin rollback no hay reutilización.
• Los scripts artesanales acumulados con lógica heredada, que nadie se atreve a tocar porque solo Pascual sabía lo que hacían. Pero es que Pascual lleva dos años cultivando berzas en Guatemala, porque IT es una cantera inagotable de futuros agricultores y poetas, que no quieren saber nada de tecnología.

Cómo diseñar automatizaciones reutilizables en un entorno multicliente

Antes hablaba de que una buena reutilización es una cuestión de diseño, especialmente en una operación multicliente como la de un MSP.
¿Y cuáles son los pasos del guion a seguir para ese diseño basado en buenas prácticas?

• Definir bloques comunes. Identificando la lógica que se repite de verdad y aislándola como ladrillo reutilizable, no como verdad absoluta a clonar «tal cual».
• Parametrizar por cliente. Cuando les vendimos nuestros servicios, seguro que les dijimos que eran especiales. Toca cumplir eso y todo lo que cambia entre entornos se convierte en variable externa, nunca en valor fijo.
• Segmentar por tipología. Agrupando clientes y activos por características comunes, de modo que un servidor Nginx se comporta igual sea de quien sea.
• Probar en grupos pequeños. Meter el dedo en el agua para ver cómo está (o por si la piscina se encuentra vacía) es una buena práctica para todo lo relacionado con IT. En este caso, debemos desplegar primero en un puñado de entornos controlados, antes de aplicar las automatizaciones a nuestra flota completa. Como diría cualquier capitán prudente: «Escudos arriba» antes de entrar en territorio desconocido.
• Documentar variables y límites. Dejando bien claro, y bien accesible, qué se puede tocar, qué no y entre qué rangos.
• Versionar los cambios. Preferiblemente, evitando denominaciones como final_v2_ahora_si_de_verdad.ps1. Debemos usar un control de versiones real para que todos usen la misma lógica validada.
• Revisar el mantenimiento real. Una automatización no es un monumento a nuestro genio que levantamos y olvidamos, para que las palomas lo decoren con el tiempo. Se trata de algo vivo que hay que comprobar cada cierto tiempo, para ver si funciona bien y sigue teniendo sentido.
• Limitar las excepciones fuera de plantilla. Volviendo a los clientes «especiales», necesariamente habrá excepciones, pero cada «caso singular» que definamos más allá de variables es deuda técnica que nuestro yo futuro pagará con intereses. Una excelente regla para la vida es intentar fastidiar lo menos posible a nuestro yo del futuro y esto enlaza directamente con qué procesos automatizar primero en un MSP.

Qué cambia cuando un MSP reutiliza con criterio

Muchas promesas tecnológicas no se trasladan bien del PowerPoint que las vende a la realidad que las vive. Pero en este caso, si hay una buena reutilización, también habrá señales como:

• Menos trabajo repetido y repetitivo, ya que lo que se resuelve una vez se aplica a todos los que comparten tipología.
• El onboarding es más rápido. Una cuestión de horas y no un suplicio de semanas.
• La operación se vuelve más homogénea, con menos sorpresas según quién esté de guardia, lo que también se traduce en…
• Reducir la dependencia de personas concretas, porque el conocimiento vive en el sistema y no en esos genios de turno que de nuevo están pensando más en berzas que en bits.
• El coste de mantenimiento desciende, pues actualizar una lógica común ya no implica retocar a mano doscientos archivos como si hubieran vuelto los noventa.
• Crece nuestra capacidad de escalar y absorber nuevos clientes sin que el equipo entre en combustión.
• Pero sobre todo, tenemos un mejor control sobre cambios y errores, que es lo que distingue a un MSP que escala de uno que aprieta los dientes y reza.

Cómo ayuda Pandora FMS a reutilizar automatizaciones entre clientes MSP

Llegados a este punto del viaje, toca aterrizar todo esto en herramientas.
Obviamente, nuestra apuesta para facilitarte el proceso de reutilización es Pandora FMS. Y es imposible que hable de ella sin sesgos, es la herramienta que conozco y la organización que nombra cada servidor propio con una referencia a Star Trek. Sin embargo, lo que puedo garantizar es honestidad como la Federación y que vendemos tecnología, pero no motos.
Pandora FMS está pensada desde las trincheras del entorno multicliente, donde reutilizar sin perder el control es el pan de cada día.
Sus plantillas y políticas reutilizables codifican el conocimiento operativo una vez y lo aplican a todos los clientes de la tipología correspondiente. Así, un dispositivo nuevo hereda la política que le toca sin intervención manual ni olvidos.
La posibilidad de segmentación por grupos y clientes permite esa separación necesaria cuando operamos como multi-tenant.
El inventario y el contexto operativo evitan actuar a ciegas, y la visibilidad centralizada desde la Metaconsola ofrece un single pane of glass para supervisar todos los entornos sin pestañear, como un Palantir bondadoso, que solo te corrompe el alma lo justo.
A todo esto se suma la trazabilidad de acciones.
Con Pandora FMS queda registrado qué se ejecutó, con qué versión y con qué resultado, algo clave para una gestión del cambio sana y unas auditorías que no se conviertan en que todos señalan a todos con el dedo.
Y si la seguridad forma parte del servicio (no sé si queda algún entorno donde no lo haga, y más en el contexto actual) Pandora SIEM unifica la consola de eventos y reduce el exceso de alertas, alineándose con marcos de referencia como los de ENISA o CISA.
Así, la gestión multicliente escala en operaciones y seguridad sin que se nos caiga el control por el camino.

Conclusión

Recapitulemos lo más importante.
Reutilizar automatizaciones entre clientes no consiste en clonar scripts y cruzar los dedos. Se trata de construir una lógica común lo bastante flexible y controlada como para operar varios entornos sin multiplicar el riesgo ni el trabajo.
La llave que abre esa cerradura doble es el diseño, parametrizando en lugar de practicar el noble arte del hardcode, segmentando y no generalizando, validando en lugar de asumir (que es siempre un primer paso hacia el desastre) y, sobre todo, tener siempre abierto el camino de retirada, por si hay que apretar un Ctrl+Z de emergencia.
Si lo hacemos así, nos convertiremos en un MSP que crece de verdad, en lugar de acumular clientes y, con ellos, escalar los problemas y no las operaciones.
Las modas son poderosas, pero automatizar como sea porque parece que es lo que toca hoy puede comprarnos un billete de ida a la quiebra. Nuestra misión es llegar a donde nadie ha llegado jamás, sí, pero no desguazando la nave por el camino.