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.
Etapa 1: Establecer objetivos
Entender qué nivel de resiliencia se necesita y cómo se medirá es la base de la fase de objetivos establecidos. Es difícil mejorar algo si no tienes un objetivo y no puedes medirlo.
No todas las aplicaciones necesitan el mismo nivel de resiliencia. Cuando establezca los objetivos, tenga en cuenta el nivel necesario para realizar las inversiones y las compensaciones correctas. Una buena analogía para esto es un automóvil: tiene cuatro neumáticos pero solo lleva un neumático de repuesto. La probabilidad de que se pinchen varias llantas durante un viaje es baja, y tener piezas de repuesto adicionales podría reducir otras características, como el espacio de carga o la eficiencia de combustible, por lo que es una compensación razonable.
Una vez definidos los objetivos, se implementan controles de observabilidad en etapas posteriores (etapa 2: diseño e implementación y etapa 4: operación) para comprender si los objetivos se están cumpliendo.
Mapeo de aplicaciones críticas
La definición de los objetivos de resiliencia no debería ser exclusivamente una conversación técnica. En su lugar, comience con un enfoque orientado a los negocios para comprender lo que debe ofrecer la aplicación y las consecuencias de su deterioro. Esta comprensión de los objetivos empresariales se extiende luego a áreas como la arquitectura, la ingeniería y las operaciones. Cualquier objetivo de resiliencia que defina puede aplicarse a todas sus aplicaciones, pero la forma en que se miden los objetivos suele variar en función de la función de la aplicación. Es posible que esté ejecutando una aplicación fundamental para la empresa y, si esta aplicación no funciona correctamente, su organización podría perder importantes ingresos o sufrir daños en su reputación. Como alternativa, es posible que tenga otra aplicación que no sea tan crítica y que pueda tolerar algunos tiempos de inactividad sin que ello afecte negativamente a la capacidad de la organización para hacer negocios.
Como ejemplo, piense en una aplicación de gestión de pedidos para una empresa minorista. Si los componentes de la aplicación de gestión de pedidos están estropeados y no funcionan correctamente, no se realizarán nuevas ventas. Esta empresa minorista también tiene una cafetería para sus empleados ubicada en uno de sus edificios. La cafetería tiene un menú en línea al que los empleados pueden acceder en una página web estática. Si esta página web deja de estar disponible, algunos empleados podrían quejarse, pero no necesariamente causaría un daño financiero a la empresa. Según este ejemplo, es probable que la empresa opte por fijar objetivos de resiliencia más ambiciosos para la aplicación de gestión de pedidos, pero no realizará una inversión significativa para garantizar la resiliencia de la aplicación web.
Identificar las aplicaciones más críticas, dónde aplicar el mayor esfuerzo y dónde hacer concesiones es tan importante como poder medir la resiliencia de una aplicación en la producción. Para comprender mejor el impacto de la discapacidad, puede realizar un análisis del impacto empresarial (BIA). Un BIA proporciona un enfoque estructurado y sistemático para identificar y priorizar las aplicaciones empresariales críticas, evaluar los posibles riesgos e impactos e identificar las dependencias de apoyo. La BIA ayuda a cuantificar el costo del tiempo de inactividad de las aplicaciones más importantes de su organización. Esta métrica ayuda a describir cuánto costará si una aplicación específica se ve afectada y no puede completar su función. En el ejemplo anterior, si la aplicación de gestión de pedidos está dañada, la empresa minorista podría perder ingresos significativos.
Mapeo de historias de usuarios
Durante el proceso de BIA, es posible que descubra que una aplicación es responsable de más de una función empresarial o que una función empresarial requiere varias aplicaciones. Siguiendo el ejemplo anterior de una empresa minorista, la función de gestión de pedidos puede requerir aplicaciones independientes para el pago, la promoción y la fijación de precios. Si una aplicación falla, el impacto podría recaer en la empresa y en los usuarios que interactúan con la empresa. Por ejemplo, es posible que la empresa no pueda añadir nuevos pedidos, ofrecer acceso a promociones y descuentos o actualizar el precio de sus productos. Estas diferentes funciones que requiere la función de gestión de pedidos pueden depender de varias aplicaciones. Estas funciones también pueden tener múltiples dependencias externas, lo que hace que el proceso de lograr una resiliencia centrada exclusivamente en los componentes sea demasiado complejo. Una mejor manera de gestionar este escenario es centrarse en las historias de los usuarios
Centrarse en las historias de los usuarios le ayuda a comprender qué aspectos de la experiencia del cliente son los más importantes, de modo que puede crear mecanismos de protección contra amenazas específicas. En el ejemplo anterior, una historia de usuario podría ser el proceso de pago, que implica la aplicación de pago y depende de la aplicación de precios. Otra historia de usuario podría consistir en la visualización de promociones, lo que implica la solicitud de promoción. Tras mapear las aplicaciones más importantes y sus historias de usuario, puede empezar a definir las métricas que utilizará para medir la resiliencia de esas historias de usuario. Estas métricas se pueden aplicar a toda una cartera o a historias de usuarios individuales.
Definir las medidas
Los objetivos de punto de recuperación (RPO), los objetivos de tiempo de recuperación (RTO) y los objetivos de nivel de servicio (SLO) son medidas estándar del sector que se utilizan para evaluar la resiliencia de un sistema determinado. El RPO se refiere a la cantidad de pérdida de datos que la empresa puede tolerar en caso de una falla, mientras que el RTO es una medida de la rapidez con la que una aplicación debe volver a estar disponible después de una interrupción. Estas dos métricas se miden en unidades de tiempo: segundos, minutos y horas. También puede medir la cantidad de tiempo durante el cual la aplicación funciona correctamente; es decir, realiza sus funciones tal y como está diseñada y es accesible para sus usuarios. Estos SLO detallan el nivel de servicio esperado que recibirán los clientes y se miden mediante métricas como el porcentaje (%) de solicitudes que se atienden sin errores en un tiempo de respuesta inferior a un segundo (por ejemplo, el 99,99% de las solicitudes recibirán una respuesta cada mes). El RPO y el RTO están relacionados con las estrategias de recuperación ante desastres, ya que se supone que se producirán interrupciones en el funcionamiento de las aplicaciones y los procesos de recuperación, desde la restauración de las copias de seguridad hasta la reorientación del tráfico de usuarios. Los SLO se abordan mediante la implementación de controles de alta disponibilidad, que tienden a reducir el tiempo de inactividad de una aplicación.
Las métricas de los SLO se utilizan habitualmente en la definición de los acuerdos de nivel de servicio (SLA), que son contratos entre los proveedores de servicios y los usuarios finales. Los SLA suelen incluir compromisos financieros y describen las sanciones que debe pagar el proveedor si no se cumplen estos acuerdos. Sin embargo, un SLA no es una medida de tu postura de resiliencia, y aumentar un SLA no hace que tu aplicación sea más resiliente.
Puede empezar a establecer sus objetivos en función de los SLO, los RPO y los RTO. Una vez que haya definido sus objetivos de resiliencia y haya obtenido una comprensión clara de sus objetivos de RPO y RTO, podrá realizar una evaluación de su arquitectura AWS Resilience Hub
Creación de medidas adicionales
El RPO, el RTO y los SLO son buenos indicadores de resiliencia, pero también puedes pensar en los objetivos desde una perspectiva empresarial y definirlos en torno a las funciones de tu aplicación. Por ejemplo, tu objetivo podría ser: los pedidos realizados por minuto se mantendrán por encima del 98% si la latencia entre mi interfaz y mi servidor aumenta un 40%.O bien: las transmisiones iniciadas por segundo permanecerán dentro de una desviación estándar con respecto a la media, incluso si se pierde un componente específico. También puede crear objetivos para reducir el tiempo medio de recuperación (MTTR) en los tipos de errores conocidos; por ejemplo: los tiempos de recuperación se reducirán un x% si se produce alguno de estos problemas conocidos. La creación de objetivos que se ajusten a las necesidades de la empresa le ayuda a anticipar los tipos de fallos que su aplicación debería tolerar. También le ayuda a identificar enfoques para reducir la probabilidad de que su aplicación se vea afectada.
Si piensa en el objetivo de seguir funcionando si pierde el 5% de las instancias que alimentan su aplicación, podría decidir si la aplicación debe preescalarse o tener la capacidad de escalarse lo suficientemente rápido como para soportar el tráfico adicional que se genere durante ese evento. O bien, puede decidir aprovechar diferentes patrones arquitectónicos, tal y como se describe en la sección Etapa 2: diseño e implementación.
También debe implementar medidas de observabilidad para sus objetivos comerciales específicos. Por ejemplo, puedes hacer un seguimiento de la tasa media de pedidos, del precio medio de los pedidos, del número medio de suscripciones u otras métricas que puedan proporcionar información sobre el estado de la empresa en función del comportamiento de tu aplicación. Al implementar capacidades de observabilidad en su aplicación, puede crear alarmas y tomar medidas si estas métricas superan los límites definidos. La observabilidad se trata con más detalle en la sección Etapa 4: Operar.
