Cómo evitar configuraciones diferentes entre servidores Linux similares

Introducción

Dos servidores Linux que empiezan con la misma configuración pueden terminar siendo muy diferentes después de unos meses. Una actualización aplicada solo en uno, una regla de firewall añadida manualmente, un paquete instalado para resolver una incidencia, una tarea cron creada deprisa o una modificación directa de un archivo pueden introducir pequeñas desviaciones. Si esas diferencias no se registran ni se corrigen, cada máquina evoluciona por su cuenta.

Este fenómeno se conoce habitualmente como configuration drift o deriva de configuración. No significa que todas las diferencias sean malas: dos servidores pueden necesitar parámetros distintos por capacidad, función o entorno. El problema aparece cuando existen diferencias no intencionadas, desconocidas o imposibles de justificar.

La deriva aumenta el riesgo operativo. Una actualización puede funcionar en un servidor y fallar en otro aparentemente equivalente. Un script puede comportarse de manera distinta por una versión de paquete. Una incidencia puede reproducirse solo en una máquina porque alguien modificó un límite meses atrás. Cuantas más diferencias invisibles existen, más difícil resulta diagnosticar, automatizar, sustituir o reconstruir servidores.

Este artículo explica cómo evitar configuraciones diferentes entre servidores Linux similares. El objetivo no es volver a definir una política general de estandarización, sino aprender a detectar desviaciones, distinguir diferencias válidas de cambios accidentales y establecer mecanismos para que servidores equivalentes permanezcan coherentes con el paso del tiempo.

Índice

• Qué es el configuration drift
• Por qué aparecen diferencias entre servidores
• Diferencias válidas y diferencias accidentales
• Necesitas un estado deseado antes de comparar
• Definir una fuente de verdad
• Comparar inventario básico
• Comparar sistema operativo y kernel
• Comparar paquetes y versiones
• Comparar repositorios
• Comparar archivos de configuración
• Comparar permisos y propietarios
• Comparar usuarios, grupos y sudo
• Comparar SSH
• Comparar firewall y puertos
• Comparar servicios systemd
• Comparar cron y timers
• Comparar directorios y rutas propias
• Comparar variables y configuración de aplicaciones
• Comparar logging y rotación
• Comparar copias y monitorización
• Reducir cambios manuales
• Versionar configuraciones
• Usar plantillas en lugar de copiar y editar
• Aplicar el estado deseado con Ansible
• Por qué importa la idempotencia
• Programar auditorías de configuración
• Crear checks automáticos
• Alertar cuando aparece una desviación
• Gestionar excepciones
• Cómo corregir una desviación detectada
• No corregir diferencias a ciegas
• Qué hacer con servidores antiguos
• Ejemplo práctico de comparación
• Procedimiento periódico recomendado
• Errores frecuentes
• Checklist contra configuration drift
• Preguntas frecuentes
• Conclusión

Qué es el configuration drift

El configuration drift es la separación progresiva entre el estado que debería tener un sistema y el estado que realmente tiene. También puede describir la divergencia que aparece entre varias máquinas que originalmente deberían mantenerse equivalentes.

Imaginemos dos servidores web creados el mismo día:

web-prod-01
web-prod-02

Ambos empiezan con:

• la misma versión de Linux;
• los mismos repositorios;
• nginx en la misma versión;
• la misma configuración SSH;
• el mismo firewall;
• los mismos usuarios administrativos;
• la misma estructura de aplicaciones.

Seis meses después, web-prod-01 tiene un paquete adicional, una regla de firewall creada durante una incidencia y un parámetro modificado en nginx. web-prod-02 no contiene esos cambios. Si nadie conoce la diferencia, las máquinas ya no son realmente equivalentes.

La deriva de configuración no es simplemente que dos servidores sean distintos; es que sean distintos sin que esa diferencia forme parte de un diseño conocido.

Por qué aparecen diferencias entre servidores

La mayoría de desviaciones no aparecen de golpe. Se acumulan mediante pequeñas intervenciones.

Cambios manuales

Un administrador edita directamente un archivo en una máquina para resolver una incidencia y no replica ni registra el cambio.

Actualizaciones parciales

Un servidor se actualiza y otro queda pendiente.

Paquetes instalados temporalmente

Se instala una herramienta de diagnóstico que termina quedándose de forma permanente.

Excepciones no documentadas

