Cómo operar cientos de clientes en un MSP con el mismo equipo técnico

En el episodio «The Trouble with Tribbles» de la serie original de Star Trek, la tripulación del Enterprise descubre que unas pequeñas y adorables criaturas peludas se reproducen como conejos, desbordando cualquier capacidad de gestión. Enseguida aparecen por todas partes, colapsando sistemas y poniendo de los nervios incluso a Spock. No es difícil ver la analogía con un MSP que crece con nuevos clientes, pero no cambia su forma de funcionar.
Los tickets se reproducen como tribbles, los técnicos gestionan con la lengua fuera y lo que al principio era adorable (por el crecimiento de facturación) enseguida muta a una crisis de gestión sin salida aparente.

Por qué escalar un MSP no consiste en contratar más técnicos

La respuesta automática ante el crecimiento suele ser contratar más personal. Es comprensible porque es una acción instintiva, predecible y, sobre todo, no exige la incomodidad de replantearnos cómo hacemos las cosas.
Si tenemos veinte clientes nuevos y contratamos a un par de técnicos, la ecuación parece cuadrada, diez para cada uno. Hasta que la realidad se empeña en no ser lineal y los márgenes se estrechan como esas paredes trampa de las películas, que se cierran sobre nosotros.
Y no quiero sacar a pasear términos de Economía como a veces hago, pero estas soluciones que consisten en meter más componentes en un sistema que no cambia produce enseguida rendimientos decrecientes.
Porque la clave y la restricción no suelen estar en la falta de personal, sino en el modelo operativo.
En las herramientas desconectadas entre sí, las tareas manuales que no nos hemos molestado en automatizar, el aluvión de alertas descontextualizadas que nadie filtra, la falta de estándares que obliga a tratar cada cliente como si fuera el primero…
Añadir técnicos sin corregir esas disfunciones solo escala el caos, haciéndolo más caro sin convertirlo en más eficiente.

Qué impide operar cientos de clientes con el mismo equipo

A nadie le gusta mirarse en el espejo y darse cuenta de que debe cambiar la forma de hacer las cosas, pero si queremos escalar las operaciones, no hay otro remedio.
En nuestra experiencia, estos son los obstáculos más habituales en la operativa de un MSP que impiden escalar las operaciones de manera óptima. Deberíamos examinar honestamente cuántos nos suenan familiares.

• Entornos heterogéneos sin criterios comunes: Cada cliente es un mundo con su propia configuración, sus herramientas particulares y excepciones a considerar. El resultado es que cada incidencia requiere investigación desde cero.
• Onboarding inconsistente: Empezar con un nuevo cliente consume semanas, depende de quién esté disponible y no sigue ningún proceso replicable. A escala, esto es insostenible.
• Soporte reactivo como norma: Si nuestro equipo pasa el 80% del tiempo empantanado con respuestas a lo que ya ha ocurrido, nadie está levantando una infraestructura que prevenga y evite esas incidencias, haciendo que reaparezcan como tribbles.
• Alertas mal afinadas: El ruido operativo destruye nuestra capacidad de priorizar. Cuando todo es urgente, nada lo es y los fallos importantes se pierden en una marea de avisos irrelevantes.
• Documentación dispersa y poca visibilidad transversal: Si para saber el estado de diez clientes debo abrir diez herramientas distintas, la eficiencia ya está comprometida antes del primer café.
• Exceso de trabajo repetitivo y falta de priorización por impacto real: Este es un fantasma que se nos aparece en forma de tareas de bajo valor, que consumen tiempo de nuestros técnicos cuando una máquina podría hacerlo mejor, más rápido y sin quejarse o pillar la baja.

Y ahora que conocemos al enemigo, pasemos a lo importante, la práctica. Vayamos por pasos.

Estandarización: La piedra angular de la escalabilidad en un MSP

Si hay un principio que separa a los MSP que escalan de los que no, es la estandarización. No como eslogan de Powerpoint, sino como condición operativa previa a cualquier otra mejora en esa manera de hacer las cosas.
Este es el primer paso a aplicar en la práctica.
No podemos operar cientos de clientes con eficiencia si cada técnico hace la guerra por su cuenta. La variabilidad destruye la posibilidad de automatizar, documentar, formar y/o predecir. Convierte cada incidencia en un caso único y cada técnico en un especialista imprescindible con su particular libro de trucos.
Y el día que decide marcharse, se lleva consigo meses de conocimiento intransferible.
Estandarizar servicios significa construir un catálogo homogéneo con:

• Las mismas políticas de monitorización.
• Los mismos umbrales base ajustables por cliente.
• Las mismas plantillas de respuesta para las incidencias más frecuentes.
• Un onboarding documentado y repetible, de modo que el técnico nuevo puede operar desde el primer día, porque la inteligencia del proceso está en el sistema, no en la cabeza de alguien sin tiempo para documentar en la base de conocimiento.

