Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Comprender las compensaciones y los riesgos
Las arquitecturas resilientes deben usar un puñado de mecanismos probados, simples y confiables para responder a las fallas. Para lograr los niveles más altos de resiliencia, las cargas de trabajo deben detectar y recuperarse automáticamente de tantos modos de falla como sea posible. Hacerlo requiere una gran inversión en la realización de un análisis de resiliencia. Esto significa que lograr niveles más altos de resiliencia implica hacer concesiones. Sin embargo, a medida que sigas haciendo concesiones, llegarás a un punto de rentabilidad decreciente en relación con tus objetivos de resiliencia. Estas son las compensaciones más habituales:
-
Costo: los componentes redundantes, la mejora de la observabilidad, las herramientas adicionales o el aumento de la utilización de los recursos se traducirán en un aumento de los costos.
-
Complejidad del sistema: detectar los modos de falla y responder a ellos, incluidas las soluciones de mitigación, y, posiblemente, no utilizar servicios gestionados 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 fallo y respondan a ellos.
-
Sobrecarga operativa: monitorear y operar un sistema que maneja más modos de falla puede aumentar la sobrecarga operativa, especialmente cuando no se pueden usar servicios administrados para mitigar modos de falla específicos.
-
Latencia y coherencia: la creación de sistemas distribuidos que favorezcan la disponibilidad requiere sacrificar coherencia y latencia, como se describe en el teorema de PACELC.
Al considerar las mitigaciones de los modos de falla identificados en la historia de usuario, considere las compensaciones que debe hacer. Al igual que ocurre con la seguridad, la resiliencia es un problema de optimización. Debe tomar la decisión de evitar, mitigar, transferir o aceptar los riesgos que plantea la falla identificada. Puede que haya algunos modos de fallo que puedas evitar, un conjunto que aceptes y algunos que puedas transferir. Puede optar por mitigar muchos de los modos de error que identifique. Para determinar qué enfoque adoptar, realice una evaluación planteándose dos preguntas: ¿Cuál es la probabilidad de que se produzca la falla? ¿Cuál es el impacto en la carga de trabajo si se produce?
La probabilidad es qué tan plausible es 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 se interrumpa en algún momento del funcionamiento del sistema, tal vez debido a procedimientos de aplicación de parches o errores del sistema operativo. Como alternativa, una base de datos gestionada por Amazon Relational Database Service (Amazon RDS) que sincroniza datos entre sus instancias principal y secundaria tiene una baja probabilidad de dejar de estar completamente disponible.
El impacto es una estimación del daño que puede causar un suceso. Debe evaluarse tanto desde una perspectiva financiera como de reputación, y es relativa al valor de las historias de los usuarios 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 nuevos pedidos. Sin embargo, la pérdida de una sola instancia de una flota de 20 instancias detrás de un balanceador de carga probablemente tendría muy poco impacto.
Puede comparar las respuestas a estas preguntas con el costo de las compensaciones que debe hacer para mitigar el riesgo. Si tiene en cuenta esta información a la vista de su umbral de riesgo y sus objetivos de resiliencia, le servirá de base para decidir qué modos de falla planea mitigar activamente.
