# Prácticas recomendadas **Topics** + [Principios básicos](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) # Principios básicos Los requisitos fundamentales son aquellos cuyo ámbito 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. En AWS, la mayor parte de estos requisitos básicos están incorporados o pueden abordarse según corresponda. La nube está diseñada para que sea, en esencia, ilimitada, por lo que la responsabilidad de brindar suficiente capacidad de computación y de red recae en AWS. Esto permite que pueda cambiar la asignación y el tamaño de los recursos según sea necesario. Las siguientes preguntas se centran en estas consideraciones de fiabilidad. (Para ver una lista de preguntas y prácticas recomendadas sobre fiabilidad, consulte el [Apéndice](a-reliability.md)). | REL 1: ¿Cómo administra las Service Quotas y las restricciones? | | --- | | Para las arquitecturas de carga de trabajo basadas en la nube, existen Service Quotas (que también se denominan límites de servicio). Estas cuotas existen para evitar el aprovisionamiento accidental de más recursos de los que se necesitan y para limitar las tasas de solicitudes en las operaciones de la API a fin de proteger los servicios contra el abuso. También hay limitaciones de recursos, por ejemplo, la velocidad a la que se pueden introducir bits por un cable de fibra óptica o la cantidad de almacenamiento en un disco físico. | | REL 2: ¿Cómo planifica la topología de la red? | | --- | | Las cargas de trabajo suelen existir en varios entornos. Estos incluyen varios entornos de nube (tanto de acceso público como privados) y, posiblemente, la infraestructura de su centro de datos existente. Los planes deben incluir consideraciones sobre la red, como la conectividad dentro y entre sistemas, la administración de direcciones IP públicas, la administración de 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 afectarán al comportamiento de su carga de trabajo en todos los pilares de Well-Architected. Para la fiabilidad, debe seguir patrones específicos. En AWS, los desarrolladores de la carga de trabajo pueden elegir los lenguajes y las tecnologías que usar. Los SDK de AWS simplifican la codificación al proporcionar API específicas de lenguajes para los servicios de AWS. Estos SDK, más la elección del lenguaje, permiten a los desarrolladores implementar las prácticas recomendadas de fiabilidad enumeradas aquí. Los desarrolladores también pueden leer y aprender sobre cómo Amazon crea y opera el software en [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 mediante una arquitectura orientada a servicios (SOA) o una arquitectura de microservicios. La arquitectura orientada a servicios (SOA) es 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 se basan en las redes de comunicaciones para interconectar componentes, como servidores o servicios. Su carga de trabajo debe funcionar de manera fiable a pesar de la pérdida de datos o la latencia en estas redes. Los componentes del sistema distribuido deben funcionar de manera que no afecten negativamente a otros componentes o a la carga de trabajo. Estas prácticas recomendadas previenen los fallos y mejoran el tiempo medio entre errores (MTBD). | | 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 manera que no afecten negativamente a otros componentes o a 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 la carga de trabajo o el entorno para lograr un funcionamiento fiable de la carga de trabajo. Los cambios incluyen aquellos impuestos a la carga de trabajo, como los picos de demanda, además de los inherentes a ella, como las implementaciones de características o las revisiones de seguridad. AWS le permite supervisar el comportamiento de una carga de trabajo y automatizar la respuesta a los KPI. Por ejemplo, la carga de trabajo puede agregar servidores adicionales a medida que la carga de trabajo gane más usuarios. Puede controlar quién tiene permisos para aplicar 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 herramientas poderosas para obtener información sobre el estado de su carga de trabajo. Puede configurar su carga de trabajo para supervisar los registros y las métricas y enviar notificaciones cuando se superen los umbrales o se produzcan eventos significativos. 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 de forma automática 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 o eliminar recursos automáticamente, de modo que se ajusten perfectamente a la demanda actual en cualquier momento dado. | | REL 8: ¿Cómo implementa los cambios? | | --- | | Los cambios controlados son necesarios para implementar nuevas funcionalidades y comprobar que las cargas de trabajo y el entorno operativo ejecuten software conocido y que puedan recibir revisiones o reemplazos de manera predecible. Si estos cambios no se controlan, es difícil predecir su efecto o abordar los problemas que surjan a causa 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, aumenta la fiabilidad a la par que se garantiza que el éxito del negocio no se convierta en una carga. Al contar con supervisión, el equipo recibirá alertas automáticas cuando los KPI se desvíen de las reglas esperadas. Los registros automáticos de los cambios aplicados 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 la 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 supervisión. Por ejemplo, cuando una métrica concreta pasa un umbral, podrá iniciar 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 hace una copia de seguridad de los datos? | | --- | | Realice copias de seguridad de los datos, las aplicaciones y la configuración para cumplir con los 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? | | --- | | El aislamiento de fallos limita el impacto de un fallo en un componente o sistema a un límite definido. Mediante un aislamiento adecuado, los componentes que se encuentran fuera del límite no se ven afectados por el error. Hacer que la carga de trabajo supere varios límites de aislamiento de fallos puede hacer que sea más resistente a los fallos. | | 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 comprobar 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 los objetivos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) de restauración de las cargas 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 costo 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 errores para después observar cómo se recuperan. Haga esto de manera regular y asegúrese de que dichas pruebas también se inicien tras aplicar cambios importantes en la carga de trabajo. Haga un seguimiento activo de los KPI, 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). Hacer 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 efectuarse igual de bien que los procesos de producción normales.