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.

# Estrategias comunes de mitigación
<a name="mitigation-strategies"></a>

Para empezar, valore la posibilidad de utilizar mitigaciones *preventivas* para evitar que el modo de error afecte a la historia del usuario. A continuación, debería pensar en las mitigaciones *correctivas*. Las mitigaciones correctivas ayudan al sistema a recuperarse automáticamente o a adaptarse a los cambios en las condiciones. Esta es una lista de las mitigaciones más comunes para cada categoría de error que se ajustan a las propiedades de resiliencia.


| 
| 
| **Categoría de error** | **Propiedades de resiliencia deseadas** | **Mitigaciones** | 
| --- |--- |--- |
| Únicos puntos de error (SPOF) | Redundancia y tolerancia a errores |   Implemente la [redundancia](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html); por ejemplo, mediante el uso de varias instancias de EC2 detrás de Elastic Load Balancing (ELB).   Elimine las dependencias del [plano de control del servicio global de AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-service-types.html#global-services) y únicamente asuma las dependencias en los planos de datos del servicio global.   Utilice una [degradación estable](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) cuando un recurso no esté disponible, de modo que el sistema se mantenga estable estáticamente ante un único punto de error.   | 
| Carga excesiva | Capacidad suficiente |   Las principales estrategias de mitigación son la [limitación de la velocidad](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems), la [reducción de la carga](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload) y la priorización del trabajo, el [trabajo constante](https://aws.amazon.com/builders-library/reliability-and-constant-work), el [retroceso exponencial y el reintento con inestabilidad](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) o sin reintentos, el [control del servicio más pequeño](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control), la [administración de la profundidad de las colas](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs), el [escalado automático](https://aws.amazon.com/autoscaling/), la [evitación de las cachés inactivas](https://aws.amazon.com/builders-library/caching-challenges-and-strategies) y los [disyuntores de circuitos](https://brooker.co.za/blog/2022/02/16/circuit-breakers.html).   También debe tener en cuenta su plan de capacidad y pensar en los futuros límites de capacidad y escalado, tanto en relación con los recursos de AWS como con los límites del sistema, que podría alcanzar.   | 
| Latencia excesiva | Salida puntual |   Implemente [tiempos de espera](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) configurados adecuadamente o tiempos de espera adaptables (modifique los valores de los tiempos de espera según las condiciones de latencia actuales y previstas para permitir que una dependencia lenta progrese en lugar de renunciar a las solicitudes lentas).   Implemente el [retroceso exponencial y el reintento con inestabilidad](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), coberturas, utilizando tecnologías como el [TCP multiruta](https://en.wikipedia.org/wiki/Multipath_TCP) cuando se conecte a servicios en la nube desde entornos en las instalaciones y experimente latencia en rutas específicas, mediante [interacciones asincrónicas con sistemas con acoplamiento débil](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_loosely_coupled_system.html), [almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies) y [sin desperdiciar trabajo](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/).   | 
| Configuraciones incorrectas y errores | Salida correcta |   La principal manera de detectar errores funcionales y repetibles en el software es mediante pruebas rigurosas mediante mecanismos como el [análisis estático](https://en.wikipedia.org/wiki/Static_program_analysis), las [pruebas unitarias](https://en.wikipedia.org/wiki/Unit_testing), las [pruebas integración](https://en.wikipedia.org/wiki/Integration_testing), las [pruebas de regresión](https://en.wikipedia.org/wiki/Regression_testing), las [pruebas de carga](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html) y las [pruebas de resiliencia](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/).   Implemente estrategias como la [infraestructura como código (IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html) y la [automatización de la integración y la entrega continuas (CI/CD)](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments) para ayudar a mitigar las amenazas de hacer configuraciones incorrectas.   Utilice técnicas de implementación como las implementaciones [en un solo paquete](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/), las [implementaciones canario](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html), las implementaciones fraccionadas que estén alineadas con los límites de aislamiento de errores o las [implementaciones azul/verde](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/blue-green-deployments.html) para reducir los errores y las configuraciones incorrectas.   | 
| Destino compartido | Aislamiento de errores |   Implemente la [tolerancia a errores](https://aws.amazon.com/builders-library/minimizing-correlated-failures-in-distributed-systems) en el sistema y use límites de aislamiento de errores lógicos y físicos, como varios clústeres de computación o de contenedores, varias cuentas de AWS, varias entidades principales de AWS Identity and Access Management (IAM), varias zonas de disponibilidad y, tal vez, varias Regiones de AWS.   Las técnicas como las [arquitecturas basadas en celdas](https://youtu.be/swQbA4zub20) y las [particiones aleatorias](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding) también pueden mejorar el aislamiento de errores.   Tenga en cuenta patrones como el [acoplamiento débil](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_loosely_coupled_system.html) y la [degradación gradual](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) para evitar errores en cascada. Al priorizar las historias de usuario, también puede aprovechar esa priorización para distinguir entre las historias de usuario que son esenciales para la principal función empresarial y las historias de usuario que pueden degradarse de manera estable. Por ejemplo, en un sitio de comercio electrónico, no le interesa que el deterioro del widget de promociones del sitio web afecte a la capacidad de procesar nuevos pedidos.   | 

Si bien algunas de estas medidas de mitigación necesitan un esfuerzo mínimo para implementarlas, otras (como la adopción de una arquitectura basada en celdas para aislar los errores de forma predecible y reducir al mínimo los errores de destino compartido) podrían necesitar un nuevo diseño de toda la carga de trabajo y no solo de los componentes de una historia de usuario concreta. Como se mencionó anteriormente, es importante sopesar las probabilidades y el impacto del modo de error en relación con las concesiones que se deben hacer para mitigarlo.

Además de las técnicas de mitigación que se aplican a cada categoría de modo de error, debe pensar en las mitigaciones necesarias para recuperar la historia del usuario o todo el sistema. Por ejemplo, un error podría detener un flujo de trabajo e impedir que los datos se escribieran en los destinos previstos. En este caso, es posible que deba usar herramientas operativas para volver a impulsar el flujo de trabajo o corregir los datos manualmente. Es posible que también tenga que incorporar un mecanismo de puntos de control a la carga de trabajo para evitar la pérdida de datos en caso de que se produzcan errores. O puede que tenga que crear un cable andon para pausar el flujo de trabajo y dejar de aceptar nuevos trabajos para evitar más daños. En estos casos, debe pensar en las herramientas operativas y las barreras de protección que necesita.

Por último, debe asumir siempre que las personas van a cometer errores a medida que desarrolle una estrategia de mitigación. Si bien las prácticas modernas de DevOps intentan automatizar las operaciones, las personas aún tienen que interactuar con las cargas de trabajo por distintos motivos. Una acción humana incorrecta podría provocar un error en cualquiera de las categorías de SEEMS, como eliminar demasiados nodos durante el mantenimiento y provocar una sobrecarga o configurar incorrectamente una marca de característica. En realidad, estas situaciones son un fracaso de las barreras de protección preventivas. Un análisis de la causa raíz nunca debe terminar con la conclusión de que “un humano ha cometido un error”. En cambio, debe abordar las razones por las que ha sido posible cometer errores en primer lugar. Por lo tanto, la estrategia de mitigación debe considerar cómo los operadores humanos pueden interactuar con los componentes de la carga de trabajo y cómo prevenir o minimizar el impacto de los errores de los operadores humanos mediante barreras de protección.