1. INTRODUCCIÓN Y DELIMITACIÓN CONCEPTUAL

Una arquitectura de sistemas informáticos es el conjunto coherente de decisiones que determina cómo se organizan el procesamiento, la memoria, el almacenamiento, las comunicaciones, el software de base y los mecanismos de explotación para prestar unos servicios concretos. No debe reducirse al esquema físico de servidores: comprende también la distribución de responsabilidades, los dominios de fallo, la forma de escalar, el modelo de seguridad, la observabilidad, la recuperación y las restricciones operativas. Dos plataformas con equipos similares pueden responder a arquitecturas distintas si difieren en la manera de repartir el estado, coordinar procesos, aislar usuarios o recuperarse de una avería.

La arquitectura es una respuesta a requisitos. Antes de elegir una tecnología hay que determinar qué carga debe soportarse, qué tiempos de respuesta son aceptables, cuántos usuarios concurrirán, qué datos se tratarán, qué pérdidas serían tolerables, cuánto tiempo puede permanecer indisponible el servicio y qué límites presupuestarios, normativos y organizativos existen. Una solución sobredimensionada puede ser económicamente ineficiente; una subdimensionada puede provocar colas, degradación, errores y pérdida de confianza. La calidad de la decisión depende de convertir necesidades generales en magnitudes verificables y de documentar los compromisos asumidos.

En este tema se emplean varios conceptos próximos, pero no equivalentes. La capacidad indica cuánto trabajo puede absorber el sistema bajo condiciones definidas. El rendimiento expresa cómo de rápido o eficientemente realiza ese trabajo. La flexibilidad refleja la facilidad con la que puede adaptarse a cambios funcionales, tecnológicos u operativos. La escalabilidad describe si mantiene un comportamiento aceptable cuando aumenta la carga y se añaden recursos. La elasticidad añade la capacidad de ajustar esos recursos de manera dinámica. La disponibilidad mide la proporción de tiempo en que el servicio está utilizable; la fiabilidad se relaciona con la probabilidad de funcionar sin fallo durante un intervalo; y la resiliencia incluye la capacidad de resistir, degradarse de forma controlada y recuperarse.

El enunciado también distingue las unidades centrales multiusuario, los sistemas departamentales y los grandes sistemas centrales. Una unidad central multiusuario comparte recursos de cómputo entre múltiples usuarios y trabajos, aplicando planificación, aislamiento, protección y contabilidad. El mainframe es su manifestación histórica y actual más característica, aunque también existen grandes servidores Unix, plataformas de virtualización y clústeres que ofrecen funciones semejantes. Por su parte, «departamental» y «central» describen sobre todo el alcance organizativo y el modelo de gobierno, no una cifra universal de procesadores o usuarios.

En una organización sanitaria, la arquitectura tiene consecuencias asistenciales. El retraso de una consulta, la caída de un servicio de identidad, la saturación de una base de datos o la indisponibilidad de una integración pueden afectar a cadenas completas de atención. Por ello, la planificación debe considerar el servicio de extremo a extremo: aplicación, datos, red, autenticación, infraestructura, operación y dependencias externas. Aumentar la disponibilidad de un servidor aislado no garantiza la disponibilidad del proceso si persiste un punto único de fallo en otro componente.

Este enfoque evita varios errores frecuentes de examen y de práctica profesional: confundir capacidad con velocidad; suponer que más CPU resuelve cualquier cuello de botella; identificar alta disponibilidad con copia de seguridad; asociar automáticamente un nivel Tier a un porcentaje contractual; creer que activo-activo siempre mejora la continuidad; o considerar que centralizar y distribuir son opciones absolutas. La arquitectura real combina patrones y exige analizar su contexto.

2. ARQUITECTURAS BÁSICAS DE LOS SISTEMAS INFORMÁTICOS

2.1. Arquitectura como estructura y como comportamiento

En sentido estricto, la arquitectura de computador describe la interfaz visible para el programador —juego de instrucciones, registros, modos de direccionamiento, tipos de datos y modelo de memoria—, mientras que la microarquitectura concreta cómo se implementa internamente. En un sentido más amplio, utilizado en planificación de sistemas, la arquitectura describe la organización de nodos, redes, almacenamiento, capas de software y mecanismos de coordinación. Conviene diferenciar ambos planos: una arquitectura de servicio puede desplegarse sobre procesadores de familias distintas, y una misma familia de procesadores puede soportar soluciones centralizadas, virtualizadas o distribuidas.

2.2. Von Neumann, Harvard y Harvard modificada

La arquitectura de Von Neumann utiliza un espacio de memoria común para instrucciones y datos. La CPU obtiene ambos a través de una ruta compartida, lo que simplifica el modelo pero introduce el conocido cuello de botella de Von Neumann: la velocidad de procesamiento puede quedar limitada por el movimiento de información entre procesador y memoria. La arquitectura Harvard separa memorias y buses de instrucciones y datos. Muchos procesadores actuales emplean una variante híbrida: memoria principal unificada y cachés de primer nivel separadas para instrucciones y datos. Esta organización permite accesos simultáneos y mantiene un espacio de direcciones manejable para el software.

La jerarquía de memoria —registros, cachés, memoria principal y almacenamiento persistente— es parte esencial de la arquitectura. Cada nivel intercambia capacidad, coste y latencia. Una caché no «acelera toda aplicación» de forma automática: su beneficio depende de la localidad temporal y espacial de los accesos. La caché L3, normalmente mayor y compartida, reduce accesos a memoria principal cuando L1 y L2 fallan, pero también introduce coherencia y contención entre núcleos.

2.3. Arquitectura centralizada

En una arquitectura centralizada, el procesamiento principal y el control de los datos se concentran en una plataforma o dominio central. Los terminales pueden limitarse a entrada y salida, mientras la unidad central ejecuta aplicaciones, gestiona sesiones y aplica políticas comunes. El modelo facilita gobierno, seguridad, consistencia y aprovechamiento intensivo de recursos; a cambio, exige una ingeniería rigurosa de capacidad y continuidad porque un fallo central puede afectar a muchos servicios.

Centralización no significa necesariamente «un único ordenador». Un servicio central puede estar formado por varios nodos, clústeres, cabinas y redes redundantes, e incluso distribuirse entre centros de datos. Lo central es que presta una capacidad corporativa común y se gobierna como una plataforma. Esta precisión es importante porque los grandes sistemas actuales combinan centralización lógica con distribución física.

2.4. Arquitectura cliente-servidor y por capas

El modelo cliente-servidor distribuye responsabilidades entre consumidores de servicios y servidores que los ofrecen. En dos capas, el cliente puede contener presentación y parte de la lógica, accediendo directamente al servidor de datos. En tres capas se separan presentación, lógica de negocio y persistencia. Las arquitecturas de más niveles añaden componentes de integración, caché, mensajería, API, identidad o análisis. La separación mejora mantenibilidad y escalado independiente, pero introduce latencia, dependencias y más puntos que observar.

Un cliente pesado ejecuta una porción importante de lógica y requiere despliegue en el puesto; un cliente ligero delega más trabajo en el servidor y simplifica la administración central. Ninguno es universalmente superior. La elección depende de conectividad, experiencia de usuario, requisitos offline, seguridad, coste de soporte y naturaleza de la carga.

2.5. Arquitecturas distribuidas

Un sistema distribuido está formado por componentes que cooperan mediante una red y se presentan como un servicio coherente. La distribución permite proximidad, paralelismo, escalado y aislamiento de fallos, pero introduce problemas que no existen en memoria compartida: mensajes perdidos o duplicados, particiones de red, relojes no perfectamente sincronizados, consistencia de datos y fallos parciales. Por ello, «distribuido» no es sinónimo de «más disponible». Sin mecanismos de replicación, consenso, reintento idempotente, control de versiones y observabilidad, la distribución puede aumentar la fragilidad.

2.6. Virtualización, contenedores y nube

La virtualización desacopla sistemas operativos y cargas del hardware físico mediante un hipervisor. Facilita consolidación, aislamiento, migración y aprovisionamiento. Los contenedores aíslan procesos compartiendo el núcleo del sistema operativo, lo que reduce sobrecarga y acelera el despliegue, aunque el aislamiento y el modelo de seguridad son distintos. La nube añade autoservicio, acceso por red, agrupación de recursos, elasticidad y medición del consumo. Estos mecanismos son habilitadores; no sustituyen la arquitectura de la aplicación ni garantizan por sí solos rendimiento o continuidad.

