Situación 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.

Situación 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 dé lugar a 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 el uso de AWS CloudFormation como parte de un enfoque de IaC.

Para este ejemplo, supongamos que un equipo de ingeniería escribe y, a continuación, implementa un programa totalmente probado que genera una respuesta automática si la capacidad de un volumen utilizado supera el 80 por ciento (un número arbitrario para este ejemplo). El programa responde al evento umbral llamando a las API para aumentar el tamaño del volumen. El equipo de ingeniería espera que el volumen siga creciendo con el tiempo, pero que no provoque 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 que a menudo se pasa por alto: la deriva.

Nota

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

Consecuencias involuntarias

La deriva se produce cuando se cambian las propiedades de los recursos fuera del sistema IaC. En este escenario, eso significa los recursos aprovisionados por CloudFormation. En este escenario, los ingenieros se puede reducir el tamaño de un volumen de EBS. La deriva introducida al utilizar la API en lugar de CloudFormation tiene un efecto dominó que genera problemas adicionales. El problema también se agrava con la implementación de actualizaciones de la misma pila en un DevOps proceso.

Como el tamaño del volumen cambió en el recurso fuera del repositorio de código, la CloudFormation plantilla no tiene conocimiento 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 están al tanto de los cambios en los recursos de volumen, sus plantillas no tendrán las actualizaciones necesarias. Los volúmenes son particularmente vulnerables a la deriva. No puede reducir el tamaño de almacenamiento. 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.

Un enfoque

En el siguiente diagrama se muestra el siguiente diagrama. 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 alinea con las mejores prácticas incluidas 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 CodeCommit para el control del código fuente, AWS CodePipeline para el despliegue automático de código y AWS Step Functions para la orquestación del flujo de trabajo sin servidor. Con este enfoque, CodePipeline agrega inicialmente el tamaño del volumen de EBS al almacén de parámetros (una función de AWS Systems Manager) y, a continuación, Step Functions realiza las actualizaciones posteriores.

Puede usar el Almacén de parámetros para ver un historial de los valores y usarlo para los valores que cambian. Parameter Store también se integra con varios servicios, CloudFormation como 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 cambio, la función Lambda interactúa con la API CloudFormation para actualizar. Como resultado, las CloudFormation pilas están protegidas contra la deriva. Por último, este enfoque CloudFormation se basa en la única fuente para realizar actualizaciones.

Escenario recomendado con volumen de EBS