Cómo Databricks utiliza la inteligencia artificial para acelerar la investigación de incidentes

En nuestra publicación de blog anterior, compartimos cómo Databricks utiliza AI para depurar miles de bases de datos. Aquí, continuamos esa historia explorando cómo nuestros ingenieros utilizan AI para operar cientos de microservicios en más de 1500 clústeres de Kubernetes, que abarcan más de 70 regiones y tres nubes.

Cuando algo se rompe a las 2 a. m., el ingeniero de guardia debe responder rápidamente a una pregunta: ¿Qué cambió?

AI SRE es un agente de depuración impulsado por AI que comienza a investigar tan pronto como se activa un incidente. Correlaciona señales de todo nuestro stack y guía a los ingenieros a través del análisis de causa raíz.

En esta publicación, describimos el proceso de depuración que dio forma a AI SRE, la arquitectura detrás de él y los principios de ingeniería que seguimos para hacer que un sistema impulsado por LLM sea confiable durante los incidentes.

Antes de AI SRE: La experiencia de las 2 a. m.

Imagina una alerta de guardia típica. Un pico de latencia afecta a una API de cara al cliente. El ingeniero se despierta y comienza la rutina habitual:

• Inspeccionar las métricas del servicio en todos los paneles y regiones.
• Buscar en los logs errores que sean tanto relevantes como inusuales.
• Revisar los despliegues, los cambios de dependencias y las actualizaciones de feature flags.
• Comprobar el estado de la nube, la red y la plataforma compartida.
• Buscar y ejecutar el runbook adecuado.

Cada uno de estos flujos de trabajo funciona bien de forma aislada, pero el flujo de trabajo de depuración (es decir, el acto de conectar las señales entre ellos) vive completamente en la mente del ingeniero. Los ingenieros experimentados podían hacerlo en unos pocos minutos porque ya habían visto el patrón antes. Los ingenieros más nuevos podrían pasar horas o derivar el problema a otra persona.

Las herramientas no eran el problema principal. La responsabilidad de conectar sus señales recaía en el ingeniero de guardia que trabajaba bajo la presión de un SLA.

Comenzando por el cliente, no por la tecnología

No empezamos construyendo un agente. Empezamos observando cómo depura la gente.

Durante varias semanas, entrevistamos a ingenieros de guardia de docenas de equipos para mapear sus procesos de depuración de extremo a extremo. Leímos postmortems y documentos de investigación. Hicimos una pregunta sencilla: ¿en qué dedicas tu tiempo y dónde te atascas?

Surgieron tres patrones de manera constante:

• La recopilación de contexto consumía la mayor parte del tiempo. El momento de revelación real (es decir, identificar la causa raíz) solía ser rápido una vez que el ingeniero tenía las señales correctas frente a él. Pero recopilar esas señales (la métrica adecuada, la ventana de tiempo correcta, el despliegue relevante, la dependencia ascendente que cambió) consumía entre el 60 % y el 80 % del tiempo de investigación.
• El conocimiento estaba distribuido de manera desigual. Cada equipo tenía un par de expertos que "simplemente sabían" cómo fallaba su sistema. Cuando estos expertos no estaban disponibles, las investigaciones se ralentizaban drásticamente. Los runbooks existían, pero a menudo estaban desactualizados o incompletos, y no podían responder a modos de fallo nuevos.
• El estado de la plataforma era invisible hasta que dejaba de serlo. Muchos incidentes se debían a un problema de infraestructura a gran escala, como una interrupción del proveedor de la nube o de la red, o a un fallo crítico del sistema como Auth. Pero los ingenieros que depuraban en la capa de aplicación no tenían una forma sencilla de comprobar esas señales, por lo que pasaban tiempo analizando hipótesis a nivel de aplicación antes de descubrir que el problema estaba en las capas inferiores de infraestructura.