3. MODELOS DE PROCESAMIENTO Y ORGANIZACIÓN DE RECURSOS

3.1. Procesamiento por lotes, interactivo y transaccional

El procesamiento por lotes agrupa trabajos que se ejecutan sin interacción continua del usuario. Es apropiado para cierres, consolidaciones, generación masiva de documentos o transformación de datos. Permite optimizar ventanas y prioridades, pero debe controlar dependencias, reejecución, puntos de reinicio y duración máxima. El procesamiento interactivo exige respuesta durante una sesión humana y es sensible a la latencia. El procesamiento transaccional en línea mantiene integridad y concurrencia sobre operaciones cortas, normalmente con propiedades ACID en la base de datos. Una misma plataforma puede combinar los tres modelos y asignarles clases de servicio diferentes.

3.2. Tiempo compartido

El tiempo compartido permite que varios usuarios perciban ejecución simultánea aun cuando comparten procesadores. El planificador distribuye intervalos de CPU conforme a prioridades, políticas y estado de los procesos. El quantum limita el tiempo de ejecución antes de una posible expropiación, pero no es por sí solo el criterio de selección. Se tienen en cuenta prioridades, afinidad, interactividad, consumo previo y clases de planificación. Este modelo transformó las unidades centrales de los años sesenta y continúa, con mayor sofisticación, en sistemas operativos actuales.

3.3. Multiprocesamiento simétrico y NUMA

En un sistema SMP, varios procesadores o núcleos comparten memoria y dispositivos bajo una imagen común del sistema operativo. El acceso uniforme simplifica la programación, pero la coherencia de caché y el ancho de banda de memoria limitan el crecimiento. En NUMA, la memoria está físicamente distribuida entre nodos: cada procesador accede más rápido a su memoria local que a la remota. El sistema sigue ofreciendo un espacio compartido, pero el rendimiento depende de ubicar procesos y páginas cerca del procesador que los usa. NUMA no es una técnica para fusionar la memoria de servidores independientes ni equivale a hiperconvergencia.

3.4. Procesamiento masivamente paralelo y clústeres

Los sistemas MPP y los clústeres distribuyen trabajo entre nodos con memoria propia. En una arquitectura shared-nothing, cada nodo controla su CPU, memoria y almacenamiento, y coopera por mensajes. Esta organización escala bien cuando la carga puede particionarse y los datos se distribuyen adecuadamente. En shared-disk, varios nodos acceden a almacenamiento común y necesitan coordinar bloqueo y coherencia. En shared-memory, el paralelismo ocurre sobre memoria compartida. Cada modelo desplaza la complejidad a un lugar distinto: coherencia de caché, coordinación de disco o partición de datos.

3.5. Aceleradores y heterogeneidad

Las plataformas modernas combinan CPU de propósito general con GPU, unidades vectoriales, aceleradores criptográficos, DPU y dispositivos específicos de inteligencia artificial. La heterogeneidad mejora rendimiento por vatio para cargas adecuadas, pero añade requisitos de programación, controladores, portabilidad y planificación. Un acelerador no reemplaza a la CPU: desplaza operaciones concretas cuando existe suficiente paralelismo y el coste de transferir datos no anula la ganancia.

4. PLANIFICACIÓN DE LOS SISTEMAS INFORMÁTICOS

4.1. De la estrategia al sistema operable

La planificación de sistemas informáticos traduce objetivos organizativos en capacidades tecnológicas sostenibles. No consiste en elaborar una lista de compras ni en extrapolar el inventario actual. Debe definir el servicio que se desea prestar, la arquitectura objetivo, la transición desde la situación existente, los recursos humanos y económicos, los riesgos, el modelo de operación y los criterios con los que se verificará el resultado. En términos de planificación de sistemas de información, la arquitectura tecnológica debe derivarse del modelo de información, del mapa de sistemas y de los requisitos priorizados, no al revés.

El punto de partida es identificar interesados y procesos críticos. Se recogen cargas actuales, previsiones de crecimiento, calendarios, obligaciones regulatorias, dependencias, contratos, ciclos de renovación, competencias del equipo y restricciones de centro de datos o nube. La planificación debe abarcar tanto la inversión inicial como los costes recurrentes: licencias, soporte, comunicaciones, almacenamiento, energía, observabilidad, copias, pruebas, formación, guardias y renovación. El coste total de propiedad es más útil que comparar únicamente precios de adquisición.

4.2. Requisitos funcionales y no funcionales

Los requisitos funcionales expresan qué capacidades proporciona el sistema; los no funcionales determinan con qué nivel de calidad. Para arquitectura y capacidad son especialmente relevantes el volumen, la concurrencia, el tiempo de respuesta, el caudal, la disponibilidad, la durabilidad, la recuperación, la seguridad, la portabilidad, la mantenibilidad y la trazabilidad. Un requisito como «el sistema será rápido» no permite diseñar ni aceptar. Debe reformularse, por ejemplo: «el 95 % de las consultas de un tipo determinado responderá en menos de dos segundos bajo una carga de 1.500 sesiones concurrentes, excluyendo tiempos de un tercero previamente identificados».

También deben aclararse las condiciones: tamaño del conjunto de datos, distribución de operaciones, patrón de lectura y escritura, cachés calientes o frías, número de conexiones, ventanas de batch y tolerancia al error. Sin un perfil de carga reproducible, una cifra de tiempo de respuesta carece de contexto. El mismo servidor puede ser suficiente para operaciones ligeras y resultar insuficiente para consultas complejas, cifrado intensivo o procesamiento de imágenes.

4.3. Situación actual y línea base

La planificación exige una línea base fiable. Se inventariarán componentes y versiones, se identificarán relaciones de dependencia y se analizarán métricas históricas. La media no basta: hay que observar máximos, percentiles, estacionalidad, crecimiento, distribución por franjas y episodios anómalos. La CPU media del 30 % puede ocultar un núcleo saturado, pausas de memoria, colas de entrada/salida o picos periódicos. Del mismo modo, una base de datos con espacio libre puede estar limitada por IOPS, latencia, bloqueo o tamaño del registro de transacciones.

La línea base debe abarcar la cadena completa: cliente, DNS, red, balanceador, identidad, aplicación, mensajería, base de datos, almacenamiento y servicios externos. Los mapas de dependencia y la gestión de configuración ayudan a evitar que se dimensione un componente ignorando otro. Para cada servicio se identifican propietarios, criticidad, horarios, RTO, RPO, soporte, contratos y obsolescencia.

4.4. Arquitectura objetivo y alternativas

Con los requisitos y la línea base se comparan alternativas: mantener y optimizar, escalar verticalmente, distribuir, consolidar, virtualizar, migrar, sustituir o retirar. La evaluación debe incluir capacidad técnica, riesgo de transición, reversibilidad, dependencia de proveedor, disponibilidad de competencias, seguridad, interoperabilidad, sostenibilidad y coste. Una prueba de concepto puede validar una incógnita concreta; no sustituye una prueba de carga representativa ni demuestra por sí sola la operabilidad a largo plazo.

Las decisiones significativas deben registrarse con contexto, opciones consideradas, decisión, consecuencias y fecha de revisión. Este registro evita que una elección se convierta en dogma cuando cambian las condiciones. También facilita auditoría, transferencia de conocimiento y gestión de deuda técnica.

4.5. Plan de transición

La transición determina secuencia, coexistencia, migración de datos, pruebas, formación, reversión y retirada. Conviene separar despliegue técnico de puesta en servicio: una plataforma puede estar instalada pero no preparada para tráfico real. El plan debe incluir pruebas funcionales, rendimiento, seguridad, continuidad y recuperación; criterios de entrada y salida; monitorización reforzada; responsables; comunicación; y procedimientos de vuelta atrás.

La capacidad se planifica también durante la migración. Las coexistencias duplican temporalmente almacenamiento y procesamiento; las sincronizaciones, reindexaciones o conversiones consumen recursos adicionales; y la ventana de cambio puede exigir mayor paralelismo. Ignorar esta carga transitoria provoca proyectos que funcionan en laboratorio pero fallan durante el paso a producción.

4.6. Revisión continua

La planificación no termina con la implantación. Se revisan demanda, SLO, costes, incidentes, crecimiento y obsolescencia. Deben definirse umbrales de actuación y plazos de aprovisionamiento. Un aviso cuando el disco llega al 95 % puede ser demasiado tardío si la ampliación contractual requiere meses. La gestión de capacidad madura anticipa la decisión antes de agotar el margen y relaciona cada ampliación con una hipótesis de demanda verificable.