La estandarización no elimina la flexibilidad, define una lógica común con parámetros personalizables por cliente.
Así, la inevitable diversidad operativa real se gestiona dentro de un marco controlado y auditable.

La automatización y reducción del trabajo manual

La automatización sin estandarización es potencia sin control: libera mucha energía, pero en todas las direcciones, lo que no permite avanzar en ninguna.
Por eso:

• Primero definimos con precisión qué debe pasar y cómo.
• Luego se automatiza todo lo posible para que ocurra sin nuestra intervención.

Con una base estandarizada, tendremos una categoría de tareas que no deberían tocar manos humanas, como por ejemplo:

• Despliegues rutinarios.
• Comprobaciones periódicas de salud de sistemas.
• Limpieza de temporales.
• Rotación de logs.
• Parches programados.
• Informes recurrentes.
• Escalados automáticos de servicios ante condiciones predefinidas.
• Descubrimiento e inventario de nuevos dispositivos en la infraestructura…

Todo aquello que tiene una lógica predecible y un resultado conocido es candidato a la automatización.
El impacto de estandarizar y automatizar se mide en horas de técnico liberadas.
Si la monitorización de infraestructura es capaz de detectar que un servicio cojea, reiniciarlo, verificar que ha recuperado su funcionamiento normal y cerrar la incidencia sin intervención humana, el cliente no percibe degradación. Así, el SLA se cumple y el técnico que antes hacía eso dedica su tiempo a fingir que trabaja en algo importante.
Ese es el camino real para reducir las horas de soporte sin sacrificar los compromisos contractuales.

Reducir el ruido y mejorar la priorización

Tras estandarizar y automatizar es hora de gestionar el ruido para seguir escalando las operaciones de nuestro MSP sin necesidad de más técnicos.
Un sistema que grita alerta en cada variación de CPU, pico de memoria o latencia momentánea condiciona a los técnicos a ignorar el panel por culpa de todo ese ruido.
Eso es lo contrario de lo que necesitamos porque protagonizamos el cuento de Pedro y el lobo versión IT: Cuando llega el fallo real, nadie está mirando.
Operar cientos de clientes con eficiencia exige trabajar por excepción, no por volumen de avisos, para así reducir falsos positivos y alertas innecesarias. Para ello, debemos meter mano al sistema de alertas en nuestra monitorización, aplicando buenas prácticas como:

• Correlacionar eventos relacionados para que tres alertas de servidores conectados al mismo switch se conviertan en una sola alerta de switch caído.
• Agrupar incidencias del mismo tipo y priorizar según el impacto real en el servicio.

La gestión de eventos debe orientarse a la tendencia y al impacto, no al evento aislado.
Así, un pico de CPU durante un backup nocturno no merece atención humana, es normal. Una degradación progresiva del rendimiento de un servidor de producción durante tres días consecutivos hay que mirarla, aunque ningún umbral estático la haya marcado todavía.

Visibilidad centralizada para múltiples clientes

En las guerras antiguas, el problema era la comunicación. Mensajeros que corrían de acá para allá desde distintas partes de la batalla llevando y trayendo órdenes bajo fuego enemigo que, cuando se ejecutaban (en caso de llegar, claro), ya estaban obsoletas.
Gestionar a escala sin visibilidad centralizada es ser esos generales del pasado, visualizando el campo de batalla lleno de humo desde puestos de mando separados, sin comunicación entre ellos y con planos distintos para cada sector (cliente) de la guerra diaria.
Posible técnicamente hablando, pero una catástrofe anunciada en la práctica.
Un NOC funcional para un MSP necesita monitorización TI centralizada, un punto de control único que permita ver el estado de todos los clientes desde una sola consola, con:

• Capacidad de segmentar por cliente.
• Por criticidad del servicio.
• Por compromisos de SLA, porque al final del día, el dinero manda.

Idealmente, esto significa un dashboard global, pero que permita hacer zoom y bajar al detalle de un cliente específico sin cambiar de herramienta.
Con eso, obtendremos una visión consolidada de disponibilidad, eventos activos, inventario y tendencias de rendimiento.
Sin ese Palantir que permita observar cada rincón de nuestra Tierra Media IT particular, cada cambio de contexto entre clientes consume tiempo, carga cognitiva y aumenta el riesgo de que algo importante pase desapercibido.
Y ahora que ya sabemos qué hacer y en qué orden, ¿Cómo sabemos si lo estamos implementando bien?
Midiendo.

Qué métricas indican que un MSP está escalando bien

