STPA: la nueva capacitación de Google SRE para prevenir incidentes

• STPA (System Theoretic Process Analysis, análisis de procesos teóricos de sistemas) es un método para modelar los bucles de control-retroalimentación de sistemas complejos con base en teoría de sistemas y de control
  • Google usa STPA para analizar sistemas de software y descubrir riesgos potenciales
• STPA trata la seguridad del sistema como un problema de control y analiza todas las acciones de control que podrían llevar al sistema a un estado peligroso
• En vez de centrarse en el resultado de acciones individuales, se enfoca en estados peligrosos para encontrar la causa raíz
  • Si se entienden las acciones de control que llevan a un estado peligroso, se puede prevenirlo o recuperar el sistema automáticamente
  • Si la recuperación automática es difícil, se puede alertar a operadores humanos

Por qué Google está personalizando la capacitación en STPA

• Han aumentado los casos exitosos en los que STPA permitió descubrir problemas no identificados con anticipación y prevenir incidentes
• El material de capacitación existente de STPA está enfocado en sistemas físicos, por lo que es difícil aplicarlo a entornos de software
• Se hizo necesaria una capacitación adaptada a los sistemas puramente de software de Google

Primeros intentos de capacitación en STPA

• La capacitación inicial comenzó en 2021 (para 40 ingenieros de Google)
• Se usaron casos de sistemas físicos (por ejemplo, la caída del Mars Polar Lander) → poca identificación por parte de ingenieros de software
• Se reconoció la necesidad de contar con casos reales aplicados a sistemas de Google

Enseñanza del concepto de estructura de control

• Una estructura de control (control structure) se compone de un bucle básico de control-retroalimentación
  • Un controlador gestiona cambios de estado → verifica el estado mediante retroalimentación y luego decide la siguiente acción
• Ejemplos de aplicación en entornos de software
  • Ejemplo: eliminar o corregir contenido incorrecto en una base de datos de contenido generado por usuarios
  • Si el bucle de retroalimentación no está bien diseñado, pueden producirse acciones de control incorrectas
• Retos en la capacitación
  • Es difícil enseñar a diseñar estructuras de control útiles en tiempo limitado
  • Como cada sistema de software tiene una estructura de control distinta, es difícil dar retroalimentación

Estrategia para mejorar la capacitación en STPA

• Enseñar todas las etapas de STPA → ayudar a que los ingenieros puedan ejecutar STPA de forma independiente
• Usar casos reales de Google → explicar la teoría y luego aplicarla a casos reales
• Enfocarse en reforzar las rutas de retroalimentación de la estructura de control
  • Retroalimentación incorrecta → acción de control incorrecta → análisis de casos que terminaron en incidentes
  • Falta de retroalimentación para operadores humanos → aparición de estados peligrosos

La importancia de la retroalimentación

• En un sistema de Google, una retroalimentación incorrecta provocó una acción de control errónea 30 días después → se produjo un incidente
• La causa fue una retroalimentación incorrecta y la falta de retroalimentación para operadores humanos
• Si el diseño de la retroalimentación se hace correctamente, es posible prevenir incidentes
• La explosión del cohete Ariane 5 también es un caso de error de retroalimentación
  • El error ocurrió al convertir datos de punto flotante a entero
  • Error de retroalimentación → percepción incorrecta del estado → error en la dirección del cohete y explosión

Diagrama de flujo de datos vs. estructura de control

• Diagrama de flujo de datos (Dataflow Diagram)
  • Muestra cómo se mueven los datos entre componentes de software
  • La retroalimentación y la estructura de control no quedan claras
• Estructura de control (Control Structure)
  • Muestra acciones de control y retroalimentación → deja clara la jerarquía de control
  • Facilita identificar problemas de retroalimentación → permite rastrear la causa del problema en interacciones complejas del sistema

Efectos de aplicar STPA

• En software complejo, reduce de millones de líneas de código a unos cientos las partes donde es más probable que ocurran problemas
• Convierte acciones de control peligrosas en escenarios → permite identificar el código problemático
• En casos reales, tras construir la estructura de control, se identificó y corrigió la falta de retroalimentación