5. PLANIFICACIÓN DE CAPACIDAD Y CARACTERIZACIÓN DE CARGAS

5.1. Concepto y niveles

La planificación de capacidad determina qué recursos se necesitan, cuándo y bajo qué condiciones para cumplir niveles de servicio con un margen de riesgo aceptable. Se aplica a recursos individuales —CPU, memoria, almacenamiento, red, licencias, conexiones—, a componentes —base de datos, servidor de aplicaciones, clúster— y al servicio de extremo a extremo. La capacidad de la cadena no es la suma de sus capacidades: queda limitada por el recurso o dependencia que se satura primero.

Conviene distinguir capacidad instalada, utilizable y efectiva. La instalada es el total físico o contratado. La utilizable descuenta reservas, redundancia y límites operativos. La efectiva es el trabajo real que puede procesarse con el perfil de carga y el SLO exigidos. Un clúster de cuatro nodos diseñado para soportar el fallo de uno no debe planificarse como si los cuatro estuvieran disponibles de manera permanente; su capacidad de diseño puede ser N+1 y exigir que tres nodos absorban la carga máxima.

5.2. Unidad de trabajo y perfil de carga

El primer paso es elegir unidades significativas: transacciones por segundo, solicitudes por minuto, estudios procesados, mensajes, trabajos batch, usuarios activos, gigabytes ingeridos o consultas concurrentes. Los «usuarios registrados» rara vez sirven para dimensionar. Interesa cuántos están activos simultáneamente, qué operaciones ejecutan, con qué distribución y qué recursos consume cada clase.

El perfil debe separar lectura, escritura, operaciones ligeras y pesadas, tamaños de petición y respuesta, tasa de aciertos de caché, sesiones, conexiones y ventanas. También se modelan picos previsibles, campañas, cierres mensuales, contingencias y crecimiento de datos. Un pico no siempre se resuelve con capacidad permanente: puede desplazarse, limitarse, encolarse o absorberse elásticamente, según el requisito de tiempo.

5.3. Ley de Little y concurrencia

La ley de Little relaciona el número medio de elementos en un sistema, la tasa media de llegada y el tiempo medio de permanencia:

L = λ × W

L  = número medio de solicitudes presentes
λ  = tasa media de llegada o throughput estable
W  = tiempo medio dentro del sistema

Si un servicio completa 100 solicitudes por segundo y cada solicitud permanece en él 0,2 segundos, la concurrencia media será aproximadamente 20. La ley es muy útil para comprobar coherencia entre métricas, pero requiere un sistema estable y promedios observados en el mismo intervalo. No predice por sí sola percentiles ni comportamiento bajo saturación.

5.4. Margen y utilización objetivo

Dimensionar para una utilización sostenida del 100 % elimina el margen frente a variación y fallos. A medida que un recurso se aproxima a la saturación, la cola puede crecer de manera no lineal y disparar el tiempo de respuesta. El objetivo de utilización depende del recurso, del patrón de carga y del tiempo de aprovisionamiento. No existe un porcentaje universal del 70 u 80 %. Una CPU con tareas paralelizables puede tolerar picos altos; un dispositivo de almacenamiento sensible a latencia o un pool de conexiones pequeño puede degradarse antes.

Como aproximación inicial puede utilizarse una fórmula heurística, siempre declarando sus supuestos:

capacidad objetivo =
demanda prevista × factor de pico × margen de contingencia
---------------------------------------------------------
             utilización operativa objetivo

La fórmula no sustituye pruebas ni modelos de colas. Si la demanda actual es 1.000 operaciones por segundo, se prevé un crecimiento del 20 %, el pico es 1,5 veces la carga ordinaria y se desea operar al 75 %, el resultado aproximado sería 2.400 operaciones por segundo antes de añadir otras reservas. El cálculo debe revisarse porque crecimiento, pico y contingencia pueden estar correlacionados; multiplicarlos sin análisis puede sobredimensionar.

5.5. Predicción

Las técnicas incluyen extrapolación de tendencias, medias móviles, modelos estacionales, regresión con variables de negocio, simulación, benchmarking y pruebas de carga. La predicción debe expresar escenarios, no una falsa cifra exacta: base, esperado y estrés. Cada escenario identifica supuestos, probabilidad, impacto y acción. Es especialmente importante distinguir crecimiento de usuarios, aumento de actividad por usuario y crecimiento del volumen histórico, porque presionan recursos diferentes.

5.6. Capacidad de datos y almacenamiento

El almacenamiento se dimensiona por capacidad, rendimiento y durabilidad. Deben contemplarse datos primarios, índices, réplicas, registros, instantáneas, copias, crecimiento, retención, compresión, cifrado y espacio temporal de mantenimiento. La capacidad bruta de un dispositivo no coincide con la útil después de RAID, codificación de borrado, reservas y sobreaprovisionamiento. Además, terabytes disponibles no garantizan IOPS ni latencia suficientes.

En bases de datos, el tamaño de índices, la selectividad, el patrón de escritura, los checkpoints, la replicación y las operaciones de mantenimiento influyen en CPU, memoria y E/S. En almacenamiento de objetos, el número de objetos y solicitudes puede ser tan importante como los bytes. En red, hay que diferenciar ancho de banda, paquetes por segundo, latencia y conexiones simultáneas.

5.7. Capacity plan

El plan de capacidad recoge servicio, recurso, línea base, previsión, umbral, margen, fecha estimada de agotamiento, acción, plazo de suministro, coste, responsable y evidencia. Debe vincularse al presupuesto y a la gestión de cambios. La mejor predicción carece de valor si no desencadena una decisión con antelación suficiente.

6. RENDIMIENTO, MEDICIÓN Y ANÁLISIS DE CUELLOS DE BOTELLA

6.1. Métricas fundamentales

El rendimiento se evalúa con varias dimensiones. La latencia es el tiempo que tarda una operación; el throughput o caudal es el trabajo completado por unidad de tiempo; la concurrencia es el número de operaciones activas; y la utilización es la proporción de capacidad ocupada. Estas magnitudes se relacionan, pero no son intercambiables. Un sistema puede tener alto throughput y una latencia inaceptable, o baja latencia con poca capacidad total.

La latencia debe expresarse mediante distribución y percentiles. La media oculta colas largas. Los percentiles p50, p95, p99 o p99,9 indican el umbral bajo el que termina una proporción de operaciones. Un p95 de dos segundos significa que el 95 % termina en dos segundos o menos; no garantiza nada sobre el 5 % restante. Para servicios clínicos críticos puede importar más la cola que la media.

6.2. Tiempos de servicio y espera

El tiempo de respuesta incluye procesamiento y espera. Cuando llegan más solicitudes de las que un recurso puede servir, se forma una cola. La CPU al 100 %, un pool de conexiones agotado, un bloqueo de base de datos o una cola de disco pueden producir el mismo síntoma visible: aumento de latencia. Por ello, analizar solo el componente con mayor porcentaje de uso puede conducir a una conclusión errónea.

El método USE propone revisar para cada recurso utilización, saturación y errores. El método RED, habitual en servicios, observa tasa de solicitudes, errores y duración. Ambos son puntos de partida, no sustituyen la correlación con trazas y dependencias. La observabilidad integra métricas, registros y trazas distribuidas para reconstruir el recorrido de una petición.

6.3. Cuellos de botella y ley de Amdahl

Un cuello de botella es el recurso cuya capacidad limita el throughput o provoca espera dominante. Al mejorarlo, el límite puede desplazarse. La ley de Amdahl muestra que acelerar una parte de un trabajo produce una ganancia limitada por la fracción que no mejora:

S = 1 / ((1 - P) + P / N)

S = aceleración total
P = fracción paralelizable o mejorable
N = factor de aceleración aplicado a esa fracción

Si el 80 % de una tarea puede acelerarse diez veces, la mejora total no es diez, sino aproximadamente 3,57. El 20 % restante se convierte en límite. La ley recuerda que añadir núcleos no corrige serialización, bloqueo, E/S o llamadas externas. La ley de Gustafson ofrece otra perspectiva cuando el tamaño del problema crece con los recursos, pero tampoco elimina costes de coordinación.

6.4. Benchmarking

