Práctica recomendada 4.3: pruebe periódicamente los planes de continuidad de la empresa y la recuperación de errores - SAP Lens

Práctica recomendada 4.3: pruebe periódicamente los planes de continuidad de la empresa y la recuperación de errores

Los sistemas SAP suelen ser esenciales para las empresas y se depende mucho de ellos para transacciones directas con clientes. Permitir la reanudación rápida de las operaciones de TI y minimizar la pérdida de datos durante un error o ante un desastre es esencial para lograr la excelencia operativa. Se requieren Business Continuity Plans (BCP, planes de continuidad empresariales) y procedimientos de recuperación de errores para asegurarse de que su equipo y sus sistemas de operaciones sepan qué hacer y cuándo hacerlo, y así se puede reanudar el servicio de la carga de trabajo rápidamente en caso de un error.

Para lograr una reanudación exitosa de los servicios es esencial que se prueben, se mejoren y se refinen con regularidad los procedimientos del BCP y los planes de recuperación de errores a medida que el equipo de soporte y los sistemas evolucionan. Probar su BCP y sus planes de recuperación fuera de situaciones de crisis reales garantizará que, cuando se produzca una falla o un desastre reales en el sistema, pueda confiar en su capacidad de reanudar el servicio de manera satisfactoria y en que cumplirá con el Recovery Time Objective (RTO, objetivo de tiempo de recuperación) y con el Recovery Point Objective (RPO, objetivo de punto de recuperación).

Sugerencia 4.3.1: cree un calendario de pruebas de los procedimientos de recuperación de errores y del BCP

Cree un calendario para programar pruebas regulares (como mínimo anuales) de los procedimientos de recuperación de errores y del BCP para su carga de trabajo de SAP. Involucre a equipos operativos de tecnología, personal de soporte y partes interesadas comerciales en esta prueba, de manera que se comprendan los procedimientos y se cumplan las expectativas. Intente probar su sistema en una situación que se asemeje lo máximo posible a la realidad.

Considere probar las siguientes situaciones y validar las métricas de recuperación para cada uno de ellas:

  • Error en el servicio de aplicaciones SAP

    (por ejemplo, el servicio de aplicaciones SAP no se inicia debido a un cambio en la configuración)

  • Error del host de única instancia

    (por ejemplo, la instancia de EC2 del servidor de aplicaciones SAP se torna inaccesible)

  • Error en el volumen de almacenamiento único

    (por ejemplo, un volumen de EBS único se torna inaccesible)

  • Error en la red y conmutación a conexión redundante

    (por ejemplo, su conexión de Direct Connect en las instalaciones es inaccesible)

  • Conmutación por error automatizada entre los componentes agrupados primarios y secundarios

    (por ejemplo, el clúster SUSE HAE fuerza a la base de datos principal de HANA a moverse a la base de datos secundaria en una AZ alternativa)

  • Conmutación por error manual entre componentes primarios y secundarios

    (por ejemplo, invocación manual de la conmutación de Oracle DataGuard a la base de datos secundaria en una AZ alternativa)

  • Balanceador de carga entre múltiples componentes redundantes

    (por ejemplo, el Web Dispatcher principal falla en un par de alta disponibilidad entre las AZ)

  • Recuperación de su aplicación SAP en una región de AWS alterna (si es necesario)

  • Recuperación a partir de la copia de seguridad en caso de ransomware

    (por ejemplo, recuperar todo su sistema SAP ERP desde la copia de seguridad WORM de Amazon S3)

Sugerencia 4.3.2: revise y actualice regularmente el BCP y los procedimientos de recuperación de errores como parte de los cambios en la carga de trabajo

A medida que su carga de trabajo evoluciona y cambia, asegúrese de que se tomen en cuenta el BCP y los procedimientos de recuperación en estos cambios. Cuando un cambio de código o infraestructura podría afectar su RTO o RPO, asegúrese de que la documentación y la configuración estén actualizadas, y de probar el nuevo BCP y proceso de recuperación como parte del proceso de lanzamiento o calendario de prueba regular.