Sistema de fallo rápido

Este artículo incluye una lista de referencias generales , pero carece de suficientes citas en línea correspondientes . Ayúdenos a mejorar este artículo introduciendo citas más precisas. ( Junio ​​de 2016 ) ( Aprenda cómo y cuándo eliminar este mensaje )

En el diseño de sistemas , un sistema de respuesta rápida a fallos es aquel que informa inmediatamente en su interfaz cualquier condición que pueda indicar un fallo. Los sistemas de respuesta rápida a fallos suelen estar diseñados para detener el funcionamiento normal en lugar de intentar continuar un proceso posiblemente defectuoso. Estos diseños suelen comprobar el estado del sistema en varios puntos de una operación, de modo que cualquier fallo pueda detectarse de forma temprana. La responsabilidad de un módulo de respuesta rápida a fallos es detectar errores y, a continuación, dejar que el siguiente nivel superior del sistema los gestione.

Los sistemas o módulos a prueba de fallos son deseables en varias circunstancias:

• Las arquitecturas fail-fast se basan en una política de manejo de errores donde cualquier error detectado o estado no contemplado hace que el sistema falle (rápido). En cierto sentido, la política de manejo de errores es la opuesta a la que se utiliza en un sistema tolerante a fallos . En un sistema tolerante a fallos, se establece una política de manejo de errores para tener componentes redundantes y mover las solicitudes de cómputo a componentes activos cuando algún componente falla. Paradójicamente, los sistemas fail-fast hacen que los sistemas tolerantes a fallos sean más resilientes. Podemos tener 10 servidores redundantes para una base de datos determinada, pero si la configuración compartida para los 10 servidores se actualiza con datos de autenticación erróneos para los clientes, todos ellos "fallarán de forma redundante". En ese sentido, un sistema fail-fast se asegurará de que todos los 10 servidores redundantes fallen lo antes posible para que DevOps reaccione rápido.
• Los componentes de respuesta rápida a fallos se utilizan a menudo en situaciones en las que el fallo de un componente puede no ser visible hasta que provoca el fallo de otro componente como consecuencia de una inicialización diferida. Por ejemplo, "El sistema que está "condenado" a fallar porque una ruta del sistema de archivos está mal configurada, no falla al iniciarse porque la ruta del sistema de archivos no se comprueba al iniciarse. Solo cuando llega una solicitud del cliente, el sistema falla, al azar, más adelante.
• Encontrar la causa de una falla es más fácil en un sistema que funciona a prueba de fallos, ya que el sistema informa sobre la falla con la mayor cantidad de información posible y lo más cerca posible del momento en que se produce. En un sistema tolerante a fallos, la falla puede pasar desapercibida, mientras que en un sistema que no es tolerante a fallos ni que funciona a prueba de fallos, la falla puede permanecer oculta temporalmente hasta que cause algún problema aparentemente no relacionado más adelante.
• Un sistema de respuesta rápida a fallos, diseñado para detener e informar el error en caso de falla, tiene menos probabilidades de realizar por error una operación irreversible o costosa.

Los desarrolladores también se refieren al código como fail-fast si intenta fallar lo antes posible en una inicialización de variable u objeto. En la programación orientada a objetos , un objeto diseñado fail-fast inicializa el estado interno del objeto en el constructor, lanzando una excepción si algo está mal (en lugar de permitir objetos no inicializados o parcialmente inicializados que fallarán más tarde debido a un "setter" incorrecto). El objeto puede entonces hacerse inmutable si no se esperan más cambios en el estado interno. En funciones, el código fail-fast verificará los parámetros de entrada en la condición previa . En arquitecturas cliente-servidor, fail-fast verificará la solicitud del cliente justo al llegar, antes de procesarla o redirigirla a otros componentes internos, devolviendo un error si la solicitud falla (parámetros incorrectos, ...). El código diseñado fail-fast disminuye la entropía interna del software y reduce el esfuerzo de depuración.

• Una aplicación/sistema a prueba de fallos verifica que todos los recursos de entrada/salida necesarios para cálculos futuros estén listos antes de que llegue cualquier solicitud de cálculo.
• Una aplicación/sistema a prueba de fallos verifica que todas las configuraciones iniciales inmutables sean correctas al iniciarse.
• Una función de falla rápida es una función que verifica todas las entradas a la función en una condición previa antes de continuar con cualquier cálculo o lógica comercial en dicha función.
• Una función de falla rápida normalmente arrojará una excepción en tiempo de ejecución cuando se encuentre algún cálculo anormal, lo que hará que el sistema falle si ningún otro ha contemplado una "captura", en lugar de devolver algún valor de error sin hacer ninguna suposición (optimista) sobre la gestión correcta del error generado.
• Desde el campo de la ingeniería de software , un iterador de falla rápida es un iterador que intenta generar un error si la secuencia de elementos procesados ​​por el iterador cambia durante la iteración .
• Dado un estado inicial en una máquina de estados, un sistema de fallo rápido comprobará dicho estado y fallará rápidamente.
• Dado un cambio de estado en una máquina de estados, el sistema de respuesta rápida detendrá la máquina si el cambio de estado está prohibido. Podría darse el caso de que el cambio de estado prohibido se deba a una entrada externa incorrecta. En ese caso, el sistema de respuesta rápida detendrá el procesamiento de la solicitud tan pronto como detecte la entrada incorrecta (en lugar de delegar en la implementación de la máquina de estados).

El término se ha utilizado ampliamente como metáfora en el ámbito empresarial desde al menos 2001 ^[1], lo que significa que las empresas deberían emprender experimentos audaces para determinar la viabilidad a largo plazo de un producto o estrategia, en lugar de proceder con cautela e invertir años en un enfoque condenado al fracaso. Se adoptó como una especie de "mantra" dentro de la cultura de las empresas emergentes , es decir, "Fallar rápido, fallar a menudo". ^[2]

• Software que solo detecta fallos
• Diseño por contrato
• Fracasar mal vs. fracasar bien
• A prueba de fallos
• Parada de emergencia
• Sistema silencioso ante fallos

• Gray, Jim (1985). "¿Por qué se detienen las computadoras y qué se puede hacer al respecto?". CiteSeerX  10.1.1.110.9127 ,Presentando 'Fail Fast'
• Artículo de Jim Shore sobre el concepto "Fail Fast" que explica el uso del concepto "Fail Fast" en el desarrollo de software (de "Columns for IEEE software" editado por Martin Fowler )