Explícame cómo gestionarías una caída crítica de un servidor en pleno horario laboral.

Mi primer paso es siempre confirmar el alcance y el impacto antes de tocar nada: si es un solo servicio o algo más amplio, y a cuántos usuarios afecta. Publico una actualización breve en nuestro canal de incidentes en los primeros cinco minutos, aunque solo diga que estamos investigando, porque el silencio es peor que un honesto 'todavía no lo sabemos'. Una vez que tengo una hipótesis de trabajo, busco la mitigación más rápida y segura, a menudo un rollback o un reinicio del servicio, en lugar de la solución definitiva más rápida. En mi anterior empresa, un pool de conexiones a base de datos se agotó durante un pico de una campaña de marketing; escalé el pool y reinicié el servicio afectado para restaurar el acceso en once minutos, y dediqué el resto del día a identificar el límite real que había que revisar. Después del incidente, escribo un informe: cronología, impacto, causa raíz y el cambio concreto que evita que se repita, y lo comparto con todo el equipo, no solo con mi responsable.

¿Cómo abordas la gestión de parches y las actualizaciones de seguridad?

Trato los parches como un proceso planificado y graduado por riesgo, no como algo reactivo. Los parches de seguridad críticos, sobre todo los ligados a una CVE activa, se prueban en un entorno de preproducción y se despliegan en 48 a 72 horas mediante una ventana de cambio acelerada. Los parches rutinarios siguen un ritmo mensual: los pruebo primero en un grupo piloto de máquinas no críticas, observo durante unos días y luego los despliego al resto del parque por lotes. Cada ventana de parches tiene un plan de rollback documentado antes de empezar, nunca improvisado en mitad de un incidente. También mantengo un inventario preciso de qué corre y dónde, porque no puedes parchear lo que no has catalogado: una hoja de cálculo no es suficiente a esa escala, así que uso herramientas como WSUS y Ansible para rastrear y automatizar el despliegue. Lo único en lo que no cedo nunca es desactivar una política de parches para cumplir un plazo; esa deuda siempre vuelve en el peor momento.

¿Cómo documentas los sistemas para el resto del equipo?

Escribo la documentación en el momento en que construyo o cambio algo, no como una tarea para más tarde, porque los detalles están más frescos en ese momento y el 'más tarde' casi nunca llega. Mi estándar es que alguien con conocimientos generales de administración de sistemas, pero sin historial con este sistema en concreto, debería poder seguir la documentación durante una caída a las dos de la madrugada. Eso significa diagramas claros de cómo se conectan los servicios, comandos exactos en lugar de descripciones vagas, y una sección de 'problemas conocidos' para las particularidades que no son evidentes desde la arquitectura. Mantengo la documentación en una wiki compartida en lugar de notas locales, y la reviso cada vez que toco el sistema relacionado para que no quede desactualizada. En un equipo anterior heredé un conjunto de scripts sin ninguna documentación; pasé dos semanas haciendo ingeniería inversa y documentándolos correctamente antes de dejar que nadie más dependiera de ellos, porque una automatización sin documentar es un punto único de fallo con mi nombre puesto.

Cuéntame sobre una vez que automatizaste una tarea manual repetitiva.

Cada lunes revisaba manualmente el espacio en disco, el estado de los servicios y la caducidad de certificados en unos 40 servidores, lo que llevaba unas dos horas y era exactamente el tipo de tarea donde un despiste hace que algo se pase por alto. Escribí un script de PowerShell que recogía las métricas clave de cada servidor, marcaba en rojo cualquier cosa fuera de umbral, y enviaba automáticamente un informe resumen por correo a las 6 de la mañana, antes incluso de que yo me conectara. Tardé una semana aproximadamente en construirlo y probarlo bien, incluyendo gestionar servidores desconectados o inalcanzables sin que todo el script fallara. Además de ahorrar las dos horas semanales, detectó un certificado a cinco días de caducar que probablemente habría pasado por alto en una revisión manual durante una semana ajetreada. Más tarde lo amplié para publicar alertas en tiempo real en nuestro canal de Teams en lugar de esperar al informe semanal, lo que permitió detectar un problema de espacio en disco tres días antes de que causara una caída.

