La evolución del SRE en Google

• El SRE de Google ha logrado reducir las fallas incluso a medida que la escala de los servicios creció, pero concluyó que los métodos existentes no bastan para pérdidas que deben prevenirse por completo, como violaciones de privacidad o pérdida de datos, por lo que adoptó STAMP
• STAMP se enfoca en la interacción del sistema y las fallas de control más que en fallas de componentes individuales; CAST se usa para investigar incidentes y STPA para analizar riesgos
• Los modelos de flujo de datos y las cadenas lineales de causalidad muestran límites crecientes de análisis frente a diagramas RPC con más de 100 nodos, modelos de arquitectura desactualizados y requisitos faltantes
• En el incidente interno de quota rightsizer de 2021, una retroalimentación incorrecta sobre uso de recursos y un pending change que no se comunicó crearon un estado riesgoso durante varias semanas, que finalmente derivó en una falla
• Google está invirtiendo esfuerzos del orden de engineer-weeks en análisis STPA para encontrar cientos de escenarios y ampliar el alcance de SRE hacia el diseño seguro de Google Cloud, redes internas y varios productos

---

Límites que enfrentó el enfoque tradicional de SRE

• Los productos de Google son usados a diario por miles de millones de personas en todo el mundo, y aunque la escala de los servicios creció mucho durante los últimos 25 años, las fallas se han vuelto menos frecuentes
• SRE ha escalado la confiabilidad mediante SLO, presupuestos de error, estrategias de aislamiento, análisis postmortem rigurosos y despliegues graduales
• Ahora el reto no es solo reducir la frecuencia de las fallas, sino abordar pérdidas cuya ocurrencia debe impedirse desde el inicio
  • violaciones de privacidad
  • pérdida de datos
  • incumplimiento regulatorio
• Los presupuestos de error tradicionales funcionaban bastante bien para servicios web con poco estado, pero no son suficientes para tratar pérdidas donde el presupuesto de error es cercano a 0
• A medida que la IA y el ML se vuelven el núcleo de casi todos los productos, y la automatización hace posible la escalabilidad, la eficiencia de costos y energía pasa a ser tan importante como las funciones para usuarios

La estructura de la forma tradicional de pensar en SRE

• El análisis de riesgos tradicional se compone en gran medida de tres elementos
  • una forma de modelar el sistema
  • una teoría causal que explique cómo ocurren los problemas
  • un algoritmo de búsqueda para encontrar riesgos
• El enfoque previo de Google SRE no estaba formalizado como una teoría explícita, pero analizaba riesgos en torno a la arquitectura de software y los modelos de flujo de datos
• Un modelo de flujo de datos muestra cómo las solicitudes de red o los datos se mueven entre distintas partes del sistema
• Este modelo lleva de forma natural al razonamiento lineal de causa y efecto
  • se observan los SLO de cada componente para entender las garantías de confiabilidad
  • se verifica si cumplen o superan los requisitos del llamador
• En los postmortems se usa razonamiento inductivo para extraer patrones generales a partir de incidentes individuales
  • no se trata solo de corregir un incidente puntual, sino de encontrar cómo evitar toda una clase de incidentes similares
  • se intenta convertir alertas repetitivas en soluciones de ingeniería para eliminar la causa del problema

Límites de los modelos de flujo de datos y del análisis causal lineal

• A medida que la complejidad del sistema aumenta cada año, los modelos de flujo de datos tienen cada vez más dificultad para manejar la complejidad a escala de Google
• Los diagramas RPC y los modelos de arquitectura de software se vuelven excesivamente complejos si no usan la abstracción de manera consistente, y por lo general quedan incompletos o desactualizados
• Estos modelos no muestran suficientemente la dinámica del sistema
  • qué RPC pueden iniciar un flujo
  • cómo se propagan los errores
  • qué componentes pueden causar fallas graves y cuáles solo problemas menores
  • por qué cierta interacción es segura en un contexto pero no en otro
  • cuáles son los objetivos globales del sistema
  • qué responsabilidad tiene cada componente respecto a esos objetivos globales
• Un diagrama de flujo de datos con más de 100 nodos resulta abrumador desde el punto de partida para buscar defectos
• Si los requisitos de seguridad faltan o están mal definidos desde la etapa de definición de requisitos, la seguridad del sistema puede romperse incluso si el diseño implementa perfectamente esos requisitos
• Aprender a partir de datos de fallas tiene límites para predecir y prevenir pérdidas que aún no han ocurrido nunca

Cómo STAMP cambia la forma de pensar

• Google SRE está adoptando teoría de sistemas y teoría de control, y tomó el framework STAMP desarrollado por Nancy Leveson en MIT
• STAMP considera un incidente no como una cadena de fallas de componentes, sino como el resultado de un control insuficiente del sistema
• CAST se usa para la investigación posterior al incidente y STPA para el análisis de riesgos
• STAMP trata la seguridad no como una propiedad de componentes individuales, sino como una propiedad emergente a nivel sistema
• También cambian las preguntas del análisis
  • pregunta tradicional: qué servicio de software falló
  • pregunta STAMP: qué interacciones entre partes del sistema no estuvieron suficientemente controladas
• Muchos incidentes en sistemas complejos pueden ocurrir aunque cada componente haya funcionado según su diseño, pero en conjunto hayan creado un estado inseguro

Las cuatro condiciones de la teoría de control

• Las condiciones de control descritas por W.R. Ashby en An Introduction to Cybernetics están integradas en la metodología STAMP de Leveson
• Para controlar un proceso se necesitan cuatro condiciones
  • condición de objetivo: el controlador debe tener un objetivo
  • condición de acción: el controlador debe poder influir en el estado del sistema
  • condición de modelo: el controlador debe tener un modelo del sistema
  • condición de observabilidad: el controlador debe poder conocer el estado del sistema
