

# Práctica recomendada 11.4: realice pruebas periódicas de resiliencia
<a name="best-practice-11-4"></a>

Pruebe periódicamente la resiliencia en situaciones de errores críticos para demostrar que el software y los procedimientos tienen un resultado predecible. Evalúe cualquier cambio en la arquitectura, software o personal de soporte para determinar si es necesario realizar pruebas adicionales.

 **Sugerencia 11.4.1: defina las situaciones de error críticas dentro de su alcance en función de los requisitos de su empresa** 

 Debe definir qué situaciones de error críticas puede probaren función de sus requisitos empresariales. Los siguientes son ejemplos de situaciones de error que podrían servir de guía para su análisis. La granularidad, cobertura, clasificación o impacto de las situaciones variarán según sus requisitos y arquitectura. 

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/sap-lens/best-practice-11-4.html)

 **Sugerencia 11.4.2: defina un conjunto de casos de prueba para simular errores críticos** 

Debería tener un conjunto completo de pruebas definidas para simular las situaciones de error críticas que afectarían su carga de trabajo de SAP.

Debe tener en cuenta que, para algunas situaciones de error, es posible que una simulación no represente completamente el error real que ocurriría. Por ejemplo, para simular un problema de hardware, no puede causar un error en una instancia de EC2, pero, en el caso de las instancias basadas en Nitro, puede generar un pánico del kernel para que la instancia se reinicie.

 Además, [AWS Fault Injection Simulation](https://aws.amazon.com/fis/) está diseñado para ayudar a simular errores dentro de sus recursos de AWS. 
+  Documentación de AWS: [Guía de configuración de alta disponibilidad para SAP HANA on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-ha-configuration.html) 
+  Documentación de AWS: [Enviar una interrupción de diagnóstico](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/diagnostic-interrupt.html#diagnostic-interrupt-prereqs) 

 **Sugerencia 11.4.3: defina el comportamiento esperado para cada caso de prueba** 

Debería documentar una serie de resultados esperados que sirvan como estándares de referencia de sus pruebas.

 **Sugerencia 11.4.4: defina un enfoque para evaluar el impacto de un cambio y las pruebas posteriores requeridas** 

Debería definir un enfoque para evaluar el impacto de un cambio en su entorno y el número de pruebas que se deben realizar tras ese cambio con el fin de garantizar que no invalide su enfoque de disponibilidad y fiabilidad. Entre algunos ejemplos de cambios, se incluyen actualizaciones de software, revisiones y cambios de parámetros.

 **Sugerencia 11.4.5: defina un cronograma de pruebas** 

Asegúrese de contar con un cronograma de pruebas en el que se contemple la implementación inicial, las pruebas de los cambios y la validación periódica de su entorno.

 **Sugerencia 11.4.6: revise los resultados de las pruebas** 

Según los resultados de la prueba, identifique cualquier mejora en los casos de prueba, la configuración o la arquitectura.

 **Sugerencia 11.4.7: defina las actividades requeridas para hacer una reversión a un estado previo a la prueba** 

En cada prueba, debe definir las actividades necesarias para revertir el estado anterior a la prueba. Esto es para garantizar que cada caso de prueba esté aislado de otras pruebas y que la prueba no afecte la disponibilidad y fiabilidad de un sistema de producción.