Describe una vez que evitaste un problema antes de que ocurriera.

Noté que la tasa de éxito de nuestras copias de seguridad había bajado silenciosamente del 100% a alrededor del 92% en unas semanas, sin que saltara ninguna alerta porque el monitoreo solo marcaba un job como fallido, no uno completado con avisos. Investigando los logs, encontré que un volumen de almacenamiento se estaba quedando sin capacidad, lo que provocaba copias truncadas de forma intermitente en tres servidores. Si no lo hubiera detectado, lo habríamos descubierto el día en que realmente necesitáramos restaurar algo, el peor momento posible. Amplié el volumen, corregí los jobs de copia afectados, y luego reconstruí las alertas para que un estado de 'completado con avisos' se tratara como algo a revisar, no como un éxito silencioso. También configuré un recordatorio recurrente para probar la restauración de una copia al azar cada mes, porque una copia de seguridad que nunca se ha probado a restaurar no es realmente una copia de seguridad.

Cuéntame sobre una vez que tuviste que trabajar con un proveedor o soporte externo durante una incidencia.

Teníamos un problema recurrente de caídas de conexiones VPN en nuestro firewall bajo carga alta, y tras dos rondas de diagnóstico interno, abrimos un caso con el soporte del fabricante. Me aseguré de entregarles un caso limpio y específico: marcas de tiempo exactas, versión de configuración, capturas de paquetes de la ventana afectada, y lo que ya habíamos descartado, porque los tickets vagos reciben respuestas vagas y hacen perder días. Su primera solución no resolvió el problema, así que insistí en escalar a un ingeniero senior, respaldando la petición con datos que mostraban que el patrón era constante y reproducible, no puntual. Resultó ser un bug conocido en una versión específica de firmware. Apliqué su solución en una ventana de mantenimiento, probándola antes bajo carga simulada, y luego documenté todo el intercambio en nuestra wiki interna para que la siguiente persona no tenga que reconstruir el historial del caso si vuelve a ocurrir.

¿Qué herramientas y plataformas usas en el día a día, y cómo decides entre ellas?

Mi base es una mezcla de administración de Linux y Windows Server, porque la mayoría de los entornos en los que he trabajado son híbridos. En el lado de Windows gestiono Active Directory, las políticas de grupo, y uso PowerShell para todo lo repetitivo. En Linux me manejo bien con las herramientas de shell habituales, cron, y trabajo con gestión de configuración a través de Ansible en lugar de hacer cambios a mano en cada máquina, porque los cambios manuales no escalan y son difíciles de auditar. Para el monitoreo he usado Nagios y Datadog: Nagios para alertas sencillas de tipo activo/caído y umbrales en infraestructura que controlo por completo, Datadog cuando necesito mejores dashboards e integración con servicios cloud. También trabajo con virtualización mediante VMware y, más recientemente, con cargas de trabajo en contenedores, lo que cambia algunas de las suposiciones sobre parches y ciclo de vida, ya que el host y la capa de aplicación se gestionan de forma distinta. Elijo la herramienta según lo que realmente necesita el entorno, no por defecto hacia lo que mejor conozco.

¿Cómo abordas las copias de seguridad y la recuperación ante desastres?

Parto del lado del negocio: cuál es el tiempo de recuperación y la pérdida de datos aceptables para cada sistema, porque eso determina la estrategia de copia de seguridad, no al revés. Un servidor de archivos con un RPO de 24 horas no necesita el mismo enfoque que una base de datos transaccional que solo puede tolerar minutos de pérdida de datos. Combino copias completas e incrementales según el sistema, almaceno copias fuera de sitio o en una región de nube distinta para que un fallo en una única ubicación no se lleve por delante tanto la producción como su copia, y cifro todo lo que contiene datos sensibles. Lo que la mayoría de los equipos se saltan es probar las restauraciones: programo simulacros trimestrales en los que realmente levantamos una copia en un entorno aislado y verificamos que funciona de principio a fin, no solo que el job de copia informó éxito. Esa práctica detectó una cadena de copias corrupta en un sistema, seis meses antes de que la hubiéramos necesitado para una recuperación real.

