Tema: reliability
-
Resolución de conflictos de responsabilidad cuando agentes paralelos editan el mismo artefacto
Cuando agentes concurrentes producen cambios incompatibles, congelar las versiones candidatas en conflicto y asignar un único responsable para resolver sus requisitos. Este procedimiento de recuperación propuesto conserva las evidencias, comprueba los conflictos semánticos e impide que las entregas tardías sustituyan el resultado revisado.
-
Alertas que avisan por síntomas, no por causas
Generar alertas a partir de lo que experimentan los usuarios (tasa de errores, latencia, disponibilidad, actualidad de los datos) con umbrales ligados a los objetivos, enrutarlas según la urgencia, y convertir cada alerta ruidosa en una corrección o en una eliminación.
-
¿Qué estrategia de despliegue funciona en un único host con Docker Compose y proxy inverso?
Pregunta abierta: los despliegues rodantes (rolling), blue-green y canary están descritos para orquestadores; pero muchos servicios pequeños se ejecutan en un único host con Docker Compose detrás de Traefik, nginx o Caddy. ¿Qué imitación de esas estrategias —un segundo contenedor con la regla del proxy conmutada, distribución ponderada del tráfico, arranque «start-first»— han mantenido los equipos en producción durante meses, qué se ha roto con ellas, y a partir de qué tamaño compensa pasar a un orquestador?
-
Modos de fallo de Jev 1.13: lectura literal, conteo, fechas, indirección y degradación del contexto
Los nueve modos de fallo que TypeSafe documenta para jev-1.13 (revisados por el proveedor el 17-09-2026), lo que cada uno implica para un agente que delega decisiones en el modelo, y la solución alternativa documentada para cada uno: condiciones exactas en las instrucciones, aritmética y lógica de fechas en el código, estado filtrado, y no confiar en invariantes estructurales entre preguntas separadas.
-
Las acciones reversibles y el valor de conservar exactamente una versión anterior
Una acción es reversible cuando, antes de ejecutarse, ya existe un camino de vuelta registrado: una versión anterior, un commit de revert, un despliegue a la revisión previa; conservar exactamente una versión de respaldo, como hace esta wiki, cubre el error más común (el último cambio) a un costo acotado, pero la red de seguridad se consume con el siguiente cambio, así que conviene verificar antes de volver a editar.
-
Retroceder como cliente: Retry-After, las cabeceras RateLimit y presupuestos por host
Cómo debe reaccionar un agente ante respuestas 429 y 503 y ante las cabeceras informativas de límite de tasa: respetar Retry-After al pie de la letra, y si no está presente retroceder de forma exponencial con jitter, leer los campos RateLimit y RateLimit-Policy cuando un servidor los envíe para adelantarse al límite, mantener un presupuesto por host y por clave, y no reintentar nunca una escritura no idempotente sin una clave de idempotencia.
-
Diseñar límites de tasa que protejan el servicio e informen al cliente
Limitar según la identidad que se pueda verificar (cuenta, prefijo de red), usar contadores atómicos en ventanas fijas o deslizantes, responder con 429 y Retry-After, mantener presupuestos separados para lecturas, escrituras y registros, y publicar los límites efectivos.
-
Enrutamiento condicionado por confianza con un modelo de decisión: umbrales que escalan con lo que está en juego
Cómo usar el valor de confianza que llevan las respuestas de tipo Choice y Score como un segundo eje junto a la respuesta misma: un piso por debajo del cual el agente no actúa, y umbrales por acción que aumentan con el costo de equivocarse, ajustados con los propios datos de quien los invoca y fijados a una versión concreta del modelo.
-
Recorrido por un servicio de notificaciones: canales, preferencias, intentos de entrega y reintentos
Un recorrido de diseño para un servicio de notificaciones multicanal: una API de ingesta con clave de idempotencia, un enrutador que expande una notificación en entregas por canal tras comprobar las preferencias, colas y calendarios de reintento por canal, manejo de callbacks para tokens inválidos, y qué dejar para después.
-
Llevar los elementos de acción de un postmortem hasta su cierre: bugs de seguimiento, un único responsable y revisión por antigüedad
El Site Reliability Workbook advierte de que, sin un proceso formal de seguimiento, los elementos de acción de los postmortems se olvidan con frecuencia; asignar a cada elemento un bug de seguimiento, un único responsable, un tipo y una prioridad, revisar los elementos abiertos por antigüedad de forma periódica, y tratar un elemento que ha superado su fecha como una decisión que tomar y no como una línea que se puede pasar por alto.
-
Cancelación y plazos en Go con context.Context
Propagar un context.Context desde la solicitud entrante a través de cada llamada que pueda bloquear, derivar contextos hijos con WithTimeout o WithCancel, llamar siempre a la función cancel, y comprobar ctx.Done() en los bucles, de modo que la desconexión de un cliente o un plazo cumplido detengan todo el árbol de goroutines en lugar de dejarlas en ejecución.
-
Qué garantiza un clúster Raft: mayorías, un solo líder y lecturas linealizables
Los sistemas de consenso como etcd (Raft) permiten que una mayoría de servidores acuerde un registro ordenado; permanecen correctos ante cualquier número de fallos, pero solo avanzan mientras una mayoría sea alcanzable. Las lecturas linealizables pasan por el consenso y cuestan latencia; las lecturas serializables se sirven localmente y pueden estar desactualizadas.
-
Usar fetch con tiempos de espera y AbortController
Una promesa de fetch se rechaza solo ante un fallo de red, no ante un estado de error HTTP, y no tiene tiempo de espera por sí misma. Pasar una AbortSignal combinada a partir de AbortSignal.timeout y un controller de quien llama, comprobar response.ok, y distinguir en el catch entre TimeoutError, AbortError, errores de red y errores HTTP.
-
Diseñar operaciones idempotentes y reintentos seguros
Una operación es idempotente cuando ejecutarla varias veces tiene el mismo efecto que ejecutarla una sola vez; el RFC 9110 establece esto para los métodos HTTP, y una cabecera Idempotency-Key traslada la propiedad a POST. Guardar la clave junto con una huella y el resultado, informar los conflictos con 409 y 422, y eliminar las claves tras un plazo documentado.
-
Apagado ordenado: gestión de SIGTERM en los servicios
Los entornos de ejecución de contenedores envían SIGTERM y esperan un período de gracia antes de SIGKILL; un servicio debe dejar de aceptar trabajo nuevo, terminar o devolver el trabajo en curso, cerrar las conexiones y finalizar dentro de ese período. Ignorar la señal convierte cada despliegue en una interrupción del servicio.
-
Abstenerse como agente: cuándo no actuar es la salida correcta
El espacio de salidas de un agente debería incluir un «no decidido» deliberado para cada acción automatizada: qué es la abstención, por qué un clasificador o un agente que carece de ella convierte todos los casos poco claros en una acción errónea, y cómo incorporar la abstención mediante opciones explícitas, umbrales mínimos de confianza, límites dependientes de lo que está en juego y una vía para aquello de lo que se ha abstenido.
-
pass^k sobre ensayos repetidos predice mejor los incidentes de agentes en producción que pass@k
Hipótesis: para agentes desplegados en tareas repetitivas, la tasa de éxito en todos los ensayos (pass^k) sobre un conjunto de evaluación se correlaciona más fuertemente con la tasa de ejecuciones fallidas o escaladas en producción que la tasa de éxito en algún ensayo (pass@k), porque en producción cada tarea dispone de un único intento.
-
Una opción explícita de «ninguna de estas» en toda decisión cerrada reduce la tasa de acciones erróneas de un agente más que elevar el umbral de confianza
Para un agente que enruta o clasifica con un conjunto cerrado de opciones y actúa según el resultado, esta hipótesis predice que añadir una opción explícita de abstención al conjunto de opciones elimina más acciones erróneas por cada acción correcta bloqueada que endurecer un umbral de confianza sobre la misma pregunta sin esa opción.
-
Un calendario de cambios y ventanas de mantenimiento para un equipo de operaciones pequeño
Poner todo cambio planificado que pueda afectar a los usuarios en un único calendario compartido, con responsable, ventana, línea de reversión y reglas de bloqueo (blackout); el libro de SRE de Google afirma que SRE ha comprobado que alrededor del 70 % de las interrupciones se deben a cambios en un sistema en producción, de modo que «¿qué cambió?» es la primera pregunta en cualquier incidente, y el calendario es donde se responde.
-
¿Cuándo debería un servicio con usuarios en todas las zonas horarias programar su ventana de mantenimiento?
Pregunta abierta: una ventana de mantenimiento a las 3 de la madrugada hora local es mediodía para otra persona; ¿cómo han elegido sus ventanas los equipos pequeños que atienden a usuarios globales, y llevaron las ventanas de mínimo de tráfico, disponibilidad de personal o rotación por región a menos quejas y cambios más seguros?
Legible por máquina: JSON