Por qué en 2026 el "Cómo" es lo menos importante (Manifiesto de un Informático de Sistemas)

1. Bienvenido al ruido (y por qué necesitamos silencio)

Sí, sé perfectamente lo que estarás pensando al ver la fecha de publicación de este post. ¿Un nuevo blog de tecnología que nace en 2026? ¿No vas como, mínimo, 20 años tarde a la fiesta? ¿No se ha mudado todo el mundo ya al vídeo efímero o a los feeds creados por algoritmos?

Ante esas preguntas, me paro, respiro y pienso. Es posible que empiece tarde según el reloj de las modas, sí. Pero si miramos el reloj de la calidad, creo que llego justo a tiempo.

Vivimos un momento extraño. A día de hoy, encontrar contenido técnico de calidad que no sea "automático", refrito o directamente generado por una Inteligencia Artificial sin una mínima revisión humana, se ha convertido en buscar una aguja en un pajar. La red se ha inundado de mediocridad a gran escala. Parece absurdo iniciar un proyecto "artesanal" de este estilo en plena era de la automatización masiva. O eso podría parecer a simple vista.

Y aquí viene la gran paradoja: no vengo a demonizar la tecnología que está saturando la red. Sería hipócrita por mi parte. De hecho, la IA es una herramienta que utilizo constantemente en mi día a día. La uso para depurar scripts, para encontrar patrones en logs y, sí, incluso la he usado para ayudarme a estructurar y pulir estas líneas que estás leyendo ahora mismo.

"Negar la Inteligencia Artificial en 2026 es como negar la calculadora en 1980."

Sin embargo, la diferencia —y la razón de ser de este blog— no está en el motor, sino en el conductor. Un Ferrari en manos de un niño que solo sabe pisar el acelerador es un peligro público; ese mismo Ferrari en manos de un piloto experimentado es una herramienta de precisión.

Este blog nace como mi cuaderno de bitácora personal para demostrar una tesis impopular: en 2026, las herramientas han cambiado y son más potentes que nunca, pero la necesidad de tener un experto humano a los mandos, alguien con criterio, ética y experiencia, es más crítica que nunca. El piloto automático es genial cuando el cielo está despejado, pero cuando hay tormenta en el servidor, quieres a un humano en la cabina.

2. Quién soy: El valor de la trinchera

Una vez aclarado el "por qué ahora", es el turno de responder al "quién".

Hola, soy Iván Anta. No soy un gurú de internet que vende cursos de éxito, ni un académico que teoriza sobre sistemas que nunca ha tocado. Soy, ante todo, un informático de trinchera.

Llevo un lustro peleándome a diario con sistemas reales, con esos entornos empresariales "vivos" donde un error no es una anécdota, sino una planta de producción parada o un departamento financiero incapaz de cerrar el mes.

Mi perfil profesional es una mezcla un poco extraña, difícil de encasillar en las descripciones estándar de LinkedIn. Mi día a día bascula constantemente entre dos mundos que rara vez se tocan:

• Por un lado, la administración de sistemas generalista: redes, servidores, virtualización, hosting, observabilidad. Soy el que baja al barro para entender por qué un paquete se pierde en la red.
• Por otro, la consultoría de alta especialización: soy Systems Engineer focalizado en el ERP IFS y en su motor, la base de datos Oracle.

Esta dualidad es mi mayor ventaja. Puedo pasar en un momento de estar diagnosticando por qué un servidor Windows va lento (mirando métricas de disco o CPU a bajo nivel), para al momento siguiente estar tirando del hilo dentro de un paquete PL/SQL complejo en una base de datos Oracle crítica. Entiendo el código, pero también entiendo el hierro sobre el que corre ese código.

Lo que más claro tengo después de estos cinco años de trabajo bajo presión es que, en tecnología corporativa, lo importante no es "que funcione" (cualquier cosa funciona, o renquea, un rato si la reinicias). Lo verdaderamente relevante, lo que separa a los profesionales de los aficionados, es diseñar para que no falle.

Por eso, he desarrollado una obsesión personal, casi enfermiza, por la estabilidad. Soy esa persona a la que, probablemente, le importen tus sistemas incluso más que a ti mismo. Mi objetivo no es cerrar tickets rápido para cumplir un KPI de soporte. Mi objetivo es diseñar, mantener y curar tu infraestructura para que tú, como cliente, te olvides de que existo. Porque si te acuerdas de mí, es que algo se ha roto. Y mi trabajo es que nada se rompa.

3. El manual de instrucciones que NO escribiré

