La regla suena simple: un SRE dedica menos de la mitad de su tiempo al toil y el resto al trabajo de ingeniería. En el mismo capítulo hay una segunda cifra que casi nunca se cita. Las encuestas trimestrales dentro de Google situaban el toil medio en torno al 33%: la organización vive bastante por debajo de su propio límite. Ese 50% no es un presupuesto que haya que gastar, sino una línea a partir de la cual se empieza a mirar qué se rompió.
Y hay una tercera cifra, la más incómoda.
El techo tiene suelo
La guardia genera toil que no se puede automatizar, porque consiste en estar disponible. El libro hace la cuenta de forma explícita: en una rotación de seis personas cada una cubre dos semanas de seis —primary y secondary—, con lo que el límite inferior del toil queda en 2/6, cerca del 33%. Con ocho personas es 2/8, un 25%.
De la misma fórmula se deduce algo que el libro no dice. Cuatro personas de guardia con la misma estructura de turnos dan 2/4, exactamente el 50%. El equipo está en el techo antes de abrir la cola de tickets. Tres personas dan un 67%, y eso ya no es un problema de automatización.
La salvedad es importante: la aritmética cuenta primary más secondary. Donde no existe segunda línea y una sola persona lleva el turno, el límite es la mitad: 1/N. Aun así, un 25% con cuatro personas significa que el calendario ya consume la mitad del presupuesto permitido.
Para un equipo de plataforma pequeño la conclusión es incómoda: «tenemos demasiada rutina» describe muchas veces el tamaño de la rotación y no la calidad de las herramientas. Ningún agente cambia el 2/4.
Qué quita de verdad un agente de IA
El mismo texto ordena las fuentes de toil. En primer lugar no están los incidentes, sino las interrupciones: consultas no urgentes sobre el servicio, correos y mensajes. Después llegan las respuestas urgentes de guardia, y solo entonces las releases y los despliegues.
El primer puesto es justo el trabajo que termina en una investigación sin ningún cambio. «¿Esta versión llegó a producción?», «por qué se reinicia el pod», «qué cambió en la última hora», «sigue el drift en este clúster». La respuesta ya está en el clúster, en las métricas y en el historial de despliegues; una persona gasta minutos más un cambio de contexto, y el sistema queda después en el mismo estado: la definición de toil se cumple por completo.
Un agente de solo lectura encaja aquí: responde sin modificar nada y la decisión sigue siendo humana. La mecánica de ese acceso es otra conversación; lo interesante aquí es la contabilidad.
La trampa: «aquí hace falta criterio»
La forma habitual de sacar trabajo del presupuesto de toil es decir que requiere criterio humano. El libro cierra ese resquicio en una nota al pie: lo que hay que comprobar es si el criterio es intrínseco a la tarea o si hace falta porque el sistema se diseñó mal. Un servicio que llama varias veces al día a quien está de guardia para una respuesta compleja aparece allí descrito como mal diseñado, y esa respuesta sigue siendo toil hasta que el rediseño se despliega.
De ahí un riesgo que conviene sopesar antes de la adopción y no después. Un agente que ejecuta ese análisis a diario en lugar de una persona vuelve cómodo un sistema mal diseñado. El toil medido en minutos-persona baja. La causa que lo produjo sigue donde estaba, y la presión por rediseñar se va junto con el dolor.
La consecuencia práctica está en qué se cuenta. Los minutos mostrarán una mejora, porque los minutos son exactamente lo que se llevó el agente. Cuente el número de investigaciones: cuántas veces por semana alguien —persona o agente— tuvo que averiguar por qué el sistema está en ese estado. Esa cifra no se mueve al instalar un agente, pero sí al arreglar la causa. Cómo una métrica se convierte en objetivo y deja de funcionar, lo traté aparte.
Solo lectura no es sinónimo de seguro
Hay un detalle donde fallan los roles hechos a mano. El ClusterRole view integrado en Kubernetes niega los Secrets a propósito: leer el contenido de un secreto entrega credenciales de ServiceAccount y la posibilidad de llamar a la API con esa identidad. La documentación clasifica eso como escalada de privilegios, no como lectura.
Un rol montado a mano como «get, list, watch sobre todo» incluye los secretos. Sobre el papel es de solo lectura, y en la práctica le da al agente material para actuar en nombre ajeno. Todo lo leído acaba además en el contexto del modelo —logs, variables de entorno, configuraciones—, por lo que las alertas ruidosas conviene arreglarlas antes de conectar un agente y no después (sobre los modos de disparo).
Qué hacer con esto
Calcule su propio suelo: tamaño de la rotación y si existe una secondary. Si queda cerca del 50%, la conversación sobre agentes es prematura: primero el calendario de guardias. Si hay margen, entregue al agente las interrupciones: la mayor fuente individual de toil y la única donde leer resuelve la tarea entera. Y lleve un recuento aparte de investigaciones, para distinguir una causa arreglada de una bien escondida.