No debemos valorar la eficiencia operativa de un MSP con métricas como tickets cerrados u horas de técnico facturadas. Eso es seguir midiendo el pasado, cuando tenemos que evaluar si los cambios en nuestra forma de operar están produciendo mejoras o, simplemente, absorbemos más carga con el mismo caos.
Para averiguar si la optimización de nuestras operaciones sigue un buen rumbo podemos emplear métricas como:

• Incidencias por técnico y endpoint: Si crecen nuestros clientes, pero baja este ratio, los cambios en las operaciones están funcionando.
• Ratio de alertas útiles frente a alertas irrelevantes: El indicador más directo de la calidad de la monitorización. Si no lo estamos aumentando, se trabaja con demasiado ruido.
• MTTR (Mean Time To Resolution): Si la automatización está haciendo su trabajo, este tiempo debería caer de forma sostenida.
• Cumplimiento de SLA: La vara de medir que no debe moverse, aunque todo lo demás cambie.
• Tiempo dedicado a tareas repetitivas: Si no disminuye con el tiempo, la automatización no está avanzando.
• Porcentaje de automatización de respuestas: Cuántas incidencias se resuelven satisfactoriamente sin intervención humana directa. Todo aumento es bueno.
• Tiempo de onboarding de nuevos clientes: Indicador directo del nivel de estandarización alcanzado. Si tarda semanas, no tenemos la operación estandarizada, solo finge serlo.
• Clientes gestionados por técnico: El número más elocuente sobre la escala real del modelo operativo, si aumenta sin deterioro de la satisfacción ni de la cordura de los técnicos, vamos bien porque este se apoya en estándares, automatización y buenas prácticas.

Cómo ayuda Pandora FMS a operar cientos de clientes con el mismo equipo

Pandora FMS se diseñó entendiendo el problema operativo del MSP desde dentro porque lo sufrimos. Porque lo vivimos, porque venimos de esas trincheras en el barro, no de las alturas teóricas donde todo suena bien.
Por eso no creamos una herramienta de monitorización genérica adaptada a posteriori, sino algo que aliviara nuestro propio dolor y que compartimos porque pensamos que podía aliviar el de otros.
Esa diferencia de origen se traduce en funcionalidades que responden directamente a los retos de la escala con múltiples clientes.
Así, la monitorización MSP con Pandora FMS se construye sobre:

• Una arquitectura multicliente real.
• Segregación de datos por cliente.
• Permisos granulares.
• La capacidad de aplicar políticas globales o específicas según el perfil de cada entorno.
• Plantillas y políticas reutilizables, que permiten un onboarding estructurado y medible, no una operación artesanal dependiente de quién esté en el turno cuando el cliente llega.
• Capacidades de automatización.
• Adaptación total a cualquier infraestructura, sin importar lo heterogénea que sea, con máquinas in-house, virtualización, servicios en la nube… Sea cual sea la infraestructura, Pandora FMS la unifica en su monitorización sin importar lo diferentes que sean las piezas del puzzle.
• Visualización en un solo cuadro de mando, nuestra metaconsola, que permite controlar a vista de pájaro todo lo que ocurre desde un solo punto y entrar al detalle que sea necesario.

En el núcleo de todo ello está la capacidad de correlación de eventos de Pandora FMS y la de predicción basada en tendencias, que permiten detectar incidencias antes de que impacten en el cliente, convirtiendo el soporte reactivo en una operación realmente proactiva.
Evitar que ese soporte reactivo consuma el margen y el tiempo del equipo es uno de nuestros objetivos centrales que durante el diseño y el desarrollo continuo de la herramienta.
Y luego está el omnipresente tema de la seguridad, claro.
Para ella, Pandora SIEM complementa este escenario en los entornos donde dicha seguridad operativa forma parte del servicio, aportando también correlación de eventos de seguridad y visibilidad unificada en entornos híbridos y heterogéneos.
La visión consolidada (paneles por cliente, vista multicliente, reporting automático…) permite que un equipo de tamaño razonable no colapse ante el crecimiento, sino que lo gestione con calma y datos, no con estrés y (más) caféina.
Como hemos visto, un MSP escala cuando convierte su operación en un sistema repetible, automatizable y medible, no cuando alista legiones de ingenieros nuevos que no caben en los sótanos en los que los encerramos a pan y agua.
Pero eso precisa cambios en la forma de actuar, algo a lo que no debemos resistirnos, sino implementar siguiendo los pasos del mapa dibujado aquí.
Así, gestionar cientos de clientes con el mismo equipo técnico no es un truco, ni promesa de vendedor.
Es el resultado inevitable de construir una operación que funciona como un reloj suizo.
Quien entiende eso deja de buscar técnicos dispuestos a apretar los dientes y empieza a buscar sistemas capaces de hacer más. Ahí radica la diferencia entre un MSP que crece y uno que simplemente engorda.