Estandarizar servicios MSP sin depender de scripts manuales

Cuando era niño, descubrí pronto que crecer era una trampa, y lo mismo ocurre en un MSP si no se lleva mucho cuidado. Porque al principio todo es genial, champán para todos por los nuevos contratos, pero conforme aumenta la infraestructura gestionada, también crecen los desafíos para controlarla. Y si nuestra operativa para gestionar esa mayor dimensión es acumular scripts artesanales y rezarle al genio de nuestros técnicos, no estamos escalando, sino engordando un problema.
En el día a día de un MSP, la presión por resolver el ticket y cumplir el SLA (Service Level Agreement) empuja a los técnicos a crear soluciones rápidas. Es el «modo héroe» que he mencionado alguna vez: alguien detecta un patrón, escribe un código ingenioso y solventa el rompecabezas para tres clientes.
El problema es que esas catedrales de palillos no son una solución factible en una estructura operativa global con docenas o cientos de clientes. La única solución es una estandarización real, que debería eliminar la necesidad de esos scripts artesanales en primer lugar.

El problema de los scripts manuales en las operaciones de un MSP

El script manual es el primer paso hacia la automatización, pero también el clavo en el ataúd de la escalabilidad si no evolucionamos desde ahí.
En entornos multicliente, los problemas de depender de scripts lanzados a mano o mediante tareas programadas inconexas son evidentes:

• Variabilidad incontrolada: El mismo script puede comportarse de forma distinta en un Windows Server 2019 que en un 2022, si no hay una capa de abstracción que normalice el entorno.
• Fragmentación del conocimiento: Si Pascual deja la empresa, porque siempre fue un genio, pero nunca cobró como tal, sus scripts se convierten en legacy code instantáneo. Nadie se atreve a tocarlos por pánico a romper un equilibrio precario que solo comprendía esa cabeza llena de atajos de Vim y datos de Star Trek.
• Falta de trazabilidad: ¿Quién ejecutó el script? ¿Con qué parámetros? ¿Qué error devolvió antes del incendio que produjo? En una operativa basada en archivos sueltos, la auditoría (por no decir la autopsia) es una pesadilla de logs dispersos.
• Mantenimiento imposible: Si tenemos 200 scripts para 50 clientes, actualizar una lógica común implica 200 ediciones manuales, buena suerte con el hecho de que no se cuelen erratas. Y además, ese sistema de nombres que parecía tan genial el primer día ya no lo comprende nadie. Esa es una invitación formal al error humano.

La operación MSP a escala exige que dejemos de ver los scripts como la solución y empecemos a verlos como los ladrillos de algo más grande: Las políticas técnicas.

Cuándo un script deja de ser una solución y se convierte en un riesgo

Existe un punto de inflexión donde lo que nos ahorraba tiempo empieza a robarlo. Suele coincidir con un crecimiento que abre la puerta a esos primeros clientes con «necesidades especiales».
Ahí comienza el riesgo cuando un script:

• Carece de control de versiones real: No basta con tener un script_v2_final_ahora_sí_te_lo_juro.ps1. Sin un flujo de control de versiones, que asegure que todos los técnicos usan la misma versión validada, la inconsistencia está garantizada.
• No tiene un manejo de errores (Error Handling) robusto: La mayoría de scripts caseros asumen que todo irá bien. Pero cuando fallan, lo suelen hacer de forma silenciosa o dejando el sistema en un estado inconsistente.
• Depende de credenciales locales: Si ciertas operaciones necesitan privilegios, al incrustar usuarios y contraseñas en código (aunque sea ofuscado) cometemos vulneraciones de seguridad que ningún responsable de operaciones o CTO debería permitir.
• No asegura el mismo funcionamiento en todas las ocasiones: Si ejecutas el script dos veces, ¿rompe algo? ¿Está programado para esa repetición de ejecuciones sean cuales sean las condiciones? Una estandarización efectiva requiere que las tareas se aseguren de que el sistema esté en el estado deseado, sin importar cuántas veces se lancen (es decir, idempotencia, mi tecnicismo favorito).