Una diferencia tenía sentido originalmente, pero el motivo se pierde.

Automatizaciones distintas

Una máquina tiene una versión nueva de un script o una tarea cron adicional.

Configuración local

Una plantilla común se copia una vez y después cada servidor se modifica independientemente.

Reparaciones de emergencia

Durante una caída se aplican cambios rápidos que nunca se incorporan al estándar.

Administración por varias personas

Cada técnico utiliza convenciones diferentes cuando no existe una fuente de verdad compartida.

Diferencias válidas y diferencias accidentales

El objetivo no es conseguir diferencias cero.

La pregunta correcta no es “¿son idénticos?”, sino “¿puedo explicar cada diferencia?”.

Necesitas un estado deseado antes de comparar

No puede hablarse de desviación si no existe una referencia.

El estado deseado puede definirse mediante:

• una baseline;
• plantillas;
• repositorio Git;
• roles de Ansible;
• checklists;
• documentación técnica;
• listas de paquetes;
• políticas de usuarios y acceso.

El artículo cómo estandarizar la configuración de varios servidores Linux desarrolla precisamente esa fase: definir qué debería ser común. Una vez existe el estándar, este artículo se ocupa de comprobar que los servidores continúan cumpliéndolo.

Definir una fuente de verdad

Uno de los mayores problemas aparece cuando nadie sabe qué copia de una configuración es la correcta.

Mal escenario

portatil/config-nginx.conf
servidor-1/nginx.conf
servidor-2/nginx.conf
NAS/config-nginx-final.conf
correo/nginx-corregido.conf

Puede haber cinco versiones y ninguna identificada como oficial.

Fuente de verdad

Una estrategia mejor mantiene la configuración declarada en un repositorio o sistema central. Los servidores reciben esa configuración o se comparan contra ella.

La máquina en producción deja de ser el único lugar donde vive el conocimiento.

Estado real frente a estado deseado

La fuente de verdad describe cómo debería estar configurado el servidor. La auditoría comprueba cómo está realmente. La diferencia entre ambos estados es lo que debe analizarse.

Comparar inventario básico

Una comparación sencilla puede empezar por elementos básicos.

hostnamectl
uname -r
timedatectl
df -h
lsblk
ip addr
ip route

Estos datos ayudan a detectar:

• versiones distintas;
• discos adicionales;
• montajes ausentes;
• interfaces diferentes;
• rutas no esperadas;
• configuración temporal distinta.

La comparación debe centrarse en elementos que deberían ser equivalentes y excluir diferencias conocidas como hostname o IP.

Comparar sistema operativo y kernel

Servidores equivalentes que ejecutan versiones distintas pueden comportarse de forma diferente incluso con configuraciones aparentemente iguales.

Comprobar

• distribución;
• release;
• kernel;
• arquitectura;
• estado de actualizaciones;
• reinicios pendientes cuando el sistema los indique.

No igualar versiones sin evaluar

Si una máquina está retrasada, primero hay que entender por qué. Puede existir una actualización bloqueada deliberadamente por compatibilidad.

Registrar excepciones

Si un nodo debe permanecer temporalmente en otra versión, esa diferencia deja de ser drift si está documentada y tiene fecha de revisión.

Comparar paquetes y versiones

Las listas de paquetes son una de las fuentes más claras de deriva.

Qué buscar

• paquetes presentes solo en un servidor;
• versiones diferentes;
• paquetes retenidos;
• dependencias huérfanas;
• software instalado manualmente;
• paquetes eliminados en un nodo pero no en otro.

En sistemas basados en Debian puede generarse una lista para comparar, por ejemplo:

dpkg-query -W -f='${Package}\t${Version}\n' | sort

La salida de dos servidores puede compararse mediante diff, siempre interpretando correctamente las diferencias específicas del hardware o rol.

Comparar repositorios

Dos servidores pueden instalar versiones distintas aunque ambos ejecuten el mismo comando de actualización si sus repositorios no coinciden.

Revisar

• repositorios oficiales;
• repositorios adicionales;
• claves de firma;
• prioridades;
• componentes habilitados;
• repositorios antiguos que deberían haberse retirado.

Un repositorio añadido para instalar una herramienta puntual puede seguir alterando futuras resoluciones de dependencias mucho después.

Comparar archivos de configuración

Los archivos de texto permiten comparaciones muy precisas.

diff