• En la práctica de SRE, estas condiciones pueden usarse como criterio para verificar si existen los elementos necesarios para controlar eficazmente sistemas complejos

El margen de respuesta que crean los estados peligrosos

• El modelo de cadena causal lineal suele mostrar solo dos estados: operación normal y operación con pérdida
• La transición de operación normal a operación con pérdida suele ser repentina, con casi nada de tiempo para responder y evitar la pérdida
• Una razón por la que SRE usa juntos SLO de fast burn y slow burn es detectar problemas antes del daño real, pero esos SLO suelen ser propiedades de componentes individuales
• STAMP formaliza esto como estado peligroso a nivel sistema
  • un estado peligroso es un estado o conjunto de condiciones del sistema que, al combinarse con ciertas condiciones ambientales de peor caso, produce una pérdida para una o más partes interesadas
• Un estado peligroso no es un evento individual ni un fenómeno a nivel de un solo componente
• Un sistema puede permanecer en un estado peligroso durante mucho tiempo antes de que ocurra un incidente
  • se introdujo un bug, pero todavía no se activa
  • se disparó una alerta, pero nadie la recibió
  • un servidor está subaprovisionado, pero luego recibe tráfico repentino desde una función popular
• El objetivo de ingeniería no es eliminar todas las fallas individuales, sino impedir que el sistema entre en un estado peligroso o hacerlo volver de ese estado a operación normal

El caso de quota rightsizer en 2021

• Google configura y hace cumplir cuotas de recursos para parte del software en su infraestructura interna
• Para mejorar la eficiencia, monitorea cuánto de esa quota usa cada servicio y, si un servicio usa persistentemente menos, reduce la quota de forma automática
• Desde la perspectiva de STPA, quota rightsizer tiene como acción de control reducir la quota de un servicio
• Esta acción es insegura cuando rightsizer reduce la quota por debajo de la necesidad real del servicio
  • el servicio queda en condición de falta de recursos
  • en STPA, esto se denomina acción de control insegura, o UCA
• Las UCA tienen cuatro tipos
  • no se proporciona una acción de control necesaria
  • se proporciona una acción de control incorrecta o insuficiente
  • la acción de control se proporciona en un momento u orden incorrecto
  • la acción de control se detiene demasiado pronto o se aplica durante demasiado tiempo
• Reducir la quota por debajo de la necesidad real corresponde al segundo tipo de UCA

Vulnerabilidades expuestas en la ruta de retroalimentación

• El requisito de seguridad puede resumirse como: “quota rightsizer no debe reducir la quota por debajo de la necesidad actual del servicio”
• Este requisito es útil para diseños futuros, planes de prueba y comprensión del sistema
• STPA estructura el análisis para encontrar escenarios concretos que lleven a violar este requisito de seguridad
• En el caso de rightsizer, pueden investigarse cuatro escenarios representativos
  • rightsizer en sí funciona mal
  • rightsizer recibe retroalimentación incorrecta o no recibe retroalimentación en absoluto
  • rightsizer intentó enviar una acción, pero el sistema de quota no la recibió
  • el propio sistema de quota funciona mal
• El escenario que realmente destacó fue cuando la retroalimentación del uso actual de recursos se calculó demasiado baja
  • el cálculo del uso de recursos incluye varios recolectores de datos y lógica de agregación compleja
  • si el resultado del cálculo es menor que el real, rightsizer funciona según diseño y aun así reduce incorrectamente la quota
• Antes se ponía mucha atención en el algoritmo de ajuste de quota y en la precisión de su salida, pero la ruta de retroalimentación se entendía menos
• STPA ayuda a encontrar problemas no solo en la ruta de control, sino también en la ruta de retroalimentación, y en varios análisis de sistemas de Google se observó que estas rutas de retroalimentación estaban menos comprendidas

Cómo el incidente terminó en pérdida

• En el incidente de 2021, se envió a rightsizer una retroalimentación incorrecta sobre los recursos usados por un servicio crítico de la infraestructura de Google
• rightsizer calculó una nueva quota, lo que terminó asignando muchos menos recursos que el uso real
• Como medida preventiva, la reducción de quota no se aplicó de inmediato y quedó en espera durante varias semanas para dar tiempo a una intervención humana
• Sin embargo, la retroalimentación sobre el pending change no se comunicó a nadie
• El sistema permaneció durante semanas en un estado peligroso, pero como nadie lo estaba buscando, se perdió la oportunidad de evitar la pérdida
• Semanas después, la reducción de quota se aplicó y causó una falla importante
• Google ha usado STPA para predecir por adelantado problemas similares en varios sistemas

Hacia dónde se dirige Google SRE

• Google SRE ya no ve la complejidad como un bug, sino que está avanzando hacia un enfoque de confiabilidad más integral y proactivo usando teoría de control, STPA y CAST
• El objetivo no es solo reaccionar ante fallas, sino diseñar sistemas más seguros desde el principio
• Google analizó con STPA algunos de sus sistemas más complejos y, con un esfuerzo del orden de engineer-weeks por análisis, encontró cientos de escenarios con distintos alcances de impacto
• Los escenarios descubiertos se mitigaron antes de que derivaran en fallas
  • soluciones temporales rápidas
  • trabajo de ingeniería de software planificado con más cuidado
  • uso del proceso regular de planificación de Google para minimizar costos e interrupciones
• El trabajo actual se concentra en sistemas muy complejos de Google Cloud, sistemas internos de red a gran escala y varios productos de Google
• El cambio de metodología de seguridad de sistemas en SRE apunta a dar a los ingenieros una nueva forma de entender los sistemas que construyen y ofrecer garantías más sólidas sobre cómo funcionan