Un benchmark es una prueba estandarizada o reproducible que facilita comparaciones. Las suites SPEC CPU se utilizan para comparar rendimiento intensivo de procesador bajo reglas de ejecución publicadas; su versión concreta debe comprobarse en la documentación vigente de SPEC antes de convertirla en dato memorístico. TPC-C modela procesamiento transaccional y publica, entre otras, la métrica tpmC y el coste asociado. Estas pruebas son útiles para comparar configuraciones bajo reglas comunes, pero no predicen directamente una aplicación sanitaria concreta.

El benchmark de proveedor, el microbenchmark y la prueba de aplicación responden preguntas distintas. Un microbenchmark puede medir memoria o cifrado; una prueba de carga reproduce flujos del servicio; una prueba de estrés busca el límite; una prueba de resistencia mantiene carga durante horas para detectar fugas o degradación; una prueba de pico observa cambios bruscos; y una prueba de escalabilidad compara comportamiento al añadir recursos.

6.5. Diseño de pruebas de rendimiento

La prueba define objetivos, escenario, datos, entorno, calentamiento, duración, distribución de operaciones, ramp-up, think time, criterios de éxito y monitorización. Debe evitar que el generador de carga sea el cuello de botella. Los datos de prueba han de tener cardinalidad y distribución semejantes a producción sin exponer información real. El resultado debe incluir intervalos, percentiles, errores y consumo de recursos, no solo una captura de pantalla.

6.6. Optimización

Optimizar exige medir antes y después. Se formula una hipótesis, se cambia una variable, se repite la prueba y se verifica que no se desplaza el problema ni empeoran otras propiedades. Las mejoras habituales incluyen índices y consultas, caché, pooling, reducción de llamadas, compresión, paralelismo, colas, partición y ajuste de memoria. Cada técnica tiene efectos secundarios: la caché introduce invalidación, la compresión consume CPU, el paralelismo aumenta coordinación y el pooling puede amplificar la presión sobre la base de datos.

7. FLEXIBILIDAD, ESCALABILIDAD Y ELASTICIDAD

7.1. Flexibilidad

La flexibilidad es la capacidad del sistema para admitir cambios con esfuerzo y riesgo controlados. Puede referirse a modificar reglas, incorporar nuevas integraciones, sustituir componentes, desplegar en otra plataforma, aumentar recursos o adaptar la operación. Se favorece mediante interfaces estables, modularidad, configuración externa, automatización, estándares, bajo acoplamiento y separación entre estado y procesamiento. Sin embargo, cada capa de abstracción tiene coste; una solución excesivamente genérica puede ser más difícil de entender y operar que una específica.

La flexibilidad debe evaluarse con escenarios concretos: añadir un nuevo centro, cambiar un proveedor de identidad, incorporar otra fuente de datos, actualizar el motor de base de datos o duplicar la carga. Decir que una arquitectura es «flexible» sin identificar qué cambios facilita es una afirmación vacía. También conviene distinguir flexibilidad técnica de flexibilidad contractual y organizativa. Un producto portable puede quedar bloqueado por licencias, competencias o formatos propietarios.

7.2. Escalabilidad vertical

El escalado vertical o scale up aumenta recursos de un nodo: procesadores, memoria, canales de E/S o almacenamiento. Simplifica la consistencia y evita repartir datos, por lo que resulta atractivo para bases de datos y cargas monolíticas. Sus límites son el tamaño máximo de la plataforma, el coste creciente, el dominio de fallo y las ventanas necesarias para algunas ampliaciones. En plataformas empresariales y mainframes puede existir ampliación dinámica o activación de capacidad, lo que reduce parte de estos inconvenientes.

Escalar verticalmente no significa necesariamente sustituir el equipo. La virtualización puede reasignar vCPU y memoria; un sistema modular puede activar procesadores; y una cabina puede ampliar puertos o discos. Aun así, el software debe aprovechar los recursos. Añadir memoria no mejora una carga limitada por bloqueo, y añadir CPU puede empeorar contención si la aplicación mantiene una sección serial.

7.3. Escalabilidad horizontal

El escalado horizontal o scale out añade nodos y distribuye carga. Funciona especialmente bien cuando las instancias son sin estado o cuando el estado se externaliza y puede particionarse. Requiere balanceo, descubrimiento, coordinación, despliegue homogéneo, observabilidad y tratamiento de fallos. Si todos los nodos dependen de una única base de datos saturada, la capa frontal escala pero el servicio no.

La eficiencia de escalado compara la ganancia obtenida con los recursos añadidos. Duplicar nodos y obtener 1,8 veces el throughput implica una eficiencia del 90 % para ese intervalo. La eficiencia suele disminuir al crecer por comunicación, sincronización, datos calientes y operaciones globales. Por ello, una prueba con dos nodos no demuestra escalado indefinido.

7.4. Escalado diagonal, partición y replicación

El escalado diagonal combina crecimiento vertical hasta un punto económico con expansión horizontal posterior. La replicación crea copias para lectura, continuidad o proximidad; la partición distribuye subconjuntos de datos o carga. Replicar no aumenta necesariamente la capacidad de escritura y puede introducir retraso. Particionar aumenta capacidad, pero complica consultas globales, rebalanceo y transacciones entre particiones.

Las claves de partición deben distribuir carga y conservar afinidad. Una clave temporal puede concentrar todas las escrituras recientes en una partición; una clave aleatoria distribuye mejor, pero dificulta recorridos por rango. Los datos sanitarios pueden requerir afinidad por paciente o centro, aunque cualquier decisión debe preservar continuidad asistencial, seguridad e interoperabilidad.

7.5. Elasticidad

La elasticidad es la capacidad de aumentar y reducir recursos según demanda, idealmente de forma automatizada. Se basa en métricas, políticas y tiempos de aprovisionamiento. Un autoscaler reactivo puede llegar tarde ante un pico súbito; uno predictivo depende de patrones fiables. La reducción también exige cuidado para no interrumpir sesiones, perder trabajos o reducir redundancia por debajo del mínimo.

La elasticidad de infraestructura no garantiza elasticidad de aplicación. Una instancia puede arrancar en segundos, pero cargar datos, reconstruir caché, registrarse o obtener licencias puede tardar minutos. Las aplicaciones con estado necesitan drenaje, replicación y coordinación. El diseño debe medir el tiempo real desde la decisión hasta que la nueva capacidad sirve tráfico útil.

7.6. Patrones de software que favorecen el escalado

• Instancias sin estado: permiten repartir peticiones sin afinidad persistente.
• Colas y procesamiento asíncrono: absorben picos y desacoplan productores de consumidores.
• Idempotencia: posibilita reintentos sin duplicar efectos.
• Caché: reduce trabajo repetido, con una política explícita de expiración e invalidación.
• Backpressure: limita la entrada cuando el consumidor no puede mantener el ritmo.
• Bulkheads: separan pools y evitan que una carga agote todos los recursos.
• Circuit breaker: interrumpe temporalmente llamadas a una dependencia degradada.

8. DISPONIBILIDAD, FIABILIDAD, RESILIENCIA Y CONTINUIDAD

8.1. Conceptos

La disponibilidad responde a la pregunta «¿qué proporción del tiempo solicitado estuvo el servicio apto para su uso?». La fiabilidad responde a «¿con qué probabilidad funcionará sin fallo durante un intervalo?». La mantenibilidad mide la facilidad y rapidez de restauración. La resiliencia abarca prevención, absorción, degradación, recuperación y aprendizaje. La continuidad de negocio conecta estas propiedades con procesos, prioridades y alternativas operativas.

Un componente muy fiable puede tardar mucho en repararse y ofrecer peor disponibilidad que otro que falla más pero se recupera en segundos. Para un sistema reparable, una aproximación estacionaria es:

A = MTBF / (MTBF + MTTR)

MTBF = tiempo medio entre fallos
MTTR = tiempo medio de restauración o reparación

La fórmula es útil para razonar, pero no describe distribuciones, dependencias, mantenimiento planificado ni fallos correlacionados. Tampoco debe confundirse MTTR de reparación física con tiempo total de restauración del servicio, que puede incluir detección, diagnóstico, escalado, conmutación, validación y comunicación.

8.2. Los «nueves» de disponibilidad

Estas cifras son conversiones matemáticas, no garantías universales. Debe definirse la ventana de servicio, qué cuenta como indisponibilidad, si se excluye mantenimiento, desde dónde se mide y qué porcentaje de usuarios debe estar afectado. Un SLA puede incluir créditos económicos, mientras un SLO es el objetivo interno y un SLI la medición. La arquitectura debe basarse en la necesidad del proceso, no en acumular «nueves» sin analizar coste.