La clave es que, si nuestro equipo pasa más tiempo haciendo troubleshooting de sus propios scripts que de los problemas de los clientes, hemos cruzado la línea y estamos operando en la zona de peligro. Nuestra fragilidad operativa consumirá cordura, paciencia del cliente y margen de beneficio.

Estandarizar no es automatizar sin criterio

En muchas ocasiones estandarizar y automatizar se usan como sinónimos, pero esos dos conceptos están muy lejos en el diccionario. Y en la operación de un MSP a escala, que debe ser nuestro objetivo, la distinción entre ambos verbos es vital.

• Automatizar es conseguir que una tarea se realice sola. Podemos automatizar el reinicio de un servicio que se cae, por ejemplo, lo que nos ahorrará cinco minutos de técnico.
• Estandarizar es decidir que todos los servidores de base de datos de todos nuestros clientes deben tener la misma política de retención de logs, el mismo nivel de parches e idéntico comportamiento ante un fallo de servicio, independientemente de la tecnología subyacente, gracias a una capa de abstracción que normalice los distintos entornos.

Eso nos muestra la primera diferencia fundamental:
La estandarización es estratégica, mientras que la automatización es táctica.
No podemos tener una automatización y estandarización MSP efectiva si primero no hemos definido el comportamiento esperado de nuestra flota (estelar) de activos gestionados.
Por eso hablaba antes de políticas y no de scripts cuando queremos estandarizar de verdad. Dicha estandarización significa que, en lugar de lanzar un script para «limpiar discos», aplicamos una política técnica que dice:
«Cualquier endpoint etiquetado como ‘Servidor Web’ debe mantener al menos un 15% de espacio libre, eliminando temporales de más de 30 días».
La herramienta se encarga del cómo, pero la estandarización define el qué y el cuándo.
Por eso empezar por scripts, en lugar de políticas, es construir la casa por el tejado.

Qué significa estandarizar servicios en un MSP

Para un responsable de soporte o director técnico, la estandarización debería ser sinónimo de paz mental y claridad de actuación conforme a las mejores prácticas. Que suena muy a folleto corporativo, lo sé, pero implica que tenemos una plantilla general a partir de la cual levantar nuestro trabajo. De esa manera, definir servicios estandarizados significa que nuestro catálogo de soluciones es consistente.
Si, por ejemplo, ofrecemos un «Servicio de Gestión de Seguridad de Endpoints», ese servicio debe ejecutarse de la misma forma para una gestoría con cinco empleados que para una fábrica con quinientos.
Los parámetros concretos cambiarán, obviamente (habrá excepciones de firewall, diferentes horarios de escaneo según la actividad de la empresa…), pero la lógica operativa es idéntica.
Estandarizar es ofrecer el mismo nivel de control y calidad técnica sin que importe quién esté de guardia en el NOC esa noche monitorizando los sistemas. Es convertir nuestra operación en un proceso tan eficiente que enorgullecería a los Borg, porque la improvisación ha sido desterrada en favor de procesos repetibles y medibles.
Sin esto, es imposible operar cientos de clientes MSP con el mismo equipo técnico.

Los elementos clave de una estandarización efectiva

Para romper la dependencia de los scripts manuales, debemos construir un marco de trabajo operativo basado en los siguientes pilares:

1. Políticas técnicas comunes

En lugar de tareas aisladas, hablamos de actuaciones generales.
Una política es un conjunto de reglas que se aplican automáticamente a un grupo de dispositivos basándose en criterios lógicos (el sistema operativo, el papel que tiene el servidor, la etiqueta asignada al cliente…).
Si entra un nuevo servidor en el sistema, este hereda la política que le corresponde según su naturaleza, eliminando olvidos y errores humanos durante su configuración.

2. Parámetros por tipología de cliente

La estandarización no implica una dictadura de configuración única para todos.
Un buen modelo permite definir una lógica estándar pero con parámetros personalizables.
El script base es el mismo para todos, pero el valor de la variable $UmbralAlerta, por ejemplo, se lee de la configuración específica del cliente.
Esto permite flexibilidad sin romper la uniformidad del código.

3. Control de cambios y trazabilidad

