# Fiabilidad El pilar de fiabilidad abarca la capacidad de una carga de trabajo para llevar a cabo su función prevista de forma correcta y coherente cuando se espera que lo haga. Esto incluye la capacidad de utilizar y probar la carga de trabajo a lo largo de todo su ciclo de vida. En este documento se incluye orientación de prácticas recomendadas para la implementación de cargas de trabajo fiables en AWS. **Topics** + [ # Modelo de responsabilidad compartida para la resiliencia ](shared-responsibility-model-for-resiliency.md) + [ # Principios de diseño ](design-principles.md) + [ # Definiciones ](definitions.md) + [ # Comprensión de las necesidades de disponibilidad ](understanding-availability-needs.md) # Modelo de responsabilidad compartida para la resiliencia La resiliencia es una responsabilidad compartida entre AWS y el cliente. Es importante que entienda cómo la recuperación de desastres (DR) y la disponibilidad, como parte de la resiliencia, operan bajo este modelo compartido. **Responsabilidad de AWS: resiliencia de la nube** AWS es responsable de la resiliencia de la infraestructura en la que se ejecutan todos los servicios que se ofrecen en la Nube de AWS. Esta infraestructura está conformada por el hardware, el software, las redes y las instalaciones que ejecutan servicios de la Nube de AWS. AWS hace todos los esfuerzos razonables desde el punto de vista comercial para que estos servicios de la Nube de AWS estén disponibles, lo que garantiza que la disponibilidad del servicio cumpla o supere los [acuerdos de nivel de servicio (SLA) de AWS](https://aws.amazon.com/legal/service-level-agreements/). La [infraestructura en la nube global de AWS](https://aws.amazon.com/about-aws/global-infrastructure/) está diseñada para permitir a los clientes crear arquitecturas de cargas de trabajo altamente resilientes. Cada Región de AWS está totalmente aislada y se compone de múltiples [zonas de disponibilidad](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/#Availability_Zones), que son particiones físicamente aisladas de la infraestructura. Las zonas de disponibilidad aíslan errores que podrían afectar la resiliencia de la carga de trabajo y les impide repercutir en otras zonas en la región. Al mismo tiempo, todas las AZ de una Región de AWS están interconectadas con ancho de banda alto y redes de baja latencia, y utilizan fibra metropolitana dedicada y totalmente redundante, lo que ofrece una conexión de red de baja latencia y alto rendimiento entre las zonas. Todo el tráfico entre las zonas está cifrado. El rendimiento de la red es suficiente para llevar a cabo la replicación sincrónica entre zonas. Cuando una aplicación está particionada en varias AZ, las empresas estarán mejor aisladas y contarán con mayor protección frente a problemas como interrupciones de alimentación eléctrica, tormentas eléctricas, tornados, huracanes, etc. **Responsabilidad del cliente: resiliencia en la nube** Su responsabilidad vendrá determinada por los servicios de Nube de AWS que elija. Esto determina la cantidad de trabajo de configuración que debe llevar a cabo como parte de sus responsabilidades de resiliencia. Por ejemplo, un servicio como Amazon Elastic Compute Cloud (Amazon EC2) exige que el cliente lleve a cabo todas las tareas necesarias de configuración y administración de la resiliencia. Los clientes que implementan instancias de Amazon EC2 son responsables de [implementar las instancias de Amazon EC2 en varias ubicaciones](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) (como las zonas de disponibilidad de AWS), [implementar la autorreparación](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) mediante servicios como el escalado automático y utilizar [las prácticas recomendadas de arquitectura de carga de trabajo resiliente](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html) para las aplicaciones instaladas en las instancias. En el caso de los servicios administrados, como Amazon S3 y Amazon DynamoDB, AWS se encarga de gestionar la capa de infraestructura, el sistema operativo y las plataformas, mientras que los clientes acceden a los puntos de conexión para guardar y recuperar información. El cliente es responsable de administrar la resiliencia de sus datos, incluidas las estrategias de copia de seguridad, control de versiones y replicación. La implementación de la carga de trabajo en varias zonas de disponibilidad de una Región de AWS forma parte de una estrategia de alta disponibilidad diseñada para proteger las cargas de trabajo al aislar los problemas en una zona de disponibilidad, que utiliza la redundancia de las demás zonas de disponibilidad para seguir atendiendo las solicitudes. Una arquitectura de varias zonas de disponibilidad también forma parte de una estrategia de DR diseñada para que las cargas de trabajo estén mejor aisladas y protegidas de problemas como interrupciones de alimentación eléctrica, tormentas eléctricas, tornados, terremotos, etc. Las estrategias de DR también pueden hacer uso de varias Regiones de AWS. Por ejemplo, en una configuración activa-pasiva, el servicio para la carga de trabajo pasa de su región activa a su región de DR si la región activa ya no puede atender solicitudes. ![\[Cuadro que ilustra el modelo de resiliencia compartida.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/shared-model-resiliency.png) Puede utilizar los servicios de AWS para lograr sus objetivos de resiliencia. Como cliente, es responsable de la administración de los siguientes aspectos de su sistema para lograr la resiliencia en la nube. Para obtener más información sobre cada servicio en particular, consulte la [documentación de AWS](https://docs.aws.amazon.com/index.html). **Redes, cuotas y limitaciones** + Las prácticas recomendadas para esta área del modelo de responsabilidad compartida se describen en detalle en [Principios básicos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/foundations.html). + Planifique su arquitectura con el espacio suficiente para escalarla y comprenda las [cuotas de servicio](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html) y las limitaciones de los servicios que incluya, en función de los aumentos de carga esperados en las solicitudes, cuando proceda. + Diseñe la [topología de red](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html) para que sea de alta disponibilidad, redundante y escalable. **Administración de cambios y resiliencia operativa** + [Administración de cambios](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/change-management.html) incluye cómo introducir y administrar los cambios en su entorno. La [implementación de cambios](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/implement-change.html) requiere crear y mantener actualizados los manuales de procedimientos y estrategias de implementación para su aplicación e infraestructura. + Una estrategia flexible para [supervisar los recursos de la carga de trabajo](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/monitor-workload-resources.html) considera todos los componentes, incluidas las métricas técnicas y empresariales, las notificaciones, la automatización y el análisis. + Las cargas de trabajo en la nube deben [adaptarse a los cambios en la demanda](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-adapt-to-changes-in-demand.html) al reducir horizontalmente en respuesta a las deficiencias o fluctuaciones del uso. **Observabilidad y administración de errores** + Es necesario observar los fallos mediante la supervisión para automatizar la reparación, de modo que sus cargas de trabajo puedan [soportar los fallos de los componentes](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html). + La [administración de errores](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/failure-management.html) requiere [hacer copias de seguridad de los datos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html), aplicar las prácticas recomendadas para permitir que la carga de trabajo resista los fallos de los componentes y [planificar la recuperación de desastres](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html). **Arquitectura de la carga de trabajo** + La [arquitectura de la carga de trabajo](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html) incluye la forma de diseñar los servicios en torno a los dominios empresariales, aplicar el diseño de sistemas distribuidos y de SOA para evitar fallos e incorporar capacidades como la limitación, los reintentos, la gestión de colas, los tiempos de espera y las palancas de emergencia. + Confíe en las [soluciones de AWS](https://aws.amazon.com/solutions/) probadas, la [Amazon Builders' Library](https://aws.amazon.com/builders-library/) y los [patrones sin servidor](https://serverlessland.com/patterns) para alinearse con las prácticas recomendadas y poner en marcha las implementaciones. + Utilice la mejora continua para descomponer su sistema en servicios distribuidos para escalar e innovar con más rapidez. Utilice la orientación sobre [microservicios de AWS](https://aws.amazon.com/microservices/) y las opciones de servicios administrados para simplificar y acelerar su capacidad de introducir cambios e innovar. **Pruebas continuas de infraestructura crucial** + [Prueba de fiabilidad](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html) implica hacer pruebas a nivel funcional, de rendimiento y de caos, así como adoptar prácticas de análisis de incidentes y prácticas propias del día de juego para adquirir experiencia en la resolución de problemas que no se comprenden bien. + Tanto para las aplicaciones en la nube como para las híbridas, saber cómo se comporta su aplicación cuando surgen problemas o se caen los componentes le permite recuperarse de las interrupciones de forma rápida y fiable. + Cree y documente experimentos repetibles para comprender cómo se comporta su sistema cuando las cosas no funcionan como se esperaba. Estas pruebas demostrarán la eficacia de su capacidad de recuperación general y proporcionarán un bucle de retroalimentación para sus procedimientos operativos antes de enfrentarse a escenarios de error reales. # Principios de diseño En la nube, hay algunos principios que pueden contribuir a aumentar la fiabilidad. Téngalos presentes cuando hablemos de las prácticas recomendadas: + **Recuperación automática de un error**: al supervisar una carga de trabajo de indicadores clave de rendimiento (KPI), se puede ejecutar la automatización cuando se supera un umbral. Estos KPI deben ser una medida del valor de negocio, no de los aspectos técnicos del funcionamiento del servicio. De este modo, se permite la notificación y el seguimiento automático de los errores, así como los procesos de recuperación automatizada que pueden solucionar o corregir el error. Con una automatización más sofisticada, es posible anticipar y solucionar errores antes de que sucedan. + **Prueba de los procedimientos de recuperación**: en un entorno en las instalaciones, a menudo se hacen pruebas para ver si una carga de trabajo funciona en una situación concreta. Normalmente, las pruebas no se usan para comprobar estrategias de recuperación. En la nube, puede probar los errores de la carga de trabajo y validar los procedimientos de recuperación. Puede usar la automatización para simular diferentes errores o recrear escenarios que anteriormente han producido algún error. Esto expone vías de error que puede probar y arreglar *antes* de que se produzca una situación de error real, lo que reduce el riesgo. + **Escalado horizontal para aumentar la disponibilidad agregada de la carga de trabajo**: reemplace un gran recurso por varios recursos pequeños para reducir el efecto de un solo error en toda la carga de trabajo. Distribuya las solicitudes a través de varios recursos más pequeños para garantizar que no compartan el mismo error. + **No más conjeturas sobre la capacidad:** un factor común de error de los sistemas en las instalaciones es la saturación de recursos, cuando las demandas que se hacen a una carga de trabajo superan su capacidad (este es a menudo el objetivo de los ataques de denegación de servicio). En la nube, se puede supervisar la demanda y el uso de la carga de trabajo, además de automatizar la incorporación o eliminación de recursos de forma automatizada para mantener un nivel óptimo y satisfacer la demanda sin tener un aprovisionamiento excesivo o insuficiente. Aún hay límites, pero algunas cuotas se pueden controlar, mientras que otras se pueden administrar (consulte [Manage Service Quotas and Constraints](manage-service-quotas-and-constraints.md)). + **Administración de los cambios mediante la automatización**: los cambios que se apliquen a la infraestructura deben hacerse mediante la automatización. Entre los cambios que se deben administrar se encuentran los de la automatización, de los que, posteriormente, se puede hacer un seguimiento y una revisión. # Definiciones En este documento técnico se trata la fiabilidad en la nube y se describen las prácticas recomendadas para estas cuatro áreas: + Principios básicos + Arquitectura de la carga de trabajo + Administración de cambios + Administración de errores Para lograr la fiabilidad hay que empezar por los cimientos: un entorno en el que las cuotas de servicio y la topología de la red se adapten a la carga de trabajo. La arquitectura de la carga de trabajo del sistema distribuido debe estar diseñada para prevenir y mitigar los errores. La carga de trabajo debe gestionar los cambios en la demanda o los requisitos, y debe estar diseñada para detectar errores y repararse automáticamente. **Topics** + [ # La resiliencia y los componentes de la fiabilidad ](resiliency-and-the-components-of-reliability.md) + [ # Disponibilidad ](availability.md) + [ # Objetivos de recuperación de desastres (DR) ](disaster-recovery-dr-objectives.md) # La resiliencia y los componentes de la fiabilidad La fiabilidad de una carga de trabajo en la nube depende de varios factores, el principal de los cuales es la *resiliencia*: + La **resiliencia** es la capacidad de una carga de trabajo para recuperarse de interrupciones en la infraestructura o el servicio, para incorporar dinámicamente recursos computacionales que satisfagan la demanda y para mitigar las interrupciones, como errores de configuración o problemas de red temporales. Los otros factores que influyen en la fiabilidad de la carga de trabajo son: + Excelencia operativa, que incluye la automatización de los cambios, el uso de manuales de estrategias para responder a los errores y las revisiones de disponibilidad operativa (ORR) para confirmar que las aplicaciones estén listas para las operaciones de producción. + La seguridad, que incluye la prevención de daños a los datos o a la infraestructura por parte de infractores, lo que afectaría a la disponibilidad. Por ejemplo, cifrar las copias de seguridad para garantizar la seguridad de los datos. + Eficiencia del rendimiento, que incluye el diseño para obtener las máximas tasas de solicitudes y minimizar las latencias para su carga de trabajo. + Optimización de costos, que incluye compensaciones tales como si se debe gastar más en instancias de EC2 para lograr la estabilidad estática o confiar en el escalado automático cuando se necesita más capacidad. La resiliencia es el objetivo principal de este documento técnico. Los otros cuatro aspectos también son importantes y están cubiertos por sus respectivos pilares del [Marco de AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/). En muchas de estas prácticas recomendadas también se tratan esos aspectos de la fiabilidad, pero el enfoque se centra en la resiliencia. # Disponibilidad La *disponibilidad* (también conocida como *disponibilidad del servicio*) es una métrica de uso común para medir cuantitativamente la resiliencia, así como un objetivo de resiliencia. + La **disponibilidad** es el porcentaje de tiempo que una carga de trabajo está dispondisponibilidad es el porcentaje de tiempo que una carga de trabajo está disponible para utilizarse. Que esté *disponible para su uso* significa que cumple satisfactoriamente la función acordada cuando es necesario. Este porcentaje se calcula en periodos de tiempo, por ejemplo, mensual, anual o trienal. Al aplicar la interpretación más estricta posible, la disponibilidad se reduce siempre que la aplicación no funciona con normalidad, ya sea con interrupciones programadas o no programadas. Definimos la *disponibilidad* de la siguiente manera: ![\[\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/availability-formula.png) + La disponibilidad es un porcentaje de tiempo de actividad (como el 99,9 %) durante un periodo de actividad (normalmente un mes o un año) + La denominación común se refiere únicamente al “número de nueves” (por ejemplo, “cinco nueves” se traduce en una disponibilidad del 99,999 %). + Algunos clientes optan por excluir el tiempo de inactividad del servicio programado (por ejemplo, el mantenimiento previsto) del *tiempo total* en la formula. Sin embargo, esto no es aconsejable, ya que es probable que sus usuarios quieran utilizar su servicio durante esas horas. A continuación, se presenta una tabla con los objetivos comunes de diseño de disponibilidad de aplicaciones y la duración máxima en el que de las interrupciones se pueden producir en un año sin dejar de cumplir el objetivo. En la tabla figuran ejemplos de los tipos de aplicaciones que se suelen ver en cada nivel de disponibilidad. A lo largo del documento, trataremos estos valores. | Disponibilidad | Falta de disponibilidad máxima (por año) | Categorías de aplicación | | --- | --- | --- | | 99% | 3 días 15 horas | Procesamiento en lotes, extracción de datos, transferencia y trabajos de carga | | 99,9% | 8 horas 45 minutos | Herramientas internas como la administración del conocimiento o el seguimiento de proyectos | | 99,95 % | 4 horas 22 minutos | Comercio en línea, punto de venta | | 99,99% | 52 minutos | Cargas de trabajo de entrega y transmisión de video | | 99,999 % | 5 minutos | Cargas de trabajo de transacciones en cajeros automáticos y telecomunicaciones | **Medición de la disponibilidad en función de las solicitudes.** Para su servicio, puede ser más fácil contar las solicitudes correctas y erróneas en lugar del “tiempo disponible para su uso”. En este caso, se puede utilizar el siguiente cálculo: ![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png) Suele medirse por periodos de uno o cinco minutos. Se puede calcular un porcentaje de tiempo de actividad mensual (medición de la disponibilidad en función del tiempo) a partir de la media de estos periodos. Si no se recibe ninguna solicitud en un periodo determinado, se cuenta con el 100 % disponible para ese tiempo. **Cálculo de la disponibilidad con gran dependencia.** Muchos sistemas dependen de otros, por lo que la interrupción de un sistema dependiente se interpreta directamente como una interrupción en el sistema de invocación. Esto se contrapone a una dependencia flexible, en la que un error del sistema dependiente se compensa en la aplicación. Cuando se producen las dependencias estrictas, la invocación de la disponibilidad del sistema es el producto de las disponibilidades de los sistemas dependientes. Por ejemplo, si se tiene un sistema diseñado para una disponibilidad del 99,99 % que tenga una dependencia estricta de otros dos sistemas independientes que están diseñados para una disponibilidad del 99,99 % cada uno, la carga de trabajo puede teóricamente lograr una disponibilidad del 99,97 %: Availinvok × Avail*dep1* × Avail*dep2* = Availworkload 99,99 % × 99,99 % × 99,99 % = 99,97 % Por lo tanto, es importante entender sus dependencias y sus objetivos de diseño de disponibilidad al hacer los cálculos. **Cálculo de la disponibilidad con componentes redundantes.** Cuando un sistema implica el uso de componentes independientes y redundantes (por ejemplo, recursos redundantes en diferentes zonas de disponibilidad), la disponibilidad teórica se calcula como el 100 % menos el producto de las tasas de error de los componentes. Por ejemplo, si un sistema utiliza dos componentes independientes, cada uno con una disponibilidad del 99,9 %, la disponibilidad efectiva de esta dependencia es 99,9999 %: ![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/image2.png) Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency)) 99,9999 % = 100 % − (0,1 % × 0,1 %) *Cálculo abreviado*: si la disponibilidad de todos los componentes del cálculo consiste únicamente en el dígito nueve, puede sumar el número de nueves dígitos para obtener la respuesta. En el ejemplo anterior, dos componentes redundantes e independientes con una disponibilidad de tres nueves dan como resultado seis nueves. **Cálculo de la disponibilidad de las dependencias.** Algunas dependencias proporcionan orientación sobre su disponibilidad, por ejemplo, los objetivos de diseño de disponibilidad de muchos servicios de AWS. Pero en los casos en los que no está disponible (por ejemplo, un componente en el que el fabricante no publica la información sobre la disponibilidad), una forma sencilla de estimarla es determinar el **tiempo medio entre errores (MTBF)** y el **tiempo medio de recuperación (MTTR)**. Se puede estimar la disponibilidad: ![\[\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png) Por ejemplo, si el MTBF es de 150 días y el MTTR es de 1 hora, la disponibilidad estimada será del 99,97 %. Para obtener más información, consulte [Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html), que puede ayudarle a calcular su disponibilidad. **Costos de disponibilidad.** El diseño de aplicaciones para niveles más altos de disponibilidad suele aumentar los costos, por lo que es conveniente identificar las verdaderas necesidades de disponibilidad antes de iniciar el diseño de la aplicación. Los altos niveles de disponibilidad exigen requisitos más estrictos para el ensayo y la validación en situaciones de error exhaustivas. Requieren la automatización para la recuperación de todo tipo de errores y necesitan que todos los aspectos de las operaciones del sistema se desarrollen y prueben de forma similar con los mismos estándares. Por ejemplo, el aumento o la disminución de la capacidad, la implementación o restauración de software actualizado o cambios en la configuración, o la migración de los datos del sistema se deben efectuar hasta alcanzar el objetivo de disponibilidad deseado. Al sumar los costos de desarrollo de software con niveles de disponibilidad muy elevados, la innovación se ve afectada por la necesidad de avanzar más lentamente en la implementación de los sistemas. Por lo tanto, la orientación debe ser minuciosa al aplicar las normas y considerar el objetivo de disponibilidad adecuado para todo el ciclo de vida del sistema. La selección de dependencias es otra forma con la que aumentan los costos en los sistemas que funcionan con objetivos de diseño de mayor disponibilidad. En estos objetivos superiores, el conjunto de programas o servicios que se pueden elegir como dependencias disminuye en función de cuáles de estos servicios han tenido las inversiones más importantes que hemos descrito anteriormente. A medida que aumenta el objetivo de diseño de la disponibilidad, es habitual encontrar menos servicios de uso múltiple (como una base de datos relacional) y más servicios de uso específico. Esto se debe a que los servicios de uso específico son más fáciles de evaluar, probar y automatizar, además de que muestran menos posibilidades de interacciones inesperadas con funcionalidades incluidas, pero sin utilizar. # Objetivos de recuperación de desastres (DR) Además de los objetivos de disponibilidad, su estrategia de resiliencia debe incluir también objetivos de recuperación de desastres (DR) basados en estrategias para recuperar la carga de trabajo en caso de que se produzca un desastre. La recuperación de desastres se centra en objetivos de recuperación puntuales en respuesta a catástrofes naturales, errores técnicos a gran escala o amenazas humanas como ataques o errores. Es distinto de la disponibilidad, que mide la resiliencia media durante un periodo de tiempo en respuesta a los errores de los componentes, los picos de carga o los errores de software. **Objetivo de tiempo de recuperación (RTO)** definido por la organización. El RTO es la máxima demora aceptable entre la interrupción del servicio y el restablecimiento del servicio. Este valor determina el período de tiempo que se considera aceptable cuando el servicio no está disponible. **Objetivo de punto de recuperación (RPO)** definido por la organización. El RPO es la cantidad máxima de tiempo aceptable desde el último punto de recuperación de datos. Esto determina qué se considera una pérdida de datos aceptable entre el último punto de recuperación y la interrupción del servicio. ![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/business-continuity.png) *La relación entre el RPO (objetivo de punto de recuperación), el RTO (objetivo de tiempo de recuperación) y el evento del desastre.* El RTO es similar al MTTR (tiempo medio de recuperación) en el sentido de que ambos miden el tiempo transcurrido entre el inicio de una interrupción y la recuperación de la carga de trabajo. Sin embargo, el MTTR es un valor medio que se aplica a varios eventos que afectan a la disponibilidad durante un periodo de tiempo, mientras que el RTO es un valor objetivo, o el valor máximo permitido, para un *solo* evento que afecta a la disponibilidad. # Comprensión de las necesidades de disponibilidad Es común pensar inicialmente en la disponibilidad de una aplicación como un solo objetivo para la aplicación en su totalidad. Sin embargo, al analizarlo más detenidamente, con frecuencia encontramos que ciertos aspectos de una aplicación o servicio tienen requisitos de disponibilidad diferentes. Por ejemplo, algunos sistemas podrían dar prioridad a la capacidad de recibir y almacenar nuevos datos antes que a la de recuperar datos ya existentes. Otros sistemas dan prioridad a las operaciones en tiempo real sobre las operaciones que cambian la configuración o el entorno de un sistema. Los servicios pueden tener requisitos de disponibilidad muy elevados durante ciertas horas del día, pero pueden tolerar periodos mucho más largos de interrupción fuera de esas horas. Estas son algunas de las formas en que se puede separar una sola aplicación en las unidades funcionales y evaluar los requisitos de disponibilidad de cada una de ellas. El beneficio de hacerlo consiste en centrar los esfuerzos (y los gastos) en la disponibilidad de acuerdo con las necesidades específicas, en lugar de diseñar todo el sistema según los requisitos de mayor exigencia. | Recomendación | | --- | | Evalúe de forma crítica los aspectos exclusivos de sus aplicaciones y, según corresponda, determine los objetivos de diseño de la disponibilidad y de la recuperación de desastres para reflejar las necesidades de su empresa. | En AWS, normalmente dividimos los servicios en el “plano de datos” y el “plano de control”. El plano de datos se encarga de entregar el servicio en tiempo real mientras que el plano de control se utiliza para configurar el entorno. Por ejemplo, las instancias de Amazon EC2, las bases de datos de Amazon RDS y las operaciones de escritura de tablas de Amazon DynamoDB son operaciones de plano de datos. Por el contrario, el lanzamiento de nuevas instancias de EC2 o bases de datos RDS o agregar o cambiar los metadatos de las tablas en DynamoDB se consideran operaciones de plano de control. Si bien los altos niveles de disponibilidad son importantes para todas estas capacidades, los planos de datos suelen tener objetivos de diseño de disponibilidad más altos que los planos de control. Por lo tanto, las cargas de trabajo con requisitos de alta disponibilidad deben evitar la dependencia en tiempo de ejecución de las operaciones de plano de control. Muchos clientes de AWS adoptan un enfoque similar para evaluar de forma crítica sus aplicaciones e identificar los subcomponentes con diferentes necesidades de disponibilidad. Los objetivos de diseño de la disponibilidad se adaptan a los diferentes aspectos y se llevan a cabo los debidos estudios de ingeniería del sistema. AWS cuenta con gran experiencia en aplicaciones de ingeniería con un intervalo de objetivos de diseño de disponibilidad, incluidos servicios con una disponibilidad del 99,999 % o mayor. AWS Los arquitectos de soluciones (SA) pueden ayudarle a crear el diseño adecuado para lograr sus objetivos de disponibilidad. Involucrar a AWS en la fase inicial de su proceso de diseño aumenta nuestra capacidad para ayudarle a cumplir sus objetivos de disponibilidad. La planificación de la disponibilidad no solo se hace antes de lanzar la carga de trabajo. También se hace continuamente para perfeccionar su diseño a medida que se adquiere experiencia operativa, se aprende de los eventos reales y se toleran errores de diferentes tipos. De esta forma, podrá aplicar el esfuerzo de trabajo adecuado para mejorar su aplicación. Las necesidades de disponibilidad que se requieren para una carga de trabajo deben estar alineadas con la necesidad empresarial y la criticidad. Al definir primero el marco de criticidad empresarial con RTO, RPO y disponibilidad definidos, podrá evaluar cada carga de trabajo. Este enfoque requiere que los implicados en la implementación de la carga de trabajo conozcan el marco y el impacto que su carga de trabajo tiene en las necesidades empresariales.