\u00abEstos clientes no tuvieron que esperar a que se lanzara una nueva funci\u00f3n. Utilizaron las herramientas que NinjaOne ya ofrece \u2014scripts, API, campos personalizados y pol\u00edticas din\u00e1micas\u2014 y crearon exactamente lo que necesitaba su entorno. Ese es el poder de una plataforma dise\u00f1ada para ampliarse: cuando necesitas algo espec\u00edfico, tienes los componentes necesarios para hacerlo realidad ahora, no el pr\u00f3ximo trimestre\u00bb.<\/p>\n
Para la mayor\u00eda de las organizaciones, la aplicaci\u00f3n de parches no es un proceso sencillo. Tienen comit\u00e9s asesores de cambios, despliegues por fases, ventanas de mantenimiento definidas en la CMDB, periodos anuales de bloqueo de cambios y calendarios de cumplimiento normativo que hacen que Patch Tuesday resulte claramente insuficiente. Cuando sus herramientas no est\u00e1n a la altura, los equipos de TI acaban conectando hojas de c\u00e1lculo con procesos manuales y confiando en que nada se quede por el camino.<\/p>\n
NinjaOne ha trabajado con clientes empresariales que se negaron a conformarse con esa soluci\u00f3n de compromiso. En lugar de esperar a que se desarrollara una nueva funci\u00f3n, utilizaron el motor de scripts, la API, los campos personalizados y las pol\u00edticas din\u00e1micas de NinjaOne para crear exactamente los flujos de aplicaci\u00f3n de parches que necesitaban. Estas son dos de esas historias.<\/p>\n
Una gran empresa llevaba a\u00f1os utilizando una plataforma heredada de gesti\u00f3n de la configuraci\u00f3n. Funcionaba, pero el coste de la infraestructura era enorme: servidores dedicados, puntos de distribuci\u00f3n, infraestructura de bases de datos y dependencia de VPN para los dispositivos remotos.<\/p>\n
La empresa quer\u00eda migrar a NinjaOne, pero tem\u00eda que su proceso de aplicaci\u00f3n de parches supusiera un obst\u00e1culo insalvable para adoptarlo. Hab\u00edan creado un modelo de despliegue por fases en el que los parches se distribu\u00edan por la organizaci\u00f3n de forma escalonada. Empezaban con un peque\u00f1o grupo de prueba, ampliaban despu\u00e9s el despliegue a los primeros usuarios, luego a las oficinas corporativas y, por \u00faltimo, semanas m\u00e1s tarde, a las ubicaciones operativas. Cada fase ten\u00eda un retraso espec\u00edfico respecto a la fecha de publicaci\u00f3n de los parches de Microsoft, y algunas solo pod\u00edan instalarse durante ventanas de mantenimiento nocturnas para evitar interrupciones.<\/p>\n
Este tipo de l\u00f3gica de \u00abd\u00eda de lanzamiento + N d\u00edas\u00bb no existe de forma nativa en la mayor\u00eda de las herramientas de gesti\u00f3n de endpoints. Tampoco exist\u00eda en las tres plataformas que hab\u00edan evaluado antes de NinjaOne.<\/p>\n
Con el motor de scripts de NinjaOne, el cliente cre\u00f3 un script de control que se ejecuta autom\u00e1ticamente antes de cada ciclo de aplicaci\u00f3n de parches. El script calcula las fechas, determina la fecha de referencia del lanzamiento del mes, a\u00f1ade el retraso correspondiente a la fase asignada al dispositivo y decide si ese d\u00eda toca aplicar parches. Si es as\u00ed, contin\u00faa la aplicaci\u00f3n de parches. Si no, el script indica a NinjaOne que omita el ciclo de forma controlada y vuelva a intentarlo la pr\u00f3xima vez.<\/p>\n
El script simplific\u00f3 el trabajo diario del equipo encargado de la aplicaci\u00f3n de parches. Los administradores no tienen que tocar una sola l\u00ednea de c\u00f3digo. Solo tienen que elegir la fase de despliegue en un men\u00fa desplegable de NinjaOne y el script se encarga del resto. Si la organizaci\u00f3n decide modificar el retraso de un grupo concreto, basta con cambiar un valor en el men\u00fa desplegable. Eso es todo.<\/p>\n
En la actualidad, la empresa ha retirado por completo su infraestructura heredada de aplicaci\u00f3n de parches. Ya no necesita servidores dedicados. Ya no necesita VPN para los port\u00e1tiles remotos. Todo su parque de dispositivos aplica los parches directamente desde el proveedor a trav\u00e9s de Internet y mantiene la misma disciplina de despliegue por fases de siempre, pero sin la carga operativa.<\/p>\n
Una gran empresa gestiona un parque de servidores con varios sistemas operativos. Cada servidor de su entorno tiene definida una ventana de mantenimiento en la CMDB. Esta ventana de mantenimiento es un registro que especifica el tipo de entorno, el d\u00eda de la semana y la franja horaria en la que se permite aplicar parches. En todo su parque de servidores, esto se traduce en decenas de combinaciones distintas de ventanas de mantenimiento.<\/p>\n
Para complicarlo a\u00fan m\u00e1s, su calendario de aplicaci\u00f3n de parches no se basa en patrones recurrentes. Aplican parches en fechas concretas de cada mes, planificadas con un a\u00f1o de antelaci\u00f3n. Tambi\u00e9n establecen un periodo anual de bloqueo de cambios durante la \u00e9poca de mayor actividad, en el que no se aplica ning\u00fan parche a los sistemas de producci\u00f3n. Adem\u00e1s, cada servidor tiene sus propias condiciones: algunos no pueden reiniciarse durante la aplicaci\u00f3n de parches, otros solo deben reiniciarse sin instalar parches y otros requieren una intervenci\u00f3n completamente manual.<\/p>\n
Antes de NinjaOne, el equipo de TI gestionaba todo esto manualmente. Las hojas de c\u00e1lculo registraban qu\u00e9 servidores se hab\u00edan parcheado y cu\u00e1ndo. El conocimiento no documentado del equipo supl\u00eda las carencias. Algunos dispositivos quedaban sin atender. Algunos parches no llegaban a aplicarse.<\/p>\n
NinjaOne elimin\u00f3 toda esta complejidad conectando directamente la CMDB con el motor de pol\u00edticas de NinjaOne mediante tres capas de automatizaci\u00f3n:<\/p>\n
Con estas automatizaciones, la organizaci\u00f3n puede aplicar parches autom\u00e1ticamente a todo su parque de servidores en la fecha, la hora y el orden correctos. La CMDB sigue siendo la fuente de referencia principal para las ventanas de mantenimiento, y NinjaOne ejecuta la aplicaci\u00f3n de parches a partir de esa informaci\u00f3n, sin intervenci\u00f3n manual. Lo que antes requer\u00eda hojas de c\u00e1lculo y llamadas de coordinaci\u00f3n ahora funciona de forma autom\u00e1tica.<\/p>\n
Ninguno de estos clientes pidi\u00f3 a NinjaOne que desarrollara una nueva funci\u00f3n. No presentaron una solicitud y se quedaron esperando a que llegara una nueva versi\u00f3n. Analizaron las herramientas que NinjaOne ya ofrece \u2014scripts, API, campos personalizados y pol\u00edticas din\u00e1micas\u2014 y crearon los scripts que necesitaban para sus entornos.<\/p>\n
Esa es la diferencia entre una herramienta y una plataforma. Una herramienta hace aquello para lo que fue dise\u00f1ada. Una plataforma te permite adaptarla para que haga lo que necesitas.<\/p>\n
Para los equipos de TI empresariales que gestionan calendarios complejos de aplicaci\u00f3n de parches, integraciones con CMDB, despliegues por fases y restricciones operativas que no encajan en un simple men\u00fa desplegable, NinjaOne ofrece los componentes necesarios para hacerlo realidad. No en el futuro. Hoy.<\/p>\n