# Prácticas recomendadas **Topics** + [Fundamentos](rel-found.md) + [Arquitectura de la carga de trabajo](rel-workload-arch.md) + [Administración de cambios](rel-chg-mgmt.md) + [Administración de errores](rel-failmgmt.md) # Fundamentos Los requisitos fundamentales son aquellos cuyo alcance va más allá de una única carga de trabajo o proyecto. Antes de diseñar la arquitectura de cualquier sistema, los requisitos básicos que afectan a la fiabilidad deberían estar aplicados. Por ejemplo, es preciso que haya suficiente ancho de banda de la red en el centro de datos. AWS ya incorpora la mayor parte de estos requisitos básicos. Si no lo están, permite que estos se traten según corresponda. La nube está diseñada para que sea, en esencia, ilimitada, por lo que la responsabilidad de brindar suficiente capacidad de cómputo y de red recae en AWS. Al mismo tiempo, será libre de cambiar la asignación y el tamaño de los recursos según lo necesite. Las siguientes preguntas se centran en estas consideraciones de fiabilidad. (Para ver una lista de preguntas y prácticas recomendadas sobre la optimización de costos, consulte el [Apéndice](a-reliability.md)). | REL 1 ¿Cómo administra las cuotas de servicio y las restricciones? | | --- | | Para las arquitecturas de carga de trabajo basadas en la nube, existen cuotas de servicio (que también se denominan límites de servicio). Estas cuotas existen para evitar aprovisionar por accidente más recursos de los necesarios y para limitar las tasas de solicitud en las operaciones de la API de modo que los servicios queden protegidos ante posibles usos inadecuados. También existen restricciones de recursos, por ejemplo, la velocidad a la que se pueden introducir bits en un cable de fibra óptica o la cantidad de almacenamiento de un disco físico. | | REL 2 ¿Cómo planifica la topología de la red? | | --- | | Suele haber cargas de trabajo en distintos entornos. Entre estos se incluyen los entornos de la nube (tanto públicamente accesibles como privados), y posiblemente la infraestructura del centro de datos existente. Los planes deben incluir consideraciones, como la conectividad dentro de los sistemas y entre ellos, la administración de las direcciones IP públicas, la administración de las direcciones IP privadas y la resolución de nombres de dominio. | Para las arquitecturas de carga de trabajo basadas en la nube, existen cuotas de servicio (que también se denominan límites de servicio). Estas cuotas existen para evitar aprovisionar por accidente más recursos de los necesarios y para limitar las tasas de solicitud en las operaciones de la API, de modo que los servicios queden protegidos ante posibles usos inadecuados. Suele haber cargas de trabajo en distintos entornos. Debe supervisar y administrar estas cuotas para todos los entornos de la carga de trabajo. Entre estos se incluyen los entornos de la nube (de acceso público y privado) y pueden incluir la infraestructura del centro de datos existente. Los planes deben incluir consideraciones, como la conectividad dentro de los sistemas y entre ellos, la administración de las direcciones IP públicas, la administración de las direcciones IP privadas y la resolución de nombres de dominio. # Arquitectura de la carga de trabajo Una carga de trabajo fiable comienza por tomar decisiones de diseño anticipadas tanto para el software como para la infraestructura. Sus elecciones respecto a la arquitectura tendrán un impacto sobre el comportamiento de su carga de trabajo en los seis pilares de Well-Architected. Para la fiabilidad, hay patrones específicos que debe seguir. En AWS, los desarrolladores de la carga de trabajo pueden elegir los idiomas y las tecnologías a usar. Los SDK de AWS simplifican la codificación al proporcionar API específicas de idioma para los servicios de AWS. Estos SDK, más la elección del idioma, permiten a los desarrolladores implementar las prácticas recomendadas de fiabilidad enumeradas aquí. Los desarrolladores también pueden informarse y aprender sobre el modo en que Amazon crea y opera software en la [Amazon Builders' Library](https://aws.amazon.com/builders-library/?ref=wellarchitected-wp). Las siguientes preguntas se centran en estas consideraciones de fiabilidad. | REL 3 ¿Cómo diseña la arquitectura de servicio de su carga de trabajo? | | --- | | Desarrolle cargas de trabajo escalables y fiables utilizando una arquitectura orientada a servicios (SOA) o una arquitectura de microservicios. La arquitectura orientada a servicios (SOA) es la práctica de hacer que los componentes de software se puedan reutilizar mediante interfaces de servicio. La arquitectura de microservicios va más allá, para hacer que los componentes sean más pequeños y sencillos. | | REL 4 ¿Cómo diseña las interacciones en un sistema distribuido para evitar errores? | | --- | | Los sistemas distribuidos dependen de las redes de comunicaciones para interconectar componentes, como servidores o servicios. Su carga de trabajo debe funcionar de manera fiable aunque se pierdan datos o haya latencia en estas redes. Los componentes del sistema distribuido deben funcionar de forma que no repercutan negativamente en otros componentes ni en la carga de trabajo. Estas prácticas recomendadas evitan que se produzcan errores y mejoran el tiempo medio entre errores (MTBF). | | REL 5 ¿Cómo diseña las interacciones en un sistema distribuido para mitigar o tolerar errores? | | --- | | Los sistemas distribuidos dependen de las redes de comunicaciones para interconectar componentes, como servidores o servicios. Su carga de trabajo debe funcionar de manera fiable aunque se pierdan datos o haya latencia en estas redes. Los componentes del sistema distribuido deben funcionar de forma que no repercutan negativamente en otros componentes ni en la carga de trabajo. Estas prácticas recomendadas permiten que las cargas de trabajo toleren el estrés o los errores, se recuperen más rápidamente de ellos y mitiguen el impacto de dichos errores. El resultado es un tiempo medio de recuperación (MTTR) mejor. | # Administración de cambios Se deben prever y ajustar los cambios en su carga de trabajo o su entorno para poder conseguir un funcionamiento fiable de la carga de trabajo. Los cambios incluyen aquellos que se imponen a su carga de trabajo, como los picos de demanda, además de los inherentes a ella, como los despliegues de funciones o los parches de seguridad. Con AWS puede monitorear el comportamiento de una carga de trabajo y automatizar la respuesta a los KPI. Por ejemplo, la carga de trabajo puede añadir servidores adicionales a medida que la carga de trabajo gane más usuarios. Puede controlar quién tiene permisos para realizar cambios en la carga de trabajo e inspeccionar el historial de cambios. Las siguientes preguntas se centran en estas consideraciones de fiabilidad. | REL 6 ¿Cómo supervisa los recursos de las cargas de trabajo? | | --- | | Los registros y las métricas son una potente herramienta para obtener información sobre el estado de sus cargas de trabajo. Puede configurar su carga de trabajo de forma que supervise registros y métricas, y envíe notificaciones cuando se crucen ciertos umbrales o se produzcan eventos importantes. La supervisión permite que su carga de trabajo reconozca cuándo se cruzan umbrales de bajo rendimiento o se producen errores, para que pueda recuperarse de los errores rápidamente una vez recibida una respuesta. | | REL 7 ¿Cómo diseña su carga de trabajo para que se adapte a los cambios en la demanda? | | --- | | Una carga de trabajo escalable proporciona elasticidad para agregar y eliminar recursos de forma automática a fin de que coincidan estrechamente con la demanda actual en cualquier momento dado. | | REL 8 ¿Cómo implementa los cambios? | | --- | | Los cambios controlados son necesarios para implementar nueva funcionalidad y garantizar que las cargas de trabajo y el entorno operativo ejecuten software conocido y puedan recibir parches o reemplazos de manera predecible. Si estos cambios no se controlan, puede ser difícil prever su efecto o abordar los problemas que surjan a raíz de ellos. | Cuando diseña la arquitectura de una carga de trabajo para agregar y eliminar recursos de forma automática como respuesta a los cambios solicitados, se aumenta la fiabilidad a la par que se garantiza que el éxito del negocio no se convierta en una carga. Al contar con monitoreo, el equipo recibirá alertas automáticas cuando los KPI se desvíen de las reglas esperadas. Los registros automáticos de los cambios realizados en el entorno le permiten inspeccionar e identificar rápidamente aquellas medidas que hayan repercutido en la fiabilidad. Controlar la administración de cambios garantiza que se puedan aplicar reglas que ayuden a alcanzar el grado de fiabilidad deseado. # Administración de errores De cualquier sistema con una complejidad razonable se esperan errores. La fiabilidad requiere que su carga de trabajo conozca los errores a medida que ocurren y que actúe para evitar que afecten a la disponibilidad. Las cargas de trabajo deben ser capaces de tolerar errores y de repararlos de forma automática. Gracias a AWS, podrá aprovechar la automatización para reaccionar a los datos de monitoreo. Por ejemplo, cuando una métrica concreta pasa un umbral, podrá desencadenar una acción automática para solucionar el problema. Además, puede reemplazar un recurso que genere un error y forme parte del entorno de producción por uno nuevo y analizar dicho recurso fuera de banda en lugar de intentar diagnosticar y arreglar el recurso del error. Ya que la nube permite soportar versiones temporales de todo un sistema a bajo costo, puede usar las pruebas automáticas para comprobar los procesos de recuperación completos. Las siguientes preguntas se centran en estas consideraciones de fiabilidad. | REL 9 ¿Cómo realiza una copia de seguridad de los datos? | | --- | | Realice una copia de seguridad de los datos, las aplicaciones y la configuración para satisfacer sus requisitos de objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO). | | REL 10 ¿Cómo usa el aislamiento de errores para proteger su carga de trabajo? | | --- | | Los límites aislados de los errores acotan el efecto de un error en una carga de trabajo a un número limitado de componentes. Los componentes fuera del límite no resultan afectados por el error. Mediante el uso de varios límites aislados de error, puede acotar el impacto en su carga de trabajo. | | REL 11 ¿Cómo diseña su carga de trabajo para que soporte los errores de los componentes? | | --- | | Las cargas de trabajo con un requisito de alta disponibilidad y un tiempo de recuperación (MTTR) bajo deben diseñarse para que sean resilientes. | | REL 12 ¿Cómo pone a prueba la fiabilidad? | | --- | | Una vez diseñada la carga de trabajo para que sea resiliente al estrés de producción, las pruebas son la única forma de garantizar que funcionará según lo previsto y proporcionará la resiliencia esperada. | | REL 13 ¿Cómo planifica la recuperación de desastres (DR)? | | --- | | Disponer de copias de seguridad y de componentes de cargas de trabajo redundantes es el principio de su estrategia de DR. [El RTO y el RPO son sus objetivos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) para la restauración de su carga de trabajo. Estos se definen en función de las necesidades del negocio. Implemente una estrategia para satisfacer estos objetivos teniendo en cuenta las ubicaciones y la función de los recursos de las cargas de trabajo y los datos. La probabilidad de una interrupción y el coste de recuperación son también factores clave que ayudan a conocer el valor empresarial de proporcionar recuperación de desastres para una carga de trabajo. | Haga una copia de seguridad de los datos de forma regular y ponga a prueba estos archivos para garantizar que pueda recuperarse tanto de los errores físicos como de los lógicos. Un factor clave para administrar los errores es probar de forma frecuente y automática las cargas de trabajo que causan error para después observar cómo se recuperan. Haga esto de manera regular y asegúrese de que dichas pruebas también se desencadenen tras realizar cambios importantes en la carga de trabajo. Realice un seguimiento activo de los KPI, así como el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) para evaluar la resiliencia de la carga de trabajo (especialmente, cuando se pongan a prueba situaciones en las que se produzca un error). Realizar el seguimiento de los KPI será de ayuda para identificar y mitigar los puntos únicos de error. El objetivo es someter los procesos de recuperación de la carga de trabajo a pruebas exhaustivas para que sepa que puede recuperar todos los datos y continuar brindando servicios a los clientes, aunque se experimenten problemas prolongados. Los procesos de recuperación deberían realizarse igual de bien que los procesos de producción normales.