Capítulo 47 — Ensayo de fallo y recuperación
Mapa de la lección
Lección 47 publicada. Mapa, ejemplo, EX139.
flowchart TD
N0["Resultados de aprendizaje"]
N1["47.1 Propósito"]
N2["47.2 Planificación"]
N3["47.3 Métricas"]
N4["47.4 Revisión posterior a la acción"]
N5["47.6b Compartir lo que enseñó el ensayo"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX139"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["47.1 Propósito"]
N2["47.2 Planificación"]
N3["47.3 Métricas"]
N4["47.4 Revisión posterior a la acción"]
N5["47.6b Compartir lo que enseñó el ensayo"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX139"]
[Resultados de aprendizaje]
|
v
[47.1 Propósito]
|
v
[47.2 Planificación]
|
v
[47.3 Métricas]
|
v
[47.4 Revisión posterior a la acción]
|
v
[47.6b Compartir lo que enseñó el ensayo]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX139]
Resultados de aprendizaje
Usted será capaz de (1) planificar y ejecutar un ensayo controlado de fallo y recuperación de un sistema de IA; (2) inyectar fallos y ataques en un entorno seguro; (3) medir los tiempos de detección, contención y recuperación; y (4) mejorar los manuales de operación y el diseño a partir de la evidencia del ensayo.
47.1 Propósito
Un plan de recuperación que nunca se ha ejercitado es una hipótesis. Un ensayo comprueba si las personas, las herramientas y los procedimientos detectan fallos y ataques realistas, los contienen y se recuperan de ellos dentro de los tiempos objetivo. Los planes dan por supuestas cosas que pueden no cumplirse bajo presión: que el ingeniero de guardia encuentre el manual de operación, que las credenciales puedan revocarse con rapidez, que haya disponible una versión limpia del modelo. Un ensayo comprueba esas suposiciones con personas y herramientas reales en un entorno seguro. Los fallos encontrados en un ensayo cuestan una tarde; los mismos fallos encontrados en un incidente cuestan mucho más, y los tiempos del ensayo se convierten en la evidencia de que los objetivos de recuperación son realistas.
47.2 Planificación
Defina los escenarios (por ejemplo: se descubre un lote de entrenamiento envenenado; un documento inyectado provoca propuestas de herramientas; un modelo firmado no supera la verificación en el despliegue; el servicio de monitorización cae durante un intento de extracción), los objetivos, las normas de seguridad, los observadores, los criterios de éxito y una condición de parada. Ejecútelo en un entorno de preproducción con datos sintéticos. Informe a los participantes del periodo del ejercicio, pero no de los detalles de los escenarios, para que la detección sea realista.
Ocultar a los participantes los detalles de los escenarios da sentido a los tiempos de detección. Una condición de parada, como cualquier indicio de impacto fuera de preproducción, termina el ensayo de inmediato y se acuerda de antemano con los propietarios de los sistemas.
47.3 Métricas
Tiempo hasta la detección, tiempo hasta la contención, tiempo hasta la recuperación, corrección de las acciones, calidad de la comunicación y pérdida de datos. Compárelos con los objetivos de los requisitos (por ejemplo, contener el mal uso de herramientas en 15 minutos). Los tiempos se toman de los registros y no de la memoria, para que puedan comprobarse. La corrección de las acciones pregunta si quienes respondieron hicieron lo correcto, no solo algo rápido: revocar la credencial correcta importa más que revocar deprisa cualquier credencial. La calidad de la comunicación abarca si se dijo a tiempo a los directivos y a los usuarios afectados lo que necesitaban saber, lo que los observadores evalúan con una lista de comprobación acordada.
47.4 Revisión posterior a la acción
En el plazo de una semana, celebre una revisión sin culpables: qué ocurrió, qué funcionó, qué no y acciones con responsables. Actualice los manuales de operación, la monitorización y el diseño. Sin culpables no significa sin rendición de cuentas: las acciones tienen responsables y fechas, y el ensayo siguiente comprueba si se realizaron. La atención se centra en las condiciones que hicieron probables los errores, como un paso confuso del manual de operación o una alerta que faltaba, porque corregirlas ayuda a quien esté de guardia la próxima vez. Un resumen escrito breve mantiene disponibles las lecciones cuando las personas implicadas ya se han ido.
47.5 Ejemplo resuelto (caso sintético de NRS)
El equipo de Sam ejecutó tres escenarios sobre Bulletin Gate y Wrench en preproducción. El escenario A (boletín inyectado) se detectó en 6 minutos gracias a la señal del clasificador y se contuvo en 11 revocando la credencial de órdenes de trabajo de Wrench. El escenario B (actualización envenenada del modelo de extracción) se bloqueó en el despliegue mediante la verificación del manifiesto en menos de 1 minuto. El escenario C (caída de la monitorización más extracción masiva) solo se detectó al cabo de 52 minutos, cuando se recuperó la monitorización, con lo que no se cumplió el objetivo de 30 minutos. La corrección añadió una alerta de «falta el latido de la monitorización» y una limitación de frecuencia predeterminada cuando la monitorización está caída.
47.6 Errores y límites
- Ensayos que solo prueban la tecnología, no las personas ni los procedimientos.
- Revisiones centradas en buscar culpables, que desincentivan la notificación.
- Ningún seguimiento de las acciones.
Un ensayo que solo prueba si el software conmuta ante un fallo pasa por alto la llamada telefónica lenta, el manual de operación confuso y el ingeniero que no encuentra una contraseña. Las revisiones que buscan a quién culpar enseñan a la gente a ocultar los problemas, lo que hace más difícil detectar el siguiente incidente. Las acciones sin seguimiento hacen que las mismas lagunas aparezcan en el ensayo del año siguiente; la alerta de latido del escenario C se comprobó en el siguiente ensayo antes de aceptar ningún otro resultado.
47.6b Compartir lo que enseñó el ensayo
El resumen posterior a la acción va más allá del equipo de IA y llega a los responsables de mantenimiento ferroviario que dependen de TrackEye y Wrench: qué falló, cuánto tardó la recuperación, qué cambia y cuándo. Para ellos, el lenguaje llano y las fechas importan más que las métricas. En el ensayo de Sam, la versión para los responsables decía tres cosas. Un boletín malicioso se detectó en 6 minutos y el acceso de Wrench a las órdenes de trabajo se cortó en 11. Una actualización defectuosa del modelo se bloqueó antes de entrar en servicio. Cuando cayó la propia monitorización, un intento de extracción masiva pasó inadvertido durante 52 minutos; a partir de la siguiente versión, Wrench y TrackEye se ralentizan automáticamente cuando la monitorización está caída, así que un responsable de mantenimiento ferroviario puede notar respuestas más lentas durante una caída así.
Ejercicios — capítulo 47
- EX139 — Escenario. Redacte un escenario de ensayo con objetivo, método de inyección, detección esperada y criterio de éxito. Rúbrica: 3 = los cuatro, de forma segura; 2 = tres; 1 = vago; 0 = nada.
- EX140 — Métricas. ¿Qué métrica no se cumplió en el escenario C y qué principio de diseño ilustra la corrección? Rúbrica: 3 = tiempo hasta la detección (52 > 30 min); valor predeterminado a prueba de fallos cuando la monitorización está caída; 2 = una parte; 1 = vago; 0 = incorrecto.
- EX141 — Revisión posterior. Enumere cuatro productos de una revisión posterior a la acción. Rúbrica: 3 = cronología, qué funcionó, lagunas, acciones con responsable y fecha; 2 = tres; 1 = uno o dos; 0 = ninguno.
Síntesis del capítulo
Los ensayos de fallo y recuperación convierten los planes de recuperación en evidencia. Los tiempos medidos de detección, contención y recuperación impulsan mejoras concretas.
Siga estudiando — capítulo 47 de 50
← Capítulo 46 (borrador) · Índice de capítulos del curso · Capítulo 48 (borrador) →