diff -u servidor1.conf servidor2.conf

Pero comparar archivos completos puede producir ruido si contienen valores que deben ser diferentes.

Normalizar antes de comparar

Puede ser útil excluir o parametrizar:

• hostname;
• IP;
• credenciales;
• IDs únicos;
• rutas específicas justificadas.

Comparar la configuración efectiva

Algunos servicios permiten mostrar la configuración final después de procesar includes y valores por defecto. Esa vista puede ser más útil que comparar únicamente el archivo principal.

Comparar permisos y propietarios

Dos árboles de archivos con contenido idéntico pueden comportarse de forma diferente por permisos.

Revisar

• propietario;
• grupo;
• modo;
• ACL;
• atributos extendidos cuando sean relevantes.

Una diferencia de permisos puede introducirse mediante una extracción, una copia manual o un chown recursivo.

La comparación debe limitarse a rutas donde exista realmente una política común.

Comparar usuarios, grupos y sudo

Las cuentas son una fuente de drift especialmente importante desde el punto de vista de seguridad.

Comprobar

• usuarios administrativos;
• cuentas de servicio;
• grupos;
• UID y GID cuando importen;
• shell;
• estado de bloqueo;
• reglas de sudo;
• claves SSH autorizadas.

Cuentas residuales

Una cuenta eliminada de tres servidores pero olvidada en el cuarto es una desviación con impacto potencial de seguridad.

No copiar /etc/passwd a ciegas

El objetivo es comparar políticas y cuentas administradas, no forzar que todas las cuentas internas del sistema coincidan exactamente.

Comparar SSH

Una pequeña diferencia en SSH puede crear niveles de seguridad distintos.

Comparar

• acceso root;
• autenticación por contraseña;
• usuarios permitidos;
• grupos permitidos;
• puerto cuando exista un estándar;
• algoritmos;
• timeouts;
• includes y drop-ins.

Cuando sea posible, conviene comparar la configuración efectiva y no solo una copia de sshd_config.

La definición de una política de acceso puede ampliarse en cómo proteger el acceso SSH en servidores Linux.

Comparar firewall y puertos

Los servidores equivalentes deberían exponer servicios equivalentes salvo excepción documentada.

Comparar reglas

Puede revisarse la política configurada en nftables, iptables, UFW, firewalld o la herramienta utilizada.

Comparar puertos reales

ss -lntup

Una regla de firewall y un puerto abierto responden a preguntas distintas. Conviene revisar ambos.

Buscar servicios inesperados

Un servidor puede haber dejado ejecutándose una utilidad de diagnóstico, un panel o un servicio temporal.

Comparar servicios systemd

La lista de servicios habilitados y activos puede revelar diferencias importantes.

systemctl list-unit-files --type=service
systemctl --failed

Comprobar

• servicios habilitados;
• servicios deshabilitados;
• unidades propias;
• drop-ins;
• variables de entorno;
• dependencias;
• políticas de reinicio.

Dos servidores pueden ejecutar el mismo binario con unidades systemd diferentes y comportarse de forma distinta.

Comparar cron y timers

Las tareas programadas suelen quedar fuera de las comparaciones básicas y pueden producir diferencias silenciosas.

Revisar

• crontab del sistema;
• crontabs de usuarios;
• /etc/cron.d;
• directorios periódicos;
• timers systemd;
• scripts llamados;
• usuarios de ejecución.

Un mismo script no garantiza el mismo resultado

Si los horarios, parámetros o archivos de configuración difieren, la automatización también lo hará.

Comparar directorios y rutas propias

La estructura propia debería seguir las mismas convenciones en servidores equivalentes.

Problemas habituales

• una aplicación en /opt en un servidor y en /srv en otro;
• logs propios en rutas diferentes;
• configuración mezclada con código;
• datos persistentes dentro del directorio de despliegue;
• scripts duplicados en /root.

Una estructura común facilita automatización y recuperación. Puede ampliarse en cómo diseñar una estructura de directorios propia para aplicaciones empresariales.

Comparar variables y configuración de aplicaciones

Las aplicaciones suelen necesitar diferencias legítimas, pero deben estar delimitadas.

Variables esperadas

• hostname;
• IP;
• ID de nodo;
• credenciales;
• recursos asignados;
• dominios;
• rutas específicas.

Valores que deberían ser comunes

