View a markdown version of this page

Pilar de excelencia operativa - AWS Orientación prescriptiva
Automatice la implementación mediante un enfoque de IaCCambios frecuentes, pequeños y reversiblesAnticipación de los erroresLecciones de los errores operativosUso de características de registro para supervisar la actividad no autorizada o anómala

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.

Pilar de excelencia operativa

El pilar de excelencia operativa del AWS Well-Architected Framework se centra en el funcionamiento y la supervisión de los sistemas, y en la mejora continua de los procesos y procedimientos para ofrecer valor empresarial. El pilar de la excelencia operativa incluye la capacidad de respaldar el desarrollo y ejecutar las cargas de trabajo de manera eficaz, así como de obtener información sobre su funcionamiento.

Puede reducir la complejidad operativa mediante cargas de trabajo con capacidad de recuperación automática, que detectan y solucionan la mayoría de los problemas sin intervención humana. Para lograr este objetivo, siga las prácticas recomendadas que se describen en esta sección. Utilice CloudWatch las métricas de Amazon para Amazon Timestream para InfluxDB, el punto final de métricas nativo de InfluxDB, y los mecanismos para responder cuando su carga de APIs trabajo se desvíe del comportamiento esperado.

Este análisis del pilar de excelencia operativa se centra en las siguientes áreas clave:

  • Infraestructura como código (IaC)

  • Administración de cambios

  • Estrategias de resiliencia

  • Administración de incidentes

  • Registro y supervisión con fines de auditoría

Automatice la implementación mediante un enfoque de IaC

Las mejores prácticas para automatizar la implementación en Timestream para InfluxDB mediante IaC incluyen las siguientes:

Cambios frecuentes, pequeños y reversibles

Las siguientes recomendaciones se centran en cambios pequeños y reversibles para minimizar la complejidad y reducir la probabilidad de que se interrumpa la carga de trabajo:

  • Guarde las plantillas y scripts de IaC en un servicio de control de código fuente, como o. GitHub GitLab No almacene las AWS credenciales en el control de código fuente.

  • Exija que las implementaciones de IaC utilicen un servicio de integración y entrega continuas (CI/CD), como AWS CodeDeploy o AWS CodeBuild. Estos servicios compilan, prueban e implementan código en un entorno no de producción que contiene una instancia efímera de InfluxDB antes de afectar a la instancia de InfluxDB de producción.

  • Pruebe las consultas de infraestructura y aplicaciones en un entorno inferior antes de implementarlas en producción. Esto minimiza la probabilidad de que se produzca una interrupción y ayuda a garantizar que funcionen bien con su carga de trabajo y su escalabilidad.

Anticipación de los errores

Una infraestructura que se recupere automáticamente ejemplifica la excelencia operativa, pues anticipa los errores y trata de resolver cualquier problema sin intervención. Las siguientes recomendaciones le ayudarán a alcanzar esa madurez con Timestream para InfluxDB:

  • Utilice métricas para supervisar la memoria, la CPU y el uso de almacenamiento. Puede configurar CloudWatch para notificar cuándo cambian los patrones de uso o cuándo se está llegando al límite de capacidad de la implementación. De esta forma, puede mantener el rendimiento y la disponibilidad del sistema.

  • Amplíe su instancia de base de datos cuando se acerque al límite de recursos. Debe tener búfer de almacenamiento y de memoria para asumir incrementos imprevistos de la demanda de las aplicaciones.

  • Si la carga de trabajo de su base de datos requiere I/O más de lo que ha aprovisionado, la recuperación tras una conmutación por error o un fallo en la base de datos será lenta. Para aumentar la capacidad. I/O capacity of a DB instance, migrate to a different DB instance that has higher I/O

  • Si la aplicación cliente almacena en caché los datos de DNS de las instancias de base de datos, establezca un valor time-to-live (TTL) inferior a 30 segundos. La dirección IP subyacente de una instancia de base de datos puede cambiar después de producirse una conmutación por error. El almacenamiento en caché de los datos del DNS durante un período prolongado puede provocar fallos de conexión. Es posible que tu aplicación intente conectarse a una dirección IP que ya no esté en servicio.

  • Si su aplicación necesita sobrevivir a una Región de AWS interrupción total, considere configurar la replicación o escribirla a otra región como parte de sus planes de recuperación ante desastres (DR). Comprenda las limitaciones a la hora de configurar la replicación. Para obtener más información sobre la replicación, consulte la documentación de InfluxDB.

Lecciones de los errores operativos

Una infraestructura autorreparable es un esfuerzo a largo plazo que se desarrolla de forma iterativa cuando se producen problemas poco frecuentes o las respuestas no son tan eficaces como se desearía. Para centrarse en lograr una infraestructura que se recupere automáticamente, adopte las siguientes prácticas:

  • Aprenda de los errores para impulsar la mejora.

  • Comparta las conclusiones con los equipos y la organización. Si varios equipos de una organización utilizan Timestream para InfluxDB, cree una sala de chat o un grupo de usuarios común para compartir las lecciones aprendidas y las mejores prácticas.

Uso de características de registro para supervisar la actividad no autorizada o anómala

Para observar patrones anómalos de rendimiento y actividad, tenga en cuenta las siguientes prácticas:

Para obtener más información, consulte la documentación de Timestream for InfluxDB.