Capítulo 27 — Despliegue y validación
Mapa de la lección
Lección 27 publicada. Mapa, ejemplo, EX079.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["27.1 Comprobaciones previas"]
N2["27.2 Canarios y criterios de promoción"]
N3["27.3 Validación después del despliegue"]
N4["27.4 Lo que la ventana no puede mostrar"]
N5["27.6 Actividad práctica: decisión sobre el canario"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX079"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["27.1 Comprobaciones previas"]
N2["27.2 Canarios y criterios de promoción"]
N3["27.3 Validación después del despliegue"]
N4["27.4 Lo que la ventana no puede mostrar"]
N5["27.6 Actividad práctica: decisión sobre el canario"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX079"]
[Resultados de aprendizaje y conexión]
|
v
[27.1 Comprobaciones previas]
|
v
[27.2 Canarios y criterios de promoción]
|
v
[27.3 Validación después del despliegue]
|
v
[27.4 Lo que la ventana no puede mostrar]
|
v
[27.6 Actividad práctica: decisión sobre el canario]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX079]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- preparar un despliegue con comprobaciones previas, incluida la verificación de lo que se va a desplegar;
- desplegar por etapas con un canario y criterios explícitos de promoción y de reversión;
- validar después del despliegue frente a las propiedades funcionales y de seguridad del servicio;
- indicar lo que una ventana de validación puede y no puede mostrar.
El capítulo 14 planificó los cambios; el capítulo 22 automatizó la configuración. Este capítulo trata de los despliegues de software (una nueva versión del retransmisor, una actualización del historiador), en los que el cambio es mayor y más difícil de prever. En los servicios críticos, el objetivo es encontrar un problema en un solo equipo, en un momento tranquilo y con una reversión preparada, y no en todos los equipos en el pico de la mañana.
27.1 Comprobaciones previas
Antes de desplegar: el cambio está aprobado; operaciones conoce la ventana; se ha hecho una copia de seguridad de la configuración y el paquete de reversión está preparado; y el propio paquete está verificado: su firma o su resumen publicado se han comprobado con los del proveedor, de modo que lo que instala es lo que el proveedor publicó. Las guías de desarrollo seguro piden a los productores que protejan la integridad del software publicado, por ejemplo con firmas (NIST SP 800-218); como implementador, su parte consiste en comprobarlas y en tratar un paquete no verificable como un hallazgo.
27.2 Canarios y criterios de promoción
Un despliegue canario instala la nueva versión primero en un equipo y lo compara con los equipos que siguen en la versión antigua, durante el mismo periodo y con la misma carga. El manual práctico de SRE de Google describe el despliegue canario como un despliegue parcial y limitado en el tiempo que se evalúa frente a una población de control antes de un despliegue más amplio (Google SRE workbook, Canarying releases). Redacte los criterios de promoción antes de desplegar: para LANTERN, una proporción de aceptación no más de 0,2 puntos porcentuales por debajo del control; una latencia p95 no más de un 25 % por encima del control; ningún reinicio; rechazos por MAC sin cambios. Si falla cualquier criterio, revierta el canario y abra un registro de problema. Si se cumplen todos, promocione un equipo cada vez.
27.3 Validación después del despliegue
Después de actualizar cada equipo, valide: las propiedades funcionales (todas las estaciones aceptadas, latencia normal, el historiador recibe); las propiedades de seguridad (las comprobaciones del MAC siguen aplicándose: inyecte un mensaje de prueba con un MAC erróneo; los servicios a la escucha no han cambiado: ejecute la comprobación de deriva; los registros siguen reenviándose y analizándose: revise los recuentos del normalizador); y las propiedades operativas (las alertas siguen evaluándose; el informe de salud está en verde). Las regresiones de seguridad son fáciles de pasar por alto, porque un servicio puede funcionar perfectamente mientras una comprobación se ha deshabilitado en silencio.
En RLY-03, la comprobación de deriva tras la 2.4.1 seguía mostrando el servicio de depuración a la escucha: la función superó la validación, una propiedad de seguridad no.
27.4 Lo que la ventana no puede mostrar
Un canario nocturno de una hora muestra el comportamiento con la carga nocturna durante una hora. No dice nada del pico de demanda de la mañana, de las ejecuciones semanales del informe (capítulo 1), de los informes de cierre de mes ni de los tipos de mensaje poco frecuentes. Amplíe la ventana a los periodos que importan o declare la carencia y vigile de cerca esos periodos tras la promoción. El canario de relayd 2.4.1 se ejecutó durante una hora nocturna, así que su caída de 0,0010 en la proporción de aceptación se registró como elemento abierto para el pico de la mañana.
Las ejecuciones semanales del informe los días 6 y 7, con alrededor del 62 % de CPU, son otro periodo que una hora nocturna no puede mostrar.
27.5 Ejemplo resuelto: relayd 2.4.1 (sintético)
Las comprobaciones previas se superan: cambio aprobado, sala de control informada, copia de la configuración hecha, paquete de reversión preparado, firma del paquete verificada. El canario RLY-03 ejecuta la 2.4.1 durante una hora frente a RLY-01 con la 2.4.0. Proporción de aceptación de 0,9985 frente a 0,9994 (una caída de 0,0010, dentro de 0,002); latencia p95 de 41 ms frente a 37 ms (dentro del 25 %); ningún reinicio; rechazos por MAC sin cambios. Decisión: promocionar a RLY-02 y después a RLY-01. La validación posterior al despliegue en RLY-03 inyecta un mensaje de prueba con un MAC erróneo (rechazado, como se esperaba) y ejecuta la comprobación de deriva, que sigue mostrando el servicio de depuración a la escucha del capítulo 22, un recordatorio de que el despliegue no corrigió la deriva de configuración y no debe presentarse como si lo hubiera hecho. La caída de la proporción de aceptación, aunque está dentro de los criterios, se registra como elemento abierto que hay que comprobar en el pico de la mañana.
27.6 Actividad práctica: decisión sobre el canario
Lab 27 (guárdelo como lab27.py y ejecútelo con python3 lab27.py):
# Lab 27 - pre- and post-deployment validation with a canary and a rollback rule (offline, standard library only)
# Synthetic: relayd 2.4.1 rolled to rly-03 first (canary), compared with rly-01 still on 2.4.0 for one hour.
checks_pre = {"backup of config taken": True, "rollback package staged": True, "change ticket approved": True,
"operations told (control room)": True, "maintenance window open": True, "signature of package verified": True}
canary = {"msgs_in": 7200, "msgs_accepted": 7189, "mac_rejects": 0, "p95_latency_ms": 41, "cpu_p95": 38, "restarts": 0}
control = {"msgs_in": 7200, "msgs_accepted": 7196, "mac_rejects": 0, "p95_latency_ms": 37, "cpu_p95": 36, "restarts": 0}
limits = {"accept_ratio_drop": 0.002, "latency_ratio": 1.25, "restarts": 0}
print("pre-checks:", "PASS" if all(checks_pre.values()) else "FAIL " + str([k for k, v in checks_pre.items() if not v]))
ra, rc = canary["msgs_accepted"] / canary["msgs_in"], control["msgs_accepted"] / control["msgs_in"]
results = {
"acceptance ratio": (rc - ra <= limits["accept_ratio_drop"], f"{ra:.4f} vs {rc:.4f} (drop {rc-ra:.4f})"),
"p95 latency": (canary["p95_latency_ms"] <= control["p95_latency_ms"] * limits["latency_ratio"], f"{canary['p95_latency_ms']} vs {control['p95_latency_ms']} ms"),
"restarts": (canary["restarts"] <= limits["restarts"], str(canary["restarts"])),
"MAC rejects unchanged": (canary["mac_rejects"] == control["mac_rejects"], str(canary["mac_rejects"])),
}
for k, (ok, detail) in results.items(): print(f" {k:<22} {'pass' if ok else 'FAIL'} {detail}")
print("decision:", "promote to rly-02, then rly-01" if all(ok for ok, _ in results.values()) else "ROLL BACK canary and open problem record")
# What the canary cannot show: a 1-hour window at night says nothing about the morning demand peak or month-end reports.
Salida esperada (Python 3.13.5):
pre-checks: PASS
acceptance ratio pass 0.9985 vs 0.9994 (drop 0.0010)
p95 latency pass 41 vs 37 ms
restarts pass 0
MAC rejects unchanged pass 0
decision: promote to rly-02, then rly-01
Compruebe cada línea frente a los criterios fijados antes de la ventana: proporción de aceptación de 0,9985 frente a 0,9994, una caída de 0,0010 dentro del 0,002 permitido; latencia p95 de 41 ms frente a 37 ms, dentro del 25 %; ningún reinicio; rechazos por MAC sin cambios. Todos se cumplen, así que la decisión es promocionar a RLY-02 y después a RLY-01, un equipo cada vez. La caída, aunque está dentro de los criterios, permanece en la lista de elementos abiertos para el pico de la mañana.
Si la caída hubiera sido de 0,0025, la regla fijada de antemano habría exigido la reversión, por pequeña que pareciera la diferencia.
27.7 Errores frecuentes y límites
- Instalar paquetes sin verificar su origen.
- Criterios de promoción decididos después de ver los resultados del canario.
- Validar la función, pero no las propiedades de seguridad.
- Una ventana del canario que no abarca los periodos de carga real.
- Promocionar todos los equipos restantes a la vez después del canario.
- Una reversión que nunca se probó.
El despliegue de relayd 2.4.1 evitó todos ellos: firma verificada, criterios fijados antes del canario, un mensaje con MAC erróneo inyectado después y promoción de un equipo cada vez.
El elemento abierto para el pico de la mañana es la forma de tratar el cuarto cuando la ventana no puede ser más larga.
Ejercicios — capítulo 27
EX079 — Haga fallar el canario. Objetivo: aplicar la regla de reversión. Entradas: el Lab 27. Restricciones: cambie solo los números del canario. Pasos: (1) fije en 7170 el recuento de mensajes aceptados del canario; (2) ejecútelo; (3) indique la decisión y las tres primeras acciones. Evidencia esperada: salida y acciones. Rúbrica: 3 = la caída de la aceptación ≈ 0,0036 no cumple el criterio de 0,002, decisión de revertir; acciones: revertir el canario con el cambio, conservar los registros del canario y los motivos de rechazo, abrir un registro de problema e informar a la sala de control; 2 = decisión correcta, acciones escasas; 1 = no ejecutado; 0 = nada.
EX080 — Conjunto de validación de seguridad. Objetivo: especificar las comprobaciones de seguridad posteriores al despliegue. Entradas: el capítulo 27 («Validación después del despliegue»). Restricciones: cinco comprobaciones, cada una con su resultado esperado. Pasos: enumérelas. Evidencia esperada: tabla. Rúbrica: 3 = prueba con MAC erróneo rechazada, prueba de reproducción rechazada, la comprobación de deriva no muestra servicios nuevos a la escucha, recuento de líneas no analizadas del normalizador sin cambios, el servicio se ejecuta con una cuenta sin privilegios, la prueba de alerta sigue saltando; 2 = cuatro; 1 = solo función; 0 = nada.
EX081 — Amplíe la ventana. Objetivo: diseñar una ventana del canario que cubra la carga real. Entradas: ejecuciones semanales del informe los días 6 y 7 (capítulo 1), pico de la mañana de 06:00 a 09:00. Restricciones: el cambio debe completarse en diez días. Pasos: proponga la ventana o ventanas, los puntos de promoción y los criterios comprobados en cada uno. Evidencia esperada: calendario. Rúbrica: 3 = canario a lo largo de al menos un pico de la mañana y una ejecución del informe antes de la promoción, con los criterios evaluados en cada uno, y después promoción escalonada dentro de los diez días; indica que la reversión está preparada en todo momento; 2 = cubre uno; 1 = mantiene la ventana de una hora; 0 = nada.
Síntesis del capítulo
Despliegue por etapas. Compruebe de antemano las aprobaciones, a operaciones, las copias de seguridad, la reversión y el origen del paquete. Use un canario en un equipo frente a un control, con criterios de promoción fijados de antemano; revierta ante cualquier fallo y, si todo va bien, promocione un equipo cada vez. Valide las propiedades funcionales, de seguridad y operativas después de cada equipo, y declare con honestidad lo que la ventana de validación no pudo mostrar.
Siga estudiando — capítulo 27 de 30
← Capítulo 26 · Índice de capítulos del curso · Capítulo 28 →
Continúe con la siguiente lección escrita.