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 2: diseño e implementación
En la etapa anterior, estableció los objetivos de resiliencia. Ahora, en la etapa de diseño e implementación, intentará anticipar los modos de error e identificar las opciones de diseño, guiándose por los objetivos que estableció en la etapa anterior. También define estrategias para la administración de cambios y desarrolla el código de software y la configuración de la infraestructura. En las siguientes secciones se destacan las prácticas recomendadas de AWS que debe tener en cuenta al valorar las concesiones, como el costo, la complejidad y los gastos operativos.
AWS Well-Architected Framework
Al diseñar la aplicación en función de los objetivos de resiliencia que desee, debe evaluar varios factores y hacer concesiones en función de la arquitectura más óptima. Para crear una aplicación altamente resiliente, debe tener en cuenta aspectos de diseño, creación e implementación, seguridad y operaciones. El Marco de AWS Well-Architected
Los siguientes son ejemplos demuestran cómo el Marco de AWS Well-Architected puede ayudarlo a diseñar e implementar aplicaciones que cumplan sus objetivos de resiliencia:
-
El pilar de la fiabilidad: el pilar de la fiabilidad enfatiza la importancia de crear aplicaciones que puedan funcionar de manera correcta y coherente, incluso durante errores o interrupciones. Por ejemplo, el Marco de AWS Well-Architected recomienda utilizar una arquitectura de microservicios para hacer que las aplicaciones sean más pequeñas y sencillas, de modo que pueda diferenciar las necesidades de disponibilidad de los distintos componentes de la aplicación. También puede encontrar descripciones detalladas de las prácticas recomendadas para crear aplicaciones mediante la limitación, el retroceso exponencial, la respuesta rápida a los errores (reducción de carga), la idempotencia, el trabajo constante, los disyuntores y la estabilidad estática.
-
Revisión exhaustiva: el Marco de AWS Well-Architected fomenta una revisión exhaustiva de su arquitectura comparándola con las prácticas recomendadas y los principios de diseño. Proporciona una forma de medir sus arquitecturas de forma coherente y de identificar áreas de mejora.
-
Administración de riesgos: el Marco de AWS Well-Architected lo ayuda a identificar y administrar los riesgos que podrían afectar a la fiabilidad de su aplicación. Al abordar las posibles situaciones de error de forma proactiva, puede reducir su probabilidad o el deterioro resultante.
-
Mejora continua: la resiliencia es un proceso continuo y el Marco de AWS Well-Architected enfatiza la mejora continua. Al revisar y perfeccionar periódicamente su arquitectura y sus procesos en función de las directrices del Marco de AWS Well-Architected, puede asegurarse de que sus sistemas se mantengan resilientes ante los desafíos y requisitos en evolución.
Comprensión de las dependencias
Comprender las dependencias de un sistema es clave para la resiliencia. Las dependencias incluyen las conexiones entre los componentes de una aplicación y las conexiones con componentes externos a la aplicación, como las API de terceros y los servicios compartidos propiedad de la empresa. Comprender estas conexiones lo ayuda a aislar y administrar las interrupciones, ya que una avería en un componente puede afectar otros componentes. Este conocimiento ayuda a los ingenieros a evaluar el impacto de las averías y a planificar en consecuencia, además de garantizar que los recursos se utilicen de forma eficaz. Comprender las dependencias lo ayuda a crear estrategias alternativas y a coordinar los procesos de recuperación. También lo ayuda a determinar los casos en los que puede reemplazar una dependencia rígida por una dependencia flexible, de modo que la aplicación pueda seguir desempeñando su función empresarial cuando se produzca una avería en las dependencias. Las dependencias también influyen en las decisiones sobre el equilibrio de carga y el escalado de aplicaciones. Comprender las dependencias es fundamental a la hora de realizar cambios en la aplicación, ya que puede ayudarlo a determinar los posibles riesgos e impactos. Estos conocimientos lo ayudan a crear aplicaciones estables y resilientes, lo que contribuye a la administración de errores, la evaluación del impacto, la recuperación de averías, el equilibrio de carga, el escalado y la administración de cambios. Puede realizar un seguimiento de las dependencias manualmente o utilizar herramientas y servicios como AWS X-Ray
Estrategias de recuperación ante desastres
Una estrategia de recuperación ante desastres (DR) desempeña un papel fundamental en la creación y la utilización de aplicaciones resilientes, principalmente al garantizar la continuidad empresarial. Garantiza que se puedan mantener las operaciones cruciales para la empresa con las mínimas averías posibles, incluso durante eventos catastróficos, lo que minimiza el tiempo de inactividad y la posible pérdida de ingresos. Las estrategias de recuperación ante desastres son fundamentales para la protección de datos, ya que normalmente incorporan copias de seguridad y replicación de datos periódicas en varias ubicaciones, lo que ayuda a proteger la valiosa información empresarial y a evitar su pérdida total en caso de desastre. Además, muchos sectores están regulados por políticas que exigen que las empresas cuenten con una estrategia de recuperación ante desastres para proteger la información confidencial y garantizar que los servicios permanezcan disponibles durante un desastre. Al garantizar un deterioro mínimo del servicio, una estrategia de recuperación ante desastres también refuerza la confianza y la satisfacción de los clientes. Una estrategia de recuperación ante desastres bien implementada y aplicada con frecuencia reduce el tiempo de recuperación después de un desastre y ayuda a garantizar que las aplicaciones vuelvan a estar disponibles rápidamente. Además, los desastres pueden generar costos considerables, no solo por la pérdida de ingresos debido al tiempo de inactividad, sino también por los gastos que supone la restauración de las aplicaciones y los datos. Una estrategia de recuperación ante desastres bien diseñada ayuda a protegerse contra estas pérdidas financieras.
La estrategia que elija dependerá de las necesidades específicas de su aplicación, su RTO y RPO y su presupuesto. AWS Elastic Disaster Recovery
Para obtener más información, consulte Disaster Recovery of Workloads on AWS y Aspectos fundamentales de las operaciones en múltiples regiones de AWS en el sitio web de AWS.
Definición de estrategias de CI/CD
Una de las causas más comunes de las averías en las aplicaciones son los cambios en el código u otros cambios que alteran la aplicación desde un estado de funcionamiento conocido anteriormente. No gestionar la administración de cambios con cuidado puede provocar averías frecuentes. La frecuencia de los cambios aumenta las oportunidades de que se produzca un impacto. Sin embargo, hacer cambios con menos frecuencia genera conjuntos de cambios de mayor tamaño, que tienen muchas más probabilidades de provocar una avería debido a su alta complejidad. Las prácticas de integración y entrega continuas (CI/CD) están diseñadas para hacer que los cambios sean pequeños y frecuentes (lo que se traduce en un aumento de la productividad) y, al mismo tiempo, someten cada cambio a un alto nivel de inspección mediante la automatización. Estas son algunas de las estrategias básicas:
-
Automatización total: el concepto fundamental de la CI/CD es automatizar los procesos de creación e implementación en la medida de lo posible. Esto incluye la creación, las pruebas, la implementación e incluso la supervisión. Los procesos automatizados ayudan a reducir la posibilidad de que se produzcan errores humanos, garantizan la coherencia y hacen que el proceso sea más fiable y eficiente.
-
Desarrollo impulsado por pruebas (TDD): escriba las pruebas antes de escribir el código de la aplicación. Esta práctica garantiza que todo el código tenga pruebas asociadas, lo que mejora la fiabilidad del código y la calidad de la inspección automatizada. Estas pruebas se ejecutan en la canalización de CI para validar los cambios.
-
Confirmaciones e integraciones frecuentes: anime a los desarrolladores a confirmar el código y a realizar integraciones con frecuencia. Los cambios pequeños y frecuentes son más fáciles de probar y depurar, lo que reduce el riesgo de que surjan problemas importantes. La automatización reduce el costo de cada confirmación e implementación, lo que permite realizar integraciones frecuentes.
-
Infraestructura inmutable: trate los servidores y demás componentes de la infraestructura como entidades estáticas e inmutables. En la medida de lo posible, sustituya la infraestructura en lugar de modificarla y cree la nueva infraestructura mediante código que se pruebe e implemente a lo largo de la canalización.
-
Mecanismo de reversión: tenga siempre una forma fácil, fiable y probada con frecuencia de revertir los cambios si se produce algún problema. Poder volver rápidamente al estado correcto previo conocido es esencial para la seguridad de la implementación. Puede ser un simple botón para volver al estado anterior o puede automatizarse completamente e iniciarse mediante alarmas.
-
Control de versiones: mantenga todo el código, la configuración e incluso la infraestructura de la aplicación como código en un repositorio controlado por versiones. Esta práctica ayuda a garantizar que pueda realizar un fácil seguimiento de los cambios y revertirlos si fuera necesario.
-
Implementaciones canario e implementaciones azul/verde: implementar primero las nuevas versiones de la aplicación en un subconjunto de la infraestructura, o mantener dos entornos (azul/verde), le permite verificar el comportamiento de un cambio en la producción y revertirlo rápidamente si es necesario.
La CI/CD no se basa solo en las herramientas, sino también en la cultura. Crear una cultura que valore la automatización, las pruebas y el aprendizaje de los errores es tan importante como implementar las herramientas y los procesos correctos. Los retrocesos a versiones anteriores, si se hacen muy rápido y con un impacto mínimo, no deben considerarse un error sino una experiencia de aprendizaje.
Realización de ORR
Las revisiones de la preparación operativa (ORR) ayudan a identificar las brechas operativas y de procedimiento. En Amazon, creamos las ORR para resumir lo aprendido durante décadas de operación de servicios de gran escala en preguntas seleccionadas con orientación sobre las prácticas recomendadas. Una ORR recoge las lecciones aprendidas anteriormente y requiere que nuevos equipos se aseguren de haber implementado estas lecciones en sus aplicaciones. Las ORR pueden proporcionar una lista de los modos de error o las causas de error que se puede incluir en la actividad de modelado de resiliencia que se describe en la sección sobre los modelos de resiliencia que aparece a continuación. Para obtener más información, consulte Operational Readiness Reviews (ORRs) en el sitio web del Marco de AWS Well-Architected.
Descripción de los límites de aislamiento de errores de AWS
AWS proporciona varios límites de aislamiento de errores para ayudarlo a alcanzar sus objetivos de resiliencia. Puede utilizar estos límites para aprovechar el alcance predecible de la contención de impactos que proporcionan. Debe familiarizarse con el diseño de los servicios de AWS mediante el uso de estos límites, de modo que pueda tomar decisiones intencionadas sobre las dependencias que elija para la aplicación. Para entender cómo usar los límites en la aplicación, consulte AWS Fault Isolation Boundaries en el sitio web de AWS.
Selección de respuestas
Un sistema puede responder a una alarma de distintas formas. Algunas alarmas pueden requerir una respuesta del equipo de operaciones, mientras que otras pueden activar mecanismos de autorreparación dentro de la aplicación. Puede decidir conservar las respuestas que podrían automatizarse como operaciones manuales para controlar los costos de la automatización o administrar las limitaciones de ingeniería. Es probable que el tipo de respuesta a una alarma se seleccione en función del costo de implementar la respuesta, la frecuencia prevista de la alarma, la precisión de la alarma y las posibles pérdidas para la empresa si no se responde en absoluto a la alarma.
Por ejemplo, cuando un proceso del servidor se bloquea, el sistema operativo puede reiniciarlo, o puede aprovisionarse un nuevo servidor y finalizar el anterior, o también puede indicarse a un operador que se conecte al servidor de forma remota y que lo reinicie. Estas respuestas tienen el mismo resultado (reiniciar el proceso del servidor de aplicaciones), pero varían en los costos de implementación y mantenimiento.
nota
Puede seleccionar varias respuestas para adoptar un enfoque de resiliencia exhaustivo. Por ejemplo, en el escenario anterior, el equipo de la aplicación podría optar por implementar las tres respuestas con un intervalo de tiempo entre cada una. Si el indicador de proceso del servidor con error sigue en estado de alarma después de 30 segundos, el equipo puede suponer que el sistema operativo no ha podido reiniciar el servidor de la aplicación. Por lo tanto, podrían crear un grupo de escalado automático para crear un nuevo servidor virtual y restaurar el proceso del servidor de la aplicación. Si el indicador sigue en estado de alarma después de 300 segundos, es posible que se envíe una alerta al personal operativo para que se conecte al servidor original e intente restaurar el proceso.
La respuesta que elijan el equipo de la aplicación y la empresa debe reflejar el interés de la empresa por compensar los gastos operativos mediante una inversión inicial en tiempo de ingeniería. Debe elegir una respuesta (un patrón de arquitectura, como la estabilidad estática, un patrón de software, como un disyuntor, o un procedimiento operativo), teniendo en cuenta cuidadosamente las limitaciones y el mantenimiento previsto de cada opción de respuesta. Es posible que existan algunas respuestas estándar para guiar a los equipos de aplicaciones, de modo que pueda utilizar las bibliotecas y los patrones que administra su función de arquitectura centralizada como base para esta consideración.
Creación de modelos de resiliencia
En los modelos de resiliencia se documenta cómo responderá una aplicación a las diferentes interrupciones anticipadas. Al anticipar las interrupciones, su equipo puede implementar procesos de observabilidad, controles automatizados y recuperación para mitigar o prevenir las averías a pesar de las interrupciones. AWS ha creado una guía para desarrollar un modelo de resiliencia mediante el marco de análisis de la resiliencia. Este marco puede ayudarlo a anticipar las interrupciones y su impacto en la aplicación. Al anticipar las interrupciones, puede identificar las mitigaciones necesarias para crear una aplicación fiable y resiliente. Le recomendamos que utilice el marco de análisis de la resiliencia para actualizar su modelo de resiliencia con cada iteración del ciclo de vida de la aplicación. El uso de este marco en cada iteración ayuda a reducir los incidentes al anticipar las interrupciones durante la fase de diseño y probar la aplicación antes y después de la implementación en producción. Desarrollar un modelo de resiliencia mediante este marco lo ayudará a garantizar el cumplimiento de sus objetivos de resiliencia.
Errores seguros
Si no puede evitar las interrupciones, haga que los errores sean seguros. Considere la posibilidad de crear la aplicación con un modo de funcionamiento a prueba de errores predeterminado, en el que no se incurra en pérdidas significativas para la empresa. Un ejemplo de estado a prueba de errores para una base de datos sería utilizar de forma predeterminada las operaciones de solo lectura, en las que los usuarios no pueden crear ni modificar ningún dato. En función de la confidencialidad de los datos, es posible que incluso desee que la aplicación se apague de forma predeterminada y que ni siquiera se realicen consultas de solo lectura. Tenga en cuenta cuál debe ser el estado a prueba de errores de su aplicación y utilice este modo de funcionamiento de forma predeterminada en condiciones extremas.
