Práctica recomendada 11.4: realice pruebas periódicas de resiliencia
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.
| Ejemplos de situaciones de error | Riesgo comparativo de ocurrencia |
|---|---|
| Mantenimiento planificado o controlado | Planificado |
| Recurso agotado o comprometido (uso elevado de la CPU/sistema de archivos lleno/memoria insuficiente/problemas de almacenamiento) | Medio |
| Error de componente distribuido sin estado (por ejemplo, despachadores web) | Medio |
| Error de componente distribuido con estado (por ejemplo, servidores de aplicaciones) | Medio |
| Único punto de error (base de datos o servicios centrales de SAP) | Medio |
| Error de red o de AZ | Bajo |
| Error en servicio central (DNS/Amazon EFS/llamada a la API) | Bajo/medio |
| Corrupción/eliminación accidental/actividades maliciosas/implementación de código defectuoso | Bajo |
| Error de región | Muy bajo |
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
-
Documentación de AWS: Guía de configuración de alta disponibilidad para SAP HANA on AWS
-
Documentación de AWS: Enviar una interrupción de diagnóstico
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.