Cada acción ejecutada sobre la infraestructura del cliente debe quedar registrada de forma centralizada y segregada por cliente (multitenant).
No en el log local de la máquina en la que actúa para que luego se olvide y nunca más se supo, sino en nuestra consola de gestión.
Debemos saber exactamente qué versión de la política se aplicó y cuál fue el output del proceso. Esto es fundamental para un buen cumplimiento y, sobre todo, para eliminar el error humano en mantenimientos MSP.

4. Reutilización segura entre clientes

La estandarización permite crear nuestra Biblioteca de Alejandría particular con «bloques operativos» validados.
Si desarrollamos una forma eficiente de monitorear una infraestructura, dicha lógica debe estar disponible para ser desplegada en otros clientes «con un clic», sin necesidad de reescribir nada.
Obviamente, no será con un clic, pero creo que se entiende la esencia.

5. Eliminación de dependencias individuales

El repositorio de conocimiento debe ser el sistema, no la cabeza de Luis, que está deseando comprarse una pequeña huerta al sol, porque sus sueños tecnológicos se volvieron distopía.
Al documentar la lógica dentro de una plataforma de gestión profesional, permitimos que un técnico junior pueda ejecutar procedimientos complejos de forma segura, porque la inteligencia de dicho proceso ya está integrada en la política estandarizada.
Esto es clave para romper la dependencia de técnicos imprescindibles y que Luis cumpla su sueño de cultivar berzas sin poner en peligro nuestra iniciativa de negocio.

El impacto directo de la estandarización en la operación MSP

Cuando dejamos de pelear con archivos .bat y empezamos a gestionar políticas, los beneficios se reflejan positivamente en la cuenta de resultados y las ojeras del equipo, mediante:

• La reducción drástica de errores: La automatización estandarizada no se cansa ni se equivoca al escribir una ruta de archivo. La variabilidad desaparece y, con ella, los incendios provocados por fallos humanos en tareas rutinarias.
• Un onboarding más rápido: Integrar a un nuevo cliente no implica tres semanas de proyecto de ingeniería. Es cuestión de asignarle las políticas técnicas correspondientes a su perfil, comprobar las modificaciones concretas que necesita en los detalles y dejar que el sistema haga el despliegue inicial.
• Una menor carga de soporte reactivo: Al gestionar entornos más homogéneos y predecibles, las incidencias extrañas y las excepciones disminuyen. Esto libera tiempo para que los séniors se dediquen a proyectos de valor y a mejorar esas políticas estrategizando a alto nivel, en lugar de sacar a mano la basura de los cachés.
• Una previsibilidad operativa: Lo aburrido es bueno, lo aburrido es rentable. Así sabemos exactamente cuánto tiempo y recursos consume cada tarea, lo que permite presupuestar servicios con precisión quirúrgica, protegiendo nuestros márgenes de sustos y facturas imprevistas.

Cómo se relaciona todo esto con la operación a escala de un MSP

Sin una estandarización como la que hemos descrito, operar a escala es un espejismo.
Podemos crecer en facturación, pero si nuestros costes operativos engordan al mismo ritmo, porque necesitamos contratar a un técnico por cada X endpoints nuevos, nuestro modelo de negocio está roto.
La escala real solo ocurre cuando el esfuerzo para gestionar mil dispositivos no es significativamente superior al de gestionar cien.
Y eso solo se consigue con una gestión centralizada y estandarizada.
Si cada cliente es un copo de nieve especial con su propia configuración artesanal y puñado de scripts manuales, nuestros sueños de grandeza se traducen en infraestructuras de pesadilla.
La estandarización es lo que permite que el equipo deje de ser un parque de bomberos y se convierta en una unidad de élite, que supervisa y perfila detalles de procesos automáticos.
Ese es el paso necesario para una monitorización MSP profesional.
Tal y como está la competencia actual, los MSP que sobreviven y prosperan no son los que tienen a los técnicos que más scripts sepan escribir de memoria, sino quienes han sabido codificar ese conocimiento en políticas técnicas replicables, seguras y escalables.
Sin ellas, ponemos del revés el objetivo de la tecnología y seremos nosotros los que trabajemos para Skynet, en lugar de que dicha tecnología nos facilite la vida.