Capítulo 1 — Sistemas informáticos | Tecnólogo Seguridad de infraestructuras críticas y sectores

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Mapa de la lección

Lección 01 publicada. Mapa, ejemplo, EX001.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["1.1 Un equipo como conjunto de recursos finitos"]
  N2["1.3 El margen de capacidad, y por qué «suficiente» n"]
  N3["1.4 Prever el agotamiento"]
  N4["1.5 Modos de fallo silenciosos"]
  N5["1.7 Actividad práctica: margen de capacidad"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX001"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["1.1 Un equipo como conjunto de recursos finitos"]
  N2["1.3 El margen de capacidad, y por qué «suficiente» n"]
  N3["1.4 Prever el agotamiento"]
  N4["1.5 Modos de fallo silenciosos"]
  N5["1.7 Actividad práctica: margen de capacidad"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX001"]

[Resultados de aprendizaje y conexión]
    |
    v
[1.1 Un equipo como conjunto de recursos finitos]
    |
    v
[1.3 El margen de capacidad, y por qué «suficiente» n]
    |
    v
[1.4 Prever el agotamiento]
    |
    v
[1.5 Modos de fallo silenciosos]
    |
    v
[1.7 Actividad práctica: margen de capacidad]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX001]

Resultados de aprendizaje y conexión

Al terminar este capítulo, usted debería ser capaz de:

describir un equipo en función de los cuatro recursos que realmente se le agotan a un operador (cómputo, memoria, almacenamiento y E/S) y del recurso que la gente olvida, el tiempo;
prever cuándo se agotará un recurso a partir de una serie corta de mediciones e indicar hasta qué punto puede confiarse en la previsión;
explicar por qué un equipo que presta una función esencial necesita margen de capacidad, y no solo «lo suficiente»;
reconocer las formas habituales en que un equipo falla en silencio y escribir las primeras comprobaciones que lo detectarían.

El curso de entrada le enseñó cómo funciona un ordenador. Este capítulo plantea una pregunta más estrecha que recorre todo el libro: ¿qué debe seguir siendo cierto en este ordenador para que el servicio que funciona sobre él siga funcionando, y cómo sabría usted que ha dejado de serlo? El equipo retransmisor de LANTERN, RLY-01, es la primera máquina que conocerá; en el capítulo 29 será una de tres.

1.1 Un equipo como conjunto de recursos finitos

Todo servicio que usted opera se ejecuta en un equipo con recursos finitos. El cómputo (tiempo de CPU) limita cuánto trabajo puede hacerse por segundo. La memoria limita cuánto puede mantenerse a la vez; cuando se agota, el sistema operativo o bien pagina a disco (y todo se ralentiza) o bien termina procesos. El almacenamiento limita lo que puede conservarse; cuando un disco se llena, las escrituras fallan, y muchos programas fallan mal: una base de datos puede dejar de aceptar escrituras, un demonio de registro puede descartar mensajes en silencio, un retransmisor puede caerse. La E/S (el rendimiento del disco y de la red) limita la rapidez con que los datos pueden entrar y salir.

El recurso que la gente olvida es el tiempo: el reloj del equipo. Un reloj erróneo no detiene un servicio, pero hace que sus registros discrepen de los de todos los demás, rompe la validación de certificados y las comprobaciones de ventanas temporales, y hace que las investigaciones resulten engañosas. Los capítulos 17 y 20 vuelven con detalle sobre el tiempo.

Para un servicio crítico, la pregunta útil sobre cada recurso no es «¿cuánto se usa?», sino «¿cuánto falta para que este recurso detenga el servicio, y con cuánta antelación nos avisaremos?».

1.2 Utilización, saturación y errores

Una forma práctica de examinar cualquier recurso es preguntarse tres cosas sobre él: su utilización (lo ocupado que está, como fracción de su capacidad), su saturación (cuánto trabajo espera porque está ocupado: una cola de ejecución, una cola de disco, paquetes descartados) y sus errores (operaciones fallidas). Una CPU al 60 % de utilización sin cola está bien; un disco al 40 % de utilización con una cola larga, no. La utilización por sí sola oculta el problema que perciben los usuarios, que es la espera.

De ello se derivan dos hábitos. Primero, mida en un percentil, no en una media: el percentil 95 de la CPU a lo largo de un día le informa de los momentos de mayor actividad, que son los que importan; la media diaria los oculta. Segundo, mida durante un periodo lo bastante largo como para ver el ritmo del servicio. Los retransmisores de telemetría están más ocupados cuando se ejecutan los informes y cuando las estaciones suben datos por lotes tras un corte de red; los sistemas hospitalarios alcanzan su máximo en los cambios de turno; los sistemas de transporte, en la hora punta.

1.3 El margen de capacidad, y por qué «suficiente» no basta

El margen de capacidad es la capacidad sobrante entre la carga máxima normal y el punto en que el servicio se degrada. Un servicio esencial necesita margen por tres razones: la demanda crece de forma inesperada (una tormenta, un suceso con víctimas en masa, un corte en otro lugar que le envía tráfico); la propia recuperación consume recursos (las estaciones que estaban desconectadas suben su acumulado cuando vuelven; una restauración escribe intensamente en disco); y las herramientas de seguridad consumen recursos (un escaneo, una comprobación de integridad o una actualización del antivirus pueden duplicar el uso de CPU durante minutos). Un equipo dimensionado para tener «justo lo suficiente» en un día normal está dimensionado para fallar el día en que más importa.

1.4 Prever el agotamiento

En los recursos que crecen de forma constante (el disco que se llena con registros y datos es el caso clásico), un ajuste lineal sobre las mediciones diarias recientes da una previsión utilizable: el crecimiento por día y los días que faltan hasta un umbral de alarma y hasta llenarse. Es una previsión, no una promesa. Supone que el crecimiento continúa al ritmo reciente. Será errónea si cambia la conservación, si un proceso ruidoso empieza a registrar en nivel de depuración o si a un corte le sigue una ráfaga de datos acumulados. Úsela para programar acciones mucho antes del umbral, y vuelva a calcularla tras cualquier cambio.

Un cálculo complementario útil es el tamaño en régimen estacionario: si los datos se conservan durante R días y llegan a razón de g GB al día, el volumen conservado se estabiliza en torno a g × R. Si esa cifra supera el disco, ninguna «limpieza» salvará al equipo; tiene que cambiar la conservación, el volumen o la capacidad.

1.5 Modos de fallo silenciosos

Los equipos de los servicios que funcionan durante mucho tiempo tienden a fallar de un pequeño número de formas silenciosas: se llena un disco o una partición; un trabajo de rotación de registros se detiene y un archivo crece sin límite; caduca un certificado; el reloj se desvía después de que su fuente de hora deje de ser accesible; un proceso pierde memoria y el gestor del sistema lo reinicia cada pocos días, con lo que se pierden los datos en tránsito; un trabajo programado (copia de seguridad, informe) falla y nadie lee su correo. Cada uno de ellos puede detectarse con una comprobación que no cuesta casi nada, siempre que alguien escriba la comprobación y alguien lea su resultado. El capítulo 19 convierte esas comprobaciones en monitorización.

1.6 Ejemplo resuelto: el disco de RLY-01 (sintético)

E. Strand le pregunta si RLY-01, que almacena temporalmente la telemetría de las estaciones y conserva sus propios registros durante 30 días, necesita un disco más grande antes del invierno. Usted recoge 14 días de uso del disco (disco de 200 GB) y el percentil 95 diario de la CPU. El disco crece unos 1,9 GB al día y está en 120,9 GB. La alarma de operaciones salta al 85 % (170 GB). A este ritmo, la alarma saltará en unos 26 días y el disco estará lleno en unos 41 días. Con una conservación de 30 días, el volumen de registros en régimen estacionario es de unos 57 GB, pero el disco ya está muy por encima de esa cifra, lo que indica que el crecimiento no se debe solo a los registros dentro del plazo de conservación. Algo conserva datos durante más de 30 días. Es una cuestión de configuración, no de capacidad, y debe responderse antes de comprar un disco.

La serie de la CPU muestra una pauta semanal: los días 6 y 7 de cada semana funcionan en torno al 62 %, frente a alrededor del 42 % los demás días. Usted pregunta a operaciones de Water y se entera de que esos días se ejecutan los informes semanales de cumplimiento. Es una carga normal, pero es la carga para la que hay que dimensionar.

1.7 Actividad práctica: margen de capacidad

Ejecute el Lab 1. Ajusta una recta a la serie del disco, informa de los días que faltan hasta la alarma y hasta llenarse, del volumen de registros en régimen estacionario con una conservación de 30 días, y compara la CPU de los días de informes con la de los demás días. Lab 1 (guárdelo como lab01.py y ejecútelo con python3 lab01.py):

# Lab 1 - capacity headroom for the relay host (offline, standard library only)
# Synthetic: Fallowmere relay host RLY-01. Daily samples over 14 days.
disk_total_gb = 200.0
disk_used_gb = [96.0, 97.9, 99.7, 101.8, 103.6, 105.5, 107.6, 109.4, 111.3, 113.2, 115.1, 117.0, 118.8, 120.9]
cpu_p95 = [41, 43, 40, 44, 42, 61, 63, 42, 41, 44, 43, 40, 62, 64]  # percent, 95th percentile per day
alarm_at = 0.85  # operations alarm when disk reaches 85 % full

n = len(disk_used_gb)
xs = list(range(n))
mx, my = sum(xs) / n, sum(disk_used_gb) / n
slope = sum((x - mx) * (y - my) for x, y in zip(xs, disk_used_gb)) / sum((x - mx) ** 2 for x in xs)
print(f"growth: {slope:.2f} GB/day")
for limit, label in ((alarm_at * disk_total_gb, "85% alarm"), (disk_total_gb, "full")):
    days = (limit - disk_used_gb[-1]) / slope
    print(f"days until {label}: {days:.1f}")
# retention: logs kept 30 days; growth comes from logs (synthetic assumption)
print(f"steady-state log volume at 30-day retention: {slope*30:.1f} GB")
weekly = [cpu_p95[i] for i in range(n) if i % 7 in (5, 6)]
weekday = [cpu_p95[i] for i in range(n) if i % 7 not in (5, 6)]
print(f"cpu p95 mean weekday {sum(weekday)/len(weekday):.1f}% vs days 6-7 of each week {sum(weekly)/len(weekly):.1f}%")

Salida esperada (Python 3.13.5):

growth: 1.91 GB/day
days until 85% alarm: 25.7
days until full: 41.4
steady-state log volume at 30-day retention: 57.3 GB
cpu p95 mean weekday 42.0% vs days 6-7 of each week 62.5%

Anote las cuatro cifras en su nota de trabajo como observado; después, escriba una frase inferida y un elemento abierto. Un buen elemento abierto nombra una pregunta y un titular: «¿Por qué conserva RLY-01 más de 30 días de datos? — E. Strand, antes del viernes».

1.8 Errores comunes y límites

Informar de la CPU media y concluir que hay margen, cuando el máximo (el momento que importa) está cerca de la saturación.
Tratar una previsión lineal como una garantía; supone que el futuro se parecerá a las dos últimas semanas.
Resolver un fallo de conservación o de registro comprando capacidad, lo que oculta el fallo hasta que se llena el disco nuevo.
Olvidar que la recuperación y la actividad de seguridad consumen recursos.
Fijar una alarma en un umbral que deja menos tiempo de aviso del que se tarda en adquirir, aprobar e instalar más capacidad.
Ignorar el reloj porque «solo es la hora».

Catorce muestras son una base pequeña para cualquier previsión. El valor del método es que convierte una impresión («parece que el disco se está llenando») en una cifra con un supuesto explícito que alguien puede comprobar.

Ejercicios — capítulo 1

EX001 — Plazo de suministro frente a tiempo de aviso. Objetivo: fijar un umbral de alarma a partir del plazo operativo de suministro. Entradas: la salida del Lab 1; la adquisición e instalación aprobada de un disco nuevo tarda 21 días laborables (unos 30 días naturales). Restricciones: mantenga el mismo ritmo de crecimiento. Pasos: (1) calcule el nivel de llenado en el que debe presentar la solicitud para que el disco se instale antes de llenarse, con 7 días de margen; (2) expréselo como porcentaje del disco; (3) indique si la alarma del 85 % es adecuada. Evidencia esperada: cálculo y una recomendación de dos frases. Rúbrica: 3 = umbral correcto (se necesitan 37 días × 1,91 GB ≈ 71 GB de espacio libre, es decir, presentar la solicitud a unos 129 GB o al 65 %, que RLY-01 alcanza en unos cuatro días) y un juicio claro de que el 85 % es demasiado tarde para este plazo de suministro; 2 = método correcto, error aritmético; 1 = umbral elegido sin tener en cuenta el plazo de suministro; 0 = nada.

EX002 — Explique el crecimiento. Objetivo: separar un problema de capacidad de un problema de configuración. Entradas: el ejemplo resuelto. Restricciones: no toque ningún sistema real; razone a partir de las cifras. Pasos: (1) calcule cuántos días de datos a 1,91 GB/día representan los 120,9 GB actuales; (2) indique dos causas de configuración plausibles; (3) describa la comprobación que permitiría distinguirlas. Evidencia esperada: nota breve con las etiquetas observado / inferido / abierto. Rúbrica: 3 = unos 63 días calculados, dos causas concretas (por ejemplo, la rotación no borra, no se purga el búfer de un destino desconectado o un segundo flujo de registros queda fuera de la política de conservación) y una comprobación para cada una; 2 = causas genéricas; 1 = recomienda solo un disco más grande; 0 = nada.

EX003 — Lista de comprobación de fallos silenciosos. Objetivo: convertir los modos de fallo silenciosos en comprobaciones. Entradas: el capítulo 1 («Modos de fallo silenciosos»). Restricciones: cinco comprobaciones; cada una debe nombrar lo que se mide, el umbral y quién lee el resultado. Pasos: escriba una tabla con las columnas: modo de fallo, medición, umbral, lector, acción. Evidencia esperada: tabla. Rúbrica: 3 = cinco modos de fallo distintos, umbrales medibles con tiempo de aviso, un lector designado y una acción para cada uno; 2 = una columna débil; 1 = un genérico «monitorizar el servidor»; 0 = nada.

Síntesis del capítulo

Un equipo es un conjunto de recursos finitos más un reloj. Para un servicio esencial, la pregunta sobre cada recurso es cuánto falta para que detenga el servicio y con cuánta antelación se le avisará. Mida la utilización, la saturación y los errores en percentiles a lo largo del ritmo natural del servicio; mantenga margen para los días malos, la recuperación y el trabajo de seguridad; prevea el agotamiento con supuestos explícitos; y escriba comprobaciones baratas para los fallos silenciosos que de verdad hacen caer los servicios. Cuando las cifras no coincidan con lo esperado, como ocurrió con el disco de RLY-01, busque una causa de configuración antes de comprar capacidad.