Una vez que reconocimos la depuración como una secuencia de pasos de investigación repetibles seguidos de un juicio experto, quedó claro que los agentes de AI podían acelerar el trabajo. Pero ningún equipo por sí solo podía construir un agente que entendiera cada servicio, señal y modo de fallo. Necesitábamos una plataforma compartida que gestionara los componentes comunes, como recopilar contexto, ejecutar herramientas y runbooks, y correlacionar pruebas, al tiempo que permitiera a los equipos ampliarla con su propio conocimiento operativo. La pregunta pasó de ser ¿Podemos automatizar la depuración? a ¿Cómo ofrecemos a cada equipo una plataforma impulsada por AI para un diagnóstico y una resolución más rápidos e informados?

Presentamos AI SRE

AI SRE admite dos experiencias complementarias: el triaje automático, que comienza cuando se activa un incidente, y la investigación interactiva, que permite a los ingenieros de guardia explorar hipótesis y solicitar pruebas adicionales.

Triaje automático cuando se activa un incidente

Cuando se activa un incidente, AI SRE se pone en marcha de inmediato, incluso antes de que el ingeniero haya abierto su portátil. Lanza tres vías de investigación en paralelo, recopilando pruebas complementarias para generar una evaluación inicial:

Las comprobaciones de estado de la plataforma evalúan el entorno en el que se ejecuta el servicio.

• ¿Está en buen estado la infraestructura de nube subyacente?
• ¿Hay problemas de red en curso en la región correspondiente?
• ¿Están experimentando degradación las dependencias ascendentes (bases de datos, colas de mensajes, servicios compartidos)?

Esto por sí solo elimina una gran cantidad de pistas falsas, de modo que un ingeniero ya no pasa 30 minutos depurando el código de su aplicación solo para descubrir que la causa raíz era un problema de infraestructura a gran escala.

El análisis a nivel de servicio extrae los logs, las métricas y las trazas relevantes para el servicio afectado y sus dependencias inmediatas. Examina los despliegues recientes y los cambios de configuración. Identifica anomalías en relación con el comportamiento de referencia del servicio, no solo "la CPU está alta", sino "la CPU aumentó 3 veces a las 2:47 a. m., coincidiendo con un despliegue que cambió el tamaño del lote en el pipeline de procesamiento".

La ejecución de runbooks es donde AI SRE asume un rol específico para cada equipo. Los equipos codifican sus procedimientos de depuración, como las comprobaciones que realizaría un experto en el dominio, los umbrales que buscarían y las medidas de mitigación que tomarían. Los equipos pueden convertir sus runbooks existentes en runbooks agénticos utilizando habilidades (skills). Estas habilidades se basan en la base de código, los datos de observabilidad y el historial de incidentes anteriores para que los runbooks sean más precisos y conscientes del contexto. Luego, ejecuta estos pasos en nombre del ingeniero de guardia, realizando la misma investigación que haría un experto en el dominio, pero en cuestión de segundos en lugar de minutos.

Para cuando el ingeniero lee los detalles del incidente por primera vez, AI SRE ya ha recopilado un completo resumen de diagnóstico: qué se rompió, qué cambió y qué indica el runbook de tu equipo que se debe comprobar, con todas las señales, la correlación y los siguientes pasos en una sola vista.

Depuración interactiva para una investigación más profunda

No todas las investigaciones terminan con el triaje automático. A veces, la causa raíz es sutil o el ingeniero desea explorar una hipótesis. La UI de AI SRE proporciona un entorno de depuración interactivo donde los ingenieros pueden hacer preguntas de seguimiento en lenguaje natural, solicitar señales adicionales y profundizar en ventanas de tiempo o componentes específicos.

Aquí es donde la combinación de comprobaciones de estado estructuradas y AI conversacional se vuelve potente. Un ingeniero podría preguntar: "¿Hubo algo inusual en el retraso del consumidor de Kafka (Kafka consumer lag) en los 10 minutos anteriores a esta alerta?". AI SRE obtiene las métricas relevantes, las superpone en la línea de tiempo del incidente y explica lo que encuentra.

