Respuesta.

Historia de la pregunta

Con la transición a arquitecturas de microservicios y sistemas distribuidos, la probabilidad de errores en la interacción entre servicios ha aumentado drásticamente, así como la complejidad de su manejo. Los enfoques anteriores a menudo no consideraban la inestabilidad de la interacción en red, lo que llevó a incidentes masivos en producción.

Problema

El problema clave es que los escenarios complejos de fallos, degradación de servicios y errores de integración no están suficientemente formalizados en los requisitos. Debido a esto, los desarrolladores deben tomar decisiones sobre el manejo de errores a su discreción, lo que resulta en heterogeneidad de casos y dificultades para probarlos.

Solución

Una descripción efectiva del manejo de errores debería incluir:

• Identificación de tipos de errores (fallos de red, timeouts, fallo de terceros, errores de lógica empresarial, inconsistencia de datos).
• Especificación de las opciones de respuesta para cada tipo de error: reintentos, reversión de transacciones, degradación de funcionalidad, alertas, mensajes al usuario.
• Introducción de escenarios claros para pruebas de fallo (fail-over, degradación elegante), incluyendo incidentes no específicos y en cadena.
• Documentación de contratos y formatos de errores (por ejemplo, contrato JSON estándar para la respuesta de error).

Características clave:

• Estandarización de plantillas de manejo de errores entre servicios.
• Validación de escenarios de degradación y su alineación con el negocio.
• Garantizar el seguimiento de errores y el registro para el análisis posterior de incidentes.

Preguntas capciosas.

¿Es necesario describir el manejo de errores técnicos en los requisitos — no es tarea del desarrollador?

Es necesario. La política de manejo de errores no reflejada a menudo conduce a fallos operativos y malentendidos. Un analista de sistemas debe discutir el comportamiento ante errores.

¿Es necesario describir casos que ocurren muy raramente (por ejemplo, pérdida parcial de conexión entre servicios)?

Sí, porque los errores que ocurren raramente pueden llevar a los incidentes más complejos. Sus consecuencias pueden ser críticas para el negocio.

¿Es necesario coordinar con el negocio los mensajes que se muestran a los usuarios en caso de errores?

Sí. Los mensajes deben ser correctos, informativos, pero no excesivos o alarmantes, y deben ser coordinados con el negocio; de lo contrario, se afecta la experiencia y lealtad del usuario.

Errores típicos y anti-patrones

• Describir solo el happy path, ignorando los escenarios de fallo.
• No considerar la degradación del sistema (escenarios de respaldo no documentados).
• Mensajes de error no coordinados o técnicamente complejos para el usuario.

Ejemplo de la vida real

Caso negativo: En el proyecto no se describieron los escenarios de manejo de timeouts entre servicios. Como resultado de una red inestable, los servicios "se colgaban" sin respuesta. Pros: Ejecución rápida de los escenarios principales. Contras: Fallos masivos en producción, descontento de los clientes, cierre "manual" de incidentes.

Caso positivo: El analista documentó los escenarios de degradación y reinicios, reintentos y mensajes correctos. Pros: Alta estabilidad del servicio ante fallos, disminución del número de emergencias. Contras: Más tiempo dedicado al desarrollo de la arquitectura de los escenarios.