Etapa 1: establecimiento de objetivos
Entender el nivel de resiliencia que necesita y cómo se medirá es la base de la etapa de establecimiento de objetivos. Es difícil mejorar algo si no tiene un objetivo y no puede 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 concesiones correctas. Una buena analogía para este caso es un automóvil: tiene cuatro neumáticos pero solo lleva un neumático de repuesto. La probabilidad de que se pinchen varios neumáticos durante un viaje es baja, y tener más piezas de repuesto podría reducir otras características, como el espacio de carga o la eficiencia de combustible, por lo que es una concesión razonable.
Una vez definidos los objetivos, debe implementar controles de observabilidad en etapas posteriores (Etapa 2: diseño e implementación y Etapa 4: funcionamiento) para comprender si se cumplen los objetivos.
Asignación de aplicaciones críticas
La definición de los objetivos de resiliencia no debería ser una conversación exclusivamente técnica. En su lugar, comience con un enfoque orientado a la empresa para comprender qué 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. Puede aplicar cualquier objetivo de resiliencia que defina 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 ejecute una aplicación crítica 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 importante 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 administración de pedidos para una empresa minorista. Si los componentes de la aplicación de administración de pedidos están deteriorados y no funcionan correctamente, no se producirá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 causaría un daño financiero a la empresa necesariamente. Según este ejemplo, es probable que la empresa opte por fijar objetivos más ambiciosos para la aplicación de administración de pedidos en materia de resiliencia, pero no realizará una inversión significativa para garantizar la resiliencia de la aplicación web.
Identificar las aplicaciones más importantes, dónde aplicar el mayor esfuerzo y dónde hacer concesiones es tan importante como poder medir la resiliencia de una aplicación en producción. Para comprender mejor el impacto de los deterioros, 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. El BIA ayuda a cuantificar el costo del tiempo de inactividad de las aplicaciones más importantes de la 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 administración de pedidos está deteriorada, la empresa minorista podría perder importantes ingresos.
Asignación de historias de usuarios
Durante el proceso del BIA, es posible que observe que una aplicación es responsable de más de una función empresarial o que una función empresarial necesita varias aplicaciones. Siguiendo el ejemplo anterior de una empresa minorista, la función de administración de pedidos puede requerir aplicaciones independientes para la tramitación de pedidos, las promociones y la fijación de precios. Si se produce un error en una aplicación, el impacto podría tener consecuencias para la empresa y los usuarios que interactúan con ella. Por ejemplo, es posible que la empresa no pueda agregar nuevos pedidos, ofrecer acceso a promociones y descuentos o actualizar el precio de los productos. Estas diferentes funciones que necesita la función de administración de pedidos pueden depender de varias aplicaciones. Estas funciones también pueden tener varias 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 esta situación es centrarse en las historias de usuarios
Centrarse en las historias de usuarios lo 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 la tramitación del pedido, que implica la aplicación de tramitación de pedidos 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 aplicación de promociones. Tras asignar las aplicaciones más importantes y sus historias de usuarios, 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 específicas.
Definición de 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 un error, 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 con métricas como el porcentaje (%) de solicitudes que se atienden sin errores en un tiempo de respuesta inferior a un segundo (por ejemplo, cada mes recibirán una respuesta el 99,99 % de las solicitudes). El RPO y el RTO están relacionados con las estrategias de recuperación ante desastres, y suponen que se producirán interrupciones en el funcionamiento de las aplicaciones y los procesos de recuperación, que van desde la restauración de las copias de seguridad hasta la redirección del tráfico de usuarios. Los SLO se gestionan 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 suelen utilizar 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 su postura de resiliencia, así que aumentar el SLA no hace que la 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, puede usar AWS Resilience Hub
Creación de medidas adicionales
El RPO, el RTO y los SLO son buenos indicadores de la resiliencia, pero también puede pensar en los objetivos desde una perspectiva empresarial y definirlos en torno a las funciones de la aplicación. Por ejemplo, el objetivo podría ser: los pedidos realizados correctamente por minuto se mantendrán por encima del 98 % si la latencia entre mi frontend y mi backend aumenta un 40 %.O bien: los flujos iniciados 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 lo ayudará a anticipar los tipos de errores que la aplicación debe tolerar. También lo ayudará a identificar enfoques para reducir la probabilidad de que la aplicación se vea deteriorada.
Si piensa en el objetivo de mantener el funcionamiento si pierde el 5 % de las instancias que alimentan la aplicación, podría decidir si la aplicación debe escalarse previamente o tener la capacidad de escalarse lo suficientemente rápido como para soportar el tráfico adicional que se genere durante ese evento. Como alternativa, puede decidir aprovechar diferentes patrones de arquitectura, tal y como se describe en la sección Etapa 2: diseño e implementación.
También debe implementar medidas de observabilidad para los objetivos comerciales específicos. Por ejemplo, puede hacer un seguimiento de la tasa media de pedidos, el precio medio de los pedidos, el 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 la aplicación. Al implementar capacidades de observabilidad en la 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: funcionamiento.