¿Cómo gestionas el acceso y los permisos de los usuarios de forma segura?

Aplico el principio de mínimo privilegio por defecto: los usuarios y las cuentas de servicio reciben exactamente el acceso que requiere su rol, nada más amplio por comodidad. Las nuevas solicitudes de acceso pasan por un proceso de aprobación documentado con un aprobador identificado, no un mensaje informal por Slack, para mantener un rastro auditable. Realizo revisiones de acceso trimestralmente, sobre todo para cualquier cosa con privilegios elevados o administrativos, y retiro el acceso de inmediato como parte del proceso de baja en lugar de hacerlo por lotes, porque una cuenta que queda activa tres semanas después de que alguien se va es exactamente el tipo de hueco que se explota. Para cuentas compartidas o de servicio, evito las contraseñas estáticas cuando es posible, a favor de credenciales gestionadas o tokens de corta duración. También mantengo una separación clara entre mi cuenta del día a día y mi cuenta de administrador, usando esta última solo cuando realmente hago trabajo de administración, para que una cuenta comprometida no dé automáticamente acceso de administrador de dominio.

Administrador de sistemas

Las entrevistas para Administrador de sistemas evalúan tu capacidad para mantener una infraestructura fiable y segura mientras equilibras el mantenimiento habitual con las solicitudes urgentes. Los entrevistadores buscan un diagnóstico calmado y metódico bajo la presión de una caída de servicio, buen criterio ante el riesgo, y el hábito de documentar los sistemas para que el conocimiento no dependa solo de ti. Esta guía cubre las preguntas más frecuentes y las respuestas que consiguen ofertas.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Prepárate más

Dominar la entrevista conductual (método STAR)Cómo prepararse para una entrevista técnica

Preguntas de entrevista habituales para Administrador de sistemas

Preguntas conductuales para puestos de Administrador de sistemas

Preguntas técnicas para candidatos a Administrador de sistemas

Lo que buscan los reclutadores en las entrevistas para Administrador de sistemas

Lo que los responsables de selección buscan realmente en los candidatos a Administrador de sistemas:

Gestión de incidentes calmada y estructurada. Fíjate si aparece un paso de comunicación pronto en el relato de una caída, no solo la solución técnica.
Evidencia de monitoreo proactivo, no solo gestión reactiva de urgencias. Los mejores candidatos describen problemas detectados antes de convertirse en caídas.
Experiencia real de automatización. Pide un script o herramienta concreta que hayan construido, no una afirmación vaga tipo 'automatizo cosas'.
Rigor en la documentación. Los sistemas que solo existen en la cabeza de una persona son un riesgo en cuanto esa persona no está disponible.
Buen criterio sobre el riesgo, especialmente en torno a parches y accesos. Los candidatos que describen un plan de rollback o un proceso de aprobación están más avanzados que los que simplemente describen ir rápido en solitario.

Preguntas que puedes hacer al entrevistador

→¿Qué stack de monitoreo y alertas usa actualmente el equipo?
→¿Cómo está estructurada la guardia, y con qué frecuencia se avisa realmente a alguien fuera del horario laboral?
→¿Cómo es el proceso de gestión de parches y cambios aquí?
→¿Cómo se mantiene la documentación de infraestructura, y qué tan actualizada está en la práctica?
→¿Cuál es el mayor riesgo de infraestructura que el equipo está trabajando en reducir actualmente?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis en tu primer puesto guardado.

Puestos relacionados

Técnico de soporte informático

Tech10 preguntas

Disponible en otros idiomas

English Français