Versiones, estructura, políticas de logging, timeouts, configuración de seguridad y otras decisiones comunes deberían proceder de una plantilla.

Evitar archivos casi idénticos

Cuando cada servidor mantiene una copia independiente completa, las diferencias accidentales resultan difíciles de detectar.

Comparar logging y rotación

El drift también afecta a la capacidad de diagnosticar.

Comprobar

• ruta de logs;
• nivel;
• formato;
• rotación;
• retención;
• permisos;
• envío a un sistema central cuando corresponda.

Una máquina que retiene siete días y otra treinta puede dificultar la investigación de una incidencia histórica.

Comparar copias y monitorización

Dos servidores equivalentes no deberían diferir silenciosamente en sus mecanismos de protección.

Backups

• qué se copia;
• frecuencia;
• destino;
• retención;
• cifrado;
• última ejecución correcta.

Monitorización

• agente instalado;
• checks;
• umbrales;
• alertas;
• responsables.

Una máquina no monitorizada puede desviarse durante mucho más tiempo antes de que alguien lo descubra.

Reducir cambios manuales

La forma más eficaz de reducir drift es limitar las modificaciones irrepetibles realizadas directamente sobre cada servidor.

Mal patrón

ssh web-prod-01
vim /etc/nginx/conf.d/app.conf

ssh web-prod-02
vim /etc/nginx/conf.d/app.conf

Aunque se intente repetir el mismo cambio, es fácil introducir una diferencia.

Mejor patrón

Modificar una fuente común, revisarla y desplegar el mismo cambio mediante un procedimiento reproducible.

Las emergencias existen

Si se necesita modificar producción directamente, después debe incorporarse inmediatamente esa corrección a la fuente oficial. De lo contrario, el siguiente despliegue puede eliminarla.

Versionar configuraciones

Git permite comparar el estado deseado a lo largo del tiempo.

Puede versionarse

• plantillas;
• scripts;
• roles;
• inventarios;
• documentación;
• fragmentos de configuración no sensibles.

Ventajas frente a copias manuales

Un historial real evita archivos como:

nginx.conf.old
nginx.conf.old2
nginx.conf.final
nginx.conf.bueno

Además, permite saber cuándo se introdujo una diferencia y por qué.

Usar plantillas en lugar de copiar y editar

Una plantilla reduce la cantidad de contenido que puede divergir.

Ejemplo conceptual

worker_processes {{ nginx_workers }};
server_name {{ server_name }};
proxy_pass http://{{ backend_host }}:{{ backend_port }};

La estructura permanece común y solo cambian variables explícitas.

Ventaja

Una diferencia que no está representada por una variable o excepción resulta más fácil de detectar.

Evitar copiar desde producción

Tomar el archivo de un servidor como plantilla para otro puede propagar precisamente las desviaciones que se intentan eliminar.

Aplicar el estado deseado con Ansible

Cuando existen varias máquinas, una herramienta de gestión de configuración puede convertir la comparación y corrección en un proceso repetible.

Ejemplo conceptual

- name: Instalar nginx
  package:
    name: nginx
    state: present

- name: Desplegar configuración
  template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf

- name: Mantener nginx activo
  service:
    name: nginx
    state: started
    enabled: yes

En lugar de preguntar cómo está configurado cada servidor, se describe cómo debería estar.

Modo check

Las herramientas de configuración pueden ofrecer mecanismos de simulación o comprobación para detectar qué modificarían antes de aplicar.

Aplicar con prudencia

Una automatización incorrecta puede propagar el mismo error a todos los servidores. Deben existir pruebas, etapas y capacidad de reversión.

Por qué importa la idempotencia

Una operación idempotente puede ejecutarse repetidamente y mantener el mismo estado deseado.

Ejemplo problemático

Un script que añade una línea cada vez que se ejecuta puede generar duplicados.

Ejemplo deseado

La automatización comprueba si la línea existe y solo actúa cuando es necesario.

Relación con drift

Las operaciones idempotentes facilitan ejecutar periódicamente una política para corregir desviaciones sin introducir cambios adicionales en servidores que ya cumplen.

Programar auditorías de configuración

No conviene esperar a una incidencia para comparar máquinas.

Auditoría periódica

Puede revisarse mensualmente, trimestralmente o con otra frecuencia adecuada según el número de servidores y su criticidad.

Después de cambios importantes

