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.
# Descripción de la disponibilidad
La disponibilidad es una de las principales formas en que podemos medir cuantitativamente la resiliencia. Definimos la disponibilidad (*D*) como el porcentaje de tiempo que una carga de trabajo está disponible para utilizarse. Es una relación entre el tiempo de actividad esperado (estar disponible) y el tiempo total que se está midiendo (el tiempo de actividad esperado más el tiempo de inactividad esperado).
![\[Imagen de la ecuación D = tiempo de actividad/(tiempo de actividad + tiempo de inactividad)\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability.png)
Para entender mejor esta fórmula, veremos cómo medir el tiempo de actividad y el tiempo de inactividad. En primer lugar, queremos saber cuánto durará la carga de trabajo sin que se produzca ningún error. A esto lo denominamos *tiempo medio entre errores* (MTBF), que es el tiempo medio que transcurre entre el momento en que una carga de trabajo comienza a funcionar con normalidad y el siguiente error. Luego, queremos saber cuánto tardará en recuperarse la carga de trabajo tras un error.
A esto lo denominamos *tiempo medio de reparación (o recuperación)* (MTTR), que es el período de tiempo en el que la carga de trabajo no está disponible mientras se repara el subsistema averiado o este empieza a funcionar de nuevo. Un período de tiempo importante en el MTTR es el *tiempo medio de detección (MTTD)*; es decir, el tiempo que transcurre entre el momento en que ocurre el error y el inicio de las operaciones de reparación. En el siguiente diagrama se muestra cómo se relacionan todas estas métricas.
![\[Diagrama que muestra la relación entre el MTTD, el MTTR y el MTBF\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability-metrics.png)
De este modo, podemos expresar la disponibilidad, (*D*) con el MTBF (el tiempo que la carga de trabajo está activa) y el MTTR (el tiempo en que la carga de trabajo está inactiva).
![\[Imagen de la ecuación D = MTBF/(MTBF + MTTR)\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation2.png)
*Y la probabilidad de que la carga de trabajo esté inactiva (es decir, no disponible) es la probabilidad de que falle (F).*
![\[Imagen de la ecuación F =1 − D\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation3.png)
La [fiabilidad](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/reliability.html) es la capacidad de una carga de trabajo para hacer lo correcto, cuando se le solicita, dentro del tiempo de respuesta especificado. Esto es lo que mide la disponibilidad. El hecho de que una carga de trabajo falle con menos frecuencia (MTBF más largo) o que tenga un tiempo de reparación o recuperación más corto (MTTR más corto) mejora su disponibilidad.
**Regla 1**
Los tres factores que se utilizan para mejorar la disponibilidad en los sistemas distribuidos son una menor frecuencia de errores (MTBF más largo), tiempos de detección de errores más cortos (MTTD más corto) y tiempos de reparación más cortos (MTTR más corto).
**Topics**
+ [Disponibilidad de los sistemas distribuidos](distributed-system-availability.md)
+ [Disponibilidad con dependencias](availability-with-dependencies.md)
+ [Disponibilidad con redundancia](availability-with-redundancy.md)
+ [Teorema CAP](cap-theorem.md)
+ [Tolerancia a errores y aislamiento de errores](fault-tolerance-and-fault-isolation.md)
# Disponibilidad de los sistemas distribuidos
Los sistemas distribuidos se componen tanto de componentes de software como de componentes de hardware. Algunos de los componentes de software podrían ser en sí mismos otro sistema distribuido. La disponibilidad de los componentes de hardware y software subyacentes afecta a la disponibilidad resultante de la carga de trabajo.
El cálculo de la disponibilidad mediante el tiempo medio entre errores (MTBF) y el tiempo medio de reparación o recuperación (MTTR) tiene sus raíces en los sistemas de hardware. Sin embargo, los sistemas distribuidos fallan por motivos muy diferentes a los de un componente de hardware. Mientras que un fabricante puede calcular de manera coherente el tiempo promedio antes de que se deteriore un componente de hardware, las mismas pruebas no se pueden aplicar a los componentes de software de un sistema distribuido. El software suele seguir la curva en forma de bañera (donde la curva desciende primero bruscamente, luego se produce un periodo de estabilidad y, por último, la curva asciende de manera drástica), mientras que el software sigue una curva escalonada producida por los defectos adicionales que se van introduciendo con cada nueva versión (consulte [Fiabilidad del software](https://users.ece.cmu.edu/~koopman/des_s99/sw_reliability)).
![\[Diagrama que muestra los índices de hardware y software\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/availability-and-beyond-improving-resilience/images/failure-rates.png)
Además, el software de los sistemas distribuidos suele cambiar a índices exponencialmente superiores a las del hardware. Por ejemplo, un disco duro magnético estándar puede tener un índice medio de errores anual (AFR) del 0,93 %, lo que, en la práctica, en el caso de un disco HDD puede suponer una vida útil de al menos 3 a 5 años antes de que llegue al período de deterioro, y podría ser superior (consulte los [datos y estadísticas sobre discos duros publicados en 2020 por Backblaze](https://www.backblaze.com/b2/hard-drive-test-data.html)). El disco duro no cambia sustancialmente durante esa vida útil, mientras que, en un plazo de 3 a 5 años, por ejemplo, Amazon podría implementar de 450 a 750 millones de cambios en sus sistemas de software (consulte [Amazon Builders' Library: Automatización de implementaciones seguras y sin intervención](https://aws.amazon.com/about-aws/whats-new/2020/06/new-abl-article-automating-safe-hands-off-deployments/)).
El hardware también está sujeto al concepto de obsolescencia programada; es decir, tiene una vida útil incorporada y será necesario reemplazarlo después de un período de tiempo determinado. (Lea “[The Great Lightbulb Conspiracy](https://spectrum.ieee.org/tech-history/dawn-of-electronics/the-great-lightbulb-conspiracy)”). En teoría, el software no está sujeto a esta restricción, no tiene período de deterioro alguno y puede funcionar indefinidamente.
Todo esto significa que los mismos modelos de prueba y predicción utilizados para calcular el MTBF y el MTTR del hardware no se aplican al software. Desde la década de 1970, se han realizado cientos de intentos de diseñar modelos para solucionar este problema, pero generalmente todos se dividen en dos categorías: modelos de predicción y modelos de estimación (consulte la [lista de modelos de fiabilidad del software](https://en.wikipedia.org/wiki/List_of_software_reliability_models)).
Según esto, el cálculo de un MTBF y un MTTR prospectivos para sistemas distribuidos y, por lo tanto, de una disponibilidad prospectiva, siempre se derivará de algún tipo de predicción o estimación. Pueden generarse mediante modelos predictivos, simulaciones estocásticas, análisis históricos o pruebas rigurosas, pero esos cálculos no garantizan el tiempo de actividad o el tiempo de inactividad.
Es posible que las razones por las que un sistema distribuido falló en el pasado nunca vuelvan a repetirse. Es probable que las causas por las que se produzca un error en el futuro sean diferentes y, posiblemente, desconocidas. Los mecanismos de recuperación necesarios también pueden ser diferentes para errores futuros de los utilizados en el pasado y requerir mucho más o menos tiempo.
Además, los MTBF y MTTR son promedios. Habrá alguna variación entre el valor promedio y los valores reales observados (la desviación estándar [σ] mide esta variación). Por lo tanto, es posible que trascurra más o menos tiempo entre errores de las cargas de trabajo y que los tiempos de recuperación sean algo diferentes en un entorno de producción real.
Dicho esto, la disponibilidad de los componentes de software que componen un sistema distribuido sigue siendo importante. El software puede fallar por numerosos motivos (que se analizarán con más detalle en la siguiente sección) y repercuten en la disponibilidad de la carga de trabajo. Por lo tanto, en el caso de los sistemas distribuidos de alta disponibilidad, se debe prestar la misma atención al cálculo, la medición y la mejora de la disponibilidad de los componentes de software que a los subsistemas de hardware y software externos.
**Regla 2**
La disponibilidad del software en su carga de trabajo es un factor importante de la disponibilidad general de la carga de trabajo y debe recibir la misma atención que otros componentes.
Es importante señalar que, a pesar de que el MTBF y el MTTR son difíciles de predecir para los sistemas distribuidos, aún proporcionan información clave sobre cómo mejorar la disponibilidad. Reducir la frecuencia de los errores (mayor MTBF) y disminuir el tiempo de recuperación después de que se produzca un error (menor MTTR) redundará en una mayor disponibilidad empírica.
## Tipos de errores en los sistemas distribuidos
En general, existen dos clases de errores en los sistemas distribuidos que afectan a la disponibilidad, denominados cariñosamente *Bohrbug* y *Heisenbug* (lea [“A Conversation with Bruce Lindsay” de ACM Queue; vol. 2, núm. 8; noviembre de 2004).](http://queue.acm.org/detail.cfm?id=1036486)
Un Bohrbug es un problema de software funcional que se repite. Con los mismos datos de entrada, el error generará coherentemente los mismos datos de salida incorrectos (como el modelo atómico determinista de Bohr, que es sólido y se detecta fácilmente). Estos tipos de errores son poco frecuentes cuando una carga de trabajo entra en el entorno de producción.
Un Heisenbug es un error transitorio, lo que significa que solo ocurre en condiciones específicas e infrecuentes. Estas condiciones suelen estar relacionadas con aspectos como el hardware (por ejemplo, un error transitorio del dispositivo o detalles específicos de la implementación del hardware, como el tamaño del registro), optimizaciones del compilador e implementación del lenguaje, condiciones límite (por ejemplo, falta de almacenamiento temporal) o condiciones de carrera (por ejemplo, no usar un semáforo para operaciones con varios subprocesos).
Los errores Heisenbug constituyen la mayoría de los errores de producción y son difíciles de encontrar porque son esquivos y parecen cambiar de comportamiento o desaparecer cuando se intenta observarlos o depurarlos. Sin embargo, si se reinicia el programa, es probable que la operación fallida se realice correctamente porque el entorno operativo es ligeramente diferente, lo que elimina las condiciones que originaron el Heisenbug.
Por lo tanto, la mayoría de los errores en el entorno de producción son transitorios y, cuando se vuelve a intentar realizar la operación, es poco probable que vuelva a fallar. Para ser resilientes, los sistemas distribuidos tienen que ser tolerantes a los errores Heisenbug. Descubriremos cómo se logra esto en la sección [Cómo incrementar el MTBF de los sistemas distribuidos](increasing-mtbf.md#increasing-mtbf.title).
# Disponibilidad con dependencias
En la sección anterior, mencionamos que el hardware, el software y, potencialmente, otros sistemas distribuidos son todos componentes de la carga de trabajo. A estos componentes los denominamos *dependencias*, los elementos de los que depende una carga de trabajo para proporcionar su funcionalidad. Existen las dependencias *fuertes*, que son aquellos elementos sin los que la carga de trabajo no puede funcionar, y dependencias *suaves*, cuya falta de disponibilidad puede pasar desapercibida o tolerarse durante un período de tiempo. Las dependencias fuertes repercuten directamente en la disponibilidad de la carga de trabajo.
Podríamos intentar calcular la disponibilidad máxima teórica de una carga de trabajo. Se trata del producto de la disponibilidad de todas las dependencias, incluido el propio software (*α**n* es la disponibilidad de un único subsistema), ya que todas ellas deben estar operativas.
![\[Imagen de la ecuación D =α1 × α2 × … × αnsubscript>\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation4.png)
Los números de disponibilidad utilizados en estos cálculos suelen estar asociados a aspectos como los acuerdos de nivel de servicio (SLA) o los objetivos de nivel de servicio (SLO). Los SLA definen el nivel de servicio esperado que recibirán los clientes, las métricas con las que se mide el servicio y las soluciones o penalizaciones (normalmente monetarias) en caso de que no se cumplan los niveles de servicio.
Con la fórmula anterior, podemos concluir que, desde un punto de vista puramente matemático, una carga de trabajo no puede estar más disponible que alguna de sus dependencias. Pero no coincide con lo que solemos ver. Una carga de trabajo creada con dos o tres dependencias con un SLA de disponibilidad del 99,99 % puede lograr una disponibilidad del 99,99% o superior por sí misma.
Esto se debe a que, como explicamos en la sección anterior, estas cifras de disponibilidad son estimaciones. Estiman o predicen la frecuencia con la que se produce un error y la rapidez con la que se puede reparar. No garantizan el tiempo de inactividad. Las dependencias suelen superar el SLA o el SLO de disponibilidad indicados.
Las dependencias también pueden tener objetivos de disponibilidad interna más altos con respecto a los objetivos de rendimiento que las cifras proporcionadas en los SLA públicos. Esto ofrece un cierto nivel de mitigación de riesgos a la hora de cumplir los SLA cuando ocurre algo desconocido o impredecible.
Por último, es posible que su carga de trabajo tenga dependencias cuyos SLA no puedan conocerse o que no ofrezcan un SLA o un SLO. Por ejemplo, el enrutamiento de Internet en todo el mundo es una dependencia común para muchas cargas de trabajo, pero es difícil saber qué proveedores de servicios de Internet utiliza su tráfico global, si tienen algún SLA o si los proveedores funcionan de forma coherente entre sí.
Lo que todo esto nos indica es que calcular una disponibilidad teórica máxima solo es probable que produzca un cálculo aproximado, pero por sí mismo es probable que no sea preciso ni proporcione información significativa Lo que sí nos dicen las matemáticas es que de cuantas menos cosas dependa su carga de trabajo, menor probabilidad habrá de que se produzca, en general, un error. Cuantos menos números menores de uno se multipliquen, mayor será el resultado.
**Regla 3**
Reducir las dependencias puede tener un impacto positivo en la disponibilidad.
Las matemáticas también ayudan a conformar el proceso de selección de dependencias. El proceso de selección afecta a la forma de diseñar la carga de trabajo, la manera de aprovechar la redundancia en las dependencias para mejorar su disponibilidad y a decidir si esas dependencias son fuertes o suaves. Las dependencias que pueden afectar a la carga de trabajo se deben elegir cuidadosamente. La siguiente regla proporciona orientación sobre cómo hacerlo.
**Regla 4**
En general, seleccione las dependencias cuyos objetivos de disponibilidad sean iguales o superiores a los objetivos de su carga de trabajo.
# Disponibilidad con redundancia
Cuando una carga de trabajo utiliza subsistemas múltiples, independientes y redundantes, puede alcanzar un mayor nivel teórico de disponibilidad que si se utilizara un único subsistema. Piense en una carga de trabajo compuesta de dos subsistemas idénticos. Puede estar completamente operativa si el subsistema uno o el subsistema dos están operativos. Para que todo el sistema esté inactivo, ambos subsistemas deben estar inactivos al mismo tiempo.
Si la probabilidad de error de un subsistema es 1 − *α*, entonces la probabilidad de que dos subsistemas redundantes estén inactivos al mismo tiempo es el producto de la probabilidad de que falle cada subsistema, *F* = (1 − *α*1) × (1 − *α*2). Para una carga de trabajo con dos subsistemas redundantes, si se utiliza la ecuación *(3)*, se obtiene una disponibilidad definida de la siguiente manera:
![\[Imagen de tres ecuaciones\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation5.png)
Por lo tanto, para dos subsistemas cuya disponibilidad es del 99 %, la probabilidad de que uno falle es del 1 % y la probabilidad de que ambos fallen es (1 − 99 %) × (1 − 99 %) = 0,01 %. Así, la disponibilidad al usar dos subsistemas redundantes es del 99,99 %.
Esto se puede generalizar para incorporar otros componentes redundantes de repuesto, *r*.** En la ecuación *(5)*, solo asumimos un repuesto, pero una carga de trabajo puede tener dos, tres o más repuestos para poder sobrevivir a la pérdida simultánea de varios subsistemas sin afectar a la disponibilidad. Si una carga de trabajo tiene tres subsistemas y dos son de repuesto, la probabilidad de que los tres subsistemas fallen al mismo tiempo es (1 − *α*) × (1 − *α*) × (1 − *α*) o (1 − *α*)3. En general, una carga de trabajo con *r* repuestos solo fallará si fallan los subsistemas *s* \$1 1.
Para una carga de trabajo con *n* subsistemas y *r* repuestos, *f* es el número de modos de error o las formas en que los subsistemas *r* \$1 1 pueden fallar a partir de *n*.
En efecto, este es el teorema binomial, la matemática combinatoria de elegir *k* elementos de un conjunto de *n*, o *“**n* *elige* *k**”*. En este caso, *k* es *r*\$1 1.
![\[Imagen de cuatro ecuaciones\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation6.png)
Luego, podemos producir una aproximación generalizada de disponibilidad que incorpore el número de modos de error y los repuestos. (Para entender por qué hablamos de una aproximación, consulte el apéndice 2 de Highleyman, et al., “[Breaking the Availability Barrier](https://www.amazon.com/Breaking-Availability-Barrier-Survivable-Enterprise/dp/1410792331)”).
![\[Imagen de cuatro ecuaciones\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation7.png)
La incorporación de repuestos se puede aplicar a cualquier dependencia que proporcione recursos que fallen de forma independiente. Entre los ejemplos se incluyen instancias de Amazon EC2 en diferentes zonas de disponibilidad (AZ) o buckets de Amazon S3 en diferentes Regiones de AWS. El uso de repuestos ayuda a esa dependencia a lograr una mayor disponibilidad total para cumplir con los objetivos de disponibilidad de la carga de trabajo.
**Regla 5**
Utilice repuestos para incrementar la disponibilidad de las dependencias en una carga de trabajo.
Sin embargo, el uso de repuestos conlleva un costo. Cada repuesto adicional cuesta lo mismo que el módulo original, lo que incrementa el gasto de manera lineal. Crear una carga de trabajo que pueda utilizar componentes de repuesto también aumenta su complejidad. Debe saber cómo identificar los errores de dependencias, trasladar el trabajo a un recurso en buen estado y gestionar la capacidad general de la carga de trabajo.
La redundancia supone un problema de optimización. Si hay pocos repuestos, la carga de trabajo puede fallar con más frecuencia de la deseada; si hay demasiados, la carga de trabajo cuesta demasiado. Existe un umbral en el que añadir más repuestos costará más de lo que justifica la disponibilidad adicional que ofrecen.
Si utilizamos nuestra fórmula de disponibilidad general con repuestos, la ecuación *(7)*, para un subsistema que tiene una disponibilidad del 99,5 %, con dos repuestos, la disponibilidad de la carga de trabajo es *D* ≈ 1 − (1)(1 − 0,995)3 = 99,9999875 % (aproximadamente 3,94 segundos de inactividad al año); con 10 repuestos obtenemos *D* ≈ 1 − (1)(1 − 0,995)11 = 99,99999999999999999999999** (el tiempo de inactividad aproximado sería 1,26252 × 10−15*m**s* al año, prácticamente 0). Al comparar estas dos cargas de trabajo, hemos incurrido en un aumento de 5 veces en el costo de los repuestos para lograr cuatro segundos menos de tiempo de inactividad al año. Para la mayoría de las cargas de trabajo, el aumento del costo no estaría justificado para este aumento de la disponibilidad. La relación se muestra en la siguiente figura.
![\[Diagrama que muestra rendimientos decrecientes derivados del aumento de repuestos\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/availability-and-beyond-improving-resilience/images/effect-of-sparing.png)
Con tres repuestos o más, el resultado son fracciones de segundo del tiempo de inactividad previsto al año, lo que significa que, a partir de esa cantidad, se llega a la zona de rentabilidad decreciente. Puede que surja la necesidad de añadir más capacidad para lograr niveles más altos de disponibilidad, pero en realidad, la rentabilidad desaparece muy rápidamente. El uso de más de tres repuestos no proporciona ganancias materiales ni notables para casi ninguna carga de trabajo cuando el propio subsistema en sí tiene una disponibilidad de al menos el 99 %.
**Regla 6**
La rentabilidad del uso de repuestos tiene un límite superior. Utilice el menor número de repuestos necesario para lograr la disponibilidad requerida.
Debe tener en cuenta la unidad de error al seleccionar el número correcto de repuestos. Tomemos como ejemplo una carga de trabajo que requiere 10 instancias de EC2 para gestionar los picos de capacidad, implementadas en una sola AZ.
Dado que las AZ se han diseñado para funcionar como límites de aislamiento de errores, la unidad de error no es solo una instancia de EC2, sino que todas las instancias de EC2 de una AZ pueden fallar al mismo tiempo. En este caso, querrá [añadir redundancia con otra AZ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) e implementar 10 instancias de EC2 adicionales para gestionar la carga en caso de que se produzca un error en la AZ, lo que supone un total de 20 instancias de EC2 (siguiendo el patrón de estabilidad estática).
Si bien parece que hablamos de 10 instancias de EC2 de reserva o de repuesto, en realidad se trata de una única AZ de reserva, por lo que no hemos superado el punto de rentabilidad decreciente. Sin embargo, puede disfrutar de más rentabilidad y, al mismo tiempo, incrementar la disponibilidad si utiliza tres AZ e implementa cinco instancias de EC2 por AZ.
Esto proporciona una AZ de reserva con un total de 15 instancias de EC2 (frente a dos AZ con 20 instancias) y, al mismo tiempo, proporciona las 10 instancias necesarias en total para atender los picos de capacidad durante un evento que afecte a una única AZ. Por lo tanto, debe incorporar repuestos para tolerar los errores en todos los límites de aislamiento de errores utilizados por la carga de trabajo (instancia, celda, AZ y región).
# Teorema CAP
Otra manera de entender la disponibilidad guarda relación con el teorema CAP. Este teorema establece que un sistema distribuido, formado por varios nodos que almacenan datos, no puede ofrecer simultáneamente más de dos de las siguientes tres garantías:
+ Coherencia (**c**onsistency): cada solicitud de lectura recibe la escritura más reciente o un error cuando no se puede garantizar la coherencia.
+ Disponibilidad (**a**vailability): todas las solicitudes reciben una respuesta sin errores, aunque los nodos no estén disponibles ni activos.
+ Tolerancia a las particiones (**p**artition tolerance): el sistema sigue funcionando a pesar de la pérdida de un número arbitrario de mensajes entre los nodos.
(Para obtener más información, lea a Seth Gilbert y Nancy Lynch en “[http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970](http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970)”; *ACM SIGACT News*; volumen 33, número 2 (2002), págs. 51—59).
La mayoría de los sistemas distribuidos tienen que tolerar los errores de la red y, por lo tanto, se debe permitir la partición de la red. Esto significa que estas cargas de trabajo deben elegir entre la coherencia y la disponibilidad cuando se produce una partición de red. Si la carga de trabajo elige la disponibilidad, siempre devuelve una respuesta, pero con datos potencialmente incoherentes. Si elige la coherencia, durante una partición de red devolverá un error, ya que la carga de trabajo no puede garantizar la coherencia de los datos.
Para las cargas de trabajo cuyo objetivo es proporcionar niveles de disponibilidad más elevados, pueden elegir la disponibilidad y la tolerancia a las particiones para evitar que se produzcan errores (no estar disponible) durante una partición de red. Esto hace que se requiera un [modelo de coherencia](https://en.wikipedia.org/wiki/Consistency_model) más relajado, como coherencia final o coherencia monótona.
# Tolerancia a errores y aislamiento de errores
Estos son dos conceptos importantes cuando pensamos en la disponibilidad. La tolerancia a errores es la capacidad de [resistir los errores de los subsistemas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) y mantener la disponibilidad (hacer lo correcto dentro de un acuerdo de nivel de servicio [SLA] establecido). Para implementar la tolerancia a errores, las cargas de trabajo utilizan subsistemas de repuesto, de reserva o redundantes. Cuando uno de los subsistemas de un conjunto redundante falla, otro retoma su trabajo, por lo general casi sin problemas. En este caso, los repuestos son realmente capacidad de reserva; están disponibles para asumir el 100 % del trabajo del subsistema con errores. Cuando hablamos de verdaderos repuestos, es necesario que se produzcan varios errores en el subsistema para que repercutan negativamente en la carga de trabajo.
El aislamiento de errores minimiza el alcance del impacto cuando se produce un error. Esto se suele implementar con la modularización. Las cargas de trabajo se dividen en pequeños subsistemas que fallan de forma independiente y se pueden reparar de forma aislada. Un error que se produce en un módulo [no se propaga más allá del módulo](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html). Esta idea se extiende tanto verticalmente, a través de distintas funcionalidades de una carga de trabajo, como horizontalmente, a través de varios subsistemas que proporcionan la misma funcionalidad. Estos módulos actúan como contenedores de errores que limitan el alcance del impacto durante un evento.
Los patrones arquitectónicos de los planos de control, los planos de datos y la estabilidad estática respaldan directamente la implementación de la tolerancia a errores y el aislamiento de errores. El artículo de Amazon Builders' Library [Estabilidad estática con zonas de disponibilidad](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) define bien estos términos y cómo se aplican a la creación de cargas de trabajo resilientes y de alta disponibilidad. Este documento técnico utiliza estos patrones en la sección [Cómo diseñar sistemas distribuidos de alta disponibilidad en AWS](designing-highly-available-distributed-systems-on-aws.md#designing-highly-available-distributed-systems-on-aws.title), y también resumimos sus definiciones aquí.
+ **Plano de control**: la parte de la carga de trabajo involucrada en realizar cambios. Agregar recursos, elimina recursos, modifica recursos y propaga los cambios donde sean necesarios. Los planos de control suelen ser más complejos y tienen más partes móviles que los planos de datos, por lo que estadísticamente tienen más probabilidades de fallar y tener una menor disponibilidad.
+ **Plano de datos**: la parte de la carga de trabajo que proporciona la funcionalidad empresarial diaria. Los planos de datos suelen ser más simples y funcionan a volúmenes más altos que los planos de control, lo que se traduce en una mayor disponibilidad.
+ **Estabilidad estática**: la capacidad de una carga de trabajo para continuar funcionando correctamente a pesar de las deficiencias de las dependencias. Un método de implementación consiste en eliminar las dependencias del plano de control de los planos de datos. Otro método consiste en acoplar de forma flexible las dependencias de la carga de trabajo. Es posible que la carga de trabajo no vea ninguna información actualizada (como cosas nuevas, eliminadas o modificadas) que se supone que su dependencia debía haber proporcionado. Sin embargo, todo lo que hacía antes de que la dependencia se viera afectada sigue funcionando.
Cuando pensamos en el deterioro de una carga de trabajo, hay dos enfoques de alto nivel que podemos plantearnos para la recuperación. El primer método consiste en responder a ese deterioro después de que se produzca, tal vez recurriendo a AWS Auto Scaling para añadir capacidad nueva. El segundo método consiste en prepararse para esas deficiencias antes de que se produzcan, tal vez aprovisionando en exceso la infraestructura de una carga de trabajo para que pueda seguir funcionando correctamente sin necesidad de añadir recursos adicionales.
Un sistema estable desde el punto de vista estático utiliza este último enfoque. Aprovisiona la capacidad de reserva previamente para que esté disponible en caso de error. Este método evita crear una dependencia en un plano de control en la ruta de recuperación de la carga de trabajo para aprovisionar nueva capacidad para recuperarse de un error. Además, aprovisionar nueva capacidad para varios recursos lleva tiempo. Mientras espera nueva capacidad, la carga de trabajo puede verse sobrecargada por la demanda existente y sufrir una mayor degradación, lo que puede provocar una pérdida total de la disponibilidad. Sin embargo, también se deben comparar las implicaciones financieras de utilizar capacidad previamente aprovisionada con los objetivos de disponibilidad.
La estabilidad estática brinda las dos reglas siguientes para las cargas de trabajo de alta disponibilidad.
**Regla 7**
No tenga dependencias en los planos de control en el plano de datos, especialmente durante una recuperación.
**Regla 8**
Cuando sea posible, acople las dependencias de manera flexible para que la carga de trabajo pueda funcionar correctamente a pesar del deterioro de la dependencia.