Son las 2:13 a.m. PagerDuty dispara una alerta para checkout-service: el p95 lleva cuatro minutos sobre el umbral. Abres Datadog, encuentras el dashboard equivocado, luego el correcto, después la herramienta de CI para ver deploys recientes, luego Jira para incidentes abiertos y finalmente #incidents en Slack para ver si algún compañero ya está en el war room. Ocho minutos después, tienes una hipótesis.
Eso no es respuesta a incidentes. Es un impuesto por cargar contexto que el ingeniero de guardia paga antes de empezar a trabajar.
Los agentes de código como Claude Code ya se comen el inner loop. El outer loop es otra historia. El trabajo operacional (respuesta a incidentes, ejecución de runbooks, investigación de SLO, handoffs de guardia) sigue viéndose casi igual que hace cinco años. El problema no es el modelo, sino la infraestructura para correr herramientas agénticas en equipo, contra producción, con las garantías de auth, alcance y auditoría que un programa de SRE necesita.
Este artículo trata sobre la capa de ejecución. El sustrato de datos que la sostiene es la otra mitad del problema, y lo cubrí en el blog de ClickHouse.
TL;DR
- Claude Code ya funciona en el outer loop. La interfaz, el razonamiento y el contrato de llamadas a herramientas se transfieren. Lo que cambia son las fuentes de datos.
- Cinco flujos lo demuestran. Triaje de incidentes, ejecución de runbooks, redacción de postmortems, investigación de SLO y handoffs de guardia. Todos tienen la forma exacta que Claude necesita.
- La brecha de auth, alcance y auditoría es el cuello de botella. Los servidores MCP para la mayoría de herramientas SaaS ya existen. El problema es que cuando cada ingeniero conecta su propia integración, hereda autorización inconsistente, credenciales con demasiados permisos y sin rastro de auditoría. Útil para una persona en el mejor caso. Un incidente de exposición de datos en el peor.
- La brecha es un runtime de MCP, no un modelo. Auth administrada, cómputo en la nube, gobernanza por herramienta y logs de auditoría persistentes. Mientras algo no ofrezca los cuatro, el AI en el outer loop seguirá siendo un truco de salón.
- Un runtime de MCP es más que un gateway de MCP. Un gateway enruta herramientas MCP bajo una sola URL. Un runtime de MCP añade el cómputo que las ejecuta, la auth que las delimita y el rastro de auditoría que las hace seguras en producción. Arcade.dev es un runtime de MCP con un gateway incluido.
Cinco flujos de AI SRE y los servidores MCP que los impulsan
Si solo vas a leer una cosa de este artículo, lee esta tabla.
| # | Flujo | Servidores MCP | Qué hace Claude Code | Qué hace el ingeniero de guardia |
|---|---|---|---|---|
| 1 | Triaje de incidentes | PagerDuty, Datadog, Slack, GitHub | Obtiene el payload de PagerDuty, correlaciona señales de Datadog en la ventana, revisa deploys recientes, escanea Jira y #incidents, redacta el post del war room | Decide el siguiente paso |
| 2 | Ejecución de runbook | Confluence, Kubernetes, GitHub | Parsea el doc de Confluence en pasos, presenta la secuencia de diagnóstico con comandos y salida esperada, propone cualquier comando de escritura | Ejecuta los pasos y aprueba cada escritura |
| 3 | Redacción de postmortem | Slack, PagerDuty, Datadog, Confluence | Reconstruye la línea de tiempo desde Slack, PagerDuty, Datadog y el log de despliegues; llena la plantilla del equipo con evidencia enlazada a la fuente | Redacta la causa raíz y los puntos de acción |
| 4 | Investigación de SLO | Datadog, PagerDuty, Snowflake, Confluence | Encuentra el punto de inflexión de consumo, correlaciona despliegues, cambios de configuración, variaciones de tráfico e incidentes upstream, y clasifica hipótesis con evidencia enlazada | Evalúa hipótesis y decide los puntos de acción |
| 5 | Transferencia de guardia | PagerDuty, Datadog, Slack, Zendesk | Arma el resumen del turno a partir de alertas, incidentes activos, despliegues en espera, consumo de SLO y puntos de acción abiertos; lo entrega como DM en Slack | Revisa, agrega contexto, da el visto bueno |
Flujo de trabajo 1: el triage de incidentes es pura arqueología
Escenario
El triage manual de arriba es un problema de paralelismo, no de habilidad. Un ingeniero, cinco flujos de trabajo, cargas de contexto en serie. Todos los ingenieros de guardia que conozco cuentan la misma historia: “Pasé los primeros diez minutos tratando de entender qué estaba pasando.”
Qué hace Claude Code
Dale la alerta a Claude Code: “Triagea esta alerta en particular, correlaciónala con las métricas de Datadog, los logs del servicio y el historial de despliegues. Escanea el historial de Slack en busca de fallas correlacionadas.”
Claude Code devuelve el contexto de la alerta en dos oraciones, las tres señales correlacionadas más relevantes con enlaces directos a Datadog, y los despliegues con mayor probabilidad de importar según la proximidad en el grafo de servicios, con los commit SHAs y autores. Dos o tres minutos de principio a fin, mientras todavía estás abriendo la laptop. El equipo de Grafana reportó una reducción de 3.5x en el tiempo para llegar a la causa raíz usando un patrón similar.
Qué hace el ingeniero de guardia
Para cuando el ingeniero pasa de la alerta en su celular a abrir la laptop, el análisis inicial de Claude Code ya lo está esperando. Lee el resumen, lo valida contra los dashboards, cruza los despliegues clasificados con lo que sabe que salió recientemente y decide el siguiente paso. También detecta los errores: la correlación espuria, el despliegue que el grafo de servicios no conoce, el hilo de #incidents que era ruido. Claude Code comprime la arqueología. El ingeniero de guardia la juzga.
La brecha de autenticación, alcance y auditoría
PagerDuty, Datadog, Slack, Jira y GitHub todos tienen servidores MCP. El problema no es construirlos, sino operarlos en equipo.
Si la configuración no es consistente para cada ingeniero en la rotación, el flujo falla justo en el turno que más lo necesita. Los permisos mal configurados generan análisis inconclusos, y un análisis inconcluso a las 3am es peor que no tener ninguno. Los ingenieros que configuran sus propias conexiones suelen darse alcances más amplios de los que el flujo necesita, y la siguiente revisión de accesos se convierte en una limpieza que nadie planeó. El peor escenario: si el acceso a las herramientas no está bien delimitado, un paso de diagnóstico puede disparar accidentalmente una acción de escritura, mutar el estado en producción y convertir el triage en el incidente. La configuración consistente, las credenciales con alcance definido y la restricción de solo lectura son propiedades del runtime de MCP, no de la configuración de cada ingeniero.
Flujo de trabajo 2: ejecución de runbooks a las 3am
Escenario
Los equipos maduros mantienen sus runbooks. Los que se usan todo el tiempo se mantienen al día porque la gente los corrige después de cada incidente. El deterioro vive en dos lugares más silenciosos. Los runbooks que se activan una vez al trimestre se desactualizan entre usos y nadie lo nota hasta que la próxima alerta a las 3am revela que la mitad de los comandos apuntan a herramientas obsoletas y clústeres renombrados. Y los ingenieros nuevos en la rotación muchas veces no saben qué runbook aplica a la alerta que tienen enfrente. Encontrar el documento correcto a las 3am es una habilidad en sí misma, y toma meses en la rotación desarrollarla.
“Los runbooks son una mentira que nos contamos.”
Durante el tiempo que lideré confiabilidad en Confluent y Dropbox, vi cómo este patrón se repetía en stacks muy distintos. No es un problema específico de una organización. Es la ley de la priorización en acción: los runbooks que se disparan seguido reciben atención, los que rara vez se disparan, no.
Qué hace Claude Code
Encontrar el runbook correcto. Una vez que el triaje acota el problema, el on-call necesita saber qué runbook aplica y qué ejecutar. Apunta Claude Code a la alerta. Coteja los metadatos (servicio, síntoma, etiqueta) contra el índice de runbooks, presenta el candidato más probable y detalla la secuencia de diagnóstico con comandos exactos, los sistemas que tocan y la salida esperada en cada paso.
Mantener los runbooks actualizados. La mayoría de los equipos maduros hacen semanas de calidad o sprints de confiabilidad para actualizar sus runbooks. En Confluent lo hacíamos cada trimestre. Claude Code abarata el sprint porque es un entorno seguro: reproduce cada runbook contra staging en lote, marca los comandos que apuntan a herramientas obsoletas y clústeres renombrados, y regenera los pasos contra la infraestructura actual. El deterioro acumulado desde la última revisión se detecta en horas, no en semanas.
Qué hace el on-call
El on-call ejecuta los pasos. Claude Code traza el plan, el ingeniero lo lleva a cabo. Darle acceso irrestricto a producción a un agente de código no pasa el olfato de ningún equipo de confiabilidad con el que haya trabajado, y con razón. El ingeniero confirma que Claude Code eligió el runbook correcto, corre cada diagnóstico en su propia terminal con sus propias credenciales acotadas, y registra los resultados paso a paso. Cuando Claude Code elige el runbook equivocado, el on-call lo corrige, y esa corrección alimenta el índice para la siguiente alerta.
La brecha de autenticación, alcance y auditoría
Si Claude Code no ejecuta directamente contra producción, el control se convierte en todo el juego. El runbook tiene que estar acotado al usuario que lo ejecuta, al entorno que apunta, y a las acciones que el paso actual realmente necesita. Un paso seguro en staging puede ser peligroso en prod. Un paso seguro para un SRE senior puede ser catastrófico para alguien recién integrado que todavía aprende el clúster. Sin gobernanza a nivel de herramienta que entienda usuario, entorno y acción en conjunto, volvemos a confiar en que cada ingeniero lea con cuidado a las 3am, que es exactamente el modo de falla que el runbook debía prevenir. Encontrar el runbook correcto y aplicar los alcances adecuados son dos problemas distintos. Claude Code resuelve el primero. El runtime de MCP resuelve el segundo, con gobernanza por usuario, por entorno y por acción. Los dos tienen que funcionar, y ninguno reemplaza al otro.
Flujo 3: la redacción de postmortems se pudre en el paso de arqueología
Escenario
El incidente se resolvió a las 4pm. La retrospectiva es el jueves. Alguien tiene que escribir el borrador. Lo difícil no es el análisis. Es la arqueología: el historial de Slack, la línea de tiempo de PagerDuty, las gráficas de Datadog, el historial de deploys, la plantilla del equipo. El equipo de incident.io estima que la reconstrucción manual toma entre 60 y 90 minutos por incidente. Coincide con todos los equipos que he dirigido.
La mayoría de los postmortems se redactan mal y a última hora. La retrospectiva arranca desde una base débil, y la misma clase de incidente regresa seis meses después.
Qué hace Claude Code
Escribe en Claude Code: “Redacta el postmortem de INC-4729 usando la plantilla del equipo.” Claude Code ensambla la arqueología. Extrae la transcripción de Slack, la línea de tiempo de PagerDuty, los paneles de Datadog del dashboard del incidente y el log de deploys de cada servicio afectado. Vuelca todo en la plantilla del equipo con los enlaces fuente, de modo que cada entrada de la línea de tiempo traza de vuelta al panel, commit o mensaje de origen.
El borrador se detiene en la arqueología. Línea de tiempo, impacto, servicios afectados, evidencia. Los campos de causa raíz, factores contribuyentes y elementos de acción quedan estructuralmente vacíos. Los equipos que dejan que la AI redacte esas secciones convierten cada retrospectiva en un ejercicio de corrección. El equipo de Zalando reportó tasas de alucinación de hasta 40 por ciento en análisis de postmortems redactados con AI en etapas tempranas, y la lección no es mejorar los prompts. Es mantener todo lo causal fuera del borrador.
Qué hace el on-call
El on-call y el grupo de la retrospectiva revisan el borrador. No lo están reescribiendo. Corrigen entradas de la línea de tiempo que están mal, agregan la señal que la arqueología omitió (un reporte de cliente que llegó por correo, un incidente relacionado tres días antes, el deploy de dos sprints atrás que introdujo el bug latente), y dedican su tiempo a lo que importa: el análisis de los 5 porqués, la validación de la causa raíz, y la decisión de los elementos de acción.
El apalancamiento es mayor en la cola larga. En mi experiencia, entre el ochenta y el noventa por ciento de los incidentes que maneja un equipo maduro son eventos de alto volumen y baja prioridad donde la arqueología es mecánica y el reporte se siente rutinario. Ahí es donde los equipos recortan esquinas, y donde los incidentes repetidos se acumulan en silencio. Claude Code absorbe el trabajo rutinario para que el trabajo de alto juicio reciba atención en cada incidente, no solo en los grandes.
La brecha de autenticación, alcance y auditoría
Las herramientas de las que tira el borrador contienen los datos más sensibles de la empresa. #incidents tiene PII de clientes y secretos de proveedores. El log de deploys tiene mensajes de commit que a veces filtran contexto de seguridad. Los dashboards de Datadog exponen patrones de tráfico de toda la flota. El ingeniero que configuró el conector de Slack suele tener permisos de lectura del workspace más amplios de lo que el rol de postmortem necesita, y el borrador termina citando mensajes que no tenía por qué leer.
El acotamiento tiene que ocurrir en la capa de herramientas, no en la capa de prompts. Qué canales puede leer el borrador, qué dashboards puede consultar, qué tablas puede interrogar, todo acotado por política y ligado al usuario que dispara el flujo. Luego, una traza de procedencia en un log persistente que muestre a qué accedió la AI, cuándo y bajo qué identidad. Esa es la mitad que compliance va a preguntar, y la mitad que determina si el flujo sobrevive su primera revisión de seguridad.
Flujo 4: investigación de SLOs y revisiones de error budget
Escenario
En Confluent, mi equipo revisaba nuestro SLO de disponibilidad cada lunes. Extraíamos los incidentes de la semana, medíamos su impacto en el SLO y el SLA del cliente, y mapeábamos las causas raíz de cada postmortem de vuelta a servicios y temas. El objetivo era ver si el error budget de la semana se había gastado en un problema repetido o disperso en cinco problemas sin relación.
La mayor parte de la preparación era correlación manual: delta del error budget, cruzado con el incidente de PagerDuty, cruzado con la regresión de Datadog, cruzado con el historial de deploys, cruzado con el postmortem, cruzado con el segmento temático. Un SRE típicamente pasaba cuatro a seis horas en ese pipeline antes de que empezara la reunión. El análisis ocurría en la revisión. La preparación era trabajo de campo.
Qué hace Claude Code
Pídele a Claude Code que prepare la revisión del lunes. Extrae los deltas de SLO y SLA, obtiene cada incidente de PagerDuty en el período, lo cruza con la regresión de Datadog que coincide en tiempo y servicio, extrae el postmortem de Confluence y saca la sección de causa raíz. Agrupa las causas raíz en temas usando la taxonomía existente del equipo y entrega un resumen estructurado: delta del error budget, los incidentes que lo explican, los temas y las preguntas abiertas que los postmortems no resolvieron.
Lo que Claude Code no hace es cuantificar cuánto del consumo “causó” cada incidente en términos porcentuales. Ese es el análisis causal que los modelos actuales hacen mal, y un porcentaje inventado en una revisión de métricas es peor que ningún número.
La AI rastrea. El humano decide.
Qué hace el on-call
El SRE que dirige la revisión lee el resumen, valida los cruces entre incidente y regresión (Claude Code va a equivocarse en algunos), escribe la historia causal que la AI se negó a adivinar, decide qué temas merecen elementos de acción y plantea las preguntas abiertas en la reunión. Cuatro horas de preparación se convierten en treinta minutos de revisión y corrección.
La brecha de autenticación, alcance y auditoría
Los flujos respaldados por data warehouse son los que los equipos de SRE han postergado más, y la razón es el alcance. No puedes darle a Claude Code acceso irrestricto al warehouse y esperar que el prompt engineering lo mantenga lejos del PII. No puedes darle presupuestos de consulta sin límite y esperar ver en la siguiente factura un escaneo de cinco mil dólares. El control de alcance en la capa del runtime de MCP es lo que cambia la ecuación: esta tarea consulta estas tablas y no otras, cuesta menos de cincuenta dólares, nunca toca rutas de escritura en prod. Sin eso, el flujo se queda como prototipo y nunca entra a la rotación.
Flujo de trabajo 5: Los relevos de guardia pierden el contexto que nadie escribió
Escenario
Los relevos son el ritual más subestimado en el trabajo de SRE, porque los incidentes que evitan nunca se contabilizan. La calidad del relevo depende de qué tan cansado esté el ingeniero saliente, lo que significa que los peores relevos ocurren en los turnos con más incidentes, que son justo cuando más importan. El costo no tan obvio: el incidente matutino donde el nuevo ingeniero de guardia no sabía que un deploy seguía en curso y termina llamando al anterior a las 8am para preguntar qué pasó en la noche.
Qué hace Claude Code
Claude Code genera el briefing en el cambio de rotación, sin que nadie lo active. Recopila las últimas 24 horas de alertas con notas de resolución, incidentes activos, deploys en curso, SLOs que cruzaron un umbral de consumo, hilos sin resolver en #incidents, escalaciones de Zendesk y reportes de clientes que llegaron al alias de correo de guardia. Lista las acciones abiertas asignadas a la rotación. Entrega el briefing como DM en Slack con una copia en el doc de Confluence del equipo.
Qué hace el ingeniero de guardia
El ingeniero saliente agrega el contexto que solo él tiene: qué cree que es una falsa alarma, qué reporte de cliente vale la pena vigilar, qué deploy le preocupa, qué alerta silenció y por qué. Ese es el conocimiento del relevo que vive en su cabeza y en ningún otro lado. Claude Code ensambla los hechos. El ingeniero de guardia aporta el juicio.
La brecha de auth, permisos y auditoría
El briefing se dispara a las 5pm sin importar si alguien tiene sesión abierta, lo que significa que necesita una credencial que exista fuera de la sesión de cualquier ingeniero. Los dotfiles en una laptop cerrada no califican. Un flujo programado sin una identidad de servicio persistente no es un flujo de trabajo, es un cron job que deja de correr sin avisar la próxima vez que alguien sale de la rotación. La identidad de servicio persistente es una propiedad del runtime de MCP, no de la laptop del ingeniero.
Claude Code es un compañero, no un SRE de AI autónomo
Cinco flujos de trabajo, un mismo patrón. Claude Code lee, correlaciona, redacta y espera. El humano decide.
La mayoría del mercado de AI SRE está apostando lo contrario.Traversal, Resolve, Anyshift, y otros están construyendo hacia agentes autónomos que alertan, remedian y cierran incidentes por su cuenta. Soy escéptico. El output de un modelo es función de su capacidad y del contexto que recibe. Los modelos actuales pueden hacer la arqueología de forma confiable. No pueden recibir de forma confiable suficiente contexto acotado y las herramientas adecuadas para remediar producción sin supervisión. Esa es una brecha de contexto y herramientas, no de modelo, y prefiero lanzar la forma que ya funciona.
Claude Code corre cuando se lo pides. Se detiene cuando el siguiente paso requiere juicio. Nunca manda alertas, hace rollbacks ni cierra un incidente por su cuenta.
Un compañero también evita la batalla de procurement que frena los despliegues autónomos. No estás reemplazando un rol ni agregando un nivel de guardia. Estás apuntando la herramienta que tu equipo ya usa hacia fuentes de datos en las que ya confían, con un runtime de MCP que acota lo que puede hacer. La revisión de seguridad pasa de “nuevo vendor, nuevo riesgo” a “herramientas acotadas dentro de un agente existente”.
Cada flujo de trabajo de este artículo empieza como un prompt y crece hasta convertirse en una skill. El prompt de triaje, el despachador de runbooks, el redactor de postmortems, el pipeline de revisión de SLOs, el briefing de relevo: cada uno comienza como algo que un ingeniero escribe una vez y se convierte en una skill empaquetada que todos en la rotación invocan igual. La skill se afina con el tiempo porque el equipo la sigue editando: una nueva fuente de datos aquí, un prompt más preciso allá, una corrección después de que un incidente revela un punto ciego. El truco de una persona se convierte en infraestructura del equipo, e infraestructura que se acumula.
La confiabilidad viene de tener un programa de confiabilidad real, y un programa real es sobre todo trabajo operativo alrededor de rituales: triaje, runbooks, postmortems, revisiones de SLO, relevos. Claude Code se gana su lugar haciendo que esos rituales sean lo suficientemente baratos como para ocurrir en cada turno, no solo en los que alguien tiene energía para ellos.
Qué necesita un SRE de AI de su capa de integración de herramientas MCP
Cada flujo de trabajo anterior necesita las mismas cuatro cosas.
- Autenticación y autorización gestionadas en todas las herramientas. Flujos OAuth para cada herramienta conectada, credenciales que se refrescan automáticamente, acotadas por usuario y accesibles desde cualquier dispositivo, incluyendo el celular a las 3am.
- Cómputo gestionado, siempre disponible, para todo el equipo. Las herramientas corren en infraestructura compartida, en la nube o on-prem, con el mismo comportamiento sin importar si el trigger vino de una laptop, un celular, un webhook o un cron job.
- Gobernanza a nivel de herramienta y agente. Políticas de permisos por herramienta, presupuestos de costo por tarea y límites de acceso a datos por consulta, aplicados donde ocurre la llamada, no donde el modelo lo propone. Esa es la diferencia entre un flujo que seguridad aprueba y uno que matan al instante.
- Logs de auditoría persistentes. Cada llamada a una herramienta registrada con el usuario que la disparó, los argumentos, la respuesta y el timestamp, en un log que el agente no puede modificar. Sin esto no puedes hacer retro del AI, y no puedes confiar en él.
Arcade.dev: un runtime de MCP para flujos de trabajo de AI SRE
Arcade es un runtime de MCP construido para cerrar exactamente esta brecha. OAuth gestionado maneja cada herramienta conectada, con credenciales que se refrescan automáticamente y nunca tocan el modelo de lenguaje. Cada llamada a una herramienta corre en nombre del usuario que la disparó, por lo que los permisos nativos en PagerDuty, Datadog y Snowflake se aplican exactamente como lo harían fuera del agente. Conectas PagerDuty una vez y cada sesión de Claude Code en tu equipo lo toma con el alcance correcto.
El runtime ejecuta herramientas en workers hospedados, desplegables en tu nube o on-prem, y aplica políticas por herramienta donde ocurre la llamada, no donde el modelo la propone. El mismo workflow disparado desde un celular, una computadora o un cron job corre en infraestructura compartida. Las políticas se aplican en la capa del runtime de MCP: “este workflow consulta estas tablas de Snowflake y no otras”, “este workflow puede proponer acciones en PagerDuty pero no ejecutarlas sin aprobación”, “este workflow tiene un presupuesto de consultas de $25”.
Cada llamada a una herramienta queda registrada en un log de ejecución compatible con OpenTelemetry, con el usuario que la disparó, los argumentos, la respuesta y el timestamp. Se integra directamente al pipeline de observabilidad que ya usa tu equipo de plataforma. Cuando el postmortem pregunta qué hizo Claude Code durante el incidente, tienes la respuesta. Cuando cumplimiento pide cada consulta que este AI corrió contra el warehouse el trimestre pasado, también la tienes.
Herramientas preconfiguradas disponibles para PagerDuty, Datadog, Slack, Jira, Confluence, GitHub, Snowflake y más. También puedes traer tus propios servidores MCP al runtime: los servidores de PagerDuty, Datadog, Snowflake y Kubernetes enlazados en la tabla de arriba funcionan tal cual y heredan la misma autenticación administrada, aplicación de políticas y logs de auditoría que los preconfigurados. Así extiendes tu inversión existente en MCP en lugar de reemplazarla.
Puedes construir esto sin Arcade, y la razón para no hacerlo es la misma por la que no escribiste tu propio sistema de CI: el trabajo es real, los casos extremos son complicados, y no es ahí donde vive tu diferenciación en confiabilidad. Un equipo maduro puede implementar OAuth administrado a mano, levantar workers hospedados, conectar la aplicación de políticas por herramienta y publicar un log de auditoría a prueba de manipulaciones. Algunos equipos de plataforma que conozco empezaron ese camino y concluyeron que era demasiado costoso de mantener, o simplemente no era donde querían gastar su presupuesto de confiabilidad.
Reducir la carga de guardia es donde vive el apalancamiento de SRE
El ciclo externo no ha alcanzado al ciclo interno porque faltaba la infraestructura para ejecutar herramientas agénticas de forma segura contra sistemas en producción. Un asistente de código solo necesita tu repositorio y tu editor. Un asistente operacional necesita identidad administrada, cómputo hospedado, gobernanza aplicada y una traza de auditoría, porque toca sistemas donde los errores le mandan página al CTO.
Los equipos de SRE que resuelvan esto en el próximo año se separarán de los que no lo hagan, igual que los equipos que adoptaron Claude Code para el trabajo de ciclo interno en 2024 se separaron de los que esperaron. El ciclo interno ya está resuelto. El ciclo externo es donde vive el apalancamiento ahora, apoyado en un sustrato de datos que es su propio problema de diseño.
Claude Code no reemplaza al ingeniero de guardia. Solo le permite empezar en la página 5 en lugar de la página 1.
Preguntas frecuentes
¿Qué es un AI SRE?
Un AI SRE es un asistente de AI que ayuda a los ingenieros de confiabilidad del sitio con trabajo operacional: triaje de incidentes, ejecución de runbooks, redacción de postmortems, investigación de SLOs y handoffs de guardia. La mayoría de los despliegues prácticos de AI SRE funcionan hoy como compañeros que leen, correlacionan y redactan mientras un ingeniero humano decide el siguiente paso, no como agentes autónomos que mandan páginas, remedian y cierran incidentes por su cuenta.
¿Cuál es la diferencia entre un gateway de MCP y un runtime de MCP?
Un gateway de MCP enruta herramientas MCP bajo una sola URL para que cualquier cliente MCP pueda llamarlas. Un runtime de MCP va más lejos: agrega el cómputo que ejecuta las herramientas, autenticación administrada, aplicación de permisos por herramienta y logs de auditoría persistentes. Un gateway es infraestructura de enrutamiento. Un runtime es infraestructura de producción. Arcade.dev es un runtime de MCP con un gateway integrado.
¿Puede Claude Code reemplazar a un ingeniero de guardia?
No. Claude Code funciona mejor como compañero del ingeniero de guardia, no como reemplazo. Comprime la arqueología (extraer alertas, correlacionar señales, redactar resúmenes) para que el ingeniero comience con el contexto ya cargado. Cada decisión que requiere juicio (revertir un deploy, mandar página a un colega, cerrar un incidente) se queda con el humano.
¿Cómo uso Claude Code para el triaje de incidentes?
Apunta Claude Code a la alerta con un prompt como “Triagea esta alerta correlacionada con métricas de Datadog, logs del servicio e historial de despliegues. Busca fallas correlacionadas en Slack.” Con servidores MCP para PagerDuty, Datadog, Slack y GitHub conectados a un runtime de MCP, Claude Code devuelve un resumen, las principales señales correlacionadas, deploys candidatos y un borrador para el war room en dos o tres minutos.
¿Es seguro dejar que Claude Code ejecute runbooks en producción?
Claude Code no debería ejecutar directamente en producción. El patrón más seguro es que Claude Code analice el runbook, plantee la secuencia de diagnóstico y proponga los comandos, mientras el ingeniero de guardia corre cada paso en su propia terminal con sus propias credenciales con alcance limitado. El acceso ilimitado a producción para cualquier agente de código no debería pasar una revisión de confiabilidad.
¿Qué servidores MCP necesito para los workflows de AI SRE?
El conjunto base cubre las herramientas que ya están en la rotación de SRE: PagerDuty, Datadog, Slack y GitHub para triaje de incidentes; Confluence y Kubernetes para ejecución de runbooks; Snowflake para investigación de SLOs; Zendesk para handoffs de guardia. Cada uno tiene un servidor MCP listo para producción que puede correr dentro de un runtime de MCP como Arcade, el cual gestiona autenticación, políticas y logs de auditoría para todos.
¿Cómo funciona Arcade con Claude Code?
Arcade es un runtime de MCP que gestiona OAuth, políticas de permisos por herramienta y logs de auditoría para cada herramienta que llama Claude Code. Conectas PagerDuty, Datadog o Snowflake una vez, y cada sesión de Claude Code en tu equipo toma las herramientas con el alcance correcto. Arcade también ejecuta servidores MCP propios, así que las integraciones existentes funcionan tal cual.
¿Cuál es la diferencia entre herramientas de AI SRE como Traversal y usar Claude Code con un runtime de MCP?
Traversal, Resolve y Anyshift están construyendo agentes autónomos que mandan páginas, remedian y cierran incidentes por su cuenta. Claude Code con un runtime de MCP toma el enfoque de compañero: leer, correlacionar, redactar y esperar a que el ingeniero decida. El patrón de compañero funciona hoy. La apuesta autónoma, todavía no.
¿Importa tanto el almacén de observabilidad por debajo como el runtime de MCP por encima?
Sí. Un agente de AI corre entre 10 y 30 consultas por investigación, y la mayoría de los almacenes de observabilidad no fueron construidos para servir ese patrón con la retención y cardinalidad que necesita un SRE. El runtime de MCP maneja la capa de ejecución; el almacén de observabilidad maneja el sustrato cognitivo. Ambos importan. Escribí sobre el lado del sustrato aquí.