8.3. RTO y RPO

El RTO es el tiempo objetivo para restaurar una capacidad tras una interrupción. El RPO expresa el punto máximo de pérdida de datos aceptable, medido hacia atrás desde el incidente. RTO de una hora y RPO de quince minutos significa que el servicio debería recuperarse en una hora y que no deberían perderse más de quince minutos de datos. No implica que la recuperación real esté garantizada: debe respaldarse con arquitectura, procedimientos y pruebas.

Alta disponibilidad y recuperación ante desastres tratan escalas distintas. La primera suele actuar automáticamente frente a fallos locales y breves. La recuperación ante desastres contempla pérdida de un dominio mayor, corrupción, ciberincidente o indisponibilidad prolongada. La copia de seguridad protege frente a pérdida o corrupción de datos, pero no proporciona por sí sola capacidad de servicio. Una réplica inmediata puede copiar la corrupción; una copia aislada puede preservar datos, pero tardar horas en restaurarse.

8.4. Disponibilidad de una cadena

En componentes en serie, si todos son necesarios y sus fallos fueran independientes, la disponibilidad aproximada de la cadena sería el producto de sus disponibilidades. Cinco componentes al 99,9 % producirían alrededor del 99,5 %, no 99,9 %. En la realidad, la independencia rara vez es completa: varios elementos pueden compartir energía, red, identidad, almacenamiento, software o equipo operativo. Los fallos comunes y correlacionados son más peligrosos que la avería aislada.

8.5. Tier de centros de datos

El sistema Tier de Uptime Institute clasifica la topología de infraestructura del emplazamiento en cuatro niveles: Tier I, capacidad básica; Tier II, componentes de capacidad redundantes; Tier III, mantenimiento concurrente; y Tier IV, tolerancia a fallos. El nivel describe criterios de topología y comportamiento ante mantenimiento o fallo. No es una puntuación de 0 a 99,999, no mide PUE y no debe traducirse automáticamente a un SLA de aplicación. Un servicio puede fallar por software, datos, red externa u operación aunque el edificio tenga una topología avanzada.

8.6. Presupuesto de error

Un presupuesto de error transforma el SLO en indisponibilidad o errores tolerables durante un periodo. Si el servicio consume el presupuesto demasiado rápido, se priorizan estabilidad y reducción de riesgo; si lo conserva, puede asumirse más velocidad de cambio. Esta práctica equilibra innovación y fiabilidad, pero requiere mediciones representativas y una gobernanza que respete las decisiones derivadas.

9. PATRONES Y MECANISMOS DE ALTA DISPONIBILIDAD

9.1. Redundancia y eliminación de puntos únicos de fallo

La alta disponibilidad comienza identificando puntos únicos de fallo: componentes cuya pérdida interrumpe el servicio. Se aplican redundancia de fuentes, interfaces, enlaces, nodos, balanceadores, almacenamiento, bases de datos y dependencias. Pero duplicar elementos no basta si comparten el mismo riesgo: dos servidores en el mismo rack con una única alimentación, dos enlaces por el mismo conducto o dos instancias que dependen de la misma credencial.

Los esquemas N+1 disponen de una unidad adicional sobre las necesarias; N+2 soportan dos pérdidas de capacidad; 2N duplican toda la capacidad; y 2N+1 añade reserva. La elección depende del fallo que se desea tolerar, el tiempo de reparación y el coste. La capacidad de reserva debe probarse bajo carga y durante mantenimiento, no solo existir en inventario.

9.2. Activo-pasivo

En activo-pasivo, un nodo atiende y otro permanece preparado. El pasivo puede estar caliente, templado o frío según el grado de sincronización y el tiempo de arranque. El failover puede ser automático o manual. Sus ventajas son simplicidad y menor riesgo de conflictos de escritura; sus inconvenientes incluyen capacidad ociosa, posible degradación durante la conmutación y el riesgo de que el pasivo no esté realmente preparado.

La conmutación requiere detección fiable, decisión, fencing y validación. El fencing impide que el nodo considerado fallido continúe escribiendo. Sin él puede producirse split brain: dos nodos se creen activos y corrompen el estado. Los heartbeats solo detectan comunicación; no demuestran que la aplicación cumpla el SLO ni resuelven por sí solos la autoridad.

9.3. Activo-activo

En activo-activo, varios nodos atienden tráfico. Puede aprovechar mejor capacidad y reducir tiempo de conmutación, pero exige distribuir sesiones, datos y escrituras. Si los nodos comparten una base de datos única, esta puede seguir siendo el punto de fallo. Si cada nodo posee datos, se necesitan replicación, resolución de conflictos o partición. Activo-activo no es automáticamente más disponible: aumenta componentes y rutas que pueden fallar.

9.4. Balanceo, salud y drenaje

El balanceador reparte peticiones según algoritmo y estado. Las comprobaciones de salud deben distinguir proceso vivo de servicio apto. Un puerto abierto puede responder mientras la base de datos está bloqueada. Una sonda demasiado profunda puede declarar caídos todos los nodos por una dependencia común. Es habitual separar liveness, readiness y señales de negocio.

Antes de retirar un nodo se realiza drenaje: deja de recibir nuevas sesiones y termina las existentes dentro de un límite. Las sesiones persistentes dificultan el balanceo; externalizar el estado o usar afinidad controlada mejora la operación. Los despliegues rolling, blue-green y canary reducen riesgo, pero requieren compatibilidad entre versiones y migraciones de datos seguras.

9.5. Replicación de datos

La replicación síncrona confirma una escritura cuando las réplicas requeridas la han persistido, reduciendo RPO pero aumentando latencia y sensibilidad a la distancia. La asíncrona confirma antes y replica después, mejorando rendimiento y distancia a costa de posible pérdida reciente. La semisíncrona combina garantías intermedias. La elección se basa en consistencia, RPO, latencia y topología.

El quorum evita que una minoría aislada tome decisiones. En un conjunto de tres votantes, normalmente se requieren dos; con dos nodos no hay mayoría si se separan, salvo árbitro o política específica. Añadir nodos pares no siempre mejora tolerancia, porque la mayoría sigue determinando cuántos fallos pueden soportarse. La latencia y disponibilidad del plano de consenso son parte de la capacidad del servicio.

9.6. Degradación controlada

La resiliencia no siempre mantiene todas las funciones. Puede preservar consultas críticas y suspender informes, usar datos en caché con advertencia, encolar operaciones no urgentes o limitar cargas pesadas. Este diseño requiere priorizar funciones y evitar inconsistencias. La degradación debe ser visible, reversible y probada; ocultar errores con datos obsoletos puede ser peligroso en un contexto sanitario.

9.7. Pruebas y operación

Un mecanismo no probado es una hipótesis. Deben ensayarse pérdida de nodo, red, almacenamiento, zona, credenciales y dependencias; recuperación de copia; failback; capacidad durante mantenimiento; y procedimientos humanos. Las pruebas controladas de resiliencia descubren acoplamientos y supuestos. El objetivo no es provocar caos sin control, sino aprender dentro de límites, con observación y criterios de parada.

10. UNIDADES CENTRALES MULTIUSUARIO

10.1. Concepto

Una unidad central multiusuario es una plataforma capaz de ejecutar simultáneamente trabajos y sesiones de múltiples usuarios, manteniendo aislamiento, reparto de recursos, protección y administración común. El término procede de la evolución desde terminales conectados a un computador central, pero sus principios siguen presentes en servidores Unix, mainframes, sistemas de virtualización y plataformas de nube. La simultaneidad puede ser real, mediante varios procesadores, o aparente, mediante tiempo compartido.

El sistema debe resolver cuatro problemas básicos: identificar quién solicita el recurso; decidir cuándo y cuánto puede usarlo; impedir accesos no autorizados; y contabilizar el consumo. A ello se añaden comunicación entre procesos, almacenamiento, red, gestión de trabajos, auditoría y recuperación. La unidad central no se define únicamente por potencia, sino por la capacidad de gestionar cargas heterogéneas bajo políticas coherentes.

10.2. Gestión de procesos

Un proceso posee espacio de direcciones, estado, credenciales, descriptores y recursos. El sistema operativo crea, planifica, suspende y termina procesos. Las políticas pueden ser expropiativas o cooperativas, de prioridad fija o dinámica, de tiempo real o de tiempo compartido. El planificador debe equilibrar respuesta interactiva, throughput de batch, equidad y compromisos de servicio. En grandes plataformas, las cargas se agrupan en clases con objetivos y prioridad, no se gestionan como procesos aislados sin contexto.

