The Delivery Hero Reliability Manifesto (traducción)

Cada punto del contenido me pareció profundamente inspirador, así que no puedo resumirlo fácilmente y solo enumeraré algunos de los que más me impactaron.

• No violar el Manifesto, sino debatir para cambiar las reglas y así hacerlo evolucionar.
• Todos los servicios deben documentarse con diagramas de arquitectura, incluidas sus dependencias, y la arquitectura debe ser revisada.
• Quienes producen datos también deben documentar los datos que generan.
• Incluso los despliegues de los viernes deben funcionar de manera estable.
• Implementar lógica defensiva para escenarios de falla (timeout, reintentos, circuit breaker, fallback, throttling, idempotencia, etc.).
• Crear y monitorear dashboards que permitan conocer el estado del servicio (solicitudes por minuto, tasa de errores, tiempo de respuesta del servidor, métricas de negocio).
• Documentar en un runbook cómo analizar y reproducir incidentes, y vincularlo con las alertas para minimizar el tiempo de recuperación.
• Cuando ocurra un problema, arremangarse y ayudar a resolverlo.
• Entendamos toda conversación escrita asumiendo siempre que existe una intención de actuar de buena fe.
• Para reflejar las acciones relacionadas con seguridad como parte del desempeño del equipo, crear y publicar una tabla de puntajes de seguridad por equipo.
• A medida que aumente el número de pedidos en el sistema, el costo por pedido debe disminuir. Sería ideal que el costo por pedido bajara 10% cada trimestre.
• Monitorear el lead time (desde el inicio del desarrollo hasta el despliegue en producción), la frecuencia de despliegue, el tiempo de recuperación y la tasa de errores durante ese tiempo de recuperación.

Además de esto hay mucho más contenido; al leerlo, también me da curiosidad cuántas personas habrán contribuido para crear algo así... realmente es un texto que provoca una sensación de admiración.