La evolución de SRE en Google

• Los productos de Google los usan miles de millones de personas en todo el mundo, y es importante que funcionen de forma confiable. El equipo de SRE de Google ha desarrollado diversas formas de elevar la confiabilidad de sus servicios
• Las técnicas SRE existentes (error budget, postmortems, etc.) han contribuido enormemente a que Google escalará sus servicios web a gran escala
• Con la expansión reciente de AI/ML, la complejidad del sistema ha aumentado mucho, por lo que se necesita un nuevo enfoque
• La teoría de sistemas y la teoría de control son útiles para identificar de forma sistemática las interacciones complejas
• Es imprescindible pasar de un enfoque de “resolver después de que ocurre el problema” a uno que asegure la seguridad desde el diseño fundamental a nivel de sistema

Resumen de STAMP

• El enfoque STAMP (System-Theoretic Accident Model and Processes), propuesto por la profesora Nancy Leveson del MIT, analiza accidentes (incidentes) desde una perspectiva de interacción del sistema más compleja que la falla de una sola pieza
• En lugar de la causalidad tradicional (“hay un bug y por eso falla”), pone el foco en “en qué flujo de control incorrecto entró todo el sistema”
• Reconstruye accidentes con el Causal Analysis based on Systems Theory (CAST) y detecta factores de riesgo por adelantado con el System-Theoretic Process Analysis (STPA)

Base de la teoría de control: cuatro condiciones

• La teoría de control requiere cuatro condiciones para un control efectivo
  • Condición de objetivo: debe existir un objetivo (por ejemplo, mantener un indicador específico)
  • Condición de acción: debe haber capacidad de influir en el estado del sistema para lograr el objetivo
  • Condición de modelo: se necesita un modelo (interno y externo) para entender el sistema
  • Condición de observabilidad: se requiere un sistema de observación como sensores para identificar el estado actual del sistema

Tratar la interrupción (Outage) como un problema de control

• Antes había una fuerte tendencia a explicar un incidente como una “cadena de fallas”
• STAMP lo interpreta desde la perspectiva de “control e interacciones inadecuadas”, logrando seguridad a nivel sistémico
• En vez de buscar únicamente “dónde comenzó la primera falla”, evalúa integralmente “qué flujo de control/retroalimentación funcionó de forma anómala”

Ganar tiempo desde el estado de riesgo (Hazard)

• El modelo causal tradicional pasa de estado normal a estado de incidente de inmediato, por lo que el tiempo de respuesta es muy corto
• STAMP introduce el concepto de “estado de hazard” para encontrar el punto en que se ingresa a riesgo antes de un incidente completo
• Al detectar un estado de hazard e intervenir de manera proactiva, surge la oportunidad de prevenir antes de que se convierta en un incidente real

Visto a través de un caso real

• El “Rightsizer de cuotas” interno de Google reasigna recursos según el uso del servicio
• Desde la perspectiva STPA, es posible identificar de antemano una situación donde, al recibir datos de uso incorrectos, se reduce la cantidad de recursos por debajo de lo realmente necesario
• En la fase de diseño, se centraba sobre todo en una “lógica de control precisa”, pero al aplicar STPA se detectó un problema en la ruta de retroalimentación (en el cálculo del uso de recursos, entre otros)
• En 2021 hubo un caso real en el que una retroalimentación incorrecta acumulada derivó en un gran problema, y durante varias semanas estuvo en estado de hazard sin detectarlo

Direcciones futuras

• El SRE de Google persigue mayor seguridad y gestión de complejidad con enfoques basados en teoría de sistemas como STAMP, STPA y CAST
• Incluso con una inversión de ingeniería de pequeña escala (del orden de algunas semanas), se detectan numerosos escenarios potenciales de riesgo en sistemas de gran escala
• Si además del enfoque de confiabilidad existente se incorpora análisis basado en la teoría de control, aumenta la posibilidad de brindar servicios estables también en la era AI/ML

[GN⁺]

Comentario de Hacker News

• El enfoque de ingeniería de Google puede ser perjudicial para una startup. Los SRE tienden a caer en el síndrome del protagonista y a querer rehacer el diseño técnico de otros equipos.

  • Es parecido al fenómeno de un equipo legal intentando dirigir la empresa.

• Tiene similitudes con el libro de Sidney Dekker.

  • Evalúa todo el sistema y analiza por qué los participantes del incidente pensaban que habían tomado la decisión correcta.
  • Explica cómo cambios independientes en sistemas complejos pueden afectar la seguridad.

• El enfoque CAST se ve muy atractivo.

  • Requiere mucho análisis de fallos y de fallos cercanos, y la parte más difícil de implementarlo suele ser la gente.

• Hay una similitud interesante entre CAST y el trabajo de análisis mecánico.

  • Proporciona un marco para analizar cómo interactúan entre sí los componentes del sistema.

• Me pregunto si existen casos de aplicar un marco formal de ingeniería de seguridad al análisis de redes neuronales.

  • Podría ser útil para rastrear relaciones causales complejas y el comportamiento a nivel del sistema.

• Es posible que se hayan obtenido los mismos resultados con el ejemplo de "rightsizer" aunque se hubiera analizado de forma tradicional.

  • Este enfoque nuevo es más fácil y más fácil de ejecutar.

• La razón por la que muchos detestan las pruebas de software es por fallas causadas por factores externos.

  • Este enfoque podría ayudar a resolverlo.

• CAST se parece al análisis de causa raíz de múltiples factores.

  • Reforzó el CAST de la profesora Nancy Leveson del MIT.

• La pregunta de si SRE/DevOps forma parte de un rol cotidiano.

  • En muchos casos, creo que esto no es más que un rebranding de los roles de operaciones existentes.

• La mayor característica de Google SRE es que se necesita ayuda de SRE al lanzar un nuevo producto.

  • La cantidad limitada de SREs ayuda a mejorar las buenas ideas.

• El texto es demasiado largo y cuesta sacar el objetivo principal.

  • Las referencias a CAST y STPA son lo más importante y valioso.

• Me pregunto si este enfoque también tiene valor a escalas fuera de FAANG.

  • Las empresas suelen estar inclinadas a invertir mucho en la evitación de riesgos.

• Al igual que DevOps, el significado de SRE se está expandiendo.

  • Los SRE toman muchos roles distintos, desde escribir software hasta manejar fallos del sistema.