La concurrencia introduce condiciones de carrera, interbloqueo e inanición. Mutex, semáforos, monitores, colas y transacciones coordinan acceso. Un sistema robusto también limita procesos, hilos, archivos, memoria y conexiones para que un usuario no agote recursos comunes. Los límites deben ser suficientemente estrictos para proteger y suficientemente amplios para la carga legítima.

10.3. Memoria virtual y protección

La memoria virtual proporciona a cada proceso un espacio lógico independiente. Las tablas de páginas traducen direcciones virtuales a marcos físicos y los permisos distinguen lectura, escritura y ejecución. La paginación permite usar almacenamiento secundario como respaldo, aunque un exceso de fallos de página produce thrashing: el sistema dedica más tiempo a mover páginas que a ejecutar trabajo útil. En plataformas NUMA, la ubicación física de páginas también afecta al rendimiento.

La unidad de gestión de memoria y el núcleo impiden que un proceso ordinario acceda a zonas no asignadas. Una violación puede generar una excepción y finalizar el proceso. La separación protege confidencialidad e integridad, pero no reemplaza controles de aplicación, mínimos privilegios ni mitigaciones frente a canales laterales.

10.4. Entrada/salida, spooling y trabajos

Los periféricos son mucho más lentos que la CPU y se comparten. Interrupciones, DMA, colas y cachés permiten solapar cálculo y E/S. El spooling deposita trabajos en almacenamiento para que un servicio los procese en orden y con políticas, como impresión o ejecución batch. Las colas facilitan prioridades, reintentos, reinicio y auditoría.

En una unidad central se diferencian frecuentemente trabajos batch, transacciones, servicios de larga duración y sesiones interactivas. Cada categoría requiere límites y objetivos. El batch puede usar capacidad ociosa sin perjudicar transacciones; una operación crítica puede recibir prioridad; y una tarea mal diseñada debe contenerse para no monopolizar el sistema.

10.5. Seguridad y contabilidad

La autenticación establece identidad; la autorización determina recursos y operaciones; la auditoría registra actividad; y la contabilidad mide consumo. Los modelos incluyen usuarios, grupos, roles, listas de control, capacidades y etiquetas. El principio de mínimo privilegio limita impacto. En entornos centralizados, una identidad comprometida puede alcanzar muchos recursos, por lo que son esenciales segregación, autenticación reforzada, control de cuentas privilegiadas y trazabilidad.

10.6. Virtualización y particionamiento

La virtualización permite ejecutar varios sistemas aislados sobre una unidad física. Una partición lógica recibe procesadores, memoria y dispositivos virtuales, y puede ajustarse según políticas. Esta consolidación mejora utilización y separación de cargas, pero crea una nueva capa crítica: hipervisor, red virtual, almacenamiento compartido y plano de gestión. La capacidad debe considerar sobreasignación, afinidad, reserva y contención entre máquinas.

11. EL MAINFRAME COMO GRAN SISTEMA CENTRAL

11.1. Rasgos distintivos

El mainframe es una plataforma empresarial orientada a gran volumen transaccional, consolidación, seguridad, entrada/salida intensiva y disponibilidad. No debe definirse como «ordenador muy grande» ni confundirse con supercomputador. El supercomputador suele optimizar cálculo científico masivamente paralelo; el mainframe prioriza throughput de transacciones, aislamiento de cargas, compatibilidad, gestión y continuidad. Ambos pueden ser potentes, pero responden a perfiles diferentes.

Sus características históricas incluyen canales de E/S especializados, particionamiento lógico, procesadores especializados, corrección de errores, componentes reemplazables y mecanismos de actualización. La capacidad se gestiona de forma central mediante clases de servicio y prioridades, permitiendo coexistir transacciones, bases de datos, batch, Linux y analítica.

11.2. Particiones y gestión de cargas

En IBM Z, PR/SM proporciona particiones lógicas o LPAR que aíslan sistemas y asignan recursos. Sobre ellas pueden ejecutarse z/OS, Linux y otros entornos soportados. z/VM añade virtualización de gran densidad, especialmente para Linux. El Workload Manager de z/OS clasifica trabajo y ajusta recursos conforme a objetivos, importancia y estado del sistema. Esta gestión basada en políticas es una diferencia relevante frente a administrar servidores independientes únicamente por métricas locales.

Los subsistemas cumplen funciones especializadas. CICS soporta procesamiento transaccional; Db2 gestiona datos relacionales; IMS combina gestión de información y transacciones; JES organiza trabajos; RACF gestiona identidades y permisos; y Parallel Sysplex coordina múltiples imágenes z/OS para capacidad y continuidad. No todas las instalaciones utilizan todos estos componentes, pero ilustran una arquitectura integrada de gran sistema central.

11.3. E/S y procesadores especializados

El diseño descarga tareas de entrada/salida y determinadas funciones para preservar CPU general. Procesadores o capacidades especializadas pueden atender Linux, Java o comunicaciones según la plataforma y licenciamiento. La separación mejora eficiencia, aunque exige comprender qué carga es elegible. La arquitectura de canales mantiene múltiples operaciones de E/S concurrentes y reduce intervención de la CPU.

11.4. Compatibilidad y modernización

Una fortaleza del mainframe es la continuidad de aplicaciones y datos durante largos periodos. Esa compatibilidad protege inversión, pero también puede mantener lenguajes, formatos y dependencias difíciles de renovar. Modernizar no implica siempre reescribir: puede encapsular funciones mediante API, separar interfaces, automatizar pruebas, trasladar cargas adecuadas, actualizar datos o refactorizar gradualmente. Una reescritura masiva introduce riesgo funcional, especialmente cuando el conocimiento está implícito en programas antiguos.

11.5. IBM z17

IBM anunció la generación IBM z17 en abril de 2025 como evolución de z16. La familia incorpora procesadores Telum II y continúa la tendencia de integrar aceleración para cargas de inteligencia artificial, seguridad, consolidación y procesamiento transaccional. Para oposición, lo relevante no es memorizar una cifra comercial de núcleos o frecuencia —que varía por modelo y configuración—, sino entender la dirección tecnológica: más aceleración especializada, modernización de aplicaciones, criptografía integrada y operación híbrida.

11.6. Ventajas y límites

12. EVOLUCIÓN Y TENDENCIAS DE LAS UNIDADES CENTRALES MULTIUSUARIO

12.1. De batch a tiempo compartido

Las primeras unidades centrales ejecutaban lotes secuenciales preparados fuera de línea. La multiprogramación mantuvo varios trabajos en memoria para aprovechar la CPU mientras otro esperaba E/S. Después, el tiempo compartido permitió interacción mediante terminales. La evolución del hardware, la memoria virtual y la protección convirtió el computador central en plataforma compartida para comunidades amplias de usuarios.

12.2. Minicomputadores y sistemas departamentales

Los minicomputadores acercaron capacidad a departamentos y laboratorios con menor coste que un mainframe. Unix reforzó portabilidad y multiusuario. Más tarde, servidores RISC y x86 asumieron muchas cargas departamentales y empresariales. La descentralización aumentó autonomía, pero creó silos, duplicidades y costes de administración. La posterior consolidación mediante virtualización recuperó parte de las ventajas de centralizar sin volver al terminal clásico.

12.3. Cliente-servidor, web y plataformas distribuidas

El cliente-servidor desplazó presentación y lógica al puesto o a servidores especializados. La web simplificó distribución del cliente. Las arquitecturas por capas, SOA, microservicios y mensajería ampliaron la distribución. Cada etapa resolvió problemas de la anterior y creó otros: dependencia del puesto, proliferación de servidores, complejidad de integración, observabilidad y consistencia.

12.4. Virtualización, convergencia e hiperconvergencia

La virtualización consolidó servidores y permitió movilidad de cargas. Las infraestructuras convergentes integraron cómputo, red y almacenamiento validados. La hiperconvergencia agrupa cómputo y almacenamiento distribuido definido por software en nodos administrados como sistema. Se amplía añadiendo nodos, aunque la granularidad puede obligar a adquirir CPU y almacenamiento conjuntamente aunque solo falte uno.

12.5. Nube híbrida y modernización

La tendencia no es una sustitución total del centro por la nube, sino combinación. Los datos, la latencia, la regulación, la dependencia, el coste y las competencias determinan ubicación. Las unidades centrales exponen API, ejecutan Linux y contenedores, participan en automatización y se integran con servicios externos. Una arquitectura híbrida necesita identidad, red, observabilidad, seguridad y gobierno comunes; de lo contrario solo añade fronteras.

