Administrador de sistemas

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.

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.

Gestiono el mantenimiento a través de un sistema de tickets con SLA acordados, para que no quede silenciosamente relegado cada vez que alguien me escribe directamente. Bloqueo tiempo recurrente cada semana para el trabajo planificado, como parches, revisiones de capacidad y limpieza, y protejo ese tiempo igual que protegería una reunión. Cuando llega una solicitud urgente, la evalúo según el impacto real en el negocio, no según la urgencia percibida por quien la pide: una impresora averiada no es lo mismo que un sistema de nóminas caído. Si una solicitud realmente necesita pasar por delante, lo digo abiertamente y replanifico el mantenimiento en lugar de dejarlo caer discretamente, y aviso a mi responsable cuando las urgencias están desplazando de forma constante el trabajo planificado, porque eso suele ser una señal de plantilla o de proceso, no algo que simplemente hay que absorber.

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.

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.

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.

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.

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.

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.

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.