# Definiciones 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 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 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.