Cambios en la estrategia de capacitación

• De capacitaciones largas a sesiones más cortas
  • Tutoriales de 30 a 60 minutos → motivan a ingenieros interesados a participar en talleres
• Introducción de un modelo de aprendizaje autodirigido
  • Videos cortos + tareas → impulsan la aplicación de STPA a sistemas reales
  • Se refuerza la formación para que puedan realizar STPA inicial sin intervención de expertos

Estrategia para expandir STPA dentro de Google

• Formar especialistas en STPA → permite difundir STPA dentro de los equipos
• Éxitos iniciales → expansión a otros equipos → aplicación de STPA en toda la organización
• Después de la capacitación en STPA, es posible eliminar factores de riesgo desde la etapa de diseño

También puede aplicarse en otras empresas

• STPA es una herramienta poderosa para encontrar "factores de riesgo no identificados" en sistemas de software complejos
• Puede comenzar en equipos pequeños y expandirse con especialistas en STPA al frente
• La clave es desarrollar una capacitación en STPA adaptada a cada empresa
• Tras una fase inicial de prueba y error, se puede corregir el rumbo → en última instancia, mejora la estabilidad y confiabilidad del sistema

[GN⁺]

Comentarios en Hacker News

• En Google hubo un caso en el que un controlador de software recibió retroalimentación incorrecta y ejecutó una acción de control peligrosa

  • Esta acción estaba programada para ejecutarse 30 días después
  • Había indicadores de que ocurriría una acción peligrosa, pero no había ingenieros monitoreándolos
  • Al final, 30 días después ocurrió la acción de control peligrosa y se produjo una caída del servicio
  • Hay comentarios preguntándose si este incidente fue el caso de la eliminación de una base de datos gubernamental
  • Está bien intentar generalizar sin culpar a nadie, pero estaba escrito con un estilo tan exagerado que no dejó mucho por aprender

• La clase de STPA estaba bien estructurada y el ejemplo de Google fue útil

  • Sin embargo, el artículo en sí no incluía ejemplos concretos

• STPA es un marco de revisión de diseño para encontrar modos de falla menos evidentes

  • FMEA es más popular, pero solo enumera modos de falla que ya se conocen
  • STPA ayuda a cubrir modos de falla en los que no se había pensado

• Hay opiniones que dicen que es difícil de entender, pero que igual quieren conocerlo

  • Hace falta una explicación concreta de cómo se aplica a un servicio específico en Google
  • Falta explicar por qué “B tiene retroalimentación insuficiente de C” es algo malo

• Habría sido más convincente si STPA hubiera tenido casos reales en Google donde resolvió problemas de confiabilidad

• STAMP/STPA funciona bien como modelo y metodología para sistemas complejos

  • Había interés en la cuantificación del riesgo cibernético
  • En otros enfoques no se ofrece un modelo que permita entender fácilmente las acciones de control peligrosas
  • Ojalá más empresas lo adoptaran

• Tras colaborar con expertos del sistema para construir la estructura de control, de inmediato quedó claro que faltaba retroalimentación de C hacia B

  • Hay un bucle de retroalimentación a través de D
  • Se preguntan por qué no aplica también el problema de no tener una conexión directa de B a D
  • Al releerlo, entendieron que la dirección vertical es importante para representar el control y la retroalimentación

• Es una historia corporativa inflada, llena de buzzwords, que intenta hacer ver ideas viejas como si fueran innovadoras

  • Hay un intento forzado de conectar una historia infantil sobre reparar radios con STPA
  • Google afirma que aplicar STPA al software es innovador, pero es un método antiguo
  • La mayor parte del contenido son conceptos básicos de ingeniería sobre bucles de retroalimentación y estructuras de control
  • El mensaje real es que Google creó un programa interno de capacitación
  • El final sigue la típica estrategia corporativa de insinuar que no se puede vivir sin usar STPA

• Hay comentarios diciendo que les gustaría que Google se quedara callado por un año, haciendo solo un ruido bajo como el de una aspiradora