Gestión de parches para MSP: una sola política para todos sus clientes

Usted dirige un MSP. Con tres clientes, los parches son una costumbre de martes por la tarde: sabe qué servidor aloja el programa de contabilidad, qué portátil es del gerente y a quién llamar cuando una actualización bloquea la impresora. Al llegar al décimo cliente, esa costumbre deja de escalar. Cada cliente tiene sus excepciones, cada técnico aprueba las actualizaciones a su manera y, cuando un cliente pregunta «¿estamos al día?», la respuesta le lleva una tarde.

Este artículo está pensado para propietarios y responsables técnicos de MSP que quieren una sola política de parches para todos sus clientes: qué aprobar automáticamente, cómo desplegar por anillos, cómo tratar las aplicaciones de terceros y los servidores, y cómo mostrar a un cliente en qué punto está. Al final verá cómo lo hacemos en Xcellerate RMM.

En resumen

• Escriba la política una sola vez, por tipo de dispositivo: equipos de trabajo, servidores y servidores críticos tienen cada uno su plazo de aprobación, su ventana de instalación y su regla de reinicio.
• Despliegue por anillos: primero sus equipos de prueba, luego sus máquinas internas, después los clientes piloto y, por último, todos.
• Aplique parches a las aplicaciones de terceros con el mismo flujo que al sistema operativo, y nunca reinicie automáticamente un servidor fuera de una ventana de mantenimiento.
• Entregue a cada cliente un informe mensual: estado de parches por dispositivo, qué se instaló, qué falló y qué pospuso a propósito.

Por qué los parches se descontrolan en el décimo cliente

Los parches rara vez fallan porque un técnico no sepa cómo aplicarlos. Fallan porque las reglas están en la cabeza de las personas. Un técnico lo aprueba todo el miércoles, otro espera una semana y un tercero se salta el servidor del cliente que se quejó de un reinicio el año pasado. Nada está por escrito, así que nada es coherente y nadie puede demostrar qué ocurrió de verdad.

Una política de parches lo resuelve. Es un documento breve, e idealmente una configuración de su RMM, que responde a cuatro preguntas para cada dispositivo: qué actualizaciones se aprueban automáticamente, tras cuántos días, en qué franja horaria y si el dispositivo puede reiniciarse por sí solo. Con esas respuestas por escrito, los parches pasan a ser un proceso que puede comprobar y no una costumbre en la que confiar.

La política en una tabla

Empiece por los tipos de dispositivo, no por los clientes. La mayoría de los MSP necesitan tres. Las cifras siguientes son un ejemplo que debe adaptar, no una norma:

¿Por qué esperar? Unos días dan tiempo a la comunidad para notificar una actualización defectuosa antes de que llegue a sus clientes. ¿Por qué ventanas distintas? Los equipos se actualizan mejor cuando la gente hace una pausa; los servidores, cuando nadie trabaja.

Después añada las excepciones por cliente, no por dispositivo: un cliente con turnos de noche recibe otra ventana para sus equipos; un cliente con una aplicación de negocio delicada pasa su servidor a la clase crítica. Anote cada excepción con su motivo.

Anillos: sus propios dispositivos primero

Un anillo de actualización es un grupo de dispositivos que recibe las actualizaciones en la misma fase. Una configuración sencilla para un MSP tiene cuatro:

1. Anillo de prueba: algunos dispositivos propios que reciben cada actualización en primer lugar.
2. Anillo interno: el resto de su propia oficina.
3. Anillo piloto: uno o dos clientes tolerantes, bien documentados y que saben que son piloto.
4. Anillo general: todos los demás.

Cada anillo espera al anterior. Si una actualización rompe algo en el anillo de prueba o en el interno, la bloquea antes de que llegue a un cliente. Los anillos también le dan una respuesta clara cuando un cliente pregunta por qué no recibió una actualización el primer día: es deliberado.

Las aplicaciones de terceros, la verdadera brecha

Las actualizaciones del sistema operativo son la parte fácil: Windows, macOS y Linux tienen cada uno su propio mecanismo, y la mayoría de los RMM los gestionan. La brecha está en todo lo demás: navegadores, lectores de PDF, Java, Zoom y las demás aplicaciones que instalan los usuarios y que nadie actualiza.

Trátelas igual que el sistema operativo: las mismas reglas de aprobación, los mismos anillos, las mismas ventanas. Mantenga por cliente una lista de las aplicaciones de terceros que da soporte y decida qué pasa con las demás (eliminarlas o dejarlas en manos del cliente con una nota por escrito).

Servidores: nunca reiniciar sin ventana

La forma más rápida de perder la confianza de un cliente es un reinicio imprevisto, en plena jornada, del servidor donde funciona su aplicación de negocio. Tres reglas:

• Ningún reinicio automático de servidores fuera de una ventana de mantenimiento acordada.
• Acuerde la ventana por escrito con el cliente, en la zona horaria del cliente.
• En los servidores críticos, tenga a alguien disponible durante la ventana para comprobar los servicios después.

La prueba: el informe que ve su cliente

Una política solo genera confianza cuando el cliente ve que funciona. Una vez al mes, envíe a cada cliente un breve informe de parches:

• Estado de parches por dispositivo: el porcentaje de actualizaciones aplicables que están instaladas.
• Qué se instaló el último mes y qué falló.
• Qué pospuso o bloqueó a propósito, y por qué.
• Dispositivos que requieren atención: desconectados desde hace semanas, pendientes de reinicio o sin soporte.

Revíselo en su seguimiento mensual o trimestral. Así los parches dejan de ser un coste invisible y se convierten en un servicio que el cliente ve.

Cómo lo hacemos en Xcellerate RMM

Xcellerate RMM es nuestro RMM: source-available bajo la licencia FSL, en sus propios servidores o en nuestra nube europea. La gestión de parches forma parte del núcleo source-available. Así encaja en él la política anterior:

• Sistemas operativos y aplicaciones de terceros: Windows Update, apt/yum en Linux y softwareupdate en macOS, además de un catálogo de aplicaciones de terceros populares que siguen el mismo flujo de aprobación y programación.
• Políticas de parches por grupo: aprobación automática, plazos de aplazamiento, ventanas de mantenimiento y comportamiento de reinicio, configurados una vez y asignados a un grupo. Las estrategias de parches con nombre, con sus propias programaciones y reglas, se asignan a cualquier agente o grupo.
• Aprobar, aplazar o bloquear por lotes: revise los parches pendientes de toda la flota y cambie su estado en una sola operación.
• Anillos de actualización: elija qué anillo sigue cada tenant, para que las primeras versiones no lleguen a los clientes en producción.
• Detalle e historial por dispositivo: qué está instalado, pendiente o con error en cada dispositivo, y un registro de cada instalación con su resultado y su hora.
• Puntuación de cumplimiento e informes: el porcentaje de parches aplicables instalados por dispositivo o grupo, un compliance report exportable para compartir con el cliente y una alerta cuando la puntuación baja de un umbral que usted define.

La página de gestión de parches ofrece la visión general, y la documentación de gestión de parches explica paso a paso cómo crear una política. ¿Quiere ejecutarlo en sus propios servidores? La guía de instalación describe la instalación autoalojada.

¿Usa también un PSA junto a su RMM? Xcellerate RMM y Xcellerate OPS son dos productos independientes y todavía no existe una conexión lista para usar entre ambos. RMM + PSA todo en uno o best-of-breed le ayuda a decidir qué necesita su stack.

Pruebe la política en su propia flota: gratis para siempre en sus propios servidores, o una prueba Cloud de 14 días. Empezar gratis