Una actualización mayor, migración o intervención de emergencia es un buen momento para comprobar que todos los nodos siguen dentro del estándar.

Antes de ampliar capacidad

Antes de clonar o añadir un nuevo nodo conviene asegurarse de que la máquina utilizada como referencia no contiene drift acumulado.

Crear checks automáticos

No todo requiere una plataforma compleja. Un conjunto pequeño de comprobaciones puede detectar desviaciones relevantes.

Ejemplos

• hash de archivos controlados;
• versión de paquetes;
• lista de servicios;
• usuarios administrativos;
• puertos abiertos;
• estado de firewall;
• existencia de cron;
• último backup;
• agente de monitorización.

Salida estructurada

En lugar de producir cientos de líneas, el check puede devolver:

PASS ssh-policy
PASS backup-agent
FAIL nginx-version
WARN extra-user: soporte-temp
PASS firewall-baseline

Esto facilita revisar únicamente lo que requiere atención.

Alertar cuando aparece una desviación

Una comprobación es más útil si alguien sabe cuándo deja de cumplirse.

Evitar exceso de alertas

Alertar por cada diferencia conocida genera ruido. Las excepciones aprobadas deben quedar excluidas o clasificadas.

Priorizar

• crítica: SSH inseguro, backup ausente, firewall abierto;
• alta: paquete crítico desactualizado;
• media: configuración no estandarizada;
• baja: diferencia sin impacto inmediato.

Alertar por aparición

Una nueva desviación suele ser más importante que una excepción conocida desde hace meses.

Gestionar excepciones

Una excepción documentada no es drift.

Debe indicar

• servidor;
• parámetro;
• valor estándar;
• valor diferente;
• motivo;
• responsable;
• riesgo;
• fecha de revisión.

Caducidad

Las excepciones temporales deberían tener una fecha. De lo contrario, una solución provisional puede convertirse silenciosamente en una configuración permanente.

Revisar patrones

Si muchos servidores necesitan la misma excepción, quizá no sea una excepción: puede indicar que el estándar necesita cambiar.

Cómo corregir una desviación detectada

No toda diferencia debe corregirse inmediatamente.

1. Identificar la diferencia.
2. Determinar cuándo apareció.
3. Buscar el motivo.
4. Comprobar si es una excepción legítima.
5. Evaluar impacto de corregirla.
6. Preparar rollback.
7. Aplicar el estado deseado.
8. Validar técnicamente.
9. Validar funcionalmente.
10. Registrar el cambio.
11. Corregir la causa que permitió la deriva.

Este último punto es importante. Si solo se corrige el síntoma, la misma diferencia puede aparecer de nuevo.

No corregir diferencias a ciegas

Encontrar una diferencia no significa que el servidor equivocado sea necesariamente el distinto.

Ejemplo

Si tres servidores tienen un parámetro antiguo y uno tiene un valor nuevo, podría parecer que el cuarto se ha desviado. Pero quizá ese cuarto recibió una corrección importante que nunca se propagó a los otros tres.

Buscar historia

Antes de revertir hay que consultar:

• registro de cambios;
• commits;
• tickets;
• incidencias;
• documentación;
• actualizaciones.

El registro de modificaciones puede estructurarse siguiendo cómo registrar cambios realizados en un servidor Linux.

Qué hacer con servidores antiguos

Los sistemas con varios años suelen acumular mucha más deriva que los recién desplegados.

No intentar corregir todo en una sola ventana

Puede haber dependencias ocultas. Conviene clasificar diferencias por riesgo.

Prioridad alta

• accesos;
• firewall;
• backups;
• versiones sin soporte;
• servicios desconocidos;
• repositorios obsoletos.

Prioridad media

• rutas diferentes;
• nomenclatura;
• logging;
• scripts duplicados;
• paquetes no críticos.

Convergencia gradual

La meta es reducir diferencias desconocidas sin introducir una gran interrupción solo para conseguir uniformidad estética.

Ejemplo práctico de comparación

Supongamos dos servidores web que deberían tener el mismo rol:

web-prod-01
web-prod-02

Resultado de auditoría

Tratamiento

La diferencia de workers se conserva porque responde al hardware. El horario de limpieza se conserva porque evita ejecutar las dos tareas simultáneamente. En cambio, la autenticación por contraseña se corrige y la cuenta temporal se investiga antes de eliminarla.

