Escenario de punto ciego - AWS Guía prescriptiva

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.

Escenario de punto ciego

En esta sección se proporciona un ejemplo de un escenario en el que un equipo de ingeniería puede tomar una decisión de TI que se traduce en un punto ciego con consecuencias no intencionadas que pueden perjudicar a su organización. El escenario hipotético supone que se crea un volumen de almacenamiento de Amazon Elastic Block Store (Amazon EBS) en la nube de AWS mediante AWS CloudFormation como parte de un enfoque de IaC.

Para este ejemplo, supongamos que un equipo de ingeniería diseña y, a continuación, implementa un programa completamente probado que genera una respuesta automática si la capacidad de un volumen utilizado supera el 80 por ciento (una cifra arbitraria en este ejemplo). El programa responde al evento de umbral llamando APIs para aumentar el tamaño del volumen. El equipo de ingeniería espera que el volumen siga aumentando con el tiempo, sin provocar una interrupción de la producción. El equipo de ingeniería ha resuelto el problema del espacio de almacenamiento, pero surge involuntariamente otro problema sutil y a menudo ignorado: la deriva.

Nota

Esto es solo un ejemplo y son posibles otros escenarios. Por ejemplo, podría reemplazar el volumen de EBS por un grupo de seguridad en el que el equipo de ingeniería cree una regla de entrada que permita el tráfico desde una dirección IP dinámica en función de un evento.

Consecuencias no intencionadas

La desviación se produce cuando se cambian las propiedades de los recursos fuera del sistema IaC. En este escenario, se refieren a los recursos aprovisionados por. CloudFormation En este escenario, los ingenieros utilizan una API para aumentar el tamaño de un volumen de EBS. La desviación que supone el uso de la API en lugar de CloudFormation ella tiene un efecto dominó que genera problemas adicionales. El problema también se agrava con la implementación de la misma pila de actualizaciones en un DevOps proceso.

Como el tamaño del volumen ha cambiado en el recurso externo al repositorio de código, la CloudFormation plantilla no es consciente del cambio. Por lo tanto, cualquier implementación fallará hasta que el aumento del tamaño del volumen se incorpore a la CloudFormation plantilla. Y lo que es más importante, si los ingenieros no son conscientes de los cambios en el volumen de recursos, sus plantillas no tendrán las actualizaciones necesarias. Los volúmenes son particularmente vulnerables a la desviación. Después de aumentar el tamaño de almacenamiento por volumen, no puede reducirlo. Por lo tanto, la CloudFormation plantilla no solo no se actualiza, sino que tampoco se puede revertir porque no se puede aplicar el valor del parámetro de tamaño.

Enfoque problemático

El siguiente diagrama muestra una solución problemática al escenario de ejemplo. El usuario, como parte del flujo de trabajo, sigue un enfoque de IaC y aprovisiona un volumen de EBS mediante una CloudFormation plantilla. El equipo de supervisión de la producción utiliza un enfoque de automatización de EDP y crea una regla de Amazon CloudWatch Events. Esta regla está configurada para invocar una función de AWS Lambda cuando el volumen de EBS alcanza un umbral de almacenamiento específico. A continuación, la función Lambda llama a la API para aumentar el tamaño del volumen de EBS.

Escenario problemático con el volumen de EBS

El siguiente diagrama muestra un enfoque recomendado que se ajusta a las prácticas recomendadas descritas en la sección de mejores prácticas de esta guía. Este enfoque implica una mayor complejidad y más servicios de AWS, como Amazon Simple Notification Service (Amazon SNS) para el envío de notificaciones, AWS para el control de código fuente, CodeCommit AWS para la implementación automatizada de código y CodePipelineAWS Step Functions para la organización de flujos de trabajo sin servidores. En este enfoque, inicialmente se CodePipeline añade el tamaño del volumen de EBS al almacén de parámetros (una capacidad de AWS Systems Manager) y, a continuación, Step Functions realiza las actualizaciones posteriores.

nota

AWS CodeCommit ya no está disponible para nuevos clientes. Los clientes existentes de AWS CodeCommit pueden seguir utilizando el servicio con normalidad. Más información

Puede utilizar el almacén de parámetros para ver un historial de los valores y utilizarlo para los valores que cambien. Parameter Store también se integra con varios servicios, como CloudFormation Lambda. La función Lambda en este escenario no interactúa directamente con el volumen de EBS para aumentar el tamaño del volumen. En su lugar, la función Lambda interactúa con ella CloudFormation para actualizar la API. Como resultado, las CloudFormation pilas están protegidas contra la deriva. Por último, este enfoque se basa en CloudFormation la única fuente para realizar las actualizaciones.

Escenario recomendado con volumen de EBS