12.6. Automatización e infraestructura como código

El aprovisionamiento manual se sustituye por plantillas versionadas, pipelines, políticas y configuración declarativa. La automatización reduce variabilidad y acelera recuperación, pero también puede propagar errores a gran escala. Requiere revisión, pruebas, segregación, secretos seguros y mecanismos de reversión. En sistemas centrales, automatizar no significa eliminar control, sino hacer el control repetible y auditable.

12.7. IA y aceleración

La IA se acerca a la transacción para detectar patrones sin mover datos sensibles o añadir latencias excesivas. CPU vectorial, GPU y aceleradores especializados conviven. La planificación debe incluir memoria, ancho de banda, precisión, consumo, actualización de modelos y gobierno. El rendimiento de inferencia no puede evaluarse solo por operaciones teóricas; importan modelo, lote, latencia, exactitud y coste.

12.8. Sostenibilidad

La eficiencia se analiza por trabajo útil, energía, refrigeración y ciclo de vida. Consolidar puede reducir equipos, pero una alta utilización sin margen perjudica resiliencia. PUE mide la relación entre energía total del centro y energía del equipamiento TI; no mide por sí sola eficiencia de aplicaciones ni emisiones. También cuentan ubicación, mezcla energética, agua, reutilización, vida del hardware y retirada responsable.

12.9. Seguridad poscuántica y criptografía

Las grandes plataformas incorporan aceleración criptográfica y preparan migraciones a algoritmos resistentes a futuros ataques cuánticos. La transición será gradual porque afecta protocolos, certificados, HSM, aplicaciones y datos de larga duración. La «agilidad criptográfica» —inventariar, sustituir y versionar algoritmos sin rediseñar todo— se convierte en requisito arquitectónico.

12.10. Edge y centralidad lógica

El edge procesa cerca del origen para reducir latencia, consumo de red o dependencia. No elimina los sistemas centrales: desplaza funciones concretas y sincroniza resultados. La arquitectura debe decidir qué ocurre desconectado, qué dato es autoritativo, cómo se actualiza el software y cómo se protege el dispositivo. El futuro combina centralidad lógica, distribución física y gobierno común.

13. SISTEMAS DEPARTAMENTALES

13.1. Definición por alcance

Un sistema departamental satisface necesidades de una unidad, servicio, centro o dominio limitado. La característica definitoria no es un rango fijo de usuarios, memoria o precio, sino el alcance organizativo y la responsabilidad de gobierno. Puede ejecutarse en un servidor pequeño, en una plataforma corporativa o como servicio en nube. Lo departamental es su finalidad y ámbito de decisión, no necesariamente su ubicación física.

Estos sistemas surgen cuando una necesidad local no está cubierta, requiere rapidez o posee particularidades. Pueden aportar innovación, proximidad y conocimiento del proceso. También pueden convertirse en aplicaciones críticas aunque nacieran como solución menor. Por ello, el tamaño inicial no debe justificar ausencia de seguridad, continuidad, documentación o propietario.

13.2. Ventajas

• Proximidad funcional: el equipo conoce usuarios, vocabulario y flujo real.
• Agilidad: las decisiones pueden adoptarse con menos niveles de coordinación.
• Experimentación: permite validar una necesidad antes de una extensión corporativa.
• Especialización: cubre equipos, técnicas o procesos muy concretos.
• Continuidad local: ciertas funciones pueden mantenerse ante problemas de un servicio central, si existe diseño desconectado y reconciliación.

13.3. Riesgos

Los riesgos típicos son duplicidad, datos inconsistentes, integraciones punto a punto, cuentas locales, falta de soporte, tecnologías obsoletas y dependencia de una persona o proveedor. Una hoja de cálculo o base de datos local puede crecer hasta contener información crítica sin controles equivalentes a los corporativos. La autonomía no debe confundirse con excepción permanente.

También aparece el shadow IT: soluciones adquiridas o desarrolladas fuera de los procesos de arquitectura, seguridad y contratación. Su origen puede ser una necesidad legítima, pero crea exposición. La respuesta madura no es solo prohibir; es ofrecer canales ágiles, catálogo de servicios y criterios para evaluar, integrar o retirar.

13.4. Gobierno

Todo sistema departamental debería registrar propietario funcional y técnico, finalidad, datos, usuarios, interfaces, criticidad, soporte, copias, continuidad, costes, contrato y fecha de revisión. Debe usar identidad corporativa cuando proceda, aplicar mínimos privilegios, mantener inventario y exportar datos en formatos controlados. Las excepciones necesitan caducidad y plan.

La arquitectura puede adoptar un modelo federado: la organización central define guardarraíles —identidad, seguridad, interoperabilidad, observabilidad, respaldo y ciclo de vida— y el departamento conserva configuración o desarrollo dentro de esos límites. Así se evita tanto la fragmentación total como una centralización incapaz de responder a necesidades locales.

13.5. Evolución posible

Un piloto local puede consolidarse, transformarse en producto corporativo, integrarse en una plataforma común o retirarse. La decisión considera valor, adopción, duplicidades, coste, riesgo y capacidad de soporte. Convertirlo en corporativo exige rediseñar para múltiples centros, parametrización, segregación, capacidad, soporte 24/7 y gobierno de datos; no basta con «abrir acceso» a más usuarios.

14. GRANDES SISTEMAS CENTRALES

14.1. Características

Un gran sistema central presta capacidades transversales a una organización extensa o a varias entidades. Concentra datos, reglas, identidad o procesamiento bajo gobierno común. Puede implementarse sobre mainframe, servidores Unix, clústeres x86, plataformas hiperconvergentes, nube o combinaciones. Por tanto, «gran sistema central» no es sinónimo exclusivo de mainframe.

Su escala exige arquitectura explícita, operación especializada, gestión de cambios, observabilidad, capacidad, continuidad, seguridad y soporte. El impacto potencial de un fallo obliga a segmentar dominios y evitar que la centralización lógica produzca un único dominio físico. Los sistemas centrales suelen disponer de entornos separados, automatización, pruebas, catálogo, acuerdos de nivel y procedimientos de emergencia.

14.2. Economías y coherencia

La centralización reduce duplicidad, facilita estándares y concentra competencias. Una única plataforma de identidad, integración o datos puede servir a muchas aplicaciones. El coste marginal de incorporar usuarios puede ser menor que mantener soluciones aisladas. También mejora la consistencia de reglas y la visión longitudinal de información.

Sin embargo, la economía de escala puede invertirse por complejidad, licencias, coordinación o dependencia. Una plataforma corporativa que tarda años en responder genera soluciones paralelas. El gobierno debe medir experiencia, lead time, coste unitario, fiabilidad y valor, no solo número de servidores consolidados.

14.3. Riesgo sistémico

Cuanto mayor es el alcance, mayor es el radio de impacto. Una actualización defectuosa, una identidad central caída o una corrupción replicada puede afectar simultáneamente a muchos centros. La solución es diseñar aislamiento de fallos, despliegues progresivos, compatibilidad, límites y recuperación. La redundancia de hardware no contiene un error lógico desplegado en todos los nodos.

14.4. Plataformas compartidas y multitenencia

Una plataforma compartida debe aislar cargas, datos, cuotas y configuración. La multitenencia puede ser por base, esquema, tabla, contenedor, máquina o partición. Cada modelo equilibra coste y aislamiento. Deben prevenirse vecinos ruidosos mediante límites, prioridades y reservas. El consumo debe atribuirse para planificar y asignar costes.

14.5. Operación

La operación central necesita turnos, escalado, runbooks, gestión de eventos, problemas y cambios. La monitorización debe orientarse a servicios y procesos, no solo a equipos. Un indicador verde de CPU no demuestra que el usuario complete su tarea. Las pruebas sintéticas y de recorrido verifican capacidades desde puntos representativos.

La gestión de obsolescencia es permanente. Hardware, sistema operativo, middleware, base de datos, lenguajes y certificados tienen ciclos diferentes. La hoja de ruta evita acumulación de actualizaciones incompatibles. Los contratos deben prever transición, exportación de datos, soporte y salida.

14.6. Centralización física, lógica y de gobierno

Estas dimensiones pueden separarse. Un servicio puede estar físicamente distribuido entre dos centros, lógicamente centralizado como una única capacidad y gobernado corporativamente. Otro puede ejecutarse en un CPD central, pero estar fragmentado por departamentos sin datos ni reglas comunes. Analizar estas tres dimensiones ofrece una visión más precisa que etiquetar simplemente «centralizado» o «distribuido».