Este ejemplo muestra por qué una herramienta no debería “igualar” todos los valores automáticamente sin conocer el significado de cada diferencia.

Procedimiento periódico recomendado

1. Seleccionar grupos de servidores equivalentes.
2. Cargar la baseline y roles aplicables.
3. Obtener inventario actual.
4. Comparar sistema y paquetes.
5. Comparar repositorios.
6. Comparar configuraciones controladas.
7. Comparar usuarios y privilegios.
8. Comparar SSH y firewall.
9. Comparar servicios, cron y timers.
10. Comprobar backups y monitorización.
11. Aplicar lista de excepciones conocidas.
12. Clasificar nuevas diferencias.
13. Investigar causa.
14. Preparar correcciones.
15. Aplicar cambios por etapas.
16. Validar.
17. Actualizar la fuente de verdad cuando proceda.
18. Registrar excepciones y cambios.

Con pocos servidores este proceso puede ejecutarse mediante una checklist y scripts. Con un entorno mayor, conviene automatizar buena parte de la obtención, comparación y aplicación del estado.

Errores frecuentes

Comparar servidores sin definir qué deberían compartir

Produce una lista enorme de diferencias sin significado.

Intentar que sean idénticos

Hostname, IP, capacidad y determinados parámetros pueden necesitar diferencias legítimas.

Elegir un servidor como verdad porque “funciona”

Puede contener años de cambios accidentales.

Copiar /etc completo

Puede propagar secretos, certificados, IDs, usuarios o valores específicos.

Corregir automáticamente todas las diferencias

Una excepción legítima puede ser destruida.

No versionar configuraciones

Impide saber cuándo apareció una diferencia.

Permitir cambios directos sin registro

La fuente oficial deja de representar producción.

No revisar cron y timers

Las diferencias de automatización pueden permanecer ocultas durante meses.

Comparar paquetes pero no repositorios

Las máquinas pueden volver a divergir en la siguiente actualización.

No comprobar permisos

Archivos idénticos pueden comportarse de manera distinta.

No gestionar excepciones

Cada auditoría vuelve a marcar las mismas diferencias legítimas.

Automatizar sin pruebas

Un error de la fuente de verdad puede propagarse a todo el entorno.

No corregir la causa del drift

La desviación reaparece después de haberla eliminado.

Checklist contra configuration drift

Preguntas frecuentes

Conclusión

Evitar configuraciones diferentes entre servidores Linux similares exige controlar la evolución del sistema después de su instalación inicial.

La deriva aparece mediante cambios manuales, actualizaciones parciales, paquetes temporales, excepciones olvidadas, cron, servicios, reglas de firewall y configuraciones que se modifican directamente en producción. Cada pequeña diferencia puede parecer irrelevante, pero su acumulación termina haciendo que máquinas aparentemente equivalentes se comporten de manera distinta.

El primer requisito para detectar drift es disponer de un estado deseado. Una baseline, plantillas, Git, roles y documentación permiten saber qué debería ser común y qué valores deben variar por servidor.

Después hay que comparar sistemáticamente el estado real: sistema operativo, paquetes, repositorios, configuración, permisos, usuarios, SSH, firewall, servicios, automatizaciones, directorios, logs, backups y monitorización.

Las diferencias no deben corregirse automáticamente sin comprenderlas. Una excepción legítima puede ser necesaria, y el servidor aparentemente distinto puede contener una corrección que todavía no se ha propagado a los demás. Por eso el registro de cambios y el historial de Git son fundamentales.

La mejor prevención consiste en reducir cambios manuales y utilizar una fuente de verdad. Las plantillas disminuyen variaciones accidentales y herramientas como Ansible permiten aplicar estados deseados de forma repetible cuando el entorno ya justifica ese nivel de automatización.

Finalmente, la configuración debe auditarse periódicamente. La coherencia de un conjunto de servidores no es un resultado que se consigue una vez, sino una propiedad que debe mantenerse. Cuanto antes se detecta una desviación, más sencillo resulta explicar su origen y decidir si debe conservarse o corregirse.

ESTUDIO METADATOS desarrolla programas de formación online para profundizar en tecnologías utilizadas en entornos profesionales reales. Puedes consultar sus programas de formación tecnológica para ampliar conocimientos sobre Linux, administración de sistemas, automatización, seguridad, configuración y mantenimiento de infraestructuras.