Una interrupción del servicio en producción suele tener su origen en decisiones del proyecto que parecían razonables hasta que el sistema se enfrentó a una carga real. El incumplimiento de los SLO (Objetivos de Nivel de Servicio) se manifiesta tras el lanzamiento debido a que la integración se realizó tarde, las dependencias se trataron como meras suposiciones y nadie asumió la responsabilidad del comportamiento integral del sistema (end-to-end).
El riesgo de ejecución aumenta cuando la responsabilidad no está clara. Un equipo lanza la versión v1 de un servicio, otro se encarga de las guardias (on-call) y un tercero controla el esquema upstream; como resultado, un pequeño cambio pasa inadvertido en la revisión y desencadena reintentos, acumulación de colas y latencia en cascada. El proyecto entregó las funcionalidades, pero el sistema de entrega no logró controlar el alcance del fallo.
Un plan de entrega funciona mejor cuando se asemeja a un diagrama de arquitectura simplificado. Este vincula el objetivo del producto con el alcance técnico, asigna responsabilidades y hace explícitas las dependencias externas, permitiendo así que la integración se realice con la antelación suficiente para corregir el rumbo si fuera necesario.
Utilice el diagrama para identificar los puntos donde es preciso tomar decisiones y generar evidencias. Dichas evidencias suelen constituir puntos de control, como el resultado de una prueba de carga, la superación de pruebas de contrato o la aprobación de disponibilidad de una dependencia que condiciona el paso a la siguiente fase.
Interactúe con el diagrama para visualizar cómo se conectan el objetivo, el alcance, las responsabilidades de los equipos, las dependencias y los puntos de control.
El diagrama hace visible el sistema de entrega al mostrar qué componente genera un resultado para el siguiente. Cuando un nodo de dependencia carece de responsable o no existe un punto de control previo a la integración, el riesgo deja de estar identificado en una etapa conocida y pasa a descubrirse tardíamente durante el despliegue.
Es más fácil gestionar las compensaciones (trade-offs) cuando se identifican las palancas y se prevé su efecto en el sistema. El alcance modifica la carga de trabajo; el tiempo determina cuánta incertidumbre se puede eliminar; la calidad afecta la tasa de defectos que llegan a producción; el riesgo define el nivel de variabilidad aceptado; y la deuda técnica determina cuánto trabajo futuro se adelanta o se pospone.
Una regla útil es que cualquier ajuste en una palanca debe reflejarse en al menos uno de los siguientes resultados:
Compare los cambios en las palancas y sus resultados previstos en la tabla.