La forma más rápida de matar una prueba de concepto exitosa es entregarla a operaciones sin observabilidad. Has construido algo que funciona. Resuelve el problema. Todos están emocionados. Luego aterriza en producción y el equipo de SRE no tiene idea de cómo monitorearlo, no hay forma de depurarlo, y no tienen confianza de poder hacer rollback si algo se rompe a las 2am.
Seis meses después, todavía está corriendo en la laptop del desarrollador original porque nadie confió lo suficiente para ejecutarlo correctamente. El Proof Sprint tuvo éxito técnicamente y falló organizacionalmente.
Resolvemos esto con lo que llamamos el contrato de telemetría: un conjunto de requisitos no negociables de observabilidad y handoff que se entregan con cada Proof Sprint.
Por qué la telemetría es un problema de entrega, no de ops
La mayoría de los equipos tratan la observabilidad como algo que ops agrega después de la entrega. Los desarrolladores construyen la cosa, la tiran por encima del muro, y el equipo de SRE descubre cómo monitorearla. Esto está al revés.
El contrato de telemetría invierte esto. La observabilidad es un requisito de entrega, no una ocurrencia posterior.
Paridad de señales: tus colectores, tus dashboards
Cada Proof Sprint emite trazas, métricas y logs en los formatos que el cliente ya usa. Si están en Datadog, emitimos a Datadog. Si están en Grafana con Prometheus y Loki, emitimos a esos.
Paridad de señales significa que el Proof Sprint aparece en el mismo lugar donde tu equipo ya está mirando. Mismos dashboards. Mismos canales de alertas. Mismo formato de runbook.
El paquete de evidencia
Cada Proof Sprint incluye un paquete de evidencia: un bundle documentado de artefactos de seguridad y operacionales que adquisiciones y seguridad necesitan para aprobar el despliegue.
El paquete incluye: SBOM (inventario completo de dependencias), reporte SCA (análisis de vulnerabilidades), diff de IAM (permisos exactos requeridos), y documentación de flujo de datos.
Pista para ops: haciendo el Día 2 aburrido
El primer día que un sistema corre en producción es emocionante. El segundo día debería ser aburrido. Si el Día 2 es emocionante, algo está mal.
Diseñamos para Días 2 aburridos. Cada Proof Sprint incluye: plan de despliegue canary, runbooks, procedimientos de rollback, y notas de planificación de capacidad.
Por qué esto importa para el caso de negocio
Los Proof Sprints a menudo mueren en adquisiciones porque el costo total de propiedad no está claro. El contrato de telemetría elimina el riesgo de todo esto por adelantado. Cuando entregamos el Proof Sprint, el equipo de ops ya sabe cómo soportarlo porque están usando sus herramientas existentes.