Operación · Soporte · Identidades
Plataforma, identidades y sistemas
Este caso agrupa la parte más operativa de mi perfil: estaciones, identidades, servicios, red y soporte técnico con foco en causa raíz. No pretende vender administración de sistemas como servicio; pretende mostrar cómo trabajo cuando el problema no está solo en una capa.
Contexto
He trabajado sobre todo en pymes y entornos mixtos, donde el mismo día tocas usuario, máquina y servicio. Ahí conviven Windows en puestos y Windows Server donde toca, con Linux cuando un servicio encaja mejor fuera del escritorio (alojamientos ligeros, utilidades de red, lo que el contexto pide). Encima suele estar Microsoft 365 con correo, colaboración e identidades en cloud o híbrido, y debajo la red que o bien falla o bien parece fallar. Las incidencias reales raramente respetan un solo cajón: el síntoma aparece en la aplicación, la causa en identidad o conectividad. Es el mismo eje que detallo en la experiencia en NATTIA VENTURES SL.
Problema
Los síntomas se reparten entre varias capas: “no entra”, “va lento”, “no sincroniza” pueden ser cuenta, política, DNS, VPN, caché local o una actualización mal terminada. Sin método, cuesta separar lo que es identidad, sistema, conectividad o configuración, y se pierde el día probando a ciegas. El negocio necesita soporte que no se quede en un parche superficial que vuelve en dos semanas: hace falta acotar hipótesis, probar en orden y dejar constancia de qué se tocó para poder revertir.
Qué resolvía el sistema o proyecto
Que el trabajo diario siga: puestos estables, identidades coherentes y servicios alcanzables sin que cada incidencia sea un misterio nuevo. El “sistema” no es un producto con nombre comercial; es la combinación de estación, directorio, nube, servidor y red que sostiene a la gente que produce. Mi aportación va en ordenar el diagnóstico, aplicar cambios reversibles y documentar lo mínimo imprescindible para que otro compañero o yo podamos retomar el hilo.
Mi rol
Diagnóstico antes de tocar: acotar si el fallo vive en sesión, permiso, red o servicio. Soporte a usuarios y equipos con criterio, sin asumir que “siempre es el mismo”. Configuración de lo que el entorno permite: estaciones, servicios puntuales en Linux cuando aplica, comprobaciones de conectividad. Identidades en Active Directory y escenarios habituales en Microsoft 365 (buzones, licencias, grupos, políticas razonables). Administración básica de plataforma sin pretender un datacenter entero en una ficha. Y la relación entre operación y continuidad: lo que decido en plataforma afecta a si mañana alguien puede trabajar; lo tengo presente al priorizar y al comunicar.
Stack y dominios
El día a día mezcla puestos Windows, servidores Windows donde el rol lo exige, y Linux cuando el servicio encaja mejor ahí. El directorio y los grupos en Active Directory condicionan buena parte del acceso; Microsoft 365 añade otra capa de identidad y colaboración que hay que alinear con lo on-premise cuando el entorno es híbrido.
En red trabajo con TCP/IP, DNS y resolución de rutas habituales; VPN la abordo a nivel de diagnóstico (síntoma, encaminamiento, autenticación), sin publicar aquí topología interna ni reglas copiables. Todo ello enlaza con puestos y servicios como piezas del mismo problema, no como tickets aislados.
Decisiones técnicas
- Causa raíz: separar capas (identidad, sistema, red, aplicación) antes de acumular cambios; probar hipótesis en orden en lugar de aplicar tres palos a la vez.
- Mínimo privilegio: grupos y derechos acotados; revisión de excesos antes de normalizar “admin local para todos”.
- Cambios pequeños y trazables: un ajuste comprobable; posibilidad de revertir; comprobación posterior con el usuario cuando aplica.
- Documentación útil: breve, buscable: qué se hizo, por qué y cómo deshacerlo; no papel formal que nadie lee.
- Visión transversal: entender que una decisión en identidad o red condiciona aplicación y productividad al día siguiente.
Restricciones o NDA
Sin nombres de dominio interno, VLANs, direcciones ni capturas de consolas con datos de terceros.
Resultado o aprendizaje
Menos reincidencias cuando hay patrón, hipótesis clara y un registro corto post-incidente. Lo que aprendí en este frente se parece a lo que pido en desarrollo: cambios acotados, comprobación y posibilidad de volver atrás. Ese cruce es parte del perfil híbrido: no trato la plataforma como un mundo aparte del resto del trabajo técnico.
Este caso explica una parte clave de mi perfil: la capacidad de relacionar aplicación, identidad, sistema y red cuando el síntoma no coincide con una sola capa.