Si has llegado hasta aquí buscando el típico tutorial rápido de "copia y pega este comando para arreglar tu error ORA-00600", tengo que darte una muy mala noticia: este no es tu sitio. Cierra la pestaña.

Y te digo esto por tu propia seguridad.

Internet está plagado de recetas mágicas y How-tos. La Inteligencia Artificial te puede generar veinte scripts de solución en diez segundos. Pero en el mundo de los sistemas críticos —donde una query mal optimizada o un parámetro de Oracle mal ajustado puede costar miles de euros por hora, o cientos de miles—, el "Cómo" es la parte fácil, y a la vez, la más peligrosa.

Una vez tienes claro el contexto, el "Cómo" se busca en la documentación oficial (man, manuales, San Google) o se le pregunta a la IA. El problema es que ejecutar el "Cómo" sin entender el contexto es jugar a la ruleta rusa con tus datos.

El verdadero valor de un experto, y lo que vas a encontrar en este blog, reside en las otras cuatro preguntas. Esas que casi nadie responde porque requieren pensar, no solo ejecutar:

3.1. El QUÉ (El Diagnóstico)

¿Cuál es el problema raíz real y no solo el síntoma que aparece en la pantalla? A menudo, el usuario dice "el sistema va lento". El síntoma es lentitud. Pero el Qué puede ser un bloqueo en base de datos, una latencia de red o un disco saturado. Si no aciertas el Qué, ninguna medicina curará al paciente por mucho que le puedas poner parches.

3.2. El POR QUÉ (La Estrategia)

¿Por qué ha ocurrido esto? Y más importante: ¿Por qué esta solución que propongo es la adecuada, no solo para salir del paso hoy, sino para dentro de tres años? Aquí es donde hablamos de deuda técnica: aplicar un parche rápido (el Cómo) sin entender las implicaciones arquitectónicas (el Por Qué) es pan para hoy y desastre para mañana.

3.3. El QUIÉN (La Responsabilidad)

¿Quién debe ejecutar esta acción? ¿Es una tarea para un operador junior? ¿Requiere la mano de un senior DBA? ¿O debería ser un proceso automatizado por un script validado? Saber delegar la tarea técnica al perfil (o al robot) adecuado es gestión de riesgos pura.

3.4. El CUÁNDO (El Timing)

¿Es el momento de migrar o de mantener? ¿De parchear o de sustituir? A veces, la mejor solución técnica es la peor solución de negocio si se aplica en el momento erróneo. Gastar decenas de miles de euros en solucionar un problema en un sistema que se va a sustituir en unos meses habiendo un parche que te cuesta decenas, es un error. El Cuándo define el impacto en el negocio.

El objetivo de este blog es simple: mostrar la estrategia, la arquitectura y las decisiones difíciles que ocurren antes de tocar el teclado. Mostraré el contexto para que entiendas el mapa del territorio. Pero no te daré un volante para conducir a ciegas. Porque mi trabajo, día tras día, es asegurarme de que los sistemas de mis clientes siguen funcionando, y para ello, necesito que entiendas el "qué" y el "por qué" antes siquiera de atrevernos a hablar del "cómo".

Por tanto, bajo mi guardia, en este blog no habrá "cómos" sin contexto.

4. La profundidad requiere espacio y tiempo

Para cerrar este primer post, quiero justificar la elección del formato. ¿Por qué un blog escrito? ¿Por qué textos de 2.000 palabras en un mundo que consume clips de 15 segundos?

La respuesta es la misma que aplico a mis servidores: robustez.

La complejidad de un entorno IFS o la arquitectura de alta disponibilidad de Oracle no caben en un tweet, requieren espacio. Además, escribo para ordenar mis propias ideas, porque el proceso de escritura me obliga a estructurar mi conocimiento y encontrar lagunas que no sabía que tenía.

Y, de paso, aprovecho para trabajar mi marca personal de la única forma que sé: con honestidad. Busco ganar visibilidad, sí, pero no a cualquier precio. Si a través de estas líneas consigo conectar con clientes, o compañeros de profesión que valoren la calidad, la reflexión y la estabilidad por encima de la inmediatez y el precio bajo, entonces el esfuerzo habrá merecido la pena.

• Si eres de esas personas que prefiere entender la raíz del problema antes de aplicar la solución.
• Si valoras la tranquilidad de saber que tus sistemas están en manos de alguien que mira más allá del comando a ejecutar.
• Si crees que en 2026 todavía hay espacio para la ingeniería artesanal apoyada en herramientas modernas...

Toma asiento y sé bienvenido.
Este blog será largo. Será técnico. A veces será denso.
Pero te prometo que merecerá la pena.

Nos leemos en el próximo post.