¿Qué pasa si falla el software?
El tipo de fallo de software más grave es la caída del sistema operativo, ya que detiene todo el sistema informático. Como muchos problemas de software son transitorios, un reinicio suele reparar el problema.
Esto implica reiniciar el sistema operativo, ejecutar un software que repara el estado del disco que podría haberse vuelto inconsistente debido al fallo, recuperar las sesiones de comunicación con otros sistemas en un sistema distribuido y reiniciar todos los programas de aplicación.
Todos estos pasos aumentan el MTTR y, por tanto, reducen la disponibilidad. Por ello, deben realizarse lo más rápido posible. La necesidad de una recuperación más rápida inspiró a los vendedores de sistemas operativos en la década de los 90 a incorporar procedimientos rápidos de recuperación del sistema de archivos, lo cual era un componente importante del tiempo de arranque del sistema operativo.
Algunos sistemas operativos están cuidadosamente diseñados para un arranque rápido. Por ejemplo, los sistemas de comunicación de alta disponibilidad tienen sistemas operativos que se reinician en menos de un minuto, en el peor de los casos.
Llevando este objetivo al extremo, si el tiempo de reparación fuera cero, los fallos no importarían, ya que el sistema se recuperaría instantáneamente y el usuario nunca notaría la diferencia. Está claro que reducir el tiempo de reparación puede tener un gran impacto en la disponibilidad.
Algunos fallos de software sólo degradan las capacidades de un sistema, no lo hacen fallar. Por ejemplo, considere una aplicación que ofrece funciones que requieren acceso a un servicio remoto.
Cuando el servicio remoto no está disponible, esas funciones dejan de funcionar. Sin embargo, mediante un diseño cuidadoso de la aplicación, otras funciones de la misma pueden seguir siendo operativas.
Es decir, el sistema se degrada con gracia cuando algunas partes dejan de funcionar. Un ejemplo real que conocemos es el de una aplicación que utilizaba una base de datos TP y un almacén de datos, donde este último era agradable de tener pero no era de misión crítica.
La aplicación no estaba diseñada para degradarse con gracia, así que cuando el almacén de datos falló, toda la aplicación dejó de estar disponible, lo que causó una gran e innecesaria pérdida de ingresos.
Cuando un proceso de aplicación o un sistema de base de datos falla, el fallo debe ser detectado y el proceso de la aplicación o del sistema de base de datos debe ser recuperado. Aquí es donde las técnicas específicas de TP adquieren relevancia.