15. COMPARACIÓN Y CRITERIOS DE DECISIÓN ARQUITECTÓNICA

15.1. No existe una dicotomía absoluta

La decisión entre sistema departamental y central, entre escalado vertical y horizontal, o entre local y nube no debe plantearse como elección ideológica. Cada servicio puede combinar elementos. La identidad y los datos maestros pueden centralizarse; una captura cercana al equipo puede ser local; el análisis intensivo puede ejecutarse en una plataforma compartida; y la contingencia puede mantener una función mínima en el centro.

15.2. Matriz de criterios

15.3. Principios de diseño

Las capacidades transversales, difíciles de duplicar de forma segura, suelen centralizarse: identidad, directorio, certificados, interoperabilidad, terminologías, observabilidad y gobierno de datos. La configuración específica puede federarse. Los datos deben tener fuente autorizada y reglas de sincronización. Las integraciones deben evitar conexiones punto a punto no gobernadas.

El principio de subsidiariedad tecnológica asigna cada decisión al nivel más cercano que pueda resolverla sin perjudicar coherencia global. El centro decide lo que solo afecta a su configuración; la organización decide lo que crea impacto común, riesgo sistémico o dependencia transversal.

15.4. Coste y riesgo

El análisis económico incluye inversión, operación, personal, energía, licencias, soporte, red, continuidad, migración y salida. El análisis de riesgo valora probabilidad, impacto y controles. Una alternativa barata puede tener alto coste de indisponibilidad; otra muy redundante puede ser desproporcionada. Se busca minimizar coste total ajustado al riesgo, no precio aislado.

15.5. Decisiones reversibles e irreversibles

Las decisiones reversibles pueden tomarse con experimentación y límites; las difíciles de revertir —modelo de datos, contrato largo, dependencia propietaria o ubicación de datos— requieren análisis mayor. Diseñar una estrategia de salida reduce bloqueo. La portabilidad real se demuestra con formatos, automatización, pruebas y competencias, no con una cláusula genérica.

15.6. Antipatrones

• Servidor más grande como respuesta universal: ignora software, colas y dependencias.
• Activo-activo cosmético: dos frontales con una base o red única.
• Microservicios por moda: distribuye un dominio sin capacidad operativa.
• Promedio como requisito: oculta picos y colas.
• Backup como HA: confunde restauración con continuidad inmediata.
• Piloto convertido en corporativo sin rediseño: amplía usuarios, no arquitectura.
• Redundancia sin diversidad: componentes duplicados comparten el mismo fallo común.

16. APLICACIÓN AL ENTORNO SANITARIO Y AL SAS

16.1. Criticidad y cadenas asistenciales

En el Servicio Andaluz de Salud conviven sistemas asistenciales, administrativos, analíticos, de integración, identidad y puesto de trabajo. Su criticidad no depende solo del número de usuarios. Un servicio pequeño puede ser esencial para una unidad; una plataforma masiva puede admitir degradación parcial. La clasificación debe basarse en impacto sobre seguridad del paciente, continuidad asistencial, obligaciones, actividad y recuperación.

La disponibilidad se analiza por recorrido. Una consulta clínica puede depender de puesto, red, autenticación, aplicación, bus, repositorio y servicio externo. El objetivo de extremo a extremo debe asignar presupuestos a componentes y establecer degradaciones seguras. No se deben publicar detalles internos no verificados ni asumir que un producto concreto utiliza una arquitectura por su apariencia funcional.

16.2. Perfiles de demanda

La actividad sanitaria presenta franjas, cambios de turno, campañas, episodios epidémicos, cierres y procesos batch. La planificación combina históricos con escenarios. También contempla incidentes en otros canales que desplazan demanda: si un portal falla, aumentan llamadas; si una integración se retrasa, crecen colas y reintentos. La omnicanalidad puede distribuir o multiplicar carga.

16.3. Datos y continuidad

Los datos sanitarios requieren confidencialidad, integridad, trazabilidad y disponibilidad. La replicación, copia y archivo responden a riesgos distintos. Deben existir inventario, clasificación, retención, pruebas de restauración y control de acceso. Los RPO se asignan según proceso: no todas las fuentes toleran la misma pérdida. La reconciliación debe preservar autoría, tiempo y versiones.

16.4. Planificación de capacidad corporativa

La capacidad se gobierna desde servicio, no desde cada servidor. Se recogen SLI, tendencias, previsiones, contratos y plazos. Las plataformas compartidas necesitan cuotas y atribución. El equipo local aporta conocimiento de picos, equipamiento e incidencias; el equipo corporativo consolida y evita duplicidad. El modelo debe establecer qué cambios son configuración local y cuáles afectan arquitectura común.

16.5. Alta disponibilidad y contingencia

Los servicios críticos necesitan redundancia, procedimientos y pruebas. La contingencia puede incluir modo degradado, trabajo en cola, formularios temporales o acceso a información mínima, siempre con reconciliación y control. No toda función debe permanecer activa: se priorizan las que evitan daño y sostienen la asistencia. La indisponibilidad se comunica con alcance, alternativa y previsión basada en evidencia.

16.6. Puesto de trabajo y centralización

El puesto clínico puede combinar ejecución local, virtualización y servicios centrales. DaaS o VDI facilitan mantenimiento, control y escalado, pero dependen de conectividad, periféricos, latencia y capacidad de backend. Las pruebas deben incluir impresión, dispositivos, audio, imagen y movilidad. Un modelo centralizado de escritorio no elimina soporte local ni red.

16.7. Gobierno y documentación

La decisión arquitectónica debe registrar propietario, requisitos, datos, dependencias, SLO, RTO, RPO, capacidad, seguridad, soporte, coste y salida. Las pruebas y métricas aportan evidencia. Los datos internos del SAS que no sean públicos o verificables no deben convertirse en material de estudio como cifras exactas. Para oposición, se estudian conceptos y fuentes publicadas, separando ejemplos pedagógicos de descripciones oficiales.

17. CASO PRÁCTICO, REPASO Y MAPA CONCEPTUAL

17.1. Supuesto

Una plataforma corporativa atiende 900 solicitudes por segundo en hora punta. El p95 es 1,4 segundos y el SLO exige menos de dos. Existen tres nodos de aplicación, cada uno probado hasta 400 solicitudes por segundo manteniendo el SLO. La base de datos alcanza 65 % de CPU, pero su latencia de escritura aumenta durante un batch nocturno. Se prevé crecimiento del 25 % y se exige soportar la pérdida de un nodo.

17.2. Análisis

La demanda futura sería 1.125 solicitudes por segundo sin margen adicional. Con tres nodos y uno fuera quedarían dos, capaces de 800; el diseño incumple N+1. Cuatro nodos dejarían tres tras el fallo, con capacidad teórica de 1.200, apenas 6,7 % sobre la previsión. Antes de aprobar, habría que aplicar margen por variabilidad, repetir pruebas con base de datos y batch, y verificar red, conexiones y almacenamiento.

La CPU de base de datos no demuestra ausencia de cuello. El aumento de latencia durante batch puede deberse a E/S, bloqueo, registros o caché. Se separan cargas, se revisan consultas, se ajusta ventana o se reserva capacidad. Si se añade aplicación sin aumentar la base, el cuello puede desplazarse. Se prueba con distribución real y percentiles.

17.3. Propuesta

1. Definir escenarios normal, pico, batch y fallo de nodo.
2. Instrumentar trazas, pool de conexiones, bloqueo, IOPS y latencia.
3. Optimizar el batch o aislar su clase de servicio.
4. Probar cuatro y cinco nodos para conocer curva de escalado.
5. Verificar failover, drenaje, capacidad N+1 y recuperación.
6. Establecer umbrales y fecha de revisión según crecimiento.

17.4. Preguntas de repaso

• ¿Qué métrica define experiencia de cola: media o percentiles?
• ¿La capacidad instalada coincide con la efectiva en fallo?
• ¿Qué diferencia existe entre RPO y RTO?
• ¿Activo-activo elimina el punto único de base de datos?
• ¿NUMA es hiperconvergencia? No: describe acceso no uniforme a memoria compartida.
• ¿Tier y PUE miden lo mismo? No: topología de disponibilidad frente a eficiencia energética.

17.5. Mapa conceptual

17.6. Ideas esenciales