Una arquitectura por capas para la depuración

Nuestra principal conclusión de las entrevistas con los clientes fue que la depuración no es un solo problema, sino una pila de problemas, y resolverlos requiere abstracciones deliberadas. Diseñamos AI SRE como una plataforma por capas, donde cada capa tiene una responsabilidad clara y las capas superiores pueden centrarse en aspectos de nivel cada vez más alto.

Las primitivas constituyen la base: los datos operativos brutos de los que depende en última instancia cada investigación. Ya existen primitivas para métricas, alertas, logs, información de lanzamiento y código, pero acceder a ellas durante un incidente significaba saltar entre cinco herramientas diferentes con cinco lenguajes de consulta distintos. La capa de primitivas no reemplaza estos sistemas; los reconoce como la fuente de verdad.

La capa de API utiliza primitivas y proporciona un acceso controlado y uniforme a los datos subyacentes. En lugar de que cada herramienta de depuración consulte directamente las fuentes de datos, como el almacenamiento de logs o métricas, creamos API específicas para cada propósito: una API de observabilidad, una API de despliegue y una API de alertas que gestionan la autenticación, la limitación de velocidad (rate limiting) y la normalización de datos. Esta es la capa que convierte la "infraestructura bruta" en "infraestructura depurable". También significa que cuando reemplazamos un sistema subyacente, las herramientas de depuración superiores no se rompen.

El Core Engine es donde reside la inteligencia. Un framework de bots proporciona la capa de orquestación para crear flujos de trabajo de depuración, y el motor se encarga de la mecánica de la ejecución en paralelo, la correlación de resultados y la síntesis impulsada por LLM. Esta es la plataforma en la que se ejecutan nuestros bots propios pero, fundamentalmente, también es la misma plataforma disponible para cada equipo que quiera crear la suya propia.

La Capa de Aplicación es donde realmente ocurre la depuración. Aquí es donde se ejecuta nuestro bot de triaje de incidentes a nivel de plataforma. También es donde se pueden integrar herramientas de IA de terceros, proporcionando capacidades complementarias sin que tengamos que reconstruir todo desde cero.

Esta separación nos permite mejorar el acceso a los datos y la orquestación de forma independiente, al tiempo que admite tanto los flujos de trabajo mantenidos de forma centralizada como los runbooks propiedad de los equipos

Desarrollar para la confiabilidad en un mundo no determinista

Hacer que un agente impulsado por LLM sea lo suficientemente confiable para la respuesta a incidentes, donde la confianza lo es todo, requirió una ingeniería deliberada. Nos guiamos por algunos principios:

Comprobaciones estructuradas antes del razonamiento abierto. AI SRE ejecuta primero comprobaciones deterministas del estado de la plataforma y pasos de runbooks. La capa de LLM sintetiza y explica los resultados, pero la recopilación de datos no se deja al criterio del modelo.

Transparencia sobre respuestas de caja negra. Cada conclusión que presenta AI SRE se vincula con la evidencia subyacente: la métrica específica, la línea de registro, la diferencia de despliegue. Los ingenieros pueden verificar el razonamiento, no solo confiar en él. Esto no era negociable porque los ingenieros de guardia no actuarán sobre una recomendación que no puedan auditar.

Degradación progresiva. Si AI SRE no puede determinar una causa raíz con confianza, lo dice explícitamente y presenta la evidencia que recopiló, organizada por relevancia. Una investigación parcial que sea honesta sobre sus límites es mucho más útil que un diagnóstico alucinado.

Impacto

AI SRE ahora da soporte a más de 150 equipos en todo Databricks, con más de 250 usuarios activos semanales que ejecutan más de 2,000 investigaciones cada día y ahorran varias horas de tiempo de depuración. Hemos recibido comentarios positivos desde el lanzamiento:

“El equipo de la plataforma de almacenamiento depende en gran medida de AI SRE para el triaje. Se anticipa a mis investigaciones: antes de que abra una alerta, el agente ya ha correlacionado las señales y ha producido un análisis inicial de la causa raíz. Felicitaciones al equipo por crear una plataforma de depuración verdaderamente genérica que permite a múltiples equipos integrar flujos de trabajo basados en agentes en su día a día.”—Gaurav Garg, Sr. Staff Engineer

“Antes de AI SRE, el primer tramo de un incidente era la recopilación de contexto: paneles de control, ventanas de tiempo, filtros para toda la flota. Ahora, el contexto relevante llega a un solo lugar, ya acotado a la alerta o incidente. No tengo que creer ciegamente en la palabra del agente. La evidencia está integrada en la investigación y, con un solo clic, se abre la herramienta subyacente, prefiltrada, para que pueda verificarla yo mismo.”—Himanshu Mishra, Senior Engineer

“AI SRE ha transformado la respuesta a incidentes al unificar métricas, logs y el estado de las dependencias, acelerando el triaje de incidentes y detectando las causas raíz antes, reduciendo así el MTTR en toda la empresa.”—Adama Kone, Manager - NOC Team

El resultado más importante no fue reemplazar el criterio de los ingenieros. Fue darles un punto de partida más rápido y respaldado por evidencias para la investigación.

Lo que aprendimos

Tres conclusiones clave de la creación de AI SRE:

Permitir que los equipos sean dueños de su propia experiencia. Un agente centralizado que intente codificar el conocimiento de dominio de cada equipo siempre estará desactualizado y será frágil. Al hacer que los runbooks basados en agentes sean una primitiva componible que los equipos poseen y mantienen, convertimos a AI SRE en una plataforma que se vuelve más inteligente a medida que crece, sin que la plataforma se convierta en el cuello de botella.

Crear la capa de contexto antes de optimizar el modelo. Pasamos más tiempo mapeando cómo los ingenieros investigan realmente los incidentes que en la ingeniería de prompts. Esa inversión inicial para comprender el problema significó que creamos lo correcto, es decir, un agente que recopila el contexto y ejecuta comprobaciones conocidas, en lugar de lo obvio, que habría sido un chatbot acoplado a nuestro sistema de observabilidad.

Ganarse la confianza a través de evidencia rastreable. Los ingenieros de guardia trabajan bajo presión y no pueden permitirse seguir pistas falsas. Cada recomendación que hace AI SRE está respaldada por evidencia rastreable. Esta transparencia es lo que convirtió a los primeros usuarios escépticos en usuarios diarios.

Las barreras de seguridad importan más para los agentes que para las personas. Dar a los agentes acceso a los datos de observabilidad significó rediseñar nuestra capa de API, no solo abrirla. Los agentes realizan consultas de manera diferente a los humanos. Envían ráfagas de peticiones a los endpoints, ejecutan comprobaciones en paralelo y no se cansan ni se detienen por sí mismos. Tuvimos que incorporar barreras de seguridad para que los agentes pudieran trabajar rápido sin interrumpir la infraestructura que también sustenta las alertas y el monitoreo críticos para el negocio.

¿Qué sigue?

Hoy en día, AI SRE se centra en la fase de investigación de la respuesta a incidentes: comprender qué sucedió y por qué. El siguiente paso natural es expandirse hacia la mitigación guiada, no solo diagnosticando el problema, sino ayudando a los ingenieros a tomar la medida correctiva adecuada de manera segura.

También estamos invirtiendo en el aprendizaje entre incidentes: utilizar patrones de incidentes pasados para mejorar los diagnósticos futuros, detectar problemas recurrentes antes de que generen alertas y ayudar a los equipos a identificar brechas de confiabilidad sistémicas.

Únete a nosotros

De cara al futuro, nos entusiasma seguir superando los límites de cómo la IA puede dar forma a los sistemas de producción y hacer que la infraestructura compleja parezca sencilla. Si te apasiona crear la próxima generación de plataformas internas impulsadas por IA, ¡únete a nosotros!

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original