Descripción de las concesiones y de los riesgos
Las arquitecturas resilientes deben usar una serie de mecanismos probados, simples y fiables para responder a los errores. Para lograr los niveles más altos de resiliencia, las cargas de trabajo deben detectar tantos modos de error como sea posible y recuperarse de ellos automáticamente. Hacerlo requiere una gran inversión para realizar un análisis de resiliencia. Esto significa que para lograr niveles más altos de resiliencia hay que hacer concesiones. Sin embargo, a medida que siga haciendo concesiones, llegará a un punto de rentabilidad decreciente en relación con los objetivos de resiliencia. Estas son las concesiones más habituales:
-
Costo: los componentes redundantes, la mejora de la observabilidad, las herramientas adicionales o el aumento de la utilización de recursos se traducirán en un aumento de costos.
-
Complejidad del sistema: detectar los modos de error y responder a ellos, así como las soluciones de mitigación y, posiblemente, no utilizar servicios administrados aumentan la complejidad del sistema.
-
Esfuerzo de ingeniería: los desarrolladores necesitan más horas de trabajo para crear soluciones que detecten los modos de error y respondan a ellos.
-
Sobrecarga operativa: supervisar y utilizar un sistema que gestione más modos de error puede aumentar la sobrecarga operativa, especialmente cuando no se pueden usar servicios administrados para mitigar modos de error específicos.
-
Latencia y coherencia: para crear sistemas distribuidos que favorezcan la disponibilidad hay que hacer concesiones en términos de coherencia y latencia, como se describe en el teorema de PACELC
.
Al considerar las mitigaciones de los modos de error identificados en la historia de usuario, considere las concesiones que tendrá que hacer. Al igual que con la seguridad, la resiliencia supone un problema de optimización. Debe tomar la decisión de si evitar, mitigar, transferir o aceptar los riesgos que plantea el error identificado. Es posible que haya algunos modos de error que pueda evitar, un grupo que acepte y algunos que pueda transferir. Puede optar por mitigar muchos de los modos de error que identifique. Para determinar qué enfoque adoptar, haga una evaluación con estas dos preguntas: ¿Cuál es la probabilidad de que se produzca el error? ¿Cuál es el impacto en la carga de trabajo si se produce?
La probabilidad es la plausibilidad de que ocurra un evento. Por ejemplo, si la historia de usuario tiene un componente que funciona en una sola instancia de Amazon Elastic Compute Cloud (Amazon EC2), es posible que el componente sufra interrupciones en algún momento del funcionamiento del sistema, tal vez debido a procedimientos de aplicación de revisiones o a errores del sistema operativo. Como alternativa, una base de datos administrada en Amazon Relational Database Service (Amazon RDS) que sincroniza datos entre las instancias principales y secundarias tiene una baja probabilidad de dejar de estar disponible en su totalidad.
El impacto es una estimación del daño que puede causar un evento. Debe evaluarse tanto desde el punto de vista financiero como de la reputación, y depende del valor de las historias del usuario a las que afecta. Por ejemplo, una base de datos sobrecargada podría tener un impacto significativo en la capacidad de un sistema de comercio electrónico para aceptar pedidos nuevos. Sin embargo, perder una sola instancia en una flota de 20 instancias detrás de un equilibrador de carga probablemente tendría muy poco impacto.
Puede comparar las respuestas a estas preguntas con el costo de las concesiones que debe hacer para mitigar el riesgo. Si tiene en cuenta esta información a la vista del umbral de riesgo y los objetivos de resiliencia, le servirá de base para decidir qué modos de error planea mitigar activamente.
